14.09.2021 - Aktuell kann es bei der elektronischen Patientenakte (ePA) kurzzeitig zu Einschränkungen bei der Nutzung kommen.:
Mehr erfahren

10.09.2021 - ePA: Maintenance ePA (Stufe 2): Die aktuelle Vorabveröffentlichung der gematik vom 10.09. steht ab sofort zum Download zur Verfügung. Die Rückmeldefrist endet am 17.09.2021.
Mehr erfahren

03.09.2021 - TI-Statusmeldung: Aktuell kommt es zu Interoperabilitätsproblemen an der Signaturschnittstelle des KoCoBox MED+ Konnektors der Version 4.2.10.
Weiterführende Informationen finden Sie hier:
Mehr erfahren

02.09.2021 - Konnektor PTV 5.0.2: Ab sofort steht Ihnen das Wartungsrelease "Maintenance 21.5" zum Download zur Verfügung.
Mehr erfahren

31.08.2021 - Vorabveröffentlichung Highspeed-Konnektor: Die Featurespezifikation zum Highspeed-Konnektor und die dazugehörigen Steckbriefe stehen ab sofort zum Download zur Verfügung. Die Rückmeldefrist endet am 13.09.2021.
Mehr erfahren

FAQ

Themenübergreifende FAQ-Seite

Die nachfolgenden FAQ-Listen basieren vornehmlich auf Rückmeldungen aus der Industrie zu den Spezifikationen und Konzepten der gematik. Die FAQ umfassen sowohl die Beantwortung von Verständnisfragen als die Richtigstellung von formalen Inkonsistenzen. Weder die Fragen noch die Antworten verändern den Scope des Online-Produktivbetriebs der TI.

Die in den FAQ gegebenen Antworten repräsentieren die in Abnahme- und Zulassungstests gültige Interpretation.

Die gematik behält sich vor, die Inhalte der FAQ in einem zukünftigen Release in die Konzept- bzw. Spezifikationsdokumente zu übernehmen.

Spezifikations- und releasebezogene FAQ

FAQ Release 3.1.2

7z | 710 KB

Die FAQ beziehen sich insbesondere auf ePA

Download

Fragen aus der Praxis

Konnektorsimulator für Primärsysteme

Bitte prüfen Sie, ob im Konsolenfenster Fehlermeldungen mit dem Text „java.net.BindException: Address already in use: bind“ ausgegeben werden. Wenn ja, prüfen Sie, ob die konfigurierten Ports (zu finden unter Oberfläche => Einstellungen) frei sind (z.B. unter Windows mit „netstat -an -p TCP“). Die Standardports 80 bzw. 443 können ggf. von anderen Anwendungen belegt sein. In diesem Fall müssen Sie die Standardports ändern. Bitte prüfen Sie nach der Änderung das KoPS-Konsolenfenster erneut auf Fehlermeldungen. Tritt keine Fehlermeldung mit dem Text „java.net.BindException: Address already in use: bind“ auf, ist KoPS richtig konfiguriert.

Der Testsuite liegt folgende Anforderung aus der gematik-Spezifikation „Implementierungsleitfaden Primärsysteme“ [gemILF_PS] zugrunde:

TIP1-A_4959: Konfigurierbarkeit von Kontext-Parametern

Innerhalb des Primärsystems MUSS eine Konfigurationsverwaltung vorhanden sein, welche die Parameter MandantId, ClientSystemId, WorkplaceId und UserId entsprechend Abb_LFPS_01_Element Context gemäß ConnectorContext.xsd” abbildet. Die Parameter sind alphanumerisch und haben eine Maximallänge von 64 Zeichen.

Die Überprüfung dieser MUSS-Anforderung erfolgt mithilfe von unverändlichen Clienttparametern.

Bitte hängen Sie allen im Testschritt „Screenshots anhängen“ beschriebenen Prüfpunkten ein Screenshot an.

Es wird eine Fehlermeldung im Primärsystem mit den folgenden Aussagen erwartet: „Der Typ der Karte ist unbekannt.“

Mögliche Fehlerursachen können sein:

  • keine eGK/KVK gesteckt
  • Karte nicht lesbar
  • Karte falsch gesteckt
  • „alte“ eGK gesteckt

Im Fall einer „alten“ elektronischen Gesundheitskarte (älter als G2; siehe Kartenaufdruck) besteht kein Leistungsanspruch. Bitte erkundigen Sie sich beim Versicherten, ob die gesteckte eGK die aktuelle elektronische Gesundheitskarte ist. Verweisen Sie ggf. an die Krankenversicherung für einen Austausch der Karten.

Die Fehlermeldung zu Fehlercode 105 muss einen Hinweis enthalten wie „Die eGK ist fehlerhaft/defekt. Bitte setzen Sie sich mit Ihrer Krankenversicherung in Verbindung.“

Im Falle einer gesperrten PIN (nach mehrfacher Falscheingabe der PIN) muss das Primärsystem zur Eingabe der PUK auffordern, nicht der PIN.

Die VSDM-Testfallkataloge sind in der aktuellen Version 1.0.6 für KoPS Puppetry und KoPS 2.1 inhaltlich identisch und damit derzeit gleichwertig in puncto Bestätigungsverfahren für die Konformität des Primärsystems zur Konnektorschnittstelle. Somit kann derzeit eine Bestätigung der VSDM-Funktionalität sowohl mit KoPS Puppetry als auch mit KoPS 2.1 erfolgen.

