Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

TI-Messenger Strukturierte Daten

Version
1.0.0_CC
Revision
1443227
Stand
02.12.2025
Status
zur Abstimmung freigegeben
Klassifizierung
öffentlich_Entwurf
Referenzierung
gemF_TI-M_Strukturierte_Daten

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Dieses Dokument "TI-Messenger - Feature Strukturierte Daten" beschreibt die Erweiterungen an der TI-Messenger Spezifikation, die benötigt werden, um einen interoperablen Austausch von strukturierten Daten sicherzustellen.  

1.1 Zielsetzung

Im Gesundheitswesen sind reibungslose Kommunikation und der verlässliche Austausch von Informationen entscheidend für die Qualität der Versorgung. Doch genau hier liegt eine der größten Herausforderungen: Wichtige medizinische und organisatorische Daten werden häufig in uneinheitlichen Formaten und über unterschiedliche Systeme hinweg ausgetauscht. Das führt nicht nur zu Medienbrüchen, sondern auch zu Verzögerungen, Missverständnissen und zusätzlichem Arbeitsaufwand, der wertvolle Zeit kostet – Zeit, die bei der Behandlung von Patientinnen und Patienten fehlt.

Ein Beispiel aus der Praxis verdeutlicht das Problem: Eine Hausärztin möchte von einer neuen Patientin wichtige Informationen zur Krankengeschichte einholen und sendet ihr dafür einen Anamnesebogen. Doch in der Realität wird dieser Vorgang häufig durch unstrukturierte Prozesse erschwert. Der Fragebogen wird entweder als PDF verschickt, das die Patientin ausdrucken, ausfüllen und zurücksenden muss, oder die Antworten müssen später manuell in das Praxisverwaltungssystem übertragen werden. Dieser Medienbruch birgt ein hohes Risiko für Fehler, kostet Zeit und erschwert die direkte Weiterverarbeitung der Daten in den IT-Systemen der Ärztin. Zudem ist nicht sichergestellt, dass die Patientin den Fragebogen korrekt empfängt oder dass alle relevanten Informationen vollständig zurückgespielt werden.

Mit der Erweiterung des TI-Messengers um die Möglichkeit, strukturierte Daten sicher und interoperabel zu übertragen, wird genau hier angesetzt. Ziel ist es, den Austausch von Informationen zwischen den Akteuren im Gesundheitswesen zu standardisieren und zu vereinfachen. Durch die Nutzung etablierter Standards wie ISiK, MIOs oder weiterer abgestimmter Datenformate, werden medizinische Inhalte einheitlich in strukturierter Form übermittelt. Das schafft die Grundlage dafür, dass Daten direkt in die bestehenden Systeme der Empfänger integriert und dort automatisiert weiterverarbeitet werden können. Der manuelle Aufwand wird minimiert, die Fehleranfälligkeit reduziert und der Austausch beschleunigt.

Zudem wird durch neue Mechanismen sichergestellt, dass der Austausch von strukturierten Daten zuverlässig funktioniert. Absender können sich darauf verlassen, dass ihre Nachrichten nicht nur zugestellt, sondern auch korrekt verarbeitet werden. Sollte dies nicht der Fall sein, erhalten sie eine transparente Rückmeldung und können gezielt nachsteuern. Gleichzeitig wird der interoperable Austausch zwischen verschiedenen Herstellern und Systemen durch Mechanismen unterstützt, die sicherstellen, dass Sender und Empfänger dieselbe „Sprache“ sprechen. Dies ermöglicht eine reibungslose Kommunikation, auch wenn unterschiedliche Systeme aufeinandertreffen.

