EHR and EPR Migration Architecture: Planning Clinical System Transitions with Sparx EA

An EHR or EPR replacement is the largest, riskiest IT transformation most health organizations ever attempt — and it fails far more often on architecture than on technology. Sparx EA gives clinical and technical architects the dependency map, target-state design, and wave sequencing needed to plan a cutover that holds. This piece walks through how to model the as-is clinical landscape, design the target state, sequence the migration, and keep the program board looking at one source of truth.

No healthcare program carries more risk than replacing a core Electronic Health Record (EHR) or Electronic Patient Record (EPR). It touches every clinical workflow, every integration, and every user in the building. When these programs slip badly — over time, over budget, or into a botched go-live — the cause is almost always the same: the current-state architecture was never understood well enough before the cutover date was set. Undocumented integration dependencies trigger unplanned downtime. Gaps in the data migration scope put patient safety at risk. Decommissioning plans collide with clinical dependencies nobody had written down.

The fix is unglamorous but reliable: document the landscape before you touch it, in a tool built to hold that much complexity. The five sections below are the working sequence we use.

Why EHR migration is an architecture problem

A typical NHS trust or US health system has been running its current clinical systems for ten to twenty years before it embarks on a replacement. In that time, dozens of point-to-point integrations get built — and most go undocumented. HL7 v2 interfaces handle ADT feeds, lab orders and results, radiology orders, e-prescribing, and clinical correspondence. PACS receives radiology orders and returns images. A LIMS (Laboratory Information Management System) receives orders and returns results. Pharmacy handles medication reconciliation. Ward systems take patient-location updates. Communications platforms pull demographics.

Almost none of this is documented comprehensively. The integration engine holds thousands of active channels, many of unknown provenance. Application teams know their own systems but not the full web they sit in. So when the cutover date lands and the old EPR goes dark, the integration failures cascade — and they cascade in production, during clinical hours.

The architectural answer is simple to state and demanding to execute: document everything before you start. That takes systematic effort and a repository capable of carrying the complexity without buckling.

Set a cutover date on top of an undocumented landscape and you are not planning a migration — you are scheduling an outage.

The five-stage migration model

The work breaks into five stages. Each produces a concrete artifact in the repository, and each feeds the next.

A fifth stage runs alongside the rest: keep the model queryable so the program board is governing from live architecture, not a stale status deck. We come back to that below.

Stage 1 — building the as-is clinical landscape

The as-is architecture is built at the Application layer using ArchiMate notation.

Application Components represent each clinical system: the existing EPR (Lorenzo, RiO, Meditech, Cerner Millennium, and the like), the PAS (Patient Administration System, often separate from the EPR in the UK NHS), PACS (Picture Archiving and Communication System), LIMS, e-prescribing, pharmacy, clinical communications, ward management, theatres/PeriOp, outpatient management, community nursing, and mental health systems.

Application Interfaces represent each system's integration endpoints — the HL7 v2 listening ports, REST APIs, and proprietary APIs.

Data Flow relationships connect the interfaces, each labeled with its integration standard and message type (for example HL7 v2.4 | ADT A01, HL7 v2.5 | ORM O01, FHIR R4 | MedicationRequest). Where an integration engine mediates the flow, model it as an intermediate Application Component with serving and using relationships to the source and target systems.

Tagged values on each integration record the message type, direction, frequency (real-time or batch), data sensitivity (does it carry PHI?), the business function it supports, and — critically — the migration status: In Scope, Out of Scope, To Be Replaced, or To Be Retired.

This view becomes the integration inventory of record, shared with the integration team, the EHR vendor, and the program management office. Any integration found in the engine with no known owner is flagged for clinical review rather than quietly carried forward.

Stage 2 — designing the target state

The target state is a second architecture version inside the same repository — often an alternative package, or built with Sparx EA's scenario capability.

The chosen EHR sits at the center, modeled as an Application Component. Its FHIR R4 API is modeled as a set of Application Interfaces — typically Patient, Encounter, Observation, DiagnosticReport, MedicationRequest, AllergyIntolerance, Condition, Procedure, and CarePlan resources.

The surrounding ecosystem — some systems retained, some replaced — is modeled around it:

• PACS: radiology infrastructure is expensive, so most organizations keep their existing PACS. The target integration uses FHIR ImagingStudy resources or DICOM-over-FHIR rather than HL7 v2 ORM/ORU messages.
• LIMS: laboratory systems often stay in place but adopt FHIR DiagnosticReport for result delivery instead of HL7 v2 ORU messages.
• Pharmacy: some EHR vendors (Epic in particular) bundle pharmacy modules; others integrate with standalone pharmacy systems via FHIR MedicationRequest.
• Clinical communications: platforms such as Vocera, Imprivata Cortext, or DrFirst integrate via FHIR or proprietary APIs.
• NHS Spine (UK): PDS (Personal Demographics Service), e-Referral, and EPS (Electronic Prescribing Service) connections are usually required — the EHR must support the NHS England FHIR profiles for them.