Das Fachmodul prüft das XML-Dokument gegen das Schema sowie alle in [gemSpec_InfoNFDM/gemSpec_Info_AMTS] aufgeführten Validitätskriterien. Schlägt die Validierung fehl, bricht das Fachmodul die Operation mit dem Fehler 5017 (NFDM) bzw. dem Fehler 6058 (AMTS) ab. KoPS 2.1 gibt ab Version 2.1.16 Detailinformationen zu den fehlgeschlagenen Validitätskriterien t, um Ihnen die Fehlersuche zu erleichtern. Diese Detailinformationen werden unter Umständen von den Konnektoren nicht in die Response generiert. Die Syntax der Detailinformation bildet den Pfad zu dem Element/Attribut, welches fehlerhaft ist. Das ist also der technische Pfad, wie er in der XSD bzw. im übersetzen Java-Code abgebildet ist.

Zum Beispiel bedeutet die Meldung amts.mp.s.0.mOrXOrR.0.m.ps [Das Element darf nicht vorhanden sein.]: Der Fehler liegt hier im „AMTS-Dokument“ [amts] > im „MP-Datensatz“ [mp] > in der 0-ten (Nullten) „Gruppierung von Medikationseinträgen“ [s.0] > im 0-ten (Nullten) meTyp (also „Medikation“ oder „Freitextzeile“ oder „Rezeptur“) [mOrXOrR.0] > der meTyp ist eine „Medikation“ [m] > im „Code-System PZN“ [ps].

Gemäß Spezifikation für den Konnektor dienen die veröffentlichten Schnittstellenbeschreibungen als Grundlage für die Implementierung. Daher ist die Bereitstellung der WSDLs zur Laufzeit nicht notwendig. Ein Primärsysystem muss ohne WSDLs mit dem Konnektor kommunizieren können. Zur Laufzeit stellt der Konnektor den Dienstverzeichnisdienst zur Verfügung.

KoPS 2.1 stellt nur den DVD, nicht die WSDL zur Verfügung.

Personalisierungsvalidierung

Vor der Durchführung einer Personalisierungsvalidierung ist es notwendig, dass Sie überprüfen, ob die aktuellen Trust-Service Status Lists im PVTe G2 hinterlegt sind.

Trust-Service Status List für Produktivraum

Dazu laden Sie bitte die TSL für den Produktivraum hier https://download.tsl.ti-dienste.de/TSL.xml und für ECC Zertifikate hier https://cloud.gematik.de  herunter. Dadurch wird mehr als eine TSL in einem Ordner akzeptiert.

Zum Hinterlegen der TSL führen Sie folgende Schritte durch:

  1. Beenden Sie PVTe G2.
  2. Löschen Sie dier Dateien unter /PVTeG2/Artefakte/tslProd/
  3. Kopieren Sie die neuen TSLs in das Verzeichnis /PVTeG2/Artefakte/tslProd/
  4. Starten Sie nun PVTe G2 neu.

 

Trust-Service Status List für

Die Trust-Service Status List des Testraumes lässt sich ebenfalls aktualisieren. Dazu laden Sie bitte die TSL hier https://download-testref.tsl.ti-dienste.de/TSL-testref.xml und für ECC-Zertifikate hier https://cloud.gematik.de herunter.

Zum Hinterlegen der TSL führen Sie folgende Schritte durch:

  1. Beenden Sie PVTe G2.
  2. Löschen Sie die Dateien unter /PVTeG2/Artefakte/tslTest/
  3. Kopieren Sie die neuen TSLs in das Verzeichnis /PVTeG2/Artefakte/tslTest/
  4. Starten Sie nun PVTe G2 neu.

Hinweis:
Momentan werden weder in der Testumgebung noch in der Produktivumgebung X.509 CA-Zertifikate auf Basis elliptischer Kurven bereitgestellt.

Damit bei der Personalisierungsvalidierung die in den Karten enthaltenen X.509-Zertifikate auf Basis elliptischer Kurven geprüft werden können, stellt die gematik im Downloadportal unter https://cloud.gematik.de spezielle TSLs bereit, die X.509-CA-Zertifikate auf Basis elliptischer Kurven enthalten und regelmäßig aktualisiert werden.

Für die Datenigration vom Truecrypt-Container pvte.tc in einen VeraCrypt-Container gibt es zwei Möglichkeiten.

Möglichkeit 1

Sie können den Container pvte.tc aus der alten VM auf einen USB-Stick kopieren und in die neue VM unter /PVTeG2/VeraCrypt/ kopieren. Bitte benennen Sie die Datei um in „pvte.vc“. Beim Start von PVTe müssen Sie nun bei der Aufforderung „Enter password“ immer den „TrueCrypt Mode“ aktivieren.

Möglichkeit 2

Sie öffnen PVTe G2 in der alten VM und kopieren sich die Daten aus /PVTeG2/Dokumente auf einen USB-Stick. Sie legen sich einen neuen Container pvte.vc in der neuen VM an (weitere Informationen hierzu finden Sie auch in der Anwenderdokumentation), öffnen PVTe G2 und kopieren sich die Daten in den Ordner /PVTeG2/Dokumente.

Bei der Durchführung einer Validierung der Personalisierung im Rahmen des Bestätigungsverfahrens muss die aktuelle PU TSL verwendet werden.

Sie erreichen den Downloadbereich unter https://cloud.gematik.de

Als Benutzername können Sie entweder die E-Mail-Adresse oder den per E-Mail versendeten Benutzernamen verwenden.

Der Link für das erstmalige Setzen des Passwortes ist 12 Stunden gültig. Nach Ablauf dieser Zeit erscheint beim ersten Anmelden der Fehler „Das Passwort konnte aufgrund eines ungültigen Tokens nicht zurückgesetzt werden“. Bitte nutzen Sie die Funktion „Passwort vergessen?“, um ein neues temporäres Passwort zu erhalten.

