Every healthcare technology programme now carries an interoperability workstream, and most of them succeed on paper. A message conforms to the standard, an API returns the expected payload, an integration test passes in a lower environment. Then the system goes live and a nurse or a consultant still opens three windows to answer one question about a patient. The standard was met. The workflow was not.
This gap between compliance and experience is where a lot of healthcare technology spend quietly underperforms. It is worth being precise about why, because the fix is rarely another interface engine or another version of a messaging standard. It is usually a decision about where information should surface, in what sequence, and how much of it a clinician should have to reconcile in their own head.
The cost of context switching
Clinical work is interrupted work by nature, so every additional screen, login or reconciliation step is not a minor inconvenience, it is a tax on attention during moments that matter. When a result sits in one system and the medication history sits in another, the clinician becomes the integration layer, manually holding both in mind and cross-checking for consistency.
This is rarely visible in the metrics that get reported upward. Uptime looks fine, message volumes look fine, the standard is certified. What does not show up in a status report is the extra ninety seconds per patient that clinicians spend stitching the picture together, multiplied across a shift, a ward, a hospital.
A certified standard tells you data can move between systems. It tells you nothing about whether a clinician still has to hold the picture together in their own head.
Standards are necessary, not sufficient
None of this is an argument against standards. A common structure for clinical data, consistent identifiers and agreed vocabularies are what make integration possible at all, and organisations that skip this step end up with brittle, bespoke point-to-point connections that are expensive to change later.
The mistake is treating certification against the standard as the finish line. The standard tells you the data can move and be understood by another system. It says nothing about whether the receiving system presents that data at the right point in a clinician's workflow, in the right density, without asking them to open something else first.
- 路Map the clinical workflow before the data flow, so integration serves a sequence of decisions rather than a sequence of systems
- 路Treat the receiving screen as part of the interoperability scope, not a downstream concern for someone else
- 路Test with the people who will use the result under time pressure, not only with sample messages in a lab
- 路Measure clicks, screens and logins avoided as seriously as message conformance
Where the seams usually are
In most programmes we see, the visible seams cluster in a handful of places: allergy and medication reconciliation across primary and secondary care, discharge summaries that arrive as documents rather than structured data, and identity matching where the same patient exists under slightly different demographics in different systems.
Each of these has a technical fix, but each also has a governance and workflow dimension that is easy to skip when a programme is under deadline pressure. Fixing the technical layer without fixing the workflow around it produces a system that is interoperable in the audit sense and still frustrating in the ward.
Designing for the moment of use
The organisations that get this right tend to involve clinical staff early, not as a validation step at the end but as co-designers of what should surface, when, and in what order. That changes the integration backlog, because priority shifts from what is easiest to connect to what actually changes a clinical decision.
It also changes how success is defined. A programme that reports interoperability success purely in terms of standards adopted and messages exchanged is measuring the mechanism, not the outcome. The outcome is a clinician who trusts the information in front of them enough to act on it without opening a second system to check.
Interoperability programmes will keep being judged, understandably, against the standards they adopt, because those are the milestones that are easiest to verify and report. But the standard is a means, not an end. The end is a clinician who moves through a patient encounter without friction they can name but cannot always articulate on a status call.
Getting there means treating workflow design as core scope rather than a nice-to-have layered on top of a messaging project, and it means being honest that a technically compliant integration can still fail the people it was built for.