Each target-state integration is modeled with the same detail as the as-is landscape: interface, standard, message type, direction. The gap analysis view then compares the two, identifying which integrations must be rebuilt, which migrate as-is, and which are being decommissioned.

Stage 3 — the migration roadmap: work packages and waves

EHR migrations are rarely a single cutover. Most large programs use a wave approach — groups of clinical areas or wards go live in sequence, each wave with its own cutover date, training, and integration cutover.

In Sparx EA's Implementation and Migration layer, each wave is an Architecture Roadmap segment. Within each wave, Work Packages represent discrete units of work:

• Wave 1 Preparation — EHR build, integration engine configuration, data migration ETL development
• Wave 1 Cutover — go-live for Emergency Department and AMU (Acute Medical Unit)
• Wave 2 Cutover — go-live for surgical services and theatres
• Wave 3 Cutover — go-live for outpatients and community services
• Legacy Decommission — retirement of old EPR licenses and infrastructure

Each Work Package links to the Application Components being deployed or retired, the integrations being cut over (from as-is HL7 v2 to target FHIR), the business processes affected at the Business layer, and the predecessor packages it depends on.

That dependency modeling is the real architectural contribution to sequencing. It makes explicit what cannot move until something else is done: theatre systems cannot go live until PACS integration is tested; LIMS integration cannot be retired until the new DiagnosticReport FHIR interface is validated; outpatient systems cannot migrate until the EHR's e-Referral integration (ERS in the UK, Epic Tapestry in the US) is in place.

Stage 4 — integration complexity: HL7 v2 to FHIR cutover

The HL7 v2 to FHIR cutover is where EHR migrations most often hit the unexpected. HL7 v2 messages are nominally standardized but implemented differently by every vendor. Custom Z-segments — local extensions to the standard message format — carry clinically important data that may have no direct FHIR equivalent, and mapping those fields is detailed, time-consuming work.

In the model, Z-segment customizations are captured as tagged values on the integration element, with notes documenting the mapping to FHIR equivalents. Where no direct mapping exists, a Data Constraint element records the gap and the agreed resolution — a custom FHIR extension, a data transformation, or a decision not to migrate that field.

PACS, LIMS, and pharmacy each bring their own complexity:

• PACS: DICOM for the image format, HL7 v2 for the order/result workflow, with the target state often moving to IHE profiles (MWL, MPPS) rather than bespoke HL7 interfaces.
• LIMS: lab systems carry decades of test-code mappings (LOINC, SNOMED, local codes). The migration must document how each local code maps to a FHIR Observation code.
• Pharmacy: medication data is safety-critical. The FHIR MedicationRequest interface has to be validated against clinical pharmacy workflows before cutover, not after.

Each specialist integration area is modeled as a sub-package, with the detail needed to drive technical delivery and support clinical safety assurance.

Stage 5 — a live migration view for the program board

A program running eighteen to thirty-six months generates thousands of decisions, hundreds of work packages, and dozens of integration cutovers. Traditional reporting — weekly spreadsheet updates and hand-built status decks — cannot keep pace with that rate of change.

Because the architecture model already holds the structured data, you can connect it to a BI platform such as Microsoft Power BI and report the program board's dashboard straight from the model:

• Wave completion — percentage of Work Packages complete by wave
• Integration cutover status — how many integrations are on FHIR versus still on HL7 v2
• Dependency health — how many Work Packages have outstanding dependencies blocking them
• System retirement — legacy systems decommissioned versus planned
• Data migration progress — patient records migrated versus total scope

Ask the model "what is blocking Wave 3 cutover?" and you get the specific dependency packages that are not yet complete; ask "which legacy integrations are still active?" and you get the list of HL7 v2 interfaces not yet cut over to FHIR. That is the shift worth aiming for — the architecture stops being an architect's private tool and becomes a governance asset senior clinical and operational leaders use directly.

Frequently asked questions

Where Sparx Services fits

EHR migration programs need architecture, not just project management. We help you build the full clinical system architecture — as-is landscape, target state, migration roadmap, and a live dashboard the program board can act on — so you can manage risk and make decisions with confidence rather than from a status deck.

If you are at the start of migration planning, the fastest way in is to establish the as-is landscape and integration inventory as the foundation: Paralysis to a Plan is built for exactly that. From there, the same model carries you through target-state design and into governance — see how the architecture leaders approach scopes to a program's complexity.