Telematikinfrastruktur: 5 Anforderungen, die Software-Hersteller beachten müssen

Die Telematikinfrastruktur (TI) ist eine Plattform bzw. ein Netzwerk, über das in Deutschland Gesundheitsdaten sicher ausgetauscht werden und auf der Gesundheitsanwendungen wie die elektronische Patientenakte und das e-Rezept betrieben werden sollen.

Dieser Beitrag hilft Herstellern medizinischer Software zu verstehen, wann sie welche gesetzlichen und technischen Anforderungen im Kontext dieser Telematikinfrastruktur erfüllen müssen.

1. Zusammenfassung: Anforderungen der Telematikinfrastruktur an die Hersteller

Gesetze führen direkt oder indirekt (über die Betreiber) zu Anforderungen, die für Hersteller medizinischer Software relevant sind:

1. Anforderungen an gesetzlich definierte Schnittstellen nach ISiK
   Falls ihre Produkte zu den „bestätigungsrelevanten Systemen“ zählen, müssen sie eine Schnittstelle implementieren und dabei z. B. die Spezifikation des ISiK-Basismoduls beachten. Dazu weiter unten mehr.
2. Anforderungen an strukturierte Datensätze bezüglich MIO
   Falls die Hersteller Daten in die elektronische Patientenakte (ePA) schreiben oder darauf zugreifen wollen, müssen deren Produkte ebenfalls medizinische Informationsobjekte (MIO) austauschen können.
3. Anforderungen an „Informationstechnische Systeme im Gesundheitswesen“
   Hersteller sonstiger IT-Systeme wie DIGA, Krankenhaus- und Praxisverwaltungssysteme sind nicht mehr frei in der Wahl der Interoperabilitätsstandards. Diese gibt die gematik vor.
4. Anforderungen an Implantate und Hilfsmittel
   Produkte, die im Kontext der Implantate oder als Hilfsmittel Daten übertragen, müssen unter bestimmten Voraussetzungen auch standardisierte Schnittstellen für Digitale Gesundheitsanwendungen anbieten.
5. Anforderungen an Kommunikationsstandards im Kontext KIM und TIM
   Nicht durch das Gesetz, sondern durch die Kunden (Krankenhäuser, niedergelassene Ärzte) getrieben, sollten Hersteller die Kommunikation durch KIM und TIM ermöglichen.

2. Übersicht über die Telematikinfrastruktur 

a) Ziele

Einer der ersten Treiber der Telematikinfrastruktur war der Wunsch, Fehlbehandlungen sowie unerwünschte Neben- und Wechselwirkungen von Medikamenten zu minimieren.

Aktuell verfolgt die TI einen eher normierenden Ansatz zur Digitalisierung im Gesundheitswesen. Sie soll das digitale Gesundheitswesen technisch ins 21. Jahrhundert bringen und so zur Verbesserung der Gesundheitsversorgung beitragen.

Die Telematikinfrastruktur soll die notwendigen Voraussetzungen schaffen, um

• einen sicheren Datenaustausch zu gewährleisten (IT-Security),
• den Datenschutz zu ermöglichen (Data Protection, Confidentiality),
• die Verfügbarkeit der Daten sicherzustellen (Availability),
• die Interoperabilität der Systeme zu gewährleisten (Interoperability),
• die Aufwände und Kosten zu senken (Efficiency).

Diese Voraussetzungen sollen dazu beitragen, dass

• Innovationen erfolgen, z. B. im Bereich der IT-Systeme, bei medizinischen Dienstleistungen oder bei der Gestaltung medizinischer Prozesse,
• die Effizienz im Gesundheitswesen steigt, und zwar sowohl bei der Entwicklung als auch bei der Nutzung dieser Produkte und Dienstleistungen, und
• die Forschung Zugang zu den notwendigen Daten erhält.

b) Aufbau

Die Telematikinfrastruktur wird vereinfacht als Datenautobahn für das Gesundheitswesen bezeichnet (z. B. von der KBV). Diese Infrastruktur besteht aus Hardware und Software, die gemeinsame Regeln befolgen müssen, z. B. zur Interoperabilität. 

Zur Hardware zählen: 

