Nervecentre Integration: Understanding HL7, ADT, and MFN Requirements for EPR Connectivity

Electronic Patient Record (EPR) programmes using Nervecentre are moving from “nice-to-have” mobile apps to mission-critical platforms at the heart of acute care. Trusts adopting Nervecentre as their primary EPR or as a major clinical workflow layer are discovering that the real differentiator is not just usability, but how well the platform integrates with Patient Administration Systems (PAS), legacy clinical systems, and regional shared records. That integration is overwhelmingly driven by HL7 v2 messaging, especially ADT and MFN feeds, alongside newer FHIR and API integrations.

To make Nervecentre work as a real-time source of truth, integration teams need a deep grasp of how HL7 v2 behaves in live NHS environments, how ADT messages drive patient context across systems, and how MFN messages keep master data aligned with clinical workflows. This is not purely a technical challenge; it is a design problem touching governance, data quality, operational processes, and clinical safety.

This article explores the role of Nervecentre in modern NHS connectivity, breaks down the HL7 building blocks that matter most, and translates ADT and MFN requirements into practical patterns that integration teams can apply when delivering or upgrading Nervecentre EPR integrations.

The role of Nervecentre in modern NHS EPR connectivity

Nervecentre has evolved from an observations and escalation solution into a full EPR platform for acute and collaborative care, with modules spanning PAS, inpatients, outpatients, emergency care, virtual wards and patient engagement. It is explicitly designed to be mobile-first and cloud-native, providing real-time patient information to clinicians at the bedside, in virtual clinics, and across organisations. For integration teams, this means the system must be continuously fed with accurate, timely event data from other systems, and must in turn be able to share data outwards using standard interfaces.

Nervecentre’s architecture supports multiple interoperability patterns: traditional HL7 v2 interfaces, HL7 FHIR APIs, RESTful APIs, and messaging via NHS connectivity such as MESH. This flexibility allows trusts to plug Nervecentre into existing interface engines such as Rhapsody, Ensemble, or Corepoint, and to phase in FHIR-based exchanges over time while still relying on mature HL7 v2 ADT and MFN feeds for the bulk of operational updates.

In many trusts, especially those on multi-year transformation journeys, Nervecentre is introduced initially as a clinical workflow and mobile layer alongside an incumbent PAS/EPR. Over time it may assume more of the EPR role or even replace a legacy PAS. Regardless of the end-state, the short- to medium-term picture almost always involves bidirectional integration: ADT feeds from the PAS into Nervecentre, master data feeds via MFN (or local equivalents), and outbound messages or APIs from Nervecentre into radiology, pathology, dictation, bed boards, and shared care records.

Because Nervecentre is used directly at the point of care, integration issues surface quickly as visible clinical problems. A missing ADT discharge may leave a patient stranded on a ward list for hours. A misconfigured MFN feed for wards or beds may cause patients to appear under the wrong location, undermining escalation pathways or deteriorating-patient workflows. Integration is therefore not just plumbing; it directly underpins patient safety, flow, and the trust’s ability to demonstrate digital maturity.

Core HL7 v2 concepts that underpin Nervecentre integration

At the heart of Nervecentre integration in most NHS deployments is HL7 v2, particularly versions around 2.3–2.5, aligned with the HL7 UK implementation guidance. These standards define how systems exchange patient and operational data using messages composed of segments, fields, and components. The UK-specific guidance provides consistency for things like NHS numbers, demographics, and common code sets so that vendors and trusts can interoperate more reliably.

HL7 v2 messages are line-based text structures. Each message contains a header (MSH) and a sequence of segments such as PID (patient identifiers and demographics), PV1 (visit details), and others depending on the message type. Messages are triggered by events in source systems – an admission, a bed move, a user being created, a new consultant code being loaded – and are sent through an interface engine or directly to consuming systems such as Nervecentre. ADT (Admit, Discharge, Transfer) messages carry the dynamic, event-oriented facts about a patient’s journey, while MFN (Master File Notification) messages carry relatively static reference data such as providers, locations or services.

For Nervecentre projects, several HL7 concepts are particularly important:

• Message types and trigger events – ADT^A01 (admit/registration), ADT^A03 (discharge), ADT^A08 (update), ADT^A11 (cancel admission), and the various transfer events (A02, A06, A07) define when patient location and encounter changes should propagate. MFN message types describe updates to master files such as provider or location records.
• Segments and segment groups – PID and PV1/PV2 segments hold the patient and visit details Nervecentre relies on for bed boards, lists and escalation rules. Additional segments like NK1 (next of kin), DG1 (diagnoses) and AL1 (allergies) may be included depending on the trust’s integration scope.
• Identifiers and coding – NHS numbers, local hospital numbers, organisation codes, location codes and professional identifiers need to be consistent. HL7 UK guidance encourages standard use of identifier types and code tables.
• Acknowledgements and error handling – Nervecentre must be able to respond with accept, error, or reject acknowledgements so that interface engines and PAS teams can monitor for failed messages.

