A healthcare AI platform had accurate diagnostic results but no way to get them back into the hospitals ordering them. The platform needed bidirectional HL7 messaging — receiving orders from EHR systems and delivering AI-generated results in a format each hospital would accept without rejection. This is production-grade message engineering with compliance at every level, diagnosis code handling for billing, delivery timing that prevents duplicates, and per-organization configuration that makes one codebase serve hospitals with different HL7 requirements.
ML LABS engineered this entire messaging layer. The companion article on EHR and FHIR integration covers the integration setup layer — authentication, FHIR, sandbox access. This article covers what happens after setup: building the actual messages.
The Problem
HL7 v2 messaging remains the dominant transport for clinical orders and results in hospital systems. Standard clinical coding systems provide observation identifiers for HL7 message segments. But the standard is a starting point. The actual message that any given EHR will accept depends on site-specific configuration, vendor-specific requirements, and organizational policies that vary across every hospital deployment.
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:#fffOrder Messages with Billing Code Flow
When the AI platform communicates order-level information back to the EHR, every message must match the originating order precisely so the EHR can file it correctly.
Order Tracking
Return messages must reference the original order identifiers exactly as the EHR assigned them. A mismatch means the result enters a limbo queue requiring manual intervention from the hospital's interface team.
Billing Code Flow
Diagnosis codes selected during clinician review carry direct billing implications — they must flow through the HL7 message so the EHR can associate them with the order for revenue cycle processing. ML LABS built a billing code selection UI that enables clinicians to attach ICD codes during review, with those codes propagating into the outbound message.
Each organization requires different code subsets, supports different levels of diagnostic complexity, and enforces different formatting rules. The system handles any diagnostic complexity without per-hospital code changes.
Delivering AI Results
The result message carries AI-generated clinical findings back to the EHR in a structured format the ordering clinician can review within their normal workflow.
Clinical Measurements and Coding
ML LABS built bidirectional HL7 messaging that delivers AI results with clinical measurements and billing codes that downstream systems depend on — heart rate, rhythm classification, RR interval, and axis measurements, each coded so the EHR files, displays, and trends them correctly.
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 and Provider Validation
Patient identifier and ordering provider fields are among the most strictly validated elements. They must match the EHR's internal formats exactly. ML LABS fixed both based on direct feedback from the EHR integration team — the specification documents which fields exist, but the EHR decides which values it will accept.
Delivery Timing and Duplicate Prevention
The platform supports multiple result delivery workflows — responses to EHR orders and platform-initiated results — including preliminary delivery through web upload paths.
ML LABS built delivery coordination that prevents duplicate sends across all pathways. Per-organization configuration controls which result types are enabled — some organizations want preliminary visibility while others require formal sign-off before any delivery.
Per-Organization Configuration
One codebase serving multiple hospitals means no hardcoded defaults. 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 organizational context. Validation rejects message construction when required per-org configuration is missing, preventing silent misconfiguration.
Boundary Condition
Bidirectional HL7 v2 messaging is the right approach when the target EHR uses HL7 v2 as its primary integration interface — the majority of US hospital systems. Some newer deployments support FHIR-based result delivery with different tradeoffs. In practice, most production healthcare AI deployments require both — FHIR for data access, HL7 v2 for order and result messaging.
First Steps
- Define the message catalog before writing code. List every order and result message type required per organization.
- Build per-org configuration from the start. Every value that could vary across hospitals should be configurable with loud validation on missing fields.
- Implement delivery coordination for every result pathway. Duplicate sends erode clinical trust faster than any other integration failure.
Practical Solution Pattern
Engineer the HL7 messaging layer as a per-organization configurable system with mandatory validation and delivery coordination that prevents duplicates across all result pathways. Externalize every site-specific value into per-org configuration from the first deployment. Build billing code flow with support for multiple diagnoses, and coordinate delivery triggers so no study sends duplicate results.
This works because the primary failure mode in HL7 integration is not message construction logic — it is site-specific field values that silently break when a second hospital has different requirements. Organizations that get the per-org architecture right add new hospital sites as configuration tasks rather than code changes. If the HL7 messaging requirements are defined and the constraint is production-quality engineering, AI Workflow Integration is the direct build path.
References
- Regenstrief Institute. LOINC and Other Standards. LOINC.