Clinia's virtual file system for clinical agents, and 112 lab codes through Astra — Sep 10, 2026
Register to get the calendar and joining links for the weekly calls
One registration covers every upcoming Agents on FHIR call.
Loading your registration…
Don't have an account? Signing in creates one in seconds.
Demo: Clinia's virtual file system for clinical agents
Etienne Soulard-Geoffrion (CTO and co-founder at Clinia) and Gabrielle Lafontaine (director of marketing) walked the group through a product that started twelve months ago as summarisation and chat agents on top of EMRs in Canadian healthcare — and turned into something else entirely once Clinia realised the actual bottleneck.
The actual complexity that we found was not necessarily building those agents, but more around context engineering. How can you put the right context in the context window for the agents to reason accordingly?
The soft launch was a few weeks ago; a sandbox is live now, with production workspaces (with PHI access) coming to the console soon. The demo patient was a digital clone of one they'd been working with — twelve years of data, a FHIR bundle, a stack of CDAs, and a pile of PDFs. Etienne showed why pointing an MCP straight at the FHIR server does not scale: raw data blows the context window, and the duplication and conflicts across sources push agents into hallucination even when the window holds.
Clinia's answer is a data-quality pipeline applied before any agent task. Resources get deduplicated into "facts" (conditions, medications, labs) through four ordered layers: deterministic code matching against terminologies, NLP fuzzy matching and synonyms, embedding similarity for candidate pairs, and — as a last resort — an LLM to adjudicate. On the sample patient the collapse was around 67%, dropping roughly a thousand resources to a fraction of that. Provenance links back to the source of record are preserved through the merge so the agent can jump back to the FHIR server if it needs to.
On top of the clean patient graph they infer relationships FHIR doesn't always carry — an HbA1c lab monitors type-2 diabetes, a medication is linked to a condition — and roll those into templated "condition stories" that show the progression, complications, monitoring labs, and prescribed medications. Etienne stressed the stories are templated, not LLM-generated, so the audit trail survives.
The interface piece is what people asked most about. Clinia projects the patient graph into a virtual file system and exposes it via an MCP server with three tools — browse, read, search — modelled on the primitives coding agents already know how to drive.
We all know that coding agents are very effective at navigating file systems. And so that's where we took the inspiration. By projecting the graph into a virtual file system, the agent then is capable of navigating and fetching the right information.
In practice Markdown outperformed JSON as the file content format, though Etienne said they're still experimenting per task. The next step is role-aware context — a cardiologist would see a different virtual file system than another specialist. Beta feedback from clinician testers flagged one live fix inbound: medication merging is currently too aggressive, and oral vs. IV routes of the same ingredient should be two separate entries. Benchmarking is internal for now — a set of questions across synthetic patient profiles — with plans to publish findings on the Clinia blog.
Ryan Brush called the file-system metaphor "a really cool idea" and mentioned he's been experimenting with a related pattern from a Flexpa blog post that uses SQL on FHIR to render data more token-efficiently.
Guarding against hallucination — provenance and the AI Transparency IG
When Nikolai asked what Clinia does to guard against agent hallucination on generated summaries, Etienne's answer was that they push the problem upstream — data quality first, harness second. The one agent-level lever they use is a validation step at the end done by a second agent, which helps but adds latency.
Nikolai's own trick is to make the agent surface receipts:
I'm asking it to build the provenance. So it should give me back the quotes and links, and then another agent can go and check that these quotes and links are existing ones.
John Moehrke picked up the thread to point at the AI Transparency IG — a FHIR provenance spec for marking any data created or influenced by AI so downstream systems know its origin. Chaining one AI's output through a second AI for validation is itself a legitimate provenance mechanism under the IG, and John's existing YouTube walkthrough covers the details.
Within the AI Transparency IG it's focusing on making sure that anything that's created or influenced by AI is marked in a way that downstream it can be known as having been influenced or marked by AI.
Etienne hadn't seen the IG; Nikolai pointed him at John's video.
Narrative-to-code: 112 lab codes through Astra
Eyal Dviri from Clalit Health Services came off mute to report a live test he'd run that day. He took 112 lab codes — a mix of LOINC and SNOMED — and asked Astra to match them against Clalit's internal codes using a partial mapping they had from earlier research. Roughly 20 came back as confident matches, around 40 as reasonable, and about 50% as poor. He's now handing the rest to manual review.
It's a problem in the real world. It's not the AI problem, it's a human problem first.
Gino Canessa framed the difficulty as one of scope. Embeddings trained on all world knowledge don't distinguish well between fine-grained clinical concepts, and most facilities use local codes that aren't publicly described. Ryan Brush suggested the community build shared eval sets for unstructured-to-clinical-code conversion — the space feels ripe now that LLMs have real tool integration, though he hasn't tested it end-to-end. Nikolai pointed at a recent SDC meetup where teams from BDA Software and CSI demoed voice-to-EHR coding in real time, which is still the hard case.
Ryan noted that basic terminology search works well enough for the top ~1,000 most common LOINC codes but degrades quickly beyond that. Gino added that SNOMED and Regenstrief are now sitting down together to build official SNOMED↔LOINC mappings — done by domain experts, probably AI-assisted internally.
The Argonaut work Gino recently wrapped on writing document references sharpened the same problem in a different direction: a facility rolls up 30 local codes into the one public code it sends out (all technically correct), but the reverse — reading a document in and routing it to the right workflow — can't recover the original mapping from the public code alone. Even with a well-understood space, the ontological knowledge you'd need to reconstruct it lives outside the wire.
Eyal raised terminology servers as the natural place to persist mappings once they're done, pointing at iCuvia and CM Medical. Nikolai brought up the terminology server Health Samurai released — production-grade, roughly 10× faster than Ontoserver, positioned to make concept-map curation and reuse cheaper for teams doing exactly this kind of legacy-code harmonisation.
SNOMED in the AI era
Nikolai's prediction — one worth pushing back on but he stood by it — is that agents change the SNOMED calculus.
With the AI era, I think SNOMED will become the default terminology for most things. You don't need very experienced terminologists to do that anymore. Good skills for agents can help people use SNOMED, and with post-coordination you can express things like COVID even before the code exists.
Ryan raised the licensing concern: LOINC is liberal, SNOMED is country-dependent, and that alone is a real constraint. Nikolai agreed the licence is strange but said if you're lucky enough to live in a country that can use SNOMED, the ontology — internal relationships, properties, subsumption — is exactly the kind of structure agents can reason on top of. The adoption curve is slow because SNOMED predates FHIR and moves at its own pace, but it's growing.
Eyal added the reason coding quality is often poor in practice: clinicians write in free text and don't prioritise codes, so the data problem predates the AI problem.
Frameworks and harnesses — do we still need them?
Clinia builds everything from scratch in TypeScript on Vercel's AI SDK. Etienne's take: frameworks like LangChain created more friction than value, and the AI SDK is the right middle ground between "too opinionated" and "no useful abstractions."
Nikolai went further — the current models are capable enough that heavy harnesses are now slowing progress rather than helping, especially given no framework has solved context compaction well.
Gino disagreed on the record:
I have a whole set of orchestration things that happen so that any one agent has a small task, even if I give it a massive task. I had one running the other day that ran for six days on Sonnet Fast — it didn't hit compaction because none of the agents had to worry about that individually.
Nikolai's counter: Gino's setup works because the individual tasks are small, not because the harness is doing something the model can't. Etienne mentioned in passing that Clinia's approach — the virtual file system with browse/read/search — could plug into Claude Code as a skill, mounted as a file system.
Next meeting, Ryan's stealth exit, and FHIR Camp
Gino proposed a "how are you working" lightning round — five minutes each, everyone shows their tools, harness, and skills. Nikolai wants to slot it into the next meeting.
Ryan Brush revealed he resigned from Google about a week and a half ago; he and a co-founder are building something in the AI healthcare space in stealth, nothing to share yet, hopes to present in a few months. Etienne also wants to come back once Clinia is further into production with a real live use case.
No HL7 work group meeting session is formally scheduled — Gino noted the closest existing slot is the Monday-night implementers roundtable, which sometimes drifts into these conversations. Nikolai reminded the group there's a dedicated day for this at FHIR Camp in Portugal in November.