FHIR als Framework für agentisches Kodieren

LLMs schreiben plausiblen Code — und sie schreiben ihn schnell. Doch jeder, der einen Coding-Agenten durch mehr als ein Spielzeugprojekt geführt hat, kennt den typischen Fehlermodus: Gibt man ihm genug Spielraum, driftet er ab. Feldnamen ändern sich zwischen Sessions, das Datenmodell mutiert, und die Konventionen von gestern werden still und leise neu erfunden. Bei einer Landing Page ist das lästig. Bei Healthcare-Software ist „Improvisieren" keine Option.

Wir haben bei Health Samurai's Lab eine Hypothese getestet: FHIR ist nicht nur ein Datenstandard — es ist ein ungewöhnlich gutes Framework für KI-gestützte Entwicklung. Dieser Beitrag erläutert, warum das so ist, und was passierte, als wir dasselbe Produkt zweimal gebaut haben, um es herauszufinden.

Agentisches Kodieren braucht Leitschienen

Setzt man einen leistungsfähigen Agenten auf einen generischen Stack an, tauchen immer wieder vier Probleme auf:

• Agenten driften ab. Ohne ein festes Modell erfindet jede Session leicht unterschiedliche Feldnamen, Strukturen und Konventionen. Änderungen hören auf, sich zu ergänzen — jedes neue Feature kämpft gegen das letzte.
• Halluzinierte Datenstrukturen. Bittet man einen Agenten, „Allergien hinzuzufügen", erfindet er bereitwillig ein Schema. Nichts weist eine ungültige Struktur zurück, bis sie die Produktion erreicht und jemandem auffällt, dass die Daten falsch sind.
• Keine Selbstvalidierung. Ein generischer Stack gibt dem Agenten keine Möglichkeit, seine eigene Ausgabe zu überprüfen — außer „kompiliert es?" — was nicht dasselbe ist wie „sind das korrekte Gesundheitsdaten?"
• Generische Frameworks kennen das Gesundheitswesen nicht. React, Rails und Django wissen nichts über Patient, Encounter oder Observation. Jedes Projekt erfindet dieselbe Domänenmodellierung von Grund auf neu, und der Agent erfindet sie jedes Mal ein wenig anders.

Der gemeinsame Nenner ist das Fehlen von Leitschienen — einem starken, meinungsstarken Framework, das einschränkt, was der Agent produzieren kann, und ihn sofort informiert, wenn er falsch liegt. Je besser die Leitschienen, desto weniger Spielraum hat der Agent zum Abdriften, und desto schneller kann er sich korrigieren.

FHIR als Framework

Hier liegt die Erkenntnis: FHIR stellt fast all diese Leitschienen bereits bereit — und zwar speziell für das Gesundheitswesen. Ein festes Datenmodell behebt das Driften; serverseitige Validierung behebt die halluzinierten Strukturen und gibt dem Agenten eine Möglichkeit zur Selbstkontrolle; und das Ganze ist von Haus aus healthcare-nativ, sodass nichts pro Projekt neu modelliert werden muss.

Ein FHIR-nativer Stack besteht aus drei zusammenwirkenden Teilen — der FHIR-Server ist das Backend, die App wird auf FHIR-SDKs aufgebaut, und der Entwickler arbeitet neben einem KI-Copiloten, der bereits FHIR spricht. Der größte Teil dieses Stacks ist bereit, bevor man eine einzige Zeile Anwendungscode schreibt; der einzige Teil, den man tatsächlich baut, ist die App, die die FHIR-Teile miteinander verbindet.

Schauen wir uns an, was jede Schicht dem Agenten bietet.

Ein Datenmodell, das man erbt, nicht entwirft

FHIR R4 definiert 150+ Healthcare-Ressourcen — Patient, Condition, Observation, Encounter, MedicationStatement, DocumentReference und viele weitere. Nativ in einem FHIR-Server wie Aidbox gespeichert, benötigen sie überhaupt kein Schema-Design.

Das ist bedeutsamer, als es zunächst erscheint. Wenn der Agent Allergien speichern muss, erfindet er keine Tabelle — er greift auf AllergyIntolerance zurück, das bereits die richtigen Felder, Kardinalitäten und Bindings enthält. Benutzerdefinierte Domänenkonzepte werden zu benutzerdefinierten FHIR-Ressourcen — in unserer eigenen App ein PhrUser — mit ihrer eigenen StructureDefinition, nicht zu einer maßgefertigten Tabelle mit vom Agenten erfundenen Spalten. Man erbt zwei Jahrzehnte Healthcare-Domänenmodellierung — und der Agent auch.

Validierung als Feedback-Loop

Jeder Schreibvorgang auf einem FHIR-Server wird gegen die StructureDefinition der Ressource validiert: Kardinalität, Typen, Bindings, Invarianten. Ungültige Daten gelangen nie in die Datenbank.

Für einen menschlichen Entwickler ist das ein Sicherheitsnetz. Für einen Agenten ist es etwas Wertvolleres — ein enger, präziser Feedback-Loop. Anstatt eines 500-Fehlers drei Ebenen tiefer erhält der Agent etwas wie:

