From Legacy HL7 to FHIR R4 in 90 Days: What One Health System Actually Learned

This is an account of a real FHIR R4 implementation delivered by Clinovera for a regional health system. Identifying details have been changed. The timeline, blockers, data quality issues, and outcomes are reported as they occurred. The purpose is not to present a marketing narrative—it is to give organizations considering a similar migration an accurate picture of what the work actually involved.

The Starting State

The health system operated two primary EHR platforms—Epic for inpatient and a third-party ambulatory EHR for physician practices—with a legacy integration engine routing HL7 v2 ADT, lab results, and medication orders between them. Patient data was siloed between the two platforms, creating care coordination friction, duplicate documentation, and medication reconciliation errors at transitions of care.

The immediate driver was a compliance deadline: the organization needed to expose a certified FHIR R4 Patient Access API before a CMS audit window. The secondary goal was to use the FHIR infrastructure to enable a new care transitions application for high-risk patients moving from inpatient to ambulatory care.

Existing FHIR readiness was minimal. Epic had FHIR R4 API support enabled but not configured for external access. The ambulatory EHR had limited FHIR support with known data completeness gaps. The integration engine had no FHIR capability. The internal team had limited FHIR experience and no clinical informatics staff.

The Phased Migration Approach

Phase 1: Discovery and Architecture (Days 1–21)

The first three weeks were spent on EHR API assessment, workflow discovery for the care transitions use case, and architecture design. The discovery phase produced findings that materially changed the technical approach.

• Epic FHIR API assessment revealed that the CapabilityStatement declared support for 18 resource types, but only 12 were returning complete data for the use case scope. Six resource types had known Epic configuration gaps that required Epic support engagement.
• Ambulatory EHR FHIR assessment revealed that the vendor’s FHIR R4 support was limited to Patient, Encounter, and Condition resources. Medication and AllergyIntolerance resources required HL7 v2 extraction and transformation.
• Clinical workflow discovery identified that care coordinators needed medication reconciliation data, problem list data, and upcoming appointment data at the point of care transition—not a full patient summary document.
• Data quality baseline found a 12% duplicate patient rate across the two EHR platforms and significant coding inconsistency in the ambulatory problem list data.

Phase 2: Integration Build and Data Validation (Days 22–70)

The build phase proceeded resource type by resource type, with continuous data quality validation. The compliance target (Patient Access API) and the care transitions use case were built in parallel tracks.

The most significant blocker was Epic’s FHIR API configuration for the Medication resource. Epic’s MedicationRequest resource population required activation of specific FHIR configuration settings in Epic’s environment. This required Epic support escalation and took 11 business days to resolve—a delay that was not in the initial timeline.

The ambulatory EHR transformation required building a custom FHIR transformation layer in the integration engine to convert HL7 v2 RDE messages to FHIR MedicationRequest and AllergyIntolerance resources. This took 8 days of integration engineering and 5 days of clinical validation.

Data quality remediation addressed the duplicate patient issue using a probabilistic patient matching algorithm. The 12% duplicate rate was reduced to under 2% before go-live through a combination of automated deduplication and manual review of high-confidence match candidates.

Phase 3: Go-Live and Post-Go-Live (Days 71–90)

The compliance deadline was met. The Patient Access API passed ONC test criteria and was live before the audit window. The care transitions application went live on day 85 with a pilot cohort of 12 care coordinators.

Post-go-live monitoring identified two data quality issues that had not surfaced during validation: a timezone handling error that caused appointment data to display incorrectly for patients in a different timezone than the server, and a coding inconsistency in ambulatory diagnosis codes that caused 8% of problem list entries to fail terminology validation.

Both issues were identified within 72 hours through the monitoring dashboard and resolved within 5 business days. Neither caused clinical harm, but both would have been more difficult and more expensive to discover and fix if monitoring had not been in place.

What Was Skipped—and What It Cost

Under timeline pressure, the team elected not to complete a full data quality assessment of the ambulatory EHR before starting the integration build. This decision was made with awareness of the risk. The timezone and coding issues that surfaced post-go-live were likely within the scope of a complete pre-build assessment. The fix cost approximately 2 days of engineering time.

The team also elected to defer the mobile patient application that was in the original scope. Delivering the care transitions application on a 90-day timeline required focusing build capacity on the integration layer. The mobile application was moved to Phase 2 of the program.

What Actually Mattered Most

In retrospect, three decisions drove the outcome more than any other:

• Doing the clinical workflow discovery before scoping the technical build. The finding that care coordinators needed three specific data elements—not a full patient summary—reduced the build scope significantly and allowed the 90-day timeline to be achievable.
• Building the Epic FHIR API configuration issue discovery into Week 2 rather than finding it at integration testing. Early discovery of the Medication resource gap allowed 11 days of Epic support engagement to run concurrently with other build work rather than blocking it.
• Implementing post-go-live monitoring before go-live. The data quality issues that surfaced post-go-live would have been discovered through clinical complaints rather than technical monitoring—a slower, more disruptive, and more trust-damaging discovery process.

Outcomes Delivered

• Patient Access API live and ONC-certified before the compliance deadline
• Care transitions application in use by 12 care coordinators within 90 days
• Medication reconciliation time at care transitions reduced by approximately 35% for pilot users (measured at 30 days post-go-live)
• Duplicate patient rate reduced from 12% to under 2%
• Foundation FHIR architecture in place to support Phase 2 mobile patient application and analytics use cases

What Organizations Considering a Similar Migration Should Know

Ninety-day FHIR R4 implementations are achievable for well-scoped use cases with active EHR vendor cooperation and a clear clinical use case. They are not achievable when scope is undefined, EHR configuration work is underestimated, or data quality problems are discovered at go-live rather than during build.

The most important investment in a compressed timeline is the discovery phase. Organizations that want to move fast should invest most heavily in the first three to four weeks of structured discovery, not in build velocity.

Contact Clinovera to discuss how a production-first approach would apply to your organization’s FHIR timeline and EHR environment.

June 2026