Interoperability projects fail less often on the standard itself and more often on a partner who claims "FHIR support" without the network connections, security implementation, or production experience to back it up. This checklist is for the health system CTO, hospital IT director, or health-tech product lead evaluating an integration partner for an EHR, HIE, or patient-data-exchange project.

Standards support — go deeper than "FHIR compliant"

  • [ ] Do they support FHIR R4 specifically, aligned with the US Core Implementation Guide and USCDI v3 — not an older FHIR version or a partial implementation?
  • [ ] Can they demonstrate structured data handling for labs (LOINC), medications (RxNorm), and conditions (SNOMED CT) — not just message passing, but actual terminology mapping?
  • [ ] Do they support SMART on FHIR for authorization, and HL7 UDAP for scalable registration and authentication?
  • [ ] If your environment still runs HL7 v2 feeds, do they have real production experience translating v2 to FHIR R4, including the semantic gaps that don't map cleanly?
  • [ ] Are they ONC-certified, or do they integrate cleanly with your existing ONC-certified EHR without requiring you to replace it?

TEFCA and network readiness

  • [ ] Are they TEFCA-ready today, or is that "on the roadmap"? Networks are required to expose data via FHIR APIs aligned with USCDI v3 well before most 2026 deadlines — a partner still building toward this is a partner behind schedule.
  • [ ] Which QHIN(s) can they connect you to — Epic Nexus, Carequality, CommonWell, eHealth Exchange, Health Gorilla, Kno2, KONZA? Ask specifically, not generically.
  • [ ] Do they support Common Agreement attestations and identity proofing to the NIST SP 800-63-3 standard (IAL2/AAL2)?
  • [ ] If you're not on TEFCA yet, can they walk you through a concrete adoption roadmap with dates, not just a diagram?

Security and compliance architecture

  • [ ] How is PHI protected in transit and at rest across every integration point, not just the primary data store?
  • [ ] Do they implement FHIR Provenance so every data exchange has an auditable record of source and modification?
  • [ ] What's their HIPAA compliance posture — do they sign a Business Associate Agreement, and can they show you evidence of a recent risk assessment?
  • [ ] How do they handle authentication and rate limiting at the API layer — this is a regulatory requirement now, not an optional hardening step?

Scale and production readiness

  • [ ] Can they show a reference deployment handling volume comparable to yours — not a pilot, a production system?
  • [ ] What are their sub-second response time guarantees for real-time data exchange, and what's the SLA if they're missed?
  • [ ] How do they handle version control and monitoring across the integration layer as both your EHR and their platform evolve?
  • [ ] What's the actual go-live timeline they're quoting, and does it include time for semantic data mapping and testing — not just connection setup?

Vendor experience and support model

  • [ ] How many production healthcare interoperability projects have they shipped, specifically in a setting similar to yours (hospital system, ambulatory network, payer, health-tech vendor)?
  • [ ] What does post-go-live support actually look like — dedicated team, ticket queue, or something in between?
  • [ ] Can they provide a reference customer who will speak candidly about what went wrong during implementation, not just what went right?
  • [ ] Is pricing transparent up front, including the cost of ongoing maintenance and future API version upgrades?

Red flags

  • "FHIR compliant" with no specifics on which version, which implementation guide, or which USCDI version
  • No clear TEFCA roadmap or QHIN relationships when your organization needs one
  • Vague answers on PHI encryption or BAA terms
  • A go-live timeline with no allowance for data mapping or testing
  • No production reference you can actually call

How to use this

Start with the standards-support section — it filters out vendors making broad interoperability claims without the specifics to back them up. If a vendor can't answer the FHIR version and USCDI alignment questions precisely, that's usually enough signal to move on before spending time on the rest of the checklist.