04.10.2024 - behoben - Einschränkung Kommunikation im Medizinwesen (KIM) - BITMARCK Service GmbH:
Mehr erfahren

02.10.2024 - Wartungsarbeiten am E-Rezept Fachdienst: In der Zeit vom 05.10.2024 23:30 Uhr bis 06.10.20 00:30 Uhr finden Wartungsarbeiten am E-Rezept-Fachdienst statt...
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

Die technische Nutzbarkeit von Konnektoren wird durch die Laufzeit der im Konnektor verbauten Sicherheitszertifikate begrenzt. Seit den Zulassungen für die Produkttypversion 3 (ca. 2019/2020) haben die Konnektorhersteller die Auflage, Maßnahmen zu ergreifen, damit nur Geräte in der Verkehr gebracht werden, die noch mindestens 4 Jahre nutzbar sind. 

Da der Konnektor bei einem Lieferanten erworben wird und nicht beim Hersteller selbst, hängen die Ansprüche des Käufers wegen einer kürzeren Restlaufzeit bei Erwerb von der Vertragsgestaltung mit dem jeweiligen Lieferanten ab.

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. 

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.

Konnektor, Highspeed-Konnektor

Eine Entscheidungshilfe befindet sich im Dokument „Anbindung von Krankenhäusern“ in Kapitel 3.4.3.

  • Sollte sich aus dem derzeit begrenzten Angebot an Highspeed-Konnektoren kein überzeugendes Angebot ergeben, erscheint eine Verlängerung der bestehenden SMC-K sinnvoll, um Entscheidungszeit zu gewinnen. Eine Verlängerung der bestehenden RSA-basierten SMC-K ist bis Ende 2025 per SW-Update möglich (Hersteller anfragen). 
  • Eine Entscheidung, ob die Konnektorlösung in den KH ab Anfang 2026 aus einem HSK/Ti-Gateway oder aus vielen einzelnen ECC-basierten Konnektoren bestehen könnte, sollte aufgrund des möglicherweise hohen Rollout-Aufwands in den KH 6-9 Monate vor Ende 2025 getroffen werden. Hierbei ist auch zu beachten, dass durch die deutlich gesteigerte Leistungsfähigkeit des HSK eine Umkonfiguration des bestehenden Mandantenmodells hin zu einer übersichtlicheren Konfiguration möglich und geboten ist, da dies zu einem insgesamt geringeren Betriebsaufwand hinsichtlich organisatorischer Änderungen und Skalierungen führt.
  • Die derzeitigen Planungen der gematik sehen eine Einführung des HSK in den Produktivbetrieb ab September 24 vor; eine Verfügbarkeit des HSM-B ist für 2025 geplant.
  • Verfügt ein KH heute bereits über ECC-basierte Konnektoren kann deren Laufzeit um 3 Jahre verlängert werden.
  • Für die Anbindung der Krankenhäuser an das Ti-Gateway (als Zugangspunkt zum HSK, mit gleicher Schnittstelle zum PS wie bisher der Konnektor) werden in den laufenden Friendly-User-Tests Erfahrungen gesammelt. Hier empfiehlt sich ein direkter Austausch mit dem Hersteller und ein Erfahrungsaustausch mit den Pilotanwendern.

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.

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. 

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 und schreibenden Zugriff auf ePANFDM 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.

Das Thema Schadsoftware/Viren hat eine hohe Aktualität und erfordert eine ständige Überprüfung der getroffenen Maßnahmen. Dies kann von der gematik nicht geleistet werden. Für diese Aufgabe, die in nahezu allen IT-Bereichen, also auch außerhalb des Gesundheitswesens, relevant ist, gibt es Unternehmen, die sich entsprechend spezialisiert haben.

Eine zentrale Prüfung auf Schadsoftware/Viren wird von der gematik nicht durchgeführt. Eine Integration von Schadsoftware-/Virenprüfmechanismen in die Aktensysteme würde ein zu hohes Risiko hinsichtlich der Abgeschlossenheit der vertrauenswürdigen Anwendungsumgebung, VAU, mit sich bringen.

Qualifizierte elektronische Signatur und elektronischer Heilberufsausweis

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

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.

 

KIM – Kommunikation im Medizinwesen

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.

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

Die gematik gibt keine Entsorgungsempfehlung. Diese ist beim Hersteller der KT zu erfragen. Die in den KTs enthaltenen SMC-KTs können jedoch weiterverwendet werden. Bitte beachten Sie auch die notwendigen Konfigurationen im Konnektor beim Austausch eines KTs.

SMC-B

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

