POCT software RFP template: requirements you can copy

How to structure a POCT software RFP

A request for proposal (RFP) is the document you send to vendors that says what you need, how they should respond and how you will decide. For point-of-care testing (POCT) connectivity and data management software, a workable RFP has seven parts.

1. Background. Who you are, how many sites, how many analysers by model, roughly how many tests a year, which laboratory information system (LIS) or clinical systems the results must reach, and whether the POCT service is accredited or working towards accreditation under ISO 15189:2022.
2. Scope. What is in (devices, sites, interfaces, modules) and what is out (the analysers themselves, the network, the clinical system licence).
3. Requirements. The numbered tables below, each with a priority and a space for the vendor to answer.
4. Response instructions. The format you want, the response codes, the deadline, who takes questions and by when, and whether a demonstration on your own analysers is part of the evaluation. It should be.
5. Evaluation method. The weights and the scoring scale, published up front so vendors know what matters.
6. Commercial and contractual terms. Contract length, payment terms, the data processing agreement, exit provisions.
7. Appendices. Your device list, your site list, your interface diagram and your information governance questionnaire.

Keep the requirements list to the things you will score. Fifty well-chosen requirements produce better responses than two hundred that vendors answer with a yes and nobody reads.

How to use this template

Each requirement has a reference, a priority and a space for the vendor's response.

• Priority. M is mandatory: a vendor that cannot meet it is excluded. S is should have: scored, and a strong influence on the decision. C is could have: scored at a lower weight or noted for the future. Set these yourself; the priorities below are a starting point for an organisation with several sites and an LIS. A single-site clinic with no LIS would move F2 to mandatory and F1 to could have.
• Vendor response. Ask vendors to answer with one of four codes, then explain: F fully met by the current released product; P partially met, with the gap described; R on the roadmap, with a date; N not met. Require evidence for every F on a mandatory requirement: a screenshot, a demonstration or a reference site.

Renumber if you delete rows. Terms used in the tables are explained in the POCT and connectivity glossary.

The template: requirement tables

Copy the tables below into your own document. Appendix 1 is your device list by model; Appendix 2 is the list of systems a result must reach.

A. Connectivity and devices

The four protocols named here are explained in HL7 vs POCT1-A2 vs ASTM.

B. Patient identity and results

C. Quality control, EQA and competency

These map to the quality requirements in ISO 15189:2022 and its Annex A on point-of-care testing; see ISO 15189:2022 and POCT.

D. Multi-site administration

E. Security, hosting and data protection

Ask for evidence, not logos. Cyber Essentials is the UK baseline; the Data Security and Protection Toolkit is the NHS self-assessment; DTAC is an assessment an NHS buyer carries out on the supplier's evidence, not a badge a vendor holds, so it is phrased below as a question.

F. Integration with LIS and clinical systems

G. Reporting and analytics

H. Implementation, training and support

I. Commercial

Scoring the responses

Publish the method in the RFP so vendors know how they will be judged, then apply it without exception.

1. Exclude any vendor answering N, or P without a credible workaround, on a mandatory requirement.
2. Score each remaining requirement 0 to 3: 0 for N, 1 for R with a date inside the contract term, 2 for P, 3 for F with evidence.
3. Weight the sections. A typical split for a multi-site organisation with an LIS: connectivity 20, identity and results 15, QC and competency 20, multi-site 5, security 15, integration 10, reporting 5, implementation 5, commercial 5. Change it to suit your setting; a single-site clinic might give integration 20 and multi-site 0.
4. Score the demonstration separately, on your own analysers, and give it real weight. Written answers describe intent; the demonstration shows the product.
5. Score the three-year total cost last, after the quality scores are locked, so price does not colour the technical evaluation.

Record who scored what and why. A scoring sheet with initials survives a challenge; a consensus number does not.

Common mistakes in POCT RFPs