Für die Nutzung von PVTe G2 sind ab dem 4. Quartal 2018 folgende (im Rahmen der Softwarewartung und -pflege) notwendigen Systemvoraussetzungen zu erfüllen:

Kriterium: Anforderung Minimum/Anforderung Empfohlen

Architektur: 64 bit

Freier Festplattenspeicher: 10 GB/20 GB

RAM: 8 GB/ 16 GB

Prozessorleistung: 2 GHz Dual-core

Bildschirmauflösung: 1366x768/1920x1080

Eingabegeräte: Maus und Tastatur

Kartenlesegerät: ORGA 6041 L oder Identive 4700 F/4701 F

VMware Player/Workstation: Version 14

Die Hardwareanforderungen werden für 3 Jahre beibehalten.

Beachten Sie bitte, dass:

  • die Version des VMware Players zukünftig einmal jährlich aktualisiert wird,
  • die Hardwareanforderungen gegebenenfalls alle 3 Jahre aktualisieren werden,

PVTe G2 ab dem 2. Quartal 2017 nicht mehr auf den „Prüfkoffer“-Laptops ausgeführt werden kann, da eine 32-Bit-Architektur nicht mehr unterstützt wird.

Die Änderungen zur Vorversion der Software sind in den Release Notes beschrieben. Darüber hinaus enthalten die Release Notes einen Hinweis auf die geänderten Testspezifikationen.

Die Änderungen zur Vorversion der Testfälle sind in den Testspezifikationen gelb markiert. Die Testspezifikationen sind im VMware Image im Ordner „Testspezifikationen“ hinterlegt.

Wenn Fehler auftreten, die bei der Nutzung der Vorversion nicht aufgetreten sind, kann dies an zwei Punkten liegen: Zum einen verbessern und aktualisieren wir die Testsuite kontinuierlich. Zum anderen ist es unser Ziel, stets den zuletzt veröffentlichten Spezifikationsstand zu unterstützen. In beiden Fällen können Prüfungen hinzugekommen sein, wodurch neue Fehlermeldungen bedingt werden können.

Bei Fragen zu fehlgeschlagenen Testfällen hilft Ihnen die gematik gern. Schreiben Sie uns: pv-support@gematik.de.

Dies ist im Einzelfall zu entscheiden. Bitte schauen Sie sich die Änderungen der Software und die Änderungen in den Testspezifikationen an. Der Einsatz der neuen Version in der Qualitätssicherung hängt unter anderem vom Spezifikationsstand des jeweiligen Kartentyps ab.

Tipp: Behalten Sie in Ihrem VMware Player das VMware Image der alten Version bei und laden das neue VMware Image ebenfalls in den VMware Player. So können Sie einfach zwischen der alten und neuen Version wechseln.

Das VMware Image wird „restricted“, d.h. verschlüsselt, bereitgestellt. Laut den Lizenzinformationen von VMware kann das Image nur mit einer lizenzierten VMware-Player-Plus-Version gestartet werden.

Die PIN ist noch transportgeschützt und muss freigeschaltet werden. Bitte schalten Sie die PIN über den Menüpunkt „Einstellungen => PIN der Berechtigungskarte ändern“ frei. Führen Sie den Vorgang erneut aus.

Im Dateinamen des ZIP-Archives finden Sie zwei Versionsnummern: z.B. PVTe_G2_v1.8.2_VM_v1.8.10.zip.

PVTe_G2_v1.8.2 ist die Versionsnummer von PVTe G2; VM_v1.8.10 ist die Versionsnummer des gesamten VMware Images.

Die Release Notes enthalten in Kopfzeile und Dokumententitel einen Verweis auf die PVTe-G2-Version. Zusätzlich dazu hat das Dokument eine Versionsnummer, die in der Fußzeile und auf dem Deckblatt steht.

Die verschiedenen Artefakte werden versioniert, da sich z.B. Änderungen an dem VMware Image aber nicht an PVTe G2 ergeben können oder an dem Release-Notes-Dokument, aber nicht an PVTe G2.

Testportal der gematik

Das Testportal der gematik unterstützt Hersteller und Anbieter von Fachanwendungen und Fachdiensten der Telematikinfrastruktur bei eigenverantwortlichen Tests der Produkte in der Referenzumgebung der Telematikinfrastruktur. Das Testportal ermöglicht sowohl die Ausführung einer automatisierten Testsuite als auch eine manuelle Auswahl einzelner Testfälle.

Nutzen Sie das gematik-Testportal für Regressionstests nach dem Austausch einzelner Komponenten in Ihrem Produkt sowie nach Updates involvierter Softwaremodule, um zu erkennen, ob Ihr Produktes weiterhin stabil funktioniert.

Das Testportal ist ein Angebot der gematik für Hersteller und Anbieter von Fachanwendungen und Fachdiensten, wie z.B. VSDM, für die Durchführung von Regressionstests.

Vor Nutzung des gematik-Testportals müssen Sie im Besitz eines Nutzerkontos und Ihre zu testende Fachanwendung bzw. Ihr zu testender Fachdienst muss über einen sicheren zentralen (Gast-)Zugangspunkt (SZZP) freigeschaltet sein. Beides wird im Rahmen eines mit Ihnen abgestimmten Vorgehens sichergestellt.

Das Testportal ist eine Webanwendung, mit dem Sie Ihre Fachanwendung bzw. Ihren Fachdienst mithilfe von Testsuiten und Testfällen der gematik testen können.

Loggen Sie sich hierfür in das Testportal der gematik ein und registrieren Sie Ihre Fachanwendungen oder Ihren Fachdienst als ein Testobjekt. Nach Auswahl der spezifischen Testfälle aus den Ihnen zur Verfügung stehenden Testsuiten starten Sie den Testlauf.

