Text in FHIR-Ressourcen

6 März 2023

von René Spronk, HL7 Niederlande

Übersetzt und übertragen von Kai U. Heitmann

Der FHIR-Standard legt fest, dass alle FHIR-Ressourcen mit einer textuellen Zusammenfassung versehen sein sollten. Was ist der Zweck dieses Textes? Wie muss man diesen Text füllen?

Ein Blick auf Ressourcen in FHIR-Projekten zeigt, dass diese normalerweise keine textliche Zusammenfassung beinhalten. Nach FHIR-Standard sollten (SHOULD) alle Ressourcen allerdings immer Text für die menschliche Lesbarkeit von FHIR-Ressourcen enthalten. Grahame Grieve, der ursprüngliche Schöpfer von FHIR, präferierte sogar, dass Text erforderlich ist (SHALL, siehe Interview)

Der Text (Resource.text) ist in erster Linie ein Fallback-Mechanismus für einen Empfänger, der strukturierte Daten einer Ressource nicht verarbeiten kann. In diesem Fall kann einem menschlichen Leser der Text angezeigt werden. Man denke zum Beispiel an eine einfache App, die nur wenige Ressourcentypen unterstützt, weil sie nur zur Überwachung bestimmter Blutwerte gedacht ist. Wenn diese App beispielsweise einen hochspezialisierten Ressourcentyp wie MolecularSequence verarbeiten müsste, dann kann diese App damit nichts anfangen, könnte aber einem menschlichen Nutzer der App wenigstens den Text zeigen und damit noch Interoperabilität erreichen.

Die Verwendung dieser Fallback-Option in Textform ist eine Lehre aus den vielen Implementierungen des HL7 Clinical Document Architecture (CDA)-Standards. Die Popularität dieses Standards war teilweise das Ergebnis der Möglichkeit, Text zu verwenden. FHIR hat die Verwendung von Text absichtlich nicht auf FHIR-Dokumente beschränkt, sondern verpflichtet ihn auch für REST-, Dokumenten- und nachrichtenbasierten Austausch von Ressourcen.

Verpflichtung zur Verwendung von Text

Solange man sich in einem begrenzten Kontext befinden – wie z. B. ISiK bzw. ISiP (Informationstechnische Systeme im Krankenhaus bzw. in der Pflege) oder einem medizinischen Informationsobjekt (MIO) Impfpass – dort, wo jeder Beteiligte genau die gleichen Ressourcen und FHIR-Profile basierend auf derselben FHIR-Version unterstützt, dann bringt Text keinen großen Mehrwert. Aus diesem Grund sehen wir auch, dass Softwareanbieter, die in einem so begrenzten Kontext arbeiten, den Textteil der verwendeten FHIR-Ressourcen nicht füllen, teilweise weil Text streng genommen nicht obligatorisch ist (SHOULD).

Die Vergangenheit hat gezeigt, dass Gesundheitsdaten, die zunächst in einem begrenzten Kontext ausgetauscht werden, später in einem breiteren Kontext (wieder)verwendet werden. Man kann dann nicht mehr davon ausgehen, dass Systeme alle Datenelemente verstehen, die in einer Ressource vorhanden sind. Sie unterstützen die verwendeten FHIR-Profile nicht, unterstützen eine andere (höhere) Version von FHIR, kennen die verwendeten Erweiterungen nicht oder verarbeiten die Ressourcen Jahre nach ihrer Erstellung. Generell gilt: je weiter man sich vom ursprünglichen Kontext der Ressource entfernt, desto schwieriger wird es, die darin enthaltenen strukturierten Daten richtig zu interpretieren, desto weniger Vertrauen kann man in die Qualität der bereitgestellten Daten haben und desto größer ist der Bedarf einer textuellen Zusammenfassung.

Tatsächlich hätte Grahame Grieve es lieber gesehen,
dass Text obligatorisch ist.