Die Erweiterung des TI‑Messengers löst damit konkret die Probleme, die bislang den digitalen Austausch von Gesundheitsdaten erschweren. Sie stellt sicher, dass medizinische Informationen schnell, sicher und ohne Medienbrüche dort ankommen, wo sie benötigt werden – und legt zugleich die Basis für fachliche Verfahren, die auf klar beschriebenen, veröffentlichten Strukturen wie ISiK‑ und MIO‑Datensätzen beruhen. Wiederkehrende Versorgungsszenarien – vom digitalen Anamnesebogen bis hin zu weiteren standardisierten Inhalten – können so als verlässliche, intersektorale Workflows im TI‑Messenger abgebildet werden: mit transparenter fachlicher Rückmeldung, eindeutiger Zuordnung und nahtloser Integration in bestehende Primärsysteme. Das stärkt die Zusammenarbeit zwischen Ärztinnen und Ärzten, Praxisteams, Kliniken und Patientinnen und Patienten und bringt die Versorgung spürbar voran.

1.2 Zielgruppe

TI-Messenger Hersteller, Anbieter, Nutzer und andere Stakeholder.

1.3 Abgrenzungen

Das Dokument beinhaltet nur neue bzw. geänderte Anforderungen. Die vollständige Anforderungslage für die Produkttypen des TI-Messengers und den Anbieter des TI-Messengers ergeben sich aus den Produkttypsteckbriefen, dem Anbietersteckbrief und den darin referenzierten Anforderungen.

1.4 Methodik

Dieses Dokument ist ein Konzept und bereitet die spätere Spezifikation vor. Es beschreibt den aktuellen Diskussions- und Entscheidungsstand zum Feature „Strukturierte Daten“ im TI‑Messenger und veranschaulicht dessen fachliche wie technische Ausprägung. Ziel ist es, frühzeitig ein gemeinsames Verständnis herzustellen, zentrale Annahmen transparent zu machen und strukturiertes Feedback aus der Praxis einzuholen.

Im Mittelpunkt steht die frühe Abstimmung mit den Gesellschaftern sowie die Einbindung weiterer relevanter Stakeholder. Auf diese Weise werden fachliche Anforderungen, technische Lösungsansätze und Abgrenzungen so konkretisiert, dass sie als belastbare Grundlage für die anschließende Normierung dienen. Durch das frühzeitige Einbeziehen der Perspektiven – insbesondere zu Datenschutz und Informationssicherheit – wird die spätere Kommentierung der Spezifikation vereinfacht und beschleunigt.

Das konsolidierte Feature‑Konzept wird von den Gesellschaftern beschlossen und – im Benehmen mit dem BfDI und dem BSI – als verbindliche Basis für die Spezifikation herangezogen. Die Spezifikation wird anschließend aus dem beschlossenen Konzept abgeleitet und normativ ausgeformt. Auf diese Weise basieren die späteren Festlegungen auf einem abgestimmten, tragfähigen Fundament.

2 Neue Funktionalitäten

In den folgenden Kapiteln werden die neuen Funktionalitäten beschrieben, die mit dem Feature eingeführt werden sollen.

2.1 Statusabfrage einer Anfrage

In der Interaktion von unterschiedlichen Systemen ist es notwendig den aktuellen Verarbeitungsstatus austauschen zu können, damit unter Umständen kompensierende Maßnahmen gestartet werden. Hierzu wird im Rahmen dieses Featuredokumentes ein Nachrichtenschema definiert, dass für eine Statusabfrage genutzt werden kann. Details finden sich im Technischen Konzept unter: 3.1 Abfrage des Verarbeitungsstatus von Events.

2.2 Kompabilitätsabfragen

Für den automatisierten, zuverlässigen Datenaustausch ist es notwendig zu Wissen, welche Sprache spricht eigentlich der Kommunikationspartner. Aus diesem Grund führen wir im Rahmen dieses Featuredokumentes die Kompatibilitätsabfragen ein, damit ein Client bei einem anderen Client abfragen kann, welche Events von diesem verstanden werden. Details zu den Eventtypen und dem Ablauf finden sich in Kapitel 3.2 Abfrage der Unterstützung von Events.

2.3 Etablierung und Veröffentlichung von Fachverfahren und Verfahrenskennungen

