Integration architecture is clinical infrastructure

When integration fails, clinicians do not experience an “interface issue”. They experience missing information, delayed care, and loss of trust in systems. Integration architecture determines whether orders arrive on time, results attach to the correct encounter, and patient context remains coherent across systems.

Across public and private hospitals in Scotland, England, New Zealand, and Thailand, the same lesson emerges: integration is clinical infrastructure. Treating it as middleware plumbing introduces hidden risk that only surfaces under pressure.

PAS and EMR programmes do not fail because of standards

Large PAS and EMR programmes rarely fail due to HL7, FHIR, or integration engines. They fail because of unclear ownership, assumptions that vendors will “handle the interfaces”, and underestimation of legacy behaviour embedded in HL7 v2 messaging.

Standards compliance is often mistaken for interoperability. In reality, interoperability only emerges when standards are applied within a disciplined architectural framework with clear accountability.

What actually survives in long‑lived hospital estates

After multiple PAS replacements, EMR upgrades, and national initiatives, the architectures that endure share common characteristics.

• HL7 v2 remains the internal backbone for ADT, orders, results, and scheduling due to its event‑driven reliability.
• FHIR is used at boundaries for shared care, aggregation, and controlled external access.
• Integration engines are treated as utilities, not decision-makers.

Successful programmes stabilise HL7 rather than attempting to remove it, and apply FHIR where it delivers structural advantage rather than ideological purity.

FHIR works when behaviour is constrained

FHIR resources are intentionally flexible. Without profiling and governance, two systems can both be FHIR‑compliant and still incompatible. Profiles define required fields, value sets, cardinality, and clinical expectations.

Experience from UK shared care programmes demonstrates that interoperability improves when behaviour is constrained deliberately. Profiles are not technical overhead. They are clinical contracts that enable trust at scale.

The risks most programmes underestimate

Integration logic always leaks upward. If architectural decisions are not made explicitly, they are made implicitly in mappings, transformations, and support workarounds. Over time, this creates fragile estates that are difficult to change safely.

Governance delayed until after go‑live is governance denied. Once systems are live, clinical pressure limits change, vendors resist rework, and risk accumulates quietly.

Lessons from UK shared care records

UK shared care record initiatives succeeded not because of FHIR alone, but because of architectural discipline. HL7 and FHIR were allowed to coexist. Source systems retained ownership. Consent and stewardship were explicit.

The lesson for other health systems is clear: interoperability improves when architecture, not tooling, leads the conversation.

What health technology leaders should demand upfront

• Clear ownership of integration architecture
• Approved and forbidden integration patterns
• Defined boundaries between HL7 and FHIR usage
• Governed profiling and versioning strategy
• Explicit handling of clinical risk when interfaces fail

If these answers are unclear at programme start, the organisation will eventually pay for it operationally.

The JTX IT perspective

At JTX IT, we treat healthcare integration as a long‑lived architectural discipline. We work across PAS, EMR, integration engines, and national services to design architectures that survive upgrades, vendor change, and operational pressure.

Our focus is clarity of ownership, sustainable patterns, and integration that supports clinical care rather than disrupting it.