Ein System wie ISiP wird die zuvor erwähnte MolecularSequence-Ressource nicht verarbeiten können, da diese nicht im Anwendungsbereich des Systems liegt. Gesundheitssysteme werden sicherlich versuchen, häufig verwendete Ressourcentypen, die nicht offiziell zu ISiK oder ISiP gehören, bis zu einem gewissen Grad zu unterstützen, aber selbst dann müssen sie häufig auf den in Ressourcen vorhandenen Text zurückgreifen.

Kurzfristig fürchten Gesundheitsorganisationen und Softwareanbieter die Kosten für die Entwicklung von Software, um den Textteil von Ressourcen zu füllen, was angesichts des derzeit begrenzten Kontexts von FHIR-Projekten verständlich ist. Dies steht jedoch im Widerspruch zu der langfristigen Erwartung, dass Ressourcen außerhalb ihres ursprünglichen Kontexts verwendet werden: Text ist dann erforderlich.

Inhalt des Textes

Wenn in einer Ressource Text vorhanden ist, sollte dieser den wesentlichen Inhalt der Ressource zusammenfassen. Ein Gesundheitsdienstleister sollte handeln können, wenn ihm nur die Textversion einer FHIR-Ressource gezeigt wird. Der FHIR-Standard sagt nichts darüber aus, wie eine „gute“ Zusammenfassung (engl.: clinically safe summary) aussehen muss. Profile und Implementierungsleitfäden könnten jedoch Anforderungen daran stellen. So hat Nictiz in den Niederlanden eine allgemeine Empfehlung ausgesprochen, was der Text befassen sollte. Sie basiert auf den fünf Ws:

Was – Art der Ressource, Status der in Ressource beschriebenen Aktivität, Art der Aktivität: Worauf sind Sie allergisch? Von welchem Verfahren sprechen wir?
Wer – der Patient, der Autor, andere Hauptakteure, die an der in der Ressource beschriebenen Aktivität beteiligt sind
Wann – handelt es sich um Daten aus der Vergangenheit oder um zukünftige Aktivitäten?
Warum – was ist dem vorausgegangen, zum Beispiel ein Problem oder ein Hinweis?
Wo – Ort, an dem die dokumentierte Aktivität stattgefunden hat, stattfindet oder stattfinden wird.
Kontext – andere kontextbezogene Informationen zur Aktivität, wie z. B. Erfassungsdaten, Diagnosen, Zustände.

Mittlerweile ist diese Empfehlung auch in der Spezifikation der International Patient Summary (IPS) aufgenommen. Sicherlich möchte man nicht alle Details aller Datenelemente in den Text aufnehmen. Zusätzlich zu den oben genannten fünf Ws könnte man sich auch solche Datenelemente ansehen, die in einer Ressourcendefinition obligatorisch sind, oder die eine Eigenschaft haben, die darauf hinweist, dass sie von besonderer Bedeutung sind. Dies sind zum Beispiel Datenelemente, die das Zusammenfassungssymbol (Sigma-Label) haben oder in einem Profil als Must support oder Is modifier deklariert sind. Datenelemente, die ausschließlich für die Verarbeitung durch Software bestimmt sind, wie kanonische URLs und logische IDs, sollten niemals in den Text aufgenommen werden.

Jede Ressource, die eine DomainResource ist (alle Ressourcen außer Bundle, Parameter und Binary), kann eine für Menschen lesbare Beschreibung enthalten, die eine Zusammenfassung der Ressource enthält.

Beispiel

Der Text muss manchmal auf dem Inhalt mehrerer Ressourcen basieren. Beispiele:

eine Textzusammenfassung eines Rezepts muss normalerweise eine gute Beschreibung des verschriebenen Medikaments enthalten.
Im Text einer Maßnahme möchten Sie wissen, wer diese durchgeführt hat – nicht nur den Namen des Arztes, sondern auch das Fachgebiet dieses Arztes und die Organisation, für die dieser Arzt arbeitet.

Generell sollte der Text so verfasst werden, dass er nicht speziell für einen Kontext relevant ist, damit die Ressource auch in anderen Kontexten verwendet werden kann.

Aspekte der Implementierung