Conceptually, it helps to think of HL7 v2 as an event stream feeding an event-driven platform. When ADT and MFN feeds are comprehensive and clean, the EPR behaves like a live operational picture of the hospital. When those feeds are incomplete or inconsistent, clinicians experience missing patients, incorrect locations, or confusing lists – and often attribute these issues to the EPR rather than to the integration design.

For technical teams, a strong conceptual grounding in HL7 v2 is still essential even as FHIR adoption grows. Many trusts will adopt a hybrid pattern: HL7 v2 for admitted-patient and master data, combined with FHIR APIs and REST integrations for newer digital health solutions, analytics, and cross-organisational flows. Nervecentre’s support for both means that the core HL7 design decisions made today will continue to matter long after FHIR is introduced elsewhere in the ecosystem.

Designing robust ADT feeds for Nervecentre and PAS/EPR synchronisation

ADT messages are the backbone of Nervecentre’s view of the hospital. They tell the system which patients exist, where they are, which encounters are active, and when those encounters change state. ADT is often the highest-volume HL7 message set in a hospital, driving synchronisation between PAS/EPR and clinical systems. For Nervecentre, the quality of the ADT feed effectively determines the accuracy of bed management, patient flow, and escalation lists.

The first design decision is the source of truth for patient and encounter data. In most trusts where Nervecentre is layered on top of an existing PAS, that PAS remains the master for registrations, admissions, discharges and transfers. Nervecentre consumes a real-time ADT feed and uses those events to construct its live lists. In a minority of configurations, especially where Nervecentre’s PAS component is deployed, Nervecentre itself may originate ADT-equivalent messages for downstream systems.

Next comes event coverage. A minimal ADT feed might include only A01 (admit/registration), A03 (discharge) and A08 (update). For a modern EPR, that is rarely sufficient. To give Nervecentre the fidelity it needs for escalation rules, theatre planning, ED flow and virtual wards, the feed should cover the full range of events that represent material changes in a patient’s journey, including internal transfers between wards, changes in attending consultant, and “off ward” statuses used in local bed-management processes.

A third dimension is location modelling. HL7 ADT relies heavily on location fields in PV1 and related segments to represent wards, bays, beds, clinics and departments. Trusts often have a legacy of inconsistent or overloaded location codes in PAS and downstream systems. Because Nervecentre exposes locations so prominently in its mobile UI and live-flow dashboards, any discrepancies become obvious: a patient may appear on a “ghost ward”, or a bay name may not match signage. This requires a coordinated effort to clean and govern location master data before finalising ADT mapping into Nervecentre.

Data protection and patient identity management are equally critical. The ADT feed is where NHS numbers, local identifiers, demographics, and sometimes temporary or unknown patient profiles are first propagated into Nervecentre. Aligning with HL7 UK guidance on using patient identifier types, appropriate handling of temporary identifiers, and clear merge/duplicate-resolution processes is essential. Trusts must decide how to handle merges, late-arriving NHS numbers, and updates from national services, ensuring that Nervecentre applies these changes cleanly.

Finally, error handling and monitoring around ADT is non-negotiable. Because Nervecentre is used at the bedside, the tolerance for missing or delayed patients is low. Interface engines should route all ADT feeds through monitored channels, with clear alerting for rejected messages or acknowledgement mismatches. Operational run-books should define how ADT failures are investigated and reconciled.

In short, ADT design for Nervecentre is about faithfully representing the lived operational reality of the hospital. Done well, it supports safe escalation, efficient flow, and accurate reporting. Done poorly, it creates constant background problems that undermine clinician confidence in the EPR.

Using MFN and master data feeds to drive clinical workflow in Nervecentre

While ADT messages describe what is happening to a patient right now, MFN messages describe the relatively stable “things” in the hospital: locations, clinicians, specialties, services, beds, user accounts and more. MFN messages are essential for EPRs because they shape how workflows, rules, lists and reporting behave inside systems like Nervecentre.

Nervecentre’s workflow and escalation capabilities rely on accurate staff roles, responsibilities, specialty mappings and ward structures. To achieve this at scale, trusts typically automate as much master-data integration as possible, especially for:

