Healthcare integration is the engineering of the platform that moves data between EHRs, labs, payers, devices and analytics stores. The standards are fixed by others; the platform is what a team designs, owns and keeps running.
This guide covers the parts of that platform: listeners and the interface engine, the enterprise master patient index, terminology mapping, wearable and payer feeds, and the monitoring that tells you a feed has stopped. It also gives a decision list for choosing between an engine and custom code.
What is healthcare integration?
Building or replacing an integration platform?
Agnotic builds EHR, lab, payer and device integrations, from the interface engine to patient matching and feed monitoring.
Healthcare integration is the design and operation of the software layer that receives, transforms, matches and routes clinical and administrative data between systems. A typical platform combines transport listeners, an interface engine, an enterprise master patient index, a terminology service, a message archive and monitoring, so each new partner reuses the same parts.
The test of a platform is the second and third partner. If adding a new clinic means copying a channel and editing it by hand, the team owns a collection of interfaces, not a platform. If the new clinic plugs into shared identity, mapping and alerting, the work shrinks to the parts that are truly site-specific.
What sits inside an integration platform?
Seven components appear in almost every design. Their boundaries matter more than the products chosen for each one.
- Transport listeners: MLLP sockets for HL7 v2, HTTPS endpoints for FHIR and webhooks, and SFTP or AS2 drops for X12 batch files, each with its own certificates and network rules.
- Interface engine: routes, filters and transforms messages per channel. Products such as Mirth Connect by NextGen Healthcare, Rhapsody, Cloverleaf and Corepoint fill this role, as can cloud queues and functions.
- Raw archive: stores each inbound message exactly as received, before any transform, so a mapping bug can be fixed and the data replayed.
- Enterprise master patient index (EMPI): links the medical record numbers, member IDs and device accounts that refer to one person.
- Terminology service: translates local lab, charge and problem codes to LOINC, SNOMED CT, RxNorm and ICD-10-CM, and keeps the maps versioned.
- Canonical store and APIs: a FHIR R4 repository or data model that downstream apps and analytics read from, rather than reading each partner feed directly.
- Monitoring: per-channel volume, acknowledgment, latency and error signals with alerts routed to a named owner.
Which standards does the platform have to speak?
A platform rarely gets to pick one standard. It has to accept what each partner sends and still produce one consistent record.
- X12 transactions: under the HIPAA Administrative Simplification rules at 45 CFR Part 162, CMS lists X12 standards for eligibility (270/271), claim status (276/277), prior authorization (278), claims (837) and remittance (835), and NCPDP standards for retail pharmacy.
- HL7 v2 acknowledgments: HL7 Version 2 defines the ACK message, with MSA-1 codes AA, AE and AR in original mode, which the sending engine uses to decide whether to resend.
- Patient matching in FHIR: FHIR R4 defines a Patient $match operation that returns candidate records with a match score, which an EMPI can expose to other systems.
- Code translation in FHIR: FHIR R4 defines ConceptMap and a $translate operation for mapping a code from one system to another.
- Audit controls: the HIPAA Security Rule at 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems that contain or use ePHI.
Engine or custom code: how to choose
The choice depends on the mix of feeds and on who will run the platform after go-live. Use this decision list before buying or building.
- Mostly HL7 v2 feeds from hospitals: an interface engine pays for itself, because MLLP handling, ACKs, filtering and replay come built in.
- Mostly FHIR APIs and webhooks: cloud queues and small services are often simpler, with a FHIR server as the canonical store.
- Many X12 trading partners: a clearinghouse or an EDI translator usually beats hand-written X12 parsing, since companion guides differ by payer.
- Small in-house team: pick the option your on-call staff can debug at night; an engine with a familiar console can be the safer choice.
- Strict cost or licence limits: check current licence terms for any engine before committing, and price the support model, not only the software.
- Mixed estate: keep the engine for v2 and batch, put FHIR traffic through services, and share one EMPI, terminology service and alerting layer across both.
Whichever route wins, keep channel logic in source control with automated tests. A channel edited only in a production console cannot be reviewed, rolled back or rebuilt after a server failure, and that risk grows with every partner added to the platform.
How should the EMPI handle matching and merges?
The EMPI should link records only when the evidence is strong and send everything else to a person. Deterministic rules match on exact identifiers; probabilistic scoring weighs name, birth date, sex, address, phone and identifiers together.
Identifiers only mean something with their issuer attached. An HL7 v2 PID-3 value carries an assigning authority, and the EMPI should store the pair, because MRN 12345 at one hospital and MRN 12345 at another are different people. In FHIR the same pair becomes Patient.identifier with a system URI per issuer.
Set two thresholds: one above which records link automatically, and one below which they stay separate. Anything between them goes to a data steward queue with both records shown side by side. Matching on name and birth date alone is a known failure point, because twins, family members and common names collide.
Merges arrive from source systems too. An HL7 v2 A40 message tells the platform that one patient identifier has been merged into another, and an A08 carries updated demographics. The EMPI has to apply both, record who changed what, and support an unmerge when a hospital reverses a mistake. In FHIR, Patient.link records the replaced and replacing records so downstream readers can follow the change.
How do you map terminology without losing the source?
Keep the original code and add the standard one beside it. A FHIR CodeableConcept can carry several codings, so the lab's local test code and the LOINC code travel together and nothing is lost if a map later proves wrong.
- Version every map: record which map version produced each mapped value, so a correction can be traced and replayed.
- Queue unmapped codes: route a code with no map to a work queue instead of dropping it or passing it through as free text.
- Normalize units: convert result units to UCUM where the receiving profile expects it, and keep the source unit for audit.
- Map per site: two clinics on the same EHR product can still use different local codes, so maps belong to a source, not to a product.
- Test with real samples: run a month of de-identified production messages through a map change before it ships.
Which signals show a feed is failing?
Silence is the signal teams most often miss. A feed that stops sending raises no errors, so the platform has to alert on missing traffic as well as bad traffic.
- Volume floor: alert when a channel's hourly count drops below its normal range for that hour and day.
- Message age: alert when the oldest unprocessed message in a queue passes a set age.
- Negative acknowledgments: track AE and AR rates per sender; a spike usually means a mapping or validation change.
- Expiring credentials: alert weeks ahead of TLS certificate, VPN key and OAuth client secret expiry.
- Unmapped code rate: a rise means a partner added new local codes.
- Steward backlog: a growing EMPI review queue means duplicate charts are being created downstream.
What the replay runbook should cover
Alerts only help if the on-call engineer knows what to do next. Write the replay procedure before go-live and rehearse it with each partner once.
- 1. Contain: pause the outbound channel so a bad map does not keep writing wrong values downstream.
- 2. Scope: use the raw archive to list every message received since the fault began, by control ID and timestamp.
- 3. Fix: correct the map or filter, bump its version, and run the affected messages through a test channel first.
- 4. Replay: resend from the archive in original order, relying on idempotent writes so repeated messages update rather than duplicate.
- 5. Confirm: compare counts with the sender, tell downstream owners which records changed, and record the incident.
Vertical integration and wearable feeds
Vertical integration in healthcare joins payers, clinics, management services organizations and pharmacies under one owner. The platform then has to link member IDs from claims to medical record numbers from each acquired clinic, which puts the EMPI at the center of every report on cost and care gaps.
Claims and clinical data answer different questions. Claims show care delivered anywhere a member was billed; the EHR holds lab values, vitals and findings that never reach a claim. A combined model keeps both, with the source of each fact recorded.
Wearable integration in healthcare needs its own path. High-frequency readings from cuffs, glucose monitors and phone health stores belong in a time-series store, not an EHR flowsheet. The platform normalizes units and codes, applies the clinical team's rules, and writes only summaries or out-of-range FHIR Observations into the chart.
How Agnotic can help
An integration platform is only as good as its weakest shared part, so Agnotic Technologies starts with the pieces every feed reuses: the raw archive, the EMPI, the terminology maps and the alerting. Agnotic then builds the channels for each EHR, lab, payer and device source on top of them, for the client and to the client's runbooks.
Design your integration platform with Agnotic
See Agnotic's EHR integration services, or read more in the Healthcare Data Engineering hub.
Related reading on Agnotic
Compare interface engines, handle HL7 errors and replay, and read the rules side of interoperability.
