Topics discussed:

• Alexander's problem statement: agents drift. Left to themselves they invent a slightly different data model and a slightly different implementation of the same feature every time, and the generic frameworks they reach for know nothing about healthcare. He built a PHR twice to test whether FHIR fixes that. The first version was deliberately from scratch, no FHIR anywhere in the prompts — three people, two or three weeks, and it worked, but the schema kept growing, the agent kept adding tables and fields, some fields quietly went obsolete, and the codebase got heavy. The rebuild on FHIR went differently: ask for a patient summary feature and the agent immediately reaches for Composition and knows where the clinician narrative belongs. He needed two or three extensions in total.
• What "FHIR as a framework" means concretely: 150-plus resources already modelled, validation defined by StructureDefinitions, terminology handling, structured data capture with existing form builders and renderers, SQL on FHIR for dashboards, access control, subscriptions for events. What you add is the part explaining to the agent how to use it — and the skill he rates as non-negotiable is type generation. Without generated types the agent invents interfaces that spread across front end and back end and diverge; with them it never misses. The framing from the group: this is a specific case of the general rule that structure — types, FHIR, APIs — keeps agents out of black holes, and the open question is how much structure.
• The pushback came from someone building EHR integrations with a cybersecurity background: for a standard that has conformance testing, the variability in the wild is remarkable, and interpretations of the spec get genuinely weird. His practical finding is that FHIR resources carry the read path fine, but the workflow side — tasks, messaging — almost always ends up being some proprietary API even where perfectly good FHIR structures exist. Nikolai's answer was two-part. First, the spec is ten years of experts arguing about the data model, it amounts to a best practice, and it's in the training set — whatever you invent yourself under business pressure will be worse. Second, much of FHIR's ambiguity is essential rather than accidental: the same fact can legitimately be an Observation, a Condition or a Flag depending on the use case, and profiles carry a lot of the modelling on top of deliberately generic resources. The mitigation isn't stricter rules, it's giving the agent the knowledge base the community has built over a decade so it hallucinates less — same as for a human.
• Two risks that are not the same risk. Deterministic validators are underused and can have bugs of their own, and the group's view was that production systems should be validating all the data all the time rather than treating validation as a one-off exercise. Separately, and harder: if the goal is to remove engineers and let clinicians build their own apps behind guardrails — skills, templates, UI components, SDKs — how does a clinician evaluate that the code does what they think it does? Get a risk calculation subtly wrong and you get a wrong score and a wrong diagnosis, and no amount of resource validation catches it. Nobody claimed to know how well the guardrails hold.
• Wouter Biestra (Firely) showed work on automating the seven stages of FHIR data modelling — use case, logical model, mapping to base resources, quality control, documentation as an IG, publishing the package, feedback, and round again — by writing down what their consultants actually do as markdown skills plus tools that search the registry and Zulip. A related point on why skills need tools: an earlier FHIR skill described what FHIR looks like but couldn't do anything, whereas one that knows how to install and drive a validator lets the model generate a resource, run it, read the output and try again — which makes it dramatically better. That fed into an argument for rebuilding the IG pipeline agent-first: the IG Publisher is a publishing Swiss Army knife, and agents work badly with monoliths and well with small, focused, composable tools they can chain in bash. The counterpoint was that the publisher does much more than validation and people rely on all of it.