Systeme können selbst entscheiden, wie Ressourcen mit einer textuellen Zusammenfassung versehen werden. Text sollte vom Quellsystem einer Ressource oder einem System erstellt werden, welches denselben Kontext wie das Quellsystem hat. Diese Systeme wissen am meisten über den Kontext, kennen die verwendeten Profile, die Value Sets und die verwendeten Erweiterungen. Das Erstellen einer Textzusammenfassung muss vom Sender erzeugt werden. Einem Empfänger kann es nicht überlassen werden, denn er versteht womöglich nicht alle strukturierten Daten in einer Ressource und kann somit keinen treffenden Text erzeugen.

Regeln zur Zugriffssteuerung können verhindern, dass ein FHIR-Server den gesamten Text zurückgibt, was bedeutet, dass ein Server tatsächlich Text in dem Moment generieren muss, in dem er abgefragt wird. Ein neuer Text muss auch generiert werden, wenn sich etwas an der Ressource ändert.

Gesundheitsdaten haben lange (gesetzliche) Aufbewahrungsfristen und aus diesem Grund sollte der Text so formatiert sein, dass er unabhängig vom Browser und der Art des Bildschirms, auf dem der Text angezeigt wird, eindeutig wiedergegeben wird. Formatierungsmöglichkeiten von HTML und CSS sollten daher vorsichtig eingesetzt werden. Der Fokus liegt besser auf dem Inhalt und nicht auf dem Layout.

Die Verwendung einer oder mehrerer der im FHIR-Standard genannten Formatierungsoptionen bedeutet nicht, dass Empfänger diese einhalten müssen.

Tabellen sollten nur verwendet werden, wenn die Daten ein tabellarisches Format haben, und nicht als Entwurfswerkzeug. Als Alternative reicht oft ein Satzbau oder eine Liste. Eine Tabelle, die aus zwei Zeilen oder zwei Spalten besteht, von denen eine die Namen von Datenelementen enthält, ist fast immer ein Zeichen dafür, dass eine Tabelle nicht angebracht ist.
Systeme, die Text generieren, sollten sich darüber im Klaren sein, dass ein Empfänger mit Ressourcen aus mehreren Systemen arbeiten muss, von denen jedes seine eigene Formatierung verwendet, um den Text zu strukturieren. Einige Texte wurden möglicherweise vor Jahren erstellt. Man möchte ein einheitliches Design für alle Texte. Dies ist in der Praxis nicht durchführbar, eine solche Konsistenz kann nicht garantiert werden.

Das automatische Generieren von Text ist komplex, insbesondere für internationale Softwareanbieter, die mit allen Arten von Profilen, mehreren Sprachen und grammatikalischen Unterschieden im Satzbau zu tun haben. Mehrere FHIR-Server und -Tools verfügen über konfigurierbare Textgeneratoren für FHIR-Ressourcen, die die Textgenerierung erleichtern.

Zusammenfassung

Die Verwendung von Text in FHIR ist notwendig, wenn Ressourcen außerhalb ihres ursprünglichen Kontexts verwendet werden. Man kann nicht erwarten, dass alle Systeme in allen Kontexten die Details aller Ressourcentypen aus (alten) FHIR-Versionen korrekt verarbeiten oder alle verwendeten FHIR-Profile und Erweiterungen kennen. Text zu generieren bedeutet für aktuelle Systeme mehr Arbeit, aber dieser Aufwand zahlt sich auf lange Sicht aus.

Momentan wiegt offensichtlich der kurzfristige Nachteil der Textgenerierung schwerer als die langfristigen Vorteile durch das Versehen von Ressourcen mit Text. Erwartungsgemäß wird FHIR noch überall und lange für alle Arten von Projekten eingesetzt. Es liegt daher an uns als Nutzern von FHIR, der Verwendung von Text in FHIR-Ressourcen mehr Priorität einzuräumen.

Der Text erschien zuerst im Mitteilungsheft „HighLights“, HL7 Niederlande, Ausgabe 19 vom Januar 2023. Mit freundlicher Genehmigung des Autors und der Redaktion können wir den Text hier veröffentlichen.

Autor

René Spronk
HL7 Niederlande