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

An EHR or EPR replacement is among the largest and riskiest IT transformations a health organization will take on, and the risk sits mostly in architecture. 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 covers 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.

Replacing a core Electronic Health Record (EHR) or Electronic Patient Record (EPR) 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 often that 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 to document the landscape before you touch it, in a tool built to hold that much complexity. The sequence below is the working order.

The architect's job on a migration is to say what is running, what depends on it, and what has to move first, and to say it before the date is committed. By hand, that is an integration-engine export, a pile of spreadsheets and interviews with every application team. AI-augmented, the architect decides the scope, the modeling conventions and the sequencing rules, and AI does the mechanics in the tool and the model: loading the interfaces, drafting the data flows, tracing dependencies between waves. The skill is clinical and technical judgment: knowing which dependency is a patient safety risk and checking every draft against the people who run the systems.

Why EHR migration is an architecture problem

A health system that has run its clinical systems for many years before a replacement has usually built dozens of point-to-point integrations, and most of them 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.

Little of this is documented in full. A large integration engine can hold 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 that can carry the complexity.

A cutover date set on top of an undocumented landscape schedules 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 governs from live architecture instead of 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, theaters/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 the migration decision: 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 bundle pharmacy modules; others integrate with standalone pharmacy systems via FHIR MedicationRequest.
• Clinical communications: secure messaging and alerting platforms 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 architect's main contribution to sequencing. It makes explicit what cannot move until something else is done: theater 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 (the e-Referral Service in the UK) 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 long migration program generates thousands of decisions, hundreds of work packages, and dozens of integration cutovers. Weekly spreadsheet updates and hand-built status decks cannot keep pace with that rate of change.

The modern way is to leave status and progress figures out of hand-edited values in the repository. AI connects to the project and portfolio management, IT service management, governance, risk and compliance, and IT financial management systems that already hold them. The architecture model stitches that data to the Work Packages, integrations and systems and shows the relationships, and dashboards in Prolaborate or Power BI present the program board's view:

• 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

The effort is lower, it is easier to maintain, and the insight is always current. 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 HL7 v2 interfaces not yet cut over to FHIR. The architecture stops being an architect's private tool and becomes a governance asset that senior clinical and operational leaders use directly.

Frequently asked questions

What this asks of the architect

EHR migration programs need architecture as much as project management. The architect owns the decisions that make the plan safe: what is in scope, which integrations carry clinical risk, and what has to be proven before each wave goes live. AI does the loading, drafting and checking, and the architect decides what right looks like. If you are at the start of migration planning, Paralysis to a Plan establishes the as-is landscape and integration inventory as the foundation. See also what we do for architecture leaders.