HL7 and healthcare interface engineering for MedTech, built on an honest reading of a standard that permits local variation by design.
Optional fields, locally defined code sets and Z-segments are not abuses of HL7 v2. They are features of it, included so that two organizations could agree a working interface without waiting for the standard to accommodate them. That flexibility is why the standard succeeded and why every interface is a bilateral agreement rather than a product capability. A device company integrating at scale is not implementing a protocol, it is maintaining a portfolio of negotiated contracts that drift independently.
Device integration projects are scoped around results, because results are the thing the product produces. The feed that determines whether those results land correctly is ADT: admissions, discharges, transfers, patient merges, account changes, cancellations and corrections. When a patient is merged, moved between units or has an encounter corrected, every device association built on the old identifiers becomes wrong, silently, and the results already sent sit against a record that no longer represents the patient.
Underneath that is the structural issue: because the standard permits local variation, no two of your interfaces are the same and none of them is a product.
Every interface is a bilateral agreement
Optional fields and local extensions are permitted by design, so the specification differs at every site.
ADT determines whether anything else works
Merges, transfers and corrections invalidate device associations built on earlier identifiers.
You talk to their engine, not their EHR
Rhapsody, Cloverleaf, Mirth or equivalent, operated by their team on their schedule.
Silent failure is the default
A message accepted and discarded downstream produces no error anywhere you can see.
Orders and results do not always correlate
A result can arrive without a valid order reference or with placer and filler identifiers that do not match what the receiving system expects.
Z-segments carry the content that matters
Device-specific detail ends up in local extensions that no receiving system interprets consistently.
There are three levels of completion and they are routinely treated as one. Transport acceptance means the endpoint received it. Application processing means the receiving system handled it. Clinical workflow completion means it reached the right context and a clinician can see it. A transport ACK is not an application ACK, and an application ACK is not clinical completion.
Ask what happens to your data when a patient is merged. Two records are combined, one medical record number survives, and every result your device sent against the retired identifier is now attached to a record that may or may not have been carried across. Most device integrations have no defined behaviour for this, because the project scoped results and treated ADT as a reference feed. Establishing what your system does on a merge, a transfer and an account correction is a short exercise that reveals whether your patient context is maintained or merely initialized.
Since every interface is a separate agreement, the only architecture that scales keeps the negotiation in a thin per-customer layer and the product logic in a canonical model that knows nothing about any specific site. That split is cheap at the second interface and progressively more expensive at every one after it.
Step 1
Separate the canonical model from the site-specific mapping before the second interface, since that is the whole architecture.
Step 2
Take the ADT feed seriously, including merges, transfers, cancellations and corrections rather than admissions alone.
Step 3
Define patient context maintenance, so an association is updated by ADT rather than fixed at the moment it was made.
Step 4
Correlate results to orders through placer and filler identifiers, since that is the cleanest association available and the identifiers have to match what the receiver expects.
Step 5
Select message types against the actual workflow, since ADT, ORM, OML and ORU serve different purposes and the receiving specification decides which applies.
Step 6
Treat acknowledgments by level, because transport acceptance is not application acceptance.
Step 7
Keep the site specification in configuration, so a new customer is a mapping file rather than a release.
Step 8
Design the error path first, since silent discard is the default failure and somebody has to be told.
Step 9
Monitor per interface rather than in aggregate, as one broken site is invisible in a total.
Step 10
Version the interface specification with the customer, so a change on either side is a known event.
Step 11
Test against their engine configuration rather than a reference implementation.
A message accepted and then discarded produces no error anywhere you can see. An interface engine can accept a message, route it, and have the receiving application drop it because a required field is empty, a code is unrecognized or a filter excluded it. Your system recorded a successful send. Their engine recorded a successful route. Nobody recorded that the content never arrived in the chart. That gap between transport success and clinical arrival is where device interfaces fail most often, and the only reliable detection is reconciling what you sent against what the receiving system actually holds.
Imaging and the order-to-study correlation are covered on our HL7 v2 and DICOM Integration page, and the per-customer economics on our EHR and Clinical System Integration page. These are the HL7 messaging capabilities.
Receive and Maintain
ADT Feed Engineering
Admissions, transfers, discharges, merges, account changes and corrections processed as events that update context rather than as reference data.
Patient Context Maintenance
Device associations kept current as patients move and records change, rather than fixed when the association was first made.
Order Ingestion
Orders and worklists consumed where available, which is the cleanest basis for associating a result with a patient.
Master File and Code Set Handling
Local catalogues loaded rather than assumed, since every site names and numbers its own.
Map and Send
Canonical Model Design
An internal representation independent of any site specification, so a new customer touches mapping rather than product logic.
Per-Site Mapping
Segment, field, code and Z-segment mapping held in configuration with the exactness of each mapping recorded.
Result and Observation Messaging
Results, observations and status, with corrections and amendments handled as distinct events rather than as repeats.
MLLP and Transport Engineering
Connection handling, framing, acknowledgments, retries and reconnection, which is where interfaces fail operationally.
Prove and Sustain
Acknowledgment Handling by Level
Transport, technical and application acknowledgment treated as different facts rather than as one success.
Error and Exception Queues
Failures routed to somebody who can act, with context attached, rather than written to a log nobody reads.
Per-Interface Monitoring and Reconciliation
Volume, latency, rejections and sent-against-received counts per site, since aggregate figures conceal a broken one.
Interface Lifecycle Management
Specification versioning with each customer, upgrade tracking and regression testing against their configuration.
The third column is what each flow depends on from the ADT feed, which is the point of the table. Results and observations get the attention and none of them work correctly without current patient context underneath.
| Flow | What moves | What it needs from ADT |
|---|---|---|
| Diagnostic results | A result against an order | Encounter validity, since an order on a closed encounter routes badly |
| Continuous monitoring | Observations from a bedside device | Transfers above all, because the patient moves and the device may not |
| Point-of-care testing | A result produced at the bedside | Current admissions, since the association is made at the moment of testing |
| Laboratory interfacing | Specimens, orders and results | Merges, as a merged record strands prior results against a retired identifier |
| Clinical documentation | Device-generated content into the record | Encounter association, which determines where the content is filed |
The right result in the wrong encounter is still a failed integration. Correct patient identity does not establish correct encounter or order association, and a value filed against the wrong visit sits outside the context a clinician is working in.
The standard defines a frame and each site fills it differently, which is permitted. The third column is where to absorb the difference, and anything requiring code is a reason your interface portfolio grows faster than your team.
| What varies | How it varies | Absorb it in |
|---|---|---|
| Message version and structure | Different HL7 versions, optional segments included or omitted | Configuration, with several versions supported concurrently |
| Field usage | The same field carrying different content by local convention | A per-site mapping, never an assumption in product logic |
| Z-segments and extensions | Locally defined segments carrying site-specific content | A mapping layer, with unmapped content flagged rather than dropped |
| Code sets and catalogues | Local codes for orders, units, locations and results | Loaded tables per site, with exactness of each mapping recorded |
| Acknowledgment behaviour | Original, enhanced or none, with different semantics per engine | Explicit per-site configuration rather than one assumption |
| Engine and routing rules | Different middleware with different filters and transformations | An adapter boundary, since their engine is part of the contract |
Their integration engine is part of your interface, and you do not control it. Messages pass through middleware configured by the health system: filters, transformations, routing rules and sometimes content changes applied before the receiving application sees anything. A field you populated may be stripped, a code may be translated, a message may be routed to a destination you did not anticipate. When something arrives wrong, the engine configuration is as likely a cause as your mapping, and resolving it needs their interface team rather than yours. Designing on the assumption that the engine is a transparent pipe produces diagnoses that waste everybody time.
An HL7 interface is a standing connection moving identified patient information between two organizations, every day, usually without anybody looking at it. That makes it different from an application somebody logs into: there is no session, no user, and frequently no review of what is flowing. The obligations attach to the flow rather than to an interaction, and they persist for as long as the interface runs, including after the commercial relationship that justified it has ended.
Data protection
- Patient data in transit protected to the obligations your counsel defines, including HIPAA where applicable
- Minimum necessary applied to what the interface carries, since an interface sending more than needed expands exposure permanently
- Message archives treated as a patient data store with its own retention and access controls
- Decommissioning handled, since an interface left running after a contract ends is an unauthorized ongoing transfer
Clinical safety
- Patient context errors treated as clinical events rather than data defects, particularly those caused by transfers and merges
- Correction and amendment semantics designed so an updated result replaces rather than duplicates
- Delivery confirmed to the point a clinician can see it rather than to the point a message was acknowledged
- Error queues owned by a named person with a clearance expectation rather than accumulating
Regulatory
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304, IEC 81001-5-1 and ISO 13485
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
- Interface change assessed against device software scope where the interface participates in device function
- Per-site configuration treated as controlled where it affects clinical content
Operations
- Monitoring per interface, since one broken connection is invisible in an aggregate figure
- A named contact at each customer, because their engine change is the commonest cause of a break
- Message copies retained for investigation, within the retention your counsel approves
- Access to interface logs controlled, as they contain the same patient data the interface carries
Interface monitoring reports connection state, message volume and acknowledgment rate, all of which can look healthy while messages are being accepted and discarded downstream. The only check that detects that is a periodic comparison between what you transmitted and what the receiving system actually contains, per interface, per period. It is simple, it requires cooperation from the customer, and it finds the failures nothing else does.
Sent against received reconciliation
On a schedule, since partial loss is invisible from either side alone.
Acknowledgment type and rate
Distinguishing transport from application acceptance, which are different facts.
Error queue depth and age
Because a queue nobody clears is results that never reached a chart.
Unmatched patients and orders
The association failures, which accumulate quietly and matter clinically.
ADT event processing
Particularly merges and transfers, since a missed one corrupts context silently.
Volume against expectation per site
A drop is a break, and a drop at one site is invisible in a total.
Interface programmes are usually reported as connections live and messages flowing. The outcomes that matter are whether patient context stays correct, whether anybody would notice a partial loss, and whether the next interface is cheaper than the last.
| Category | What we measure | Why it matters |
|---|---|---|
| Follow one result end to end | Which message type, whether it is structurally valid, which patient and how identity was established, which encounter, whether order identifiers correlate, whether code, units and status are right, what acknowledgment came back, whether the receiving application processed it, whether it reached the intended workflow, and what happens when processing fails | If these cannot be answered the interface is transmitting rather than completing |
| ADT event handling | Merges, transfers and corrections processed as association updates | The failure mode with clinical consequence and no error message |
| Reconciliation variance | Sent against received per interface per period | The only check that detects accepted-and-discarded messages |
| Unmatched queue | Patient and order association failures, and whether they are cleared | Where results that never reached a chart accumulate |
| Marginal interface cost | Effort for the next site against the last | Determines whether the portfolio is maintainable as it grows |
| Break detection source | Breaks found by monitoring against breaks reported by a clinician | Their engine change is the commonest cause and you want to call them |
We will review how your interfaces handle transfers, merges and corrections, test whether sent and received counts reconcile, examine the unmatched queue and who owns it, compare the marginal cost of recent interfaces, and check how message archives are protected.
CaliberFocus is a MedTech engineering partner delivering HL7 and healthcare interface integration for device companies connecting to hospital systems at scale. From ADT feed engineering and patient context maintenance to per-site mapping, acknowledgment handling and reconciliation, we build interfaces that keep results attached to the right patient and make every new site cheaper than the last.
- ADT merges, transfers and corrections handled as association events
- One canonical model with per-site mapping held in configuration
- Acknowledgments treated by level, with errors routed to a named owner
- Sent-against-received reconciliation per interface
Security & Compliance