Das gematik-Testportal informiert Sie stetig über den Testfortschritt. Am Ende des Testlaufs erhalten Sie eine Zusammenfassung des gesamten Testlaufs. Anschließend können Sie die Testdokumentation als PDF herunterladen und diese auf Fehler und Probleme hin analysieren.

Das Testportal garantiert, dass kein Dritter Einsicht in Ihre Daten wie Nutzerprofil, Testergebnisse und Testprotokolle erhält.

Sie können das Testportal für jeweils 3 Monate abonnieren. Der Preis für das Testportal beträgt je Monat für die Testplattform 214 Euro (netto), für die PKI-v1-Testsuite 62 Euro (netto) und für die VSDM-Testsuite 21 Euro (netto) zzgl. einer einmaligen Einrichtungsgebühr von 500 Euro (netto). Sie können die Anmietung für maximal 6 Monate unterbrechen, ohne eine Einrichtung erneut beantragen und bezahlen zu müssen.

Der Mindestbestellwert umfasst die Testplattform sowie mindestens eine Testsuite. Zusätzlich bietet Ihnen die gematik einen Anwendersupport für 105,- Euro (netto) je angefangener Stunde.

Sie erreichen den Support unter betrieb[at]gematik(dot)de

Alle Preise verstehen sich jeweils zzgl. der gesetzlichen Umsatzsteuer.

Nutzen Sie das gematik-Testportal, solange Sie wollen! Ihr Abonnement läuft über 3, 6, 9 oder 12 Monate. Sie können Ihr Abonnement jederzeit verlängern. Außerdem können Sie Ihr Abonnement für maximal 6 Monate ohne erneute Einrichtungsgebühr ruhen lassen.

Die gematik unterstützt Sie kostenfrei bei der Freischaltung Ihrer Fachanwendung bzw. Ihres Fachdienstes im Testportal.

Neben der Unterstützung zur Freischaltung können Sie einen zusätzlichen kostenpflichtigen Anwendersupport (105 Euro (netto)/je angefangene Stunde) anfragen. Sie erreichen den Support unter betrieb[at]gematik(dot)de

Die gematik bietet Ihnen diesen Service von Montag bis Freitag (ausgenommen bundeseinheitliche Feiertage) von 09:00 Uhr bis 17:00 Uhr an.

Um das Testportal der gematik zu bestellen, nutzen Sie bitte das Bestellformular. Bitte bestätigen Sie Ihre Zustimmung zur DSVGO sowie zu den Nutzungsbedingungen.

Fokusbereich: Krankenhäuser

VSDM, NFDM, eMP/AMTS

Ja, eine SMC-B des Krankenhauses ist für den Online-Abgleich des VSDM ausreichend. Allerdings sollte man die Hinweise der DKG e.V. zur Ausfallsicherheit befolgen. Der Einsatz eines HBAs ist dabei nicht erforderlich.

Nein, für die Nutzung der Anwendung Notfalldaten-Management (NFDM) spielt es keine Rolle, ob für schreibende oder lesende Zugriffe dieselben Komponenten genutzt werden oder ob dies durchgängig am selben Arbeitsplatz geschieht. Ausschlaggebend ist die Verwendung derselben Telematik-ID.

Die Trennung von Arbeitsschritten ist explizit möglich. Beim NFDM dient die SMC-B lediglich zur Durchführung einer rollenbasierten Berechtigungsprüfung – falls kein elektronischer Heilberufsausweis (HBA) verwendet wird. Daher stellt das NFDM keine impliziten Anforderungen an die Verwaltung von SMC-Bs; demzufolge auch keine Anforderung an die Mandantenverwaltung im Krankenhaus.

Beachten Sie, dass sich die Fachanwendung elektronische Patientenakte (ePA) sich bei der SMC-B-Verwendung deutlich von der Anwendung NFDM unterscheidet. Im Unterschied zum NFDM werden bei der ePA die SMC-B-Zertifikate zur Identifizierung gegenüber dem ePA-Aktensystem aktiv verwendet. Hier spielt hier die Mandantenverwaltung eine wichtige Rolle.

Hintergrund der Frage:
Eine medizinische Fachkraft nimmt einen Patienten ambulant oder stationär auf. Es könnte hilfreich sein, wenn das Primärsystem automatisch anzeigt, ob sich bereits ein Notfalldatensatz (NFDM) oder ein elektronischer Medikationsplan (eMP) auf der elektronischen Gesundheitskarte (eGK) befindet.

Antwort:
Die Daten auf der elektronischen Gesundheitskarte gehören dem Versicherten. Grundsätzlich entscheidet er darüber, wer auf die Daten auf seiner eGK zugreifen darf.
Es gilt jedoch folgende Ausnahme: Im Notfall können Notfalldaten auf der eGK immer dann gelesen werden, wenn dies für die Versorgung der Versicherten erforderlich ist (gemäß § 359 Absatz 1 Satz 1 Nummer 1 SGB V) und der Versicherte nicht in der Lage ist, sein Einverständnis zu geben. Im Zweifel jedoch ist der Zugriff beim Versicherten zu erfragen.

Die Anzeige von Notfalldaten oder dem elektronischen Medikationsplan im Primärsystem sollte demnach nicht ohne Einverständnis des Patienten erfolgen. Das Primärsystem kann aber selbstverständlich Hinweise geben, das Einverständnis des Patienten zu erfragen.

Informationsmodell und Mandantenmodell