• Sogenannte Konnektoren (spezielle Router)
• Karten zum Authentifizieren: elektronische Gesundheitskarte (eGK), elektronischer Heilberufeausweis (eHBA) und Karten zum Identifizieren von Institutionen wie Krankenhäusern (SMC)
• Kartenlesegeräte
• Computer zum Betreiben von Diensten

Die Software realisiert die Dienste:

• Zentrale Dienste: Verzeichnisdienste, PKI-Dienste, VPN-Zugangsdienste, …
• Mehrwertdienste (Dritter), also Anwendungen wie die elektronische Patientenakte (ePA), das elektronische Rezept (eRezept) und die elektronische Arbeitsunfähigkeitsbescheinigung (eAU)

c) Grundsatz der Patientenhoheit

Nach den gesetzlichen Anforderungen (SGB) soll die Telematikinfrastruktur Behandlungsdaten von Patienten zu den einzelnen Leistungserbringern übermitteln. Dazu wurden und werden Datenspeicher aufgebaut – zunächst nur für gesetzlich Versicherte, inzwischen aber auch für die meisten privat krankenversicherten Bürger.

Auch wenn diese Daten nicht beim Patienten abgespeichert sind, ist es dennoch ein Grundsatz, dass nur dieser darüber entscheiden darf, wer welche Daten erheben oder verarbeiten darf.

3. Begrifflichkeiten im Kontext der Telematikinfrastruktur

a) Dienste und Anwendungen

Eine Infrastruktur hat nur dann einen Wert, wenn sie die relevanten „Use Cases“ unterstützt. Für die Telematik sind unter anderem die folgenden (Mehrwert-)Dienste vorgesehen, die die KBV als „Anwendungen“ bezeichnet:

• eRezept: Damit sollen verschreibungspflichte Medikamente verordnet und von den Apotheken abgegeben werden können.
• Elektronische Patientenakte (ePA): Dieses zentrale Element soll Daten aller Gesundheitsdienstleister (Krankenhäuser, niedergelassene Ärztinnen und Ärzte, Therapeuten) umfassen, um so den (intersektoralen) Datenaustausch zu fördern.
• Elektronische Arbeitsunfähigkeitsbescheinigung (eAU): Damit sollen die gelben Zettel der Vergangenheit angehören. Ärztinnen und Ärzte können diese Bescheinigungen direkt digital an Krankenkassen und Arbeitgeber übermitteln.
• Notfalldatenmanagement (NFDM): Auf der elektronischen Gesundheitskarte (eGK) sollen die Daten gespeichert werden, die Ärztinnen und Ärzte in einem Notfall benötigen. Beispiele sind Diagnosen und Medikamente.
• Elektronischer Medikationsplan: Ebenfalls auf der eGK sollen alle Medikationsdaten gespeichert werden, damit alle Beteiligten den Überblick bewahren und z. B. Medikamentenwechselwirkungen und Doppelmedikationen erkennen können.

Eine vollständige Übersicht der „Anwendungen“ finden Sie auf den Seiten der KBV und der gematik.

Dass diese Dienste verfügbar gehalten werden, ist nicht Aufgabe der gematik, sondern die ihrer Betreiber. Das sind kommerzielle Firmen wie ITSG, IBM und RISE. Über diese Verfügbarkeit gab es Klagen; auch die gematik berichtete über Störungen.

KIM

Die gematik zählt auch die Kommunikationsdienste KIM und TIM zu den Anwendungen.

Das Akronym KIM steht für Kommunikation im Medizinwesen. Es soll dem Austausch strukturierter und unstrukturierter medizinischer Informationen wie Labordaten, Arztbriefen (eArztbrief) und eAUs dienen.

KIM ist ein sicherer E-Mail-Dienst über die Telematikinfrastruktur. Dazu nutzt es bewährte Protokolle wie http, SMTP und POP. Die Telematikinfrastruktur stellt einen Verzeichnisdienst bereit, quasi ein Adressbuch möglicher Empfänger.

Von „normaler“ E-Mail unterscheidet sich KIM in einigen Punkten:

