Catalog / Healthcare & Clinical / HLTH-028

Clinical terminology mapping & health-data interoperability (SNOMED CT, LOINC, FHIR, OMOP)

Map local lab codes, diagnosis free text and legacy hospital data to standard terminologies and transform them into FHIR resources or the OMOP CDM, for hospital IT, research data centres and health-data platforms.

Parts needed to run it yourselfAgents & automationLanguage modelSearch & RAG

Hospitals hold decades of data under local codes ("Na-Serum", "Kreatinin_neu") that no other system understands. Embedding- and LLM-based mappers propose standard concepts (SNOMED CT, LOINC, ATC, UCUM), terminologists confirm them, and pipelines then emit FHIR resources or OMOP tables. The benefit is a much shorter mapping backlog, which is what research data centres and EHDS readiness depend on.

Problem & value

  • Today: a hospital lab catalogue has thousands of local test codes; a medication or diagnosis dictionary has tens of thousands of entries. Mapping is manual: a terminologist searches a browser, compares units, specimen and method, and records a decision. Mapping tables go stale with every system change, and each research project re-maps the same codes.
  • AI value: retrieve-and-rerank candidates in seconds, propose the full LOINC axes (component, property, system, method) from a local label plus unit and reference range, pre-fill the mapping table, and leave humans the ambiguous 10-30% (no fixed figure is claimed; measure on your own catalogue).
  • Regulatory pull: the European Health Data Space Regulation (EU) 2025/327 requires interoperable EHR systems and a European exchange format for priority categories (patient summary, ePrescription, lab results, imaging reports, discharge reports) and enables secondary use of health data, with application phased in from 2027 [1]. In Germany the Medical Informatics Initiative (MII) core data set defines FHIR profiles that university-hospital data integration centres (DIZ) must populate [2]. Common-data-model networks (OHDSI/OMOP, EHDEN) need the same harmonisation for federated studies [3].

Variants

  • Lab (LOINC + UCUM): local test code + unit + specimen → LOINC; unit normalisation.
  • Diagnoses and findings (SNOMED CT, ICD-10-GM): free text and post-coordinated expressions.
  • Medication (ATC, RxNorm/OMOP drug vocabulary, IDMP): brand names, dose forms, strengths.
  • FHIR transformation: HL7 v2 / CSV / SQL → FHIR R4 with MII or IPS profiles.
  • OMOP ETL: source tables → OMOP CDM with standard concept IDs.

How it works

  1. source catalogue / data extract
  2. profiling (frequency, units, value ranges, specimen, language)
  3. candidate retrieval (lexical + embeddings over SNOMED CT / LOINC / ATC descriptions)
  4. reranker or LLM judge (axes, units, specimen, laterality; "no match" is allowed)
  5. confidence routing: high
  6. auto-accept sample-audited | medium/low
  7. terminologist review
  8. versioned mapping table (source code, target concept, equivalence, author, date)
  9. transformation (FHIR Mapping Language / OMOP ETL, e.g. HAPI FHIR, Whistle, Rabbit-in-a-Hat)
  10. validation (FHIR profile validator, OHDSI DQD / Achilles)
  11. loading into FHIR server / OMOP DB
  • Retrieval first: the LLM must never invent codes. Candidates come from the licensed terminology release; the model only ranks, explains and rejects. Every output code is verified to exist and to be active in the loaded release.
  • Free text: NER and normalisation of diagnoses (LANG-015) feed the same retrieval step; post-coordination (finding site, laterality, severity) uses an LLM with a SNOMED expression constraint grammar and a terminology server $validate-code check.
  • Human in the loop: terminologists approve mappings; clinicians resolve clinical ambiguity; accepted decisions become training data and few-shot examples.

Data preparation

Source data are local code lists, free-text diagnoses and lab or medication names, plus the target terminologies (SNOMED CT, LOINC, ICD-10-GM, ATC, OMOP vocabularies) and existing mapping tables. They live in the hospital information system, LIS, pharmacy system, Excel files and wiki pages; mappings are often in individual specialists' spreadsheets.

Typical gaps: duplicate and obsolete local codes, abbreviations, missing units, inconsistent languages (German and English), no documented earlier mappings, and licence or access restrictions on terminology releases.

Preparation steps: export the unique local terms with frequency and context (PREP-005); clean and deduplicate them with simple scripts or OpenRefine (PREP-011); load the licensed target terminologies; collect existing expert mappings as a gold standard and a held-out test set (PREP-016, PREP-018); build a synonym and abbreviation list (PREP-015); and agree on a mapping scheme with confidence levels (PREP-019). Related: DATA-003 for master data quality.

