Eine Übersicht über die Telematikinfrastruktur im stationären Sektor

Version:  2.1
Stand:      


Historie:

VersionGrund der Änderung, besondere HinweiseDatum

2.1

Unterkapitel "Online-Check-In (OCI) & elektronische Ersatzbescheinigung (eEB)" innerhalb des Kapitels "TI und Krankenhaus-Prozesse" eingefügt

 

2

Komplettüberarbeitung:
Vermeidung von Dopplungen, die bereits in anderen Dokumenten der gematik beschrieben sind. Übernahme der bisherigen Ergebnisse aus den Austauschrunden mit KH-IT-Spezialisten.

 


Inhaltsverzeichnis:

Einleitung

Die Telematikinfrastruktur (TI) ist mittlerweile bundesweit ausgerollt und ist den meisten Akteuren im Bereich der Gesundheits-IT gut bekannt. Die Anbindung an die TI umfasst verschiedene Sektoren, wie zum Beispiel Krankenhäuser, Arztpraxen, Zahnärzte, Apotheken und weitere Einrichtungen. Es werden ständig neue Berufsgruppen, darunter auch Hebammen, an die TI angebunden. Ebenso kommen regelmäßig neue TI-Applikationen hinzu sowie Anwendungen des Gesundheitswesens wie „WANDA“, die die TI nutzen. 

Parallel dazu erfolgt eine Weiterentwicklung der TI-Architektur hin zu einem „Zero Trust“-Modell, bekannt als TI 2.0, sowie die Einführung des Highspeed-Konnektors inklusive TI-Gateway. Für Krankenhäuser werden in verschiedenen Foren Ergebnisse und Diskussionsinhalte vorgestellt, die besonders für sie von Bedeutung sind.

Zielgruppe

Das Dokument wurde entwickelt, um kleinen, mittleren und großen Krankenhäusern bei der Einrichtung und dem Betrieb der TI-Komponenten zu unterstützen. Es enthält systemische Beschreibungen sowie bewährte Praktiken, die den Krankenhäusern helfen sollen, die Herausforderungen bei der Umsetzung zu meistern. Die gematik steht im Austausch mit etwa 25 bis 45 Nutzern der TI in Krankenhäusern. Da es in Deutschland insgesamt rund 1800 Krankenhäuser gibt, findet dieser Austausch somit nur bei einem kleinen Teil statt. Deshalb richtet sich das Dokument gezielt an alle Krankenhäuser und stellt das in den Gesprächen verhandelte Wissen übersichtlich bereit. Für diejenigen, die bereits im Austausch mit der gematik stehen, bietet es eine kompakte Zusammenfassung des bisher Besprochenen.

Kapitelinhalte

TI-Architektur und BetriebDarstellung der für den Betrieb wichtigen Architekturbestandteile der TI sowie deren Auswirkungen.

TI und Krankenhaus-Prozesse: Beschreibung der Nutzung der Telematikinfrastruktur-Anwendungen im Krankenhaus

Infrastruktur: Dieses Kapitel behandelt die Themen Hardware, Vernetzung und Plattform. Dabei wird insbesondere das Mandantenmodell des Konnektors näher betrachtet. Außerdem werden die Themen Störungen sowie der Schutz vor Schadsoftware erläutert.

Anwendungen: Besonderheiten der Anwendungen, die im Betrieb innerhalb der Krankenhäuser eine wichtige Rolle spielen können.

Informationsquellen

Informationen innerhalb dieses Dokuments

In dieses Dokument sind Ergebnisse aus dem Austausch eingeflossen, an dem große Krankenhaustrukturen wie Ketten mit 10.000 Betten und mehr, Universitätskliniken sowie kommunale Großkrankenhäuser beteiligt waren. Das gewonnene Wissen basiert auf der Zusammenarbeit von Vertretern der KH-IT mit den Experten der gematik sowie des Bundesverbands Gesundheits-IT (BViTG).

Informationen für Sie zusätzlich zu diesem Dokument

Für den täglichen Betrieb stehen verschiedene Informationsquellen zur Verfügung: 

  • Für Konnektoren und Kartenterminals, einschließlich der darin betriebenen Smartcards SMC-K und SMC-KT, sind die jeweiligen Hersteller für den Support ihrer Produkte verantwortlich. 
  • Bei Smartcards wie Heilberufsausweis (HBA), Security Module Card Typ B (SMC-B) und elektronische Gesundheitskarte (eGK) sind die Informationsquellen die Herausgeber: 
    • HBA: Bundesärztekammer 
    • SMC-B für Krankenhäuser: DKTi 
    • eGK: die jeweilige Krankenkasse.

Die gematik bietet ebenfalls vielfältige Informationsmöglichkeiten. Auch Support-Tickets können direkt an die gematik gestellt werden. Besuchen Sie hierfür die Webseite der gematik.

Für die Dienste der Telematikinfrastruktur (TI) steht der Support des genutzten VPN-Zugangsdienstanbieters zur Verfügung. 

Unterstützung für WANDA bieten die jeweiligen Dienstanbieter, zum Beispiel das RKI für DEMIS. 