Grundsätzlich würde eine Beschränkung der Nutzung von SMC-Bs auch eine Beschränkung der möglichen E-Mail-Empfänger bedeuten, was bei E-Mail-Systemen nicht der Fall ist.
Die gematik hält eine Richtgrenze von 50 Schlüsseln (ein Schlüssel entspricht einem Zertifikat auf der SMC-B) beim Senden/Empfangen von KIM-Nachrichten für akzeptabel. Das wären:

  • 25 SMC-Ben der Generation 2.1, bei denen jeweils 2 Schlüssel pro Karte, RSA und ECC, vorhanden sind, und
  • 50 SMC-Ben bei Generation < 2.1.

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

Es gibt  aktuell auch Krankenhäuser, die bis zu 100 SMC-B im Einsatz haben und kein Performanceproblem melden.

Wenn jedoch eine zu hohe Systembelastung festgestellt wird, könnte man:

  • die Karten auf mehrere Telematik-IDs verteilen, was sich in der Konfiguration als umständlich/komplex auswirken kann, oder
  • separate Konnektoren nur für die 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 welcher seiner SMC-B er die Nachricht entschlüsseln möchte. Da der Absender dies vorher nicht weiß, wird eine Nachricht für alle möglichen Empfängerschlüssel verschlüsselt.
  • Der Absender verschlüsselt eine zu versendende Nachricht auch für seine eigenen Schlüssel, da es möglich ist, dass seine Nachricht zurückgewiesen wird und er sie erneut entschlüsseln muss. Auch hier ist vorher nicht bekannt, welcher seiner Schlüssel dafür verwendet wird.

Ein Performance-Engpass könnte somit in der Kommunikation mit/zwischen Einrichtungen mit vielen Schlüsseln → z.B. Krankenhäusern → auftreten.

  • Versenden Krankenhäuser mit vielen Schlüsseln, kann es aufgrund der Absenderverschlüsselung zu Performance-Problemen kommen.
  • Empfangen Krankenhäuser, kann ein Performance-Problem beim Absender, z.B. einer Praxis auftreten.

In der Regel wird der Versand bzw. Empfang von E-Mails nicht als zeitkritisch erachtet. Die Dauer des Transports einer Nachricht durch das eigene System ist in der Regel unerheblich, da die Differenz von fünf Sekunden zu einer Minute in der Praxis keine Rolle spielt. Die gematik hat unter Laborbedingungen mehrfach erfolgreich Nachrichten an sechs Empfänger mit jeweils 50 Zertifikaten versendet. Die genaue Vorgehensweise eines KIM-CM-Herstellers bei der Handhabung zahlreicher Zertifikate ist durch die Vorgaben der gematik nicht spezifiziert.

Die Konnektoren wurden in der Vergangenheit von Ihnen mit Hilfe der SMC-B bei Ihrem VPN-Zug-Dienstleister registriert. Dazu wurden die Identitäten der Konnektoren und der SMC-B beim VPN-ZugD hinterlegt. Wenn eines der hinterlegten Zertifikate (SMC-B, SMC-K) seine zeitliche Gültigkeit verliert, funktioniert im Fall:

  • einer ablaufenden SMC-K der Verbindungsaufbau für den betreffenden Konnektor nicht mehr und
  • einer ablaufenden SMC-B der Verbindungsaufbau für alle Konnektoren, die mit dieser SMC-B registriert wurden, nicht mehr.
  1. Wenn Sie rechtzeitig eine neue SMC-B bestellen und einsetzen, funktioniert diese zwar im herkömmlichen Betrieb, der VPN-Zugang ist aber nur so lange möglich, wie die alte, im VPN-Zug-D hinterlegte SMC-B noch gültig ist.
  2. In jedem Fall muss mit der neu beschafften SMC-B eine Neuregistrierung beim VPN-Zug-D erfolgen.

Die neue und die alte (zu ersetzende) SMC-B müssen so lange gleichzeitig gesteckt bleiben, bis Sie sicher sind, dass Sie alle E-Mails, die Sie vor dem Einstecken der neuen SMC-B erhalten haben, vom Mailserver abgeholt und entschlüsselt haben. Danach kann die alte SMC-B entfernt werden.

Annahme: Die neue SMC-B hat die gleiche Telematik-ID wie die alte.

Besondere Vorkehrungen beschränken sich in diesem Fall auf den VPN-Kanal, siehe hierzu FAQ "Was ist beim SMC-B-Wechsel in Bezug auf den Vpn-ZugD zu beachten?" und den KIM-Nachrichten-Empfang, siehe hierzu FAQ "Was muss beim Austausch von abgelaufenen SMC-Ben hinsichtlich KIM beachtet werden?"

Ein Einfluss auf andere Anwendungen der TI ist uns derzeit nicht bekannt.

Telematik-ID und Mandanten

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.

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.