Herausforderung: Interoperabler Daten-Export aus den Digitale Gesundheitsanwendungen (DiGA)
Die Digitalisierung im Gesundheitswesen hat zu einer Vielzahl von digitalen Unterstützungen und Ergänzungen in der Versorgungslandschaft geführt. Den Digitalen Gesundheitsanwendungen (DiGA) kommt hier eine besondere Rolle zu, da sie als „App auf Rezept in der Hand der Versicherten“ in der Lage sind, das Gesundheitshandeln des Einzelnen in das Versorgungsgeschehen zu integrieren und auch den Informationsaustausch zwischen Patient:innen und Leistungserbringern zu erleichtern.
Interoperabilität ist ein entscheidender Faktor in diesem Kontext. Sie bezieht sich auf die Fähigkeit von verschiedenen DiGA und den bestehenden Systemen, miteinander zu kommunizieren und Daten auszutauschen. In einer idealen digitalen Gesundheitslandschaft können DiGA verlustfrei Daten mit elektronischen Patientenakten, anderen Gesundheitsanwendungen und medizinischen Informationssystemen austauschen. Dies würde es Patient:innen und medizinischem Fachpersonal ermöglichen, auf genaue und umfassende Informationen zuzugreifen, die für eine nahtlose individuelle Gesundheitsversorgung wichtig sind – und so das Zielbild einer bruchlosen Patient Journey über die Sektorengrenzen hinweg realisierbar wird.
Voraussetzung ist die verbindliche Anwendung von Regeln, was strukturelle, syntaktische, semantische und organisatorische Interoperabilität gewährleistet und eine standardisierte Dokumentation und in darauf aufbauend einen universellen Austausch von medizinischen Daten in bspw. DiGA sicherstellt. Die Digitale-Gesundheitsanwendungen-Verordnung (DiGAV) schreibt gemäß § 5 Absatz 1 vor, dass Digitale Gesundheitsanwendungen (DiGA) die zum bestimmungsmäßigen Gebrauch von ihnen verarbeiteten Daten in interoperablem Format ausspielen können:
„Insbesondere muss die digitale Gesundheitsanwendung ermöglichen, dass von der digitalen Gesundheitsanwendung verarbeitete Daten in geeigneten interoperablen Formaten exportiert und im Rahmen der Versorgung genutzt werden können.“
Dieser Schritt ermöglicht es, Daten in geeigneten interoperablen Formaten auszuspielen und somit einen reibungslosen Datenaustausch und eine bessere Zusammenarbeit zwischen verschiedenen Anbietern und Akteuren im Gesundheitswesen zu ermöglichen.
Die Anlage 2 zur DiGAV bindet insgesamt 3 konkrete Anforderungen an den § 5 Absatz 1 DiGAV:
1. Datenexport für Versicherte
Die über die digitale Gesundheitsanwendung verarbeiteten Daten können durch den Versicherten aus der digitalen Gesundheitsanwendung in einem interoperablen Format (Syntax und Semantik) exportiert und dem Versicherten für die weitere Nutzung bereitgestellt werden [Anlage 2, Anforderung 1, DiGAV]
2. Relevante Gesundheitsdaten sind menschenlesbar und ausdruckbar
Der Versicherte kann für seine Versorgung relevante Auszüge der über die digitale Gesundheitsanwendung verarbeiteten Gesundheitsdaten, insbesondere zu Therapieverläufen, Therapieplanungen, Therapieergebnissen und durchgeführten Datenauswertungen, aus der digitalen Gesundheitsanwendung exportieren. Der Export erfolgt in einem menschenlesbaren und ausdruckbaren Format [Anlage 2, Anforderung 1, DiGAV]
3. Übermittlung in die ePA
Die digitale Gesundheitsanwendung ermöglicht es dem Versicherten ab dem 1. Januar 2024, die von der digitalen Gesundheitsanwendung verarbeiteten Daten mit seiner Einwilligung jederzeit in seine elektronische Patientenakte zu übermitteln. [Anlage 2, Anforderung 1, DiGAV]
Für die Exportanforderungen 1 und 3 ist das einzig als geeignet angesehene interoperable Format das von dem MIO42 spezifizierte DiGA MIO (Festlegungen für die semantische und syntaktische Interoperabilität von Daten in der elektronischen Patientenakte nach § 355 Absatz 2a des Fünften Buches Sozialgesetzbuch gemäß § 6 DiGAV). Seit dem Juli 2023 muss die Version 1.1.0 des DiGA MIO verwendet werden, die unter https://simplifier.net/dtk veröffentlicht ist.
Interoperabilitätsstandard: Der DiGA-MIO-Baukasten
Die Entwicklung von Interoperabilitätsstandards wie dem DiGA-MIO-Baukasten (Baukasten von Medizinischen Informationsobjekte) wurde vorangetrieben, um sicherzustellen, dass Gesundheitsdaten einheitlich und strukturiert ausgetauscht werden können. Dieser Standard legt fest, wie Gesundheitsdaten organisiert und präsentiert werden sollen, um die Kommunikation zwischen verschiedenen DiGA und Gesundheitsinformationssystemen zu erleichtern.
Das DiGA MIO ist ein modularer Baukasten aus insgesamt 74 Ressourcendefinitionen – 44 Profildefinitionen (StructureDefinition), 17 Kodiersysteme (CodeSystem), 8 Wertemengen (ValueSet), eine Mappingtabelle (ConceptMap) und 4 Profilerweiterungen (Extension) – die aus standardisierten FHIR-Ressourcentypen abgeleitet sind. Jede dieser Profildefinitionen beschriebt, wie ein bestimmter fachlicher Baustein (z. B. Patient, Diagnose, Therapieplan, Aktivität, Fragebogen, Tagebucheintrag) unter Verwendung von definierten Kodiersystemen, Wertemengen oder Erweiterungen dargestellt wird. Die Vorgaben umfassen dabei neben den anzugebenden Attributen (z. B. Status der Abarbeitung eines Trainingsplans) oftmals auch die hierbei zu verwendenden Terminologien. Beispielsweise darf für die grobgranulare Klassifizierung von Aktivitäten nur eine festgelegte Untermenge der Codes aus der International Classification of Functioning, Disability and Health (ICF) verwendet werden. Diese Untermenge wurde in der o. g. Wertemenge definiert. Hiermit soll sichergestellt werden, dass jede Anwendung, die die aus einer DIGA exportierten Daten einliest, auch die Semantik dieser Daten erfassen kann (z. B., dass es sich um eine Aktivität aus dem Bereich der Körperpflege handelt).
Was ist ein MIO?
Ein medizinisches Informationsobjekt (kurz: MIO) ist eine Ansammlung von Informationen zu medizinischen, strukturellen oder administrativen Sachverhalten, die in sich geschlossen oder entsprechend verschachtelt vorliegt. Zudem ist ein MIO ein klar definierter Standard dafür, wie diese Informationssammlung in der ePA gespeichert wird, wodurch eine grundlegende semantische und syntaktische Interoperabilität sichergestellt wird.
Konkrete Beispiele für MIOs sind die elektronische Impfdokumentation, das elektronische Kinderuntersuchungsheft, der elektronische Mutterpass oder das elektronische Zahnbonusheft.
Quelle: gematik (2021): MIO-Baukasten Anleitung zur Umsetzung von MIOs in der elektronischen Patientenakte (ePA).
Einzelne dieser Profildefinitionen müssen für jede DiGA verwendet werden (z. B. Ressourcen für den Patient und zur Beschreibung der DiGA), während die Nutzung anderer Ressourcen von den Datenverarbeitungen der konkreten DiGA abhängt. So ist es möglich, von einer Orthopädie-DiGA über ein Diabetestagebuch bis zu einer verhaltenstherapeutischen App alle denkbaren Arten von DiGA mit dem gleichen Satz von Bausteinen abzudecken.
Die wesentliche Herausforderung bei der Definition und Implementierung des Datenexports aus einer DiGA ist, die in der DiGA verarbeiteten Daten und ihre Querbeziehungen geeignet auf die oftmals sehr restriktiv definierten Bausteine des DiGA-MIO-Baukastens abzubilden. Im Prinzip ist das so als hätte man 44 verschiedene Arten von Legosteinen (blaue 4er, gelbe 8er-Plättchen, rote 3er-Ziegel etc.), aus denen man das Brandenburger Tor nachbauen soll. Was es dazu braucht, ist ein konkreter Bauplan, der darstellt, wie die Daten der DiGA ggf. neu zu kombinieren sind, um so einen den gesetzlichen Anforderungen entsprechenden Export zu realisieren – oder um im Beispiel zu bleiben: am Ende ein Gebäude gebaut zu haben, das das BfArM als Brandenburger Tor erkennt. Und was die Folgen eines mangelhaften Bauplans sind, zeigen Projekte wie beispielweise der BER oder Stuttgart 21.
_fbeta hat hierzu eine Methodik entwickelt und erfolgreich bei verschiedenen DiGA angewandt, mit der das bestehende Informationsmodell einer DiGA schrittweise in eine DiGA-MIO-kompatibles Exportmodell überführt werden kann. Das Ergebnis ist ein konkreter „Bauplan“, an dem der DiGA-Hersteller ablesen kann, welches Feld aus seiner Datenbank an welcher Stelle in das zu exportierende Geflecht von MIO-Bausteinen einzufügen ist.
Schnelle, flexible und aufwandsarme Anwendung des MIO-Baukastens
Die Ableitung des DiGA-Exports erfolgt nach der _fbeta-Methodik in den nachfolgend dargestellten 6 Schritten:
Ausgangsmodell
Schritt 1: Ableitung des formalisierten Ausgangsmodells des DiGA-Exports
Ausgangspunkt ist immer das Informationsmodell der DiGA, d. h. die in der DiGA verarbeiteten Informationen mitsamt ihrer Querbezüge. Aus dem Informationsmodell leiten wir ein formalisiertes Ausgangsmodell für den DiGA-Export ab. Hierzu werden die Vorgaben der DiGAV zum Umfang des Exports angelegt, um z. B. für den Export nicht relevante Daten auszublenden.
Schritt 2: Optimierung und Anpassung des Ausgangsmodells
Der nächste Schritt ist eine schrittweise Optimierung des Ausgangsmodells, z. B. durch Zusammenfassen oder Aufspalten von in der DiGA verarbeiteten Daten, Vereinfachen von Querbezügen und Auflösen von Kompositionen zu Aggregationen bzw. Referenzen. Hierbei wird bereits berücksichtigt, welche Informationsbausteine über den DiGA MIO Baukasten gut abbildbar sind und welche Muster sich bei welchen Klassen von DiGA bewährt haben. Das so entstandene UML-Klassenmodell bildet die zu exportierenden Inhalte der DiGA strukturiert ab und wird in einem Workshop mit dem DiGA-Hersteller daraufhin überprüft, dass die Semantik der verarbeiteten Daten und deren Zusammenhänge dem fachlichen Modell der DiGA entsprechen.
Zielmodell
Schritt 3 und 4: Transformation des Ausgangsmodells in das FHIR-basierte Zielmodell und Feinabstimmung des Zielmodells des DiGA-Exports
Anschließend erfolgt die Überführung des Ausgangsmodells in das Zielmodell. Dieses ist ebenfalls als UML-Klassenmodell modelliert. Die Herausforderung hierbei ist, dass das Zielmodell inhaltlich dem Ausgangsmodell entsprechen muss, aber hier nur Klassen verwendet werden dürfen, die auf den Bausteinen des DiGA MIO Baukastens basieren. Faktisch wird damit das logische Modell der DiGA in zwei Schritten in das FHIR-basierte Domänenmodell des DiGA MIO Baukastens transformiert. Während der dritte Schritt im Wesentlichen aus der Auswahl und Zusammenstellung passender Bausteine besteht, werden im vierten Schritt die einzelnen Bausteine betrachtet. Bei der hier durchzuführenden Profilierung werden nicht benötigte Attribute ausgeblendet, Wertemengen kodierter Werte auf die Vorgaben der DiGA angepasst und für alle Export-Instanzen einheitliche Daten mit konstanten Werten belegt.
Schritt 5: Vielfalt und Flexibilität im Zielbild
Oftmals gibt es mehrere Möglichkeiten, das Ausgangsmodell auf ein DiGA-MIO-konformes Zielmodell abzubilden. Beispielsweise können Bewertungen des Patienten zu einer durchgeführten physiotherapeutischen Übung als Antwortsatz zu einem Fragebogen, als Gruppe strukturierter Beobachtungen oder auch als Freitext aus der DiGA ausgespielt werden. Im fünften Schritt bilden wir solche Varianten im Modell ab und diskutieren mit den Entwicklern des DiGA-Herstellers, welche Variante sich am einfachsten aus den bestehenden Datenbanken heraus umsetzen lässt.
Wichtig dabei ist, dass es immer eine 1:1-Abbildungsvorschrift vom Ausgangsmodell zum Zielmodell und allen seinen Varianten gibt. Nur so ist sichergestellt, dass ein Export entlang des Zielmodells aus dem bestehenden Datenbankschemata heraus einfach umsetzbar ist. Auch sind so Weiterentwicklungen der DiGA gut abbildbar, da z.B. Änderungen ohne Einfluss auf das Ausgangsmodell auch keine Änderung des Zielmodells und damit des Exports zur Folge haben. Bei Änderungen der DiGA, die das Ausgangsmodell betreffen, ist hingegen über die 1:1-Abbildung sofort erkennbar, welche Teile des Exports anzupassen sind.
Ergebnis-Artefakte
Schritt 6: Praktische Werkzeuge und Dokumentation für den DiGA-Export
Aus dem mit dem DiGA-Hersteller abgestimmten Zielmodell heraus erstellen wir eine Reihe von Artefakten, die dem DiGA-Hersteller die Implementierung des Exports ermöglichen:
- Als Tabellen strukturierte Schablonen beschrieben, welches Attribut einer Klasse aus dem Ausgangsmodel wie auf ein bestimmtes Element einer FHIR-Ressourcendefinition des DiGA-MIO-Baukastens abzubilden ist und welche Bezüge zwischen den Ressourcen aus dem fachlichen Ausgangsmodell heraus herzustellen ist.
- Ein kommentiertes Beispiel des kompletten Exports der Daten einer prototypischen Nutzungssequenz der DiGA verdeutlicht, wie das resultierende FHIR-XML nach Anwendung der Schablonen auf dem Informationsmodell der DiGA aussieht.
- Viele der Ressourcendefinitionen des DiGA-MIO-Baukastens verlangen, dass bestimmte Informationen über definierte Codes aus bestehenden Terminologien kodiert werden. Beispielsweise existiert für die Auszeichnung eines Werts als durch den Patienten dokumentierte Stärke des Schmerzes bei der Ausführung einer Übung der LOINC-Code 38208-5. Wir definieren für die DiGA für alle kodierten Werte die entsprechenden Wertemengen und stellen diese als FHIR ValueSet Ressource sowie über die beim BfArM als Teil der Antragstellung abzugebende Excel-Tabelle (siehe nächster Spiegelstrich) bereit. Sofern es verpflichtend zu kodierende Inhalte des Exports keine bestehenden Codes gibt, definieren wir für den DiGA-Hersteller eine passende Terminologie als FHIR CodeSystem-Ressource und dokumentieren diese BfArM-konform.
- Das konkrete Exportformat muss vom Hersteller der DiGA über eine vom BfArM bereitgestellte Excel-Tabelle dokumentiert werden. Diese Excel-Tabelle muss bei der Antragstellung zur Aufnahme in das DiGA-Verzeichnis eingereicht werden. Wir erstellen aus dem Zielmodell heraus für den Hersteller eine abgabefertige Excel-Tabelle.
- Ausgangs- und Zielmodell mitsamt ihren Optimierungen und Varianten sind über UML-Klassendiagramme (PlantUML) dokumentiert und werden in einer Dokumentation des Exportformats ausführlich erläutert.
Fazit
Wir haben die beschriebene Methodik über die letzten zwei Jahre erfolgreich bei mehreren DiGA-Herstellern angewandt und dabei beständig weiterentwickelt und an die sich verändernden Vorgaben zur Anwendung des DiGA-MIO-Baukastens angepasst (z. B. neue Regeln zur Ableitung der Attribute eines Patienten bei Nutzung der GesundheitsID). Durch die dabei entstandenen Muster, Schablonen und Good Practices können wir DiGA-Herstellern heute bei der Umsetzung der Verpflichtungen aus der DiGA-Verordnung extrem schnell, flexibel und aufwandsarm unterstützen.
Wenn Sie Ihre DiGA-Export-Implementierung sicher beschleunigen und vereinfachen möchten, sprechen Sie uns an.
Weitere Informationen zum Market Access von DiGA & DiPA finden Sie hier.
