FHIR Exchange for a Regional HIE After a Vendor Switch
A 5-hospital regional health information exchange uses a query-based model over a legacy HL7 v2 interface engine. One member hospital migrates to a new EHR that supports FHIR R4 and US Core profiles but only exposes a limited set of resources: Patient, Encounter, Condition, MedicationRequest, and Observation. The HIE's admission-discharge-transfer notifications currently depend on v2 ADT messages the new system can emit only as batch nightly files. Public health reporting and the HIE's care-gap dashboard rely on real-time ADT. The HIE has 14 downstream consumers, 3 of which still use v2 exclusively. The migration go-live is in 90 days, and the state requires syndromic surveillance reporting within 24 hours of an encounter.
1. What is the realistic interoperability architecture for the 90-day window, and how do you sequence it?
Read the worked answer
Accept a hybrid, not a clean FHIR cutover. Sequence: (1) keep v2 ADT as the real-time backbone for the 14 consumers and 24-hour public health requirement, since batch nightly FHIR cannot meet the timeliness constraint; (2) stand up a FHIR facade for the resources the new system exposes, using US Core profiles, and map to the HIE's canonical data model; (3) use a translation layer (v2-to-FHIR or an integration engine mapping) so the 3 v2-only consumers are unaffected. Do not promise full FHIR query for resources not exposed (e.g., DiagnosticReport, DocumentReference) - flag those as gaps. Publish an interface inventory and a conformance statement so consumers know what is and isn't available. The 90-day plan prioritizes the regulated reporting path first, then care-gap data, then optional FHIR query.
2. A consumer asks for FHIR resources the new system does not expose. How do you handle the gap without stalling go-live?
Read the worked answer
Document the gap explicitly in the conformance statement and negotiate a documented workaround with the consumer: either a v2 feed for that data element or a deferred capability with a dated roadmap. Do not build custom point-to-point extracts per consumer - that recreates the integration sprawl the HIE exists to prevent. Escalate to the HIE governance body to prioritize which missing resources are clinically necessary vs. nice-to-have, and get vendor commitment dates in writing. Communicate the gap to all 14 consumers so expectations are aligned and no one assumes data is silently absent.
3. What patient-matching risk does the hybrid model introduce, and how do you mitigate it before go-live?
Read the worked answer
Mixing a new system's identifiers with legacy v2 feeds raises the risk of duplicate or mis-merged records, especially at cutover when the same patient may appear under old and new MRNs. Mitigate with: a pre-go-live identity reconciliation pass, an enterprise master patient index with deterministic plus probabilistic matching thresholds, a documented merge/unmerge workflow with audit trail, and a monitoring dashboard for duplicate-rate and merge-error rate during the first 30 days. Include a rollback and correction procedure, and test with a synthetic cohort that includes edge cases (twins, similar names, missing DOB).