There is a thing every healthcare integration team knows and no specification contains: the accepted message. It is not the message the standard describes. It is the narrow subset of that standard, populated in the exact way one hospital's interface engine expects, that a given EHR will take without complaint. Conformance and compatibility are different properties, and only one of them gets a result in front of the clinician who ordered it.
The gap is structural rather than cosmetic. A peer-reviewed analysis of the standard HL7 v2.5.1 ORU result message counted 4,132 data elements across its segments, fields, components, and subcomponents, with 85% of those elements designated optional (analysis of HL7 v2 optionality (JAMIA, 2009)). Interoperating partners must consider each optional element, agree on which subset they will exchange, and implement that subset identically. Two hospitals starting from the same specification end up with messages that look superficially similar and still reject each other's payloads on details like which fields are populated, how identifiers are formatted, and which code systems are bound to which segments.
HeartSciences had accurate AI diagnostic results and no way to get them back into the hospitals ordering them. ML LABS engineered the entire bidirectional HL7 messaging layer of their AI-ECG platform's cloud backend: receiving orders from EHR systems, delivering AI-generated results in a format each hospital accepts, carrying the diagnosis codes that decide whether the study gets paid for, coordinating delivery so no study sends twice, and doing all of it from one codebase that never forks per site. The companion piece on EHR and FHIR integration covers the setup layer — authentication, FHIR, sandbox access. This one is about what happens after setup, when the messages themselves have to be right.
graph LR
A1["EHR Order<br/>Message"] --> B1["Order Tracking +<br/>Billing Code Flow"]
B1 --> C1["AI Inference +<br/>Clinical Review"]
C1 --> D1["Per-Org Result<br/>Message Construction"]
D1 --> E1["Delivery Coordination<br/>+ Duplicate Prevention"]
E1 --> F1["EHR Files<br/>Result"]
style A1 fill:#1a1a2e,stroke:#0f3460,color:#fff
style B1 fill:#1a1a2e,stroke:#ffd700,color:#fff
style C1 fill:#1a1a2e,stroke:#ffd700,color:#fff
style D1 fill:#1a1a2e,stroke:#e94560,color:#fff
style E1 fill:#1a1a2e,stroke:#e94560,color:#fff
style F1 fill:#1a1a2e,stroke:#16c79a,color:#fffOrders, Results, Billing Codes
A return message must reference the original order identifiers exactly as the EHR assigned them. A mismatch does not bounce — it lands the result in a limbo queue that a hospital interface team has to clear by hand, and the ordering clinician waits without knowing what for.
The result message itself carries AI-generated clinical findings back into the clinician's normal workflow: heart rate, rhythm classification, RR interval, and axis measurements, each coded so the receiving system files, displays, and trends them correctly. Riding alongside them are the diagnosis codes selected during clinician review, which have direct billing consequences — ML LABS built the billing code selection interface that lets a clinician attach ICD codes during review, and those codes propagate into the outbound message so the EHR can associate them with the order for revenue cycle processing. Incorrect coding on the way out is a leading cause of claim denial under correct-coding validation rules (CMS), which is why the code path is part of the messaging layer rather than a reporting afterthought. Each organization requires different code subsets, supports different levels of diagnostic complexity, and enforces different formatting rules, and the system absorbs all of that without per-hospital code changes.
Compliance at the message level is where HL7 integration moves from "works in the sandbox" to "works in production." The specification tells you which fields exist. The EHR tells you which values it will accept — and that answer changes per site.
Patient identifier and ordering provider fields are the most strictly validated elements in the message, and both must match the receiving system's internal formats exactly. ML LABS corrected both against direct feedback from a major EHR vendor's integration team — the specification documents which fields exist; the EHR decides which values it will accept.
Rejection Signals To Instrument
Rejection failures in HL7 messaging do not announce themselves. The EHR returns an application acknowledgment with AE (application error) or AR (application reject) status in MSA-1, the result message lands in an interface engine error queue, and the ordering clinician sees nothing arrive. The signals worth instrumenting upstream are the same ones the hospital interface team reads when triaging: NACK status codes in returned MSA segments, ERR segment field-level error locations, and counts of messages stuck past expected processing time in the EHR's inbound queue. Without that telemetry, the AI platform learns about rejected results only when a hospital opens a support ticket, which is days after the clinical opportunity has passed.
The rejection causes worth designing against are concrete and unglamorous. Patient identifier formats that include or omit leading zeros. Ordering provider references that point to a retired NPI. Observation identifiers using a LOINC code the EHR has not mapped to a local result type — the standard clinical coding system (LOINC) provides the observation identifiers, and the mapping to a local result type is the hospital's to make. Order control codes that signal a workflow the receiving system does not support. Each one is a single field, and each one looks like a configuration footnote during setup. Each one also maps cleanly to per-organization configuration once the field-level error returns surface it, which is the entire argument for externalizing site-specific values before the second hospital exists.
One Codebase, Many Dialects
One codebase serving many hospitals means no hardcoded defaults, anywhere. ML LABS implemented per-organization HL7 configuration that externalizes every site-specific value: facility identifiers, application names, patient identifier formats, provider reference schemes, diagnosis code subsets, and authentication bindings. Each hospital's integration authenticates with its own credentials bound to its own organizational context. Validation refuses to construct a message when required per-org configuration is missing, so a missing mapping fails loudly at build time instead of arriving at a hospital as a malformed payload.
Delivery coordination is the other half of the per-org surface. The platform supports several result-delivery workflows — responses to EHR orders, platform-initiated results, preliminary delivery through web upload paths — and per-organization configuration controls which of them are enabled, because some organizations want preliminary visibility while others require formal sign-off before anything is delivered at all. The coordination layer prevents duplicate sends across every pathway, which matters more than its size suggests: a duplicate result in a patient chart is not a nuisance, it is two answers where the clinician expected one.
A systematic scoping review of FHIR-based implementations (JMIR Medical Informatics, 2024) names hard-coded mappings that drift as one of five recurring failure categories in health-data integration. Per-organization configuration is the structural answer to that finding: the mapping cannot drift out of sync with the code if it was never in the code.
Where HL7 Is The Wrong Protocol
Bidirectional HL7 v2 is the right layer when the target EHR uses HL7 v2 as its primary integration interface, which describes the majority of US hospital systems. Newer deployments support FHIR-based result delivery with different tradeoffs, and the FHIR R4 specification (HL7, 2024) plus the SMART App Launch framework (HL7 FHIR, 2024) give a cleaner substrate for data access and launch context than v2 messaging ever will.
The two are not competitors. On this platform the protocols split by job: FHIR for data access and launch context, HL7 v2 for the order and result workflow. A team that treats the decision as a technology preference rather than a workflow question can implement the wrong one first and discover that the ordering clinician's workflow was never reachable from it — which is the sort of thing an EHR integration simulator is built to surface before a sandbox window is spent finding it.
First Steps
- Write the message catalog before the code. Every order and result message type, per organization, with the fields each site populates. The catalog is the spec; the standard is only its vocabulary.
- Make every site-specific value configuration. If it varies across hospitals, it does not belong in the codebase — and validation should refuse to build a message when a required mapping is absent.
- Instrument the acknowledgment path first. MSA status codes and ERR segment locations, captured and counted from the first integration. A rejected message you cannot see is a clinical result that silently never arrived.
Externalize Every Site-Specific Value
The primary failure mode in HL7 integration is not message construction logic. It is the set of site-specific field values that break the moment a second hospital has different requirements — and the architecture either anticipated that or it did not. Organizations that get the per-org layer right add a hospital as a configuration task. Organizations that did not add a hospital as a release.
If the messaging requirements are understood and the real constraint is production-quality engineering across two systems that must agree — an AI platform on one side, a hospital's interface engine on the other, and a clinical workflow that has to survive the crossing — that is an AI system integration build, and it includes its first 60 days of Operate, because a live HL7 interface tells you which of your assumptions the receiving system does not share. Get the accepted message right and the AI result stops being a diagnostic sitting in a queue and becomes what it was meant to be: an answer, in the chart, where the person who ordered it is looking.
References
- Regenstrief Institute. LOINC and Other Standards. LOINC.
- Sujansky WV, Overhage JM, Chang S, Frohlich J, Faus SA. The Development of a Highly Constrained Health Level 7 Implementation Guide to Facilitate Electronic Laboratory Reporting to Ambulatory Electronic Health Record Systems. Journal of the American Medical Informatics Association, 2009.
- HL7 International. FHIR R4 Specification. HL7 International, 2024.
- HL7 International. SMART App Launch Implementation Guide. HL7 FHIR, 2024.
- Tabari, P., Costagliola, G., De Rosa, M., Boeker, M. State-of-the-Art FHIR-Based Data Model and Structure Implementations: Systematic Scoping Review. JMIR Medical Informatics, 2024.
- CMS. National Correct Coding Initiative (NCCI). Centers for Medicare & Medicaid Services.
