Roeland Luykx
RALY GmbH, Präsident HL7 Benutzergruppe Schweiz
Das deutschsprachige HL7 Magazin
Das deutschsprachige HL7 Magazin
von Roeland Luykx
Im Zuge der Digitalisierung im Gesundheitswesen werden Austauschformate aufbauend auf internationale Standards immer wichtiger, um strukturierteInformationen auszutauschen, abzulegen oder im Zusammenhang mit Empfehlungssystemen (Clinical Decision Support Systems CDSS) zu verarbeiten.
Wer hat auch schon seinen Impfausweis aus Papier gesucht – zumindest in derSchweiz gibt es einen Offiziellen aus Papier – bzw. wer musste wegen einesNotfalls ins Spital und hatte den Impfausweis nicht bei sich und hat einen neuen erhalten? Im Klein- kindes- und Kindesalter sind die Impfungen durch den Kinderarzt bzw. durch die Schulimpfungen abgedeckt und meist auch kontrolliert. Doch ist das auch später noch der Fall? Vermutlich bei einem Grossteil der Bevölkerung nicht, und die Ärzte fragen oft nicht automatisch nach.
Spätestens seit der Corona Pandemie haben viele ihre Impfausweise gesucht, umdie Corona Impfung eintragen zu lassen. Viele werden sich gefragt haben, wieso esdafür keine Applikation für das Smartphone gibt – das hat man ja immer bei sich.
Der Bedarf an Informationen und das zu jeder Zeit an jedem Ort ist gestiegen. Genau hier setzt die Digitalisierung an, und es braucht einheitliche Schnittstellen und Datenformate, die dies auch ermöglichen. HL7 trägt hier im e-Health Bereich mit seinen Standards Wesentliches bei, um den Datenaustausch zu vereinheitlichen.
CDA als Vorreiter
Im Jahr 2011 ist die zentrale Impfplattform meineimpfungen.ch in der Schweiz online gegangen. In den nachfolgenden Jahren wurde dann – HL7 FHIR steckte da noch in den Kinderschuhen – ein Austauschformat eVACDOC in HL7 CDA entwickelt und publiziert (CDA-CH- VACD, siehe ART-DECOR). Ende 2016 stand das Austauschformat in der Plattform für die Anbindung von Praxis Information Systemen (PIS) zur Verfügung und wurde auch entsprechend eingesetzt, um die Impfdaten zu aktualisieren. Aufgrund von Sicherheitslücken musste die Plattform meineimpfungen.ch im Frühjahr 2021 abgestellt werden.
Im Jahr 2020 wurde eine aktualisierte Version des CDA-Austauschformates publiziert. In dieser Version wurden fünf verschiedene Dokumententypen unterschieden (siehe Die Dokument Typen):
Diese Version ist in der Schweiz nie produktiv eingesetzt worden. ELGA und HL7 Austria haben jedoch auf diesen Grundlagen aufgebaut und ihr eigenes CDA-Austauschformat «Elektronischer Impfpass» (eImpfpass) definiert.
Abbildung 1: Elemente eines Immunization Administration Document
HL7 FHIR, die Zukunft
Die Corona Pandemie hat uns die Thematik der Digitalisierung – provokativ formuliert der fehlenden Digitalisierung –deutlich aufgezeigt. Strukturierte Daten und deren Austausch waren notwendig, um eine Übersicht zu behalten. Weltweit wurde uns dieser Mangel besonders im Gesundheitswesen deutlich aufgezeigt. Der Standard HL7 FHIR hat dadurch eine noch grössere Bedeutung erlangt.
Die ersten Arbeiten ein entsprechendes Impfaustauschformat auch in FHIR zu spezifizieren, wurden gegen Ende 2020 inAngriff genommen und durch e-Health Suisse finanziert. Der dazu erstellte FHIR-Leitfaden (Implementation Guide, IG) wurde mit einem informativen Ballot abgenommen und im Juni 2021 als STU1 Version 1.0.0 publiziert (ch-vacd).
In diversen Diskussionen, insbesondere auch rund um das Elektronische Patienten Dossier (EPD), welches in der Schweiz eingeführt wurde und auch als Ersatz der abgestellten Impfplattform dienen sollte, haben sich Anpassungen der Anwendungsfälle abgezeichnet. Es wurde dabei auch der Entscheid gefällt, das alte CDA-Format fallenzulassen und die Überarbeitung des Leitfadens ohne Rücksicht auf die Kompatibilität zum CDA in Angriff zu nehmen. Dabei wurde die Zahl der Dokumenttypen auf vier reduziert. Die daraus resultierende STU2 wurde ballotiert und als Version 2.0.0 im Februar 2021 publiziert. Weitere Anpassungen folgten und sind als STU3 nun in Ballot Resolution und sollte bis Ende Jahr als Version 3.0.0 publiziert werden.
Die Dokument Typen
Es wurden vier Dokumenttypen, die aus den Anwendungsfällen heraus entstanden sind, definiert, undentsprechend wurden dafür FHIR- Profile erstellt.
Es sind diese folgende Typen:
Immunization Administration Document
Das Immunization Administration Document ist ein FHIR-Bundle des Typs Es enthält eine Composition Ressource mit den verschiedenen Sektionen
und den Referenzen auf die verschiedenen FHIR-Ressourcen Immunization, Condition, Observation und AllergyIntolerance, wie in der Abbildung 1 dargestellt.
Das Vaccination Record Document ist wie das Immunization Administration Document ein FHIR-Bundle des Typs document. Inhaltlich unterscheiden sich die beiden Profile nicht. Ihnen kommt in der Anwendung jedoch eine andere Bedeutung zu. Im Abschnitt Immunization Administration vs. Vaccination Record wird näher darauf eingegangen.
Immunization Recommendation Request
Der Immunization Recommendation Request ist ein FHIR-Bundle des Typs message. Es enthält eine MessageHeader Ressource mit den benötigten Informationen sowie Einträgen aus den FHIR-Ressourcen Immunization, Condition, Observation und AllergyIntolerance, um einen Recommendation Request an ein entsprechendes Klinisches Support System (CDSS) schicken zu können (siehe Abbildung 2).
Immunization Recommendation Response
Der Immunization Recommendation Response ist ein FHIR-Bundle des Typs message. Es enthält eine MessageHeader Ressource mit den benötigten Informationen, sowie Einträge aus FHIR-Ressourcen des Typs ImmunizationRecommendation. Dieses Profil beschreibt die strukturierte Antwort eines Klinisches Support System (CDSS) auf einen Immunization Recommendation Request.
Abbildung 2: Elemente eines Immunization Recommendation Request Dokument
Immunization Administration vs. Vaccination Record
Weshalb müssen zwei verschiedene Dokumenttypen definiert werden, wenn der Inhalt identisch sein kann? Weil es Abläufe gibt, die die Unterscheidung nötig machen:
Alle Dokumente, die oben erwähnt wurden, sind Immunization Administration Dokumente, welche einen Input dokumentieren, sei es eine Impfung, eine Allergie oder ein Laborresultat. Man kann argumentieren, dass das doch alles mit einem Dokument gemacht werden könnte – sprich bestehendes Dokument mit den neuen Angaben ergänzen – doch bei verteilten Ablagen und eingeschränkten Lese- und Schreibberechtigungen sind schnell unüberwindbare Hürden gegeben.
Dieses Problem wird durch den Aggregator (siehe Abbildung 3) gelöst, welcher aus einer Ansammlung von Immunization Administration Dokumenten ein einziges Vaccination Record Dokument erstellt. Dabei müssen einige Regeln beachtetwerden, insb. bei doppelter Erfassung eines einzigen Ereignisses. Dazu wurde eine entsprechende Extension definiert,welche es zulässt, Duplikatskonflikte zu markieren.
Abbildung 3: Aggregation von Dokumenten
Impfempfehlung
Das Immunization Recommendation Request Dokument beinhaltet die gleichen Informationen wie auch die bei den anderen Dokumente, mit dem Unterschied, dass es nicht vom Typ «Dokument» ist, sondern vom Typ «Message». Das Request Bundle kann z. B. unter Anwendung eines auf CDS Hooks basierenden API an ein Medizinisches Support System (CDS) geschickt werden (siehe Abbildung 4).
Abbildung 4: Impfcheck
Das System setzt entsprechende Regeln für eine Impfempfehlung (z. B. CH Impfplan) um. Als Antwort gibt das Systemeine Impfempfehlung ab. Bei der Verwendung des CDS Hooks Standards sind die einzelnen Impfempfehlungen in Cards formuliert, es können aber auch strukturierte Informationen wie ein Immunization Recommendation Response Dokument in die Antwort verpackt werden.
Ein solches Impfempfehlungssystem wird derzeit bei uns in der Schweiz realisiert und als Medizinprodukt in den realen Einsatz gelangen.
Semantik
Die Zusammenstellung aller fachlich relevanter Codes in entsprechende Code Systeme und Value Sets sowie entsprechen Übersetzungen in die verschiedenen Landessprachen (deutsch, französisch und italienisch; rätoromanisch ist noch offen) nimmt viel Zeit in Anspruch und schliesslich die Essenz des Ganzen. Seit der Erarbeitung der Version 2 haben wir versucht, vermehrt auf den Austausch auch über die Landesgrenze hinweg zu achten und möglichst alles mittels Codes aus LOINC und SNOMED CT abzudecken.Während dieses Prozesses wurden auch neue Codes bei SNOMED beantragt. Da auch dieser Prozess jeweils eine gewisse Zeit dauert, konnten wir noch nicht alle Value Sets aktualisieren.
Fazit
Die Umsetzung eines Austauschformates fordert oft eine gute Analyse der möglichen Anwendungsfälle und braucht oft mehr als eine Version, bis ein guter Maturitätslevel erreicht werden kann. Sehr wichtig sind dabei eine hohe Anwendungsnähe mit entsprechendem Feedback.
Roeland Luykx
RALY GmbH, Präsident HL7 Benutzergruppe Schweiz
Bildnachweis: © Prostock-studio/stock.adobe.com