Compressing FHIR bundles for LLM context, and an agent OS for perioperative scheduling — Jul 16, 2026
Demo: Tokempic — compressing FHIR bundles for LLM prompts
Matt Berg built Tokempic to solve a practical problem: feeding a full FHIR bundle into an LLM burns through the context window fast. A typical patient record pulled via $everything runs around 72.5 KB or ~18,100 tokens. Tokempic runs that record through SQL-on-FHIR ViewDefinitions to extract clinically relevant fields, then renders a compact Markdown summary via an Eta template — bringing it down to 5.0 KB and ~1,260 tokens, a 93% reduction.
Everything about what gets extracted is configurable. ViewDefinition JSON files cover allergies, conditions, demographics, encounters, immunizations, labs, medications, procedures, related persons, and vitals. An --anon flag strips PII — names, addresses, IDs, birth dates reduced to year — for cases where you don't want to send patient details to an external model. Caching is built in, with options for incremental refresh, max-age, or full refresh. It works with Google Cloud Healthcare API out of the box and adapts to HAPI, Smile CDR, and other servers. It ships as a Claude Code plugin (/plugin marketplace add recodelabs/tokempic).
Matt also flagged where he wants the spec to go next. The current SQL on FHIR spec only supports single-resource views, but many prompt-shaping use cases would benefit from join views.
The current spec only supports single-resource views — I want to propose join ViewDefinitions so you can pull related resources into one flat projection instead of stitching them together after the fact.
Demo: Rookery and WardSim — multi-agent perioperative scheduling
Sam Schifman demoed Rookery, an agent OS he built to tackle what he sees as structural problems in how multi-agent systems are typically designed. The demo scenario is perioperative OR scheduling, run against WardSim — a simulation environment where multiple ORs execute on a compressed schedule (1 second = 1 hour) so agents can be tested against realistic disruptions. Both projects are public on GitHub: Rookery and WardSim.
Two scenarios ran on the call. First, a single circulating nurse called in sick the night before a shift; agents replaced Marcus Brown with float pool RN Jenny Kim, with the reasoning traced to MLflow. Then a harder day: two nurses out, a doctor leaving mid-day for a family emergency, and a vendor rep running late with specialized equipment. Agents worked through each disruption in turn, and all scheduling data was backed by a FHIR server.
Rookery's architecture is kernel-based with pluggable drivers for messaging, registry, model routing, orchestration, memory, observability (MLflow / OpenTelemetry), adaptive UI, and automation. Memory operates at three levels — institutional (e.g. hospital policy of no non-emergency ops on weekends), case, and user — and Sam argued most agent memory systems overweight the user layer at the expense of the other two. He also flagged Memory Hub, a related project started by a Red Hat colleague, as going further on memory architecture. The whole thing runs on OpenShift.
Agents calling each other over HTTP means blocking calls, and that pattern won't scale at enterprise scale. Async message queues are the right substrate.
The agent registry is a graph — agents know about each other within contained subgraphs. Sam expects crafting those graphs to be a key design challenge, with an open question of how much of that graph-building work eventually gets done by AI itself.
PHI, HIPAA, and where the model runs
Matt raised the question of how HIPAA and GDPR compliance actually works when agents are accessing patient data, particularly for scheduling workflows where PHI flows through the model.
Sam noted he intentionally left security out of Rookery — plenty of people at Red Hat are focused on it — but was clear it's critical, with agent identity and access control active areas of work. Red Hat's answer is local model hosting via vLLM (which Red Hat is one of the largest maintainers of) running on OpenShift, though he acknowledged the hardware cost is real.
Gino confirmed Microsoft Azure offers HIPAA-compliant model access with a BAA, and noted other providers do as well. Matt pointed out that smaller models like Gemma 27B can run on a Mac Mini, making local hospital deployment feasible for lower-complexity scheduling decisions.
Clients are already running controlled experiments with PHI and LLMs, often on anonymized data. This warrants a dedicated article on its own.
Deterministic code, BPMN, and whether CQL gets its day
Matt's broader view is that AI's biggest practical value right now is generating large volumes of deterministic if/then code — things too tedious or fragile for humans to write — which can then be unit tested and validated with confidence.
Sam agreed and framed it as "ephemeral code" — short-lived or single-use applications that AI generates and drops into a constrained automation environment, rather than open-ended code generation. He's focused on BPMN and DMN as targets: AI writes the graph or decision model, a human reviews the visual representation, and approves or modifies it.
BPMN failed the first time because it was too hard to write. If AI writes it and the human just reviews the picture, the authoring problem goes away.
Matt suggested CQL will have its day for the same reason — nobody wants to write it, but if AI writes it, the authoring problem falls away too. Gino pushed back on that framing.
CQL evaluation engines still don't produce consistent results on complex logic, and the language was designed patient-by-patient, which makes population-level evaluation infeasible.
Gino added that a project is spinning up in the SQL on FHIR group to translate CQL via relational algebra to SQL — two companies had working prototypes as of the Tuesday before this meeting, and the repo is pending approval. Sam's own preference is DMN over CQL: the visual representation of decision tables makes a meaningful difference for human review.