Written by Technical Team | Last updated 06.01.2026 | 18 minute read
Integrated Care Systems (ICSs) sit at the heart of modern health and care transformation, bringing together NHS organisations, local authorities, community providers, mental health services, social care, and voluntary sector partners to improve outcomes and reduce inequality. Yet the day-to-day reality is that information still lives in siloes: acute records in one place, community notes in another, social care assessments somewhere else, and crucial context trapped in PDFs, scanned documents, and inboxes. The technical challenge is not simply “moving data around”; it is about enabling safe, timely, and meaningful use of information across different settings, vendors, and clinical workflows.
Software development for ICSs therefore becomes an architectural discipline as much as a coding exercise. You are designing a system-of-systems: multiple sources of truth, overlapping responsibilities, and a constant tension between local autonomy and system-wide consistency. Done well, interoperable architecture supports seamless patient journeys, reduces duplication, unlocks population health insight, and creates a platform for innovation. Done poorly, it produces brittle integrations, inconsistent semantics, and new safety risks.
This article explores how to design interoperable architectures for ICSs using three pillars of health interoperability: HL7 (including established messaging), FHIR (API-first interoperability), and openEHR (clinical modelling for longitudinal records). It goes beyond superficial “standards checklists” and focuses on pragmatic design choices: how to decide what goes where, how to minimise clinical risk, and how to build systems that remain adaptable as services, policies, and suppliers evolve.
Interoperability in an ICS is never a single capability; it is a set of outcomes you need to deliver reliably across many organisations. The most common trap is treating interoperability as a technical endpoint—“we implemented FHIR”—rather than a service capability—“clinicians can see the latest medication changes regardless of where they were made, and we can prove it’s safe and consistent”.
Start by defining the journeys and decisions your interoperability must support. In an ICS context, these often include urgent and emergency care decision-making, discharge and transfer of care, shared care planning, medicines reconciliation, mental health crisis pathways, safeguarding, and coordinated support for people with complex needs. Each pathway has different tolerances for latency, completeness, and ambiguity. A discharge summary arriving a day late is inconvenient; allergy information arriving a minute late can be dangerous.
The next reality is that “patient record” means different things in different settings. Acute systems may focus on episodes and encounters; community services may prioritise caseload and longitudinal narrative; social care may structure information around assessments, eligibility, and packages of support. Interoperability must respect those conceptual differences rather than flatten everything into a lowest-common-denominator dataset. The goal is not to make every system look identical; it is to make key information computable, traceable, and trustworthy across boundaries.
A practical way to express ICS requirements is to think in layers. At the foundation are identity, consent, and provenance. Without consistent ways to match people, manage permissions, and understand where data came from, everything else becomes unsafe. Above that is “clinical safety interoperability”: problems, allergies, medications, diagnostics, and care plans that can be used in care. Above that is operational interoperability: referrals, tasking, bookings, and workflow status. Above that is analytics interoperability: de-identified or controlled datasets that support population health management, performance reporting, and research (where appropriate). Each layer can use different patterns and even different standards, but they must cohere.
Interoperability requirements also have a time dimension. Some data is event-driven (admissions, discharges, medication changes). Some is stateful (current problem list, current care plan). Some is narrative (progress notes). Some is reference data (codes, provider directories, service catalogues). Knowing which category you are dealing with shapes the architecture: event-driven data often benefits from messaging or event streaming, stateful data benefits from APIs and authoritative stores, and narrative may require document approaches with strong metadata and indexing.
Finally, an ICS must balance local flexibility with system-wide governance. You cannot impose a one-size-fits-all data model on every partner overnight, but you also cannot allow each integration to reinvent semantics. The sweet spot is a “minimum viable semantic contract” that grows over time: start with the highest-value, highest-risk domains (identity, medications, allergies, encounters), implement consistent patterns for mapping and provenance, and expand in a controlled way.
Many ICS programmes struggle with a false choice: “HL7 versus FHIR”. In practice, an ICS needs a strategy that embraces both, because the estate is mixed and the use cases are varied. HL7 v2 messaging still underpins large parts of hospital integration and operational workflows, while FHIR has become the dominant approach for modern, API-first interoperability. The key is to avoid building a patchwork where each interface is a bespoke compromise; instead, build a coherent integration strategy where HL7 and FHIR play clearly defined roles.
FHIR works best when you need on-demand access to structured clinical data, consistent resource representations, and a platform for reusable apps and services. It shines for shared care record access, clinical portals, mobile applications, and integration with modern cloud services. Its resource model, search parameters, and extensibility make it suitable for incremental adoption: you can start with a subset of resources and add more over time, while maintaining compatibility through versioning and profiling.
HL7 v2 (and in some contexts HL7 v3 or CDA documents) remains important because many core systems emit and consume it reliably. Admissions, discharges, transfers, orders, results, and scheduling flows often rely on well-understood message types with mature operational tooling. Rather than trying to replace HL7 v2 everywhere, many ICSs use it as an upstream feed, then translate and normalise events into their internal interoperability layer. This approach respects the installed base while enabling modern services to consume consistent APIs.
A robust integration strategy also recognises that interoperability is not just about transporting data; it’s about shaping information into a form that is usable, auditable, and safe. Translation between HL7 v2 events and FHIR resources is not mechanical. You must decide what constitutes an “event” in your domain, how to interpret partial updates, and how to manage conflicts when multiple systems assert competing versions of truth. For example, an HL7 ADT message may imply a patient has moved wards, but it may not convey clinical context. If downstream applications treat that message as definitive without a proper state model, you can create errors in bed management, referrals, and continuity of care.
A practical way to organise the architecture is to separate interface mechanics from clinical meaning. Use an integration layer to handle connectivity, routing, retries, and protocol conversion. Then use a clinical interoperability layer to handle identity matching, terminology alignment, clinical validation, and data lifecycle. This separation prevents “interface logic” from creeping into every consuming application, where it becomes duplicated and inconsistent.
Within that structure, there are several design choices that consistently improve outcomes:
When implementing FHIR in an ICS, profiling matters. “Vanilla FHIR” is intentionally broad; real-world interoperability depends on agreed profiles, value sets, and implementation guides. If each supplier interprets the same resource differently, you get syntactic interoperability but semantic confusion. The goal is not to over-engineer a giant specification upfront, but to converge on a small set of shared profiles for high-value domains and evolve them through governed change.
Security and access control must be embedded in the design. FHIR makes it easy to expose APIs; it also makes it easy to expose too much. An ICS needs a consistent authorisation approach across organisations, typically using token-based access with clear scopes, plus robust auditing. Crucially, access decisions should be aligned to care relationships and legitimate purpose. This is less about technical enforcement alone and more about policy encoded in software: who can see what, under which circumstances, and with which audit trail.
Finally, don’t underestimate operational robustness. Messaging systems and API platforms behave differently under load, failure, and intermittent connectivity. HL7 interfaces often rely on durable queues and acknowledgements; FHIR relies on HTTP patterns and server-side availability. An ICS integration strategy should include retries, idempotency, backpressure, and monitoring as standard. Interoperability that works only in the happy path is not interoperability; it is a demo.
Where FHIR focuses on interoperability at the boundary—data exchange and APIs—openEHR focuses on the internal representation of the clinical record: a vendor-neutral, future-proof structure for storing longitudinal health information. For an ICS building a shared care record or a system-wide clinical data repository, openEHR offers a compelling approach because it separates clinical content models from the underlying software, enabling evolution without constant database redesign.
The core idea in openEHR is the two-level modelling paradigm. The “reference model” provides stable building blocks for health record structures—compositions, sections, entries, observations, evaluations, instructions, actions—while clinical specifics are captured in archetypes and templates. Archetypes define reusable clinical concepts (such as blood pressure, medication statement, or allergy) with constraints, terminology bindings, and structure. Templates assemble archetypes into forms and documents suitable for particular use cases, like an emergency assessment or a long-term condition review.
This separation matters in an ICS because clinical requirements evolve continuously. New service models emerge, policy changes introduce new reporting needs, and partners adopt different systems. A rigid database schema becomes a bottleneck, forcing expensive migrations and creating a backlog of “data model change requests”. openEHR shifts much of that change to clinical modelling, where archetypes and templates can evolve through governance without rewriting core persistence logic.
In practice, openEHR can act as a shared care record store, aggregating data from multiple sources while preserving provenance and context. Rather than simply copying fields into a generic table, you can store richly structured entries that retain clinical meaning. This enables safer reuse: a blood pressure measurement is not just “120/80”; it includes position, method, time, device, and certainty—elements that matter when interpreting the data. The ability to capture narrative alongside structure also supports real-world clinical documentation, which is rarely fully codified.
However, openEHR is not a silver bullet, and it should be adopted with a clear understanding of where it fits. It is excellent for longitudinal clinical data that benefits from deep structure, consistency, and evolvability. It is less suitable as a direct replacement for every operational workflow system. An ICS may still rely on source systems for booking, task management, order entry, and departmental workflows. openEHR becomes a shared clinical information layer, not necessarily the engine of all operations.
A key success factor is clinical modelling governance. Archetypes and templates must be curated, versioned, and agreed in a way that supports both local variation and system-wide alignment. If every organisation creates divergent templates for the same concept, the benefits erode. Conversely, if governance becomes too centralised and slow, teams will bypass it and create workarounds. The best governance models treat clinical modelling like a product: clear ownership, transparent backlog, published release cycles, and strong involvement from clinicians and informaticians.
Integration between openEHR and FHIR is also a practical consideration. Many ICS architectures use openEHR internally for storage and clinical semantics, while exposing FHIR externally for interoperability and app ecosystems. This “openEHR inside, FHIR outside” pattern can work well: openEHR provides deep, vendor-neutral structure; FHIR provides widely adopted exchange formats and API conventions. The mapping between the two must be handled carefully, especially when dealing with versioning, terminology bindings, and differences in representational choices. The aim is not perfect one-to-one mapping for every element, but clinically safe and predictable transformations for agreed domains.
Performance and querying are often overlooked in early planning. openEHR supports AQL (Archetype Query Language), which enables querying by clinical concepts rather than raw tables. This can be powerful for building clinical views and population health queries, but it requires careful indexing strategies, disciplined modelling, and realistic expectations about query complexity. A well-designed openEHR implementation includes curated query patterns, materialised views for high-demand analytics, and a strategy for handling free text and documents in a way that still supports discovery.
Finally, vendor neutrality is not just a contractual benefit; it is an architectural resilience strategy. In an ICS, supplier landscapes change. Organisations procure new systems, merge services, or decommission platforms. A vendor-neutral record layer reduces the risk that your shared care record becomes hostage to a single product roadmap. It also helps with continuity: the clinical meaning of stored information remains stable even as front-end applications evolve.
A well-designed ICS interoperability architecture typically combines multiple patterns, each applied deliberately to a specific type of problem. Trying to force every use case into a single approach—only APIs, only messaging, only a central repository—usually creates friction and gaps. Instead, the architecture should define a small set of approved patterns with clear “when to use” guidance, backed by shared services that make the patterns easy to apply.
One common pattern is the “federated record with smart retrieval”. In this approach, data remains in source systems, and a shared care application retrieves information on demand via APIs, often using FHIR. This reduces duplication and can be faster to implement for certain partners, but it depends on source system availability, consistent authorisation, and acceptable performance. It can also be challenging when you need cross-system analytics or longitudinal aggregation across a fragmented set of APIs.
Another pattern is the “curated shared care repository”. Here, selected data is ingested from sources and normalised into a central store (often using openEHR, a FHIR server, or a hybrid). This supports consistent views, system-wide analytics, and resilience when source systems are offline. The trade-off is that you must manage data freshness, reconciliation, and clear definitions of what the repository is authoritative for. In practice, most ICSs adopt a curated repository for key clinical domains while leaving operational workflows in source systems.
A third pattern is event-driven coordination. Instead of polling for changes, systems publish events—admission, discharge, medication update, care plan change—and subscribers react. This supports timely workflows such as discharge notifications to community teams or updates to care coordinators. Event-driven approaches are powerful, but they demand mature operational controls: durable messaging, idempotent processing, and careful handling of out-of-order events.
Regardless of pattern, the hard part is governance: defining what information means, who owns it, and how it changes. This is where many ICS interoperability programmes fail, not because of technical incompetence, but because semantics and accountability are unclear. “Who owns the problem list?” “Which allergy record is trusted?” “How do we handle conflicting medication histories?” Without clear answers, developers end up encoding assumptions, and those assumptions become invisible clinical risk.
A strong governance approach includes explicit data ownership models. For each domain, identify the likely sources of truth, the acceptable secondary sources, and the reconciliation rules. For example, you might treat a GP system as the primary source for repeat medications, while hospital systems contribute acute prescribing events. The shared care record then presents a reconciled medication view, clearly indicating provenance and timestamps. Clinicians should be able to understand what they are seeing without needing an engineering explanation.
Security by design must be baked into every layer. In an ICS, you are dealing with sensitive information across organisational boundaries, and trust is earned through consistent controls and transparency. Access control should be policy-driven and auditable, with a clear separation between authentication (who someone is), authorisation (what they are allowed to do), and clinical context (why they are accessing it). Audit logs should capture not only the fact of access, but the purpose and the data domains accessed, so inappropriate access can be detected and investigated.
There are a few architectural capabilities that repeatedly prove essential in ICS shared care record programmes:
A pragmatic architecture also includes a clear approach to documents and unstructured content. Not everything will be structured, and forcing structure prematurely can slow delivery. Instead, treat documents as first-class artefacts with metadata, indexing, and linkage to structured data where possible. A referral letter, a discharge summary, and a safeguarding note can be discoverable and clinically useful even if they remain narrative, provided the system supports search, filtering, and context.
Finally, interoperability architectures must be designed for change. New partners will join. New pathways will be prioritised. Systems will be upgraded or replaced. The architecture should minimise “hard wiring” integrations and maximise configurability through profiles, mappings, and shared services. Versioning is crucial: version your APIs, version your profiles, version your templates, and provide migration paths. In an ICS, long-lived interoperability is a product that evolves, not a project you finish.
An interoperability platform is only as good as its operational maturity. In an ICS context, reliability is not a nice-to-have; it is intertwined with clinical risk and service continuity. That means software development must extend beyond feature delivery into disciplined engineering practices: automated testing across standards, robust deployment pipelines, and continuous monitoring that can detect data quality issues as well as system outages.
Testing interoperability is uniquely challenging because failures can be subtle. An API may respond correctly but return incomplete data due to an upstream mapping issue. A message flow may be processed successfully but interpreted incorrectly because of terminology mismatch. A record may look correct on screen but lack provenance, making it unsafe for clinical use. To manage this, treat interoperability testing as multi-layered: contract testing for interfaces, semantic testing for mappings, scenario testing for pathways, and operational testing for resilience.
For FHIR implementations, automated validation against agreed profiles should be part of the pipeline. If your ICS uses a set of constrained resources, every build should validate payloads against those constraints. This reduces drift and prevents “almost-FHIR” responses from creeping into production. For HL7 ingestion, include parsers and validators that can detect non-conformant segments and enforce routing rules. For openEHR, validate templates, enforce archetype constraints, and maintain a controlled library of clinical models to avoid silent divergence.
Performance engineering deserves special attention because ICS interoperability platforms often become shared infrastructure for many products. A shared care record portal, a clinical decision support service, and a population health dashboard may all rely on the same APIs. If you design without realistic load patterns, you risk building a platform that works for a pilot but collapses at scale. Performance is not only about response times; it includes throughput, concurrency, and the ability to recover under failure without data loss or corruption.
Operational observability must be both technical and clinical. Technical monitoring covers latency, error rates, queue depth, and resource utilisation. Clinical observability covers data quality: missing allergies, delayed discharge notifications, sudden drops in event volumes from a particular hospital, or abnormal spikes in identity mismatches. Building dashboards and alerts around these signals turns interoperability into a managed service rather than a black box.
Release management in ICS environments should be cautious but not paralysed. The temptation is to treat interoperability platforms as too sensitive to change, leading to infrequent releases and large, risky deployments. A better approach is frequent, small releases with strong automated testing, feature toggles, and clear rollback strategies. Changes to clinical semantics—such as mapping updates or profile changes—should be treated with the same seriousness as code changes, including peer review, staged environments, and sign-off where appropriate.
Clinical safety is a core discipline, not a document at the end. Software development for health and care must incorporate hazard identification, mitigation planning, and traceability from requirements to implementation and test evidence. In an interoperability context, hazards often come from misinterpretation, duplication, and stale data. For example, presenting two medication lists without clear provenance can lead to double dosing; failing to show the timestamp on an allergy update can lead to incorrect assumptions. Addressing these hazards means designing the user experience and data model together, not separately.
Data migration and onboarding are often underestimated. An ICS will rarely start with perfect feeds and complete coverage. Early phases involve partial datasets, inconsistent coding, and variable partner readiness. The platform should support gradual onboarding with clear data completeness indicators, partner-specific configuration, and tooling to diagnose integration issues quickly. A “partner onboarding kit” that includes test harnesses, reference implementations, and clear acceptance criteria can dramatically reduce time-to-live for new integrations.
Finally, invest in developer experience. Interoperability platforms become ecosystems: internal teams, suppliers, and partners all need to integrate. Provide clear API documentation, sandbox environments, synthetic datasets, and examples that reflect real clinical scenarios. Good developer experience is not cosmetic; it reduces integration defects and shortens feedback loops, which directly improves safety and reliability.
A mature operating model treats the interoperability platform as a living product with measurable outcomes: reduced duplication, faster discharge coordination, improved medicines reconciliation, better continuity for complex needs, and safer handovers. The standards—FHIR, HL7, openEHR—are powerful tools, but the real value comes from how you combine them into an architecture that respects clinical reality, supports governance, and can evolve at the pace of an ICS.
Is your team looking for help with healthcare software development? Click the button below.
Get in touch