Your PGx RFP checklist should make these requirements non-negotiable: CPIC level A or B or FDA-recognized actionability for every recommendation, HL7/FHIR machine-readable outputs with CDS-ready genotype-to-phenotype tables, and documented CLIA/CAP validation. Beyond those, specify living reanalysis, security and compliance, SLAs, and pilot deliverables in the RFP itself, so each requirement can be tested rather than merely promised.
TL;DR:
- Exclude proposals from scoring unless bidders document CPIC A or B or FDA recognized gene drug mapping, CLIA/CAP validation, and HL7/FHIR outputs.
- Validation should document accuracy, precision, sensitivity, specificity, and reportable ranges; require at least 20 characterized samples and explanations of copy number and structural variant handling.
- Require sample FHIR order and result payloads, CDS trigger examples, sandbox access, and acceptance tests covering retries, error handling, audit logs, and the full workflow.
- Weight interoperability at 20%, compare total cost across licensing, implementation, training, and ongoing fees, and verify claims through pilots rather than demonstrations.
- Require living reanalysis cadence, evidence sources, notification methods, and governance, plus CPT mapping and claim documentation that prevent repeat germline testing.
Table of Contents
- What should a PGx RFP checklist include?
- How should you score and rank vendor proposals?
- What integration requirements should the RFP specify?
- What validation evidence should procurement demand?
- What billing and coverage documentation should vendors supply?
- What operational and legal checks belong in vendor due diligence?
- Where most PGx RFPs go wrong
- A white-label option built around this checklist
- FAQ
- Sources
What should a PGx RFP checklist include?
Write each item as something a bidder can prove with a document, a payload, or a pilot result. Vague feature requests produce vague proposals. The list below can be pasted into your RFP as a baseline.
- Functional scope: define the gene and variant list, panel versus single-gene testing, how actionability is declared (CPIC A/B or the FDA list), and whether combinatorial algorithms are used.
- Reporting deliverables: clinician report, patient summary, machine-readable genotype-to-phenotype tables, and sample report PDFs with example outputs.
- Interoperability: compatibility with the Genomics FHIR Implementation Guidance, example FHIR resource payloads, and CDS trigger definitions.
- Analytical validation: method validation reports covering accuracy, precision, sensitivity and specificity, reportable ranges, CNV/SV handling, and minimum characterized samples.
- Regulatory: CLIA/CAP proof, a proficiency testing approach, and documented QA/QC processes.
- Security and privacy: HIPAA/GDPR compliance statements, encryption, data residency, and audit logs.
- Operational terms: SLAs, uptime, incident response, and the living reanalysis cadence with its notification methods.
- Implementation: pilot scope, sandbox access, a testing plan with acceptance criteria, and an expected deployment timeline.
- Commercial terms: pricing model, pilot pricing, change-order governance, white-label rights, and termination and transition plans.
- Support: onboarding, training, API documentation, clinical governance structure, and named contact points.
A realistic RFP timeline runs from issuance through written questions, proposal receipt, scripted demos, a sandbox or pilot window, and final selection. Exact durations depend on your institution, so set the milestones in the document and hold bidders to them.
Pro Tip: Attach a blank response matrix to the RFP and require every bidder to answer each checklist item with "meets," "partially meets," or "does not meet," plus the evidence document that proves it.
How should you score and rank vendor proposals?
Start with pass/fail gates, then score what survives. A proposal that cannot show CPIC A/B or FDA-recognized gene-drug mapping, CLIA/CAP proof, and HL7/FHIR machine-readable outputs should not reach the weighted rubric at all.
Here is a sample weighting you can adapt to your own priorities:
- Clinical validity and evidence grading
- Interoperability and machine-readable outputs: 20%
- Analytical validation documentation
- Implementation plan and support
- Security and compliance
- Price and total cost of ownership, covering licensing, implementation, training, and ongoing fees
Judge evidence by what a bidder hands you: validation sets, method descriptions, and real example outputs outweigh marketing language. Verify the rest during the pilot rather than taking it on trust.
Treat these as red flags: no sandbox access, an opaque knowledge base, and no living reanalysis plan. A bidder who cannot say where its recommendations come from, or how they change when guidelines change, cannot be audited later.
What integration requirements should the RFP specify?
Interoperability claims are cheap until you require artifacts. Ask for these and test them:
- Conformity with the Genomics FHIR Implementation Guidance and sample FHIR payloads for both orders and results.
- A curated, machine-readable knowledge base, meaning CPIC-style tables that map genotype to phenotype to recommendation, with CDS trigger examples.
- API documentation, sandbox credentials, message schemas, and a test harness for integration testing.
- Defined acceptance tests for error handling, message retries, audit logging, and the full order-to-result workflow.
Static, human-readable reports do not drive genuine EHR decision support. If you want a practical sequence for rollout, our guide on mapping one gene-drug pair in FHIR first walks through a phased approach, and our CPIC implementation checklist is a useful source of acceptance tests.
What validation evidence should procurement demand?
PGx testing is high-complexity under CLIA, so method validation must be documented, including accuracy, precision, analytical sensitivity and specificity, and reportable ranges. Industry practice typically uses a minimum of 20 previously characterized samples, so ask each bidder to state its sample count and justify it.
Require an explicit explanation of how copy-number and structural variants are detected and reported, since these are where simple panels often fall short. Ask for proficiency testing participation and a written policy for handling variants of uncertain significance.
Reports should use HGVS nomenclature and public reference sequences, so that any result can be traced and reproduced. Our piece on evidence-graded PGx reporting shows how defensible grading looks in a lab report. If your team is also vetting bioinformatics pipelines, this validation-first guide to bioinformatics companies offers useful background.
What billing and coverage documentation should vendors supply?
Coverage follows actionability. A Medicare LCD for pharmacogenomic testing describes testing as reasonable and necessary when results directly affect drug management and are actionable per CPIC level A/B or listed FDA associations, with analytical validity, clinical validity, and clinical utility supported.
Ask each vendor to map test components to CPT codes and to show the clinical documentation it will provide for claims. CMS billing and coding guidance covers CPT expectations and documentation that helps avoid duplicative testing, so require vendors to explain how their workflow prevents repeat germline testing and captures the billing fields payors need. For more detail, see our lab billing guide and CPT code reference.
What operational and legal checks belong in vendor due diligence?
Technical fit means little if the vendor cannot be held accountable. Verify these before awarding:
- CLIA/CAP certificates, third-party audit reports, and compliance evidence.
- Customer references for clinical deployments, with documented pilot outcomes. Ask for case examples of live PGx reporting deployments, not slide-deck claims.
- The living reanalysis roadmap, the evidence source list, and the medical director's governance responsibilities.
- Data portability and exit plans, SLAs with penalties, and transition assistance terms.
Also ask prospective vendors how their platform will scale as your test volume, gene list, and customization needs grow.
Where most PGx RFPs go wrong
Most weak RFPs fail the same way: they reward the best demo instead of the best evidence. A polished sample report proves nothing about how the knowledge base behaves when CPIC revises a guideline. Make bidders show you machine-readable outputs before you shortlist, set pilot acceptance criteria that a failing system cannot pass, and require sandbox access before award. Treat white-label and rapid-deploy promises as claims to verify against documented timelines and reference deployments.
— Tarek
A white-label option built around this checklist
We built SignalPGx's white-label PGx reporting around these requirements: evidence-graded reports, HL7/FHIR integration, medical-director review with an audit trail, and living reanalysis that updates recommendations as guidelines change. Labs can deploy their branded service. Ask us for sandbox access or a technical integration call, and test us against your own checklist.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
FAQ
What is a PGx RFP checklist?
It is a structured list of requirements a laboratory or health system sends to vendors when buying pharmacogenomics products or services. It covers evidence standards, interoperability, validation, security, support, and commercial terms so proposals can be compared fairly.
Which evidence standard should a PGx RFP require?
Require recommendations aligned with CPIC level A or B guidelines or FDA-recognized gene-drug tables. This is also the actionability standard that coverage policies reference.
How many samples does PGx validation typically need?
Validation typically uses a minimum of 20 previously characterized samples. Ask vendors to state their count and explain how they handled CNVs and structural variants.
Why require machine-readable outputs?
Static reports cannot trigger clinical decision support. CPIC-style, EHR-agnostic implementation tables let genotype results map to phenotypes and automated alerts inside the EHR.