08 Jul
Key takeaways
- ONC certification tests the EHR software, not the clinical data inside it. Inconsistent LOINC, SNOMED CT, and RxNorm coding is what actually breaks FHIR integrations.
- Mid-size hospitals (150 to 500 beds) carry years of unstandardized data with no dedicated terminology or data governance team to clean it up.
- The three failure points in most FHIR exchanges: inconsistent clinical coding, duplicate or mismatched patient MRNs, and narrative text where coded data should be.
- Unresolved data gaps block payer APIs, distort value-based care metrics, and force manual re-entry at receiving facilities.
- Closing the gap does not require a new EHR. Terminology mapping layers, an enterprise master patient index, and a FHIR facade layer are the practical remediation path.
Why Having a Certified EHR Is Not the Same as Having FHIR-Ready Data: The Standardization Gap Most Mid-Size Hospitals Are Sitting On
A hospital IT director gets a request from a payer wanting patient data through a FHIR API. The director checks the EHR, confirms the system is ONC-certified, and assumes the data will come through in the right format. It does not.
The payer’s team comes back with a problem: patient records arriving with inconsistent identifiers, missing code mappings, and clinical notes in unstructured free text rather than the coded FHIR resources the API was supposed to deliver. The EHR was certified. The data inside it was not ready.
This is the situation a surprising number of mid-size hospitals are walking into right now. Not because their technology teams are not paying attention, but because EHR certification and FHIR data readiness are two different things, and that distinction rarely gets explained until a specific integration breaks.
Table of contents
What EHR certification actually means
ONC certification under the 21st Century Cures Act tells you that an EHR system has been tested against a defined set of technical criteria and can, in principle, support FHIR-based data exchange. The certification covers the software. It does not certify the data inside the software.
Think of it the way you would think about a building that passed a fire inspection. The inspection confirms the sprinkler system exists and was functional on the day of the test. It does not tell you whether the building’s maintenance team has been keeping it in working order, whether the water pressure in that specific wing is sufficient, or whether the pipes are clear. The infrastructure passed. Whether it performs under real conditions depends on what happened after the inspector left.
For hospitals, the equivalent of “what happened after the inspector left” is how clinical data has been entered, structured, and maintained inside the EHR over years of operation. Certification tests the capability of the system. The data quality inside that system is a separate variable entirely.
Where the FHIR-readiness gap actually shows up
Mid-size hospitals tend to sit in a particular position when it comes to data standardization. They are large enough to have accumulated years of patient records, departmental workflows, and vendor integrations, but often without the dedicated data governance and interoperability teams that larger health systems deploy. The result is a set of data quality problems that only become visible when someone tries to use that data in a structured, machine-readable way.
The most common problem is inconsistent clinical coding. FHIR requires that clinical concepts, diagnoses, medications, procedures, lab results, be represented using standard code sets: ICD-10, SNOMED CT, LOINC, RxNorm. A certified EHR supports those code sets. Whether clinicians at a given hospital are actually using them consistently depends entirely on how the EHR was configured and how documentation workflows were set up. Many mid-size hospitals have departments where diagnoses are entered as free text, where lab results use local codes rather than LOINC, and where medication records carry brand names without the RxNorm mapping that FHIR requires. The EHR can produce a FHIR resource from any of that data, but what comes out will not be standardized enough to be usable on the receiving end.
The second common problem is patient identity. FHIR Patient resources require a consistent, reliable patient identifier that downstream systems can match against. In practice, many mid-size hospitals are managing patients whose records contain multiple MRNs from different visits, mismatched demographic fields, and identifiers that do not align with state or payer master patient index records. A FHIR API built on top of that data will produce patient records that receiving systems cannot reliably link to their own member or beneficiary records.
The third problem is document structure. EHRs generate a substantial volume of clinical documentation: progress notes, discharge summaries, care plans, referral letters. In a certified EHR, those documents can be stored and retrieved as CDA documents or converted to FHIR DocumentReference resources. But the clinical content inside those documents is often unstructured narrative text. When a downstream system needs specific coded data from a clinical note, like a structured diagnosis or a medication list in a standard format, unstructured text cannot satisfy that need regardless of which FHIR resource type the document is wrapped in.
Why this is a mid-size hospital problem in particular
Larger health systems have typically invested in dedicated interoperability programs, data governance teams, and clinical terminology management infrastructure specifically because they operate at a scale where data quality problems become expensive very quickly. They have staff whose job it is to ensure that LOINC codes are mapped, that patient identity records are reconciled, and that clinical documentation templates are structured to produce data that downstream systems can consume.
Mid-size hospitals are in a different position. A 200-bed community hospital that implemented its EHR eight years ago and has been running reasonably well with it does not typically have a clinical informaticist managing terminology standards or a team auditing whether local lab codes are being mapped to LOINC at the point of result entry. The EHR works for clinical operations. The question of whether the data it produces meets FHIR quality standards for interoperability is a different question, and one that does not come up until an integration requires it.
The timing of that question has changed. CMS interoperability regulations, value-based care contracts, and payer API requirements are now pushing mid-size hospitals to exchange data in ways that expose the standardization gap. A hospital that could operate for years without addressing clinical terminology inconsistencies is now being asked to deliver FHIR-compliant patient data to payers, ACOs, and care coordination platforms on a regular basis. The gap that was invisible is now blocking operational and contractual requirements.
What the gap costs in practical terms
The most immediate cost is integration failures. When a hospital tries to connect to a payer’s FHIR API or a health information exchange and the data quality does not meet the receiving system’s validation requirements, the integration either fails outright or produces data that the receiving system rejects at the record level. Fixing those failures after the fact, by troubleshooting individual records and tracing errors back to source data problems, takes significantly more time and resources than addressing the standardization issues upstream.
The second cost is in analytics. Mid-size hospitals participating in value-based care contracts are expected to produce population health data that reflects accurate, coded clinical information. When diagnosis coding is inconsistent or medication records are missing standard identifiers, the analytics that ACOs and payers run against that data produce distorted results. A hospital’s quality metrics, risk stratification, and care gap reporting all depend on clinical data being coded consistently in the first place.
The third cost is in patient care continuity. When a patient is referred to a specialist or transitions to a post-acute facility and the transferring hospital sends a FHIR-based care summary with unstructured content or missing code mappings, the receiving provider cannot reliably import that data into their own system. Someone on the receiving end has to interpret and re-enter it manually, which reintroduces the exact problem that structured data exchange was designed to eliminate.
What FHIR-readiness actually requires
Closing the standardization gap does not require replacing the EHR. It requires addressing the data quality issues that the EHR was never designed to enforce on its own, and those issues live in how data was captured and maintained over years of clinical operation, not in which system was used to capture it.
The starting point for most mid-size hospitals is a FHIR readiness assessment that maps current data against what standardized exchange actually requires. Which clinical domains are using standard code sets consistently? Where are local codes in use instead of LOINC or SNOMED? How reliable is patient identity across the MPI? Where is clinical documentation structured versus where is it narrative text? That assessment does not need to take months, but it does need to be specific enough to prioritize remediation work by the domains that matter most for the hospital’s current integration requirements.
Terminology mapping is typically the highest-priority remediation step. When a hospital’s lab results are using local codes, a terminology mapping layer can translate those local codes to LOINC at the point of FHIR resource generation, without requiring clinicians to change how they enter data. The same approach works for diagnosis codes, medication identifiers, and procedure codes. The mapping work is a one-time exercise with ongoing maintenance. Once it is in place, the FHIR resources produced by the system carry standardized codes rather than local identifiers.
For patient identity, mid-size hospitals typically need an enterprise master patient index or a patient matching layer that reconciles duplicate records and assigns a reliable cross-system identifier before data goes out through a FHIR API. This is a data governance step, not a technology replacement, and it has value beyond FHIR compliance because it improves the reliability of the hospital’s own internal data.
For document structure, the most practical approach for most mid-size hospitals is not to restructure years of historical documentation but to improve templates going forward so that new clinical documentation captures structured data where payers and partners need it, while using a FHIR facade layer to expose the data that currently exists in a format external systems can consume.
Where to go from here
The hospitals making the most progress on FHIR readiness in 2026 are not the ones that went looking for a new EHR. They are the ones that did a clear-eyed assessment of what their current data actually looks like when it comes out the other side of a FHIR API, found the specific gaps, and addressed them systematically through terminology mapping, patient identity remediation, and documentation workflow changes.
The EHR certification gave them the capability. What they built on top of that capability is what determines whether their data is actually usable in the interoperability environment they are now operating in. For mid-size hospitals still assuming the certification covers both, that assumption is worth testing before an integration deadline makes the gap impossible to ignore.
FAQs
EHR certification confirms that the software system meets ONC technical standards and can support FHIR-based data exchange. FHIR-ready data means the clinical content inside that system is consistently coded, patient identities are reliably maintained, and the data that comes through a FHIR API is structured and standardized enough to be usable by receiving systems. Certification covers the system. Data readiness depends on how the system has been configured and used.
Hospitals in the 150 to 500-bed range have typically accumulated years of clinical data without dedicated interoperability or data governance teams. Unlike large health systems that invested early in terminology management and patient identity infrastructure, mid-size hospitals often discover standardization gaps only when a specific integration or payer requirement surfaces them.
The most common issues include inconsistent clinical coding, where diagnoses, lab results, and medications are entered with local identifiers instead of LOINC, SNOMED CT, or RxNorm; unreliable patient identity caused by duplicate MRNs and mismatched demographic fields; and unstructured clinical documentation, where narrative text rather than coded data is stored inside FHIR resources.
No. The most common remediation approach involves terminology mapping layers that translate local codes to standard code sets during FHIR resource generation, patient identity reconciliation through an enterprise master patient index (EMPI), and FHIR facade layers that expose existing data in a standardized format without altering the underlying EHR.
A FHIR facade sits between an existing EHR or data system and external FHIR APIs. It translates data from the source system into FHIR resources on demand while applying terminology mappings and data transformations. This allows hospitals to expose FHIR-compliant data to external partners without migrating records or modifying the underlying EHR.
A FHIR readiness assessment is the best starting point. It identifies which clinical domains have standardization gaps, evaluates the reliability of patient identity across existing records, and highlights the specific issues causing failures in current or planned integrations. The result is a prioritized remediation roadmap instead of a broad, undefined data quality initiative.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