Im Gesundheitswesen reichen einzelne standardisierte Datensätze – etwa aus ISiK und MIO – allein nicht aus, um wiederkehrende, intersektorale Abläufe verlässlich abzubilden. Fachverfahren schaffen hier eine semantische Klammer: Sie benennen Zweck und Geltungsbereich eines konkreten Versorgungsszenarios und definieren, welche strukturierten Datensätze in welcher Ausprägung zum Einsatz kommen. Analog zu KIM können solche Fachverfahren künftig von Akteuren des Gesundheitswesens und der Industrie etabliert und abgestimmt werden, wobei FHIR‑basierte Datensätze die technische Umsetzung tragen.

Im TI‑Messenger werden diese strukturierten Inhalte als klar gekennzeichnete Nachrichten transportiert. Die Kennzeichnung erfolgt über den Event‑Typ, der einer Nachricht mitgegeben wird; bei FHIR‑basierten Inhalten präzisiert das im Content‑Block de.gematik.msc4302.fhir.structure_definition angegebene Profil (url, version) Format und fachliche Bedeutung. So erfährt das empfangende System, welche Information die Nachricht kodiert, kann sie eindeutig zuordnen und automatisiert weiterverarbeiten – ohne manuelle Nacharbeiten oder proprietäre Zuordnungen. Die im TI‑M verfügbaren Mechanismen zur Abfrage von Unterstützung und Verarbeitungsstatus stellen zudem sicher, dass Sender und Empfänger dasselbe Verständnis eines Fachverfahrens teilen und Rückmeldungen transparent erfolgen.

Um eine konsistente und interoperable Nutzung von Fachverfahren innerhalb der Telematikinfrastruktur zu gewährleisten, veröffentlicht die gematik Datensätze für Verfahrenskennungen zentral im Fachportal. Diese Referenz macht Verfahren eindeutig adressierbar, hält den aktuellen Stand versioniert bereit und stellt weiterführende Informationen zur Verfügung.

3 Technisches Konzept und Spezifikation

3.1 Abfrage des Verarbeitungsstatus von Events

Zentrales Instrument dieses Teilkonzeptes ist [MSC4300]. Dieses MSC definiert einen Mechanismus, mit dem Absender den Verarbeitungsstatus eines Events von Empfängern anfordern können. Hierzu wird auf dem betroffenen Event ein zusätzlicher Content-Block de.gematik.msc4300.request.status gesetzt, welcher die absendende Device-ID und eine optionale Lebensdauer enthält.

Ein empfangender Client beantwortet die Anfrage mit einem Event de.gematik.msc4300.response.status.

Details zum Schema der Events bzw. Content-Blöcke können [MSC4300] entnommen werden.

Der Content-Block zur Anfrage des Verarbeitungsstatus ist modular und kann auf beliebigen Event-Typen verwendet werden. Eine Verpflichtung hierzu besteht für TI-M Clients jedoch nicht. Die gematik gibt lediglich das zuvor beschriebene Verfahren vor, damit diese Anfragen bei Bedarf und in spezilisierten Anwendungsfällen verwendet werden können um Kompatibilität zu gewährleisten.

Damit diese Funktion sinnvoll nutzbar ist, ist es allerdings erforderlich, dass empfangene Anfragen beantwortet werden. Daher werden alle TI-M Clients hierzu verpflichtet.

Absendene Clients sollten Anfragen zum Verarbeitungsstatus nicht mit jedem beliebigen Event verschicken sondern nur in Fällen, in denen die Kenntnis des Verarbeitungsstatus essenziell ist. Dies wird üblicherweise nur bei proprietären Events oder Dateien mit speziellem Inhalt der Fall sein. So wäre es z. B. unsinnig den Verarbeitungsstatus von reinen Text- oder Bild-Nachrichten zu erfragen, da alle TI-M Clients diese Nachrichten ohnehin unterstützen sollten. Werden andererseits komplexere Inhalte wie z. B. serialisierte FHIR-Resourcen versendet, kann es sinnvoll sein, den Verarbeitungsstatus anzufragen um sicherzustellen, dass der empfangende Client die Inhalte verstanden hat.