• Alle E-Mails sind durch die TI verschlüsselt und signiert.
• Der Dienst unterstützt derzeit nicht das Protokoll IMAP. Damit ist die Synchronisation von E-Mails auf mehreren Endgeräten nicht möglich.
• Nur an die TI angeschlossene Clients können KIM-Nachrichten senden und empfangen. Das schließt Mobiltelefone derzeit aus.
• Die Vergabe von E-Mail-Adressen erfolgt zentral durch den jeweiligen Anbieter und ist an die Institution gebunden.
• Die E-Mails sollen auch dem automatisierten Austausch zwischen Systemen dienen. Beispielsweise kann ein Praxisverwaltungssystem ohne den üblichen E-Mail-Client eine KIM-Nachricht mit einer elektronischen Arbeitsunfähigkeitsbescheinigungen verschicken.

TIM

TIM steht für Telematikinfrastruktur-Messenger. Er soll eine sichere und legale Alternative zu WhatsApp & Co. bieten. Die gematik hat dafür die Schnittstellen spezifiziert.

TIM eignet sich für den kurzen und schnellen Informationsaustausch: die Rückfrage zu einem Rezept, den Hinweis für einen Patienten, eine Nachricht an mehrere Kollegen („Broadcast“).

Der Messenger erlaubt derzeit nur den Versand von unstrukturierten Informationen, konkret Textnachrichten sowie Bild- und Tonübertragung. Er setzt auf das REST-basierte Matrix-Protokoll, das neben dem Instant-Messaging auch Bildgespräche von zwei oder mehr Nutzern erlauben würde. Das soll in einer weiteren Ausbaustufe für Videochats zwischen Ärzt:innen und Patient:innen genutzt werden.

Im Gegensatz zu KIM kann der Messenger auf Smartphones betrieben werden.

b) MIO

Übersicht

Die medizinischen Informationsobjekte (MIO) gleichen Legosteinen, aus denen sich komplexere Informationsgebilde wie die elektronische Patientenakte aufbauen lassen. Derzeit sind oder werden die folgenden MIOs spezifiziert:

• Impfpass
• Krankenhaus-Entlassbrief
• Mutterpass
• Patientenkurzakte
• Untersuchungsheft (für Kinder)
• Zahnärztliches Bonusheft
• Telemedizinisches Monitoring

Die KBV hat eine Übersichtsseite zu den MIOs erstellt. Von der gematik stammen die Spezifikation sowie die Anleitung zur Umsetzung von MIOs in der ePA.

Beispiel: Impfpass

Möchte ein Hersteller in der ePA die Impfinformationen abspeichern, muss er das MIO Impfpass gemäß der Spezifikation der KBV nutzen. Diese Spezifikation setzt auf FHIR.

Sie beschreibt die zu verwendenden FHIR-Ressourcen, z. B. KBV_PR_MIO_Vaccination_Bundle_Entry. Sie legt die Attribute mit Kardinalitäten und Datentypen fest.

Beispielsweise muss die Impfung („Immunization“) genau einen Patienten referenzieren und sowohl die Charge („lotNumber“) als auch den Impfstatus (z. B. „completed“) angeben.

Die Charge und das Impfdatum sind MIO-Elemente des MIO-Modells „elektronische Impfdokumentation“ („Immunization“). 

Eine konkrete Impfdokumentation für einen spezifischen Patienten bildet ein MIO-Dokument (XML-Format). Im Gegensatz zum elektronischen Kinderuntersuchungsheft enthält das MIO-Dokument für die Impfdokumentation keine MIO-Teildokumente. Der Satz der konkreten Werte für ein (Teil-)Dokument bildet einen MIO-Eintrag.

c) ISiK

Für die Informationstechnischen Systeme in Krankenhäusern (ISiK) Stufe 1 legt die gematik ebenfalls eine Schnittstellenspezifikation vor. Diese ISiK-Spezifikation definiert auf Basis von FHIR-Profilen Datenobjekte wie Patient und Diagnose.

Damit müssen konforme Systeme übliche Funktionalitäten anbieten wie:

• Patienten suchen, z. B. anhand von Attributen wie Name, Adresse, Geburtsdatum
• Die Diagnosen eines Patienten abfragen (mit Code, Datum usw.)
• Den aktuellen Fall anhand einer Fallnummer finden (weiter unten mehr)

Das wiederum dient

• dem Austausch von Daten zwischen den Systemen innerhalb eines Krankenhauses (zwischen Primärsystemen, zwischen Primär- und Subsystemen und ab Stufe 2 „sogar“ mit Apps),
• der Integration von Anwendungen außerhalb des Krankenhauses in die Krankenhaussysteme und
• der Anbindung von Medizin-/Messgeräten.

