SNOMED-coded findings from clinical text, and mapping AI grounding to FHIR Provenance — Jul 23, 2026
Demo: Clinical Data Transformer — clinical text to a coded FHIR bundle
Giulia Baldini walked through Clinical Data Transformer (CDT), Coforix's pipeline that takes any clinical note, extracts findings, maps them to SNOMED CT codes, and returns a FHIR bundle. Grounding is the core design principle — every extracted finding links back to the exact span of source text it came from, so downstream consumers can trace any coded assertion to the sentence that produced it.
CDT is available in beta at cdt-beta.coforix.ai with API keys on request. A published Implementation Guide (v0.1.0, active June 1, 2026) defines the 5 FHIR profiles and extensions used. The demo ran on a radiology MRI report and extracted 4 confirmed conditions with SNOMED CT codes, each grounded to a source text span.
Demo: Smart Problem List — SNOMED-coded suggestions inside Chipsoft
The Smart Problem List receives a FHIR bundle from an EHR containing a recent clinical letter and the patient's current problem list, then suggests new, known, and non-relevant problems — all coded to SNOMED CT. It's integrated with the Chipsoft EHR and live in a hospital in Antwerp, Belgium. Giulia noted the Belgian government is actively pushing hospitals toward complete, SNOMED-coded problem lists ahead of upcoming EU regulations, which gave the tool its wedge into production.
Two behaviours got the room's attention. First, the tool handles repeated procedures correctly — a second PVI in 2026 is proposed as a new instance rather than collapsed into the PVI already on the list from 2021. Second, non-relevant problems (e.g. incidental osteoarthritis surfacing in a cardiology letter) are routed to a separate "non-relevant" bucket rather than proposed for addition, based on specialty context learned from doctor feedback in the training data.
Is this a clinical decision support system?
Malte Sussdorff pushed on the regulatory question: how does Coforix avoid crossing into medical device / decision support territory? Giulia's answer leaned on grounding. Their QA specialist concluded CDT is not a medical device because the tool only surfaces what's already in the text — it extracts and codes, but never proposes a diagnosis or treatment the doctor didn't already write. That said, Coforix is going through medical-device certification anyway, expected next year, which opens the door to features that would otherwise stay off-limits.
Malte shared how his own team threads the same needle: keep the software framing-only (structure, hooks, integration), let the customer bring the grounding data and the model. In their case, one customer running 500 doctors on one contract benefits from the same-legal-entity carve-out, which sidesteps the medical-device threshold entirely as long as the software isn't distributed outside that entity.
System architecture and the 10-second latency target
The pipeline is multi-turn, not a single LLM call. NER handles the bulk of extraction for speed and cost; an LLM fallback catches what NER misses; a SNOMED CT tool-calling step then codes each finding via semantic similarity against a terminology server backed by custom embeddings. Doctors want results in under 10 seconds from button press, which is tight — especially given a local anonymization step runs before anything leaves the hospital.
Giulia mentioned a future option to let users toggle extended thinking for higher precision, but it's not built yet. The company trained its own Mistral-based LLM on ~2,000 annotated letters for the Dutch use case; training runs take a couple of days.
GDPR, PHI, and where the anonymization happens
Coforix deploys a local anonymization component on the hospital's own machine — a NER model (no GPU required) plus rule-based logic that strips and replaces all PII before data leaves the hospital network. Replacement uses pseudonymization, substituting names with plausible alternatives, so that any missed entity becomes incoherent in context rather than a leaked identifier. Kishore noted real-time PHI feeding into LLMs is a strict concern in the US as well.
Malte Sussdorff offered a complementary approach that works when the doctor already has the patient record open in front of them, and referenced the DID IG that Nikolai Ryzhikov and Health Samurai have been putting together as a useful primitive for identifying which FHIR resources actually need to travel:
When the doctor has the patient record open, the system already knows the patient identity — you can bracket-anonymize the structured FHIR fields (age groups, diagnosis codes) before sending them to whichever LLM the doctor picked, rather than trying to strip PII out of free text after the fact.
Nikolai suggested the natural next step is to wire this pattern into CDS Hooks — a standard trigger that anonymizes patient context and routes it to a decision-support LLM would let hospitals plug in whichever model they trust, without each tool reinventing the anonymization boundary.
Provenance, grounding, and the AI Transparency IG
The group suggested mapping CDT's text-grounding — currently done via custom extensions with index start/end positions — to FHIR Provenance resources instead. Nikolai framed why the mapping matters:
If we make this a self-contained bundle, it can be used for evaluation frameworks — publish the bundle with the original text, and anyone can run their own extractor against it and score against yours.
Gino Canessa flagged the gap in the current standard: FHIR can link a derived resource to a narrative, but there's no standard way to reference a specific span within that narrative. He suggested leaning on the translation IG's work with div/span IDs as a possible path.
Malte proposed a workaround: store the full document as a DocumentReference, then use a matching string (with surrounding context words) plus a Provenance resource to link AI-generated content back to its source. Giulia pushed back on string matching:
Index-based references are more reliable than string matching for long documents — the same string can appear multiple times, and you want the coded finding to point at the exact occurrence.
An AI Transparency IG is entering security ballot on August 14th. It includes an AI Provenance profile, a model card DocumentReference (supporting model card Markdown and Chai versioning), and mechanisms to tag AI-assisted content. Sam Schifman, John Murkey, and May Terry (MITRE) are among the authors. The room suggested Giulia and Malte could contribute — both have practical grounding work that the IG hasn't fully absorbed yet.
Model and embedding choices
For embeddings, Coforix uses OpenAI's large embedding model. They tried training their own but it performed worse, and Dutch medical terms in particular clustered poorly in general embedding space. For NER, they landed on a RoBERTa model pre-trained on Dutch data after trying several alternatives — it outperforms the LLM for Dutch because LLMs lose precision on long documents packed with findings.
For the LLM component, they fine-tuned Mistral 24B (quantized) using Unsloth, a significant jump in quality over Mistral 9B for this task. Gino raised MedBERT and other medical BERTs; Giulia said Coforix tried several but Mistral 24B was the practical winner given language coverage and task complexity.
The group floated the idea of SNOMED International hosting an official SNOMED CT embedding model:
If SNOMED International shipped an official embedding model, everyone building coded extraction on top of the terminology would stop training their own — bring it up at the September workgroup in Bethesda where SNOMED Susie will be present.