Hintergrund der Frage: 
In einem Krankenhaus ist jeder Fachabteilung inklusive Patientenaufnahme eine eigene SMC-B zugeordnet. Der Patient erteilt während der Patientenaufnahme den Zugriff auf seine elektronische Patientenakte (ePA). Wenn noch keine Anamnese erfolgt ist oder erfolgen kann, ist zum Zeitpunkt dieser initialen Zugriffserteilung die behandelnde Fachabteilung noch nicht bekannt.

Antwort:
Da hier das fachabteilungsgetriebene Modell verfolgt wird, muss der Patient dem Zugriff auf seine ePA separat zustimmen, sobald die behandelnde Abteilung wechselt (Näheres dazu finden Sie im Dokument „Anschluss von Krankenhäusern an die TI“). Kann im Krankenhaus für ePA jedoch das anwendungsgetriebene SMC-B-Modell genutzt werden, wäre eine erneute Einwilligung des Patienten nicht erforderlich.

Die Konfiguration der Arbeitsplätze inklusive Zuordnung der SMC-Bs zum Arbeitsplatz sollte immer auf Grundlage eines durchdachten Konzepts erfolgen. Demnach ist es beispielsweise sinnvoll, einem Fachabteilungsarbeitsplatz genau die SMC-B dieser Fachabteilung zuzuordnen, nicht eine beliebig andere SMC-B.

Aus Performance-Gründen empfiehlt es sich, mehrere SMC-Bs zugreifbar zu machen. In diesem Fall ist darauf zu achten, dass diese SMC-Bs dieselbe Telematik-ID aufweisen.

Wichtig ist weiterhin, dass auch das Krankenhausinformationssystem (KIS) das Informationsmodell des Konnektors entsprechend unterstützt. Andernfalls wählt der Konnektor tatsächlich eine (beliebige) dem Aufrufkontext zugeordnete SMC-B aus.

Hintergrund der Frage:
Aufgrund mangelhafter Mandantenverwaltung über das Informationsmodell des Konnektors wurden zu einem Mandanten mehrere SMC-Bs mit unterschiedlichen Telematik-ID angelegt.

Antwort:
Wenn das Informationsmodell „ungünstig“ konfiguriert ist, kann es sein, dass der Konnektor eine der verfügbaren unterschiedlichen Telematik-IDs zufällig auswählt. Dies kann, wie in der Frage bereits angedeutet, bei nachfolgenden Aktivitäten zu Problemen führen. So kann bspw. das Einstellen von Dokumenten in die elektronische Patientenakte gestört sein, wenn dafür eine andere als die anfangs verwendete Telematik-ID den weiteren Aktenzugriff gewähren soll. 
In der eigentlichen Ad-hoc-Autorisierung ist zunächst kein Fehler zu erkennen.

