Written by Technical Team | Last updated 15.11.2025 | 14 minute read
Modern NHS trusts increasingly rely on Nervecentre as a core component of their digital ecosystem, using it for electronic observations, mobile clinical workflows, patient flow management and next-generation EPR capabilities. As Nervecentre becomes embedded more deeply into acute care pathways, the quality of its integrations – particularly HL7-based messaging with PAS, laboratory, ED, radiology and other systems – becomes a critical determinant of patient safety and operational performance. A robust integration testing strategy for Nervecentre must therefore go far beyond “does the message send and receive?” and instead provide high confidence that HL7 segments, variants and edge cases behave correctly across realistic hospital scenarios.
HL7 is both a standard and, in practice, a family of local dialects shaped by each trust’s historic systems and suppliers. Nervecentre often has to coexist with legacy PAS platforms, departmental systems and new HL7 FHIR-based APIs, all at once. This complexity means that a superficial test plan will almost certainly miss important “corner” behaviours – particularly around admission, transfer and discharge events, order workflows and deteriorating patient alerts. The result can be subtle data quality issues, broken clinical workflows and misleading dashboards.
This article sets out a practical, detailed strategy for Nervecentre integration testing that is grounded in the realities of NHS acute trusts. It focuses specifically on how to validate HL7 segments, how to manage local variants and how to systematically expose edge cases before they reach production. Whether you are an integration engineer, Nervecentre product owner, or a test lead in an EPR programme, the aim is to give you a blueprint you can adapt to your own environment.
Before designing any tests, you need a mental map of how Nervecentre sits within the hospital integration landscape. Nervecentre’s next-generation EPR is typically deployed as a mobile-first platform that surfaces real-time data at the bedside – vital signs, sepsis alerts, patient flow, prescribing and electronic documentation – while integrating with existing core systems such as PAS, ED, pathology and radiology. HL7 messaging is the connective tissue that underpins that real-time behaviour.
In many deployments, Nervecentre consumes HL7 v2 ADT messages from a PAS to keep its patient census and demographics synchronised. MSH, EVN, PID and PV1 segments are central: they determine which patient is being referred to, which episode is in play, which ward and bed they occupy and which consultant is responsible. Laboratory and radiology systems may send ORU^R01 observation messages, often with OBX segments encapsulating results that feed into rules for sepsis recognition or deterioration alerts. ED implementations frequently use HL7-based integration to ensure attendances, dispositions and flow metrics in Nervecentre align with the PAS and ED systems.
The move towards HL7 FHIR adds another layer. While many trusts still rely heavily on HL7 v2 feeds, newer Nervecentre deployments are beginning to exchange data using HL7 FHIR resources and APIs, particularly in ED and regional interoperability contexts. That means a realistic integration test strategy often needs to span both message-based interfaces (HL7 v2 over MLLP) and RESTful FHIR endpoints, validating equivalence across the two where they represent the same clinical concept.
Crucially, these integrations are not just technical plumbing; they directly drive clinical decision support. Nervecentre uses real-time data to identify deteriorating patients, support sepsis pathways and prioritise tasks across clinical teams. If HL7 feeds are incomplete, delayed or malformed, alerts may not trigger, dashboards may mislead, and escalation pathways may break. Integration testing must therefore be framed as a patient safety activity, not merely an IT exercise.
An effective Nervecentre integration testing strategy starts with a clear articulation of scope and risk. Rather than simply enumerating interfaces, you should map each HL7 feed to the clinical and operational outcomes it supports. For example, ADT messages underpin timely visibility of admissions and bed moves in Nervecentre’s patient flow dashboards, while laboratory result messages influence sepsis screening and Early Warning Score (EWS) workflows. This mapping helps you prioritise test coverage where failure would have the greatest impact on patient safety or operational performance.
The next step is to define a layered testing approach that spans unit-level validation of individual HL7 messages, system integration testing across Nervecentre and a single counterpart system, and end-to-end scenario testing from the initiating system through to the clinician’s mobile device. Unit-level tests might verify that a specific ADT^A08 message with certain PID and PV1 combinations is parsed correctly, while end-to-end tests confirm that, for example, a virtual ward transfer in the PAS results in the right change in the Nervecentre bed board and associated task lists.
Data design is often overlooked but is foundational to good integration testing. You need a curated catalogue of test patients, episodes and orders representing realistic combinations of demographics, specialties, pathways and complexity. That includes paediatric and adult patients, emergency and elective admissions, short-stay cases, outliers and complex movements. Where possible, this dataset should be stable and reusable across test cycles, with scripts or automation to reset states between runs.
It is also important to decide early how much of your HL7 testing you will automate. For message-level validation (e.g. syntax, required segments, field formats), automated tests using HL7 parsers and schema validation tools can deliver rapid, repeatable feedback as mappings evolve. For cross-system and clinical workflow testing, some manual exploratory testing remains essential, especially to uncover usability and timing issues. A hybrid approach usually works best: automated regression packs for standard scenarios, supplemented by manual or semi-automated “clinical walk-through” exercises using realistic devices and accounts.
Finally, governance matters. Integration changes for Nervecentre should be subject to a lightweight but rigorous change control process that includes a view of test impact. When a PAS upgrade introduces new PV1 field usage or a laboratory system alters its OBX coding, you should know exactly which Nervecentre tests to rerun. Over time, your integration test suite becomes not just a quality gate but a living documentation of how HL7 messages drive behaviour in Nervecentre.
For most trusts, a pragmatic Nervecentre integration test strategy will:
Validating HL7 segments for Nervecentre integrations is not just about checking that messages are structurally valid; it is about ensuring that each segment conveys the right meaning in the context of the receiving workflows. Start with the “spine” of your key messages. For ADT feeds, that typically means MSH, EVN, PID, PV1 and, where used, PV2 and Z-segments. For orders and results, it includes ORC, OBR and OBX segments. You should build a reference model describing how each of these segments is interpreted by Nervecentre – which fields are mandatory, which drive business rules, and which are ignored.
Message-level validation should first ensure that segments conform to the agreed HL7 profile. This profile will typically be more constrained than the base HL7 v2.x standard and may include local rules about repeating segments, maximum field lengths or allowed coding systems. Automated tests can parse sample messages, asserting that required fields are populated (e.g. PID-3 for primary identifier, PV1-2 for patient class) and that values are within expected sets (e.g. PV1-44 discharge date/time not before admission date/time). Such validation is particularly useful during early interface build and when applying upgrades to Nervecentre or the sending system.
However, structural correctness is not enough. You also need to validate semantic correctness – whether the message content leads to the right real-world behaviour. That requires a tight coupling between HL7 validation and application-level outcome checking. For example, after sending an ADT^A02 (transfer) with specific PV1 ward and bed values, you should verify that Nervecentre shows the patient in the expected ward bay, that the correct clinical team owns the patient, and that any location-based rules (e.g. specific sepsis screening workflows) are applied. Similarly, validating OBX segments should include checks that coded result values are correctly interpreted in clinical rules or dashboards.
Another powerful technique is differential testing, in which you compare Nervecentre’s internal representation of a patient or episode with an authoritative source after a series of HL7 messages have been processed. For instance, you could retrieve patient data from Nervecentre via API, and from the PAS via its own reporting mechanism, then assert that key fields such as identifiers, NHS number, date of birth, current ward, consultant and admission type match (or differ only where expected). This approach surfaces subtle mapping issues – for example, when one system truncates long names or uses different coding for specialties.
Finally, pay particular attention to time-related fields in segments. HL7 messages carry multiple timestamps – message creation time, event time, admission and discharge times, sample collection and result times – and mismatches or misinterpretations can have significant downstream effects. In Nervecentre, timely and accurate timestamps are essential for longitudinal charts, escalations based on “time since” criteria and retrospective audit. Your tests should therefore include scenarios with out-of-order messages, delayed sends and near-simultaneous events, validating not just that Nervecentre accepts the messages, but that it orders and displays events in ways that make clinical sense.
Every trust has its own HL7 “accent”. Over years or decades, PAS, laboratory and departmental systems accumulate local customisations, non-standard code sets and Z-segments that encode business rules not formally captured elsewhere. Nervecentre’s flexibility and modern architecture make it a good candidate for operating in this heterogeneous landscape, but only if you deliberately test against local variants rather than assuming textbook HL7 behaviour.
Start by cataloguing the variants you know about. PAS vendors may use Z-segments to represent local patient category flags, treatment functions or internal routing data. Laboratory systems might deliver results with custom OBX-3 identifiers or embed free-text comments with clinically relevant information. ED systems may emit non-standard combination codes for arrival and departure dispositions. For each sending system, create a concise profile that documents which HL7 segments and fields are used, where they deviate from the agreed interface specification and what they are intended to mean.
In Nervecentre, many of these variants will map to configuration – for example, how patient classes map to internal flows, or how particular OBX codes feed into deterioration rules. Integration testing should therefore include configuration-aware verification: not just “does the message parse?” but “does this specific combination of local codes and values lead to the configured behaviour?” When a trust rationalises local codes – for example, consolidating ward codes or specialties – your tests become a vital safety net to ensure that Nervecentre continues to behave as intended.
Legacy systems present additional challenges. Some older PAS or departmental systems produce HL7 messages that are syntactically weak by modern standards: missing fields, inconsistent date formats or excessive use of free-text. In practice, trusts rarely have the option to replace these systems quickly, so you must design your Nervecentre integration testing strategy around accepting “messy but safe” input. That often involves testing how Nervecentre behaves when key fields are absent, partially populated or filled with unexpected values, and agreeing with clinical stakeholders where the safe minimum is for the system to operate.
Interoperability increasingly extends beyond a single hospital. Nervecentre’s cloud-based EPR is designed to support multi-provider and regional workflows, sharing records and data across organisations. This may involve HL7 FHIR APIs, national services such as GP Connect, and messaging infrastructures like MESH. Your integration testing strategy should anticipate cross-border scenarios, such as patients referred from neighbouring trusts, transfers into and out of your organisation, and data flows to and from regional or national repositories. These tests help to surface assumptions that hold locally but break when data is shared more widely.
Ultimately, managing HL7 variants and legacy behaviours is as much about collaboration as it is about testing technique. You will need to work closely with clinical leads, information teams and external suppliers to understand what “good enough” looks like and to negotiate changes when necessary. Your test results, particularly when they demonstrate real or potential patient safety implications, can be a powerful tool to secure prioritisation for necessary interface and system improvements.
Edge cases are where integration defects most often hide, and Nervecentre’s role in time-critical workflows makes it essential to flush them out before go-live. A systematic approach to edge-case testing starts with analysing real historical data and incident reports, identifying patterns of unusual but clinically significant events: complex admission and transfer histories, patients with multiple active episodes, frequent cancellations and re-bookings, or extreme demographic details such as very long names or overseas addresses.
One rich seam of edge cases arises from patient movement. Real-world patients rarely follow the neat admission–ward–discharge journey portrayed in simple test scripts. Instead, they may board in ED corridors, move between multiple wards and specialties, transfer temporarily to theatres or intensive care, and then return. Your HL7 test scenarios should include out-of-sequence transfers, same-day discharges and readmissions, temporary outliers and simultaneous updates from different systems. For each scenario, you need to verify that Nervecentre’s view of the patient – location, responsible clinician, task lists and alerts – remains coherent and clinically sensible.
Data quality edge cases are equally important. Consider patients with duplicate hospital numbers, missing NHS numbers, ambiguous identifiers or conflicting demographic details. Nervecentre must balance the need to present clinicians with a consolidated, usable record against the risk of incorrect merges or misidentification. Integration tests can simulate deliberate duplicates, partial merges and correction messages, then assess how Nervecentre displays and manages these cases. Particular attention should be paid to how sepsis alerts, observation histories and tasks appear when patient identity changes mid-episode.
Timing and resilience scenarios deserve their own focus. HL7 messages may be delayed, duplicated or delivered out of order due to network issues, queue backlogs or sending system problems. Your strategy should include tests where ADT messages arrive late relative to observations or orders, where the same message is resent with the same message control ID, and where correction messages (e.g. ADT^A08 updates) arrive after downstream workflows have already progressed. For each, you must assess both technical behaviour (e.g. idempotency, failure handling) and clinical impact (e.g. whether the right patient appears on the right list at the right time).
Because Nervecentre is heavily used in recognition and escalation of deteriorating patients, you should also design edge-case tests around clinical scoring thresholds and escalation rules. For example, verify how the system behaves when multiple OBX results arrive in quick succession, when observation sets are amended or corrected, or when observations are recorded against an episode that is later cancelled or backdated. These tests help ensure that alerts are neither suppressed nor duplicated inappropriately, and that audit trails remain clear.
To help structure this work, it is useful to build a catalogue of edge-case themes and map specific test cases to each theme:
By deliberately focusing on these scenarios, you can expose weaknesses that routine “happy path” testing would miss. Over time, your edge-case catalogue becomes both a safety net for regression testing and a learning resource for new team members, encoding the hard-won lessons of previous integrations.
A disciplined, clinically aware Nervecentre integration testing strategy is not optional; it is central to delivering safe, effective digital care in modern NHS trusts. By understanding how HL7 segments and local variants drive behaviour in Nervecentre, and by rigorously testing edge cases and failure modes, you can significantly reduce the risk of integration-related incidents while enabling the full value of a mobile, real-time EPR platform.
Is your team looking for help with Nervecentre integration? Click the button below.
Get in touch