What it is
The HL7/FHIR Interoperability Readiness Checklist is a scoping and validation guide for connecting your EHR to labs, imaging, pharmacies, health information exchanges, and patient apps without months of interface surprises. Its central truth is that interoperability lives and dies on standards: HL7 v2 still carries most legacy feeds, FHIR R4 powers modern APIs, and USCDI defines the data classes you're expected to exchange. The checklist helps you scope interfaces, validate against certification requirements, and avoid the information-blocking traps that get health systems into regulatory trouble.
The document is built around a standards-and-data foundation, an interface inventory by standard, interface-scoping questions, and a go-live path. The foundation section makes you confirm your EHR's certified FHIR R4 API endpoints and SMART on FHIR app-launch support, map which USCDI data classes you must exchange (problems, meds, allergies, labs, clinical notes), inventory the legacy HL7 v2 interfaces still in production (ADT, ORM, ORU, SIU, DFT, MDM), and verify terminology bindings — LOINC for labs, RxNorm for meds, SNOMED CT for problems, ICD-10 for billing.
Where it pays off is in the scoping discipline it imposes before you build. The checklist asks whether each interface is mapped field-by-field with agreed code sets on both ends, whether you've tested against real production-volume messages rather than vendor sample payloads, whether patient-app access via FHIR meets ONC information-blocking and API requirements, and who owns monitoring and error queues once an interface is live. These are the questions whose absence turns a 'quick interface' into a months-long surprise, and answering them up front is what the readiness path is for.
What it's used for
Integration teams use this checklist to scope and stand up EHR interfaces predictably, replacing the all-too-common pattern of optimistic estimates and production surprises with a standards-grounded readiness path. It's most useful before any interface work begins.
- ✓ Confirming the EHR's certified FHIR R4 API endpoints and SMART on FHIR app-launch support so modern app and patient-access integrations have a foundation.
- ✓ Mapping the USCDI data classes you must exchange — problems, medications, allergies, labs, clinical notes — so the interface scope reflects real data needs.
- ✓ Inventorying legacy HL7 v2 interfaces in production (ADT, ORM, ORU, SIU, DFT, MDM) so nothing in the existing ecosystem is overlooked during a transition.
- ✓ Verifying terminology bindings (LOINC, RxNorm, SNOMED CT, ICD-10) so coded data actually maps between systems instead of breaking.
- ✓ Scoping each interface field-by-field with agreed code sets on both ends, and testing against real production-volume messages rather than vendor sample payloads.
- ✓ Confirming patient-app access via FHIR meets ONC information-blocking and API requirements, keeping the organization clear of regulatory exposure.
- ✓ Assigning ownership of monitoring and error queues so live interfaces don't silently fail without anyone watching.
Who uses it
Interoperability is owned by integration specialists but depends on input from clinical, compliance, and vendor stakeholders, and the checklist is structured to coordinate them around a standards-based readiness path.
Context & good to know
Interoperability projects fail predictably, and almost always for the same reasons: the team underestimated mapping, tested against clean vendor samples instead of messy production traffic, or never agreed on code sets with the partner on the other end. The checklist front-loads exactly these failure points. By insisting that each interface be mapped field-by-field with agreed code sets on both ends and tested against real production-volume messages, it converts the optimistic 'just a quick interface' estimate into a scoped, validated piece of work — which is the difference between hitting a date and discovering surprises in production.
The standards landscape itself explains why the checklist separates legacy from modern. HL7 v2 has carried clinical messaging for decades and still runs the ADT, lab order (ORM), result (ORU), scheduling (SIU), charge (DFT), and document (MDM) feeds in most production environments, so it can't be ignored even as organizations adopt FHIR. FHIR R4, with SMART on FHIR app launch, is the modern API standard the ONC certification program now requires for patient and app access, and USCDI defines the floor of data classes that must be exchangeable. Verifying terminology bindings — LOINC, RxNorm, SNOMED CT, ICD-10 — is what makes the coded data in those feeds actually usable on the receiving end rather than arriving as unmatched codes.
The regulatory dimension is what raises interoperability from a technical project to a compliance obligation. The ONC information-blocking rules require that organizations not unreasonably restrict access, exchange, or use of electronic health information, and the standardized FHIR API certification (the §170.315(g)(10) criterion) underpins patient and third-party app access. An EHR that's been certified — whether Epic, eClinicalWorks, or Azalea Health — provides the API foundation, but the organization is still responsible for enabling it and for ensuring patient-app access actually works. The checklist's information-blocking questions exist so that interoperability readiness includes staying on the right side of these rules, not just making interfaces technically function.