An EHR or EPR migration is the largest, most complex IT transformation a health organization undertakes. Sparx EA gives clinical and technical architects the dependency mapping, transition architecture, and live program dashboards needed to plan and govern the cutover safely.
No healthcare IT program carries more risk than replacing a core Electronic Health Record or Electronic Patient Record system. These programs touch every clinical workflow, every integration, and every user in the organization. They fail: or run massively over time and budget: when the architecture is insufficiently understood before cutover begins. Unknown integration dependencies cause unplanned downtime. Legacy data migration gaps compromise patient safety. Decommissioning plans conflict with clinical system dependencies that were never documented. Sparx EA addresses the root cause of EPR migration failure: insufficient architectural documentation of the current state. This article explains how to build the as-is clinical system landscape, design the target state architecture, model the migration roadmap, and use EA GraphLink to give program boards a live dashboard of migration progress.
Key Takeaways
- EPR/EHR migration failure is predominantly an architecture problem: unknown dependencies, undocumented integrations, and incomplete data migration scope.
- Sparx EA models the as-is clinical system landscape at the Application layer, capturing every system, interface, and data flow.
- The target state architecture: chosen EPR plus surrounding ecosystem: is modeled as a separate architecture version with full interface design.
- ArchiMate Work Packages represent migration waves, with dependency links making sequencing logic visible and auditable.
- EA GraphLink connects the Sparx EA migration model to Power BI: program boards see live wave completion, dependency status, and outstanding interfaces.
Why EPR Migration Is an Architecture Problem
The typical NHS trust or US health system that embarks on an EPR migration has been running its current clinical systems for ten to twenty years. In that time, dozens of point-to-point integrations have been built, often undocumented. HL7 v2 interfaces handle ADT feeds, lab orders and results, radiology orders, e-prescribing, and clinical correspondence. PACS systems receive radiology orders and return images. LIMS (Laboratory Information Management Systems) receive orders and return results. Pharmacy systems handle medication reconciliation. Ward systems receive patient location updates. Clinical communications platforms pull patient demographics.
None of this is typically documented comprehensively. Integration engines contain thousands of active channels, many of unknown provenance. Application teams know their own systems but not the full dependency web. When a cutover date is set and the old EPR is switched off, integration failures cascade.
The architectural solution is not complex in concept: document everything before you start: but it requires systematic effort and a tool capable of managing the complexity. Sparx EA is that tool.
Building the As-Is Clinical System Landscape
The as-is architecture is built at the Application layer in Sparx EA using ArchiMate notation.
Application Components represent each clinical system: the existing EPR (e.g., Lorenzo, RiO, Meditech, Cerner Millennium), the PAS (Patient Administration System: often separate from the EPR in UK NHS), PACS (Picture Archiving and Communication System), LIMS, e-prescribing, pharmacy, clinical communications, ward management, theatres/PeriOp, outpatient management, community nursing, mental health systems.
Application Interfaces represent the integration endpoints of each system: the HL7 v2 listening ports, REST APIs, and proprietary APIs.
Data Flow relationships connect the interfaces, labeled with the integration standard and message type (e.g., HL7 v2.4 | ADT A01, HL7 v2.5 | ORM O01, FHIR R4 | MedicationRequest). Where an integration engine mediates the flow, it is modeled as an intermediate Application Component with serving and using relationships to the source and target systems.
Tagged values on each integration record: message type, direction, frequency (real-time / 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 / To Be Retired).
This Application layer view becomes the definitive integration inventory for the migration program. It is shared with the integration team, the EPR vendor, and the program management office. Gaps identified during the landscape-building exercise (integrations that exist in the integration engine but had no known owner) are flagged for clinical review.
Designing the Target State Architecture
The target state architecture is a second architecture version within the same Sparx EA repository: often maintained as an alternative package or using Sparx EA’s scenario capability.
The chosen EPR is modeled as an Application Component at the center of the target state. Its FHIR R4 API is modeled as a set of Application Interfaces: typically including Patient, Encounter, Observation, DiagnosticReport, MedicationRequest, AllergyIntolerance, Condition, Procedure, and CarePlan Resources.
Surrounding ecosystem systems: some retained, some replaced: are modeled around the EPR:
- PACS integration: Many organizations retain their existing PACS (radiology infrastructure is expensive). The target integration uses FHIR ImagingStudy resources or DICOM-over-FHIR rather than HL7 v2 ORM/ORU messages.
- LIMS integration: Laboratory systems may remain unchanged but adopt FHIR DiagnosticReport for result delivery instead of HL7 v2 ORU messages.
- Pharmacy: Some EPR vendors (particularly Epic) include pharmacy modules; others integrate with standalone pharmacy systems via FHIR MedicationRequest.
- Clinical communications: Platforms like Vocera, Imprivata Cortext, or DrFirst integrate via FHIR or proprietary APIs.
- NHS Spine (UK): PDS (Personal Demographics Service), e-Referral, EPS (Electronic Prescribing Service) connections are typically required: the EPR must support the NHS Digital FHIR profiles for these integrations.
Each integration in the target state is modeled with the same detail as the as-is landscape: interface, standard, message type, direction. A gap analysis view compares as-is to target state, identifying which integrations must be rebuilt, which can be migrated as-is, and which are being decommissioned.
The Migration Roadmap: Work Packages and Waves
EPR migrations are rarely executed in a single cutover. Most large programs use a wave approach: groups of clinical areas or wards go live on the new EPR in sequence, with each wave having its own cutover date, training program, 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: EPR 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 is linked to:
- The Application Components being deployed or retired
- The integrations being cut over (from as-is HL7 v2 to target FHIR)
- The business processes being affected (at the Business layer)
- The predecessor Work Packages it depends on
This dependency modeling is the key architectural contribution to migration sequencing. The model makes explicit what cannot be cut over until something else is completed. 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 be migrated until the EPR’s e-Referral integration (ERS in UK, Epic Tapestry in US) is in place.
Integration Complexity: HL7 v2 to FHIR Cutover
The integration cutover from HL7 v2 to FHIR is where EPR migrations most often encounter unexpected problems. HL7 v2 messages, though technically standardized, are implemented differently by every vendor. Custom Z-segments (extensions to the standard message format) carry locally important clinical data that may have no direct FHIR equivalent. Mapping these custom fields is detailed, time-consuming work.
In Sparx EA, Z-segment customisations are captured as tagged values on the Integration element, with notes documenting the field mapping to FHIR equivalents. Where no direct FHIR mapping exists, a Data Constraint element records the gap and the agreed resolution (custom FHIR extension, data transformation, or data that will not be migrated).
PACS, LIMS, and pharmacy interfaces each have their own complexity:
- PACS: DICOM as the image format, HL7 v2 for order/result workflow, with the target state often using 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 must be validated against clinical pharmacy workflows before cutover.
Each of these specialist integration areas is modeled in Sparx EA as a sub-package, with the detail needed to drive technical delivery and support clinical safety assurance.
EA GraphLink: The Live Migration Dashboard
A migration program spanning eighteen to thirty-six months generates thousands of decisions, hundreds of work packages, and dozens of integration cutovers. Traditional program reporting (weekly spreadsheet updates, manually produced status decks) cannot keep pace with the rate of change.
EA GraphLink connects the Sparx EA migration model to Microsoft Power BI. The program board’s migration dashboard draws live data from the model:
- Wave completion status (percentage of Work Packages complete by wave)
- Integration cutover status (how many integrations migrated to FHIR vs still on HL7 v2)
- Dependency health (how many Work Packages have outstanding dependencies blocking them)
- System retirement status (how many legacy systems decommissioned vs planned)
- Outstanding data migration items (how many patient records migrated vs total scope)
Program directors can interrogate the architecture using Copilot or Kernaro: “What is blocking Wave 3 cutover?” returns the specific dependency Work Packages that are not yet complete. “Which legacy integrations are still active?” returns the list of HL7 v2 interfaces that have not yet been cut over to FHIR.
This transforms the Sparx EA model from an architect’s tool to a program governance asset: one that senior clinical and operational leaders can use directly.
FAQ
Q1: How long does it take to build an as-is clinical system landscape in Sparx EA? For a large acute trust with 200+ active integrations, building a comprehensive as-is landscape typically takes six to ten weeks of structured discovery work: integration engine analysis, application team interviews, and model construction. Sparx Services’ Discover engagement provides this as a defined deliverable, including the application portfolio view and integration inventory needed to start migration planning.
Q2: Can Sparx EA help with data migration scope, not just integration architecture? Yes. Data Objects in Sparx EA can represent the key data domains being migrated (Patient Demographics, Clinical Documents, Medication Records, Allergy Records, Results History). Tagged values record the migration approach (full migration, migration from a cutover date, or no migration with legacy read access), the migration tool, and validation status. This creates an auditable data migration scope register within the architecture model.
Q3: How does Sparx EA support clinical safety assurance for EPR migration? Clinical safety assurance for EPR migration (DCB0129 in the UK) requires documentation of clinical hazards and their mitigations. In Sparx EA, clinical hazards can be modeled as Risk elements linked to the relevant Application Components and Business Process elements. Mitigations are linked as Controls. This creates traceability from clinical hazard to the architectural and procedural controls that manage it: directly supporting the Clinical Safety Case.
Q4: How do we handle EPR vendor-provided integration documentation in Sparx EA? EPR vendor integration catalogues (Epic’s Integration Catalog, Cerner’s Integration Profiles) can be imported into Sparx EA as the basis for the target state interface design. Vendor-provided FHIR capability statements are attached as linked documents to the EPR Application Component. Where vendor documentation is incomplete or ambiguous, gaps are recorded as Architecture Decisions with the agreed resolution documented.
Q5: What is the recommended package structure for a migration program in Sparx EA? A typical EPR migration repository contains: (1) As-Is Architecture: the current clinical system landscape; (2) Target Architecture: the EPR and ecosystem target state; (3) Transition Architecture: the wave-by-wave migration sequence; (4) Data Architecture: the data migration scope and mapping; (5) Program Management: Work Packages, milestones, and dependency tracking. Each package can be owned by a different architecture team member with role-based access controls.
Q6: How does Sparx EA connect to the EPR vendor’s own program management tools? Integration between Sparx EA and tools like Microsoft Project (for program scheduling), ServiceNow (for change management), or the EPR vendor’s implementation tracker is achieved through EA GraphLink and standard data export. Tagged values in Sparx EA (milestone dates, work package status) can be synchronized with program management tools to create a single source of truth for program status.
Q7: Can Sparx EA support post-go-live architecture governance after EPR migration? Yes: and this is an often-overlooked benefit of doing the architecture work upfront. After go-live, the Sparx EA repository becomes the architectural baseline for the new EPR environment. Subsequent changes (adding new integrations, extending FHIR APIs, onboarding new clinical modules) are governed through the architecture model. The as-is landscape that cost significant effort to build continues to deliver value as the living architecture record.
Q8: What does a Connect engagement look like for an EPR migration program? Sparx Services’ Connect engagement for an EPR migration program delivers: a complete as-is and target-state Sparx EA model, an EA GraphLink connection to Power BI for a live migration dashboard, MDG configuration for NHS/US clinical systems (including FHIR profile governance), and quarterly architecture reviews through the migration program. Pricing starts at $50,000 depending on program complexity.
Work With Sparx Services
EPR migration programs need architecture, not just project management. Sparx Services’ Connect engagement delivers the full clinical system architecture: as-is landscape, target state, migration roadmap, and live Power BI dashboard: giving your program board the visibility to manage risk and make decisions with confidence.
For organizations starting migration planning, our Discover engagement establishes the as-is landscape and integration inventory as the foundation.
Connect from $50,000 | Discover from $25,000. Contact us to discuss your migration program.