• Listing devices by brand rather than model. A vendor may support one generation of a meter but not the next, or the serial version but not the Wi-Fi one. Give model numbers and firmware versions.
• Forgetting the other side of the interface. The middleware vendor can only build half of an LIS or clinical system interface. Ask in the RFP what the other supplier will charge and who tests it, and check that budget exists.
• Asking for certifications the product cannot hold. Whether connectivity and data management software is a medical device depends on its intended purpose and functions in each jurisdiction, not only on whether it interprets results, so rather than demanding CE marking or FDA clearance by default, require a documented regulatory assessment of the intended purpose and functions with the applicable conformity evidence. Ask instead for security certifications, a data processing agreement and the vendor's stated regulatory position.
• Treating DTAC as a certificate. DTAC is an assessment an NHS organisation carries out on a supplier's evidence, not an approval a vendor is granted. Ask whether an evidence pack is ready and whether the vendor has been through one before, and plan to run your own.
• Accepting yes without evidence. Require the response codes and evidence for mandatory items. A screenshot from a released version is worth more than a paragraph.
• No exit clause. If the RFP does not ask for data export on exit, the contract will not include it.
• Scoring price first. The cheapest response on paper often excludes interfaces, training or drivers. Compare three-year totals with assumptions, after the quality scores.
• Leaving out the operators. The nurses and healthcare assistants who use the devices should see the shortlisted products before the decision. They will find the workflow problems that the coordinator will not.

Sending the template out

Send the RFP to three to five vendors whose products fit your setting; hospital middleware built around an LIS and a clinic platform built around a practice system are different products, and Point-of-care testing software: a buyer's guide explains the difference. Allow three to four weeks for responses, hold a question period in the first week and share every answer with every vendor. Catenix will respond to this template as written; use the contact page to send it, with your device and system appendices attached.

Questions people ask

What should a POCT software RFP include?

Background on your sites, analysers and systems; scope; numbered requirements with priorities covering connectivity, patient identity, QC and competency, multi-site administration, security and data protection, integration, reporting, implementation and commercial terms; response instructions with codes and a deadline; the evaluation method with weights; contract terms; and appendices listing every device by model and every system a result must reach.

What is the difference between an RFI and an RFP for POCT software?

A request for information (RFI) asks vendors what they offer, without commitment, and is useful early on to learn the market and shape requirements. A request for proposal (RFP) asks for a priced, binding response against your specific requirements and is the basis for a decision. Many organisations run a short RFI first, then send the RFP to a shortlist of three to five vendors.

How many requirements should a POCT RFP have?

Enough to cover every capability you will score, and no more. Between forty and seventy is typical for POCT connectivity and data management software. Beyond that, vendors answer yes to everything and evaluators stop reading. Mark each as mandatory, should have or could have, and require evidence for every mandatory item rather than adding more rows.

Should we ask about DTAC in a POCT software RFP?

Yes, as a question, not as a pass or fail. The Digital Technology Assessment Criteria (DTAC) is an assessment that an NHS organisation carries out on a supplier's evidence covering clinical safety, data protection, security, interoperability and usability. Ask whether the vendor has an evidence pack ready and whether it has completed a DTAC assessment with another organisation, then plan to run your own.

How do we score POCT software RFP responses?

Exclude vendors that fail a mandatory requirement. Score the rest 0 to 3 per requirement, weight the sections according to your setting, and score the demonstration on your own analysers separately. Score the three-year cost last, after the quality scores are locked. Record each evaluator's scores and reasons individually so the decision can be explained later.

Do we have to go out to tender for POCT middleware in the NHS?

It depends on the contract value against your organisation's standing financial instructions and the procurement regulations in force, and on whether a framework agreement is available. Ask your procurement team before you start; they will tell you whether quotations, a framework call-off or a full tender applies. The requirement tables on this page work for any of those routes.

Sources and further reading

• ISO 15189:2022 Medical laboratories: requirements for quality and competence
• MHRA, Management and use of IVD point of care test devices
• National Cyber Security Centre, Cyber Essentials
• NHS England, Digital Technology Assessment Criteria (DTAC)
• NHS Data Security and Protection Toolkit
• Data Protection Act 2018 (UK GDPR)