• Wards, beds and clinical locations – Typically sourced from the PAS or an estates system, these define the physical layout of the hospital, which Nervecentre uses to drive bed boards, patient lists and escalation routes.
• Consultants, clinicians and staff roles – Often sourced from ESR or a staff directory, these records ensure that on-call rotas, escalation hierarchies and responsible-consultant views align with reality.

MFN design is sometimes overlooked because the messages appear less “urgent” than ADT. However, when MFN feeds are incomplete or inaccurate, clinicians experience subtle but pervasive friction: patients assigned to obsolete wards, alerts going to outdated teams, or reports that mix old and new service codes. Because Nervecentre’s mobile UI makes organisational context highly visible, these inconsistencies become particularly noticeable.

A robust MFN approach requires clear source-of-truth decisions for each domain. Integration specifications then map those authoritative sources into HL7 MFN messages or equivalent feeds consumed by Nervecentre. Where national code lists exist, they should be adopted rather than recreated locally, helping future-proof data for use in FHIR-based services and regional shared care records.

Another essential element is change management. Master data changes – merging wards, renaming services, restructuring specialties – have cascading impacts on EPR workflows. MFN feeds should be tightly integrated with change-control processes so Nervecentre configuration teams can test changes before they affect clinicians. This is especially important for safety-critical workflows such as deteriorating-patient alerts.

Finally, MFN design often includes code translations and local extensions. HL7 provides mechanisms for multiple identifiers and descriptive fields within master-file segments. Integration teams should use these to avoid lossy mappings, especially where Nervecentre user interfaces display location or service names. A thoughtful MFN strategy reduces reconfiguration and keeps the EPR aligned with operational reality.

Practical implementation considerations and best practices for Nervecentre HL7 integration

Turning ADT and MFN theory into a working Nervecentre integration involves many moving parts: the PAS or other source systems, an interface engine, Nervecentre’s integration layer, networking, security, and operational support teams. Successful programmes treat integration as a core workstream with its own governance, testing strategy and clinical engagement.

An early architectural decision is whether Nervecentre will connect directly to source systems or via an existing integration engine. Most trusts already use engines that handle hundreds of HL7 feeds, providing routing, transformation and monitoring. Using the existing engine allows ADT and MFN feeds to be cleansed, transformed and audited consistently. Direct connections may be considered when cloud-to-cloud performance or security requirements justify them, but most designs still include the engine for monitoring and transformation.

Beyond architecture, several practical best practices improve outcomes:

• Co-design message content with clinical stakeholders – Mapping PAS events to HL7 triggers should involve clinicians and operational leads. Decisions about statuses, temporary wards, bed-move semantics or consultant changes have real consequences for flow, escalation, and reporting.
• Align integration testing with real-world workflows – HL7 validation alone is insufficient. Full end-to-end testing should mimic real workflows: admission, transfer, consultant change, escalation, discharge, re-admission, and edge cases like cancelled admissions or rapid transfers. Testing should verify Nervecentre’s behaviour on mobile devices and dashboards under realistic conditions.
• Instrument and monitor the integration layer – Even with modern, resilient cloud hosting, HL7 channels must be monitored for message volume, queue depth, errors and acknowledgements. Trusts should implement dashboards and alerts so issues are caught before they affect clinicians.
• Plan for phased roll-out and coexistence – Many organisations implement Nervecentre in stages: ED, inpatients, flow, virtual wards, then PAS/EPR components. Integration designs should anticipate coexistence and dual-running, ensuring mappings and code sets remain compatible throughout the transition.
• Embed data quality and governance – Nervecentre exposes operational data directly to large numbers of frontline users, making inaccuracies immediately visible. Strong governance for identifiers, locations, roles and ADT processes reduces the likelihood of recurring issues and keeps workflows stable.

Security and compliance are equally crucial. Nervecentre is typically deployed in secure, accredited UK data centres, with encrypted connections between trust networks and the cloud environment. Integration designs should follow data-minimisation principles, sending only the fields required for workflows and adhering to trust-level retention policies.

A final consideration is future-proofing. The NHS is moving steadily toward FHIR-based interoperability and richer shared-care ecosystems. Nervecentre already participates in this evolution, and well-structured HL7 v2 feeds—clean code sets, consistent semantics, clear event mapping—make future FHIR transitions smoother. Poorly structured HL7 integrations, by contrast, become long-term obstacles.

For trusts and suppliers alike, the goal is clear: a mobile-first EPR that delivers truly real-time clinical information, underpinned by reliable HL7 v2 event streams and well-governed master data. Getting ADT and MFN integration right with Nervecentre is not simply a technical exercise—it is a foundational component of safe, efficient, and connected care across the NHS.