Hintergrund der Frage:
Die SMC-Bs werden im Informationsmodell des Konnektors dem TI-Mandanten zugeordnet, nicht den Arbeitsplätzen (siehe auch Konnektorspezifikation [gemSpec_Kon#PIC_KON_100]).

Antwort:
Zu einer gut konfigurierten Mandantenverwaltung gehört, dass bestimmte Mandanten ausschließlich bestimmten Arbeitsplätzen zugeordnet sind (z. B. Zuweisung der Institutions-SMC-B nur für Arbeitsplätze dieser Fachabteilung, nicht zu Arbeitsplätzen anderer Fachabteilungen).
Der Aufruf mit Angabe des Kontextes kommt vom Krankenhausinformationssystem (KIS). Der Konnektor erkennt diese Zuordnung zwar indirekt über die Mandanten-ID, kann aber selbst keine Qualitätsprüfung der Konfiguration vornehmen. Die Mandantenkonfiguration schlägt somit die Brücke vom Nutzer und seinem Arbeitsplatz zu der ihm zugeordneten SMC-B.

Elektronische Patientenakte

In einem Krankenhaus können grundsätzlich Ärzte, Zahnärzte sowie für die von Ärzten für den Zugriff beauftragten berufsmäßigen Gehilfen oder Personen, die zur Vorbereitung auf diesen Berufen in einem Krankenhaus tätig sind, auf diese Anwendungen zugreifen. Über das Krankenhausinformationssystem können Sie die Zugriffsrechte verfeinern.

Für einen lesenden Zugriff auf ePA, NFDM und eMP/AMTS ist kein elektronischer Heilberufsausweis (HBA) erforderlich; das Lesen kann auch mittels einer SMC-B erfolgen.

Anders verhält es sich beim schreibenden Zugriff. So erfolgt die Erstellung oder Aktualisierung des Notfalldatensatzes (NFD) mittels einer qualifizierten elektronischen Signatur (QES). Hierfür wird ein HBA benötigt. Mit der QES wird der NFD signiert, für das Übermitteln des QES-signierten NFD auf die eGK des Patienten ist wiederum lediglich eine SMC-B erforderlich. Die Übermittlung des aktualisierten NFD auf die eGK des Versicherten kann zeitlich und räumlich getrennt zur QES des NFD erfolgen.

Einige Dokumente, die in die elektronische Patientenakte geladen werden können, wie der elektronische Arztbrief und die elektronische Arbeitsunfähigkeitsbescheinigung (eAU) erfordern ebenfalls eine QES-Signierung.

Das Lesen, Anlegen oder Aktualisieren eines eMP erfordert generell keinen HBA-Einsatz.

Hintergrund der Frage:
Generell ist für die Nutzung der elektronischen Patientenakte (ePA) eine Verschlüsselung auf Fachabteilungsebene nicht zwingend. Aus (prozess)technischer Sicht allerdings wäre es für die Erteilung der Einwilligung in die Nutzung der ePA nützlich, eine einzelne SMC-Bs zu führen (bspw. in kleineren Krankenhäusern). Zugriffsbeschränkungen auf die ePA können innerhalb eines Krankenhauses auch komplett vom Krankenhausinformationssystem (KIS) umgesetzt werden. Angenommen aber, jemand (z. B. eine Datenschutz-Aufsichtsbehörde) fordert für die ePA eine Verschlüsselung auf Fachabteilungsebene, so ist dies ohne Weiteres realisierbar.

Antwort:
Falls beispielsweise aufgrund länderspezifischer datenschutzrechtlicher Vorgaben eine ePA-Verschlüsselung auf Fachabteilungsebene technisch über den Einsatz von SMC-Bs sichergestellt werden soll, muss jede Fachabteilung eines Krankenhauses eine eigene SMC-B mit einer für die Fachabteilung spezifischen Telematik-ID einsetzen. Die Telematik-ID darf in diesem Fall nicht der Telematik-ID des übrigen Krankenhauses entsprechen. Zusätzlich muss über das Informationsmodell des Konnektors im Krankenhaus sichergestellt werden, dass nur aus der Fachabteilung heraus auf diese SMC-B zugegriffen werden kann, da bei Verwendung mehrerer SMC-Bs die Zugriffsrechte zur Nutzung einer einzelnen SMC-B definiert bzw. beschränkt werden muss.
Die Einschränkung von Benutzergruppen bei der Nutzung der SMC-B ist eine Aufgabe des KIS, auf das generell die Verantwortlichkeit für die datenschutzrechtlichen Zugriffsbeschränkungen übertragen wird.
Die Anschaffung einzelner SMC-Bs pro Fachabteilung ist sinnvoll, wenn der Zugriff auf die SMC-B der Fachabteilung entsprechend eingeschränkt werden kann. Dafür sind eine geeignete Arbeitsplatzkonfiguration in Verbindung mit einem geeigneten Konnektorinformationsmodell erforderlich, sowie eine sichere Verwahrung der SMC-B und ihrer PIN. Außerdem muss organisatorisch dafür gesorgt werden, dass bei Vergabe der Berechtigung („Ad-hoc-Autorisierung“) im Krankenhaus zuverlässig ermittelt werden kann, auf welcher Station der Versicherte, der die Autorisierung ausspricht, behandelt wird.

Frage und Hintergrund der Frage:
Bei vielen Krankenhäusern erfolgt die Patientenaufnahme zentral. So werden an einem Arbeitsplatz Patienten für unterschiedliche Organisationseinheiten des Krankenhauses (mit potentiell unterschiedlichen TI-Mandanten) aufgenommen.
Wie kann das Krankenhaus diese gängige Praxis unter dem Aspekt der Zugriffserteilung auf die elektronische Patientenakte (ePA) des Patienten beibehalten, und gleichzeitig die zentralen Aufnahme-Arbeitsplätze TI-Mandanten zuordnen, wie es für eine gut konfigurierte Mandantenverwaltung erforderlich wäre?

Antwort:
Im Falle einer zentralen Aufnahme bestehen mehrere Möglichkeiten:

  1. Den Zugriff auf die ePA erteilt der Patient dem Aufnahme-Mandanten (bzw. der zentralen Aufnahme) des Krankenhauses (bei kleineren Krankenhäusern ggf. auch dem gesamten Krankenhaus). Der Aufnahme-Mandant liest ggf. herunterzuladende Daten aus der ePA aus und leitet sie innerhalb des Krankenhausinformationssystems (KIS) an die den Patienten behandelnden Stationen weiter bzw. macht sie verfügbar. Bei der Entlassung wiederum stellt der Aufnahme-Mandant den Entlassbrief und ggf. weitere Dokumente in die ePA des Patienten ein.
  2. Sobald entschieden ist, auf welche Station der Patient verlegt wird, erteilt der Patient den Zugriff für den entsprechenden „neuen“ Mandanten (also Fachabteilung eines Krankenhauses mit separater SMC-B und Telematik-ID).
  3. Der Aufnahme-Mandant umfasst bereits weitere Stationen, auf die typischerweise Patienten verlegt werden.

Bei geplanten Eingriffen ist  der zentralen Aufnahme die behandelnde Station in der Regel bekannt. Darum kann die Einrichtung eines „ePA-Aufnahme-Arbeitsplatzes“ sinnvoll sein, der auf mehrere weitere Mandanten zugreifen kann. Dann wird derjenige Mandant ausgewählt, der zu der behandelnden Station gehört, und die Berechtigung ausgestellt. Bei der Entlassung stellt auch der Stations-Mandant den Entlassbrief o.Ä in die elektronische Patientenakte ein.

Qualifizierte elektronische Signatur und elektronischer Heilberufsausweis

Derzeit kommt die qualifizierte elektronische Signatur (QES) bei den Anwendungen

zum Einsatz.

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

 

KIM - Kommunikation im Medizinwesen

Sie können in KIM bis zu 100 E-Mail-Adressen je SMC-B hinterlegen.

Mit folgenden Konfigurationen können Sie den Administrationsaufwand für den Konnektor bei der Einrichtung von KIM-Arbeitsplätzen reduzieren:

  • Das Primärsystem (PS) verfügt über einen Arbeitsplatz-Verwaltungsmechanismus, mit dem verschiedene reale Arbeitsplätze auf einen virtuellen Arbeitsplatz gemappt werden können (via statischem KIM-Aufrufkontext: Mandant#Clientsystem#Arbeitsplatz).
  • Dieser virtuelle Arbeitsplatz wird der Telematikinfrastruktur bekannt gemacht.
  • Der Arbeitsplatz-Verwaltungsmechanismus mappt alle Interaktionen von realen Arbeitsplätzen in Richtung der Telematikinfrastruktur auf den statischen KIM-Aufrufkontext und ordnet die Antworten aus der Telematikinfrastruktur an den virtuellen Arbeitsplatz wieder den realen Arbeitsplätzen zu. Die gematik sieht in dieser Lösung kein Sicherheitsrisiko.
  • Für Krankenhäuser und medizinische Einrichtungen vergleichbarer Größenordnung ist es zudem vorteilhaft, wenn der Arbeitsplatz-Verwaltungsmechanismus mehrere Konnektoren (bzw. im Fall von KIM mehrere KIM-Clientmodule) zwecks Erhöhung der Performance bzw. Verfügbarkeit parallel verwalten kann.

eHealth-Kartenterminal

Die Befristung von dezentralen  TI-Komponenten (Kartenterminals, Konnektoren) ist notwendig, da diese TI-Komponenten im Zuge von Releases stetig weiterentwickelt werden. Die Festelegungen in diesen Releases dienen der Erweiterung der Funktionalität eines Produktes sowie der Gewährleistung von Sicherheit, Interoperabilität und Funktionalität. Es muss daher die Möglichkeit bestehen, ältere Produktversionen verbindlich von der TI auszuschließen. Eine Verlängerung der Zulassungsfrist bleibt ausdrücklich vorbehalten.

Falls eine Zulassung ausläuft, ist das betroffene Gerät weiterhin funktionell betreibbar. Allerdings darf der Hersteller dieses Gerät (diese Geräteversion) nicht weiter in den Verkehr bringen, ohne von der gematik die entsprechende Bestätigung (Zulassung) dafür zu erhalten.

In der Regel bietet der Konnektorhersteller vorher ein Firmware-Update an, wobei durch Installation dieser neuen Version der Konnektor in einer zugelassenen Produktversion weiter betrieben werden darf (z.B. Wechsel von PTV3- auf PTV4-Konnektorversion).

SMC-B

Für das Lesen des Notfalldatensatzes (NFD) auf der elektronischen Gesundheitskarte oder in der elektronischen Patientenakte wird generell eine SMC-B benötigt. Da der Notfalldatensatz eines Patienten ggf. krankenhausweit gelesen werden soll, muss diese SMC-B jedoch nicht zwangsläufig in der Notfallambulanz gesteckt bzw. keine „Notfallambulanz-eigene“ SMC-B sein.

Außerdem handelt es sich hierbei in erster Linie eine rechtliche bzw. datenschutzrechtliche Frage (sowie ggf. auch eine abrechnungsrelevante Frage) und erst in zweiter Linie eine technische Frage.

Die DKG empfiehlt eine zwingende Trennung von SMC-Bs nach Rechtseinheiten und verweist auf länderspezifischer Datenschutzanforderungen. Die hier angesprochene Trennung kann nur durch eine SMC-B erreicht werden, die eine separate Telematik-ID aufweist. Es reicht also für eine Trennung von Rechtseinheiten nicht aus, eine weitere SMC-B zu einer bestehenden Telematik-ID zu bestellen. Es muss eine SMC-B mit eigener Telematik-ID sein. Falls die Notfallambulanz Ihres Krankenhauses keine eigenständige Rechtseinheit darstellt, prüfen Sie bitte, ob (länderspezifische) datenschutzrechtliche Anforderungen vorliegen, die eine Trennung der SMC-Bs erforderlich machen. Länderspezifische Anforderungen sehen beispielsweise vor, dass für jede Fachabteilung eine separate SMC-B vorgehalten werden muss, wenn diese für verschlüsselte KIM-Nachrichten erreichbar sein muss. Im Zweifel fragen Sie bitte den Datenschutzbeauftragten in Ihrem Hause.

Auch sollte in einem Krankenhaus nur das Personal Zugriff auf Patientendaten erhalten, das sie tatsächlich f benötigt. Der Zugriff wird dabei i.d.R. über das Krankenhausinformationssystem gesteuert.

Während das Einlesen der eGK in der Notfallambulanz nicht zwingend vorgeschrieben ist und damit auch der VSDM-Online-Abgleich nicht unbedingt erforderlich ist (bzw. die Bestätigung des Versicherungsnachweises auch mittels der SMC-B des Krankenhauses erfolgen kann), ist zu klären, mit welcher SMC-B beispielsweise ein Notfalldatensatz (NFD) oder ein elektronischen Medikationsplan (eMP) auf der eGK eines Patienten angelegt bzw. aktualisiert werden soll sowie eine ggf. vom Patienten eingeforderte Übertragung des eMP auf seine elektronische Patientenakte (ePA) oder ggf. die Ausstellung eines Arzneimittels per elektronischer Verordnung (E-Rezept) erfolgen soll. Bei einem Patienten, der ausschließlich in der Notfallambulanz medizinisch betreut wird, ist es ggf. nicht erforderlich, dass auch weiteres Klinikpersonal Zugriff auf seine Patientendaten (NFD, eMP, ePA, E-Rezept) erhält. Wie werden diese Zugriffe über die von Ihnen eingesetzten KIS-Systeme gesteuert?

Nun zum technischen Teil:

Der Zugriff auf die jeweils zutreffende SMC-B erfolgt mittels Konnektor-Informationsmodell. Dieses ist von entsprechenden Fachleuten Ihrer IT (bzw. Ihres IT-Dienstleisters) einzurichten. Hinweise zur Einrichtung, Konfiguration und Inbetriebnahme entnehmen Sie bitte den Unterlagen des Herstellers.

Hinweis:
Bei secunet-Konnektoren ist eine Installation mittels des Konnektor-Management-Systems (KMS) zu empfehlen. Dies ermöglicht nicht nur eine sicherere Inbetriebnahme, sondern auch einen wesentlich komfortableren Betrieb nebst Wartung und Pflege.

Der Konnektor bietet in seinem Informationsmodell die Möglichkeit an, für jeden Arbeitsplatz ein Remote-Kartenterminal zu definieren. Dabei fordert die am Remote-Kartenterminal arbeitende Person über das Krankenhausinformationssystem (KIS) die Möglichkeit einer PIN-Eingabe (SMC-B/HBA) an. Das KIS überträgt die entsprechende Meldung an den Konnektor. Gleichzeitig unterbindet es für weitere Remote-Kartenterminals einen eventuellen zusätzlichen PIN-Eingabewunsch. Die am Remote-Kartenterminal arbeitende Person muss hierfür die entsprechende PIN kennen.

Die Funktion einer Remote-PIN-Eingabe ist auch nach einem Konnektor-Restart oder bei einer Neu-Verifizierung einer SMC-B nach Verbindungsverlust eines Kartenterminals zum Konnektor nutzbar. Allerdings muss in diesen Fällen das KIS eine Remote-PIN-Eingabe für Endanwender unterstützen. Dies ist nicht bei allen KIS gegeben. In der Regel erfolgt bei diesen KIS die PIN-Eingabe durch die Administratoren des KIS.

 

Telematik-ID und Mandanten

Da eine SMC-B-Session durch Card Handle und Mandant-ID eindeutig bestimmt wird, können durch die im Kontext übergebene Mandant-ID zunächst die potentiell zur Verfügung stehenden SMC-Bs ermittelt werden. Der Konnektor wählt eine SMC-B aus, die dann die PIN-Eingabe erfordert.
Die Telematik-ID wird dann aus dem Zertifikat C.HCI.AUT oder C.HCI.OSIG der ausgewählten SMC-B ermittelt und zur Authentisierung im weiteren Verlauf verwendet.

Eine Eins-zu-Eins-Zuordnung zwischen einem TI-Mandanten und einer Telematik-ID (TI-ID) wird von der gematik nicht generell „vorgeschrieben“, um unterschiedliche Mandantenkonzepte nicht technisch einzuschränken.

Die Eins-zu-Eins-Zuordnung führt jedoch zu einer einfachen und stringenten Lösung der datenschutzrechtlich erforderlichen Zugriffsbeschränkung. Für eine Eins-zu-Eins-Zuordnung beantragen Sie dieselbe Anzahl von SMC-Bs und unterschiedlichen Telematik-IDs. Grundlage für die Anzahl sollte ein zuvor von der IT erstelltes Bedarfskonzept sein. Anschließend ordnen Sie die TI-ID den Mandanten zu.

Für die Anwendung elektronische Patientenakte (ePA) ist die Eins-zu-Eins-Beziehung zwischen Mandant-ID und Telematik-ID fachlich unabdingbar. Das Krankenhausinformationssystem (KIS) kann dies verifizieren, indem es

  • potentiell mehrere SMC-B-Card-Handles der für die ePA verwendeten Mandanten ermittelt,
  • pro Card-Handle per ReadCardCertificate aus der SMC-B das C.HCI.Aut – Zertifikat ausliest, die Telematik-ID extrahiert und
  • eine Fehlermeldung anzeigt, falls die ermittelten Telematik-IDs pro Mandant-ID nicht identisch sind.

Belegärzte in Krankenhäusern

Frage und Hintergrund der Frage:
Belegärzte behandeln/operieren ihre Patienten eigenverantwortlich und nutzen zu diesem Zweck unter Umständen Ressourcen eines Krankenhauses (Räume, Technik, Personal, Material usw.).
Die Patienten werden hierfür per Krankenhausinformationssystem (KIS) erfasst. In der Regel werden aber nur wenige Dokumente, bspw. der OP-Bericht, direkt im Krankenhaus erstellt.
Verwenden Belegärzte bei Dienstbeginn eine eigene SMC-B analog der im Krankenhaus angestellten Ärzte? Und wenn ja, ist die SMC-B dann der Praxis des jeweiligen Arztes zugeordnet oder braucht ein Belegarzt eine zweite SMC-B für seine Belegarzttätigkeit?
 

Antwort:
Belegärzte müssen eine eigene Institutionskarte (SMC-B) verwenden, um TI-Anwendungen nutzen und Leistungen ggü. den (gesetzlichen/privaten) Krankenversicherungen abrechen zu können. Im Krankenhaus muss diese dem KIS bzw. der Konnektorkonfiguration bekanntgemacht werden, sofern Belegärzte das Krankenhausinformationssystem für TI-Anwendungen nutzen. Die SMC-B muss entsprechend freigeschaltet werden.

Ob ein Belegarzt für seine Tätigkeit im Krankenhaus neben der SMC-B seiner Praxis eine zweite SMC-B benötigt, hängt davon ab, ob beispielsweise parallel in seiner Praxis gearbeitet wird, während er im Krankenhaus tätig ist.

Der Belegarzt kann seine Verantwortungsbereiche (Krankenhaus und Praxis) technisch auch über Institutionskarten mit unterschiedlichen Telematik-IDs trennen. Dies sollte er vorab mit den abrechnungsrelevanten Setllen (bspw. der Kassenärztlichen Vereinigung) klären. Diese Einstellung ermöglicht es außerdem, dass der Belegarzt mit einer Karte beispielsweise E-Mails über die Fachanwendung KIM (Kommunikation im Medizinwesen) sowohl aus der Belegsituation im Krankenhaus als auch aus der Praxis verschicken kann.