OperationOutcome: Patient.gender must be a code from
http://hl7.org/fhir/administrative-gender (male | female | other | unknown)

Genau das ist das Signal, auf dem ein Agent Selbstkorrekturen aufbaut. Profilbasierte Validierung ermöglicht es, die Regeln für das eigene Projekt zu verschärfen — Pflichtfelder, feste Kodiersysteme — ohne eine einzige Zeile Validierungscode zu schreiben. Der Agent schreibt weniger, und der Server teilt ihm sofort mit, wenn er falsch liegt.

Terminology, Formulare und Analysen — bereits gelöst

Ein FHIR-Server liefert viele schwierige Probleme bereits gelöst mit, und jedes davon ist ein Problem, das der Agent andernfalls von Hand zusammenstückeln würde:

• Terminology. ValueSet, CodeSystem und Operationen wie $expand, $validate-code und $lookup sind eingebaut. LOINC, SNOMED, RxNorm, ICD — alle über Standard-FHIR-Endpunkte erreichbar. Die App liefert kein Kodiersystem mit; sie fragt eines ab (zum Beispiel Termbox, einen dedizierten FHIR-Terminology-Server). Terminology hört auf, ein „TODO: Bibliothek finden"-Ticket zu sein.
• SQL on FHIR. Man definiert eine ViewDefinition, die FHIR-Ressourcen in tabellarische Spalten flacht, und fragt die View dann mit einfachem SQL ab. Analytics-Teams erhalten SQL für Berichte; die Daten bleiben in FHIR — keine Transformationspipeline zu schreiben. Es senkt auch die Hürde für In-App-Dashboards: Ein App-Entwickler, der Schwierigkeiten hätte, über verschachtelte FHIR-Ressourcen zu aggregieren, kann ein flaches GROUP BY gegen eine View schreiben, sodass ein Diagramm im Produkt und ein Bericht für die Analysten aus derselben Definition lesen. Und eine ViewDefinition ist selbst eine FHIR-Ressource, was bedeutet, dass der Agent eine schreiben kann — das Deklarieren von Spalten ist eine viel engere Aufgabe als das manuelle Schreiben von Traversierungslogik über verschachtelte Arrays.
• Structured Data Capture (SDC). FHIR-Questionnaire-Ressourcen beschreiben Formulare; Benutzer füllen sie aus, und die Antworten werden als QuestionnaireResponse gespeichert — verknüpft, validiert und durchsuchbar wie alle anderen FHIR-Daten. SDC-Implementierungen bringen Form Builder, Renderer, Extraktionslogik und Galerien fertiger Formulare mit.

Typen und Skills für den Agenten

Die oben genannten Schichten beschränken die Daten. Zwei weitere schließen den Kreis rund um den Agenten.

• Typisierte SDKs. Da jede Ressource eine maschinenlesbare StructureDefinition hat, können Client-Typen generiert statt geschrieben werden — für TypeScript, Python, C#, Java und andere. Der Vorteil für einen Agenten geht über Autovervollständigung hinaus: Ein falsch geschriebenes Feld oder ein falsches Enum schlägt auf Typebene fehl, noch bevor eine Anfrage gesendet wird, und eine einzige generierte Wahrheitsquelle wird von Server und Client geteilt, sodass beide Seiten eines Features nicht auseinanderdriften können. Öffentlich verfügbare Generatoren machen dies zu einem Build-Schritt, nicht zu einem Projekt.
• Agent Skills. Die neuere Schicht ist Dokumentation, die für Agenten statt für Menschen geschrieben wurde. Da FHIR ein öffentlicher Standard mit öffentlichen Server-APIs ist, ist dieses Wissen projektübergreifend wiederverwendbar — wie man eine Suchanfrage formuliert, wie Zugriffsrichtlinien funktionieren, wann man SQL on FHIR verwenden sollte — anstatt etwas, das jedes Team neu beibringen muss. Den Agenten auf aktuelle Dokumentation hinzuweisen verhindert zudem, dass er sich auf das stützt, was ein Modell zum Trainingszeitpunkt aufgenommen hat — bei einer Spezifikation, die neue Versionen herausbringt, eine echte Quelle für selbstbewusst falschen Code.

Beides sind Dinge, die man einmal konfiguriert, von denen der Agent dann bei jeder Aufgabe profitiert.

Das Experiment: dieselbe App, unterschiedliche Grundlage

Theorie ist billig, also haben wir es getestet. Unser Versuchsfeld war Health Samurai's internes Personal Health Record (PHR) — ein echtes Produkt für unser eigenes Team und die Familien, für die sie sorgen. Sein Umfang ist wirklich nicht trivial: Verwalten von Datensätzen für sich selbst und Angehörige, Eingeben von Diagnosen/Medikamenten/Allergien/Eingriffen, Hochladen medizinischer PDFs, chatbasierte Konsultationen mit Ärzten, eine Patientenzusammenfassung und KI-Unterstützung, die in den eigenen FHIR-Daten des Patienten verankert ist.