Die gematik nutzt eigene Profile und nicht die der KBV bzw. Medizininformatik-Initiative. Die Begründung finden Sie auf dieser Seite ganz unten.

d) ISiP

Neben dem ISiK befasst sich die gematik auch mit dem ISiP (Informationssystem für Pflegeleistungserbringer). Das ISiP soll Arbeitsabläufe in Pflegeeinrichtungen sowie die Archivierung und Übertragung der Stamm- und Pflegedaten digital unterstützen. Die gematik entwickelt hierfür standardisierte Schnittstellen zur Anbindung von ambulanten und klinischen Anwendungen und Datenbanksysteme.

Diese Informationssysteme werden von den Profilen des ISiK abgeleitet. Daher gelten Kompatibilitätsbetrachtungen des ISiK ebenfalls für das ISiP. Auch Hersteller von ISiP-Systemen kommen daher nicht mehr um eine FHIR Schnittstelle herum.

4. Gesetzliche Anforderungen

a) § 355 SGB V: Anforderungen u. a. an die ePA und damit an die MIOs

Der erste Absatz des § 355 SGB V ermächtigt die KBV, die Schnittstellen für die ePA (und damit für die MIOs), für den elektronischen Medikationsplan und die elektronischen Notfalldaten festzulegen. 

b) § 371 SGV V: Anforderungen an Systeme zur Verarbeitung personenbezogener Daten

§ 371 SGB V eröffnet den Reigen an Gesetzen mit „Anforderungen an Schnittstellen in informationstechnischen Systemen“. Er beschränkt sich nicht auf klinische Systeme. Vielmehr ist er für alle Systeme relevant, die personenbezogene Daten in der vertragsärztlichen Versorgung (bei Niedergelassenen), in Krankenhäusern sowie bei der pflegerischen Versorgung verarbeiten.

§ 371 SGB V fordert standardisierte Schnittstellen, um auf die Systeme zugreifen können, für die Medikationsverordnung sowie für ambulante und klinische „Anwendungs- und Datenbanksysteme“ (sprich: Arztpraxisverwaltungs- und Krankenhaus-Informationssysteme).

c) § 372 SGB V: Anforderungen an die Praxisverwaltungssysteme

Vergleichbar mit dem folgenden § 373 SGB V für Krankenhäuser trifft der § 372 SGB V „Festlegungen zu den offenen und standardisierten Schnittstellen für informationstechnische Systeme in der vertragsärztlichen und vertragszahnärztlichen Versorgung“. 

d) § 373 SGB V: Anforderungen an die ISiK

§ 373 SGB V bildet die gesetzliche Grundlage für die ISiK. Er ist überschrieben mit „Festlegungen zu den offenen und standardisierten Schnittstellen für informationstechnische Systeme in Krankenhäusern und in der pflegerischen Versorgung“.

Die „bestätigungsrelevanten Systeme“ sind momentan die Primärsysteme in den Krankenhäusern. Die Deutsche Krankenhausgesellschaft kann weitere Subsysteme bestimmen. 

Weitere Hinweise zu den bestätigungsrelevanten Systemen, z. B. zu Kommunikationsservern, finden sich im Implementierungsleitfaden des ISiK-Basismoduls.

e) § 374 a SGB V: Anforderungen an einige Hilfsmittel und Implantate

§374 a SGB V trägt den Titel „Integration offener und standardisierter Schnittstellen in Hilfsmitteln und Implantaten“. Er fordert, für bestimmte Produkte Datenschnittstellen auch für Drittanbieter (Anbieter von DIGAs) zu öffnen.

Dieser Artikel ist nicht unumstritten.

f) GIGV

Die IOP-Governance-Verordnung ermächtigt die gematik, die Interoperabilitätsstandards zu vereinheitlichen. Denn die einzelnen Interoperabilitätsstandards erlauben viele Freiheiten. Um die Programmierung zu erleichtern, kann die gematik die Standards also „standardisieren“. Die von ihrem Expertengremium publizierten Standards werden für die Hersteller verpflichtend. 

Für die o. g. Anwendungsfälle sind diese Standards bereits bestimmt.

