Themenübergreifende FAQ-Seite

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.

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. 

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.

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.

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.

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?

Antwort
Die gematik empfiehlt, die ePA-Zugriffsberechtigung im Kontext eines zentralen Aufnahmemandanten zu erteilen und abteilungsbezogene Downloads über das Krankenhausinformationssystem (KIS) durchzuführen. Die abteilungsbezogene Berechtigung zum Lesen und Schreiben der elektronischen Patientenakte (ePA) wird in diesem Fall über das KIS gesteuert und durchgesetzt. 

Bei der Entlassung wiederum stellt der Aufnahme-Mandant den Entlassbrief und ggf. weitere Dokumente in die ePA des Versicherten ein.

Alternativ können Sie abteilungsbezogene ePA-Berechtigungen mit Hilfe abteilungseigener SMC-Bs durchsetzen. Dann muss der Versicherte für jede Abteilung eine Berechtigung erteilen. Für diese Variante werden zwei Kartenterminals benötigt. In einem Kartenterminal steckt jeweils die für die Abteilung konfigurierte SMC-B; in das andere Kartenterminal steckt der Versicherte im Rahmen der Berechtigungserteilung seine elektronische Gesundheitskarte.

Anmerkung:
Verfügt ein Versicherter über ein Frontend des Versicherten (bspw. auf dem Smartphone), ist eine SMC-B-basierte Berechtigungserteilung für weitere Abteilungen einfacher zu handhaben, da dies durch entsprechende Klicks im Smartphone schnell eingestellt werden kann. In diesem Fall wird kein Kartenterminal gebraucht.

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

Antwort:
Die gematik empfiehlt dringend eine Eins-zu-Eins-Zuordnung zwischen einem TI-Mandanten und einer Telematik-ID (TI-ID). 
Beachten Sie auch die Frage "Stichwort "Zuordnung TI-ID und SMC-B": Welche Festlegungen sind zu beachten?".

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:
Die Zuordnung „SMC-B – Arbeitsplatz“ bedeutet, dass Sie im Informationsmodell des Konnektors einen Mandanten anlegen. Die gematik empfiehlt dringen, dass Sie einem Mandanten genau eine SMC-B sowie Arbeitsplätze und Kartenterminals zuordnen. 

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 und schreibenden Zugriff auf ePA, NFDM und eMP/AMTS ist kein elektronischer Heilberufsausweis (HBA) erforderlich; Beides kann mittels einer SMC-B erfolgen. 

Allerdings erfordert  der Notfalldatensatz (NFD) eine qualifizierte elektronische Signatur (QES). Hierfür wird ein HBA benötigt. Der NFD wird zunächst per QES signiert. Für das Schreiben des QES-signierten NFD auf die eGK des Patienten ist dann wiederum lediglich eine SMC-B erforderlich. Das Schreiben des aktualisierten NFD auf die eGK des Versicherten kann zeitlich und räumlich getrennt zur QES des NFD erfolgen.

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

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:

Ja, in diesem Fall wird eine SMC-B für jede Fachabteilung benötigt.

Anmerkung:
Generell ist für die Nutzung der elektronischen Patientenakte (ePA) eine Freigabe auf Fachabteilungsebene nicht zwingend. Zugriffsbeschränkungen auf die ePA können innerhalb eines Krankenhauses auch komplett vom Krankenhausinformationssystem (KIS) umgesetzt werden.

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?

Antwort:
Die gematik empfiehlt, die ePA-Zugriffsberechtigung mithilfe eines zentralen Aufnahmemandanten zu erteilen und abteilungsbezogene Downloads über das Krankenhausinformationssystem (KIS) durchzuführen. Die abteilungsbezogene Berechtigung zum Lesen und Schreiben der elektronischen Patientenakte (ePA) wird in diesem Fall über das KIS gesteuert und durchgesetzt. 

Bei der Entlassung wiederum stellt der Aufnahmemandant den Entlassbrief und ggf. weitere Dokumente in die ePA des Versicherten ein.

Sobald abteilungsbezogene ePA-Berechtigungen allerdings mit Hilfe abteilungseigener SMC-Bs durchgesetzt werden, muss der Versicherte für jede Abteilung eine Berechtigung erteilen. Wenn der Versicherte die Berechtigungen via elektronischer Gesundheitskarte erteilt, benötigen Sie für jede Abteilung ein Kartenterminal für die Berechtigungsfreigabe.

Anmerkung:
Verfügt ein Versicherter über ein Frontend des Versicherten (bspw. auf dem Smartphone), ist eine SMC-B-basierte Berechtigungserteilung für weitere Abteilungen einfacher zu handhaben, da dies durch entsprechende Klicks im Smartphone schnell eingestellt werden kann. In diesem Fall benötigen Sie Kartenterminal.

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

