FHIR DevDays 2026: Patient Control, Regular Tooling, and Conversational Interop

FHIR DevDays is where the standards conversation gets real. It is the rubber-meets-the-road version of FHIR: developers implementing the specs, building on them, finding the gaps, and bringing those lessons back to the people writing the next version.

The conference is part education, part experiment, and part field report from production work. Most importantly, it is community. The useful signal is often in the hallway conversation after the talk, where the question becomes practical: where trust sits, who authorizes access, what can be validated, and which workflows still fall outside the current spec work.

The Minneapolis conference made those choices feel more operational than theoretical. Patient-directed exchange is getting concrete enough to debate as an implementation model. Tooling for FHIR, CQL, FHIRPath, FSH, and packaging needs the same regularity we expect from other production infrastructure. Conversational interoperability is becoming a credible proposal for workflows that will not get a custom API.

That is the useful through-line: standards are not only about data shape. They are about putting authority, verification, and negotiation at the right layer.

1. Kill the Clipboard

"Kill the Clipboard" is an old phrase with a newly plausible path.

The clipboard is not just paper. It is the same intake workflow repeated every time a patient meets a new provider: allergies, medications, surgeries, family history, prior diagnoses, and whatever else the patient can remember while sitting in a waiting room. It is patient-mediated exchange, but in the least reliable form possible.

The hard part has never been the form itself. The hard part is trust. Two organizations may not share an EHR, a payer, or a treatment relationship. They have no built-in reason to trust each other's data, and the patient is usually reduced to carrying memory, paper, or a PDF.

TEFCA gives the United States a serious national exchange framework. It matters, and it is real progress. But the most interesting DevDays thread for me was the work adjacent to that rail: patient-held, verifiable data that does not require every exchange to start with an institution-to-institution relationship.

SMART Health Links Change the Trust Model

SMART Health Links give patients a portable pointer to clinical data rather than a static copy. A vaccination record, lab result, or clinical summary lives on a server the patient controls, and the patient shares a link: a short shlink:/ URI carrying a manifest URL and a symmetric decryption key.

To resolve the link, the verifier fetches an encrypted manifest from the patient-controlled endpoint and decrypts the files with the key embedded in the link. The manifest can carry SMART Health Cards with issuer signatures, raw FHIR resources, or SMART API access tokens for live queries. The data is fetched at presentation time, can be updated by the patient, and can be revoked, so the verifier never relies on a copy that may have drifted from the source. The file server can even be a blind intermediary, because every file in the manifest is encrypted with a key only the link carries.

That changes the shape of the workflow. TEFCA can provide centralized exchange where that is the right operating model. SMART Health Links can cover the cases where the patient is the bridge between organizations. The successor to the clipboard does not have to be another centralized repository. It can be a patient-controlled link the patient chooses to share.

The distinction matters. A central exchange can move data between organizations, but patient control is not automatic. Who can access data, which data they can access, and under what conditions are governance questions as much as protocol questions.

Patient-held links move the authorization boundary closer to the patient. The patient chooses when to present the link and can revoke or update it. The verifier fetches current data from a source the patient pointed to, not a copy that may be stale. When the manifest carries SMART Health Cards, the issuer signature is still verifiable end-to-end. The workflow is still simple enough to use at the front desk, but it no longer depends on hand-entered history or blind trust in a PDF.

There is an obvious risk. Over time, the pressure will be to fold patient-held links back into institution-only exchange because it is easier for incumbent workflows. That would miss the point. The design choice worth defending is patient authority over presentation and access.

2. Regular Tooling Is Agent-Ready Tooling

My DevDays talk was about rh, our Rust FHIR toolkit. It covers FHIR code generation, FHIRPath, FSH, CQL, validation, packaging, reusable crates, WASM builds, and typed npm packages where browser use makes sense.

The talk was not really about AI. It was about the properties that make a standards tool usable in repeated, inspectable workflows. Those properties also happen to make the tool useful to agents.

The AIC Detour

A couple of years ago we sketched an experimental language called AIC, short for "AI-compiled." The question was simple: what would a compiled language look like if it were designed for LLM-first authoring?

The answer had deterministic semantics, no hidden mutation, canonical formatting, typed holes for incomplete programs, familiar keywords, and one obvious way to express common constructs. Once the design was on paper, it looked familiar. Structs, enums, traits, pattern matching, async, and Result<T, E> had led us back to Rust.