g) KHZG

Das Krankenhauszukunftsgesetz KHZG ist in dieser Liste in doppelter Hinsicht eine Besonderheit. 

Zum einen ist es ein Gesetz, das viele Gesetze ändert, insbesondere das Krankenhausfinanzierungsgesetz und mehrere Sozialgesetzbücher.

Zum anderen ist es ein Gesetz, das die Hersteller nur indirekt betrifft. Denn das Gesetz legt Fördertatbestände fest. Das sind Projekte, für die die Krankenhäuser Fördergelder enthalten. Viele dieser Fördertatbestände dienen der besseren Digitalisierung der Krankenhäuser:

• Anpassung der technischen bzw. informationstechnischen Ausstattung der Notaufnahme eines Krankenhauses an den jeweils aktuellen Stand der Technik
• Patientenportale wie das digitale Aufnahmemanagement, Behandlungsmanagement, Entlass- und Überleitungsmanagement
• Digitale Pflege- und Behandlungsdokumentation
• Einrichtung von teil- oder vollautomatisierten klinischen Entscheidungsunterstützungssystemen
• Digitales Medikationsmanagement
• Digitale Leistungsanforderung
• Informationstechnische, kommunikationstechnische und robotikbasierte Anlagen, Systeme oder Verfahren und telemedizinische Netzwerke

Um diese Fördergelder zu erlangen, haben die meisten Krankenhäuser ein oder mehrere Projekte beantragt bzw. initiiert. Sie kommen aber nur in den Genuss der Fördergelder, wenn die Systeme die o. g. gesetzlichen Voraussetzungen erfüllen.

Damit profitieren Hersteller medizinischer Software nur von dem Nachfrageboom, wenn ihre Systeme zu den förderwürdigen Tatbeständen zählen und die gesetzlichen Anforderungen erfüllen.

5. Offene Wünsche

a) Wirkliche Interoperabilität

Die gematik hat mit der TI Interoperabilität versprochen. Doch es gibt noch Bedarf zur Nachbesserung:

• Die TI funktioniert nur mit einem veralteten und beschränkten Konnektor. Das Problem ist bekannt und wird angegangen.
• Es gibt Lücken auf der semantischen Ebene, die noch geschlossen werden.
• Die organisatorische Ebene ist unvollständig. Übergreifende Workflows und Berechtigungskonzepte fehlen zumindest teilweise. Die Umsetzung von IHE XDS ist unvollständig.
• Der eindeutige Patienten-Identifikator wurde durch die KVNR ersetzt, über die nicht alle Bürger verfügen und die auch nicht eineindeutig ist.
• Der (derzeitige) Fokus auf Arztpraxisverwaltungs- bzw. Krankenhausinformationssysteme, die über einen Konnektor angeschlossen sind, ist per se eine Einschränkung der Interoperabilität. Diese Beschränkung ist bekannt und wird angegangen.
• Trotz aller Bemühungen um Interoperabilität auch über Landesgrenzen hinweg bleibt die TI ein deutsches Gewächs, das keine durchgängige europaweite Interoperabilität schafft.

b) Usability

Um von den Vorteilen einer TI profitieren zu können, sind die Hürden teilweise hoch. Das betrifft sowohl die implementierenden Hersteller als auch die Anwender.

Selbst das viel gepriesene KIM muss ohne IMAP auskommen. Wie will man Anwendern erklären, dass sie gefühlt wieder in den 1990er-Jahren angekommen sind, wo man E-Mails nur auf einem Client speichern kann? Hier ist keine Lösung in Sicht, auch weil der Datenschutz im Weg steht.

c) IT-Sicherheit

Die IT-Sicherheit der Systeme wurde genauso oft versprochen wie widerlegt. Es muss klar sein, dass jedes IT-System gehackt werden kann. Aber angesichts der Bemühungen um den Datenschutz und der Einschränkungen, die man diesbezüglich akzeptieren muss, verwundert es, wenn oft peinlich große Lücken klaffen, wie von c’t berichtet oder dem CCC aufgedeckt.

Auch die Häufigkeit, mit der Systeme wie Konnektoren und Backendsysteme nicht verfügbar sind, schadet der Initiative.

d) Funktionalität

