Most EHR evaluations focus on price and screen layout. Interoperability — whether the system can actually talk to hospitals, labs, specialists, and your state’s health information exchange — usually gets a single checkbox on a vendor’s glossy sales sheet. That is a mistake. A practice that signs a multi-year EHR contract without verifying interoperability in detail can end up isolated: unable to pull outside records at the point of care, unable to participate meaningfully in a health information exchange (HIE), and stuck re-keying data that should have arrived automatically. This checklist walks through the specific things to verify before signing, not after.
Start With ONC Certification — But Read the Certificate
The Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification Program sets national standards for EHR data accuracy, security, and information-sharing capability, and every certified product undergoes third-party testing before it can carry the certification. Using a certified EHR is what allows a practice to avoid Medicare payment adjustments and, where applicable, receive Medicaid EHR incentive payments — but "ONC-certified" is not a single fixed bundle of features. Certification is awarded module by module, and a vendor can be certified for basic functions while lacking certification for the specific interoperability criteria a practice actually needs. Ask the vendor for the exact certification ID and cross-check which criteria it covers, rather than accepting "we’re certified" as a complete answer.
Confirm Real FHIR API Support, Not Just the Word "FHIR" on a Slide
Fast Healthcare Interoperability Resources (FHIR) is the modern, API-based standard for exchanging clinical data between systems, built around discrete, standardized data elements — a patient record, a medication, a lab observation — rather than a single flat document. The ONC Cures Act Final Rule required certified health IT developers to expose FHIR-based APIs, and the large majority of developers met that compliance deadline, so FHIR support alone is no longer a differentiator. What is worth asking:
- Is the FHIR API read-only, or can outside systems write structured data back into the record?
- Which FHIR resource types are actually implemented (patient demographics only, or also observations, medications, and care plans)?
- Is there a sandbox environment where your practice or your IT vendor can test the connection before go-live, rather than discovering gaps after the contract is signed?
Ask Specifically About HIE Connectivity
ONC certification and FHIR support are necessary groundwork, but they do not automatically mean the EHR is actually connected to your state’s health information exchange. HIE connectivity is a separate, practical question: does the vendor already have a live, working connection to the exchange your practice will use, or would that connection need to be built and tested as a separate project after implementation? A vendor that has already done this integration work for other practices in the same state can typically get a new practice connected in weeks; a vendor doing it for the first time may take months, and the cost of that build is not always itemized up front. For a practice that treats HIE participation as core to how it coordinates care — pulling a patient’s hospital discharge summary, a specialist’s note, or outside lab results at the point of care — this is not a nice-to-have. It is the difference between an EHR that reduces duplicate testing and delayed diagnoses and one that simply digitizes the same information silos a practice had on paper.
A Practical Comparison Framework
| Evaluation Question | Why It Matters | What to Ask the Vendor |
|---|---|---|
| Which specific ONC criteria are certified? | Certification is modular; broad claims can hide gaps in the features you actually need. | Request the certification ID and the criteria list, not a marketing summary. |
| Does the FHIR API support write-back, not just read? | Read-only access limits how much outside data can flow into the chart automatically. | Ask for a live sandbox demo, not a slide. |
| Is the vendor already connected to your state HIE? | An existing connection is faster and cheaper than building one from scratch. | Ask for a reference practice already live on that exchange. |
| Who owns the interoperability build cost? | HIE connection work is sometimes billed separately from the base license. | Get the interoperability setup cost itemized in writing. |
| What is the data export process if you switch vendors later? | Poor export terms can trap a practice in a system it has outgrown. | Ask for the export format and timeline in the contract. |
Why This Is Worth the Extra Diligence
Interoperability participation is increasingly tied to reporting programs like Promoting Interoperability and to how quickly a practice can act on outside information — a specialist consult note, a hospital discharge summary, an allergy update from another provider. A practice that verifies ONC certification detail, real FHIR write capability, and actual HIE connectivity before signing avoids the more common outcome: discovering, months into implementation, that "interoperable" on the sales sheet meant something much narrower in practice. Because vendor capability in this area varies significantly and changes as certifications are renewed, it is worth working with someone who tracks which vendors are already connected to your specific state exchange rather than relying on a vendor’s own claims alone.
Conclusion
Choosing an EHR is ultimately a decision about how connected your practice will be to the rest of the healthcare system around it. ONC certification, genuine FHIR API support, and confirmed HIE connectivity are the three concrete things to verify — in writing, with specifics, before signing — so that the EHR you choose actually functions as an interoperability tool rather than a closed system with an interoperability checkbox.