Tools: OpenRefine, pandas, an embedding model, a vector database and a spreadsheet for expert review. Terms themselves are usually not personal data, but check free-text fields for patient names (PREP-022). Expect about 30-40 percent of the effort in preparation. See GUIDE-003.

Implementation paths

Which path for whom

  • enterprise: B - hospital groups and vendors need mapping tied to their own data models; cloud LLM and embedding APIs in EU regions work well because terms, not patient records, are sent.
  • developer: C - open embedding models, rerankers and a local LLM (HW2) with an open vector database give full control and reproducibility.
  • public: C - public research and health institutions benefit from sovereign hosting and open components, avoiding lock-in and procurement problems with US clouds.

Path A — Buy (off-the-shelf)

  • Terminology servers and mapping tools: Snowstorm (SNOMED International, open source), Ontoserver (CSIRO), Termite/Snow Owl (B2i Healthcare), John Snow Labs Healthcare NLP with entity resolvers (SNOMED, ICD-10, RxNorm, LOINC),.
  • Interoperability platforms: Smile CDR, InterSystems HealthShare / IRIS for Health, Firely (NL, EU), Medblocks, gematik-aligned FHIR servers, Rhapsody, Health Level Seven integration engines. German vendors: Medatixx, Dedalus (EU), Philips, Siemens Healthineers (EU) for KIS-embedded FHIR.
  • Choose A when: you need a certified integration engine and accept manual mapping with AI suggestions as an add-on.

Path B — Build on cloud APIs

  • Models: frontier LLMs with structured output (Claude, Gemini, GPT, Mistral) in EU regions; embeddings such as OpenAI text-embedding-3, Cohere Embed v4, Mistral Embed, or Voyage.
  • Cloud health services: Azure Health Data Services (FHIR service, DICOM, MedTech; EU regions), Google Cloud Healthcare API (FHIR, HL7v2 ingest, EU locations), AWS HealthLake and Amazon Comprehend Medical (ICD-10-CM / RxNorm / SNOMED CT inference, limited EU region coverage).
  • Pattern: de-identify or pseudonymise first, call the LLM only with the local label, unit and metadata (no patient identifiers), keep the terminology server inside your trust boundary.
  • Choose B when: you have a data engineering team and a signed processor agreement with health-data safeguards (Art. 9 GDPR, national hospital law).

Path C — Self-host (open source)

  • Terminology and FHIR: Snowstorm / Hermes (SNOMED), HAPI FHIR, Firely .NET SDK, Blaze (FHIR server used in MII), Aidbox, Pathling (FHIR analytics), OHDSI tools (Usagi, Athena, Atlas, WhiteRabbit, Achilles, DQD).
  • Models: biomedical encoders such as SapBERT (UMLS entity linking), open-weight LLMs (Llama, Qwen, Gemma, Mistral families, MedGemma) served with vLLM; bge-m3 or e5 embeddings with a reranker; pgvector or OpenSearch for hybrid search.
  • Hardware: HW2 is enough for a 7-14B model plus embeddings on a hospital-sized catalogue; HW3 for larger models or multilingual free-text normalisation.
  • Ops effort: one data engineer plus part-time terminologist; terminology release updates twice yearly.

Path D — Custom training

Fine-tune an embedding or cross-encoder model on your own accepted mappings (typically a few thousand source-target pairs) to improve ranking for German-language and hospital-specific abbreviations. Worth it for large catalogues or recurring multi-site projects (e.g. MII, EHDEN-style networks).

State of the art (2026)

  • Retrieve-and-rerank beats pure generation. Community and research reports on LLM mapping to SNOMED CT, LOINC and OMOP consistently favour embedding retrieval plus reranking over prompting an LLM to emit codes directly, which hallucinates identifiers; verify on your own gold set.
  • Language matters: German and abbreviated local labels reduce accuracy; multilingual embeddings plus a unit/specimen check help. SNOMED CT is licensed; Germany's national release centre distributes it with licence conditions, and LOINC has a German linguistic variant.
  • OHDSI tooling (Usagi, Athena vocabulary) remains the baseline for OMOP mapping, with LLM-assisted mapping now added in research and community tools [3].
  • FHIR generation from tabular sources works well with templates; LLM-written mapping scripts need profile validation and test data before use.
  • Limits: equivalence is graded (exact, narrower, broader); post-coordination and method differences are error-prone; unit conversions must be deterministic, never LLM output; mappings drift with terminology releases and need re-validation.

