5.2 Data Integration Architectures

5.2 Data Integration Architectures

Quick Answer: Domain I B.2 treats integration as the hospital’s circulatory system. Know when a legacy HL7 v2 interface is the right tool, when a CDA document or FHIR API is, and why an interface engine plus MPI/EMPI is not optional plumbing.

Why integration is an infrastructure competency

Applications in Chapter 4 only create value if data moves: ADT to the lab, results back to the EHR, claims to the payer, a CCD to the next hospital, a FHIR query from a patient app. CPHIMS items punish people who treat “we bought FHIR” as a rip-and-replace of every feed. Task B.2 asks you to match the pattern to the job, keep identity straight, and know what the engine is for.

/study-guides/cphqFree exam prep with practice questions & AI tutor

Interfaces versus APIs

An interface in healthcare usually means a message-oriented, often asynchronous feed: a sending system emits a defined event (ADT^A04, ORU^R01), an engine transforms and routes it, the receiver files it. The unit of work is a message. Delivery is store-and-forward. The sender does not wait for a clinical decision.

An API (application programming interface), including FHIR RESTful APIs, is typically request/response: a client asks for Patient/123 or posts a ServiceRequest, the server answers now. The unit of work is a resource or transaction. Authorization is often OAuth 2.0 / SMART on FHIR rather than a static VPN plus a sending-facility ID.

Exam trap: FHIR does not replace every HL7 v2 feed. A 2,000-message-per-hour lab ORU stream is still a v2 job in most hospitals. FHIR is the right answer for app platforms, patient-access APIs, and many new HIE use cases. It is the wrong answer when the stem describes a mature ADT or results interface that already works and no query requirement exists. Saying “FHIR is newer, so retire v2 next quarter” is a project-risk answer, not an architecture answer.

HL7 v2, CDA, and FHIR — what each is for

HL7 Version 2 is the workhorse of inpatient integration. Segments (MSH, PID, PV1, ORC, OBR, OBX) carry events. Common message types you should recognize by purpose, not by field number:

• ADT — admit, discharge, transfer, registration, merge. This is how ancillary systems learn who is in which bed.
• ORM / OML — orders (lab, radiology, diet, depending on flavor).
• ORU — observational results (labs, some vitals).
• SIU — scheduling.
• DFT / BAR — charges and account events.
• MDM — document notifications.

v2 is event-centric. If no event fires, the downstream system stays stale. Custom Z-segments create local dialects that the next vendor cannot read. CPHIMS does not ask you to parse a field; it asks whether ADT is the right feed to update the pharmacy census, and whether a missing transfer message is why the blood bank still thinks the patient is on 4-West.

Clinical Document Architecture (CDA) and the Continuity of Care Document (CCD) are document standards. They package a clinical summary—problems, medications, allergies, results—as an XML document, often for transitions, referrals, or HIE. CDA is a snapshot, not a subscription. Sending a CCD does not keep the receiving EHR current after the next medication change. A 90-page CCD that no receiving clinician can find the potassium in is a usability failure even if the interface “succeeded.”

FHIR (Fast Healthcare Interoperability Resources) models healthcare as resources (Patient, Encounter, Observation, MedicationRequest, AllergyIntolerance) with standard REST operations, search, and—in later versions—subscriptions and bulk data ($export). US Core profiles constrain those resources for U.S. regulation. SMART on FHIR is how apps launch with scoped OAuth tokens so a third-party diabetes app does not receive the entire chart.

Use FHIR when the need is query, granular write-back, patient-facing apps, or standardized bulk extract. Use v2 when the need is high-volume, event-driven ancillary integration. Use CDA when the need is a human-and-machine readable summary at a point in time. A mature health system runs all three. That is not indecision; it is matching payload to purpose.

Interface engines and integration patterns

An interface engine (integration engine) is the broker: it receives, validates, transforms, filters, routes, queues, and logs messages among many systems. It is not “the interface.” Each connection is a channel with an acknowledgment contract (accept ACK versus application ACK). Green channels mean transport is alive; they do not mean the clinical content is correct.

Why the engine exists:

• Fan-out — one ADT feed becomes twenty (lab, radiology, dietary, RTLS, patient portal).
• Transformation — code-system mapping, field moves, Z-segment isolation.
• Queueing and replay — the lab can be down without losing results.
• Monitoring — aged queues are a patient-safety indicator, not an IT curiosity.

Common patterns:

1. Point-to-point — A talks only to B. Fine for a single ancillary; unmanageable at hospital scale.
2. Hub-and-spoke (engine-centric) — the default enterprise pattern.
3. Publish/subscribe — engine or event bus fans events to interested systems.
4. API gateway — fronts FHIR and other APIs with authorization, throttling, and audit.
5. ETL / ELT — scheduled extract into a warehouse or lake; not a substitute for real-time ADT.

Do not dual-write without a source of truth. Two systems both “owning” allergies is how you get conflicting lists. Pick a system of record and propagate. When a new FHIR app writes an allergy the EHR does not store, you have created a second chart.

MPI and EMPI: identity is the integration constraint

A Master Patient Index (MPI) is the organization’s authority for “is this the same person?” An Enterprise MPI (EMPI) extends that authority across facilities, affiliates, or an HIE.

Without a working MPI:

• ADT creates duplicate charts.
• Results file to the wrong encounter.
• FHIR Patient search returns two IDs for one human.
• Quality measures double-count.

Matching uses deterministic keys (MRN inside a facility) plus probabilistic traits (name, date of birth, sex, address, last four SSN, mobile). Merges and unmerges are clinical events: a bad merge mixes two patients’ allergies. CPHIMS items often hide an identity problem inside an “interface is down” story. If the engine is green but the lab is filing under a new MRN, the failure is MPI, not TCP.

HIE and multi-hospital systems need an EMPI or a carefully governed crosswalk. Local MRNs remain; the EMPI issues a surviving enterprise ID and links source identifiers. HIM owns many of the merge procedures; infrastructure owns the feeds and the match thresholds. Both must be at the table.

Scenarios and traps

• Trap: “FHIR replaces HL7.” It does not replace high-volume v2 ADT, orders, or results in most enterprises.
• Trap: “CDA is real-time interoperability.” It is a document snapshot.
• Trap: “The engine is optional if we use APIs.” You still need routing, authorization, transformation, and replay—often an API gateway plus an engine.
• Trap: “Interfaces fix identity.” Interfaces move whatever identifier they are given. MPI/EMPI quality is a separate control.
• Trap: “More messages mean better care.” Unfiltered ADT floods can crash a downstream pharmacy just as a missing ORU can hide a critical potassium.

When a stem says a new patient-access app must read medications and allergies with the patient’s authorization, think FHIR plus SMART, not a new v2 feed. When a stem says the blood bank never saw the transfer, think ADT plus engine queue, not a missing FHIR server.