A generic MCP for any FHIR R4 EMR, and a synthetic-hospital analytics stack — Apr 16, 2026
MCP glue between any agent and any FHIR R4 EMR
Hari's MCP server is written in Go on Anthropic's official SDK, talks to any FHIR R4 endpoint over token auth, and runs either locally in STDIO mode or hosted. He was explicit that he did not build the AI layer at all — the thing is glue between agents and EMRs, so Claude Desktop, Goose, Gemini or anything else MCP-compatible plugs into the same server.
40 clinical skills — elaborated prompts grounded in guidelines
Rather than an agent improvising "give me the patient's labs", a skill is an elaborated prompt grounded in clinical guidelines — so you ask for a renal function dashboard and get a structured workflow.
I'm not a clinician myself. I'm leaning on the guidelines the skills were written from.
MCP apps — server returns a React component alongside data
Hari's patient chart review app rendered labs, conditions, medications and vitals inside the desktop client. Aly Sivji asked whether the components are actually interactive — they are, in a container the client provides. Brian Kaney asked the sharper question: whether a CLI agent would render the same thing as a text UI. That combination hasn't been tried.
Brady Bastian's synthetic-hospital analytics stack
Brady's pipeline generates a synthetic hospital — 88,000 patients from Synthea, parallelised across serverless instances — and then normalises the FHIR JSON with an engine that does a breadth-first search through every field, discovers keys at any depth, writes dbt models on the fly and runs them level by level.
That design is what lets it survive malformed JSON and custom extensions: nothing is hardcoded to an expected schema, so it finds whatever is actually there. It all runs inside the user's own warehouse, with no data extracted.
OMOP or SQL on FHIR?
Building OMOP views as the target loses semantics. SQL on FHIR gives you a FHIR-native schema in the warehouse and avoids the semantic loss of the transformation.
Brady conceded OMOP loses nuance — claim line items were his example — but defended it for portability, since a query written against one OMOP dataset runs against another unchanged.
Much of SQL on FHIR's motivation was human factors — naively flattened FHIR chokes BI tools and is miserable to author queries against. When an LLM writes the SQL, those factors matter less. But I don't think human-authored queries ever fully go away.