Der TI-Status kann hier [https://fachportal.gematik.de/ti-statuseingesehen werden, die Live-Informationen zum Zustand der TI bereitstellt. 

Außerdem gibt es die [gemmunity]– eine Plattform für den Austausch der KH-IT-Vertreter untereinander. 

Die [OneRoadmap] der gematik bietet einen zentralen Überblick über die Entwicklung der TI-Produkte. 

Weiterentwicklung dieser Seite

Diese Seite soll kontinuierlich weiterentwickelt werden, um stets die aktuellen politischen Entscheidungen, die Ergebnisse der Austauschrunden mit KH-IT-Vertretern sowie die Einflüsse durch die Roadmap der gematik zeitnah widerzuspiegeln.

TI-Architektur und Betrieb

Welchen Einfluss hat die Architektur der TI auf den Krankenhausbetrieb? Betrachten Sie dazu das nachfolgende Bild mit den drei wesentlichen Blöcken Krankenhaus (KH), TI und WANDA. Die meisten betriebsbeeinflussenden Eigenschaften lassen sich bereits anhand dieser einfachen Darstellung gut erläutern. Die nachfolgenden Kapitel beziehen sich auf das Bild.

Geschlossenes Netz, VPN-Zugangsdienst

Derzeit ist die Telematikinfrastruktur (TI) als geschlossenes Netzwerk konzipiert. Der Zugang erfolgt über Konnektoren und einen VPN. Die Konnektoren wie beispielsweise die Einboxkonnektoren (EBK) befinden sich im Krankenhaus und sind über den VPN-Zugangsdienst mit der TI verbunden.

Für den VPN-Kanal benötigen Sie eine SMC-B, die allerdings nicht dauerhaft eingesteckt sein muss. Wichtig ist, dass die SMC-B bei der Registrierung vorhanden ist. Sie muss jedoch aus anderem Grund stets eingesteckt sein, da sie bei nahezu allen TI-Operationen benötigt wird.

Nur HBA-Inhaber können die SMC-B bestellen.

Den VPN-Kanal bauen Sie zwischen Ihrem Konnektor und einem VPN-Zugangsdienstanbieter auf. Dieser bietet in der Regel auch Support bei Störungen innerhalb der TI an, nicht nur für den VPN-Zugang.

Innerhalb des Krankenhauses können mehrere Konnektoren, eHealth-Kartenterminals (eH-KT) und weitere Komponenten vorhanden sein. Wie Sie diese verteilen, hängt von Ihren individuellen Bedürfnissen ab. Je weniger SMC-B (mit unterschiedlichen Telematik-ID) Sie verwenden, desto einfacher gestaltet sich die Konfiguration.

Das Krankenhausinformationssystem (KIS) greift auf die Schnittstellen des Konnektors zu. An dem oder den Konnektoren sind die eH-KT angeschlossen. In einem oder mehreren eH-KT sind SMC-B eingesteckt. In die eH-KT werden bei Bedarf eGK oder HBA gesteckt.

Es können immer nur 25 eH-KT an einen Konnektor angeschlossen werden.

Ein Mandant bezeichnet eine von Ihnen definierte Organisationseinheit. Wenn ein Mandant mehr als 25 eH-KT benötigt, setzen Sie mehrere Konnektoren ein und betreiben diese mit SMC-B, die unterschiedliche Zertifikate haben, aber alle die gleiche Telematik-ID.

Clientmodule: Migration vom Konnektor hin zum KIS

Mittlerweile wurden die Clientmodule, im Vergleich zur Einführung der TI 1.0, für das E-Rezept (eRp) und die elektronische Patientenakte (ePA) vom Konnektor in das KIS migriert. Das KIM-Clientmodul (KIM-CM) war jedoch von Anfang an eine eigenständige, zugelassene Komponente außerhalb des Konnektors.

Bei diesen Modulen ist es wichtig, darauf zu achten, ob Sie TI-Zertifikate und/oder öffentliche Zertifikate verwenden. In beiden Fällen müssen die jeweiligen Zertifikatsketten bis zum Root-Zertifikat den Clients bekannt sein, damit die entsprechenden Prüfungen erfolgreich abgeschlossen werden können. Für TI-Zertifikate ist es erforderlich, die Trust Service List (TSL) herunterzuladen und auszuwerten, da darin die Adressen aller PKI-Ressourcen enthalten sind.

Plattformdienste, Fachdienste, Provider Zone

Die Plattformdienste der TI umfassen wichtige Funktionen wie Kryptografie (z. B. Signatur, Verschlüsselung, Authentifizierung), die Zertifikatsprüfung, den Zeitdienst sowie den TI-Verzeichnisdienst (VZD).

Die offenen Fachdienste (FD) sind beispielsweise das E-Rezept, die ePA und KIM. Sie werden als "offen" bezeichnet, weil ihre Client-Komponente nicht im Konnektor, sondern außerhalb davon liegt, also in diesem Fall z.B. im KIS.

Ein geschlossener FD ist beispielsweise das Versichertenstammdatenmanagement (VSDM), da sich dessen Client-Komponente im Konnektor befindet. Sowohl die Plattformdienste als auch die Fachdienste sind nur über den Konnektor erreichbar.

WANDA

Die weiteren Anwendungen des Gesundheitswesens sind Anwendungen wie z. B. DEMIS. Ihre Transportverschlüsselung wird mit öffentlichen Zertifikaten realisiert, die Authentisierung/Autorisierung mit TI-Identitäten wie z. B. SMC-B.

TI und Krankenhaus-Prozesse

Da Krankenhäuser derzeit keine bekannten einheitlichen Prozesse haben, sollten die Anwendungen der TI so gestaltet sein, dass sie möglichst flexibel sind und verschiedene denkbare Prozesse unterstützen können.

Gleichzeitig sollen die Anwendungen der TI so gestaltet sein, dass sie es den Krankenhäusern ermöglichen, neue Prozesse zu entwickeln, die vorher ohne die Digitalisierung durch die TI nicht möglich waren. Diese neuen Prozesse können durch die erhöhte Effizienz zu weiteren Verbesserungen und Innovationen führen.

eGK ist vorhanden

Ein Entlassrezept kann ausgestellt werden, vorausgesetzt, die Krankenversichertennummer (KVNR) des Versicherten ist bekannt. Diese kann beim Einstecken der elektronischen Gesundheitskarte (eGK) zu Beginn des Aufenthalts ermittelt werden. Zum Zeitpunkt der Rezeptausstellung ist das Einstecken der eGK jedoch nicht erforderlich.

Wichtig ist, dass jede Verordnung, also jedes einzelne Rezept, separat durch eine qualifizierte elektronische Signatur (QES) bestätigt werden muss. Dies muss zwingend so umgesetzt werden. Bei einem Entlassrezept sollte die Signatur bereits beim Entlassen erfolgen, damit der Versicherte das Rezept direkt in der Apotheke einlösen kann – eine spätere Signatur am Abend per Stapelsignatur könnte dazu führen, dass das Rezept noch nicht eingelöst werden kann.

Das Stecken der eGK erfolgt bei VSDM (Versichertenstammdatenmanagement) und gilt als Nachweis für das gesamte Krankenhaus. Die entsprechende Quittung wird auf PS-Ebene gespeichert und ist für alle Abteilungen im Krankenhaus zugänglich. Ein erneutes Stecken der eGK ist somit nicht notwendig.

Bezüglich der elektronischen Patientenakte (ePA): Das Stecken der eGK berechtigt nur den jeweiligen SMC-B-Bereich, in dem die Karte eingesteckt wurde. Es gilt nicht automatisch für das gesamte Krankenhaus. Falls das Krankenhaus mehrere SMC-B-Benutzer mit unterschiedlichen Telematik-IDs nutzt, müssen diese bei Bedarf einzeln „befugt“ werden.

Zur Befugniserteilung per Handy (FdV): Hierbei können die Zugriffsrechte auch mobil vergeben werden, was die Flexibilität erhöht.

eGK ist nicht vorhanden

Wenn Sie nach einem Unfall in der Notaufnahme nur die Krankenkasse kennen, bei der der Patient versichert ist, kann es manchmal fehlerhaft sein, die richtige IK-Nummer der Krankenkasse aus dem VZD zu ermitteln. Das liegt daran, dass es bei einigen Krankenkassen Fusionen gegeben hat. Dadurch sind im VZD unter dem Namen einer Kasse mehrere IK-Nummern vorhanden, und es ist nicht immer eindeutig, welche die richtige ist.

Für solche Fälle stellt der GKV eine sogenannte Kostenträgerstammdatei bereit. Diese enthält alle Krankenkassen, inklusive der fusionierten, mit jeweils genau einer IK-Nummer. So kann man sicherstellen, dass die richtige Nummer zugeordnet wird.

Die Schnittstellenbeschreibung SDKT ist ein Standard, der den Austausch dieser Kostenträgerstammdatei in der vertragsärztlichen Versorgung regelt. Sie enthält wichtige Informationen zu den Kostenträgern, wie zum Beispiel IK-Nummer, VKNR und Gültigkeit, die bei der Abrechnung verwendet werden.

Weitere Informationen finden Sie auch auf der Webseite des [GKV] sowie in den entsprechenden Rundschreiben.

Online-Check-In (OCI) & elektronische Ersatzbescheinigung (eEB)

Der Online-Check-In (OCI) kann für privatversicherte Patienten durchgeführt werden, die elektronische Ersatzbescheinigung (eEB) für gesetzlich Versicherte. In beiden Fällen wird ein Nachweis zum Versichertenverhältnis des Patienten erstellt. Im Fall des gesetzlich Versicherten wird dieses Verfahren als Ersatzverfahren zum Versichertenstamm-Daten-Management (VSDM) durchgeführt, wenn der Versicherte beispielsweise die elektronische Gesundheitskarte (eGK) nicht dabei hat oder sie defekt ist. Im Fall des privat Versicherten kann der OCI nur dann erfolgreich durchgeführt werden, wenn eine Krankenkassenversicherungsnummer (KVNR) vorhanden ist.

  • Nach erfolgreicher eEB steht für die Leistungserbringer (LEI) fest: Die entsprechende Krankenkasse übernimmt die Behandlungskosten, der Versicherte ist GKV-versichert, es ist gleiche Aussage wie beim VSDM Prüfnachweis 2
  • Nach erfolgreichem OCI steht fest: Der Patient ist privat versichert und die KVNR stammt aus sicherer Quelle. 

In beiden Fällen erhält die LEI die KVNR und ihre Mitarbeiter könnten entsprechend elektronische Rezepte (eRezepte) verordnen. 
Eine Befugnis zum Zugriff auf die elektronische Patientenakte (ePA) ist in beiden Fällen nicht möglich. Dies muss separat erfolgen.

Ablauf: Der Patient scannt mit seinem Smartphone einen statischen QR-Code, welcher die KIM-Mailadresse der LEI enthält. Diese wird über seine Smartphone-App an seine Krankenkasse versendet, die daraufhin eine bestätigende KIM-Mail an die LEI versendet.

Das Eintreffen der Mail kann einige Zeit dauern (geschätzt weniger als 10 Minuten). Es kann auch schneller gehen, jedoch eignet sich das Verfahren nicht, um auf das Ergebnis direkt zu warten.

Der QR-Code kann an einer dafür vorgesehenen Stelle im Krankenhaus ausgehängt werden. Der generierte Nachweis ist für die gesamte LEI gültig, unabhängig davon, wie viele SMC-Ben mit unterschiedlichen Telematik-IDs verwendet werden.

Die KIM-Nachricht enthält als Nutzlast eine spezifizierte Datenstruktur mit allen notwendigen Informationen. Bei entsprechender Implementierung des KIS kann die Nachricht automatisch und ohne manuelles Eingreifen eines Mitarbeiters der LEI ausgewertet werden. 

Belegärzte:

Für Belegärzte besteht keine Notwendigkeit, eine separate SMC-B zu verwenden. Wenn sie keine eigene SMC-B nutzen, sollten Sie jedoch bedenken, dass ein Belegarzt dann auch auf die elektronische Patientenakte (ePA) eines Versicherten zugreifen kann, sofern die verwendete Krankenhaus-SMC-B die entsprechende Befugnis erhalten hat.

Krankenhausapotheke

Die Krankenhausapotheke muss über eine eigene separate SMC-B verfügen. Die Identitätsattribute dieser SMC-B geben an, ob es sich um eine Apotheken-SMC-B handelt (damit kann ein Medikament ausgegeben werden) oder um eine Krankenhaus-SMC-B (damit kann ein Medikament verschrieben werden). 

Ein besonderer Fall sind die E-Rezepte für die ambulante Behandlung eines Patienten mit Zytostatika und parenteralen Zubereitungen. Diese Rezepte werden nicht vom Patienten in die Apotheke gebracht und dort eingelöst. Stattdessen wird der Token für diese E-Rezepte direkt vom behandelnden Arzt an die Apotheke übermittelt. Für die sichere Übertragung des Tokens kann ein Verfahren der TI (z. B. KIM) genutzt werden. Im Krankenhaus können auch andere Übertragungswege über das KIS genutzt werden. 

Die Apotheke liefert das Medikament an den behandelnden Arzt aus, der es dann verabreicht. Dabei verzichtet der Patient an dieser Stelle auf sein Recht der freien Apothekenwahl. Diese Regelung sollte im Behandlungsvertrag zwischen Patient und Krankenhaus festgelegt werden. 

Falls die Apotheke, die das E-Rezept gegenüber der Krankenkasse abrechnet, nicht gleichzeitig die herstellende Apotheke ist, ist weiterhin die Dokumentation der herstellenden Apotheke zu beachten. Die Informationen zur Herstellung werden künftig nicht mehr auf dem Rezept abgedruckt, sondern elektronisch an die abrechnende Apotheke übermittelt. Die Details zu den Inhalten und zur Übergabe dieser Informationen werden zwischen GKV-SV und DAV in Zusammenarbeit mit der deutschen Krankenhaus-Gesellschaft (DKG) festgelegt. 

Bitte beachten Sie, dass die Abrechnung von E-Rezepten nicht im Rahmen der Fachanwendung E-Rezept über die TI erfolgt.

Einweisung in eine Pflegeeinrichtung

Wenn ein Patient nach einer Krankenhausbehandlung direkt in eine Pflegeeinrichtung übergeben wird, erstellt das Krankenhaus die erforderliche Entlassdokumentation oder einen Pflegeüberleitungsbogen. Diese Unterlagen enthalten wichtige Informationen zur Behandlung des Patienten, zum Vitalzustand sowie Hinweise für die weitere Betreuung in der Pflegeeinrichtung. 

Diese Informationen werden idealerweise über das sichere Kommunikationsverfahren KIM direkt an die aufnehmende Pflegeeinrichtung gesendet. Gleichzeitig werden sie auch an den behandelnden Hausarzt übermittelt. Es ist empfehlenswert, dass sich Krankenhaus und Pflegeeinrichtung auf eine standardisierte Datenstruktur einigen, damit die Informationen direkt in das Primärsystem der Pflegeeinrichtung eingelesen werden können.

Infrastruktur

Allgemeine Informationen zur Installation und Sicherheit finden Sie bei der KBV zum Thema Datenschutz und beim BSI die "IT-Grundschutz-Bausteine".

Falls im Krankenhaus geplant ist, den Konnektor parallel zum bestehenden IT-System zu betreiben, ist bei der Auswahl der Netzwerkkomponenten und der Netzwerkkonfiguration besonders auf die Umsetzungshinweise „NET: Netze und Kommunikation“ des Bundesamtes für Sicherheit in der Informationstechnik (BSI) zu achten. Diese Hinweise sind unter dem oben genannten Link zu finden. 

Denn im Parallelbetrieb wird das lokale Netzwerk (LAN) des Krankenhauses nicht durch die Netzwerksicherheitsfunktionen des Konnektors geschützt. Daher ist es wichtig, diese Aspekte bei der Planung zu berücksichtigen, um die Sicherheit der IT-Infrastruktur zu gewährleisten.

Zulassungsende von Komponenten

Im Verzeichnis der gematik der für den Produktivbetrieb zugelassenen Geräte finden sich bei einigen Geräten Angaben zum Zulassungsende. Vielleicht fragen Sie sich, was es damit auf sich hat. 

Die Befristung der Zulassung für dezentrale TI-Komponenten wie Kartenterminals und Konnektoren ist notwendig, weil diese Komponenten im Zuge von Software-Releases kontinuierlich weiterentwickelt werden. Diese Releases dienen dazu, die Funktionalität zu erweitern sowie Sicherheit, Interoperabilität und Zuverlässigkeit zu gewährleisten. 

Daher muss die Möglichkeit bestehen, ältere Versionen dieser Produkte verbindlich von der TI auszuschließen, um die Sicherheit und den reibungslosen Betrieb zu sichern. Eine Verlängerung der Zulassungsfrist bleibt ausdrücklich vorbehalten. 

In der Regel bietet der Hersteller vor Ablauf der Zulassung ein Firmware-Update an. Durch die Installation dieser neuen Version kann der Konnektor weiterhin in einer zugelassenen Produktversion betrieben werden, beispielsweise beim Wechsel von PTV3- auf PTV4-Konnektoren.

DNS - Einstellungen

Zusammenfassung der notwendigen Einstellungen im Umgang mit DNS-Verweisen und Routern bei Zertifikatsprüfungen in TI-Fachanwendungen.

Wenn eine Fachanwendung durch einen Browser oder durch einen Rich-Client TI-Zertifikate nutzt, gibt es einige wichtige Punkte zu beachten:

  1. Vertrauensraum der Browser: Standardmäßig vertrauen Browser dem „Internet“. Wenn das im Zertifikat angegebene FQDN (vollqualifizierter Domain-Name) jedoch keine Internetadresse ist und das Zertifikat nicht von einer bekannten Zertifizierungsstelle ausgestellt wurde, zeigt der Browser möglicherweise eine Meldung wie „Vertrauen Sie diesem Zertifikat?“. Bei Zertifikaten, die von bekannten Internet-Zertifizierungsstellen stammen, passiert das nicht.
  2. Zertifikatsüberprüfung bei TI-Anwendungen: Falls bei einer TI-Fachanwendung eine Zertifikatsüberprüfung (z. B. CA- oder OCSP-Abfrage) erfolgt, muss der lokale DNS-Server auf den Konnektor verweisen, anstatt ins Internet. Das bedeutet, die DNS- und Routingeinstellungen sollten speziell für TI-spezifische FQDNs so konfiguriert sein, dass sie auf den Konnektor oder in die TI zeigen.
  3. Rich Clients: Bei Rich Clients besteht das gleiche Problem, aber es kann programmtechnisch gelöst werden. Der Entwickler des Rich-Clients kann das Verhalten der Anwendung so einstellen, dass sie in solchen Situationen angemessen reagiert.

Smartcards

SMC-B & SMC-K(T)

Die SMC-B-Zertifikate sind für eine Gültigkeit von 5 Jahren ausgelegt. Falls ein Austausch erforderlich sein sollte, erhalten Sie eine neue SMC-B mit derselben Telematik-ID sowie neuen Zertifikaten.

Ablaufende SMC-K-Zertifikate, Juni 2024?

Was ist zu tun bei auslaufenden SMC-K-Zertifikaten ab Juni 2024? 

Falls sich aus dem derzeit begrenzten Angebot an Highspeed-Konnektoren kein überzeugendes Angebot ergibt, kann es sinnvoll sein, die bestehenden SMC-K-Zertifikate zu verlängern, um Zeit für eine fundierte Entscheidung zu gewinnen. Eine Verlängerung der aktuellen RSA-basierten SMC-K ist bis Ende 2025 per Software-Update möglich – hierzu empfiehlt es sich, den Hersteller zu kontaktieren. 

Bei der Entscheidung, ob die Konnektorlösung in den Krankenhäusern ab Anfang 2026 aus einem HSK/TI-Gateway oder aus mehreren einzelnen ECC-basierten Konnektoren bestehen soll, ist zu bedenken, dass dies aufgrund des möglichen hohen Rollout-Aufwands etwa 6 bis 9 Monate vor Ende 2025 festgelegt werden sollte. 

Es ist außerdem zu beachten, dass die deutlich gesteigerte Leistungsfähigkeit des HSK eine Umkonfiguration des bestehenden Mandantenmodells ermöglicht und sogar sinnvoll ist, um eine übersichtlichere und effizientere Konfiguration zu erreichen. Das reduziert den organisatorischen Aufwand und erleichtert Skalierungen. 

Der HSK ist seit September 2024 verfügbar, das HSM-B folgt in 2025. 

Wenn ein Krankenhaus bereits ECC-basierte Konnektoren nutzt, kann deren Laufzeit um weitere 3 Jahre verlängert werden. 

Zur Anbindung der Krankenhäuser an das TI-Gateway (als Zugangspunkt zum HSK, mit der gleichen Schnittstelle wie bisher der Konnektor) werden derzeit in den Friendly User Tests Erfahrungen gesammelt. Hier empfiehlt sich ein direkter Austausch mit dem Hersteller sowie ein Erfahrungsdialog mit den Pilotanwendern.

Umstellung SMC-B G2.0 -> G2.1-Betrieb (ECC/RSA)

Bitte achten Sie bei der Verwendung von SMC-B unterschiedlicher Generationen (G2.0 und G2.1) darauf, welche Konfigurationseinstellungen im Konnektor vorgenommen werden müssen, um einen fehlerfreien Verbindungsaufbau mit Diensten der TI (insbesondere Intermediär) sicherzustellen. Dabei muss sichergestellt sein, dass beide Seiten das gleiche Kryptographische Verfahren (entweder RSA oder ECC) verwenden.

SMC-B Notfallambulanz

Für das Lesen der eGK oder in der ePA wird grundsätzlich eine SMC-B benötigt. Da dies möglicherweise krankenhausweit geschehen soll, ist es nicht zwingend erforderlich, dass eine SMC-B speziell nur in der Notfallambulanz verwendet wird. Es kann also eine andere geeignete SMC-B im Haus genutzt werden.

Aufrechterhaltung Regelbetrieb

Um den Regelbetrieb in einem Krankenhaus aufrechtzuerhalten, ist es wichtig, dass das Freischalten der SMC-B reibungslos und idealerweise von jedem Arbeitsplatz aus möglich ist, auch wenn ein Restart eines Konnektors notwendig wird. 

Der Konnektor bietet im Informationsmodell die Möglichkeit, für jeden Arbeitsplatz ein Remote-Kartenterminal zu definieren. Dabei kann die Person, die am Remote-Kartenterminal arbeitet, über das KIS die Option einer PIN-Eingabe (für SMC-B oder HBA) anfordern. Das KIS übermittelt diese Meldung an den Konnektor und unterbindet gleichzeitig die PIN-Anforderung für andere Remote-Kartenterminals, um Verwirrung zu vermeiden. 

Die Person am Remote-Kartenterminal muss hierfür die entsprechende PIN kennen. Diese Funktion der Remote-PIN-Eingabe ist auch nach einem Konnektor-Restart oder bei einer Neu-Verifizierung der SMC-B nutzbar, sofern das KIS diese unterstützt. Es ist jedoch wichtig zu beachten, dass nicht alle KIS diese Funktion für Endanwender anbieten; in der Regel erfolgt die PIN-Eingabe bei diesen Systemen durch die Administratoren.

Unterscheidung mehrerer Telematik-IDs

Wenn ein Krankenhaus mehrere SMC-B mit unterschiedlichen Telematik-ID besitzt, zum Beispiel eine für das Stammhaus und eine weitere für die Kinderchirurgie, wird für jede Telematik-ID ein eigener Basiseintrag im zentralen VZD der TI erstellt. Die Stammdaten dieser Einträge – wie Krankenhausname, Adresse und Fachrichtung – sind zunächst identisch. Die Einträge unterscheiden sich zwar durch das Schlüsselmaterial und die Telematik-ID, aber für Benutzer sind diese Unterscheidungsmerkmale nicht direkt sichtbar. 

Das bedeutet, dass ein Versicherter, der in seiner ePA-App mehrere gleichlautende Einträge zu einem Krankenhaus sieht, keine gezielte Zugriffserlaubnis für eine bestimmte Einrichtung erteilen kann. Er kann nur alle Einträge gleichzeitig freigeben, um sicherzustellen, dass die richtige Institution Zugriff erhält. 

Die Lösung besteht darin, den Krankenhäusern die Möglichkeit zu geben, ihre VZD-Einträge unterscheidbar zu machen. Hierfür können sie auf der Internetseite der Deutsche Krankenhaus TrustCenter und Informationsverarbeitung (DKTIG) einen Änderungsantrag stellen. Mit diesem Formular können Krankenhäuser die Änderung bestimmter Felder ihrer VZD-Einträge beantragen. 

In einer Musterdatei sind einige Beispiele enthalten, wie man die VZD-Einträge eines Krankenhauses mithilfe des Änderungsantrags voneinander unterscheiden kann. Diese Musterdatei finden Sie unter folgendem Link: [VZD-Krankenhaus-Beispiel]. 

Zusätzlich sind in der Datei auch Beispiele für die Vergabe von Namen für KIM-Postfächer (KIM – Kommunikation im Medizinwesen) aufgeführt. 

Bitte beachten Sie auch die Hinweise der DKTIG zum korrekten Ausfüllen des Antragsformulars, um den Prozess reibungslos zu gestalten.

SMC-B-Wechsel bei VPN-Zugangsdienst

Beim Wechsel Ihrer SMC-B im Zusammenhang mit Ihrem VPN-Zugangs-Dienst gibt es einige wichtige Punkte zu beachten.

Bisher wurden die Konnektoren von Ihnen mit Hilfe der SMC-B bei Ihrem VPN-Zug-Dienstleister registriert. Dabei wurden die Identitäten der Konnektoren und der SMC-B im VPN-ZugD hinterlegt.

Wenn eines der hinterlegten Zertifikate – sei es die SMC-B oder die SMC-K – seine Gültigkeit verliert, kann das zu Verbindungsproblemen führen:

  • Bei Ablauf der SMC-K funktioniert der Verbindungsaufbau für den betreffenden Konnektor nicht mehr.
  • Bei Ablauf der SMC-B betrifft es alle Konnektoren, die mit dieser SMC-B registriert sind, sodass der VPN-Zugang nicht mehr möglich ist.

Wenn Sie rechtzeitig eine neue SMC-B bestellen und einsetzen, funktioniert der herkömmliche Betrieb weiterhin. Allerdings ist der VPN-Zugang nur so lange möglich, wie die alte, im VPN-ZugD  hinterlegte SMC-B noch gültig ist.

In jedem Fall ist nach Erhalt der neuen SMC-B eine Neuregistrierung beim VPN-ZugD notwendig, damit alles reibungslos weiterläuft.

eGK

Prüfkarte eGK

Die Prüfkarte eGK ist ein hilfreiches Werkzeug, um die erfolgreiche Anbindung einer Einrichtung an die TI nachzuweisen. Mit dieser Karte können Sie überprüfen, ob die Online-Anbindung an die TI richtig eingerichtet ist und ob alle dezentralen Komponenten sowie das KIS korrekt auf die eGK zugreifen können. 

Außerdem ermöglicht die Prüfkarte eGK, die Installation von KIS, eH-KT und Konnektoren im Hinblick auf die Fachanwendung VSDM sowie die Konfiguration der dezentralen Komponenten zu kontrollieren. 

Für Krankenhäuser bietet die Verwendung der Prüfkarte eGK den Vorteil, dass sie nicht in der Rechenzentrumsumgebung (RU) getestet werden muss, was mit erheblichem Aufwand verbunden sein kann. Bereits die Prüfung mit einer Prüf-eGK im Rahmen von VSDM stellt sicher, dass die Infrastruktur – also Konnektor, Kartenterminals, VPN-Zugangsdienst, SMC-B und Routing – ordnungsgemäß funktioniert.

eH-KT

Umgang mit defekten KTs

Die gematik gibt keine spezifische Empfehlung zur Entsorgung der Kartenterminals (KT). Für diese Informationen wenden Sie sich bitte direkt an den Hersteller der KT. 

Die in den KT enthaltenen SMC-KT können jedoch weiterhin wiederverwendet werden. Bitte beachten Sie außerdem, dass beim Austausch eines KT die notwendigen Konfigurationen im Konnektor angepasst werden müssen, um einen reibungslosen Betrieb sicherzustellen.

Einboxkonnektor

Sperrung, Außerbetriebnahme, Softwareupdates:

Bitte klären Sie dies direkt mit dem Hersteller ab.

Serielle Anbindung oder Parallelbetrieb

Serielle Anbindung („Reihenbetrieb“):
Bei der seriellen Anbindung befinden sich alle Komponenten im selben Netzwerk (LAN) und erhalten ausschließlich über den Konnektor Zugang zur TI. Dank der integrierten Firewall des Konnektors und der optionalen Einbindung des SIS ist das LAN vor unautorisierten Zugriffen von außen gut geschützt. 

Parallele Anbindung („Parallelbetrieb“):
Bei der parallelen Anbindung sind alle Komponenten über einen Netzwerkverteiler (Switch/Router) miteinander verbunden. Die medizinischen Datenverarbeitungs-Komponenten nutzen den Konnektor, um die TI oder den optionalen SIS zu erreichen. Dabei ist es wichtig, explizite Routen mit dem Ziel TI auf den Systemen zu konfigurieren, die Zugriff auf die TI benötigen. Für die Namensauflösung in der TI muss entweder der DNS-Request direkt an den Konnektor gesendet oder ein entsprechendes Forwarding auf einem lokalen DNS-Server eingerichtet werden. 

Die übrigen Komponenten erhalten über den Router direkten Zugang zum Internet. Bestehendes LAN kann dabei um den Konnektor ergänzt und weiterhin genutzt werden. Über den Router ist das Internet unabhängig vom Zugang zur TI und mit allen Diensten verfügbar. 

Bitte beachten Sie, dass im Parallelbetrieb keine Komponenten des LAN durch den Konnektor vor unautorisierten Zugriffen, beispielsweise Angriffen aus dem Internet, geschützt sind.

Mehrere SMC-B (unterschiedliche Telematik-ID) im selben Mandanten

Frage:
Erkennt der Konnektor, dass bei einem Aufrufkontext mehrere SMC-B mit unterschiedlichen Telematik-ID vorliegen? Und für welche Telematik-ID wird in diesem Fall die Ad-hoc-Berechtigung erteilt? Oder liefert der TI-Konnektor in diesem Fall einen Fehler? 

Hintergrund:
Aufgrund einer mangelhaften Mandantenverwaltung im Informationsmodell des Konnektors wurden zu einem Mandanten mehrere SMC-B mit unterschiedlichen Telematik-ID angelegt. 

Antwort:
Die gematik empfiehlt dringend, eine Eins-zu-eins-Zuordnung zwischen einem TI-Mandanten und einer Telematik-ID zu gewährleisten. Das bedeutet, idealerweise sollte jeder Mandant genau eine Telematik-ID haben. 

Bitte beachten Sie auch die Frage „Stichwort ‚Zuordnung Telematik-ID und SMC-B‘: Welche Festlegungen sind zu beachten?“, um die korrekte Zuordnung und Handhabung sicherzustellen.

Zuordnung der SMC-B zum Arbeitsplatz

Frage:
Was genau bedeutet die „Zuordnung der SMC-B zum Arbeitsplatz“? Kann eine solche Zuordnung „SMC-B – Arbeitsplatz“ im Konnektor ausgewählt werden? 

Hintergrund:
Die SMC-B werden im Informationsmodell des Konnektors dem TI-Mandanten zugeordnet, nicht direkt den Arbeitsplätzen (siehe Konnektor Spezifikation). 

Antwort:
Die Zuordnung „SMC-B – Arbeitsplatz“ bedeutet, dass Sie im Informationsmodell des Konnektors einen Mandanten anlegen. Die gematik empfiehlt dringend, dass Sie einem Mandanten genau eine SMC-B sowie die entsprechenden Arbeitsplätze und Kartenterminals zuordnen.

Mandantenkonfiguration

Im Folgenden werden verschiedene Modelle vorgestellt, die dabei unterstützen können, eine passende SMC-B-Struktur in einem Krankenhaus aufzubauen. Die Einbindung von SMC-B, die nicht dem Typ Krankenhaus entsprechen, wird in diesem Dokument nicht weiter behandelt.

Anwendungsgetriebenes Modell

Beim anwendungsgetriebenen Modell wird eine SMC-B einer bestimmten Anwendung, wie zum Beispiel KIM, zugeordnet. Ein solcher Anwendungsfall kann beispielsweise durch eine zentrale Poststelle für die Anwendung KIM realisiert werden.

Fachabteilungs-(Institutions-)getriebenes Modell

Wenn jede Fachabteilung anwendungsübergreifend mit eigenen SMC-B ausgestattet werden soll, ist eine Aufteilung der SMC-B nach Abteilungen sinnvoll. Es ist anzumerken, dass etwa bei einem ePA-Zugriff die Autorisierung in jeder Fachabteilung gesondert erfolgen muss, auch wenn es denselben Patienten betrifft.

Mandantenkonfiguration

Anforderungen an die Mandantenkonfiguration für Fachanwendungen:

  • VSDM, NFDM, eMP: Keine spezifischen Anforderungen an die TI,
  • ePA: Besondere Anforderungen an die Mandantenkonfiguration und Zugriffsverwaltung.

Anforderungen für die ePA: Die Zugriffsrechte auf die elektronische Patientenakte (ePA) werden über die Telematik-ID einer SMC-B einem Mandanten (identifiziert durch die Mandanten-ID) zugeordnet. Dadurch können datenschutzrechtliche Zugriffsberechtigungen oder -beschränkungen innerhalb eines Krankenhauses auf die ePA übertragen werden.

Mandantentrennung und SMC-B-Verwaltung

  • Für die Nutzung der ePA ist eine an die Mandantentrennung des Krankenhauses angepasste Verwaltung von SMC-B erforderlich.
  • Es muss eine 1:1-Beziehung zwischen der im Informationsmodell des Konnektors konfigurierten Mandanten-ID und der Telematik-ID bestehen.
  • Alle SMC-B, die einem (ePA-)Mandanten zugeordnet sind, müssen eine identische Telematik-ID aufweisen.
  • Der zugeordnete Mandant erhält Zugriffsrechte auf die ePA eines Versicherten, abhängig von der erteilten Berechtigung.

Abbildung interner Zugriffsberechtigungen

  • Durch geeignete Beantragung von SMC-Bs können die im Krankenhaus vorhandenen oder geplanten internen Zugriffsberechtigungen abgebildet werden (Mandantentrennung).
  • Die Freigabe von Zugriffsrechten auf die ePA erfolgt basierend auf der Telematik-ID der den Arbeitsplätzen zugeordneten SMC-B.
  • Die Telematik-ID wird im Informationsmodell des Konnektors der SMC-B und den betroffenen Arbeitsplätzen zugeordnet, um eine tatsächliche Zugriffsmöglichkeit an den vorgesehenen Arbeitsplätzen sicherzustellen.

Highspeed-Konnektor (HSK)

Die Dokumentation zum HSK finden Sie hier [Highspeed-Konnektor]. Für Krankenhäuser stellt sich die Frage, ob der Einsatz eines eigenen HSK sinnvoll ist. Im Folgenden haben wir ein Ablaufdiagramm (siehe Abbildung 1) sowie einen erklärenden Text zum Thema für Sie zusammengestellt.


Abbildung : Ablaufdiagramm

Begleittext zum Ablaufdiagramm:

Mitte 2024 erreichten die ersten festverbauten Konnektorzertifikate (gSMC-K) ihr Laufzeitende. Diese Zertifikate hatten eine Laufzeit von 5 Jahren, weshalb ab etwa seit Mitte 2023 potenzielle Ersatzlösungen notwendig wurden. Nach Ablauf der gSMC-K funktionieren die Konnektoren vorübergehend nicht mehr. Daher ist es wichtig, dass Leistungserbringer und deren Administratoren rechtzeitig Maßnahmen ergreifen, um den Weiterbetrieb der TI sicherzustellen. 

Hierfür stehen folgende Möglichkeiten zur Verfügung: 

1. Laufzeitverlängerung der gSMC-K im bestehenden Konnektor:
Die genaue Verfügbarkeit einer Laufzeitverlängerung sollte direkt bei den jeweiligen Konnektorherstellern erfragt werden.
Einschränkung: Konnektoren, die noch auf RSA-Verschlüsselung (Baujahr vor 2020) setzen, können nur bis Ende 2025 verlängert werden, da die Nutzung von RSA nur bis dahin zulässig ist. Konnektoren mit ECC-Verschlüsselung (Baujahr 2020 und später) können seit Herbst 2023 um weitere 5 Jahre verlängert werden.
Hinweis: Ein Software-Upgrade von RSA auf ECC ist technisch nicht möglich.
Wichtig: Eine Laufzeitverlängerung ändert nichts an der Leistungsfähigkeit der TI-Anbindung. 

2. Stückweiser Ersatz der Konnektoren:
Ein neuer Konnektor kann für weitere 5 Jahre genutzt werden und danach eventuell erneut verlängert werden. Je nach Modell kann ein neuer Konnektor leistungsfähiger sein als der alte.
Hinweis: Bei zunehmender Digitalisierung, insbesondere mit der Einführung der ePA für alle im Jahr 2024, könnte die bestehende Infrastruktur aus Einboxkonnektoren unzureichend werden. Die Nutzungshäufigkeit und -intensität sollten daher anhand von Log-Auswertungen oder Erfahrungswerten abgeschätzt werden. 

3. Übergangsweise Nutzung eines Konnektor-as-a-Service-Angebots:
Hierbei mieten Sie den TI-Zugang über einen Anbieter, der einen dedizierten Konnektor betreibt (auch TI-as-a-Service genannt). Die Verbindung erfolgt via VPN zum Rechenzentrum des Anbieters. Diese Lösung kann im Notfall oder bei Unsicherheiten eine sinnvolle Übergangslösung sein.
Hinweis: Zwar entlastet diese Variante die eigenen Betriebsaufwände, technische Performancevorteile sind jedoch begrenzt, und es können längere Antwortzeiten auftreten. 

4. Nutzung des TI-Gateways als Serviceleistung mit Highspeed-Konnektor (HSK):
Bei dieser Option setzt der Anbieter im Hintergrund einen Highspeed-Konnektor ein, was vor allem bei größeren Einrichtungen wie Krankenhäusern die Konfigurations- und Betriebsaufwände deutlich reduziert. Allerdings ist das TI-Gateway als Serviceangebot derzeit noch nicht am Markt verfügbar. 

5. Beschaffung und Betrieb eines Highspeed-Konnektors:
Diese Investition zielt auf maximale Leistungsfähigkeit ab. Dabei sind folgende Punkte zu beachten: 

  • Höhere Anschaffungskosten, die individuell mit dem Hersteller geklärt werden müssen. 
  • Veränderung der Betriebskosten, insbesondere durch die aktive Teilnahme am IT-Service-Management (ITSM). 
  • Steigerung der Performance, technische Flexibilität und bessere Abdeckung individueller Sicherheits- und Kontrollbedürfnisse.

Bewertung der vorhandenen TI-Zugangslösung:

Wann wurde die Beschaffung der Konnektoren bei Ihnen durchgeführt, und wie alt sind die aktuell eingesetzten Geräte?
Falls die Konnektoren bereits vor 2020 beschafft wurden, sollten Sie möglichst bald aktiv werden. Es besteht die Möglichkeit, dass Ihr Modell nicht ECC-fähig ist. Zudem entwickeln sich IT-Hardware und -Technologien schnell weiter, sodass Sie vermutlich bereits heute ein eingeschränktes Nutzererlebnis haben. Im Einzelfall hängt die Situation vom genauen Produktionsdatum Ihrer Konnektoren ab. Es ist daher ratsam, zeitnah einen konkreten Plan für den Austausch der veralteten Komponenten zu erstellen. Bitte prüfen Sie auch das Alter und die ECC-Fähigkeit Ihrer eingesetzten eHealth-Kartenterminals. 

Wie viele eHealth-Kartenterminals betreiben Sie aktuell in Ihrem Haus, und an wie vielen Standorten?
Je nachdem, wie fragmentiert Ihr Campus ist und wie die Aufnahme sowie Entlassung der Patienten organisiert sind, kann der Aufwand für Ihre IT-Mitarbeiter erheblich sein. Dieser Aufwand spiegelt sich in der Anzahl der benötigten Kartenterminals für die Interaktion von Ärzten und Versicherten wider. Bei bis zu etwa 40 eH-KT (entsprechend 2 Konnektoren) ist das bekannte Modell – der Kauf klassischer Konnektoren – weiterhin eine effektive und überschaubare Lösung. Ab etwa 1.000 Kartenterminals (etwa 50 Konnektoren) an verschiedenen Standorten (Sprechzimmer, Stationstresen, Krankenhausapotheke usw.) sollten Sie die Anschaffung eines eigenen Highspeed-Konnektors in Betracht ziehen. 

Wie groß ist Ihre IT-Abteilung, welches Rechenzentrum nutzen Sie, und wie viele Personentage pro Monat werden für die Betreuung der TI-Komponenten aufgewendet?
Der Betrieb eines Highspeed-Konnektors erfordert IT-Administratoren mit entsprechendem Fachwissen, das über das eines reinen Applikationsbetreuers hinausgeht. Es ist sinnvoll, den Aufwand zu reduzieren, wenn Sie bereits heute mehr als 0,5 Vollzeitäquivalente (VZÄ) nur für Support und Betrieb der TI in Ihrem Haus einsetzen. Idealerweise ist Ihre sonstige IT-Hardware bereits professionell in einem Rechenzentrum untergebracht (z. B. durch eine Anbindung an eine Universität), in dem der Highspeed-Konnektor installiert werden kann. 

Was ist Ihr Planungshorizont, und wie weit reicht Ihr nächster Budgetzyklus?
Je nach Umfang der geplanten Mittel (Anzahl der Konnektoren) lässt sich das benötigte Budget mit mehr oder weniger Vorlaufzeit sichern. Zukünftige TI-Produkte hängen von Zulassungsverfahren und Sicherheitszertifizierungen ab, sodass möglicherweise Nacharbeiten notwendig sind, bevor eine Zulassung erteilt wird. Auch die Weiterführung oder Anpassung bestehender Finanzierungsvereinbarungen steht noch aus. Wenn Sie kurzfristig eine belastbare Kostenschätzung benötigen, empfiehlt es sich, nur mit den derzeit verfügbaren Produkten zu planen, wie z. B. dem Konnektor oder Übergangslösungen wie Konnektor-Hosting-Angeboten.

Der Weg zum HSK / TI-Gateway im Krankenhaus

Schritte zur Aufnahme des Ist-Zustands und Umsetzung:

  • den aktuellen Zustand erfassen, 
  • die verschiedenen Konnektor-Typen identifizieren,
  • Backups erstellen,
  • HSK in Betrieb nehmen und Backups bei Bedarf einspielen,
  • die EBK abschalten und die SMC-Bs für den HSK freischalten,
  • das PVS anpassen,
  • Testen und Abschluss durchführen.

Hinweis: Geschwindigkeit und Erfolg des Prozesses werden von mehreren Faktoren beeinflusst, zum Beispiel:

  • Sind Backups von bestehenden Lösungen importierbar? 
  • Gibt es eine Möglichkeit zur Konsolidierung der Infomodelle (ggf. mit Tool-Unterstützung)? 
  • Ist eine manuelle Neukonfiguration notwendig (z. B. Infomodell, KT-Pairing, Clientzertifikate)? 
  • Muss auf eine zertifikatsbasierte Authentifizierung umgestellt werden? 
  • Wie ist die Netzwerkkonfiguration, insbesondere im Hinblick auf Firewalls?

HSM-B

Das HSM-B wird nutzbar sein, sobald die Personalisierungskette verfügbar ist – voraussichtlich im dritten Quartal 2025. 

Herausgeber: DKTiG für Krankenhäuser 

Vorteile:

  • Eine performante Nutzung der Institutionsidentität ist möglich, ohne dass es zu Duplizierungen mit vielen Karten kommt. 
  • Anwendungsfälle, bei denen die Authentifizierung als Institution erforderlich ist, können ohne Karte und Kartenterminal umgesetzt werden (z. B. KIM und ePA). 
  • Es ist keine PIN-Eingabe notwendig: Das HSM-B wird nur einmalig aktiviert und muss nicht wiederholt freigeschaltet werden.

Ausblick:

  • Erste pilothafte Ausgaben des SM-B für TI-Gateway/HSM-B sind für das zweite Halbjahr 2025 geplant. 
  • Mit einer breiten Marktverfügbarkeit ist aus heutiger Sicht frühestens im Laufe des Jahres 2026 zu rechnen.

QES

Welche TI-Anwendungen erfordern eine qualifizierte elektronische Signatur (QES)?

Derzeit kommt die qualifizierte elektronische Signatur (QES) bei den folgenden Anwendungen zum Einsatz: 

  • Notfalldaten-Management (NFDM), insbesondere beim Anlegen oder Aktualisieren eines Notfalldatensatzes,
  • E-Rezept,
  • Erstellung einer elektronischen Arbeitsunfähigkeitsbescheinigung (eAU) per KIM (Kommunikation im Medizinwesen).

Obwohl die QES für elektronische Arztbriefe gesetzlich nicht vorgeschrieben ist, ist sie dennoch für die Kostenerstattung nach § 383 SGB V bei der Übermittlung eines elektronischen Arztbriefes via KIM erforderlich, um die vertragsärztliche Versorgung abzurechnen.

TI-Gateway

Einordnung in die Telematikinfrastruktur

Das TI-Gateway ist ein wichtiger Dienst innerhalb der TI. Es ermöglicht Leistungserbringern und anderen Nutzern, eHealth-Kartenterminals (und die dazugehörigen TI-Smartcards) sowie verschiedene Services zu nutzen, die normalerweise vom Anwendungskonnektor und den Fachmodulen des Konnektors bereitgestellt werden. Außerdem erlaubt es den Zugriff auf offene Fachdienste und WANDA über das Netzwerk.

Durch die Verschiebung der Funktionen, die bisher vom Konnektor im lokalen Netz bereitgestellt wurden, in einen im Rechenzentrum betriebenen Dienst, stehen einige Funktionen nicht mehr zur Verfügung. Dazu gehören zum Beispiel der Schutz des lokalen Netzes vor Angriffen aus dem Internet, der SIS, der Zeitdienst für das lokale Netz, der DHCP-Server sowie bestimmte Funktionen des VSDM im Offline- und Standalone-Betrieb.

Nutzer und ihre Dienstleister vor Ort (DVO) müssen daher alternative Lösungen für diese Funktionen finden, falls sie diese weiterhin benötigen. Besonders wichtig ist das, wenn vorher ein Konnektor in Reihe installiert war, um das lokale Netz gegen das Internet abzusichern.

Technisches Konzept

Die Zulassung eines TI-Gateways als Anbieterprodukt erfordert sowohl eine Produktzulassung für das Zugangsmodul als auch eine Produktzulassung für den Highspeed-Konnektor (HSK). 

Das Zugangsmodul ermöglicht und sichert den Zugriff für die fachliche Nutzung auf die HSK-Instanz, den Zugriff für die Administration einer HSK-Instanz sowie den Zugang zu offenen Fachdiensten und WANDA innerhalb der TI. 

Der HSK stellt die grundlegenden Dienste der TI für die LE-Umgebung bereit, inklusive der Fachmodule und der Kartenterminalintegration für die LE-Umgebung. 

Rollenkonzept TI-Gateway

Die gematik erteilt einem Unternehmen die Zulassung als Anbieter des TI-Gateways. Dieses Unternehmen erbringt Betriebsleistungen und Serviceleistungen unter Verwendung zugelassener Produkte. Dabei kann der Anbieter auch Unterauftragnehmer beauftragen, um bestimmte Aufgaben zu übernehmen (siehe auch [gemKPT_Betr]). 

Die Beziehungen zwischen den einzelnen Firmen werden im Rollenkonzept jedoch nicht betrachtet.

Störungen

Störungsschnittstelle

Für alle, die dazu in der Lage sind – also Anbieter von TI-Diensten, PS-Hersteller und deren Supporteinheiten, Krankenhäuser sowie deren IT – empfehlen wir, die aktuellen Informationen zum Status der TI direkt über unsere Schnittstellen abzurufen. Das Fachportal nutzt diese Schnittstellen ebenfalls, um die Darstellung auf der TI-Statusseite umzusetzen. 

Eine Beschreibung der Schnittstellen ist öffentlich in unserem GitHub-Projekt einsehbar: [REST-Schnittstelle zum TI-Lagebild & TI-Status].

TI-Status

Der TI-Status ist hier [https://fachportal.gematik.de/ti-status] abrufbar. Ab Ende 2025 sollen zusätzlich alle WANDA-Anbieter verpflichtend an einer Betriebs-Status-Synchronisation teilnehmen. Für ältere Wanda-Versionen bleibt die Teilnahme weiterhin freiwillig. 

Bei den meisten Diensten der TI besteht jedoch die Verpflichtung, am TI-ITSM teilzunehmen und Wartungen (sogenannte "Changes") im Change Management anzumelden. Beim Implantateregister handelt es sich ebenfalls um eine WANDA, hier ist die Teilnahme am ITSM allerdings nicht verpflichtend. 

Dennoch haben wir auch in diesem Fall die Möglichkeit, angekündigte Wartungen bei uns zu hinterlegen, um das Lagebild aktuell zu halten. Dafür müssten uns solche Wartungen rechtzeitig vorher aktiv angezeigt werden. 

Die Meldung an [Incident_Management@gematik.de] ist freiwillig. Wenn eine Wartung bei uns nicht bekannt ist, werden Erreichbarkeitsprüfungen als ‚unentschuldigt‘ fehlend angezeigt und entsprechend als ‚Störung‘ dargestellt. 

Störung/Defekt einer Smartcard

Bitte wenden Sie sich stets an den Kartenherausgeber, falls Sie Unterstützung benötigen: 

  • für die eGK: an die herausgebende Krankenkasse,
  • für SMC-B im Krankenhaus: an DKTiG,
  • für HBA an die Bundesärztekammer.

Sicherheit, Schadsoftwareerkennung

Abgrenzung zu NIS2

NIS2 ist eine Compliance-Richtlinie, die sich auf KRITIS (kritische Infrastrukturen) bezieht. Die TI überträgt Daten per End-to-End-Verschlüsselung nur bis zu den Grenzen dieser KRITIS (wie ePA, KIM, TI-M) und hat keine direkte Überschneidung mit den kritischen Infrastrukturen. Daher behandelt die TI NIS2 in ihren Spezifikationen auch nicht. 

Weitere Informationen dazu finden Sie auch hier: [Nachweise und Prüfungen].

Dies wurde in Abstimmung mit der Rechtsabteilung der gematik geprüft: Die TI fällt nicht unter NIS2 und das deutsche NIS2-Umsetzungsgesetz (NIS2UmSuCG). Es gibt in diesem Gesetz einen Passus, der für gematik und die TI eine Ausnahme vorsieht. Es gilt weiterhin das SGB V.

Schutz vor Schadcode

KIM: Es gibt bereits erfolgreiche Lösungen in Krankenhäusern, die KIM nutzen. 

TI-M: Es besteht die Möglichkeit, einen zwischengeschalteten Content-Scanner für den Dokumenten-Download einzusetzen, um die Sicherheit zu erhöhen. 

ePA: Es wurde entschieden, keinen zentralen Virenscanner zu verwenden. Stattdessen liegt der Fokus auf den Dateiformaten und lokalen Scannern, um die Sicherheit zu gewährleisten. 

  • Single Point of Failure: Ein zentraler Virenscanner stellt einen einzigen Angriffspunkt dar. Wenn dieser kompromittiert wird, könnte der gesamte Schutzmechanismus ausfallen. 
  • Latenz und Bandbreite: Das Übertragen und Verarbeiten großer Datenmengen kann die Netzwerkbandbreite belasten und zu Verzögerungen führen. 
  • Erkennungsrate: Virenscanner arbeiten mit Signaturen, was bedeutet, dass neue oder unbekannte Bedrohungen manchmal unentdeckt bleiben, bis eine passende Signatur vorhanden ist. 
  • Datenschutz und Vertraulichkeit: Virenscanner benötigen Zugriff auf sensible Daten, was Datenschutzrisiken birgt. Eine zentrale Speicherung und Verarbeitung kann die Vertraulichkeit gefährden. 
  • False Positives: Das falsche Erkennen von Dokumenten kann negative Auswirkungen auf die Behandlung haben. Zudem ist es schwierig, zentral die Wichtigkeit einzelner Informationen zu beurteilen.

Es sind bisher keine bekannten erfolgreichen Angriffe auf Krankenhäuser über die ePA bekannt. 

Bezüglich der "TK-App" der Techniker Krankenkasse: Es gab eine Sicherheitslücke, die es ermöglichte, verbotene Zip-Dateien in die ePA hochzuladen. Diese Schwachstelle wurde jedoch bereits geschlossen, bevor sie ausgenutzt werden konnte. 

Im Zusammenhang mit KIM (Kommunikation im Medizinwesen) wurden über 46 Millionen Arztbriefe verschickt. Bisher sind keine Angriffe mit Schadcode bekannt geworden. 

Wichtig ist auch, dass der Täterkreis stark eingeschränkt ist. 

Für KIM und TI-Messenger (TI-M) ist der Besitz von SMC-B (Sichere Module Card-B) oder HBA (Hardware-Basis-Adapter) sowie die Nutzung der eGK (elektronische Gesundheitskarte) erforderlich.

Die gematik hält die Einschränkung der Dateiformate für eine sinnvolle und wirksame Maßnahme.

Sie stuft die Wahrscheinlichkeit, dass Schadcode über die elektronische Patientenakte (ePA) verbreitet wird, als unwahrscheinlich ein. Hersteller wie ASX:FDV sind verpflichtet, jährlich Penetrationstests nachzuweisen, um die Sicherheit ihrer Systeme zu gewährleisten. Alle Clients für die ePA müssen von der gematik zugelassen werden, was bedeutet, dass sie unabhängig geprüft werden. Die Beschränkung der Dateiformate ist wirksam, da die Clients und die ePA-Akten-Systeme diese prüfen und bei Bedarf ablehnen oder in ein anderes Format konvertieren. Die gematik führt regelmäßig unabhängige Penetrationstests durch, beobachtet aktiv die Sicherheitslage und pflegt engen Kontakt zu den wichtigsten Sicherheitsstellen in Deutschland. Aktuell wurde die Einschätzung getroffen, dass kein Upload von Bilddateien erlaubt ist.

Verdacht von Schadcode aus der TI

Diese Handlungsempfehlung soll Ihnen, als Nutzerinnen und Nutzer aus Arztpraxen, Zahnarztpraxen, Krankenhäusern und Apotheken, eine Orientierungshilfe bieten. Sie beschreibt die Schritte, die Sie unternehmen sollten, falls Sie den Verdacht haben, dass Schadsoftware, wie zum Beispiel Computerviren, über die TI übertragen wurde.

Obwohl die Übermittlung von Informationen über die TI grundsätzlich sehr sicher ist, ist eine direkte Überprüfung auf Schadcode innerhalb dieser Infrastruktur aufgrund der hohen Sicherheitsstandards und der Ende-zu-Ende-Verschlüsselung nicht praktikabel. Deshalb wurde bewusst auf zentrale Scanner innerhalb der TI verzichtet. Das Risiko, durch Schadcode aus der TI infiziert zu werden, ist insgesamt gering.

In den Kommunikationsdiensten im Medizinwesen, wie dem TI-Messenger, kommunizieren nur professionelle Akteure des deutschen Gesundheitswesens, die gesetzliche Sicherheitsvorkehrungen treffen, um ihre Systeme zu schützen. Dazu gehören auch lokale Virenscanner und bei größeren Einrichtungen wie Krankenhäusern sogar mehrstufige Schutzmaßnahmen.

Bei der ePA 3.0 wurde zudem darauf geachtet, nur Dateiformate zuzulassen, die das Risiko von Schadcode minimieren. Dateien, bei denen die Formatprüfung fehlschlägt, werden nicht in die ePA aufgenommen.

Trotz all dieser Maßnahmen kann eine Übertragung von Schadsoftware über die TI nicht vollständig ausgeschlossen werden. 

Empfohlene Vorgehensweise bei Verdacht:
Wenn Sie den begründeten Verdacht haben, dass beim Empfang von Informationen aus der TI-Schadcode übertragen wurde (z. B. durch eine Meldung Ihres Virenscanners), sollten Sie die betreffende Datei auf keinen Fall öffnen. Löschen Sie sie stattdessen sicher von Ihrem System und öffnen Sie sie nicht entgegen der Warnung. 

Informieren Sie außerdem Ihren Kommunikationspartner (bei der ePA ist das derjenige, der das Dokument eingestellt hat oder die Person, die die Akte besitzt) über den Verdacht. Das kann entweder über die sichere TI (z. B. KIM oder TI) oder alternativ per Telefon oder E-Mail erfolgen. So kann Ihr Partner die Situation prüfen und entsprechende Maßnahmen ergreifen. 

Zudem wird empfohlen, potenzielle Verdachtsfälle über das [Kontaktformular] der gematik zu melden. Wählen Sie bitte die Kategorie „Datenschutz und Informationssicherheit“, damit Ihre Meldung gezielt bearbeitet werden kann.

Anwendungen

ePA

Schutzmaßnahmen ePA

Die Fachanwendung ePA wird für Nutzerinnen und Nutzer in einem Krankenhaus größtenteils durch das Primärsystem, also das KIS, umgesetzt. Die Hersteller der KIS sind dazu angehalten, die im Implementierungsleitfaden ePA [gemILF_PS_ePA] festgelegten Anforderungen zu erfüllen. Da die Daten in der ePA Ende-zu-Ende verschlüsselt gespeichert werden, kann beim Herunterladen von Dokumenten aus der ePA eines Versicherten nicht vollständig ausgeschlossen werden, dass diese Schadsoftware enthalten. Aufgrund der Ende-zu-Ende-Verschlüsselung ist es jedoch nicht möglich, die Dokumente zentral auf Schadsoftware zu prüfen, beispielsweise durch den Anbieter des ePA-Aktensystems. Daher liegt die Verantwortung, die Sicherheit beim Herunterladen und Verarbeiten der Dokumente zu gewährleisten, im Primärsystem.

Als IT-Dienstleister oder IT-Verantwortliche im Krankenhaus sollten Sie sicherstellen, dass geeignete Schutzmaßnahmen getroffen werden, um eine Infektion des Primärsystems und weiterer Systeme zu verhindern. Zwar wird im genannten Implementierungsleitfaden die Verantwortung für den Schutz des Primärsystems den jeweiligen Verantwortlichen übertragen, doch die Umsetzung dieser Maßnahmen erfolgt immer in Abstimmung mit den IT-Experten und Administratoren Ihres Krankenhauses.

Mögliche Schutzmaßnahmen, bei deren Umsetzung Sie beteiligt sein können, sind beispielsweise:

  • Das Laden und Extrahieren der Dokumente in einer sicheren Umgebung, wie einer Sandbox, sowie die Untersuchung und Analyse durch geeignete Sicherheits- und Schutzsysteme vor der Anzeige eines Dokuments.
  • Das Entschärfen von Sonder- und Meta-Zeichen im Dokument durch eine geeignete Escape-Syntax, um Angriffe wie Injection-Attacken (z. B. nach OWASP Top 10) zu verhindern.
  • Die Information der Nutzerinnen und Nutzer darüber, dass Dokumente Schadsoftware enthalten können, und welche Maßnahmen sie zum Selbstschutz ergreifen sollten (z. B. in die Sicherheitsbelehrung aufnehmen).

Zudem kann es vor dem Hochladen von Dokumenten aus Ihrer Krankenhausumgebung in die ePA eines Versicherten notwendig sein, diese auf Einhaltung von Compliance-Anforderungen und auf mögliche Datenverluste (Data Loss Prevention) zu überprüfen. Die konkreten Anforderungen und Vorgaben dazu können die Verantwortlichen oder Organisationseinheiten in Ihrem Krankenhaus beantworten.

Bitte stellen Sie sicher, dass alle Schutzmaßnahmen für die Fachanwendung ePA in das übergreifende Datenschutz- und Sicherheitskonzept bzw. das Information Security Management System (ISMS) Ihres Krankenhauses integriert werden. Dabei ist eine enge Abstimmung mit den entsprechenden Fachstellen und Verantwortlichen besonders wichtig.

Umwandlung von PDF in PDF/A

Bei der Umwandlung von PDF in PDF-A kann es offenbar manchmal zu einem Informationsverlust kommen. Das macht die Konvertierung für die vollständige Wahrung der medizinischen Informationen teilweise unsicher. 

Dazu einige Hinweise: 

  • Das Primärsystem (PS) sollte ein neues Dokument nativ erstellen und dieses direkt als PDF/A speichern. 
  • Hinweis 1: Der eArztbrief ist nach KBV-Vorgabe bereits im PDF/A-Format. 
  • Hinweis 2: Wir empfehlen ausdrücklich, keine Dokumente zunächst als PDF zu speichern und anschließend zu konvertieren, da dabei Risiken für die Datenintegrität bestehen können.

Wenn das PS ein externes neues Dokument hochladen soll, beispielsweise eines, das von einer Drittsoftware wie einem EKG-Fahrrad bereitgestellt wurde, muss dieses Dokument von PDF in PDF/A konvertiert werden. 

Auch beim Hochladen eines älteren Dokuments, das nicht im PDF/A-Format vorliegt, ist eine Konvertierung notwendig, um die Anforderungen zu erfüllen.

Serverzertifikatswechsel

In der Vergangenheit kam es bei der Einführung der ePA Version 3 auch zu Server-Zertifikatswechseln, die für die TLS-Verbindung zwischen Client und Aktensystem notwendig sind. Dabei wurde in einigen Umgebungen ein Problem sichtbar, weil das Root-Zertifikat nicht aktualisiert wurde – das lag daran, dass die TLS-Aktualisierung durch das Praxisverwaltungssystem (PS) nicht rechtzeitig durchgeführt wurde. 

Die Implementierungsleitfäden fordern daher ausdrücklich eine Aktualisierung dieser Zertifikate, z. B.: 

FAQs zur ePA

Befugnis Fachabteilung

Der Patient muss dem Zugriff durch eine Fachabteilung mit eigener SMC-B separat zustimmen, damit diese Fachabteilung Zugriff auf die elektronische Patientenakte (ePA) erhält. Dies geschieht beispielsweise durch das Stecken der eGK. So wird sichergestellt, dass der Patient die volle Kontrolle über seine Daten behält und nur diejenigen Zugriff erhalten, denen er ausdrücklich zustimmt.

Fachabteilungsbezogene SMC-B

Soll eine Freigabe für die ePA auf Fachabteilungsebene erfolgen?

Wenn ja, wird dann für jede Fachabteilung eine eigene SMC-B (mit eigener Telematik-ID) benötigt? Generell ist es nicht zwingend erforderlich, Zugriffe auf die elektronische Patientenakte (ePA) auf Fachabteilungsebene zuzuordnen. Um den Versicherten zu schützen, wäre es beispielsweise für psychologische Behandlungen sinnvoll, separate SMC-Bs für die Psychologische Abteilung einzurichten. In diesem Fall könnte jede Fachabteilung eine SMC-B verwenden. Eine Zugriffskontrolle ist allerdings auch schon durch gesetzliche Vorgaben geregelt (Ärzte dürfen nur die Dokumente einsehen, die im jeweiligen Behandlungskontext relevant sind). Außerdem wird eine Zugriffssteuerung in der Regel auch durch das KIS sichergestellt.

Mandantenverwaltung vs. Aufnahme-Alltag im Krankenhaus

In Krankenhäusern, in denen die Patientenaufnahme zentral für verschiedene Organisationseinheiten (mit potenziell unterschiedlichen TI-Mandanten) erfolgt, stellt sich die Frage, wie diese bewährte Praxis unter Berücksichtigung der Zugriffsberechtigung für die elektronische Patientenakte (ePA) beibehalten werden kann, ohne die zentralen Aufnahme-Arbeitsplätze zu verändern.

Mit der neuen ePA ist eine Zugriffsberechtigung jeweils pro SMC-B (Smartcard für Beschäftigte) möglich, wobei SMC-B mit identischer Telematik-ID als gleichwertig gelten. Um die zentrale Aufnahme beizubehalten, empfiehlt es sich, für jede Abteilung ein Kartenterminal zur Berechtigungsfreigabe durch die elektronische Gesundheitskarte des Versicherten bereitzustellen.

Hinweis: Nutzt der Versicherte ein Frontend des Versicherten, beispielsweise eine ePA-App auf dem Smartphone, kann die Berechtigungserteilung für weitere Abteilungen deutlich vereinfacht werden. In diesem Fall können die notwendigen Berechtigungen schnell und unkompliziert per Klick im Smartphone erteilt werden.

E-Rezept

Im Krankenhaus betrifft die Einführung des E-Rezepts vor allem das Entlassmanagement (Entlassrezept). Darüber hinaus werden E-Rezepte, die im Krankenhaus erstellt, krankenhausintern verwendet und gemäß § 129a SGB V abgerechnet werden und für die kein Fremdzuweisungsverbot gilt, als E-Rezept verordnet. Dies umfasst auch die ambulante Behandlung von Patienten mit Zytostatika oder parenteralen Zubereitungen.

Die Erstellung des E-Rezepts erfolgt im Krankenhausinformationssystem und wird zur späteren Einlösung auf dem E-Rezept-Fachdienst gespeichert. Zur Übermittlung des E-Rezepts in die Apotheke ist auch ein Ausdruck als 2D-Barcode (Datamatrix-Code) inklusive Zusatzinformationen vorzusehen.

Ein Entlassrezept kann vom Patienten in seiner E-Rezept-App verwaltet oder via Papierausdruck in die Apotheke zur Einlösung überbracht werden. Für patientenindividuelle Rezepte ist vorgesehen, dass diese – wie bisher auch – direkt in der ambulanten Behandlung eingelöst werden. Entsprechende vertragliche Regelungen sind weiterhin mit den Patienten zu vereinbaren.

In noch folgenden Stufen zur Umsetzung des E-Rezeptes werden gemäß DVPMG weitere Rezeptarten umgesetzt:

  • Betäubungsmittel-Rezepte und T-Rezepte (T-Rezepte sind Verschreibungen von Arzneimitteln mit besonderen teratogen wirkenden Wirkstoffen)
  • Digitale Gesundheitsanwendungen
  • Häusliche Krankenpflege und Außerklinische Intensivpflege
  • Verordnung von Soziotherapie
  • Verordnung Heil- & Hilfsmittel

Beim E-Rezept muss jede Verordnung separat signiert werden. Eine Verordnung kann aber z. B. aus 2 Packungen bestehen (des gleichen Medikaments). Ein E-Rezept enthält also abweichend vom Papierrezept nur eine Verordnung, nicht bis zu 3.
hierzu auch: Rückmeldung von Dedalus zum Thema 1x Veordnungszeile = 1x E-Rezept
Im Formular E-Rezept von uns kann man so viele Verordnungen machen wie man möchte. Jede einzelne Verordnung ist ein eigenes E-Rezept und auf dem Ausdruck werden drei zusammengefasst. 

Wanda / ÖGD

[Informationen zum Authenticator

KIM

Documentation KIM auch im GitHub: api-kim/docs/Primaersystem.adoc

Die Nachrichten, die Sie aus Ihrem Krankenhaus über KIM versenden, werden vom KIM-Clientmodul verschlüsselt und signiert. Anschließend werden sie sicher über die Telematikinfrastruktur (TI) bis zum KIM-Fachdienst des Empfängers übertragen. Das KIM-Clientmodul des Empfängers übernimmt dann die Signaturprüfung und entschlüsselt die Nachricht. 

Alle KIM-Teilnehmer sind im Verzeichnis der Zugangs- und Kommunikationsdienste (VZD) der TI gelistet. Für die sichere Übertragung der Nachrichten kommen die PKI-Komponenten der TI zum Einsatz. Zudem sind alle Verbindungen zusätzlich TLS-verschlüsselt, um die Sicherheit zu gewährleisten. 

Die KIM-Fachdienste verschiedener Hersteller sowie die entsprechenden KIM-Clientmodule sind von der gematik zugelassen. Sie werden sicher in der Provider Zone der TI von zugelassenen KIM-Anbietern betrieben, sodass die Kommunikation stets zuverlässig und geschützt abläuft.

Schadsoftwareerkennung

Da die über KIM empfangenen E-Mails erst hinter dem KIM-Clientmodul unverschlüsselt vorliegen, ist die zentrale Untersuchung und Analyse der Inhalte auf Schadsoftware und Viren erst ab diesem Punkt möglich. So können Sie sicherstellen, dass die Nachrichten vor der Auswertung auf Viren geprüft werden.

Ausfallsicherheit

Ein weiterer wichtiger Punkt ist die Frage, wie Sie die Ausfallsicherheit Ihrer KIM-Anbindung verbessern können. Da KIM SMC-B-gebundenen ist, ist es ratsam, darauf zu achten, dass der gesamte KIM-Verkehr nicht durch den Ausfall einer einzigen SMC-B, eines einzelnen Kartenterminals oder eines Konnektors für längere Zeit unterbrochen wird. 

Wenn Sie persönliche Postfächer auf HBA-Basis einrichten, sollten Sie zudem berücksichtigen, dass bei einem Ausfall des HBA die an dieses Postfach gerichteten KIM-Nachrichten nicht mehr entschlüsselt werden können.

Performance

Ein weiterer wichtiger Punkt ist die Überwachung der Auslastung Ihres eingesetzten Konnektors. Es ist hilfreich, im Blick zu behalten, wie schnell dieser an seine Kapazitätsgrenzen stößt. Bitte beachten Sie dabei, dass eine KIM-Nachricht, beispielsweise an ein Funktionspostfach eines anderen Krankenhauses, unter Umständen mehrfach verschlüsselt wird.

KIM-Adressen und Routing einkommender KIM-Nachrichten

KIM-Adressen können ausschließlich über den Registrierungsdienst des beauftragten KIM-Anbieters im VZD der TI eingetragen werden.

Im VZD werden KIM-Adressen einer Telematik-ID zugeordnet. Dabei ist zu beachten, dass maximal 1000 KIM-Adressen pro Telematik-ID registriert werden können.

Eine KIM-Adresse darf im VZD nur einmal vorkommen und ist daher immer nur einer einzigen Telematik-ID zugeordnet. 

Jeder HBA besitzt eine eigene Telematik-ID. Im Gegensatz dazu können mehrere SMC-B einer einzigen Telematik-ID zugeordnet werden. Die Telematik-ID von HBA und SMC-B sind disjunkt, das heißt, eine Telematik-ID repräsentiert entweder einen HBA oder mehrere SMC-B. 

Ein Krankenhaus kann durch mehrere Telematik-IDs vertreten sein, zum Beispiel wenn einzelne Fachabteilungen eigene Institutionskennungen erhalten sollen. 

Unabhängig von der Telematik-ID kann eine KIM-Adresse auch als persönliche Adresse oder als Funktions- bzw. Gruppenpostfachadresse benannt werden.

Festlegung der KIM-Adressen

Legen Sie bitte fest, welche Funktionspostfach-Adressen im VZD registriert werden sollen? Zum Beispiel, ob diese nach Fachabteilungen getrennt sind, und wie die jeweiligen Bezeichnungen lauten. 

Wie viele Funktionspostfächer sollen eingerichtet werden und unter welchen Telematik-ID sollen diese geführt werden. 

Falls persönliche Postfächer registriert werden sollen, müsste geklärt werden, wie sichergestellt wird, dass bei Abwesenheit entsprechende KIM-Abwesenheitsnotizen eingetragen werden. 

Zudem ist wichtig, wie die interne Bearbeitung der eingehenden Nachrichten erfolgt, die an ein Postfach adressiert sind – also bei persönlichen Postfächern, Gruppenpostfächern oder Verteilern. 

Wer hat Zugriff auf diese Postfächer? Und wie kann vermieden werden, dass mehrere Personen gleichzeitig an denselben Nachrichten arbeiten und dadurch Mehrfach-Bearbeitungen entstehen? 

Abschließend: Wie wird der Patientenkontext bei eingehenden KIM-Nachrichten hergestellt, um die Nachrichten korrekt zuzuordnen.

Internes Routing

Wohin und auf welche Weise werden eingehende KIM-Nachrichten in Ihrem Krankenhaus intern geroutet und den jeweiligen Empfängern zugänglich gemacht?

Grundsätzlich lassen sich dabei folgende Vorgehensweisen unterscheiden:

  • Die eingehenden KIM-Nachrichten werden den Nutzern direkt in einem Client des jeweiligen Primärsystems angezeigt.
  • Alternativ erfolgt die Zustellung über das bereits in Ihrem Krankenhaus etablierte E-Mail-System.
  • Zudem kann eine automatisierte Verarbeitung der eingehenden Nachrichten direkt innerhalb einer krankenhausinternen Fachanwendung stattfinden, beispielsweise anhand der Dienstkennung.

Versendung von KIM-Nachrichten

  • Welche Primär- oder Clientsysteme sind an den KIM-Nachrichtenverkehr anzubinden?
  • Wie und zu welchem Zeitpunkt wird die korrekte KIM-Adresse aus dem VZD ermittelt?
  • Besteht die Möglichkeit, diese Ermittlung innerhalb der beteiligten Clientsysteme zu automatisieren, beispielsweise beim Versand einer elektronischen Arbeitsunfähigkeitsbescheinigung an die Krankenkasse oder eines Entlassungsbriefs an den Hausarzt des Patienten?
  • Wie kann eine Verknüpfung zwischen der im Primärsystem enthaltenen Arztadresse (z. B. automatisiert über einen KBV-Eintrag) und einer KIM-Adresse hergestellt werden?
  • Wie lässt sich der VZD an einen bestehenden Mail-Client anbinden, beispielsweise über LDAP?
  • Wie kann eine automatisierte, korrekte KIM-Adressierung erfolgen?
  • Welche Möglichkeiten bietet das Primärsystem hierfür?
  • Wie können Medienbrüche für den KIM-Benutzer vermieden werden?
  • Wie werden automatisiert Nicht-Zustellungs-, Abwesenheits- und sonstige Fehler-Meldungen verarbeitet?

IP Routing

Für das IP-Routing ist es wichtig zu beachten, dass Sie das Routing vom KIM-Client-System zum (KIM-)Konnektor administrativ einrichten müssen. Falls in Ihrem Netzwerk ein Standard-Gateway verwendet wird, das den gesamten Internet-Verkehr abwickelt, würden ohne entsprechende Anpassungen alle Anfragen zunächst über dieses Gateway ins Internet geleitet, was dazu führen kann, dass die Nachrichten ins Leere laufen.

Da die KIM-Client-Systeme wahrscheinlich in unterschiedlichen Netzwerksegmenten betrieben werden, ist es notwendig, falls in Ihrem Krankenhaus kein eigenes DNS vorhanden ist, auf den Layer-3-fähigen Komponenten in Ihrem Netzwerk statische Routen zum KIM-Konnektor einzurichten. Falls der KIM-Nachrichtenverkehr über mehrere Konnektoren abgewickelt wird, müssen gegebenenfalls mehrere Routen eingerichtet oder der jeweils passende Konnektor adressiert werden.

Nutzung eines etablierten E-Mail-Systems zur Versendung von KIM-Nachrichten

Beim Versand von KIM-Nachrichten ist es wichtig sicherzustellen, dass die vom Client-System an das KIM-Clientmodul übergebenen Aufruf-Parameter korrekt, vollständig und auf den jeweiligen Kontext abgestimmt sind. Wir gehen davon aus, dass in der Regel das Client-System Ihres Primärsystems oder Ihrer Fachanwendung eine KIM-integrierende Funktion besitzt und die erforderliche Funktionalität für das Versenden von KIM-Nachrichten bereits integriert ist. 

Falls notwendig, kann es jedoch sinnvoll sein, ein separates Kommunikationssystem einzurichten, das den ein- und ausgehenden KIM-Verkehr zentral steuert, beispielsweise um bei ausgehenden Nachrichten automatisiert die Dienstkennung und die korrekte KIM-Adressierung vorzunehmen. 

Wenn Sie die Versendung von KIM-Nachrichten über Ihr etabliertes E-Mail-System ermöglichen möchten, sollten Sie festlegen, wie der Nutzer einen Empfänger aus dem VZD auswählt und wie die für die KIM-Kommunikation erforderlichen Parameter an den E-Mail-Client übergeben werden, damit eine Nachricht im Rahmen von KIM versendet werden kann. Zum Beispiel muss neben dem Benutzernamen (KIM-Mail-Adresse) auch der Aufrufkontext für den Konnektor bei SMTP- oder POP3-Login angegeben werden. 

Dabei ist zu klären, ob und wie diese zusätzlichen, kontextbezogenen Daten in Ihrem E-Mail-System verwaltet werden können, beispielsweise durch Plug-In-Lösungen. Außerdem sollten Sie beachten, dass die KIM-Anwendung möglicherweise nicht alle Funktionen des bereits genutzten E-Mail-Systems unterstützt, wie etwa die Funktion „Zustell- oder Lesebestätigung anfordern“, die nicht von allen E-Mail-Clients unterstützt wird. 

Schließlich ist es wichtig zu wissen, dass Sie für das Empfangen und Versenden von KIM-Nachrichten unterschiedliche Wege und Systeme zwischen dem Nutzer (und seinem Client-System) und dem KIM-Clientmodul einsetzen können.

KIM-Administrationsmodul

Ein weiterer wichtiger Bestandteil des KIM-Clientmoduls ist das Administrationsmodul, das die Verwaltung des Accounts des KIM-Teilnehmers ermöglicht. Dieses Modul kommuniziert sicher über eine TLS-Verbindung mit dem Account Manager des KIM-Fachdienstes. 

Mit Hilfe des Administrationsmoduls können Sie beispielsweise einen neuen KIM-Teilnehmer registrieren, einen bestehenden Teilnehmer abmelden, den aktuellen Registrierungsstatus abfragen sowie das benötigte Client-Zertifikat (PKCS#12-Datei) herunterladen – entweder manuell oder automatisiert. 

Zusätzlich bietet das Administrationsmodul die Möglichkeit, Abwesenheitsnotizen zu verwalten und die KIM-Mail-Adresse auf eine andere Telematik-ID zu portieren.

Exkurs Verzeichnisdienst (VZD)

Im VZD werden gemäß § 313 SGB V Daten zu Leistungserbringern, organisatorischen Einheiten von Leistungserbringern (wie z. B. Krankenhäuser oder Fachabteilungen) sowie anderen juristischen Personen oder deren Mitarbeitenden, die die Telematikinfrastruktur nutzen, gespeichert. Diese Daten umfassen den Namen, die Adressdaten, technische Adressierungsdaten, eine eindeutige Telematik-ID, das Fachgebiet und den öffentlichen Teil der technischen Identität des Nutzers. Daten von Versicherten werden nach aktueller Gesetzeslage im VZD nicht geführt.

Sowohl der Ersteintrag als auch die laufende Pflege der VZD-Daten werden von unterschiedlichen Akteuren übernommen. Nach der Ausgabe einer oder mehrerer SMC-B zu einer Telematik-ID legt der jeweilige Kartenherausgeber (bei Krankenhäusern beispielsweise die DKTiG) einen initialen Datensatz im VZD an und ergänzt ihn mit Basisdaten. Die Identifikation des Datensatzes im VZD sowie die Zuordnung der eingetragenen natürlichen oder juristischen Person bzw. Institutionseinheit erfolgt ebenfalls über die Telematik-ID. Bitte beachten Sie, dass diese Basisdaten zunächst keine über KIM adressierbaren E-Mail-Adressen enthalten.

Datenmodell des VZD

Das vollständige Datenmodell des VZD können Sie der gematik-Spezifikation „Verzeichnisdienst“ [https://gemspec.gematik.de/docs/gemSpec/gemSpec_VZD/] entnehmen.  Die sektorspezifische Ausprägung für Krankenhäuser wird Ihnen von Ihrem Kartenherausgeber mitgeteilt.

Dienstkennung und Datenformate

KIM bietet die Möglichkeit, eine E-Mail vor dem Versenden entsprechend ihres Nachrichteninhalts zu kategorisieren. Dafür wurden spezielle Dienstkennungen festgelegt, die auf den im Medizinumfeld erwarteten Nachrichtenverkehr abgestimmt sind. Durch die Auswertung dieser Dienstkennung ist es beim Empfang einer E-Mail möglich, eine automatisierte Weiterverarbeitung der E-Mail oder ihres Anhangs (z. B. eines elektronischen Arztbriefs) durch das Primärsystem oder ein spezielles Zielsystem durchzuführen. Eine Übersicht aller bisher von den jeweiligen Akteuren festgelegten Dienstkennungen sowie deren Spezifikationen finden Sie:

  • im Fachportal [KIM - Kommunikation im Medizinwesen], oder unter
  • gematik [KIM - Schnell und sicher kommunizieren],


sowie in den FAQs zu KIM.

FAQs zu KIM

QES Arztbrief

Muss ein elektronischer Arztbrief immer qualifiziert elektronisch signiert (QES) werden? 

Nein, dazu bestehen keine gesetzlichen oder technischen Vorgaben. Auch die Anwendung KIM funktioniert grundsätzlich ohne HBA. Allerdings werden in der vertragsärztlichen Versorgung gemäß § 383 SGB V nur per QES signierte und via KIM versendete elektronische Arztbriefe vergütet.

E-Mail-Adressen pro SMC-B

Wie viele E-Mail-Adressen kann ich in KIM, dem sicheren E-Mail-Dienst in der TI, einer SMC-B zuordnen?

Sie können in KIM bis zu 1000 E-Mail-Adressen pro SMC-B hinterlegen. Dabei verfügt jede SMC-B über einen sogenannten Basiseintrag im Verzeichnisdienst, der das Hinterlegen und Verwalten von E-Mail-Adressen ermöglicht.

Aufwandsreduktion der KIM-Arbeitsplätze-Konfiguration

Wie kann der Aufwand bei der Konfiguration von KIM-Arbeitsplätzen im Konnektor verringert werden?

Es gibt einige Konfigurationsmöglichkeiten, mit denen Sie den Administrationsaufwand bei der Einrichtung von KIM-Arbeitsplätzen im Konnektor reduzieren können. 

Zum Beispiel verfügt das Primärsystem (PS) über einen Arbeitsplatz-Verwaltungsmechanismus. Damit können verschiedene reale Arbeitsplätze auf einen virtuellen Arbeitsplatz gemappt werden, indem ein statischer KIM-Aufrufkontext (Mandant#Clientsystem#Arbeitsplatz) verwendet wird. Dieser virtuelle Arbeitsplatz wird der Telematikinfrastruktur bekannt gemacht. 

Der Arbeitsplatz-Verwaltungsmechanismus sorgt dafür, dass alle Interaktionen von den realen Arbeitsplätzen in Richtung der TI auf den virtuellen Arbeitsplatz gemappt werden. Die Antworten aus der TI werden dann wieder den realen Arbeitsplätzen zugeordnet. Die gematik sieht in dieser Lösung kein Sicherheitsrisiko. 

Für Krankenhäuser und medizinische Einrichtungen ähnlicher Größe ist es außerdem vorteilhaft, wenn der Arbeitsplatz-Verwaltungsmechanismus mehrere Konnektoren (bzw. im Fall von KIM mehrere KIM-Clientmodule) parallel verwalten kann. Das erhöht die Performance und Verfügbarkeit.

KIM-Performance

Wie wirken sich SMC-B-Kopien (gleiche Telematik-ID) auf die Performance von KIM aus? 

Grundsätzlich ist zu sagen, dass eine Beschränkung der Nutzung von SMC-B auch eine Begrenzung der möglichen E-Mail-Empfänger bedeuten würde. Das ist bei E-Mail-Systemen jedoch nicht der Fall.

Die gematik hält eine Richtgrenze von etwa 50 Schlüsseln (ein Schlüssel entspricht einem Zertifikat auf der SMC-B) beim Senden und Empfangen von KIM-Nachrichten für akzeptabel. Das bedeutet:

  • Bei SMC-B der Generation 2.1, bei denen jeweils 2 Schlüssel pro Karte vorhanden sind (RSA und ECC), sind bis zu 25 Karten möglich.
  • Bei älteren Generationen (vor 2.1) sind bis zu 50 Karten möglich.

Es gibt aber auch Krankenhäuser, die bis zu 100 Karten im Einsatz haben und keine Performanceprobleme melden.

Wenn jedoch eine zu hohe Systembelastung festgestellt wird, könnten folgende Maßnahmen helfen:

  • Die Karten auf mehrere Telematik-ID verteilen (was in der Konfiguration etwas umständlich sein kann).
  • Oder separate Konnektoren nur für KIM verwenden.
  • Oder eine Kombination aus beidem.

Hintergrund: Beim Versenden einer Nachricht wird diese mit allen Schlüsseln des Empfängers und mit allen Schlüsseln des Absenders verschlüsselt. Der Empfänger kann dann wählen, mit welchem seiner SMC-B er die Nachricht entschlüsseln möchte. Da der Absender das vorher nicht weiß, wird die Nachricht für alle möglichen Empfängerschlüssel verschlüsselt.

Der Absender verschlüsselt die Nachricht auch für seine eigenen Schlüssel, falls die Nachricht zurückgewiesen wird und er sie erneut entschlüsseln muss. Auch hier ist vorher nicht bekannt, welcher Schlüssel verwendet wird.

Ein Performance-Engpass könnte also bei der Kommunikation mit Einrichtungen auftreten, die viele Schlüssel haben – zum Beispiel bei großen Krankenhäusern.

Wenn Krankenhäuser viele Schlüssel nutzen, kann es aufgrund der Absenderverschlüsselung zu Performance-Problemen kommen. Ebenso kann es bei Empfängern, wie Praxen, zu Verzögerungen kommen.

In der Regel wird der Versand und Empfang von E-Mails nicht als zeitkritisch angesehen. Die Dauer des Nachrichtentransports durch das eigene System ist meist unerheblich; Unterschiede von fünf Sekunden bis zu einer Minute spielen in der Praxis kaum eine Rolle.

Die gematik hat unter Laborbedingungen mehrfach erfolgreich Nachrichten an bis zu sechs Empfänger mit jeweils 50 Zertifikaten versendet. Die genaue Handhabung zahlreicher Zertifikate durch KIM-CM-Hersteller ist jedoch nicht durch die Vorgaben der gematik geregelt.

SMC-B-Austausch

Was muss beim Austausch von abgelaufenen SMC-B hinsichtlich KIM beachtet werden?

Beim Austausch einer abgelaufenen SMC-B ist es wichtig, dass die neue und die alte SMC-B so lange gleichzeitig im System verbleiben, bis Sie sicher sind, dass Sie alle E-Mails, die Sie vor dem Einstecken der neuen SMC-B erhalten haben, vom Mailserver abgeholt und erfolgreich entschlüsselt haben. Erst danach können Sie die alte SMC-B entfernen.

Nachrichten-Entschlüsselung mit abgelaufenen SMC-B

Wie werden KIM-Nachrichten entschlüsselt, wenn die SMC-B bereits abgelaufen ist?

Wenn KIM-Nachrichten mit einer inzwischen abgelaufenen SMC-B verschlüsselt wurden, können diese Nachrichten trotzdem weiterhin mit der alten Karte entschlüsselt werden. Der Grund dafür ist, dass der Konnektor beim Entschlüsseln nicht prüft, ob das Zertifikat noch gültig ist.

Geltungsbereich für SMC-B vom Typ ‚Krankenhaus‘

Die SMC-B eines Krankenhauses stellt gegenüber der Telematikinfrastruktur (TI) die elektronische Identität einer Organisation, Einrichtung oder Institution vom Typ „Krankenhaus“ dar. Genauere Informationen dazu finden Sie auf den Internetseiten der [DKTIG]. Bei Bedarf können Sie sich auch an die dort angegebenen Ansprechpartner oder Anlaufstellen wenden. 

Bereiche innerhalb eines Krankenhauses, die nicht direkt der Institution „Krankenhaus“ zugeordnet sind – zum Beispiel persönlich ermächtigte Ärzte (siehe § 116 SGB V) oder allgemein „Vertragsärzte“ – benötigen keine eigene institutionelle SMC-B, solange eine datenschutzwirksame Trennung zwischen Zugriffsberechtigten und Nicht-Zugriffsberechtigten auf die persönlichen Daten eines Versicherten gewährleistet ist. Das erfolgt beispielsweise durch das gemeinsam genutzte KIS. Weitere Informationen dazu finden Sie auch in den TI-Hinweisen der DKG im Kapitel 3.4: [TI-Hinweise 3.2]. 

In vielen Krankenhäusern ist es üblich, dass das KIS gemeinsam von Vertragsärzten und der Organisation „Krankenhaus“ genutzt wird. Es liegt im Ermessen des Krankenhauses – natürlich in Abstimmung mit den Vertragsärzten –, wie viele SMC-B-Karten eingesetzt werden, um sowohl Datenschutz- als auch Wirtschaftlichkeitsanforderungen optimal zu erfüllen. 

  • No labels