Eine Frau, die ich kenne, hat drei chronische Erkrankungen, vier behandelnde Ärzte und Akten in sechs verschiedenen Systemen. Vor jedem neuen Termin erledigt sie dieselbe Arbeit: in drei Patientenportale einloggen, ihre Medikamentenliste abfotografieren, ihre Krankengeschichte auf ein Klemmbrettformular abtippen und hoffen, dass die Anmeldung die Daten korrekt einträgt. Das tut sie seit elf Jahren. Sie ist keine schlechte Patientin. Sie leistet unbezahlte Integrationsarbeit, weil niemand sonst in diesem System in der Position ist, sie zu leisten.
Das ist der Engpass. Nicht die Diagnose, nicht der Datenzugang im rechtlichen Sinne. Die Patientin ist die einzige Partei, die das Gesamtbild kennt – und die einzige Partei ohne Werkzeuge, um darauf zu handeln.
Ein KI-Agent ist das erste Mittel, das diese Lücke plausibel schließen kann. Er kann sechs Systeme lesen, eine Medikamentenliste abgleichen, das Formular ausfüllen und die Überweisung einfordern. Das ist keine Spekulation. Man verbindet einen MCP-Client mit einem FHIR-Server, übergibt eine Basis-URL und ein Token – und die Demo funktioniert beim ersten Versuch.
Genau darin liegt das Problem. Die Demo funktioniert, und nichts im Stack sagt der Patientin, was dieser Agent mit dem Gelesenen tun darf.
Was FHIR zu beantworten entworfen wurde – und was nicht
FHIRs Autorisierungsmodell wurde für eine Welt entwickelt, in der der Client eine Anwendung war und ein Mensch dahinter saß. Diese Welt entstand um 2011, wurde durch Argonaut und SMART on FHIR gefestigt und durch die API-Regeln des 21st Century Cures Act zum Gesetz. Sie löste ein reales Problem – und löste es gut. Eine Patientin kann ihre Daten jetzt abrufen.
Man schaue sich an, was die Scopes tatsächlich aussagen. patient/Observation.rs bedeutet: Dieser Client darf Observations für diese Patientin lesen und durchsuchen. Das ist eine Zugriffsfrage, und FHIR beantwortet sie präzise.
Nun stelle man die Fragen, die ein Agent aufwirft:
- Darf dieser Lesende nach Sitzungsende eine Kopie aufbewahren?
- Darf er die Nutzdaten an einen Modellanbieter in einer anderen Rechtsordnung senden?
- Darf der Anbieter sie in einem Prompt-Cache speichern?
- Darf sie zum Training eines Modells genutzt werden, das jemand anderes verkauft?
- Darf der Lesende eine Diagnose ableiten und auf Basis der Inferenz handeln, ohne dass die Patientin das je sieht?
FHIR beantwortet keine dieser Fragen, weil es sich dabei um keine Zugriffsfragen handelt. Es sind Nutzungsfragen – und die Nutzung war das Problem von jemand anderem, als die Spezifikation geschrieben wurde. Consent kommt am nächsten: Sie beschreibt eine Erlaubnis zur Weitergabe mit Zweck-der-Nutzung und Akteursklauseln. Sie beschreibt jedoch immer noch eine an der Grenze erteilte Erlaubnis. Nichts an der Ressource reist mit der Nutzlast mit, und beim Empfänger wird nichts durchgesetzt. R6 führt Permission mit einer $evaluate-Operation ein – ein echter Fortschritt, der sich noch im Ballot-Verfahren befindet.
Die ehrliche Feststellung der Lücke lautet also: Der Standard regelt, wer lesen darf. Er regelt nicht, was der Lesende danach tut, und er besitzt kein Vokabular für einen Lesenden, der ein Modell ist und keine Person.
Das ist keine Kritik an FHIR. Grahame und alle, die daran beteiligt waren, lösten das Problem von 2014 – und das Problem war real. Es ist eine Aussage darüber, was 2026 braucht und noch nicht existiert.
Niemand baut die Seite der Patientin
Hier wird echte Arbeit geleistet, die benannt werden sollte. Die CARIN Alliance hat einen Verhaltenskodex für den verbrauchergesteuerten Datenaustausch. Josh Mandels SMART Health Links gaben Patientinnen und Patienten einen echten Mechanismus, ihre Akte zu ihren eigenen Bedingungen zu teilen. Das Consent IG existiert. HL7-Arbeitsgruppen sind aktiv.
Aber man schaue sich an, von wem und für wen die KI-Governance-Werkzeuge entwickelt werden. Anbieter bauen Agentensicherheit in ihre eigenen Produkte ein, begrenzt auf ihre eigene Haftung. Gesundheitssysteme schreiben KI-Richtlinien, die die Agenten des Systems innerhalb der Grenzen des Systems regeln. Beides ist rational. Keines davon erzeugt etwas, das die Patientin kontrolliert.
Die Asymmetrie ist der entscheidende Punkt. Wenn ein Gesundheitssystem einen Agenten einsetzt, bestimmt das System die Schwärzungsrichtlinie, hält das Prüfprotokoll und legt die Genehmigungsregeln fest. Wenn eine Patientin einen Agenten für ihre eigenen Akten nutzt, entscheidet sie über nichts davon. Sie akzeptiert, was auch immer der App-Anbieter gewählt hat – meist ohne es zu sehen –, und der App-Anbieter hat keinen Anreiz, konservativ zu wählen.
Wir sind dabei, Patientinnen und Patienten das leistungsfähigste Werkzeug zu geben, das sie je für die Navigation in diesem System hatten – ohne eine Governance-Schicht, die ihnen gehört. Das sollte unbehagen bereiten.
Was die Kopie tatsächlich wert ist
Hier ist der Grund, warum das kein abstraktes Anliegen ist. Wenn eine vollständig identifizierte FHIR-Ressource die Covered Entity verlässt und bei einem allgemeinen KI-Anbieter landet, hört HIPAA in der Regel auf zu gelten. Mit einem Consumer-Chatbot gibt es keine Business-Associate-Vereinbarung. Was die Daten dort regelt, ist die FTC-Vollstreckung und ein Flickenteppich aus Landesrecht – ein schwächeres Regime für den Einzelnen.
Mit dieser Kopie können vier Dinge geschehen.
Sie wird verkauft. Der Handel mit Gesundheitsdaten ist ein etablierter Markt. Zu den Käufern gehören Werbetreibende, Pharma-Vermarkter und Anbieter von Patientenrekrutierung für klinische Studien, die für konditionsbezogene Kohorten zahlen. Die FTC-Maßnahmen von 2023 gegen GoodRx und BetterHelp betrafen beide den Weg von Gesundheitsdaten zu Werbeplattformen von Unternehmen, die ihren Nutzern das Gegenteil versichert hatten. In keinem der Fälle war ein Krankenhaus beteiligt.
Sie gelangt zu einem Versicherer. Der ACA verbietet Krankenversicherern die Risikoprüfung auf Basis von Vorerkrankungen. Er verbietet das nicht für Lebens-, Berufsunfähigkeits- oder Pflegeversicherungen, die sehr wohl die Krankengeschichte berücksichtigen. Das Risiko für Arbeitgeber entsteht durch Wellnessprogramme und die Verwaltung selbstfinanzierter Pläne, bei denen die Trennung zwischen Plandaten und Arbeitgeberdaten dünner ist, als die meisten Beschäftigten annehmen. GINA und der ADA schränken einiges davon ein. Keines der beiden Gesetze wurde mit Bedingungen im Sinn verfasst, die aus einem Chat-Transkript abgeleitet werden.
Sie ordnet jemanden einer Kohorte zu. Sobald ein Dritter Diagnosen ableiten kann, lässt sich jemand in ein Outreach-Programm einordnen, dem er nie zugestimmt hat, oder es werden ihm weniger Anbieteroptionen angezeigt, als tatsächlich existieren. Ob eine solche Steuerung heute in großem Maßstab stattfindet, ist diskutabel. Der Anreiz dazu ist es nicht – und die Patientin hat in keinem Fall Einblick.
Sie trainiert ein Modell. Je nach den Bedingungen des Anbieters können Eingaben zu Trainingsdaten werden; und Consumer-Tarife unterscheiden sich in genau diesem Punkt erheblich von Enterprise-Tarifen. Das ist der einzige Punkt auf dieser Liste, der nicht rückgängig gemacht werden kann. Eine Kopie beim Datenhändler kann gelöscht werden. Modellgewichte können nicht „un-trainiert" werden.
All das setzt kein böses Handeln voraus. Es ist das Standardverhalten eines Systems, in dem die Patientin Lesezugriff erteilt hat und nichts Nachgelagertes eingeschränkt ist.
Anweisungen sind keine Durchsetzung
Die übliche Antwort lautet: bessere Anweisungen schreiben. Die Regeln in den System-Prompt schreiben. Den Agenten anweisen, Identifikatoren zu schwärzen, seine Handlungen zu protokollieren und vor dem Schreiben zu fragen.
Ein Prompt ist eine Bitte, keine Kontrolle. Das Modell entscheidet, ob es ihr nachkommt – und wer Text vor das Modell bringen kann, hat eine Stimme dabei. Klinische Notizen, gescannte Dokumente und Portalnachrichten sind allesamt Text, den ein Angreifer beeinflussen kann. Eine Kontrolle, an der sich der Agent vorbeiredet, ist keine Kontrolle.
Die Durchsetzung muss dort laufen, wo der Agent sie nicht erreichen kann. In der Praxis bedeutet das: auf dem Server – und es bedeutet vier Dinge.
Beim Lesen schwärzen. Identifikationsfelder entfernen, bevor die Ressource das Modell erreicht. Namen auf Initialen kürzen, Identifikatoren maskieren, Adressen entfernen, Geburtsdaten auf das Jahr kürzen. Der Agent erhält klinischen Inhalt, aber keine Identität. Das ist eine kompensierende Kontrolle, keine rechtliche Entidentifizierungsfeststellung – und sollte als solche beschrieben werden. Es macht eine Akte mit einer seltenen Diagnose und einer ungewöhnlichen Datumssequenz nicht unangreifbar. Was es ändert, ist der Standard – und der Standard lautet derzeit: „alles herausgeben."
Alles protokollieren. Jeder Lese- und Schreibvorgang erzeugt einen dauerhaften Eintrag mit Tenant, Agent, Ressource und Zeitstempel. Ein Anfrage-Log ist das nicht. Wenn ein Compliance-Beauftragter fragt, welcher Agent, handelnd für welche Patientin, welche Ressourcen gelesen hat, kann ein Zugriffslog mit einer gemeinsamen Service-Account-Identität das nicht beantworten. Zwei Designregeln sind entscheidend: Das Protokoll ist nur erweiterbar (Append-only), und die Prüfdetails sind PHI-frei, damit der Datensatz, den man einem Prüfer übergibt, sicher übergeben werden kann.
Bei Schreibvorgängen eskalieren. Auf Protokollebene kann ein Token, das GET /Observation darf, meist auch POST /Observation. Das Transport-Protokoll unterscheidet nicht zwischen „fasse meine Laborwerte zusammen" und „erfasse einen Blutdruck von 190/120". Ein separates, kurzlebiges Schreib-Credential stoppt einen entschlossenen Angreifer nicht allein. Es macht Schreibvorgänge zu einer eigenständigen, prüfbaren Ereignisklasse anstatt zu einem Nebeneffekt einer geschwätzigen Sitzung.
Für alles Unumkehrbare eine externe Genehmigung verlangen. Bei einem klinischen Schreibvorgang: blockieren, bis ein Mensch bestätigt. Bei einer realen Aktion – einem Anruf, einer Textnachricht, einem abgeschickten Formular – ist die Messlatte höher: „Commit" sollte die Aktion nur einreichen, während die Ausführung hinter einer Genehmigung steht, die die eigene Toolchain des Agenten nicht erzeugen kann. Wenn der Agent das Artefakt liefern kann, das menschliche Zustimmung repräsentiert, gibt es keinen Menschen in der Schleife.
Der offensichtliche Einwand: SMART-Scopes und Consent tun bereits einen Teil davon. Das stimmt teilweise – und dort sollte dieses Muster letztlich verankert sein. Scopes schränken ein, was ein Client anfordern darf. Was sie nicht können: die Form der Antwort einschränken, einen agentenattribuierten Prüfprotokoll-Eintrag erzeugen oder einen Schreibvorgang aufhalten, bis eine Person auf „Bestätigen" tippt. Das sind Laufzeitverhalten – und heute tut sie kein Server standardmäßig.
Eine Implementierung, offen entwickelt
HealthClaw Guardrails ist ein MIT-lizenzierter Proxy zwischen einem beliebigen KI-Agenten und einem beliebigen FHIR-Server. Er stellt einen MCP-Server mit 29 Tools und eine REST-Fassade bereit und setzt die vier oben genannten Kontrollen sowie Tenant-Isolierung durch. Die Designregel lautet: Keine Sicherheitseigenschaft darf vom Verhalten des Clients abhängen.
Zwei Details sind die Stellen, an denen dieses Muster üblicherweise undicht wird.
Der Schreibpfad. fhir_propose_write validiert und zeigt eine Vorschau, ohne etwas zu committen. fhir_commit_write erfordert ein Step-up-Token und gibt HTTP 428 zurück, bis ein Mensch bestätigt. Bei realen Aktionen gibt action_commit 202 awaiting_confirmation zurück und tut sonst nichts; die Ausführung verbraucht ein Einmal-Credential über einen separaten Genehmigungspfad, das atomar beansprucht wird, damit es nicht wiederholt werden kann. Eine frühere Version schützte dies mit einem X-Human-Confirmed-Request-Header. Diesen haben wir aus dem Aktionspfad entfernt, weil ein Header vom aufrufenden Client gefälscht werden kann. Dieser Header schützt heute noch klinische FHIR-Schreibvorgänge – und wir dokumentieren ihn als kompensierende Kontrolle, nicht als Beweis dafür, dass ein Mensch gehandelt hat. Präzise anzugeben, welche Garantien kryptografisch und welche Konventionen sind, ist der größte Teil des Wertes hier.
URL-Umschreibung der Upstream-URL. Antworten werden so umgeschrieben, dass die Basis-URL des Backing-Servers den Client nie erreicht. Ein Agent, der den echten Endpunkt kennt, wird versuchen, den Proxy zu umgehen.
Vor Aidbox betreiben
Das vollständige Beispiel – einschließlich docker-compose.yaml, Seed-Daten und einer geskripteten Anleitung – befindet sich unter aidbox-integrations/healthclaw-guardrails im Aidbox-Examples-Repository.
Eine kostenlose Aidbox-Lizenz gibt es unter aidbox.app, danach:
git clone https://github.com/Aidbox/examples
cd examples/aidbox-integrations/healthclaw-guardrails
cp .env.example .env # paste AIDBOX_LICENSE, set STEP_UP_SECRET
docker compose up -d
./scripts/seed-aidbox.sh # one Patient, three Observations, one Condition
Drei Dienste starten: Aidbox auf Port 8080 als System of Record, der Guardrail-Proxy auf Port 5000 und der MCP-Endpunkt auf Port 3001, mit dem der Agent sich verbindet. Aidbox ist mit einer AccessPolicy konfiguriert, die den Client des Guardrails auf den FHIR-Endpunkt beschränkt, und der Proxy ist darauf ausgerichtet:
healthclaw:
environment:
FHIR_UPSTREAM_URL: http://aidbox:8080/fhir
STEP_UP_SECRET: ${STEP_UP_SECRET}
READ_AUTH_ENABLED: "true"
An der Aidbox-Seite ist nichts Ungewöhnliches. Das ist Absicht. Die Guardrail-Schicht ist additiv, und der darunter liegende FHIR-Server verhält sich weiterhin wie ein FHIR-Server.
Dieselbe Abfrage – mit und ohne Governance
Direkt an Aidbox ist die Akte vollständig identifiziert, wie es sein sollte:
curl -u "$AIDBOX_CLIENT:$AIDBOX_SECRET" \
http://localhost:8080/fhir/Patient/pt-demo
{ "resourceType": "Patient", "id": "pt-demo",
"name": [{"given": ["Maria"], "family": "Alvarez"}],
"identifier": [{"system": "urn:mrn", "value": "MRN-88214"}],
"birthDate": "1974-03-11",
"address": [{"line": ["221 Baker St"], "city": "Pittsburgh"}] }
Über den Proxy, dieselbe Ressource, dasselbe Aidbox:
curl -H "X-Tenant-ID: demo" \
http://localhost:5000/r6/fhir/Patient/pt-demo
{ "resourceType": "Patient", "id": "pt-demo",
"name": [{"given": ["M."], "family": "A."}],
"identifier": [{"system": "urn:mrn", "value": "***masked***"}],
"birthDate": "1974",
"meta": {"tag": [{"code": "redacted"}]} }
Aidbox hält weiterhin die vollständige Akte. Die Schwärzung ist eine Eigenschaft des Pfades, den der Agent nutzt – keine Änderung der Daten.
Der Lesevorgang hat eine Spur hinterlassen
curl -H "X-Tenant-ID: demo" "http://localhost:5000/r6/fhir/AuditEvent?_count=1"
Gibt ein AuditEvent zurück, das Tenant, Agent, Patient/pt-demo und den Zeitstempel nennt – ohne PHI im Detail. $export gibt das Protokoll als NDJSON für ein SIEM aus.
Ein Schreibvorgang, zweimal blockiert
Der Agent wird gebeten, einen Blutdruck zu erfassen. Erster Versuch, kein Step-up-Token: gibt 401 zurück. Token mintieren und erneut versuchen: gibt 428 zurück, ausstehende menschliche Bestätigung. Erst nach der Bestätigung erreicht die Observation Aidbox. Zur Überprüfung wird Aidbox direkt abgefragt, am Proxy vorbei:
curl -u "$AIDBOX_CLIENT:$AIDBOX_SECRET" \
"http://localhost:8080/fhir/Observation?subject=Patient/pt-demo&code=85354-9"
Die Ressource ist vorhanden, und das Prüfprotokoll verzeichnet, wer sie vorgeschlagen hat, wer sie genehmigt hat und wann. Diese Abfolge ist das eigentliche Argument. Der Agent hat nützliche Arbeit geleistet. Er konnte sie nicht allein abschließen.
Das Deployment bewerten
curl "http://localhost:5000/r6/fhir/\$conformance?format=text"
HealthClaw Guardrail Conformance — http://localhost:5000 [tenant=demo]
Grade: A (7/7 properties)
[PASS] PHI Redaction [PASS] Human-in-the-Loop
[PASS] Immutable Audit Trail [PASS] Tenant Isolation
[PASS] Step-Up Authorization [PASS] Medical Disclaimers
[PASS] Error Fidelity
Error Fidelity ist die am wenigsten offensichtliche Eigenschaft: Unbekannte Suchparameter und nicht unterstützte Modifikatoren müssen abgelehnt oder gemeldet werden – und dürfen nie stillschweigend verworfen werden. Ein Filter, der lautlos verschwindet, weitet eine Abfrage aus – und eine ausgeweitete Abfrage auf eine Patientenakte ist eine Offenlegung. Dieselbe Prüfroutine läuft in CI als Merge-Gate, sodass eine Regression als Notenänderung erscheint und nicht als Vorfall. Eine Sicherheitsaussage, die man ausführen kann, ist mehr wert als eine, die man nur lesen kann.
Was das der Patientin bringt
Zurück zum Klemmbrett. In CareAgents, der auf dieser Schicht aufbauenden Consumer-App, lautet die Anfrage: „Ich habe nächste Woche einen Termin bei einem neuen Arzt – füllen Sie mein Aufnahmeformular aus meinen Akten aus." Der Agent füllt das Formular mittels SDC $populate aus – und hält dann an.
Jedes Medikament und jede Allergie erfordert eine individuelle Bestätigung der Patientin. „Keine bekannten Allergien" erfordert eine explizite Bezeugung und wird nie aus einer leeren Liste abgeleitet, denn eine leere Liste und ein echtes Negativ sind unterschiedliche klinische Aussagen. Der Server leitet die Elementliste beim Absenden neu ab, sodass eine manipulierte Anfrage keine Zeile überspringen kann. Die Genehmigung erzeugt ein provenanz-gestempeltes PDF hinter einem signierten, ablaufenden Link.
Elf Jahre Abtippen werden zu einem Überprüfen-und-Bestätigen. Der Agent erledigt die Arbeit. Die Patientin behält jede Entscheidung. Der Server macht diese Aufteilung zur unverhandelbaren Realität – nicht zu einem Versprechen in einer Datenschutzerklärung.
Warum diese Schicht offen sein muss
Eine Sicherheitseigenschaft, die man nicht einsehen kann, ist eine Marketingaussage. Jeder Anbieter sagt, sein Agent sei sicher im Umgang mit PHI. Open Source macht daraus etwas, das ein Krankenhaus-Sicherheitsteam lesen, ausführen und angreifen kann. Das ist eine andere Art von Zusicherung – und die einzige, die eine Sicherheitsprüfung übersteht.
Health-IT-Standards werden durch offene Referenzimplementierungen gewonnen. FHIR verbreitete sich, weil HAPI, öffentliche Testserver, Synthea und Connectathons die Einführung günstig und das Vortäuschen von Compliance schwierig machten. Agent-Governance wird sich auf dieselbe Weise standardisieren – oder gar nicht.
Das Bedrohungsmodell ist größer als jedes einzelne Team. Prompt Injection durch klinische Dokumente, Tenant-Isolierungsfehler, stillschweigend verworfene Suchparameter. Diese werden von vielen gegnerischen Lesern gefunden – oder gar nicht. Wir veröffentlichen unsere eigenen: einen Audit-Schreibfehler, der die Transaktion des Aufrufers zurückrollte und dabei Erfolg meldete, und eine Anmelde-Eingabe, die 8-stellige Codes auf 6 Stellen kürzte. In einem geschlossenen Produkt wären das stille Patches. Hier wurden sie zu Regressionstests.
Eine Schicht, die jeden Modellanbieter überdauern soll, sollte keinem gehören. Frontier-APIs und lokal betriebene Open-Weight-Modelle werden hinter einem einzigen Adapter zunehmend austauschbar. Was über Modellgenerationen hinweg bestehen bleibt, ist die Governance-Schicht. Gehört sie einem Anbieter, verfallen die Garantien der Patientin, wenn sich das Geschäftsmodell dieses Anbieters ändert.
Was die Community als Nächstes tun sollte
Drei Dinge – und keines davon ist ein Produkt.
Das fehlende Profil schreiben. Wir brauchen eine Möglichkeit, in FHIR auszudrücken, was ein Lesender nach dem Empfang einer Ressource damit tun darf. Nicht nur die Erlaubnis zur Weitergabe, sondern auch Aufbewahrung, Weitergabe, Inferenz und Training. R6 Permission ist der richtige Ausgangspunkt für diese Diskussion. Das Gespräch sollte in die Arbeitsgruppen getragen werden.
Auf einen Konformitätsvertrag für den Agentenzugang einigen. Schwärzen, protokollieren, eskalieren, menschlich genehmigen, Tenants isolieren, Error Fidelity wahren. Diese Liste ist angreifbar. Man ersetze sie durch eine bessere. Aber man einige sich auf etwas, gegen das ein Deployment bewertet werden kann – damit „unser Agent ist sicher" aufhört, ein nicht falsifizierbarer Satz zu sein.
Die Patientin zur Inhaberin der Richtlinie machen. Derzeit gehören die Schwärzungsregel, das Prüfprotokoll und das Genehmigungstor demjenigen, der die App geschrieben hat. Das ist für den verbrauchergesteuerten Datenaustausch falsch herum – und die Behebung ist ein Designproblem, das die Community bislang nicht ernsthaft angegangen ist.
Gesundheitsdaten sollten leicht zugänglich sein. Dieser Kampf ist weitgehend gewonnen. Der nächste besteht darin, sie sicher nutzbar zu machen – mit der Patientin als Inhaberin der Kontrollen, nicht als jemand, der danach darüber liest.
HealthClaw Guardrails ist MIT-lizenziert und klein genug, um es an einem Nachmittag zu lesen: eine Python-FHIR-Fassade, ein TypeScript-MCP-Server, etwa 1.170 Python- und 112 Node-Tests sowie die Konformitäts-Prüfroutine als CI-Gate. Es ist eine Referenzimplementierung und ein Argument – kein Produkt. Wer Aidbox betreibt: Das Beispiel klonen und versuchen, es zu brechen. Das Nützlichste, was man einsenden kann, ist eine Nutzdaten-Nachricht, die eine Kontrolle passiert, die sie nicht passieren sollte.
Beispiel: github.com/Aidbox/examples · Repository: github.com/aks129/HealthClawGuardrails · Live-Konformität: app.healthclaw.io/r6/fhir/$conformance · Consumer-App: careagents.cloud
Eugene Vestel schreibt bei FHIR IQ und moderiert den Podcast Out of the FHIR*. Health Samurai entwickelt Aidbox, eine FHIR-Plattform für Healthcare-Teams.*