Shared resources & combinations

  • Same stack (embedding-text, reranker, vector-db, llm-general): HLTH-018 chart search, HLTH-005 coding, HLTH-017 regulatory writing, DATA-003 master-data deduplication.
  • Upstream: LANG-015 information extraction, HLTH-011 discharge letters (structured sections), HLTH-025 nursing documentation (once FHIR-coded).
  • Downstream: HLTH-009 trial patient matching and HLTH-020 risk stratification consume OMOP/FHIR data; HLTH-010 pharmacovigilance needs MedDRA mapping.
  • One terminology service and mapping repository serves all of these.

Effort, cost & KPIs

  • Path A: weeks to license and set up; mapping still manual.
  • Path B/C: 3-6 months for a first domain (lab) including terminology server, evaluation set and review UI; further domains reuse the pipeline.
  • Cost drivers: terminologist review time (largest), SNOMED/LOINC licensing, FHIR server operation, LLM calls (small: one call per distinct code, not per patient record).
  • KPIs: mapping coverage (% of record volume mapped, not % of codes), top-1/top-5 accuracy against a gold set, reviewer minutes per code, share needing expert escalation, ETL data quality scores (OHDSI DQD), FHIR validation error rate, time to onboard a new site.

People & change

Involve management for scope, the data stewards or terminology owners (data-owner) of each source system, the clinical informatics lead (department-lead), and the clinicians or coders who validate mappings. IT and IT security are needed for the vector store and API access; the DPO should confirm that only terms, not patient records, are sent to external services, otherwise a DPIA and processing agreement apply (GUIDE-005).

Works council: usually no, because the tool works on code lists and not on staff behaviour. It becomes relevant (§87(1) no. 6 BetrVG) if reviewer logs are evaluated per person; §90(1) no. 3 still calls for timely information when work processes change, and public bodies inform the staff council (GUIDE-004).

AI literacy: support the reviewing experts with a short introduction to confidence scores, typical errors such as near-miss concepts, and the review workflow (Art. 4 AI Act; GUIDE-006). Pilot with one domain, for example lab codes, measure accuracy against the gold standard, and expand only after sign-off (GUIDE-009). A common concern is that wrong mappings spread silently into analytics and billing; address it by keeping every proposal a suggestion with a human sign-off, versioned mapping tables and sample audits (GUIDE-011).

Risks, regulation & compliance

  • EU AI Act: typically minimal risk; this is data engineering, not a medical purpose. If outputs directly drive diagnosis or therapy decisions or are marketed with a medical intended purpose, MDR software rules (Rule 11) and AI Act Art. 6(1) high-risk may apply [5].
  • GDPR / health data: patient records are Art. 9 special-category data. Mapping catalogues contain no patient data and can use external APIs; ETL on patient records requires a legal basis (care, research under national law, EHDS), pseudonymisation and data-protection impact assessment. Prefer in-house or EU-processed inference for free text.
  • EHDS: EHR system manufacturers must meet interoperability and logging requirements, and secondary-use data holders will have to supply data via health data access bodies [1].
  • Licensing: SNOMED CT affiliate licences, LOINC terms, ATC/WHO and ICD copyright.
  • Risks: wrong mapping silently corrupts research cohorts or clinical alerts; hallucinated or retired codes; unit errors. Mitigations: retrieval-only generation, deterministic unit conversion, gold-set regression tests per terminology release, audit trail of every mapping decision, sampling of auto-accepted rows.

Getting started

  1. Pick one domain (e.g. top 500 lab codes by volume) and build a gold set of 200-300 expert mappings.
  2. Load SNOMED CT/LOINC into Snowstorm or a vector index and measure retrieval recall@10.
  3. Add a reranker or LLM judge with a "no match" option; compare against the gold set.
  4. Build a review UI (or use Usagi) and route by confidence; log every decision.
  5. Generate FHIR or OMOP output for a pilot dataset and run the validators before scaling.

Sources

  1. Regulation (EU) 2025/327, European Health Data Space — https://eur-lex.europa.eu/eli/reg/2025/327/oj
  2. Medical Informatics Initiative Germany, core data set — https://www.medizininformatik-initiative.de/en/core-data-set
  3. OHDSI, Book of OHDSI (vocabularies, Usagi, ETL) — https://ohdsi.github.io/TheBookOfOhdsi/
  4. HL7 FHIR R4 specification and terminology module — https://hl7.org/fhir/R4/terminology-module.html
  5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  6. SNOMED International, Snowstorm terminology server — https://github.com/IHTSDO/snowstorm
  7. Regenstrief Institute, LOINC — https://loinc.org/
  8. HAPI FHIR — https://hapifhir.io/