Written by Technical Team | Last updated 09.10.2026 | 15 minute read
Most health and care technology estates are still shaped by organisational structure. Acute trusts have their EPRs, general practice has its EHR clinical systems, community and mental health providers have theirs, local authorities operate separate social care platforms, and voluntary sector partners often sit outside the main digital architecture altogether.
That arrangement is understandable from a procurement and accountability perspective. Each organisation needs systems it can govern, fund, secure and support. The difficulty appears when the model of care no longer follows the same boundaries.
Integrated neighbourhood teams are a useful example. A person with frailty, diabetes, depression and housing difficulties may be supported by a GP, community nurse, pharmacist, social worker, mental health practitioner, hospital consultant and voluntary sector coordinator. Clinically, that is one care pathway. Digitally, it may be six or seven separate operating environments.
Designing architecture around the provider organisations preserves the fragmentation. Designing it around the model of care produces a different set of requirements.
The starting point is not which systems should integrate. It is what the care team needs to be capable of doing.
A system architecture exercise often begins with an application inventory. Architects identify EPRs, integration engines, shared care records, repositories, portals, identity services and data platforms, then map interfaces between them.
That is useful, but it is too low in the stack to determine the target architecture.
The more productive first question is: what must the model of care support?
For an integrated neighbourhood service, the capabilities might include multidisciplinary coordination, cross-sector referral management, longitudinal care planning, medication review, appointment coordination, case finding, task management, professional communication and continuity tracking.
Those capabilities should be defined independently of the applications currently providing them.
Consider cross-sector referral management. The requirement is not simply that System A can send a referral to System B. A neighbourhood referral capability may need to support:
An architecture based on organisational systems tends to reduce that problem to interfaces between providers. An architecture based on the care capability treats referral management as a cross-system workflow that happens to involve several providers.
That changes the technical design.
The architect can now identify the information objects involved, their authoritative sources, lifecycle states, events and consumers. The discussion becomes less about connecting EPRs and more about how a referral moves through the system.
The same approach applies to shared care planning. A care plan is not simply a document that needs to be visible in several systems. It has authors, contributors, versions, goals, actions, review dates, permissions and state transitions. Different participants may need to update different elements. The patient may need to contribute. Some content belongs in the operational record of an organisation while other content needs to persist independently of any one provider.
Once those behaviours are understood, the application architecture becomes easier to reason about.
A useful sequence is:
care outcome → business capability → workflow → information requirement → application function → integration pattern → infrastructure
This avoids allowing whichever applications happen to be installed today to define tomorrow’s model of care.
It also exposes duplication. If four organisations each maintain separate lists of services, separate care-plan views and separate referral queues, the architectural issue is not necessarily four bad applications. It may be that a system-wide capability has never been designed explicitly.
Shared care records have improved access to information across organisational boundaries, but access to information and coordinated working are different capabilities.
A shared care record typically aggregates or exposes information from several source systems so that an authorised professional can view a broader picture of the person. That is useful for medications, allergies, diagnoses, recent contacts, test results, discharge information and existing care plans.
The limitation appears when the team needs to do something together.
A multidisciplinary team may need to create actions, assign responsibility, track progress, update a plan, close a referral, request another professional’s input or record a decision that changes what happens next. A read-oriented shared record does not automatically provide those workflow semantics.
This is where architecture needs to distinguish between several technical concerns that are often bundled together.
The first is record access. A professional needs to retrieve relevant information from another system. GP Connect is one example of a national mechanism for structured and document-based access to parts of the GP record. Other records may be surfaced through local shared care record platforms, direct APIs, EPR integrations or document exchange.
The second is shared state. Two or more systems need to agree that something currently has a particular status. A referral might be received, triaged, accepted, declined, redirected or completed. A care-plan action might be proposed, active, completed or cancelled.
The third is workflow orchestration. Events in one part of the pathway need to cause action elsewhere. An accepted referral may create a task, trigger an appointment workflow and notify the originating team. A hospital discharge event may require medication reconciliation and community follow-up.
The fourth is write-back. A clinician working in one application may need the result of an action to become part of another organisation’s clinical record. This is technically and operationally more difficult than read access because the receiving system needs to preserve provenance, authorship, semantics and clinical safety.
A sound architecture does not assume that one platform must own all four concerns.
For example, an integrated care pathway could use existing EPRs as the authoritative clinical records, a shared care record for cross-organisational viewing, a separate workflow service for referrals and tasks, and standards-based APIs to propagate relevant events and updates.
That arrangement is often more realistic than attempting to create a single shared application into which every professional must log.
Clinician workflow should influence the integration pattern. If a district nurse works all day in one community EPR, forcing them into a separate neighbourhood portal to update an action is likely to create duplicate documentation or incomplete data. It may be better to expose the shared workflow inside the existing application, or integrate changes back into it.
The long-term architectural aim should therefore be to allow staff to work primarily within their normal operational systems while still participating in shared pathways.
That requires more than data aggregation. It requires APIs and integration contracts that support actions as well as queries.
Integrated care architecture should be designed around care pathways, not organisational boundaries. NHS interoperability is not simply about connecting EPRs, EHRs and shared care records. Effective digital transformation in health and social care also requires shared workflow, referral management, care planning, identity, access control and standards-based APIs that allow multidisciplinary teams to coordinate care across primary, community, acute, mental health, social care and voluntary sector services.
Once the care capabilities have been agreed, the next task is to model the information flows in enough detail that implementation teams can build against them.
A generic statement such as “systems should use FHIR” is not an architecture.
FHIR provides a resource model and exchange framework. It does not determine which organisation owns a record, how conflicting updates are handled, what constitutes the canonical representation of a care plan, when data should be copied rather than referenced, or how a referral state machine should behave.
Those decisions belong in the architecture.
Take medication information. A neighbourhood team may have access to medication data from general practice, hospital prescribing, community services and pharmacy systems. Simply aggregating those records can produce several overlapping representations of the same medicine.
The architecture needs to distinguish between prescribed medication, dispensed medication, administered medication and a clinically reconciled medication list. It also needs rules for identifying source, timestamp, status and provenance.
The user interface may present a consolidated view, but the underlying model should not conceal where each assertion came from.
The same principle applies to care plans. If multiple systems can contribute, the team needs a clear model for ownership.
One option is to designate a system-wide care-plan service as the authoritative source and allow other applications to consume and update it through APIs. Another is to use a federated model in which each organisation retains ownership of its contribution and a shared service assembles a coherent view.
Neither is universally correct.
A central model simplifies querying and concurrency but creates a new critical platform and governance responsibility. A federated model preserves organisational ownership but places much greater demands on interoperability, availability and semantic consistency.
The decision should follow the care model and operational constraints rather than a preference for centralisation or federation.
Event architecture also becomes important. Many cross-organisational workflows are poorly served by repeated polling.
A change in one system should often be expressed as a clinically meaningful event: referral accepted, patient discharged, care plan changed, appointment cancelled, medication altered, person admitted or task completed.
Consumers can then respond according to their responsibilities.
In a more mature architecture, synchronous APIs and asynchronous messaging complement each other. An application may use an API to retrieve the latest state while events communicate that a change has occurred.
This also reduces unnecessary coupling. The source system does not need detailed knowledge of every downstream consumer.
Standardisation should operate at several levels.
FHIR R4 and UK Core can provide a common basis for resource representation where appropriate. SNOMED CT can standardise clinical concepts. NHS Number can provide a common patient identifier where its use is appropriate. Organisational and professional identifiers need equally disciplined handling.
Transport standards alone do not create semantic interoperability. Two systems can exchange perfectly valid FHIR resources while interpreting the underlying concepts differently.
Implementation therefore needs agreed profiles, terminology bindings, cardinality rules, extensions, versioning policies and validation. These should be treated as managed architecture products rather than details left to individual projects.
Cross-organisational care creates another problem: organisational identity models do not map neatly onto shared clinical workflows.
A professional may be employed by one organisation while delivering care as part of a multidisciplinary neighbourhood team involving several others. Their access requirement is determined by the care relationship and their role within the team, not merely by their employer.
Authentication answers who the user is. Authorisation determines what that user can do.
These should not be conflated.
National services such as CIS2 can provide strong authentication for healthcare workers and can support access to services that use national role-based access controls. Local applications may also use Microsoft Entra ID, smartcards, local directories or federated identity providers.
The harder architectural problem is authorisation across the integrated workflow.
A social worker may need access to some elements of a shared plan but not the full clinical record. A community pharmacist may need medicines and allergy information but not unrelated mental health notes. A voluntary sector worker might need assigned tasks and agreed care-plan actions without access to detailed diagnostic information.
A robust model therefore needs contextual access control.
At minimum, the architecture should be able to represent:
Simple organisation-level allow lists are rarely sufficient.
Nor should information governance be implemented as a series of disconnected project approvals. If integrated care is a strategic operating model, the system should establish common rules for data sharing, role-based access, audit, lawful basis and accountability.
This does not mean every organisation relinquishes responsibility for its information. It means the rules for using that information in shared care are agreed once at system level wherever possible.
Audit design deserves particular attention. A cross-system workflow should provide enough information to reconstruct who accessed or changed what, through which application, under which role and for what purpose.
If an update passes through several systems, provenance must survive the journey. The downstream record should not appear to have been authored by an integration engine simply because that was the technical sender.
The clinical author, source system, transmitting system and receiving system are separate concepts and should be represented separately.
Security architecture also needs to account for machine identities. Integrated neighbourhood care depends increasingly on system-to-system APIs, background synchronisation and event processing. Service accounts with broad, static privileges create unnecessary risk.
Workload identity, scoped OAuth permissions, certificate lifecycle management, secrets rotation and explicit API authorisation should be part of the target architecture from the beginning.
The most effective way to introduce this architecture is not to attempt a complete redesign of the regional technology estate.
Start with a care model that already exposes the organisational boundaries.
Neighbourhood care is well suited because its workflows naturally cross primary care, community services, mental health, acute care, social care and the voluntary sector.
Select one pathway with enough complexity to test the architecture but a sufficiently narrow scope to deliver. Frailty, complex multimorbidity or proactive care for people at high risk of admission are typical candidates.
Map the pathway at operational level. Identify where information is created, where decisions are made, what staff need to know, where hand-offs occur and where the same information is repeatedly re-entered.
Then model the capabilities required to improve it.
Suppose the pathway requires a weekly multidisciplinary review. The technical requirements might include cohort identification from population data, access to current records, creation of an agenda, shared care-plan review, action assignment, referral generation and outcome tracking.
That single workflow touches analytics, identity, interoperability, shared records, care planning, task management and governance.
Rather than designing each component independently, implement the minimum architecture needed for the pathway and use it to establish reusable patterns.
The first referral integration should define the standard referral contract. The first cross-system task workflow should establish how task ownership and status are represented. The first shared care-plan update should establish provenance and concurrency rules. The first professional accessing information across organisational boundaries should exercise the agreed authorisation model.
Those patterns can then be reused.
This is also where enterprise architecture and engineering need to remain closely connected.
Architecture documents should describe implementable decisions, not simply principles. Teams need API specifications, sequence diagrams, data contracts, state models, identity patterns, error-handling rules, non-functional requirements and deployment constraints.
If the target model says “standards based by default”, delivery teams need to know which standard, which version, which profile and what happens when the incumbent supplier does not support it.
If the principle is “reuse before buy, buy before build”, someone still needs to determine whether the existing component meets the required capability and integration model.
Architectural governance should be able to make those decisions quickly.
The governance process should also distinguish between principles that are mandatory and those that admit justified exceptions. A legacy system may not expose an open API. A service may still depend on HL7 v2 messaging. A supplier may only support document exchange for a particular workflow.
The sensible response is not to pretend the constraint does not exist. Record the exception, isolate it behind an integration boundary where possible, and prevent the workaround from becoming the architecture for everything else.
Over time, this produces an environment in which organisational systems remain important without defining the shape of the care model.
The GP can continue to use the GP clinical system. The community nurse can continue to use the community EPR. The acute clinician can continue to use the hospital EPR. The social worker can continue to use the local authority platform.
The architecture between them carries the shared capabilities: identity, record access, workflow, care planning, referral state, terminology, events and governance.
That is a more practical interpretation of integrated digital care than attempting to place every professional in the same application.
The organisational boundary does not disappear. Accountability, funding, employment and operational ownership still exist. It simply stops being the default boundary for information and workflow design.
The test for the architecture is therefore straightforward: take a real model of care and follow the patient, professional and information through it. Wherever the clinical workflow crosses an organisational boundary, the digital workflow should continue without requiring the user to reconstruct context manually, repeat data entry or start again in another system.
What clinical safety standards apply to NHS digital architecture and integrated care systems?
Digital health systems used in NHS and adult social care services may need to comply with DCB0129 and DCB0160. DCB0129 covers clinical risk management by health IT manufacturers, while DCB0160 covers the organisations deploying and using those systems. Clinical safety should therefore be considered across the whole integrated care architecture, including interfaces, workflow changes and system upgrades.
How can an Integrated Care Board assess its digital architecture maturity?
ICBs and healthcare providers can use the NHS Digital Maturity Assessment to identify strengths and gaps across areas including smart foundations, safe practice, improving care and supporting healthy populations. Architecture maturity should also consider how easily services can introduce new care pathways, integrate suppliers and share information without major redevelopment.
How can NHS organisations reduce vendor lock-in when designing healthcare architecture?
Reducing vendor lock-in requires more than choosing products that advertise interoperability. NHS technology procurement should secure usable APIs, documented standards, data portability, reasonable integration terms and clear exit arrangements. Open interfaces make it easier to replace individual components without redesigning the entire digital health architecture.
What interoperability requirements should be included in NHS technology procurement?
Procurement requirements should specify the APIs, interoperability standards and terminology services a supplier must support, alongside authentication, audit, performance, testing and version-management requirements. Contracts should also define access to technical documentation, test environments, data extraction and responsibilities when interoperability standards change.
How should healthcare organisations test interoperability before deploying an integrated care pathway?
Interoperability testing should cover complete clinical scenarios rather than checking individual interfaces in isolation. Testing should confirm that data retains its meaning, identity and provenance as it moves between systems, that failures can be detected and recovered safely, and that the end-to-end workflow remains clinically safe when one component is unavailable or produces unexpected information.
Is your team looking for help with enterprise architecture? Click the button below.
Get in touch