Viele Use Cases werden noch nicht unterstützt, an vielen Stellen mangelt es an Funktionalitäten. So ist die Aussage, dass die Telematikinfrastruktur eine Fallnummernsuche ermöglicht, nur bedingt korrekt.

Die Fallnummern vergeben die Gesundheitsdienstleister bzw. deren IT-Systeme. Externe Systeme kennen also weder die Fälle noch deren Nummern. Daher müssen Externe die Patienten direkt suchen können. Aber aufgeben kann und will man die Fallnummern nicht, da die Fälle für die Ärzte und (Medizin-)Controller eine wichtige Klammer bilden.

Um Funktionalität zu erreichen, wird man als Ergebnis in ISiK 2 wohl eine Anpassung bzgl. der Fallnummer in den FHIR-Standardprofilen vorschlagen.

6. Fazit

a) Es geht weiter …

Die Schlinge für die Hersteller von medizinischen Informationssystemen zieht sich enger – zumindest im Bereich der Interoperabilität. Das ist aber auch gut. Denn offensichtlich hat der Markt es nicht vermocht, die Voraussetzungen für die Digitalisierung zu schaffen: Standardisierte Schnittstellen, die auch genutzt werden.

Erst der gesetzliche Zwang und die Motivation mit Geld (KHZG) haben Bewegung in die Digitalisierung des Gesundheitswesens gebracht.

Spätestens die TI 2.0 wird (weitgehend) vollständig mit strukturierten Daten arbeiten und somit zum Standard im deutschen Gesundheitswesen werden.

b) … nach einem Jahrzehnt des peinlichen Stillstands

Es ist auch „nur“ eine Digitalisierung und noch keine digitale Transformation oder gar digitale Revolution. Denn Technologien und Standards wie REST und E-Mail sind zwar bewährt. Sich aber dafür zu feiern, dass man diese nun auch im Gesundheitswesen etabliert, würde in anderen Ländern eher Verwunderung auslösen.

Aber es nützt nichts, darüber zu klagen, dass man über ein Jahrzehnt verschlafen hat, dass viele Protagonisten ein peinliches Bild abgeben und die Einführung einer Telematikinfrastruktur behindert und verzögert haben.

Wer noch im Jahr 2021 ein Digitalisierungsmoratorium fordert, nachdem Deutschland auf die hinteren Ränge bei der Digitalisierung abgerutscht ist, ist möglicherweise nicht Teil der Lösung, sondern Teil des Problems.

c) Die Hersteller sind gefordert und gefördert

Wir stehen da, wo wir stehen. Die Hersteller tun gut daran, die gesetzlichen Anforderungen an die Interoperabilität zu erfüllen. Spätestens ab 2024 kann sich diesen Anforderungen keiner mehr entziehen.

Sie sollten sich sogar aktiv an deren Weiterentwicklung beteiligen. Denn sie wissen, was der Markt benötigt. Die Hersteller selbst sind diejenigen, die die Schnittstellen implementieren und nutzen wollen. Es ist an der Zeit, die Monolithen gegenüber Subsystemen und mobilen Anwendungen zu öffnen.

Das Krankenhauszukunftsgesetz KHZG hat eine Goldgräberstimmung und einen Digitalisierungsboom ausgelöst. Das Gesetz begünstigt aber nur Systeme, welche kompatibel mit der ePA/TI sind und die bereits definierten Standards im Gesundheitswesen einhalten.

Damit können schnelle, ungeplante und proprietäre Eigenentwicklungen von Herstellern ab 2024 nur noch schwer am (deutschen) Markt bestehen.

Bei all dem darf nicht vergessen werden, dass die Digitalisierung und die Sicherstellung der Interoperabilität kein Selbstzweck sein dürfen. Es geht um nicht weniger als um die Sicherstellung der Gesundheitsversorgung.

---

Dank geht an Nick Seidel für Korrekturen und Ergänzungen – auch aus Sicht der Krankenhaus-IT.

Das Johner Institut unterstützt Sie gern bei Ihren Fragen zur Telematikinfrastruktur. Wie genau, erfahren Sie in einem kostenlosen Expertengespräch.

---

Versionshistorie:

• 2024-04-19: Links auf Simplifier.net aktualisiert
• 2022-03-18: Unter 3d) Hinweise zum ISiP ergänzt.