Topics discussed:

• 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.
• The 40 clinical skills that ship with it are the interesting part: 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. Hari was careful to say he isn't a clinician himself and is leaning on the guidelines the skills were written from.
• MCP apps let the server return a React component alongside the data instead of just 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, and that combination hasn't been tried.
• 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.
• Arjun Sanyal pushed back on building OMOP views as the target: 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. Arjun's second point is the one worth sitting with: much of SQL on FHIR's motivation was human factors, because naively flattened FHIR chokes BI tools and is miserable to author queries against, and when an LLM writes the SQL those factors matter less — but he doesn't think human-authored queries ever fully go away.