Case Studies
A regional health network operating across 8 hospitals and serving a catchment population in the millions undertook a major Electronic Patient Record (EPR) program: replacing fragmented, legacy clinical systems with a single integrated EPR platform. The program represented one of the most complex and clinically significant technology change programs the network had ever attempted.
When the program began, the network had no enterprise architecture capability, no system inventory, and no documented picture of the integration landscape that a new EPR would need to navigate. The architecture team did not yet exist. The program was scheduled to start wave deployments within 18 months.
Client: Regional health network, 8 hospitals, approximately 15,000 clinical and administrative staff
Challenge: EPR wave deployment without architecture visibility creates clinical risk at go-live
Sparx Services engagement: Discover → Deploy → Connect (22 weeks total)
Outcome: 400+ applications documented, 1,200+ HL7 v2 interfaces mapped, wave readiness dashboard live for program board, Site 1 go-live completed without clinical integration failures
The clinical system landscape across the 8 hospitals had evolved over two decades of independent procurement decisions. Each hospital had its own clinical systems: laboratory information systems, radiology information systems, pharmacy systems, patient administration systems, and dozens of departmental applications: procured at different times, from different vendors, and integrated in different ways.
The total application estate, once inventoried, numbered over 400 clinical applications. Most were undocumented. When program team members needed to understand which system a particular clinical function sat in, or how patient data flowed between systems at a given hospital, the answer required identifying and interviewing the right clinical informatics staff member: a process that took days or weeks, and produced knowledge held in individual heads rather than documented architecture.
HL7 version 2 (v2) messaging was the integration backbone of the clinical system landscape. HL7 v2 is the messaging standard that most clinical systems have used since the 1990s to exchange patient data: admission, discharge, and transfer (ADT) messages, order messages, result messages, and more. The network’s HL7 v2 infrastructure: an integration engine that had been configured and reconfigured over many years: had no current documentation.
Nobody knew how many HL7 v2 interfaces existed. Nobody knew exactly which application pairs were connected by interfaces, what message types those interfaces carried, or which clinical workflows depended on them. The integration engine held the knowledge: but it was not accessible to the program team without significant technical analysis.
An EPR program deploys in waves: replacing the clinical systems at one hospital site, then the next, proceeding through all 8 sites over 18–24 months. At each wave go-live, the old systems are cut over to the new EPR. Clinical staff begin using the new platform for patient care. Integration interfaces between the new EPR and the remaining legacy systems: at adjacent hospitals, in shared services: must work correctly from the moment the cut-over occurs.
A failed integration at go-live in a hospital setting is not an inconvenience. It affects clinical workflows directly: a laboratory result that does not reach the clinician, a medication order that does not reach the pharmacy, a patient admission that does not register across connected systems. The clinical risk is real and serious.
Previous EPR program go-lives at other health networks had encountered exactly these problems: integration failures discovered at go-live, clinical workarounds implemented under pressure, program reputations damaged, and: in the worst cases: patient safety incidents that were partly attributable to integration failures during system cut-over.
The program director understood that proceeding to wave deployment without an architecture baseline was not an acceptable risk. But the program had no architecture team, no EA tooling, and an 18-month clock to the first wave go-live.
The Discover engagement began with a clinical system inventory across all 8 hospital sites. Sparx Services architects worked with the network’s clinical informatics leads, IT managers, and departmental application owners to catalogue every clinical application in the estate.
For each application, the inventory captured: the application name and vendor, the clinical function it supported, the hospital sites it operated at, the application owner and support team, the technology status (supported / approaching end-of-life / already end-of-life), and: critically: the known integration dependencies.
The HL7 v2 integration landscape was assessed by analyzing the integration engine configuration and conducting structured interviews with the integration team. The goal was not yet to produce a complete interface map: that would come in the Deploy stage: but to understand the scale and complexity of the integration landscape, and to assess the network’s readiness for FHIR (Fast Healthcare Interoperability Resources), the modern HL7 API standard that the new EPR platform used.
The FHIR readiness assessment examined: whether the EPR vendor’s FHIR implementation matched the network’s clinical data requirements, which legacy systems had FHIR capability and which would require HL7 v2-to-FHIR translation layers, and which integration patterns (FHIR-native, v2-to-FHIR gateway, point-to-point legacy) would be required for each system in the estate.
The Discover deliverable was a Clinical Architecture Baseline Report: a prioritized view of the clinical system estate, an integration complexity assessment, a FHIR readiness gap analysis, and a recommended approach for the Deploy and Connect stages. The report was presented to the EPR Program Board at week 5: the first time the board had seen a comprehensive view of the system landscape they were deploying into.
The Deploy engagement built the Sparx EA repository that would become the architecture foundation for the program. The repository was designed around an HL7 FHIR MDG: a set of model-driven generation profiles that provided the element stereotypes, tagged values, and diagram templates appropriate for clinical application architecture and FHIR integration modeling.
Application inventory in the repository: All 400+ clinical applications from the Discover inventory were modelled as Application Component elements in Sparx EA. Each application carried tagged values for: clinical function category, hospital sites, application owner, vendor support status, FHIR readiness rating (FHIR-native / v2-only / requires gateway), and EPR program disposition (retain / replace / consolidate / decommission).
HL7 v2 interface inventory: The full HL7 v2 interface inventory: conducted in collaboration with the network’s integration team: was completed during Deploy. 1,247 HL7 v2 interfaces were identified and documented. Each interface was modelled as a Technology Flow in Sparx EA between the application pair it connected, carrying tagged values for message type (ADT, ORM, ORU, etc.), the clinical data it carried, the hospital sites it served, and the EPR program impact (migrate / replace / decommission at wave N).
Wave architecture: The 8-hospital deployment was structured into waves by the program team. The interface inventory enabled wave architecture planning: for each proposed wave boundary, the architecture team could identify which interfaces crossed the boundary (connecting a wave-1 site to a wave-2 site), what clinical workflows those cross-wave interfaces supported, and therefore what integration work was required at each wave go-live to ensure continuity.
FHIR MDG configuration: The Sparx EA MDG was configured with FHIR resource stereotypes: Patient, Encounter, Observation, DiagnosticReport, MedicationRequest: as Application Service elements, enabling the architecture team to model the FHIR capability surface of the new EPR and map legacy interface requirements to FHIR resource patterns.
The Connect engagement deployed EA GraphLink and built the program management dashboard that the EPR Program Board needed to govern wave delivery.
EA GraphLink deployment: EA GraphLink was installed on the network’s Pro Cloud Server infrastructure, connecting the Sparx EA clinical architecture repository to Power BI. The connection was configured to expose the application inventory, interface inventory, and wave architecture structure to the BI layer.
Wave readiness dashboard: The primary Power BI deliverable was the Wave Readiness Dashboard: a live view of each planned go-live wave showing:
Program board access: The Wave Readiness Dashboard was published to the network’s Power BI workspace, accessible to the EPR Program Director, Program Board members, and site clinical leads without requiring any Sparx EA access. Program board members could view wave readiness status in real time, drill into specific interface gaps, and understand the clinical workflow implications of outstanding integration work.
For the first time in the network’s history, the clinical system estate was comprehensively documented:
The Wave Readiness Dashboard changed how the program was managed:
The Site 1 go-live: the first wave deployment, the highest-risk moment of the program: was completed without clinical integration failures. This was the first time in the network’s program history that a clinical system go-live of this scale had been completed without integration-related clinical workarounds in the immediate post-go-live period.
The program team attributed this outcome directly to the interface inventory and wave readiness tracking that the Sparx Services engagement had delivered: every interface dependency was known, tracked, and tested before go-live. There were no surprises at cut-over.
The architecture capability Sparx Services established continued to operate after the engagement concluded. The network’s clinical informatics team: trained to maintain the Sparx EA repository and Power BI dashboard during the Connect engagement: continued to update the interface inventory as wave deployment progressed. The Wave Readiness Dashboard became a standing program governance tool for all subsequent wave go-lives.
> “The Sparx Services team built us an architecture capability we didn’t have and didn’t know we needed. We started the program with no system inventory, no interface documentation, and a go-live schedule that was genuinely frightening. By the time we reached Site 1 go-live, we had complete visibility of every integration dependency: and we used it. The wave readiness dashboard alone saved us from two go-live failures. We’ll use this capability for every wave from here.”
, EPR Program Director (anonymised)
| Stage | Duration | Investment | Key Deliverable |
|---|---|---|---|
| Discover | 4 weeks | $38K | Clinical Architecture Baseline Report: system inventory, FHIR readiness, integration complexity assessment |
| Deploy | 6 weeks | $67K | Sparx EA repository with FHIR MDG, 400+ application inventory, 1,247 HL7 v2 interfaces documented |
| Connect | 12 weeks | $89K | EA GraphLink deployment, Wave Readiness Dashboard in Power BI, program board access |
| Total | 22 weeks | $194K | Architecture capability, complete interface inventory, live program dashboard |
An EPR program that begins without an architecture baseline takes on avoidable clinical risk. The interface inventory that most networks assume exists: often does not. The FHIR readiness picture that vendors present in procurement is rarely the complete truth of the legacy landscape.
A Discover engagement from Sparx Services delivers the clinical system baseline: the inventory, the interface picture, the FHIR readiness assessment: that de-risks your wave planning before it becomes a go-live problem.
Talk to Sparx Services about clinical EA readiness
Discover engagements for clinical programs typically run 4–6 weeks and start at $25K. Connect is the right next step if you need a live program dashboard: typically 10–16 weeks and starting at $50K.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.