Written by Technical Team | Last updated 13.02.2026 | 15 minute read
In hospitals where clinical risk, operational tempo, and regulatory pressure all coexist, integration is not a “nice-to-have”; it is part of the safety infrastructure. Dedalus Lorenzo Integration commonly sits at the centre of that infrastructure, connecting patient administration, departmental systems, diagnostics, scheduling, referrals, documents, and downstream repositories. HL7 v2 remains the workhorse protocol for much of this exchange because it is pragmatic, widely supported, and flexible enough to reflect real operational workflows.
This article focuses on HL7 v2 message flows from the moment data is generated in a source system to the point it becomes reliable, actionable information in a target system. The aim is to make the “in-between” visible: how messages move, where they can fail, how to design them for clarity, and how to support them in production without turning the interface estate into a fragile collection of one-off exceptions.
A useful way to think about Dedalus Lorenzo Integration is as a set of layered concerns: communication transport, message handling, business logic, data access, and persistence. When an HL7 v2 message arrives, you want predictable behaviour at each layer: the transport should be robust, the message handler should parse reliably, the business layer should apply the right rules, and the outcome should be recorded in a way that is traceable and supportable.
HL7 v2 is often described as “pipe and hat” messaging—segments separated by carriage returns, fields separated by |, components by ^, repeats by ~, and so on. That simplicity is deceptive. In a live hospital environment, you will encounter partial updates, multiple identifier domains, merged records, late results, corrections, and long-running episodes of care that span organisational boundaries. Dedalus Lorenzo Integration needs to manage not only the syntax but also the semantics: what the event really means, and whether it should update, create, merge, cancel, or reject.
At a high level, Lorenzo’s messaging model typically involves both inbound and outbound messaging paths. Inbound messages take external events—such as an admission, a demographic update, or a result—and drive them into Lorenzo’s business model. Outbound messages project Lorenzo events to external systems—such as orders to lab systems, demographic updates to departmental applications, or discharge notifications to community services. The hardest work is rarely “sending” or “receiving” as such; it is aligning event intent and data ownership across a complex estate.
When you design a dependable interface, you are designing for three audiences simultaneously: the source system, the target system, and the people who will support the integration at 03:00. The architecture has to help with all three by making message flow observable, enforcing consistent parsing rules, and keeping a clean separation between transport concerns and clinical/business rules.
A practical architectural breakdown you will often see in Dedalus Lorenzo Integration environments includes:
Because HL7 v2 is permissive, it is vital to be explicit about what your integration will accept and what it will reject. A “loosely validated” interface can appear stable during testing and then produce silent data quality issues in production, which are far harder to remediate than hard failures. The most robust Dedalus Lorenzo Integration estates tend to be those that treat validation as part of clinical safety rather than as an optional engineering nicety.
ADT is the heartbeat of most hospital integrations. Admissions, discharges, transfers, merges, and demographic updates are not merely administrative actions; they drive bed management, clinical documentation context, order-routing decisions, and patient safety alerts. In Dedalus Lorenzo Integration, ADT messages often arrive from a PAS (or a central patient index) and then fan out to multiple targets: departmental systems, document management, theatres, community care, and reporting platforms.
A typical ADT flow starts with an event in the source system—such as a patient being admitted through A&E. The PAS generates an HL7 v2 message where the MSH segment identifies the sending application and facility, the receiving application/facility, the message type (e.g., ADT^A01), and control identifiers that support tracking. The EVN segment captures the event timestamp and sometimes operator or event metadata. The patient’s identity and demographic details are carried in PID and PD1, and visit context is carried in PV1 and PV2. Optional segments—NK1 for next of kin, IN1 for insurance, AL1 for allergies—may appear depending on scope.
What matters most is not simply “the message arrives”, but what happens next. The receiving system must decide whether this event is a create, an update, a merge, or a state transition that affects multiple internal records. In hospitals, you will see patients with multiple identifiers (local MRN, NHS number, national identifiers, historic numbers), and you will see records that should be linked but are not yet linked at the time of the first message. A robust Dedalus Lorenzo Integration design treats identity resolution as a first-class concern rather than assuming that PID-3 always maps to one definitive record.
There is also the practical reality of out-of-order messaging. Many estates see demographic updates that arrive after an admission, or location updates that arrive before a ward move is visible in downstream systems. A well-designed integration tolerates these conditions by using consistent idempotency rules: if the same update is received twice, it should not create duplicates; if a message arrives late, it should still reconcile the patient state correctly; if a partial update arrives, it should not wipe out high-quality data already present unless the source is authoritative for that field.
Transfers and location updates can be deceptively tricky. A PV1-3 location might represent the patient’s current bed, but the meaning of “current” may vary by system workflow. Some PAS implementations generate interim movements; others send only confirmed movements. Downstream systems, such as lab or radiology, may rely on location for label printing, specimen routing, or portering. If Dedalus Lorenzo Integration forwards a bed move too early or too late, you can end up with operational friction or, worse, patient matching errors in departmental workflows.
Patient merges are a category of their own. In HL7 v2, merges are commonly represented using MRG segments alongside PID, indicating that one identifier should be merged into another. The integration must apply a clear policy: what is the survivorship record, what happens to historic encounters, and how are downstream systems informed. Some targets accept merge messages; others cannot and require alternative workflows such as “alias” identifiers or manual reconciliation. A high-quality Dedalus Lorenzo Integration approach does not treat merges as a rare exception; it explicitly designs for them, tests them, and operationalises them.
Outbound ADT messaging follows similar principles, but you must be disciplined about event generation. When Lorenzo becomes the source of truth for certain updates—such as verified demographics or encounter changes—outbound ADT should be driven by a defined set of triggers, not by ad hoc extracts. Targets need consistent message types, stable identifier strategy, and predictable timing. When you get that right, downstream systems become calmer: fewer “unknown patient” errors, fewer duplicates, fewer manual fixes.
Orders and results are where integration becomes directly clinical. An ADT mismatch can cause confusion; an order mismatch can cause delays; a results mismatch can cause harm. HL7 v2 ordering and results workflows are also more nuanced than they first appear, because they must support the lifecycle: placing, modifying, cancelling, collecting, reporting, correcting, and occasionally retracting.
The typical pattern is that Lorenzo (or a CPOE component integrated with Lorenzo) originates orders and sends them to a departmental system—laboratory, radiology, cardiology, endoscopy—using ORM messages. The order is not just a single line of text; it is a structured instruction with identifiers that must remain stable across subsequent changes. Control identifiers such as placer order number and filler order number become essential for matching later messages. The departmental system then returns results, commonly via ORU messages, using the same order identifiers to tie the result to the correct order and patient.
The first design decision is how you represent order intent. Is the departmental system receiving a “request” that it will schedule and fulfil, or is it receiving a “booking” already committed? Are clinical indications sent in free text, coded values, or both? Is specimen information included at order time, or only after collection? HL7 v2 can carry all of this, but the receiving system’s capabilities and local workflow determine what is practical. The most stable integrations tend to send a minimal, accurate, structured core, and then include optional enrichments only when they are truly consumed.
Order modifications are where many interfaces become brittle. In HL7 v2, modifications may be represented as new ORM messages with specific order control codes. If the source system changes priority, specimen requirements, clinical details, or requested time, the target must interpret whether this is a replace, an update-in-place, or a cancel-and-reorder pattern. Some departmental systems treat any change as a brand-new order; others can update selectively. A careful Dedalus Lorenzo Integration approach aligns these behaviours explicitly rather than assuming that “an ORM is an ORM”.
Results messaging adds further complexity because results are not always final the first time they appear. Preliminary, final, corrected, and appended results are common. OBX segments carry the result observations, often with associated coding systems, units, reference ranges, and abnormal flags. Some results are simple numerics; others are multi-line narratives. Some are panels with multiple OBX segments; others are structured reports. The key is consistency: targets (including Lorenzo) must interpret result status and chronology correctly so clinicians see the right thing at the right time.
A common production challenge is associating results with the correct encounter context. If the patient has multiple concurrent episodes, or if results arrive after discharge, you need a deterministic method of linking the result to the correct visit or order instance. PV1 context can help, but it can also mislead if the departmental system uses its own notion of encounter. Stable order identifiers are often the most reliable anchor, provided they are managed correctly from the outset.
To make ORM and ORU flows resilient, Dedalus Lorenzo Integration designs often include explicit handling for:
When these principles are applied consistently, you reduce the operational noise that otherwise shows up as “missing results”, “duplicate orders”, “wrong patient”, or “why did this cancel?” tickets. More importantly, you make the integration estate clinically dependable and less reliant on heroics from support teams.
HL7 v2 acknowledgements are often treated as a binary concern—ACK is good, NACK is bad. In practice, acknowledgements are a rich signal that should drive reliable delivery, error triage, and resilience. Dedalus Lorenzo Integration environments typically encounter both transport-level success (the message was delivered) and application-level success (the message was understood and applied). An ACK may mean either, depending on configuration and implementation.
A robust approach begins by defining what an ACK represents in your estate. If you use immediate acknowledgements, the receiver is confirming receipt and basic parsing. If you use application acknowledgements, the receiver is confirming that validation and business processing succeeded. Both models can be valid, but you must be deliberate because the operational implications differ. Immediate ACKs reduce sender latency but can hide downstream failures; application ACKs provide better assurance but can increase end-to-end time and require careful timeout management.
NACKs are not all equal. A NACK could represent a transient condition (such as a database lock, a temporary outage, a missing reference value that will be loaded shortly) or a permanent defect (such as an invalid identifier domain, an unknown message type, or a missing required field). Treating all NACKs as “retry until it works” is a recipe for message storms and duplicated problems. Treating all NACKs as “drop and move on” is a recipe for silent clinical data loss. The best estates use categorisation and routing: transient failures go to retry queues with backoff; permanent failures go to exception worklists with clear diagnostics.
Error handling becomes substantially easier if you invest in high-quality validation upfront. HL7 v2 messages should be validated for required segments and fields, supported code sets, identifier formats, and consistent event semantics. For example, if you require PID-3 to contain a specific assigning authority, fail fast when it does not. If you require PV1-19 for visit number in a given workflow, reject messages that omit it rather than trying to guess. The objective is not to be pedantic, but to prevent downstream ambiguity that can manifest as patient safety risk.
Another essential concept is idempotency. If a sender retries a message because it did not receive an ACK, the receiver should be able to recognise the duplicate and handle it safely. HL7 v2 provides message control IDs (MSH-10) and event timestamps, but not every system uses them consistently. Dedalus Lorenzo Integration implementations can improve idempotency by combining message identifiers, event type, patient identifiers, and encounter identifiers into a practical deduplication strategy. Without this, retry mechanisms can create duplicate updates, repeated orders, or repeated results.
Time and sequencing also matter. In synchronous request/response flows—such as QBP/RSP query messaging—the sender often blocks while waiting. If timeouts are too short, you generate unnecessary retries; if timeouts are too long, you degrade service responsiveness. If message sequencing is not controlled, you may process an update before a create, or a cancel before an order is known. A mature Dedalus Lorenzo Integration design typically incorporates ordering rules for certain message classes and uses controlled queues where sequencing is clinically meaningful.
When acknowledgement handling is done well, you get more than “delivery”; you get confidence. The integration estate becomes measurable: you can see backlog, error rates, partner reliability, and the difference between transient and permanent defects. That, in turn, allows sensible improvements—fixing mapping issues, aligning workflows, and reducing manual reconciliation—rather than endlessly firefighting symptoms.
Even the best message design fails if configuration is unmanaged. HL7 v2 interfaces are not simply “turned on”; they are defined through partner profiles, routing rules, transmission parameters, and local conventions. In Dedalus Lorenzo Integration, configuration typically reflects real-world agreements: which system is authoritative for demographics, which identifier domains are used, which message types are exchanged, and what constitutes a valid event.
A dependable configuration approach starts with clean separation. Transport parameters—hostnames, ports, protocol framing, TLS decisions, retry policies—should be isolated from mapping and business rules. Mapping should be version-controlled conceptually, even if the platform stores it in a database or configuration repository. Business rules should be explicit: which fields are updated, which are ignored, what happens on conflict, and how merges and cancellations are handled.
Testing needs to reflect clinical reality rather than idealised happy paths. Many interface test packs focus on “one admission, one discharge, one result” and then declare victory. Real flows include late registrations, amended demographics, multiple episodes, duplicate identifiers, corrections, and downtime recovery. The goal of testing is to prove that the integration behaves predictably under stress, ambiguity, and repetition, not just under clean inputs.
A production support model should be designed as deliberately as the interface itself. Interfaces are operational products: they need monitoring, clear escalation paths, and diagnostics that help teams resolve issues quickly without guesswork. The difference between a resilient estate and a fragile one often comes down to whether the integration gives you enough information to act: why a message failed, whether it was retried, what data was rejected, and what the business consequence is.
A practical checklist that many teams use when hardening Dedalus Lorenzo Integration interfaces includes:
Finally, treat documentation as part of the integration, not as an afterthought. A high-quality interface specification should describe not only the mapping but also the event semantics: what triggers each message, what it means, and what the receiver is expected to do. When incidents occur—and they will—clear documentation prevents well-intentioned fixes that create new inconsistencies. It also supports safer onboarding of new staff, reduces dependency on tribal knowledge, and helps teams make confident changes when clinical workflows evolve.
When configuration, testing, and support are approached as a single lifecycle, Dedalus Lorenzo Integration becomes more than a set of interfaces. It becomes a stable clinical messaging platform that can grow with the organisation, absorb change without chaos, and maintain the trust of the people who rely on it every day.
Is your team looking for help with Dedalus Lorenzo integration? Click the button below.
Get in touch