Written by Technical Team | Last updated 08.05.2026 | 22 minute read
NHS trust mergers are never only about organisational design, statutory change or financial integration. They are also, and increasingly, architecture events. When two or more trusts come together, the merged organisation inherits overlapping clinical systems, duplicated workflows, fragmented identity models, inconsistent data definitions and a patchwork of interfaces that were never designed for a unified operating model. At the same time, the merged trust is expected to collaborate more effectively across an Integrated Care System, support shared care record capabilities, improve patient flow, strengthen cyber resilience and give clinicians a safer, more coherent view of the patient journey. That combination of local consolidation and wider system interoperability is exactly why enterprise architecture matters.
For NHS leaders, this is the central challenge: a merger creates pressure to simplify internally while shared care records create pressure to connect externally. One pulls towards standardisation, rationalisation and platform convergence. The other demands openness, interoperability and flexible participation in a multi-organisational care ecosystem. The trusts that struggle tend to treat these as separate agendas. The trusts that make progress understand that merger architecture and shared care architecture are two sides of the same strategic problem. They both depend on clear target-state design, disciplined governance, modern integration patterns, robust information governance and a practical roadmap that can survive operational reality.
The right answer is rarely a simplistic “rip and replace” of everything into a single platform at once, nor is it a permanent tolerance of complexity. The most effective approach sits between those extremes. It uses enterprise architecture patterns to stabilise the merged estate quickly, protect frontline operations, reduce unnecessary duplication and create a route towards a more coherent digital foundation. It also ensures that local decisions about EPRs, departmental systems, identity services and integration layers support shared care records rather than undermining them.
This matters because the architecture decisions made in the first 12 to 24 months of a merger often lock in cost, risk and agility for many years. A trust that converges too slowly can become trapped in duplicated platforms, duplicated support teams and duplicated data quality effort. A trust that converges too aggressively can damage service continuity, overload clinical teams and turn architecture into a source of operational instability. Meanwhile, shared care record participation exposes every weakness in local architecture: poor master data, inconsistent coding, brittle interfaces, unclear data ownership and weak audit design all become visible very quickly once information needs to flow safely across organisational boundaries.
A merger therefore needs more than a technology plan. It needs a deliberately designed enterprise architecture that aligns clinical operating model, application portfolio, data architecture, security architecture and governance. It needs patterns that can be repeated across sites, services and programmes. And it needs to be grounded in the practical reality of the NHS, where legacy estates, constrained capacity, national interoperability expectations and local care priorities all coexist.
The first mistake many organisations make is to define merger success as application reduction alone. Rationalising systems is important, but it is not the same as designing an enterprise architecture. A merged trust can reduce the number of platforms it operates and still fail to create a coherent architecture if it keeps fragmented clinical processes, ambiguous data ownership, inconsistent integration design and weak governance. In practice, the architecture challenge begins with a more fundamental question: what should be standardised across the new organisation, what should remain locally optimised for a period, and what must be exposed to the wider care ecosystem through shared care capabilities?
This is where enterprise architecture adds real value. It provides the mechanism for linking organisational intent with technology choices. In a merger context, that means translating board-level aims such as safer care, improved productivity, reduced variation, better patient flow and stronger collaboration across the ICS into specific architectural decisions. Those decisions include whether the future-state EPR should be single-instance or multi-instance, whether departmental systems should be converged by specialty or by site, whether data should be harmonised into a common information model, and how identity, access control and audit should operate across the merged estate.
Merger architecture should also recognise that NHS trusts do not operate in isolation. Shared care records, national platforms, NHS number identity dependencies, interoperability standards and regional care pathways all shape the target state. If a trust merger is planned as though it only affects internal operations, it will likely end up optimising the wrong thing. The correct target state is usually one in which the trust becomes both simpler inside and easier to connect outside. That means reducing internal duplication while improving its ability to publish, consume and govern interoperable data across organisational boundaries.
A useful way to frame the challenge is to think in layers. At the business layer, the trust is trying to unify pathways, decision rights and service models. At the application layer, it is trying to simplify an inherited portfolio without destabilising care. At the data layer, it must define a trusted view of patients, encounters, clinicians, locations and events. At the technology layer, it needs resilient integration, identity, hosting and cyber controls. If those layers are redesigned independently, the merger becomes slower, more political and more expensive. If they are redesigned as part of one enterprise architecture, the trust has a far better chance of creating a digital estate that supports both operational integration and wider shared care participation.
Another reason strategy matters is that mergers create false urgency. There is usually pressure to demonstrate quick wins, reduce apparent duplication and show visible progress. But when that pressure leads to premature platform choices without enough architectural groundwork, the result is often rework. The trust may choose a target EPR before agreeing data standards, attempt interface migration before settling integration principles, or launch reporting convergence before defining core business terms. Good enterprise architecture does not slow delivery down; it prevents rushed decisions from becoming structural problems.
The most mature organisations therefore begin with architectural due diligence. They assess the current state not only by listing systems but by understanding dependencies, process variation, data lineage, interface patterns, contractual constraints, cyber posture, support models and business criticality. They then define a transition architecture rather than jumping straight to an idealised end state. That transition architecture is critical in the NHS context because trusts cannot pause care delivery while systems are redesigned. Architecture has to create a route from inherited complexity to future coherence, not simply describe the future in abstract terms.
In an NHS trust merger, enterprise architecture is not just about system consolidation. It is the strategic link between EPR convergence, shared care records, interoperability, identity management, data governance and cyber resilience. Trusts that standardise core platforms internally while designing for NHS shared care record integration externally are far more likely to reduce duplication, improve clinician workflow and create a safer, more connected digital estate.
The most effective architecture patterns for NHS trust mergers are those that work in both directions: inwardly for trust consolidation and outwardly for shared care records. Patterns that only solve internal simplification tend to break system-wide interoperability. Patterns that only focus on cross-organisational visibility often leave the merged trust burdened with high-cost internal complexity. The strongest designs do both.
One of the most important patterns is the federated source-of-truth model. In this pattern, the authoritative clinical record remains in the system where care is authored, but relevant information is exposed in a controlled, standards-based way for wider use. This is particularly powerful for shared care records because it avoids pretending that one platform instantly becomes the truth for every domain after a merger. It also respects the reality that, during transition, different services may still use different operational systems. The architectural discipline lies in defining which domains are authoritative where, how data is published, how freshness is managed and how provenance is preserved. For shared care records, provenance is not a technical footnote. Clinicians need confidence in where information came from, when it was updated and which organisation remains responsible for it.
A second essential pattern is the canonical interoperability layer. Merged trusts often inherit dozens or hundreds of point-to-point interfaces, each with local transformations, inconsistent naming conventions and brittle dependencies. That model does not scale in a merged estate and becomes even more fragile when the trust also needs to participate in shared care records. A canonical layer creates a common model for core concepts such as patient, encounter, referral, observation, medication and discharge. Local systems can still vary for a period, but the integration architecture stops every consuming system from having to understand every producer’s local quirks. In the NHS context, this pattern is strongest when aligned with modern interoperability standards and implementation profiles rather than being designed as a private local schema that isolates the trust from the wider ecosystem.
The third pattern is the record locator and context broker model. In many mergers, there is a temptation to centralise every record immediately into a single repository. That can work in specific domains, but it is not always the safest or fastest route. A record locator pattern allows clinicians and systems to discover where relevant information exists and retrieve it when needed, preserving local authority while improving visibility. For shared care records, this pattern is especially valuable because it supports a distributed estate. It is also useful during the merger transition period, when not all legacy platforms can be retired at once. The architectural benefit is that visibility can improve before full application convergence is complete.
The fourth pattern is event-driven integration for operational change. Traditional healthcare integration has often relied heavily on request-response interfaces and batch feeds. Those approaches still have their place, but merged organisations increasingly need architecture that reacts to operational events in near real time: admission, transfer, discharge, referral acceptance, medication change, critical result availability and care plan updates. Event-driven patterns reduce latency, support better flow and create a stronger basis for shared care scenarios in which timeliness matters. They also help decouple systems, which is invaluable when the trust is modernising part of its estate without wanting every downstream application to break.
A fifth pattern is platform standardisation above application diversity. This is particularly relevant in mergers where the trust cannot move every specialty and site onto one application stack at the same pace. Rather than forcing immediate application uniformity, the organisation can standardise the architectural capabilities around those applications. That includes common identity services, common audit, common integration tooling, common observability, common terminology services, common data quality controls and common API governance. In effect, the trust reduces complexity at the platform layer first, which then makes later application convergence safer and cheaper.
The sixth pattern is domain-based convergence. Not every application domain has the same strategic value or migration urgency. Some domains, such as enterprise EPR capability, identity, scheduling, results viewing or document management, may benefit from earlier convergence because they shape the daily experience of clinicians across multiple sites. Others may be better converged later, once the operating model is more stable. A domain-based approach prevents the merged trust from treating every system decision as equally urgent and allows architecture effort to focus where standardisation delivers the greatest clinical and operational return.
The most useful patterns in practice are usually a combination, not a single ideology. A trust may run federated source systems, publish through a canonical interoperability layer, support discovery through record location services, use event-driven messaging for high-value workflows and converge selected domains earlier than others. That combination is often more realistic than a binary choice between total centralisation and permanent federation.
The practical design principles behind these patterns are straightforward:
What makes these patterns so effective in the NHS is that they recognise two truths at once. First, variation across providers and sites is real and cannot always be removed overnight. Second, unmanaged variation is expensive, unsafe and incompatible with scalable interoperability. Enterprise architecture exists to reconcile those truths, not to deny either of them.
EPR convergence is often the most visible and politically sensitive element of a trust merger, but it is rarely the only thing that determines architectural success. A merged organisation can adopt a single EPR and still suffer from fragmented departmental systems, inconsistent location hierarchies, duplicated patient workflows and poor shared-care integration. Equally, a trust can spend years debating the target EPR while leaving obvious data and identity problems unresolved. The more effective strategy is to see EPR convergence as one major component of a broader data and identity architecture.
The first priority is data authority. The merged trust must decide which systems are authoritative for core entities and which are merely consuming, caching or presenting information. This matters because post-merger environments often create shadow data stores and conflicting updates. A clinician may see one version of a problem list in one system, another in a specialty application and a third in a shared care view. Without clear data authority and synchronisation rules, architecture quickly becomes clinically risky. Authoritative ownership must be defined not only for patient demographics, but also for encounters, orders, results, referrals, medications, care plans, staff identities, organisations, locations and service codes.
The second priority is master data management in a practical NHS form. Not every organisation will implement a formal enterprise MDM product, but every merged trust needs MDM disciplines. Patient identity should be anchored consistently, organisational and site structures should be rationalised, location hierarchies should be standardised, reference data should be governed and clinical coding variation should be reduced. Shared care records amplify the need for this because data must be intelligible across organisations, not only inside the trust that generated it. A merger that ignores reference data governance will find itself endlessly reconciling site names, clinic identifiers, order codes and pathway labels when trying to join data up across the new estate.
Identity architecture is equally important. In many mergers, staff continue to work across multiple systems with different authentication methods, different role models and inconsistent access rules. That creates friction, weakens control and undermines clinician confidence. The post-merger target should move towards a more coherent identity and access model in which users can be authenticated reliably, roles are mapped consistently, access is aligned to legitimate relationships and audit is visible across the estate. This is not simply a cyber requirement; it is a clinical usability requirement. If the merged organisation wants clinicians to use shared data safely, access must be easier to govern and easier to understand.
A well-designed identity architecture also supports the wider ICS environment. Shared care records rely on clear assurance about who the user is, why they are accessing data and what they are permitted to see. If the trust’s internal role design is chaotic, its participation in shared care becomes harder to govern. Conversely, when internal identity is disciplined, external interoperability becomes safer and more scalable. That is why identity should sit in the centre of the merger architecture, not on the edge of the security workstream.
Data architecture also needs to separate operational and analytical concerns. One of the recurring problems in post-merger programmes is using reporting repositories as if they were operational integration platforms, or expecting operational systems to serve every analytical purpose without consolidation. A better pattern is to design explicitly for both. Operational interoperability should support timely clinical and workflow needs. Analytical consolidation should support reporting, performance management, service redesign and population-level insight. Where trusts blur these concerns, they often create overloaded platforms and confused governance. Where they separate them properly, they get cleaner architecture and better value from both.
This is also the point at which terminology matters. Shared care records and merged trusts both suffer when clinical concepts are technically exchangeable but semantically inconsistent. It is not enough for data to move. It has to mean the same thing when it arrives. Terminology services, coding discipline and consistent information models therefore become foundational. In architecture terms, semantics is part of interoperability, not an optional refinement.
The trusts that handle this best are usually the ones that avoid framing convergence as a purely procurement-led or vendor-led exercise. Instead, they define the data and identity principles first, then use those principles to shape system decisions. That sequencing matters. If a trust buys or configures its future platforms before deciding how authority, identity, provenance and semantics will work, it often ends up fitting architecture around products rather than using products to enable architecture.
No enterprise architecture for NHS trust mergers is credible unless it deals properly with information governance, cyber security and clinical safety. In fact, these are not constraints on architecture; they are part of architecture. Shared care records, multi-site EPRs and post-merger data flows all depend on lawful processing, clear controllership, secure access, auditable use and safe system behaviour. When those foundations are weak, architecture may look elegant on paper but will fail in delivery or lose stakeholder trust.
The starting point is controllership and accountability. A merged trust must be clear about who controls what data, under what legal basis, for which purpose and with what responsibilities. This becomes more complex, not less, when shared care records are involved because the trust is then participating in a multi-organisational data-sharing environment. Architectural patterns must therefore support governance, not hide it. Provenance, audit trails, role-based controls, privacy notices, objection handling and records management arrangements all need to be visible in the design. A system that shares data but cannot explain accountability is not architecturally mature.
The next principle is minimum necessary access with maximum practical usability. That balance is particularly important in clinical settings. Overly broad access models create governance risk, but overly restrictive designs push clinicians into workarounds, duplicate documentation and loss of confidence. Enterprise architecture should therefore support context-aware, role-appropriate access to information, with strong audit and straightforward review processes. In a merger, this often means replacing inherited local permissions models with something more coherent across the new organisation. In shared care scenarios, it means ensuring that access is grounded in direct care needs and that users can understand why they can see what they can see.
Cyber security patterns also need to evolve in a merged estate. When trusts come together, the attack surface often increases before it decreases. There may be duplicated networks, inconsistent patching, overlapping supplier relationships, inherited legacy applications and variable resilience across sites. At the same time, shared care architectures deliberately widen connectivity. This creates a strong case for zero-trust thinking, network segmentation, stronger identity assurance, service-level monitoring, standardised endpoint management and resilient integration services. Cyber architecture is especially important where legacy systems must remain in place during transition, because they often become the weak link in an otherwise modern design.
Clinical safety deserves equal attention. One of the hidden risks in merger architecture is that interoperability creates an illusion of certainty. Clinicians may assume that because information is visible in a merged or shared care context, it is complete, current and clinically actionable. Architecture therefore has to support safe interpretation. Provenance, timestamps, source attribution, refresh logic, availability indicators and workflow boundaries all matter. A shared care record is highly valuable, but it is not automatically the same thing as a complete operational record in every context. Good architecture helps users understand what they are seeing, how recent it is and what remains the responsibility of the originating system.
Another vital pattern is auditable transparency. In health and care, trust is strengthened when access and processing can be explained. Systems should make it straightforward to investigate who accessed information, under which authority and for what purpose. Merged trusts often discover that their inherited audit capabilities are inconsistent or incomplete. Bringing them into a common model is an architectural priority because it supports governance, cyber investigation, patient confidence and operational control. Audit should not be treated as back-office plumbing. It is part of the trust contract between institutions, clinicians and patients.
The architecture should also account for records management and lifecycle design. Trust mergers tend to focus on live systems, but long-term retention, archive access, legal hold and decommissioning design are equally important. Shared care record architectures are especially sensitive to this because historical information may still need to be visible or locatable even when the source platform is retired. If archival strategy is not designed early, merger programmes often accumulate expensive legacy estates simply because nobody can safely turn them off.
The core governance and safety design questions that every merged trust should answer clearly are these:
When these questions are left unresolved, delivery teams create local answers and inconsistency spreads. When they are answered at enterprise level, architecture becomes repeatable, governable and safer to scale.
The strongest target operating model for a merged NHS trust is not one that promises instant uniformity. It is one that creates disciplined progression from complexity to coherence. That progression usually happens in phases, and enterprise architecture should make each phase explicit. The trust needs a stabilisation phase, a standardisation phase and a strategic convergence phase, all linked to shared care record participation from the start.
In stabilisation, the priority is safe continuity. The merged organisation needs visibility of the application estate, interface dependencies, critical workflows, cyber risk, contractual constraints and support responsibilities. This is also when temporary coexistence arrangements are formalised. Rather than allowing uncontrolled duplication, the trust should define which systems remain in place, which integrations are protected, which data quality issues are highest risk and which identity controls need immediate tightening. Shared care record participation should be reviewed at this stage so that no merger decision accidentally breaks wider interoperability.
In standardisation, the trust begins to reduce variation that adds little or no clinical value. Common identity controls, common integration principles, common terminology governance, common audit design and common platform services should be introduced. This is often the phase where the enterprise architecture function proves its worth, because it turns merger ambition into repeatable standards and reusable design patterns. Clinical engagement is critical here. Standardisation succeeds when it is presented as a route to safer care, lower friction and better information flow, not as an abstract IT simplification exercise.
Strategic convergence comes once the organisation is stable enough to move major domains. This may include a single EPR strategy, specialty convergence, enterprise scheduling rationalisation, order communications consolidation or the retirement of redundant document repositories. By this point, shared care record architecture should already be benefiting from the earlier work: cleaner source systems, better identity, more reliable provenance and fewer bespoke interfaces. Convergence then becomes not just a local simplification move, but a way to strengthen the trust’s role as a dependable participant in system-wide care coordination.
A practical roadmap also needs governance that can take decisions quickly enough to matter. Many post-merger programmes fail not because the architecture is wrong, but because decision-making is diffuse. There needs to be a clear design authority with clinical, operational, digital, data, cyber and information governance representation. That authority should own target-state principles, approve exceptions, manage technical debt and ensure that local projects do not drift away from the agreed architecture. Crucially, it should measure architecture by service outcomes as well as technical milestones. The point is not merely to retire systems. The point is to improve safety, flow, productivity and collaboration.
The trust should also define value in realistic terms. Not every architecture benefit is immediate cash release. Some benefits arrive as reduced duplication, lower incident risk, shorter onboarding times, better interoperability, improved clinician experience and faster service redesign. In the NHS context, those are significant outcomes. The merged trust that can move data more safely, standardise workflows more credibly and connect more effectively with shared care infrastructure is strategically stronger than one that has simply bought a larger set of systems.
Perhaps the most important insight is that enterprise architecture in NHS trust mergers should be treated as a capability, not a one-off project. Shared care records will continue to evolve. National interoperability services will continue to develop. Clinical pathways will continue to cross organisational boundaries. New applications, analytics platforms and automation tools will continue to appear. A merged trust therefore needs architecture practices that persist beyond the merger programme itself. Without that enduring capability, the estate will slowly drift back into fragmentation.
The trusts that do this well tend to share a common mindset. They do not ask whether architecture is necessary; they ask which patterns will help them simplify safely, connect intelligently and change sustainably. They do not treat shared care records as a compliance activity or a viewer project. They understand them as a strategic expression of joined-up care. And they do not assume that mergers are won by selecting one big future platform. They recognise that success comes from creating a coherent architecture across business design, applications, data, identity, governance and transition.
That is why enterprise architecture patterns matter so much in this space. They turn merger complexity into structured choices. They create a bridge between internal convergence and external interoperability. They make shared care records more reliable because they strengthen the local foundations on which shared care depends. And they give NHS leaders a way to move beyond short-term system coexistence towards a more resilient, clinically useful and strategically aligned digital estate.
For NHS trusts facing merger, that is the real opportunity. Not simply to combine organisations, but to design a digital foundation capable of supporting integrated care at trust level, ICS level and, increasingly, across the broader NHS data and interoperability landscape. When architecture is done properly, a merger stops being just a consolidation exercise and becomes a chance to build a more connected, safer and more future-ready health and care organisation.
Is your team looking for help with Enterprise Architecture? Click the button below.
Get in touch