AIC did not become a language. It became a useful constraint on how we write Rust for rh: explicit mutation, consistent idioms, canonical formatting, actionable compiler errors, and a small number of preferred patterns for recurring work. That is not AI theater. It is ordinary engineering discipline, applied to the places where an agent will eventually operate.

The same idea shows up in the browser build. The rh WASM playground runs FHIRPath, VCL, and CQL in the browser from the same Rust crates used by the CLI. That is the kind of surface I want more standards tooling to have: inspectable enough for developers, structured enough for CI, and regular enough for agents.

The CLI Is the API

For agent workflows, the command-line interface matters more than most people admit. Every rh command is designed to have stable flags, stable exit codes, and machine-readable output:

rh fhirpath eval 'Patient.name.where(use = "official").family' \
  --resource patient.json | rh validate --stdin

The same command works for a developer in a terminal, a CI job, and an agent loop. There is no separate agent SDK. The CLI is the API.

This is where the field guide framing fits: the model is not the moat. The workflow is. A tool that emits inspectable output, fails with useful errors, and composes with other tools gives both people and agents a better operating surface. When a tool lacks that regularity, agent engineering cannot fully compensate.

rh is still growing. The reference stacks have deeper coverage in several areas, including IG Publisher integration and terminology depth. But Rust gives rh a strong shape for cold-start CLIs, CI loops, browser/WASM deployment, and standards-aligned automation. That is the part I wanted to make explicit at DevDays.

3. Conversational Interoperability

Josh Mandel's session on Conversational Interoperability, or COIN, was the other talk I kept returning to.

The core problem is familiar: some workflows are too specific, too variable, or too infrequent to justify a pre-negotiated API. A niche disease registry, a complex prior authorization, or a specialized referral may need data that no standard implementation guide anticipated. The exchange is important, but the schema work may never pay for itself.

FHIR handles the head of the distribution well. COIN is aimed at the tail.

Instead of expecting every edge case to have a finished API, organization-side agents converse about what is needed. They pull from FHIR when structured data exists. They use notes and other available records when it does not. They negotiate the missing context at query time, then produce structured output that can be reviewed, replayed, and tested.

The asynchronous framing is important. Not every exchange needs a subsecond response. If an agent can spend an hour working through an EHI export, notes, and available FHIR data to produce a reviewable answer for a registry or referral, that may be a major improvement over a workflow that never happens because no one built the interface.

Banterop Makes It Testable

The Banterop demo made the idea concrete. It provides a way to simulate, build, and test agent-to-agent interactions. That matters because a conversation that cannot be replayed or asserted against is not yet an engineering surface.

Testability is the line between "agents will figure it out" and inspectable intelligence. Capture the transcript. Replay the exchange. Assert on the structured output. Track what sources were used. Decide where human review is required.

That is also where COIN has to stay disciplined. It should not become an excuse to skip modeling work that should be done. Some workflows look like long-tail problems only because no one has turned them into a computable artifact yet. Those should still become FHIR profiles, Questionnaires, CQL libraries, value sets, and implementation guides when the reuse is worth it.

COIN is strongest where pre-specification genuinely does not pay back. FHIR remains the right layer for durable, reusable exchange. The two approaches should compose, not compete.

The Useful Direction

What stuck with me from DevDays was not that AI is going to fix healthcare. That framing is too vague to be useful.

The more practical direction is this:

Patient-directed exchange should keep the patient at the authorization boundary. FHIR tooling should produce computable artifacts, deterministic validation, and inspectable output. Conversational protocols should be reserved for the workflows where pre-negotiated schemas break down, then tested like any other production surface.

That is real progress. It is less dramatic than a platform promise and more durable than a demo. It is also the kind of work FHIR DevDays is good at surfacing: standards work that becomes operational only when the trust model, the tooling, and the review path are designed together.

Kill the clipboard. Keep patient-held links patient-directed. Make the tooling regular enough that people, CI, and agents can all use it. Let conversational interop cover the workflows schemas cannot reach, but do not let it replace the modeling work FHIR already does well.

That is the DevDays 2026 takeaway I want to keep.

The rh toolkit is at github.com/reason-healthcare/rh; the COIN session materials are at github.com/jmandel/devdays-2026.