Written for the integration architect and standards guardian responsible for interface quality, with the pre-flight framing used to make routine validation discipline feel urgent rather than merely thorough. Deliberately precise about what's available today (in-workflow validation) versus what's still maturing (formal conformance certification via WeHub Proof), since this is one of the guardrailed claims in the piece and the distinction protects credibility with a technically literate reader.
A new interface goes live between a departmental system and the EPR. It passes testing, because testing covered the happy path: a handful of well-formed messages that matched what the spec said would arrive. Three weeks into production, a message shows up that's technically HL7 but structurally wrong in a way nobody tested for, a missing mandatory segment, a code from the wrong value set, and it lands in the EPR anyway, because nothing in the pipeline was actually checking.
That's the ordinary failure mode of integration testing done informally: it proves the happy path works and says almost nothing about what happens when a message doesn't match expectations. Pre-flight validation is the discipline of checking that systematically, before go-live and continuously afterward, rather than discovering conformance gaps in production.
In brief
Pre-flight validation is the practice of checking that HL7 v2 and FHIR messages actually conform to the standard and profile they claim to, before they reach a live clinical system, rather than trusting that a message which parses is a message that's correct. It catches three kinds of gap: structural non-conformance (missing mandatory fields, wrong data types), profile non-conformance (a FHIR resource that's valid FHIR but doesn't meet the UK Core profile it's supposed to), and terminology non-conformance (codes that don't belong to the value set a field is bound to). Done well, it sits both at go-live, as a formal conformance check against a target profile, and continuously in production, as in-workflow validation on every message that flows.
The message that shouldn't have made it through
The core problem with informal integration testing is that "the message parsed" and "the message was correct" get treated as the same fact, and they aren't. A message can be perfectly well-formed HL7 v2 syntax and still violate every convention the receiving system actually needs: a segment present but missing a mandatory field, a code drawn from a list the field was never meant to accept, a resource that's technically valid FHIR but doesn't meet the UK Core profile the receiving system was built against. None of these will typically cause a parser to reject the message outright. All of them can cause the receiving system to store or act on data that's subtly, dangerously wrong.
The gap exists because most integration testing checks the pipes, that a message arrives and gets parsed, without checking the water flowing through them, that the content actually conforms to what was promised.
Validation after the fact versus validation before flight
There are, broadly, two places conformance gets checked, and they serve different purposes. After-the-fact validation happens when something has already gone wrong: a clinician spots an odd value, a report doesn't reconcile, and an investigation traces it back to a message that never should have been accepted. This is expensive in the way all downstream discovery is expensive: the bad data has often already been acted on by the time it's found.
Pre-flight validation moves the check earlier, ideally to two points: once, formally, before an interface goes live, testing it against realistic and adversarial message samples rather than just the happy path; and continuously, in production, as every message is checked against its expected profile before anything downstream sees it. The name captures the idea directly: like a pre-flight check on an aircraft, the goal is to catch what's wrong before departure, not to investigate after something's gone wrong in the air.
What pre-flight validation actually checks
Three categories of check do most of the useful work. Structural validation confirms a message or resource has the fields it's supposed to have, in the right data types, honouring cardinality rules, a HL7 segment with its mandatory fields present, a FHIR resource with its required elements populated. Profile validation goes a level deeper: confirming a FHIR resource doesn't just satisfy base FHIR but satisfies the specific profile it's meant to, UK Core being the relevant one in an NHS context, since a resource can be valid FHIR and still fail the more specific constraints a receiving system actually depends on. Terminology validation checks that coded fields carry codes that actually belong to the value set that field is bound to, catching the case where a field is structurally fine but semantically wrong because its code came from an ungoverned or mismatched source.
A validation approach that only does the first of these catches the obvious problems and misses the dangerous ones; profile and terminology validation are where the real conformance risk usually lives.
Where this fits in an integration build
Practically, pre-flight validation belongs in two places in any serious integration build. Before go-live, it's a formal testing exercise: generating or sourcing realistic message samples, including deliberately awkward edge cases, and running them against the target profile to see what actually fails, rather than assuming the spec alone guarantees conformance. In production, it's a standing gate inside the workflow itself, built into the pipeline the same way a schema check sits at the boundary of any well-built integration: every message validated against its expected structure, profile and terminology bindings before it's allowed to reach the receiving system, with failures routed to an exception queue a human is accountable for, not silently logged and forgotten.
This is the discipline WeHub Studio's validation is built to support directly inside a workflow, checking messages as they flow rather than treating validation as a separate, external testing phase that happens once and is never repeated.
Conformance testing versus in-workflow validation
It's worth being precise about a distinction that matters here. In-workflow validation, checking every message against structure, profile and terminology as it flows through a live pipeline, is available today and is the discipline this piece has been describing throughout. Formal, standards-based conformance testing, systematically certifying that an entire interface conforms to a target implementation guide such as UK Core, is a deeper and more specialised capability, one that WeHub Proof is being built to provide, and it isn't live yet. The honest position for any Trust or vendor today is to build in-workflow validation now, as standard practice, while treating formal conformance certification as a capability still maturing across the market rather than something already available off the shelf.
The bottom line
Most NHS interfaces are tested for the happy path and left to discover conformance gaps in production, which is the expensive way to learn about them. Pre-flight validation, checking structure, profile and terminology before a message reaches a live system, moves that discovery earlier and makes it routine rather than incident-driven. Before the next interface goes live, ask a specific question: has it been tested against a deliberately malformed or edge-case message, not just a well-formed one? If the honest answer is no, that's the gap worth closing before go-live rather than after.
