Onyx Blog
Healthcare Has a Data Translation Problem
Across the conversations we’re having with health plans, states, and technology partners, one issue keeps coming up: healthcare data may be moving more freely, but that does not mean every system interprets it the same way.
Data comes from EHRs, claims systems, labs, pharmacies, public health platforms, and other sources. Even when organizations use standards like FHIR, the underlying information can still arrive with different terminology, mappings, and context.
A diagnosis, lab result, medication, or procedure may be represented differently depending on where it originated. Local codes remain common. Mappings are not always one-to-one. Some concepts do not have a clean match at all.
At small scale, those differences can be handled connection by connection. At network scale, that quickly becomes unsustainable.
A semantic data model provides a common representation that data from different sources can map into and be understood against.
In a FHIR environment, that can be expressed through Implementation Guides, profiles, terminology bindings, and ConceptMaps rather than living in a proprietary data dictionary.
Healthcare already has established vocabularies including SNOMED CT, LOINC, RxNorm, ICD-10, CPT, and UCUM. The challenge is applying them consistently across data coming from many different systems. Licensing adds a further wrinkle: several of these vocabularies carry use restrictions that vary by context: exchanging records, storing mappings internally, or displaying readable descriptions to providers and patients. Those terms need to be accounted for in the model, not discovered later.
Making those mappings computable also means they can be tested and validated.
No semantic model will account perfectly for every piece of healthcare data.
That makes it just as important to identify what doesn’t map cleanly.
FHIR validation and terminology services can help measure mapping success and surface concepts that fall outside the existing model. Those exceptions can then be reviewed, governed, and incorporated as the model evolves.
That is much more scalable than allowing exceptions to disappear into one-off transformation logic.
A shared model also becomes more valuable when it can move across organizations and use cases.
Expressing it as an open FHIR Implementation Guide makes the structure, mappings, and validation rules visible and portable rather than locking them inside a single platform.
That matters because the same clinical information may eventually support prior authorization, referrals, payer-to-payer exchange, quality measurement, value-based care, public health, scheduling, and other workflows.
If every application has to reinterpret the underlying data from scratch, interoperability becomes harder to scale.
Healthcare has made significant progress connecting systems.
The next challenge is making sure the information moving across those connections can be interpreted consistently by the organizations receiving it.
As healthcare moves toward larger connected ecosystems, semantic interoperability becomes less of a back-end technical issue and more of a shared infrastructure requirement.
The industry has made real progress on connectivity. The next step is making sure the data moving across those connections can be interpreted, trusted, and reused consistently.
At Onyx, we’re focused on helping healthcare organizations build that foundation with FHIR, semantic harmonization, and scalable interoperability infrastructure.
