Why Your EHR Data Is Still Locked (and What FHIR Does About It)
FHIR was supposed to unlock healthcare data. For many organizations, it has not—at least not yet. EHR data remains difficult to access, move, and use despite years of regulatory mandates and vendor certifications. FHIR is real progress, but the gap between FHIR compliance and actual data liberation is wider than most technology assessments acknowledge. This article explains why data silos persist and where FHIR actually delivers results today.
Why EHR Data Gets Locked In the First Place
EHR data locks are not accidents. They result from a combination of technical architecture decisions, business incentives, and workflow realities that pre-date FHIR by decades.
- Proprietary data models: Legacy EHRs store data in vendor-specific schemas. Extracting that data requires either vendor cooperation or expensive custom interfaces.
- Interface-based integration: Most existing health IT integrations use HL7 v2 messages sent over point-to-point connections. Each connection is a custom build maintained at ongoing cost.
- Information blocking: Before the 21st Century Cures Act, some EHR vendors and health systems restricted data access as a competitive or business strategy. Penalties now apply, but compliance is not universal.
- Data quality: Even when data can be extracted, inconsistent coding, duplicate records, and missing values make it unusable without significant transformation work.
CMS and ONC Mandates: What They Require and What They Don’t
The CMS Interoperability and Patient Access Final Rule and the ONC 21st Century Cures Act Final Rule together require certified EHR vendors and covered payers to expose standardized FHIR R4 APIs. These rules have moved the industry forward significantly.
What the mandates require: Patient Access APIs must be available. Provider Directory APIs must expose network data. Information blocking is prohibited. EHR certification requires FHIR API support.
What the mandates do not require: They do not require that data be clean, complete, or clinically meaningful when accessed via FHIR. They do not require that all integration use cases be satisfied. They do not require your internal systems to consume FHIR data. Certification is a floor, not a ceiling.
FHIR API vs. Data Feed: Understanding the Difference
| Capability | Traditional Data Feed | FHIR API |
| Access pattern | Batch export (nightly, weekly) | Real-time on-demand query |
| Standard format | Often proprietary or HL7 v2 | FHIR R4 JSON/XML |
| Authentication | VPN, SFTP credentials | OAuth 2.0 / SMART on FHIR |
| Developer experience | Requires HL7/EDI expertise | Standard REST API skills |
| Granularity | Full patient dump | Individual resource query |
| Use case fit | Bulk analytics, reporting | Point-of-care, patient apps, real-time |
Where FHIR Actually Helps Today
FHIR is delivering measurable value in specific, well-scoped use cases. Organizations that target these areas see results. Organizations that treat FHIR as a general-purpose interoperability solution encounter frustration.
- Patient-facing apps: SMART on FHIR enables patient portals and third-party health apps to pull data directly from certified EHRs. This use case is mature and in production at scale.
- Payer-provider prior authorization: FHIR-based prior authorization APIs reduce manual fax-based workflows. CMS Da Vinci project specifications are in active use.
- Care transitions: FHIR-based transition of care documents are replacing C-CDA in many health system networks, reducing integration friction.
- Clinical decision support: CDS Hooks, built on FHIR, enables real-time contextual alerts surfaced within EHR workflows.
- Analytics pipelines: FHIR bulk data export (FHIR Bulk Data Access IG) supports large-scale population health data extraction without custom interfaces.
What Still Does Not Work Well
FHIR does not solve data quality problems. Structured data in a FHIR resource is only as good as the data captured at the point of care. Duplicate patient records, missing diagnoses, and inconsistent coding survive FHIR migration intact.
FHIR does not eliminate EHR vendor fragmentation. Epic, Oracle Health (Cerner), Meditech, and Allscripts all implement FHIR R4 differently. Profile variance, extension use, and CapabilityStatement gaps mean integration testing remains necessary.
FHIR does not replace change management. Clinicians and operations staff still need to change workflows to use data that FHIR makes available. Technical connectivity without workflow adoption delivers no clinical value.
FAQ
My EHR vendor says they support FHIR R4. Does that mean we are interoperable?
Vendor FHIR R4 support means the API exists and is certified. It does not mean your organization has profiled the resources for your workflows, validated data quality, connected consuming applications, or trained staff. Interoperability requires both technical connectivity and operational readiness.
What is information blocking, and does it still happen?
Information blocking is any practice that unreasonably interferes with the access, exchange, or use of electronic health information. The 21st Century Cures Act established penalties up to $1 million per violation for EHR developers and health IT vendors. Complaints are investigated by ONC. While enforcement has increased, self-reported compliance does not guarantee that all restricting practices have been eliminated.
Should we prioritize FHIR or fix our data quality first?
Both are necessary, and they inform each other. FHIR implementation often surfaces data quality issues that were invisible in legacy systems. The most effective approach is to run data quality assessment in parallel with FHIR implementation, using FHIR profiling as the quality framework. Waiting for perfect data before starting FHIR delays compliance and competitive capability.
What Organizations Should Do Now
The gap between FHIR compliance and actual data access is closeable, but it requires deliberate effort beyond EHR certification. Clinovera helps health systems move from certified API availability to production-grade data exchange that delivers clinical and operational value. The starting point is an honest assessment of where your current state creates exposure and where it creates opportunity.
See our clinical Software Engineering & AI Solutions to understand what integration readiness actually requires.
Q2 2026