Für Mitarbeiter im Gesundheitswesen kann es hilfreich sein unbekannte Events bei Bedarf manuell weiterzuverarbeiten, z. B. indem die Inhalte in ein PVS oder anderes Drittsystem exportiert werden. Dazu ist es erforderlich, dass solche Events in TI-M Pro Clients angezeigt und mit der Möglichkeit zur Einsicht der Rohdaten versehen werden. Die folgende Abbildung zeigt exemplarisch die Anzeige eines unbekannten Events durch einen Matrix Desktop Client und die darauffolgende die Visualisierung des Inhalts des unbekannten Events. 

Abbildung 1: Visualisierung unbekanntes Event (Matrix Desktop Client)

Abbildung 2: Visualisierung von Event-Inhalten

3.2 Abfrage der Unterstützung von Events

Dieses Teilkonzept basiert auf [MSC4301] und ermöglicht TI-M Clients vorab zu erfragen welche Events andere Clients unterstützen. Hierzu wird ein neues Event vom Typ de.gematik.msc4301.request.event_capability eingeführt. Dieses Event enthält den Content-Block de.gematik.msc4300.request.status aus dem vorherigen Kapitel zur Abfrage des Verarbeitungsstatus. Zusätzlich enthält das Event einen Content-Block de.gematik.msc4301.request.event_capability, in welchem die abzufragenden Events aufgelistet sind.

Empfangende Clients beantworten die Anfrage gemäß des vorangegangenen Kapitels mit einem de.gematik.msc4300.response.status Event. Dabei geben sie in einem neuen Content-Block de.gematik.msc4301.response.event_capability die Untermenge von Events aus dem ursprünglichen Event an, die sie unterstützen.

Ähnlich zum vorigen Kapitel besteht auch hier keine Verpflichtung zum Senden der Abfragen. Damit die Abfragen bei tatsächlichem Bedarf sinnvoll nutzbar sind, werden aber alle TI-M Clients zur Antwort verpflichtet.

3.3 Versand von FHIR-Resourcen

Dieses Teilkonzept basiert auf [MSC4302] und ermöglicht den Versand beliebiger FHIR-Resourcen in Matrix-Events. Hierzu wird ein neuer Event-Typ de.gematik.msc4302.fhir eingeführt. Im Content der zugehörigen Events werden in einem Content-Block de.gematik.msc4302.fhir.structure_definition Metadaten zum Profil der Resource angeführt. Diese können zum einen zur präventiven Abfrage der Unterstützung gemäß des vorigen Kapitels eingesetzt werden. Zum anderen können sie auch beim Verarbeiten von de.gematik.msc4302.fhir Events herangezogen werden. Neben den Metadaten, kann die Resource selbst in den Content aufgenommen werden, wahlweise in eingebetteter Form oder als Datei.

TI-M Clients können de.gematik.msc4302.fhir Events nach eigenem Bedarf verwenden. Die gematik behält sich allerdings vor für bestimmte essentielle Anwendungsfälle die Unterstützung spezieller FHIR-Profile zu erzwingen. Ein erster solcher Fall sind Fragebögen. Damit diese flächendeckend eingesetzt werden können, werden TI-M ePA Clients dazu verpfichtet Fragebögen darstellen und ausfüllen zu können. Als zugrundeliegendes Profil werden die Formulare aus ISiK 5.0.0 gewählt.

3.4 Beispiel

Zur Verdeutlichung werden die drei zuvor eingeführten Teilkonzepte im Folgenden in einem Beispiel-Szenario eingesetzt.

Abbildung 3: FHIR Questionnaire Statusabfrage über Matrix Teil I

Abbildung 4: FHIR Questionnaire Statusabfrage über Matrix Teil II

4 Anhang A – Verzeichnisse

4.1 Abkürzungen

4.2 Abbildungsverzeichnis

4.3 Tabellenverzeichnis

4.4 Referenzierte Dokumente

4.4.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

4.4.2 Weitere Dokumente