The shared-language problem

In structured systems, it may also map to different LOINC codes (Logical Observation Identifiers Names) depending on whether it's a standard hemoglobin vs. A1c, the specimen type, the measurement method. Without proper mapping, these can be treated as entirely separate concepts.

This is Capability #2 in building a curated data layer: Not just extracting data, but making sure it speaks a consistent clinical language, per USCDI (US Core Data for Interoperability vocabulary standards).

Because without that, systems duplicate what should be unified, analytics miss what should be obvious, clinical and financial workflows fall out of sync.

Most healthcare data pipelines don't solve this, and they either assume the data already comes clean, or ignores the duplicates.

But in reality, terminology is where fragmentation begins; if you don't fix it here, you carry that inconsistency all the way through the system.

Data Without a Shared Language

Take a simple medication: Metformin, a medication used to treat Type II Diabetes. Across different sources, the related information about Metformin might appear like this:

• In a provider note (unstructured text): "Patient continues metformin 500 twice daily"
• In another document: "Metformin HCl 500 mg BID"
• In a medication list: "Glucophage 500mg" (the brand name)
• In a pharmacy feed: NDC Code for a specific package of Metformin
• In a standardized system: Normalized to RxNorm code for ingredient, clinical drug, or branded drug concept
• And in some cases: Just "Metformin," with no dosage, no frequency, and no code

A properly mapped system can often normalize these different representations to the appropriate RxNorm concept level, allowing related medication data to be grouped and interpreted consistently across sources. When the source includes enough detail, that normalization may resolve to a more specific clinical drug concept. When it does not, the system may only be able to normalize to a broader ingredient-level concept.

Without terminology mapping, these may be treated as different medications (brand vs generic), separate entries (due to formatting differences), or incomplete records (missing codes or structure).

What's missing from most annotations is the standardized clinical code, the identifier that tells every downstream system exactly what that medication is. And that's a problem, because in modern healthcare, data without standardized codes is data that loses meaning.

Interoperability frameworks such as USCDI strongly favor the use of standard vocabularies such as RxNorm, LOINC, SNOMED CT, and ICD-10 in the appropriate contexts. In practice, the more clinical data can be anchored to recognized coding systems, the more reliably organizations can exchange, reconcile, and analyze it across systems.

Most Systems Don't Solve This

Many downstream systems (EHRs, data lakes, interoperability layers, analytics tools) are designed to work best when the incoming data are already structured and coded. In other words, they assume the data already comes clean. They rely on EHR-generated data with embedded codes or HIE feeds that are already standardized.

The challenge with EHR-generated data is that it often arrives in CCDA format, which is XML with extensive tagging. CCDA format is optimized for exchange, but not for querying; it's deeply nested and complex, and querying it relies on understanding and navigating those complexities. In addition, EHR-generated data will often contain PDFs, which are binary files filled with unstructured or semi-structured text that cannot be queried.

The assumption of clean data breaks immediately when you introduce PDFs from prior providers, faxed documents, and free-text clinical notes.

In these cases, the data are rich in description, but they are missing standardized codes. Many systems stop at acquisition of the data and they will either store the data as-is (unstructured, unstandardized), or attempt shallow normalization without true clinical mapping. Ask any physician who has searched a PDF for a lab value embedded in a progress note.

How Predoc's Curated Data Layer Solves for This

At Predoc, terminology mapping isn't a single step, it's a layered system.

1. Code Inferencing: Creating Structure Where None Exists

A large portion of extracted data, especially from documents, does not come with codes. The first challenge is whether we infer the correct clinical code from the available information.

This happens in three steps:

Deterministic Matching: If the data is complete (e.g., medication name + dosage form), it can be matched directly to a known code. This is known as deterministic matching.

Probabilistic / AI-Assisted Matching: If the data is incomplete or inconsistent, the system identifies the best candidates and uses models to determine the most likely match.

Clinical Context Application: In more ambiguous cases, additional clinical context, such as data type, adjacent notes, units, specimen, care setting, etc, are applied to refine the mapping.

Each step builds toward a confidence score, ensuring that only high-confidence mappings are used externally. And importantly, if the system is not confident, it does not invent certainty. This is critical in healthcare, where incorrect data is often worse than missing data.

2. Internal vs External Truth: A Subtle but Critical Distinction

One of the most important nuances in terminology mapping, is that not all inferred data are treated equally.

• High-confidence mappings can be used for interoperability
• Lower-confidence mappings are used internally for data improvement

For example, if a medication is inferred from a document, and the same medication appears in an HIE feed with a confirmed code, the inferred code can be used to identify duplicates and remove redundancy, which improves data quality.

The key principle is not to present low-confidence inferences as if they were source-confirmed facts. Strong systems preserve provenance, distinguish documented values from inferred normalizations, and apply confidence thresholds before using mapped concepts in external workflows. Data aggregators operate as exchangers of information, so any low-confidence clinical code that we infer is used exclusively internally for data enhancement and aggregation purposes.

Terminology mapping powers data aggregation and deduplication behind the scenes, which we will address in our data synchronization capability deep dive.

3. Crosswalks: Translating Between Coding Systems

Even when codes exist, there's another challenge: different systems use different coding standards. For medications alone, you might see NDC (FDA) or RxNorm; for labs, LOINC; and for conditions, ICD-10 or SNOMED.

Terminology mapping must handle crosswalks: translating one coding system into another and normalizing everything to a standard (e.g., RxNorm for medications).

Predoc handles this in two primary ways:

This ensures that data from different sources can be combined, queries return complete results, and it supports interoperability across systems that speak different vocabulary. Without crosswalks, even "coded" data remains fragmented.

Why This Matters Clinically

From a clinical perspective, terminology mapping is about accuracy and completeness. Terminology mapping is the difference between "We think this patient is or was on this medication" and "We know exactly what this patient is taking, across all sources." And when these data are used as part of a curated data set, available not just in the EHR, but also in a data warehouse, its utility to revenue cycle, care management teams, analytics teams, and others within a health organization is amplified.

Healthcare data doesn't just need to be extracted, it needs to be understood in a standardized clinical language. Without terminology mapping, everything built on top, clinical care, analytics, revenue cycle, starts to break. Terminology mapping isn't just a feature. It's the backbone of usable healthcare data.