Wir haben es zweimal mit Claude Code gebaut — gleicher Umfang, unterschiedliche Grundlage. Das erste Mal ließen wir den Agenten von Grund auf bauen; das zweite Mal haben wir die gesamte App mit FHIR als Framework neu aufgebaut.

In v1 erfand der Agent sein eigenes Datenmodell, seine eigene API-Form, seine eigenen Validierungsregeln. Jedes neue Feature bedeutete, dem Agenten die Konventionen neu beizubringen, von denen er bereits abgedriftet war. In v2 produzierte das Neubauen derselben App auf FHIR eine kleinere, kohärentere Codebasis — der Agent stützte sich auf FHIR, statt es neu zu erfinden.

In der Praxis zeigt sich das in gewöhnlichem Code. Generierte Typen plus ein Satz Open-Source-Claude-Code-Skills für die Arbeit mit Aidbox bedeuteten, dass der Agent einen Patient-Create wie folgt schrieb, ohne ein eigenes Schema entwerfen zu müssen:

// The agent writes against generated types — the shape is not up for negotiation
const patient = await aidbox.create<Patient>({
  resourceType: "Patient",
  name: [{ given: [body.givenName], family: body.familyName }],
  birthDate,
  gender: body.gender || undefined,
  active: true,
});
// ...and the server validates it on write.

Unspektakulär — und das ist der Punkt: Es gab keine Entscheidung über Feldnamen oder Speicherung zu treffen, und nichts, wovon der Agent in der nächsten Session abdriften könnte.

Drei Erkenntnisse stachen hervor:

1. Weniger Code. Das Framework übernimmt die langweiligen Teile — Schema, API, Validierung — sodass der Agent einfach weniger davon schreibt.
2. Ein engerer Feedback-Loop. Der Server weist ungültige Schreibvorgänge mit präzisen Fehlermeldungen zurück, und der Agent korrigiert sich selbst — kein mysteriöser 500-Fehler drei Ebenen tiefer.
3. Features werden zu Gesprächen, nicht zu Projekten. Ein klinisches Konzept hinzuzufügen ist ein Schritt — eine FHIR-Ressource auswählen, Typen generieren, UI verdrahten — nicht fünf.

Das deutlichste Beispiel: Wir baten um ein Patientenzusammenfassung-Feature. Auf einem generischen Stack bedeutet das, ein Zusammenfassungsschema zu entwerfen, zu entscheiden, wie auf die zugrunde liegenden Datensätze verwiesen wird, und eine API darum herum zu bauen. Auf FHIR griff der Agent zur Composition-Ressource — dem eigenen Modell des Standards für ein strukturiertes, gegliedertes klinisches Dokument — und implementierte es sauber: Abschnitte, die auf die vorhandenen Condition-, MedicationStatement- und AllergyIntolerance-Ressourcen des Patienten verweisen, kein maßgefertigtes Schema erfunden. Ein Feature, das ein kleines Projekt gewesen wäre, wurde zu einem einzigen Gespräch, weil FHIR es bereits modelliert hatte.

So probieren Sie es selbst aus

Wenn Sie Ihrem Agenten dieselben Leitschienen geben möchten, ist das Ausgangsrezept kurz:

• Wählen Sie einen FHIR-Server als Backend (zum Beispiel Aidbox).
• Generieren Sie FHIR-Typen mit @atomic-ehr/codegen, damit der Agent gegen echte Strukturen kodiert.
• Installieren Sie die Claude Code Skills, damit der Agent von Anfang an FHIR spricht.

Der PHR-Quellcode ist ebenfalls offen, falls Sie ein vollständiges Beispiel sehen möchten: github.com/HealthSamurai/phr.

Was kommt als nächstes: Den Programmierer aus der Schleife nehmen?

Hier ist die Frage, die das Experiment aufgeworfen hat. Wenn FHIR einem Agenten genug Struktur gibt, um eine echte App zu bauen — was wäre, wenn der Benutzer des Agenten gar kein Entwickler wäre?

Stellen Sie sich eine Plattform vor, auf der Ärzte ihre eigenen Apps bauen, in natürlicher Sprache mit einem KI-Assistenten iterieren, und diese Apps direkt in die bestehende Infrastruktur der Gesundheitsorganisation eingebunden sind:

• Ärzte als Builder — kein Entwicklungsteam als Mittler; den Workflow beschreiben, eine funktionierende App erhalten.
• Mit KI iterieren — ein Formular ändern, eine Regel anpassen, eine Zusammenfassung hinzufügen. Ein Gespräch, kein Ticket.
• Passt in den Stack des Krankenhauses — kommuniziert FHIR mit dem EHR, respektiert bestehende Authentifizierung, Audit und Richtlinien. Kein Silo, sondern ein Bestandteil der Infrastruktur.

Es ist dieselbe Wette wie dieses ganze Experiment, eine Ebene höher: FHIR als Grundlage, die KI befähigt, Healthcare-Software für die Menschen zu bauen, die sie tatsächlich brauchen.

---

Möchten Sie besprechen, wie Sie das auf Ihrem eigenen Stack anwenden können? Wenden Sie sich an Aleksandr Kislitsyn, oder erkunden Sie das Open-Source-PHR-Repository und seine Claude Code Skills.