Healthcare has never had a single language. Hospitals bill in one coding system, record diagnoses in another, report lab results in a third and prescribe in a fourth. Countries add their own variants. Anyone building analytics, research or AI on health data meets this problem in the first week, and it is fundamentally an ontology problem.
The main terminologies
| Terminology | Used mainly for | Typical role in analytics |
|---|---|---|
| SNOMED CT | Clinical findings, conditions, procedures | Rich hierarchy for clinical meaning |
| ICD-9/ICD-10 and national variants | Diagnoses for billing and statistics | Common in source data; often mapped to SNOMED |
| LOINC | Laboratory tests and observations | Identifies what was measured |
| RxNorm | Medications | Normalised drugs, ingredients and doses |
| CPT4, HCPCS and others | Procedures and services | Common in US claims data |
Medical vocabularies go back centuries; The Book of OHDSI starts with London's Bills of Mortality. Over time each country, system and institution tended to develop its own, which is exactly what makes interoperability and multi-site research hard1.
How OMOP unifies them
The OMOP Standardized Vocabularies consolidate many vocabularies into one common format, refreshed regularly by the OHDSI vocabulary team, and they are mandatory reference tables for every OMOP CDM instance13. Organisations download them from ATHENA, which also offers search across vocabularies; proprietary vocabularies require a licence12.
The key idea is the standard concept. For each clinical meaning, one concept is designated standard and used to record data. The book's example: codes in MeSH, CIEL, SNOMED, ICD-9-CM and Read all describe atrial fibrillation, but only the SNOMED concept is standard; the others are source concepts mapped to it1. Classification concepts, such as MedDRA terms, take part in hierarchies for querying but aren't used to record data1.
Standard designation is decided per domain, not per vocabulary: conditions mainly use SNOMED, measurements SNOMED and LOINC, drugs RxNorm, RxNorm Extension and CVX1. In the book's words, there is no such thing as a "standard vocabulary".
Domains are messier than they look
Every concept is assigned a domain, such as condition, drug, procedure or measurement, which decides which CDM table it lands in. Source vocabularies often mix domains; the book shows that procedure vocabularies like CPT4 and HCPCS contain concepts from several domains1.
Mapping isn't a one-off ETL task. Vocabularies change, concepts are deprecated and remapped, and every refresh can shift results. Version the vocabulary like any other dependency.
Why this matters for health AI
- Features and cohorts depend on it. A model trained on "diabetes" is only as good as the concept set behind it, as in OMOP cohort definitions.
- Portability depends on it. A model built on standard concepts can be validated at another site; one built on local codes usually can't.
- LLMs need grounding. Language models are good at suggesting codes and poor at being reliably right. Constrain them to look up concepts in the vocabulary rather than generate codes from memory, and validate outputs, in the spirit of SHACL validation for knowledge graphs.
- Hierarchies enable better questions. Querying all descendants of a concept finds patients that a flat code list would miss.
For the architecture around the vocabularies, see FHIR to OMOP and OMOP data quality checks.
How I can help
I design health data platforms with terminology and mapping at their core, from OMOP vocabularies to ontologies that make health data usable for AI. See healthcare data architecture and ontology and knowledge graphs, or analyse your challenge and bring the result to a call.
- 1
- 2
- 3Vocabulary-v5.0OHDSI, GitHub
- 4The Book of OHDSIOHDSI