Pattern before protocol
Decide whether the interaction is request/response, message, event, document, query, bulk movement or workflow coordination before selecting FHIR, HL7 v2, IHE, DICOM or another implementation technology.
24integration patterns
12reliability overlays
11problem-led scenarios
12evidence-led findings
1. Executive judgement
Integration quality is determined by interaction semantics and workflow, not by the modernity of the protocol.
No single pattern is inherently superior. RESTful APIs are strong for interactive resource access, durable messaging for decoupled operational flows, publish/subscribe for fan-out notification, document sharing for persistent authored artefacts, DICOM for imaging, and orchestration where the real problem is accountable work. The architecture becomes weak when one pattern is promoted as a universal answer.
Delivery before syntax
Specify durability, acknowledgement, retry, duplicate handling, ordering and recovery as explicit requirements. A perfectly valid payload can still be lost, repeated or acted upon twice.
Workflow before interface
Where the clinical requirement is that somebody must act, represent responsibility and process state. Successful transport is evidence of delivery, not evidence that the intended care process completed.
2. Method and evidence
Patterns are assessed against the operational problem they solve.
The navigator combines the supplied Health Data Operability material with current authoritative HL7, IHE and DICOM specifications. Ratings for current use and strategic potential are qualitative professional judgements, not measured adoption statistics. Standards facts are separated from analytical recommendations in the findings register.
Selection dimensions
Evidence hierarchy
Primary specifications and the supplied book carry greatest weight. The navigator uses design inference only where a source defines a mechanism but does not prescribe when a particular organisation should use it.
3. Integration anatomy
An integration has more layers than its payload.
A durable integration contract needs to say not only what data is exchanged, but why, when, with whom, under which workflow state, what constitutes successful receipt, and how failure is recovered.
Interaction
Request, command, event, query, document, bulk movement or workflow transition.
Information
Payload structure, terminology, provenance, completeness and interpretation constraints.
Delivery
Durability, ordering, retry, acknowledgement, idempotency, error handling and replay.
Identity & trust
Patient, professional, organisation and system identity, authentication, authorisation and audit.
Process
The clinical or operational state that caused the interaction and the responsibility created at the receiving side.
Operations
Monitoring, support ownership, service levels, capacity, change management, versioning and incident recovery.
4. Evolution
The patterns accumulated. They did not replace one another.
Healthcare still uses every major integration style developed over the past four decades because the underlying interaction problems remain different.
Point-to-point
Systems were connected directly to solve immediate operational exchange.
HL7 v2 messaging
Common message structures reduced the cost of event-driven hospital integration while retaining substantial implementation flexibility.
Integration engines
Routing, transformation and monitoring moved into shared hubs, reducing connection arithmetic but concentrating semantic knowledge.
CDA & IHE sharing
Persistent authored clinical artefacts, registries and repositories addressed cross-organisational sharing and document integrity.
FHIR & web patterns
Resource APIs, SMART apps, subscriptions and web-friendly document/imaging access widened the set of architectural choices rather than reducing it to REST.
5. Assurance basis
A technically valid integration can still be unsafe or operationally incomplete.
This navigator is jurisdiction-neutral. Legal and regulatory duties vary, but every healthcare integration should make explicit the authorised purpose, identity and access model, provenance, auditability, information quality, clinical-safety implications and responsibility for failed or uncompleted work.
Define why information is being exchanged and whether downstream use remains within that purpose.
Identify hazards caused by delay, duplication, omission, ordering, stale data or loss of context, not merely invalid syntax.
Authenticate systems and users, apply least-privilege access, protect data in transit and preserve audit evidence.
Name who owns a failed message, an unreviewed result, an unacknowledged referral or an unavailable service.
6. Pattern landscape
Interaction timing and coupling narrow the choice quickly.
The schematic positions representative patterns from synchronous to asynchronous and from direct coupling to mediated or federated interaction. Select a node to open that pattern in the catalogue.
7. Interactive pattern catalogue
Choose the pattern according to the interoperability situation.
Select a use context to make suitability, current use and strategic potential context-sensitive. A high current-use score is not a recommendation to use the pattern for a problem it does not fit.
8. Decision aid
Build an integration stack around a real use case.
The recommended stack separates the primary interaction pattern from supporting patterns. Mature healthcare integrations commonly combine several patterns rather than forcing one mechanism to do everything.
Six questions before design
1Does the sender need an immediate answer, or only reliable eventual processing?
2Must the exchange survive receiver downtime?
3Is this a fact, an event, a command, a document or a unit of work?
4Is there one known receiver, many subscribers or an unknown future consumer?
5Must history be replayable or the artefact remain immutable?
6What clinical responsibility is created when the information arrives?
9. Reliability overlays
The interaction pattern is only half the design.
These implementation overlays determine whether a theoretically sound pattern behaves safely under retries, outages, duplicated delivery, schema change and operational recovery.
10. Coherence and consistency
Patterns can coexist without creating an architectural free-for-all.
Consistency should be imposed on contracts, semantics, identity, provenance, reliability and conformance rather than by mandating a single transport style.
Standardise centrally
Allow contextual choice
11. Clarity and drafting
Integration requirements should describe observable behaviour.
Requirements such as “provide a REST API” or “support FHIR” are architecture choices masquerading as needs. Better requirements state the behaviour and assurance outcome the design must satisfy.
Weak requirement
“The system shall expose real-time FHIR APIs.”
Problem: assumes both latency and interaction pattern without stating the business reason.
Stronger requirement
“Authorised clinical applications shall retrieve the current medication list during an active user session without depending on a batch replication cycle.”
Then decide: a synchronous FHIR API may be a good solution.
Critical distinction
Technical acknowledgement, business acceptance, clinical review and completion are different states. Requirements should name the one that actually matters.
12. Evidence, monitoring and viability
Integration assurance must continue after conformance testing.
A viable service needs evidence that messages and APIs continue to support the intended process as systems, schemas, terminology, traffic and organisational boundaries change.
Conformance
Validate profiles, schemas, terminology bindings, security configuration and supported capabilities.
Operational telemetry
Observe latency, queue depth, retries, dead letters, duplicate rates, rejected payloads, timeout rates and unavailable dependencies.
Clinical/process telemetry
Measure unacknowledged results, incomplete referrals, stale documents, reconciliation burden and other evidence that transport success did not produce operational success.
13. Interactive findings register
Key architectural findings.
Evidence type distinguishes direct source facts from analysis and professional inference. Severity reflects the consequence of getting the architectural decision wrong, not the quality of the standard involved.
| ID | Dimension | Finding | Evidence type | Severity | Confidence | Sources |
|---|
14. Recommended actions
Use the navigator as an architecture-governance instrument.
1. Require pattern justification
Every significant interface should identify the interaction pattern and explain why its latency, coupling and durability match the business process.
2. Maintain approved pattern profiles
Publish organisation-specific implementation profiles for the patterns actually supported, including security, retry, acknowledgement, monitoring and versioning rules.
3. Treat workflow as architecture
Where information creates a clinical obligation, model the work state and accountable receiver rather than ending the architecture at successful delivery.
4. Separate transport from semantics
Govern terminology, value sets, profiles and mappings independently so that a transport change does not silently change clinical meaning.
5. Test failure deliberately
Assurance should include duplicate delivery, out-of-order events, receiver outage, schema mismatch, partial bulk export and replay, not only happy-path conformance.
6. Measure downstream operability
Track whether clinicians and services can act correctly on exchanged information, not simply whether interfaces remain technically available.
15. Source register
Sources and how they were used.
16. Limitations
What this navigator does not claim.
It is a global architecture aid rather than a jurisdiction-specific implementation guide. Scores are qualitative and should be recalibrated against local estate, supplier capability, national standards, security policy and clinical-safety requirements. FHIR R5 is the current published FHIR release, but many production ecosystems remain based on R4, so version-specific implementation guidance must be checked before design.