Written by Technical Team | Last updated 10.04.2026 | 13 minute read
Health Level Seven (HL7) is an internationally recognised set of standards for the exchange of electronic health information. Within the UK, HL7 underpins interoperability between clinical systems, enabling information such as demographics, appointments, referrals, admissions and results to move securely and accurately between applications. System C’s CareFlow EPR supports HL7 version 2, with specific adoption of HL7 UK A.2 standards and certain enhancements from HL7 2.5. This means digital health innovators must be able to handle HL7 structures to ensure their solutions integrate seamlessly with CareFlow and Trust Integration Engines.
At a practical level, HL7 matters because most NHS provider organisations still depend on a mixed application landscape. A Trust may have a core EPR, specialist departmental systems, patient portals, radiology, pathology, ePMA, document management, and shared care integrations all running in parallel. System C states that CareFlow EPR includes its own integration engine and a standard HL7 message set for sharing data with departmental systems such as LIMS, PACS and patient portals, while also offering FHIR-based APIs for wider interoperability. For innovators, that means HL7 is not a legacy side issue; it is often the operational language that keeps day-to-day clinical workflows moving, even as API-led models continue to grow.
System C’s CareFlow uses the CareFlow Integration Engine (CIE) to manage message exchange with a Trust’s Integration Engine. Connectivity is achieved using TCP/IP sockets with HL7 messages transported via the Minimal Lower Layer Protocol (MLLP). The integration process is designed to ensure data consistency, guaranteed delivery and strict sequencing, which are critical in a healthcare environment where the integrity of patient records is paramount. Messages are queued, persisted, and delivered in a First-In-First-Out sequence, with acknowledgements (ACKs) ensuring confirmation at every stage.
This architecture matters because it separates application logic from routing, transformation and resilience. In most Trust environments, the TIE acts as the broker between CareFlow and many downstream systems, translating message structures, enforcing local business rules, and monitoring delivery. System C’s published implementation material also notes that onboarding involves defining the current integration architecture, issuing message specifications with examples, and carrying out a detailed mapping and gap analysis to identify missing content or local variations before development starts. That is an important point for innovators: successful System C integration is rarely just a socket connection and a sample message. It is an architecture exercise, a data-design exercise and an operational assurance exercise all at once.
Successful System C CareFlow integration depends on more than just sending HL7 messages. Digital health innovators must design for reliable HL7 messaging workflows, including ACK handling, message sequencing, data mapping, and error recovery across Trust Integration Engines (TIEs). Ensuring compliance with HL7 v2 standards, NHS interoperability requirements, and CareFlow-specific message structures is critical for delivering safe, scalable, and future-proof EPR integrations. Organisations that prioritise robust HL7 integration architecture from the outset are far more likely to achieve seamless data exchange, improved patient flow, and long-term interoperability within NHS digital ecosystems.
To integrate reliably with CareFlow, innovators need to understand not just the trigger events but also the way an HL7 message is packaged and acknowledged. MLLP provides the framing for HL7 v2 traffic over TCP/IP by marking the start and end of each message so the receiving system can separate one message from the next. HL7 then relies on the MSH segment for routing and control metadata, including message type, event, version, sender, receiver and control ID, while ACK messages confirm whether the receiving application has accepted or rejected the transaction. HL7’s acknowledgement model is especially important in healthcare because a technically delivered message is not always the same thing as a business-accepted update.
In real deployments, this means innovators must design for more than happy-path processing. They need to decide how duplicate message control IDs are handled, what happens when an ACK is delayed, whether retries are idempotent, how sequence integrity is maintained after outages, and how exceptions are surfaced to support teams. A robust integration does not simply send ADT or ORU traffic; it provides traceability from source trigger through transformation, delivery, acknowledgement, error handling and replay where necessary.
A wide range of HL7 message types are used within CareFlow EPR integration, each designed to manage specific aspects of patient care and operational workflow. For innovators planning integrations, understanding the most common message types is essential.
The MPI lies at the heart of CareFlow integration, ensuring that every patient record is uniquely identifiable across systems. Typical messages include ADT^A28 for creating new patients, ADT^A31 for updating demographics, and ADT^A40 for merging duplicate records. Outbound messages keep third-party systems up to date, while inbound MPI feeds ensure CareFlow itself receives accurate patient identifiers.
For innovators, MPI integration is usually where the hardest data quality questions emerge. Different systems may use different local identifiers, NHS numbers may be missing or unverified, and merges can have major downstream consequences. If a receiving system mishandles an A40 merge, duplicate charts, duplicate alerts or misfiled documents can follow. This is why demographic matching logic, identifier governance and replay procedures should be agreed early in the project rather than left until testing.
Inpatient workflows rely heavily on ADT messages. These include ADT^A01 for admissions, ADT^A02 for transfers, and ADT^A03 for discharges. There are also variations to handle updates, cancellations and home leave scenarios. By processing these messages, CareFlow and its connected systems maintain a real-time view of patient movement across wards and departments.
These messages often drive much more than bed state. They can trigger tasks, update whiteboards, open order pathways, change clinician assignment, drive patient flow dashboards and update downstream communication tools. System C describes CareFlow as supporting real-time updates, patient flow, task orchestration and mobile care coordination, so ADT quality directly affects both operational efficiency and clinical situational awareness.
Effective waiting list management is central to patient flow. CareFlow uses ADT^A05 messages for pre-admissions, ADT^A08 for updates, and ADT^A38 for cancellations or deletions. Outpatient care is managed using a similar structure, with referral messages such as REF^I12 to initiate referrals, REF^I13 to modify, and REF^I14 to cancel or delete referrals. This ensures referrals, appointments, and attendances are accurately tracked across the system.
A useful implementation principle here is to distinguish clearly between status changes, schedule changes and true cancellations. Trusts often have local rules around clinic templates, slot ownership, referral triage and waiting list priorities. An interface that treats all changes as a simple overwrite can undermine operational reporting. Innovators should therefore confirm which fields are authoritative, which updates are incremental, and how historical state is preserved for audit and RTT-sensitive workflows.
Clinical diagnostics and laboratory workflows are supported through HL7 order and result messaging. The OMG^O19 and OML^O33 message types handle clinical and laboratory orders respectively, while ORU^R01 and OUL^R22 manage results delivery. These ensure clinicians have timely access to patient test orders, specimen tracking, and diagnostic results, integrated directly into the CareFlow EPR.
System C’s published CareFlow material confirms that Order Communications and Results Reporting is bi-directional, using HL7 messaging to send order requests and receive scheduling and status updates from departmental systems including radiology and pathology. That bi-directional pattern is essential because order messaging is not just about sending a request; it is also about lifecycle visibility. Innovators need to decide how they will handle specimen numbers, placer and filler identifiers, order status changes, amended results, critical values and acknowledgement of results ownership, especially where downstream actions affect patient safety.
For system configuration and maintenance, MFN^M02 and MFN^M05 messages manage updates to staff and practitioner records as well as ward and bed allocations. This ensures organisational structures, healthcare professionals, and resources are correctly aligned within the EPR.
Although these flows can appear less clinically urgent than ADT or results, they are often foundational. Incorrect practitioner data can affect sign-off rights, order routing, inbox assignment and audit trails. Out-of-date location structures can disrupt dashboards, capacity management and downstream reporting.
System C CareFlow EPR relies on a range of HL7 message types to support core clinical and operational workflows across NHS Trusts. Each message type represents a specific event or action, enabling systems to communicate changes in real time.
The table below provides a simplified overview of some of the most commonly used HL7 message types within CareFlow integrations, helping innovators quickly understand their purpose and where they are typically applied.
| HL7 Message Type | Typical Use in CareFlow |
|---|---|
| ADT^A01 | Patient admission to a hospital or inpatient setting |
| ADT^A03 | Patient discharge from hospital care |
| ADT^A08 | Update to patient demographics or encounter details |
| ADT^A28 / A31 | Creation or update of patient records within the Master Patient Index |
| ADT^A40 | Merging duplicate patient records to maintain a single identity |
| REF^I12 | Creation of a new referral for outpatient or specialist care |
| OML^O33 | Laboratory order messaging for diagnostic tests |
| ORU^R01 | Delivery of clinical results back into the EPR |
One of the challenges in healthcare integration is ensuring data remains consistent across systems. CareFlow addresses this through a combination of message queuing, acknowledgements and persistent storage. Messages are not discarded until they are confirmed as received and processed by the TIE. In addition, the use of HL7’s null versus empty conventions ensures that updates are handled correctly, preventing accidental data loss or duplication.
That distinction between omitted, empty and null values is more important than many non-healthcare teams expect. HL7 guidance distinguishes between a field that is not sent, which generally means “leave the existing value unchanged”, and the explicit delete indicator represented by two double quotes, which means the receiver should remove the stored value. HL7 UK guidance expands on how this works for fields, components and repeats. In practice, this affects everything from demographic updates to clinic data and referral content. A mapping that confuses blank with delete can silently corrupt data, while a mapping that never sends delete indicators can leave stale data in clinical systems.
One of the biggest misconceptions about HL7 integration is that message type alone tells you everything you need to know. In reality, every Trust has local codes, local workflows and local priorities. Even where the trigger event is standard, the receiving system may rely on local site, specialty, clinic, consultant, ward or referral codes that need to be translated carefully. System C’s implementation approach explicitly references detailed mapping and gap analysis, and configuration against NHS data standards and local reference values, including mapping to national codes where required for CDS and related reporting.
For innovators, this means interface design should include a disciplined mapping strategy from the outset. Key questions include which system is the source of truth, which values require crosswalk tables, whether local code sets are stable, how changes will be governed, and how mappings will be tested before go-live. It is also wise to define ownership for every business-critical field. If nobody owns the semantics of a location code or referral priority, it will eventually become an operational problem.
Healthcare interfaces cannot be treated like ordinary middleware projects because message defects can create patient safety risk. NHS England’s clinical risk management standards DCB0129 and DCB0160 are mandatory for health IT used in health and social care, and DTAC assurance includes clinical safety, interoperability, security, data protection and usability. System C states that CareFlow EPR is compliant with DTAC and that System C supports collaborative testing, strategy, plans and reports as part of implementation.
For innovators, that means interface testing should go beyond format validation. Good assurance normally includes unit testing of mappings, end-to-end workflow testing, negative-path testing, downtime and replay testing, merge and unmerge scenarios where relevant, duplicate message handling, and validation of alerting and operational support processes. A technically valid message that places a result on the wrong encounter or leaves an unacknowledged order in limbo can still be a serious failure.
The wider NHS interoperability direction increasingly favours FHIR for modern APIs and structured exchange, and NHS England describes FHIR as the current standard family used for many newer national interfaces. System C also positions CareFlow as FHIR-compliant and offers open FHIR-based APIs alongside its HL7 capabilities.
However, for most Trusts the practical reality is coexistence rather than immediate replacement. HL7 v2 remains deeply embedded in departmental integrations, patient administration flows and results messaging, while FHIR is increasingly used for API-based use cases, cross-organisational exchange and newer services. For innovators, the strategic lesson is clear: build for both worlds. That means designing products with a clean internal data model, separate transport from business logic, avoid hard-coding site-specific message assumptions, and plan a route from HL7 interface feeds toward API-first interoperability where appropriate.
For digital health innovators, integrating with System C’s CareFlow presents a significant opportunity to enhance patient care pathways. Whether through patient engagement platforms, decision support tools, or advanced analytics, solutions that can plug into CareFlow via HL7 messaging add value by extending the functionality of the core EPR. However, success depends on a deep understanding of HL7 message structures, mapping requirements, and the nuances of the CareFlow Integration Engine.
Innovators should also recognise that System C integration success is measured operationally, not just technically. Trusts want confidence that messages arrive in sequence, workflows remain safe during outages, interfaces can be monitored in real time, and support teams can diagnose failures quickly. Products that are easy to map, easy to validate, easy to replay and easy to support are far more attractive to NHS organisations than products that simply claim HL7 compatibility.
Given the complexity of HL7 messaging and the critical role CareFlow plays in NHS Trust operations, many organisations choose to partner with integration specialists. At 6B, our expertise lies in navigating the technical and operational complexities of System C integration, ensuring that new digital solutions work seamlessly within CareFlow ecosystems. We provide support from initial planning through to live deployment, helping innovators accelerate adoption while maintaining compliance and patient safety.
The value of that partnership is not only in building the interface itself, but in reducing delivery risk. Early architecture design, message mapping, safety thinking, test planning, operational readiness, go-live support and optimisation all influence whether an integration becomes an asset or a support burden.
System C’s CareFlow EPR is a cornerstone of modern NHS digital infrastructure, and its ability to communicate through HL7 messaging is fundamental to its success. For digital health innovators, understanding HL7 message types and flows is not just a technical requirement but a strategic advantage. By mastering MPI, ADT, referral, order and result messaging, innovators can ensure their solutions integrate seamlessly, supporting clinicians, administrators, and patients alike. Just as importantly, by understanding message envelopes, acknowledgements, mapping design, local code governance, testing obligations, clinical safety expectations and the growing relationship between HL7 and FHIR, innovators can build integrations that are not only functional on day one but resilient for the long term. With the right technical approach and strategic partners, System C integration becomes a powerful enabler of digital health innovation in the UK.
Is your team looking for help with System C CareFlow integration? Click the button below.
Get in touch