latest
Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation Konnektor
Logdaten-Sendemodul
Version | 1.0.0 |
Revision | 548770 |
Stand | 15.05.2019 |
Status | Freigegeben für interne QS |
Klassifizierung | öffentlich |
Referenzierung | gemSpec_Kon_LDSM |
Dokumentinformationen
Änderungen zur Vorversion
Es handelt sich um die Erstversion des Dokumentes.
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
---|---|---|---|---|
1.0.0 |
15.05.2019 |
freigegeben |
gematik |
Inhaltsverzeichnis
1 Einordnung des Dokumentes
1.1 Zielsetzung
Dieses Dokument enthält die Anforderungen an den Konnektor, um nach Einwilligung durch den bzw. die Leistungserbringer Logdaten an die Schnittstelle I_LogData zu senden.
1.2 Zielgruppe
Das Dokument richtet sich an Konnektorhersteller sowie Hersteller und Anbieter von Produkttypen und anderen Systemen, die die Logdaten an der Schnittstelle I_LogData entgegen nehmen.
1.3 Geltungsbereich
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens.
Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
Schutzrechts-/Patentrechtshinweis
Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.
1.4 Arbeitsgrundlagen
Grundlagen für die Ausführung in diesem Dokument sind insbesondere:
- Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP]
- Konnektor-Spezifikation [gemSpec_Kon]
1.5 Abgrenzung des Dokuments
Spezifiziert werden in diesem Dokument die Anforderungen und das Verhalten des Konnektors, um Logdaten an die Schnittstelle I_LogData zu senden. Die Schnittstelle selbst wird in [gemSpec_SST_LD_BD] beschrieben.
Für das Verständnis dieser Spezifikation wird die Kenntnis von [gemKPT_Arch_TIP] vorausgesetzt.
1.6 Methodik
1.6.1 Anforderungen
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.
Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]
Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.
1.6.2 Dokumentenstruktur
Anders als andere Plattformfunktionen des Konnektors werden die Funktionen zum Senden von Logdaten nicht in [gemSpec_Kon], sondern im vorliegenden Dokument beschrieben. Diese Untergliederung in mehrere Dokumente erlaubt eine stärkere Strukturierung der Inhalte und einfachere Handhabung der Dokumente.
1.6.3 Detaillierungstiefe
Diese Spezifikation beschreibt detailliert die Anforderungen und internen Funktionen, um Logdaten an die Schnittstelle I_LogData zu senden. Auf eine Beschreibung zusätzlicher interner sowie implementierungsabhängiger Details wird verzichtet.
2 Systemüberblick
In folgender Abbildung ist die Einbettung des Logdaten-Sendemoduls in den Konnektor und in die TI dargestellt.
Abbildung 1: Systemübersicht logischer Komponenten und Informationsflüsse (vereinfacht)
Nach Einwilligung durch den bzw. die Leistungserbringer sollen alle Logdaten des Konnektors periodisch und mit einigen Metadaten angereichert an I_LogData gesendet werden. Von dort werden sie weiter an ein Logdaten-Analysesystem gesendet.
Die Umsetzung der Logdatenverarbeitung in der gematik ist aktuell noch nicht festgelegt.
Vor dem Senden müssen Versicherteninformationen anonymisiert und Daten des Leistungserbringers pseudonymisiert werden.
3 Übergreifende Festlegungen
A_17097 - Nutzung der Schnittstelle I_LogData
Der Konnektor MUSS die Schnittstelle I_LogData benutzen, um die Meta- und Logdaten zu versenden.
[<=]
A_17273 - Prüfung des TLS-Server-Zertifikats durch den Konnektor
Der Konnektor MUSS bei der Absicherung der Verbindung durch TLS die serverseitige Authentisierung unter Nutzung des I_LogData X.509-Komponentenzertifikats mit der TLS-Server-Identität ID.ZD.TLS_S zur Serverauthentisierung umsetzen.
Die Prüfung erfolgt durch Aufruf von TUC_KON_037 „Zertifikat prüfen“ {
qualifiedCheck = not_required;
offlineAllowNoCheck = true;
policyList = oid_zd_tls_s;
intendedKeyUsage = digitalSignature;
intendedExtendedKeyUsage = id-kp-serverAuth;
validationMode = OCSP } .
[<=]
4 Funktionsmerkmale
4.1 Aktivierung des Logdaten-Sendemoduls
A_17095 - Aktivierung des Logdaten-Sendemoduls
Der Konnektor MUSS an der Admin-Schnittstelle die Möglichkeit bieten, das Logdaten-Senden zu aktivieren und zu deaktivieren. Im Auslieferungszustand MUSS das Senden deaktiviert sein.
[<=]
A_17096 - Generierung einer eindeutigen LEI-ID
Bei der Aktivierung des Logdaten-Sendemoduls MUSS der Konnektor eine weltweit eindeutige LEI-ID gemäß [RFC4122] in der Version 4 generieren, falls diese noch nicht generiert wurde.
[<=]
4.2 Einwilligungserklärung
Von der Schnittstelle I_LogData werden nur Daten von bekannten LEI entgegengenommen bzw. verarbeitet, für die eine Einwilligungserklärung vorliegt. Die Leistungserbringer müssen die Einwilligungserklärung unterschreiben und an die gematik senden.
A_17098 - Einwilligungserklärung anzeigen
Der Konnektor MUSS bei der Aktivierung des Logdaten-Sendemoduls die Schnittstelle I_LogData::getFile und die generierte LEI-ID benutzen, um die Datei "LDA_Einwilligungserklaerung.html" herunterzuladen (siehe [gemSpec_SST_LD_BD#A_17172]) und anzuzeigen.
[<=]
Zum Ausdrucken und Unterschreiben nutzt der Leistungserbringer seinen Webbrowser und Drucker. Der Webbrowser kann auch genutzt werden um eine Datei zu erzeugen, die dann digital signiert wird.
In der Einwilligungserklärung werden in einem html-Formular einige Metadaten abgefragt wie z.B.:
- Art der LEI (Arzt, Zahnarzt, Krankenhaus, Apotheke, Psychotherapeut , sonstiges)
- Primärsystem (Name)
- Art der Internetanbindung (DSL, Kabel, Mobilfunk,....) und Up-/Download-Geschwindigkeit
- Informationen zum lokalen Netzwerk (LAN, WLAN, Internetrouter)
- Region (PLZ oder KV-Bezirk)
Das html-Formular enthält einen Senden- u. Drucken-Button. Die Formulardaten werden in einem HTTP-POST-Request mit dem Content-Type: application/x-www-form-urlencoded sowohl zurück an I_LogData gesendet als auch ausgedruckt bzw. als Datei gespeichert.
A_17332 - Weiterleiten des POST-Requests an I_LogData
Der Konnektor MUSS den aus der Einwilligungserklärung erzeugten HTTP-POST-Request gemäß den Anforderungen von I_LogData::decIntent an I_LogData weiterleiten.
[<=]
4.3 Widerrufserklärung
A_17334 - Widerrufserklärung anzeigen
Der Konnektor MUSS bei der Deaktivierung des Logdaten-Sendemoduls die Schnittstelle I_LogData::getFile und die generierte LEI-ID benutzen, um die Datei "LDA_Widerrufserklaerung.html" herunterzuladen (siehe [gemSpec_SST_LD_BD#A_17203]) und anzuzeigen. [<=]
Das html-Formular enthält einen Senden- u. Drucken-Button. Die Formulardaten werden in einem HTTP-POST-Request mit dem Content-Type: application/x-www-form-urlencoded sowohl zurück an I_LogData gesendet als auch ausgedruckt bzw. als Datei gespeichert.
Die Leistungserbringer müssen das Dokument unterschreiben und an die gematik senden.
A_17335 - Weiterleiten des POST-Requests der Widerrufserklärung an I_LogData
Der Konnektor MUSS den aus der Widerrufserklärung erzeugten HTTP-POST-Request gemäß den Anforderungen von I_LogData::decIntent an I_LogData weiterleiten.
[<=]
4.4 Senden der Logdaten
A_17099 - Logdaten-Sendeintervall
Der Konnektor MUSS an der Admin-Schnittstelle die Möglichkeit bieten, das Sendeintervall zu konfigurieren. Dabei MÜSSEN:
- der Default-Wert: 24 Stunden
- der Minimal-Wert: 10 Minuten und
- der Maximal-Wert: 30 Tage
[<=]
A_17100 - Logdaten senden
Der Konnektor MUSS periodisch im konfigurierten Sendeintervall alle Protokolleinträge, die nach dem letzten Senden, jedoch nicht vor der Aktivierung datiert sind, senden. Dazu MUSS die Schnittstelle I_LogData::fileUpload und die LEI-ID als Nutzername benutzt werden.
[<=]
Für die Übertragung wird gemäß I_LogData HTTP compression benutzt, so dass die Daten nicht vorher explizit komprimiert werden müssen.
A_17101 - Logdaten von personenbezogenen und medizinischen Daten bereinigen
Vor dem Senden MUSS der Konnektor die Logdaten von personenbezogenen und personenbeziehbaren Daten bereinigen und diese durch XXX ersetzen. Bei einer ICCSN sind die Stellen 11–20 durch XXX zu ersetzen. Die Stellen 1-10 (unpersönlicher Anteil) MÜSSEN bestehen bleiben. [<=]
Laut [gemSpec_Kon#TIP1-A_4710] werden keine medizinischen und (außer bei Sicherheitsvorfällen) keine personenbezogenen Daten protokolliert.
A_17103 - Zu sendende Logdaten
Der Konnektor MUSS alle aktivierten Protokolle unter den in TAB_KON_LDSM_001 genannten Namen an die I_LogData Schnittstelle senden.
Tabelle 1: TAB_KON_LDSM_001 Log Daten
Protokoll |
zu senden mit dem Namen |
---|---|
Systemprotokoll |
sys_<timestamp>.log |
Performanceprotokoll |
perf_<timestamp>.log |
Sicherheitsprotokoll |
sec_<timestamp>.log |
Fachmodulprotokoll |
fm_<fmName>_<timestamp>.log |
Fachmodul-Performanceprotokoll |
fm_<fmName>_perf_<timestamp>.log |
- <fmName> - der Name des Fachmoduls. Das sind z.Z. AMTS, EPA, NFDM, VSDM
- <timestamp> - Der Zeitpunkt des Sendeversuchs in dem FormatYYMMDD_hhmmss mit
- YY - Jahr, 2 Ziffern, z.B. 19 für 2019
- MM - Monat des Jahres, 2 Ziffern, z.B. 01 für Januar
- DD - Tag des Monats, 2 Ziffern, z.B. 03 für den 3. des Monats
- hh - Stunde des Tages in 24 Stunden Notation, z.B. 16 für 16 Uhr
- mm - Minute der Stunde, 2 Ziffern, z.B. 05 für 5 Minuten nach der vollen Stunde
- ss - Sekunden, 2 Ziffern
[<=]
A_17106 - Logdaten-Senden Fehlerbehandlung
Konnten die Logdaten nicht gesendet werden, MUSS der Konnektor nach weiteren 5 min die Logdaten erneut senden.
[<=]
A_17745 - Fehlerbehandlung wenn erneutes Senden Misslingt
Konnten die Logdaten erneut nicht gesendet werden, MUSS der Konnektor beim nächsten Sendeintervall senden.
A_17116 - Status des Logdaten-Sendemoduls
Der Konnektor MUSS an der Managementoberfläche darstellen können:
wann Logdaten zuletzt gesendet wurden und ob dies erfolgreich oder nicht erfolgreich war
wann Logdaten das nächste Mal gesendet werden
A_17107 - kein Einfluss auf Löschen von Protokolleinträgen
Das Logdaten-Sendemodul DARF das Löschen von Protokolleinträgen NICHT verhindern.
[<=]
Insbesondere das Vorhalten von zu sendenden Daten in dem Fall, dass das Senden nicht funktionierte, darf das Bereinigen der Protokolle nicht verhindern. Es wird akzeptiert, dass die zu sendenden Daten dann ebenfalls gelöscht wurden. Die zu sendenden Daten sind nicht zwingend separat von den Protokolleinträgen vorzuhalten.
4.5 Metadaten
A_17117 - Senden von Metadaten
Bei jedem Senden MUSS der Konnektor Metadaten unter dem Namen meta_<timestamp>.xml senden. [<=]
A_17127 - Formatierung der Metadaten
Der Konnektor MUSS zu den Logdaten Metadaten als XML-Dokument gemäß dem Schema „conn/LDMetadata.xsd“ senden.
TAB_KON_LDSM_002 beschreibt die Elemente der zu verwendenden Schemastruktur.
Tabelle 2: TAB_KON_LDSM_002 Metadaten(LDmetadata.xsd)
Name |
Beschreibung |
LOGMD:LEIId |
Die generierte eindeutige LEI-ID. |
LOGMD:VPNZugD |
Die DNS-Domain des VPN-Zugangsdienstes. Der Wert von DNS_DOMAIN_VPN_ZUGD_INT ([gemSpec_VPN_ZugD]). |
PI:ProductInformation |
Produktinformationen des Konnektors gemäß [gemSpec_OM#2.3.3] und dem Schema „ProductInformation.xsd“. |
CT:CardTerminals |
Informationen über die angeschlossenen Kartenterminals wie in der GetCardTerminalsResponse der SOAP Operation GetCardTerminals. |
LOGMD:InfoModelCounter |
Anzahl der Entitäten im Informationsmodell des Konnektors. |
LOGMD:Mandants |
Anzahl der Mandanten |
LOGMD:ClientSystems |
Anzahl der Clientsysteme |
LOGMD:Workplaces |
Anzahl der Arbeitsplätze |
[<=]
5 Anhang A – Verzeichnisse
5.1 Abkürzungen
Kürzel |
Erläuterung |
---|---|
LEI |
Leistungserbringerinstitution |
LEI-ID |
LEI - Identifikation |
5.2 Glossar
Begriff |
Erläuterung |
---|---|
Funktionsmerkmal |
Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems. |
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
5.3 Abbildungsverzeichnis
5.4 Tabellenverzeichnis
5.5 Referenzierte Dokumente
5.5.1 Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Titel |
---|---|
[gemGlossar] |
Einführung der Gesundheitskarte - Glossar |
[gemSpec_SST_LD_BD] |
Spezifikation Schnittstelle Logdaten- und Betriebsdatenerfassung |
[gemKPT_Arch_TIP] |
Konzeption Architektur der TI-Plattform |
[gemSpec_Kon] |
Spezifikation Konnektor |
[gemSpec_VPN_ZugD] |
Spezifikation VPN-Zugangsdienst |
[gemSpec_OM] |
Übergreifende Spezifikation Operations und Maintenance |
5.5.2 Weitere Dokumente
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
---|---|
[RFC4122] |
IETF (Juli 2005): A Universally Unique IDentifier (UUID) https://tools.ietf.org/html/rfc4122 |
[RFC4398] |
Storing Certificates in the Domain Name System (DNS) |