--- { "title": "[Video] FHIR Native Fine-Grained Access Control – Rostislav Antonov at FHIR DevDays 2025", "description": "FHIR-Sicherheitslabels können den Zugriff nicht nur auf ganze Ressourcen, sondern auch auf einzelne Felder einschränken. Rostislav Antonovs DevDays-Vortrag zeigt, wie dies in Aidbox funktioniert und welche Kompromisse dabei hinsichtlich Datenlecks, Performance und Schreibschutz entstehen.", "date": "2025-12-15", "author": "Rostislav Antonov", "reading-time": "23 minutes", "tags": [ "Video", "Compliance" ] } --- {% embed url="https://youtu.be/jPvkpE_tx-4" %} Dieser Beitrag ist Teil einer Reihe über Health Samurai-Sessions von den HL7 FHIR DevDays 2025. In diesem Artikel, „FHIR native fine-grained [Zugriffskontrolle](/blog/access-control-model-for-fhir-generic-server)", zeigt Rostislav Antonov, Software Engineer bei Health Samurai, wie [FHIR-Sicherheitslabels](/articles/fhir-native-fine-grained-access-control-fhir-security-labels-in-the-real-world) sensible klinische Daten schützen können, ohne die Nutzbarkeit der Datensätze für Behandlungsteams einzuschränken. **Was Sie lernen werden:** - Warum verschiedene Kliniker (zum Beispiel Psychiater im Vergleich zu Allgemeinmedizinern) unterschiedliche Ansichten desselben Patientendatensatzes benötigen. - Wie FHIR-Sicherheitslabels auf Ressourcen- und Elementebene (Feldebene) funktionieren. - Wie der Aidbox [**FHIR-Server**](https://www.health-samurai.io/fhir-server) label-basierte Zugriffskontrolle mithilfe von Datenbankfilterung und Inline-Maskierung implementiert. - Wesentliche Kompromisse in Bezug auf Datenschutz, Sicherheit, Performance und FHIR-Konformität. ## Warum Rollen nicht ausreichen Gesundheitsdaten verbinden häufig hochsensible Details (Adressen, Identifikatoren, psychiatrische Notizen) mit routinemäßigen klinischen Informationen innerhalb derselben Ressource. Eine einfache rollenbasierte Zugriffskontrolle auf ganze Ressourcen kann einem Psychiater und einem Allgemeinmediziner keine angemessen unterschiedlichen Ansichten bieten, ohne entweder zu viel zu verbergen oder zu viel preiszugeben. Das im Vortrag beschriebene Modell geht davon aus, dass das System in der Lage sein muss, bestimmte Felder auszublenden, während es den Rest der Ressource weiterhin zurückgibt – konsistent für alle Benutzer und Anwendungsfälle. ## FHIR-Sicherheitslabels in der Praxis FHIR stellt Sicherheitslabels bereit, die Vertraulichkeit und Verwendungszweck mithilfe von HL7-Codesystemen ausdrücken können. Der Vortrag unterscheidet zwischen hierarchischen Labels (zum Beispiel Vertraulichkeitsstufen, bei denen „eingeschränkt" „normal" einschließt) und flachen Labels (wie Verwendungszweck-Codes ohne Hierarchie). Labels können auf Ressourcenebene (`meta.security`) oder inline auf Elementebene über Erweiterungen gesetzt werden, was Muster wie „Psychiatrie-exklusive Beobachtungen" oder eine als standortsensibel gekennzeichnete Privatadresse ermöglicht, während eine Rechnungsadresse sichtbar bleibt. ## Zweistufige Zugriffsprüfung Die Zugriffskontrolle kombiniert Prüfungen auf Ressourcen- und Elementebene. Zunächst wird jede Ressource mit Sicherheitslabels gespeichert, und jeder Benutzer verfügt über einen Label-Satz, der aus Identität und Token abgeleitet wird. Eingehende Abfragen werden mit label-basierten Filtern umgeschrieben, sodass die Datenbank nur Ressourcen zurückgibt, deren Labels mit den Labels des Benutzers übereinstimmen. Anschließend werden Inline-Labels ausgewertet, während der Server jede Ressource durchläuft: Erlaubte Felder werden normal zurückgegeben; blockierte Felder werden durch eine `data-absent-reason`-Erweiterung ersetzt, um anzuzeigen, dass der Wert absichtlich verborgen ist. Dadurch bleiben Zugriffsregeln unabhängig vom Ressourcentyp, ohne dass doppelte Datensätze entstehen. ## Vorteile und Kompromisse Auf diese Weise eingesetzt bieten Sicherheitslabels eine fein abgestufte Kontrolle, nutzen bestehende HL7/FHIR-Standards und unterstützen sowohl rollenbasierte als auch attributbasierte Richtlinien. Gleichzeitig hebt der Vortrag wichtige Kompromisse hervor: Sichtbare „Abwesend"-Marker und Labels können offenbaren, dass verborgene Daten existieren; die Maskierung erforderlicher Elemente kann die strikte FHIR-Konformität beeinträchtigen; und das Durchlaufen auf Elementebene verursacht messbaren Performance-Overhead. Eine Zugriffsrichtlinie kann daher nicht rein technischer Natur sein – Implementierungen müssen entscheiden, wie sie Transparenz, Datenschutz und Korrektheit in Einklang bringen. ## Betriebliche Überlegungen und Demo Im Betrieb beruht das Modell auf sorgfältigem Label-Management und Auditing. Benutzer-Labels stammen aus Identitätssystemen, Clients müssen Ressourcen korrekt beschriften, und historische Daten müssen möglicherweise durch Migrationsprozesse neu gekennzeichnet werden. Ein „Break-Glass"-Label ermöglicht Notfallüberschreibungen, erfordert jedoch eine lückenlose Protokollierung. Aktuelle Implementierungen konzentrieren sich stärker auf den Leseschutz als auf die Absicherung von Schreibvorgängen wie dem Entfernen von Labels. Die Demo-Szenarien zeigen, wie JWT-basierte Labels Postman-Aufrufe steuern, bei denen ein Benutzer sowohl psychiatrische als auch allgemeine Beobachtungen sieht und ein anderer nur die allgemeinen, oder bei denen nur bestimmte Adressen sichtbar sind – und veranschaulichen so selektive Offenlegung ohne Duplizierung von Ressourcen. ![](image-1.avif) ## Wie dies FHIR-Teams hilft Für Organisationen, die FHIR-basierte Systeme implementieren, zeigt dieser Ansatz, wie standardmäßige FHIR-Sicherheitslabels das Fundament einer fein abgestuften Zugriffskontrolle bilden können, anstatt auf ein proprietäres Modell zurückzugreifen. Er demonstriert, dass Labels auf Ressourcen- und Elementebene koexistieren können, um ausdrucksstarke, interoperable Richtlinien zu unterstützen. Die explizite Auseinandersetzung mit Datenlecks, Performance und Schreibrisiken hilft Teams dabei, Implementierungen zu gestalten, die sich ihrer Kompromisse bewusst sind, anstatt Labels als vollständige Lösung zu betrachten. ## Ressourcen Sehen Sie sich Rostislavs vollständige Präsentation von den FHIR DevDays 2025 und die vollständige Health Samurai-Playlist an: [**Vollständiges Video ansehen**](https://youtu.be/jPvkpE_tx-4) [**Vollständige Playlist auf YouTube**](https://youtu.be/jPvkpE_tx-4) Vernetzen Sie sich mit Rostislav auf [**LinkedIn**](https://www.linkedin.com/in/rostislav-antonov/). Siehe auch: [RBAC mit Keycloak und SMART on FHIR V2](/blog/implementing-role-based-access-control-for-fhir-resources-with-keycloak-and-smart-on-fhir-v2).