• Notfalldaten-Management (NFDM; hier: Anlegen oder Aktualisieren eines Notfalldatensatzes),
•  E-Rezept  sowie
• beim Erstellen einer elektronischen Arbeitsunfähigkeitsbescheinigung (eAU) per KIM (Kommunikation im Medizinwesen) zum Einsatz.

Die qualifizierte elektronische Signatur von elektronischen Arztbriefen ist per Gesetzt zwar nicht vorgeschrieben. Sie ist jedoch für eine Kostenerstattung nach § 383 SGB V in der vertragsärztlichen Versorgung für die Übermittlung eines elektronischen Arztbriefes via KIM erforderlich.

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.

Sie können in KIM bis zu 1000 E-Mail-Adressen je SMC-B hinterlegen. Dabei weist jede SMC-B einen sog. Basiseintrag im Verzeichnisdienst (Telematik-ID) auf, der das Hinterlegen von E-Mail-Adressen ermöglicht.

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.

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).

Bitte achten Sie bei der Verwendung von SMC-B unterschiedlicher Generationen (G2.0 und G2.1) darauf, welche Konfigurationseinstellungen im Konnektor zu 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 Kryptifizierungsverfahren (entweder RSA oder ECC) verwenden.

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.

Problem:

Verfügt ein Krankenhaus über mehrere SMC-Bs mit unterschiedlicher Telematik-ID (zum Beispiel eine SMC-B für das Stammhaus, eine weitere für die Kinderchirugie), so wird für jede Telematik-ID ein eigener Basiseintrag im zentralen Verzeichnisdienst der Telematikinfrastruktur (VZD) erstellt. Die Stammdaten dieser Einträge (Krankenhausname, Adresse, Fachrichtung) sind dabei zunächst vollkommen identisch. Die Einträge unterscheiden sich zwar anhand des Schlüsselmaterials und der Telematik-ID – für Benutzer sind diese Unterscheidungsmerkmale aber nicht "lesbar". Ein Versicherter beispielsweise, der zur Erteilung einer Zugriffsberechtigung auf seine elektronische Patientenakte (ePA) in seiner ePA-App mehrere gleichlautende Einträge zu einem Krankenhaus findet, kann keine gezielte Zugriffserteilung vornehmen; er kann lediglich alle Einträge zum Zugriff berechtigen, um auch die „richtige" Institution zu "erwischen".

Lösung:

Die Lösung besteht darin, den Krankenhäusern die Möglichkeit zu geben, ihre VZD-Einträge unterscheidbar zu machen. Hierzu kann es auf der Internetseite der DKTIG einen Änderungsantrag stellen. Mit diesem Formular kann das Krankenhaus die Änderung bestimmter Felder seiner VZD-Einträge beantragen.

In einer Musterdatei wurden einige Beispiele aufgeführt, wie mittels des vorgenannten Änderungsantrags die VZD-Einträge eines Krankenhauses voneinander unterscheidbar gemacht werden können. Diese Musterdatei finden Sie unter folgendem Link: VZD-Krankenhaus-Beispiel.
Des Weiteren werden in der Datei einige Beispiele zur Vergabe von entsprechenden Namen von KIM-Postfächern (KIM – Kommunikation im Medizinwesen) aufgeführt. 

Bitte beachten Sie zum korrekten Ausfüllen des Antragformulars auch die Hinweise der DKTIG (Link siehe oben)!

Die gematik empfiehlt dringend eine Eins-zu-Eins-Zuordnung zwischen einem TI-Mandanten und einer Telematik-ID (TI-ID). 
Beachten Sie in diesem Zusammenhang auch die nachfolgende Frage zur Zuordnung von TI-IDs zu SMC-Bs.

Die gematik empfiehlt dringend eine Eins-zu-Eins-Zuordnung zwischen einem TI-Mandanten und einer Telematik-ID (TI-ID). 
Zwar können mehrere unterschiedliche TI-IDs einem Mandanten zugeordnet werden – das Informationsmodell des Konnektors lässt dies zu – eine Auswahl der zu nutzenden TI-IDs muss in diesem Fall jedoch per Aufrufkontext durch das Primärsystem erfolgen.

Bei einem impliziten Aufrufkontext, d.h., ohne dass die zu nutzende SMC-B festgelegt wurde (CardHandle), verhält sich der Konnektor allerdings „unspezifiziert“. Solche impliziten Aufrufe werden teilweise durch unsere- Anwendungen, z.B. KIM, genutzt.

Eine Zuordnung mehrerer SMC-Bs mit jeweils gleicher TI-ID zu einem Mandanten wird von der gematik nicht empfohlen, da die Kriterien für die SMC-B-Auswahl bei impliziten Aufrufen nicht spezifiziert sind.

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.