Kartenmanagement egk. Facharchitektur

Transkript

1 Einführung der Gesundheitskarte Kartenmanagement egk Version: Revision: main/rel_main/8 Stand: Status: freigegeben gematik_cms Kartenmanagement_eGK.doc Seite 1 von 81

2 Dokumentinformationen Änderungen zur Vorversion Gegenüber der Version wurden folgende Änderungen eingepflegt: Klarstellung zur Signatur der Responsenachricht in Tabelle 14 Anwendungsfall übergreifende Parameter Benennung SK.CAMS zu SK.CMS geändert Einfügen von Anhang D mit einer Übersicht über die verwendeten Versionen gemäß [gemspec_versnr]. Redaktionell wurde die Referenzierungstabelle (Anhang F.5) überarbeitet. Die vorgenommenen Änderungen gegenüber der Vorversion wurden farblich hervorgehoben. Sofern ganze Kapitel eingefügt oder wesentlich geändert wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Das Dokument wird von den anderen gematik-dokumenten referenziert als: [gemfa_cmsegk] gematik: Einführung der Gesundheitskarte Kartenmanagement egk, Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Version zur internen Kommentierung vorgelegt Kommentare der internen Kommentierung eingearbeitet gematik, AG3 gematik, AG Freigabe zur Vorkommentierung gematik Ergebnisse der internen Kommentierung eingearbeitet Berücksichtigung der Ergebnisse der Vorkommentierung gematik, AG3 gematik, AG Freigabe gematik Anpassung an neue Struktur für en und Einarbeitung externer Kommentare gematik, AG3 gematik_cms Kartenmanagement_eGK.doc Seite 2 von 81

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Freigabe gematik , 6.3.4, 7.1, 9.1 Änderung der Identität des Datenbearbeiters/ Fachdienstes in Tabelle 16, Anpassung an neue Vorgaben zur Ausgestaltung der Tabellen zur Bildung der SOAP- Messages gematik, AG Freigabe gematik Einpflegen der SRQs 0572 und 0573, Anpassung von Bezeichnungen an aktuellen gematik-standard Anpassung an neue Vorlage für en zur Spezifikation der SOAP- Nachrichten Einfügen eines neuen Kapitels mit ergänzenden Informationen zur Schnittstelle Broker Fachdienst gematik, AG freigegeben gematik Einarbeitung von Kommentaren der externen Kommentierung Änderung Broker Sequenz für das Kommando GetNextCommadPackage Konkretisierung der zur Nachrichtensignatur verwendeten Identitäten Entfernung von informativen Abschnitten, welche für Release 2 nicht relevant sind Einarbeitung von Anforderungen gemäß AR und AR-0456 zur Optimierung der Performance SPE/ZD freigegeben gematik Einarbeitung von Kommentaren SPE/ZD freigegeben gematik Anhang D zu Versionsangaben und Klarstellung zur Signatur einer Responsenachricht eingefügt Umbenennung SK.CAMS auf SK.CMS gemäß [gempki_nota] SPE/ZD freigegeben gematik gematik_cms Kartenmanagement_eGK.doc Seite 3 von 81

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokuments Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokuments Verwendung von Schlüsselwörtern Anforderungen und Annahmen Einleitung Anforderungen an das Kartenmanagement der egk Annahmen Systemüberblick Überblick Beschreibung der Komponenten Broker Service (BS) Card Management System (CMS) Fachdienst egk Kartenterminal Konnektor OCSP-Responder Primärsystem Update Flag Service (UFS) Administration und Aktualisierung von ausgegebenen egks Detaillierte Beschreibung der technischen Anwendungsfälle Vorgaben und generelle Hinweise zur Umsetzung gematik_cms Kartenmanagement_eGK.doc Seite 4 von 81

5 5.2 Abbildung fachlicher Anwendungsfälle auf technische Use Cases TUC_CM_001 egk-aut-zertifikat suspendieren (informativ) TUC_CM_002 egk-aut-zertifikat freigeben (informativ) TUC_CM_003 egk-aut-zertifikat sperren (informativ) TUC_CM_011 Update Flag setzen (informativ) TUC_CM_012 Notwendigkeit für Aktualisierung prüfen TUC_CM_013 Update Flag löschen (informativ) TUC_CM_021 egk aktualisieren Schnittstelle Konnektor - BrokerService Einführung Broker-Sequenzen Fehlerbehandlung Anwendungsfall übergreifende Parameter GetUpdateFlags Zuordnung der Broker Sequenzen Request Fachlicher Payload Response Fachliche Payload PerformUpdates Zuordnung der Broker-Sequenzen Request Fachliche Payload Response Fachliche Payload GetNextCommandPackage Zuordnung der Broker-Sequenzen Request Fachliche Payload Response Fachliche Payload Schnittstelle Broker Fachdienst Schnittstelle CMS Update Flag Service (informativ) SetUpdateFlag Request Fachliche Payload gematik_cms Kartenmanagement_eGK.doc Seite 5 von 81

6 8.1.2 Response Fachliche Payload DeleteUpdateFlag Request Fachliche Payload Response Fachliche Payload Schnittstelle CMS OCSP-Responder (informativ)...55 Anhang A Secure Messaging mit Trusted Channel (informativ)...56 A.1 Sequenzdiagramm A.2 Beschreibung der Prozessschritte Anhang B Einbindung in Geschäftsprozesse (informativ)...60 B.1 Sperrung einer egk bei Verlust B.1.1 Ziel des Geschäftsprozesses B.1.2 Beschreibung des Ablaufs B.2 Ausgabe einer Folge-eGK (ohne Kassenwechsel) B.2.1 Ziel des Geschäftsprozesses B.2.2 Beschreibung des Ablaufs B.3 Ausgabe einer egk nach Kassenwechsel Anhang C Anhang D Rechtematrix...64 Übersicht über Versionen und Schemata...65 Anhang E Umsetzung der Anforderungen aus dem Fachkonzept (informativ) 66 E.1 Fachliche Anforderungen E.2 Sicherheitsanforderungen E.3 Nichtfunktionale Anforderungen Anhang F...77 F.1 Abkürzungen F.2 Glossar F.3 Abbildungsverzeichnis F.4 Tabellenverzeichnis F.5 Referenzierte Dokumente gematik_cms Kartenmanagement_eGK.doc Seite 6 von 81

7 1 Zusammenfassung Zur Sicherstellung der Interoperabilität bei der Anbindung eines Kartenmanagementsystems (Card Management System, CMS) für die elektronische Gesundheitskarte (egk) an die Telematikinfrastruktur ist die Spezifikation der Schnittstelle zwischen CMS und Telematik Tier unbedingt erforderlich. Interne Komponenten eines Kartenmanagementsystems (z. B. Anwendungsmanagement, Life Cycle Management, Key Management) werden zwar zur Unterstützung der Funktionen an der Schnittstelle benötigt, eine Standardisierung dieser Komponenten ist nicht zwingend notwendig, so dass auf die Spezifikation dieser Komponenten durch die gematik verzichtet und den Kartenherausgebern die Umsetzung eigener Vorstellungen erleichtert wird. Das Ziel der Arbeiten der gematik zum Kartenmanagement ist dementsprechend nicht die Spezifikation eines vollständigen Karten- und Kartenanwendungsmanagementsystems, sondern die Spezifikation der Schnittstelle zwischen CMS und Telematik Tier, um die Einbindung des CMS in die Telematikinfrastruktur zu gewährleisten. Die vorliegende ist ein wesentlicher Beitrag zur Erstellung der benötigten Schnittstellenspezifikation und reiht sich in eine Serie von Dokumenten zum Kartenmanagement der egk ein. Im Einzelnen sind für Release 2 der Projektplanung der gematik die Dokumente zu nennen. Fachkonzept Kartenmanagement egk [gemfk_cmsegk], Schnittstellenspezifikation Card Communication Service [gemsst_ccs] und Schnittstellenspezifikation Update Flag Service [gemsst_ufs] Ausgehend von den im Fachkonzept formulierten fachlichen Anforderungen wird in Kapitel 5 dieses Dokumentes die technische Umsetzung mit Hilfe von Sequenzdiagrammen skizziert. Die detaillierte Spezifikation der Schnittstelle zwischen CMS und Telematik Tier ist nicht Bestandteil dieses Dokuments und erfolgt in [gemsst_ccs] und [gemsst_ufs]. Zur Ableitung der zur Umsetzung der Fachanforderungen notwendigen technischen Anwendungsfälle ist die in [gemgesarch] beschriebene Gesamtarchitektur der Telematikinfrastruktur berücksichtigt worden. Die dort betrachteten und im Rahmen des Kartenmanagements zu berücksichtigenden Komponenten sind in Kapitel 4 noch einmal explizit aufgelistet und beschrieben. Viele der in diesem Dokument beschriebenen Anwendungsfälle sind generischer Natur und können zur Umsetzung verschiedenster Geschäftsvorfälle verwendet werden. Zur Verdeutlichung der Zusammenhänge wird in Anhang A beispielhaft das Secure Messaging mit Trusted Channel unter Verwendung der in Kapitel 5 vorgestellten Anwendungsfälle detailliert dargestellt. Aus dem gleichen Grund erfolgt in Anhang B eine Erläuterung zur Nutzung der beschriebenen Szenarien im Rahmen von konkreten Geschäftsvorfällen wie z. B. das Sperren der HCA-Anwendung bei Verlust der egk (s. Anhang B.1). gematik_cms Kartenmanagement_eGK.doc Seite 7 von 81

8 Anhang E dokumentiert abschließend ausführlich den Zusammenhang zwischen den in diesem Dokument vorgestellten technischen Use Cases und den in [gemfk_cmsegk] dargestellten fachlichen Anforderungen. gematik_cms Kartenmanagement_eGK.doc Seite 8 von 81

9 2 Einführung 2.1 Zielsetzung und Einordnung des Dokuments Diese beschreibt die technischen Anwendungsfälle für das Karten- und Kartenanwendungsmanagement primär an der Schnittstelle zur Telematik Tier. Es handelt sich hierbei um die Abbildung der fachlichen Anforderungen und Anwendungsfälle aus dem Fachkonzept Kartenmanagement [gemfk_cmsegk] auf die technischen Komponenten der Telematik. Anhang E verdeutlicht diesen Zusammenhang noch einmal. Damit dient diese als Grundlage für die Spezifikation der Schnittstellen zwischen Konnektor und CMS unter Nutzung der Telematikinfrastruktur (s. a. [gemsst_ccs], [gemsst_ufs]). 2.2 Zielgruppe Dieses Dokument dient zur Abstimmung der Abläufe zwischen dem Kartenmanagement und der Telematikinfrastruktur. In der abgestimmten Version richtet es sich insbesondere an die Entwickler und Betreiber von Kartenmanagementsystemen für die egk sowie an die Autoren der Konnektorspezifikation [gemspec_kon]. 2.3 Geltungsbereich Dieses Dokument entstand im Rahmen der Arbeiten der gematik zur Umsetzung der Verordnung über Testmaßnahmen für die Einführung der elektronischen Gesundheitskarte gemäß der Verordnung über Testmaßnahmen für die Einführung der elektronischen Gesundheitskarte in der Fassung der Bekanntmachung vom 5. Oktober 2006 (siehe [RVO2006]). Es legt für Release 2 der gematik-projektplanung fest, wie die fachlichen Anforderungen an das Karten- und Kartenanwendungsmanagement der egk im Hinblick auf eine technische Architektur umgesetzt werden. Damit stellt es die verbindliche Grundlage für die Interaktionen zwischen den am Kartenmanagement beteiligten Komponenten sowie deren Schnittstellen dar. Abschnitte, die lediglich der ergänzenden Beschreibung der technischen Abläufe dienen, sind als informativ gekennzeichnet und haben somit keinen normativen Charakter. 2.4 Arbeitsgrundlagen Rechtliche Grundlage für die Ausführungen in diesem Dokument sind die 291 und 291a des SGB V, das Bundesdatenschutzgesetz, die Verordnung über Testmaßnahmen für die Einführung der elektronischen Gesundheitskarte [RVO2006]) sowie die Erfordernisse des Datenschutzes. Darüber hinaus trug das BMG zur Klärung rechtlicher und organisatorischer Fragen bei. gematik_cms Kartenmanagement_eGK.doc Seite 9 von 81

10 Fachliche Grundlage ist das Dokument "Fachkonzept Kartenmanagement" [gemfk_cmsegk], in dem die fachlichen Anforderungen an das Kartenmanagement beschrieben sind. Technische Grundlagen sind die Spezifikation der egk gemäß [gemspec_egk_p1] und [gemspec_egk_p2], die Gesamtarchitektur [gemgesarch] sowie die Spezifikation der Telematik Transport-Details [gemspec_ttd]. 2.5 Abgrenzung des Dokuments Die Ausführungen zum Kartenmanagement in diesem Dokument beziehen sich ausschließlich auf das Management von elektronischen Gesundheitskarten für Release 2 der gematik- Projektplanung und nicht auf das Management von Heilberufsausweisen (HBA) oder Sicherheitsmodulkarten (Security Module Card - SMC). Fachliche Grundlagen des Kartenmanagements werden im "Fachkonzept Kartenmanagement" [gemfk_cmsegk] beschrieben und bilden die Grundlage für die Erstellung dieses Dokumentes. Das Dokument beschränkt sich auf Anwendungsfälle, welche die Schnittstellen zum Kartenmanagementsystem bzw. zum Update Flag Service berühren. Da die Umsetzung der in [gemfk_cmsegk] beschriebenen Anwendungsfälle ganz wesentlich von [gemspec_egk_p1] und [gemspec_egk_p2] abhängt und in [gemspec_egk_p1] nicht alle Kommandos, welche im Rahmen des Kartenmanagements zur Umsetzung der Anwendungsfälle benötigt werden, eindeutig spezifiziert sind, ist eine herstellerunabhängige Spezifikation dieser Anwendungsfälle unmöglich. Zu nennen sind hier vor allem Anwendungsfälle, welche die Kartenkommandos CREATE FILE und LOAD APPLICATION nutzen. Die vorliegende konzentriert sich daher auf die Bereitstellung eines Transportmechanismus zur transparenten Weiterleitung von Kommandos an die egk sowie die zugehörigen Antwort-Codes der egk. Die konkrete Umsetzung der in [gemfk_cmsegk] beschriebenen Anwendungsfälle zur Administration der egk muss wegen der oben erwähnten herstellerspezifischen Implementierung der Chipkartenbetriebssysteme von den Kartenherausgebern unter Berücksichtigung der Spezifikation der verwendeten Betriebssysteme vorgenommen werden. Anwendungsfälle, welche im Zusammenhang mit der Administration von Daten und Anwendungen innerhalb eines Kartenmanagementsystems zu berücksichtigen sind, werden hier ebenfalls nicht betrachtet. Deren Umsetzung ist im Bezug auf die Interoperabilität ohne Bedeutung und wird den Betreibern der Systeme freigestellt. Die detaillierte technische Beschreibung der Schnittstelle zum Kartenmanagementsystem bzw. zum Update Flag Service befindet sich in den Dokumenten "Schnittstellenspezifikation Card Communication Service [gemsst_ccs] und "Schnittstellenspezifikation Update Flag Service" [gemsst_ufs], welche auf dem vorliegenden Dokument aufbauen. Um ein vollständiges Bild der Telematikanwendungen in Bezug auf das Kartenmanagement zu erhalten, wird empfohlen, einzelne Kapitel der folgenden Dokumente ebenfalls zu lesen: Spezifikation des Konnektors [gemspec_kon]: Hier werden sämtliche Schnittstellen des Konnektors beschrieben, die durch die Primärsysteme genutzt werden können. Verwiesen sei hier besonders auf die Basisfunktionalitäten, die zum Beispiel das Handling der Karten ermöglichen. In der Kartenmanagement wird nicht näher auf diese Funktionen eingegangen. gematik_cms Kartenmanagement_eGK.doc Seite 10 von 81

11 Spezifikation der egk Teil 1 [gemspec_egk_p1]: Hier werden die Basiskommandos, die Grundfunktionen des Betriebssystems sowie die grundlegenden Sicherheitsfunktionen und -algorithmen detailliert beschrieben. Spezifikation der egk Teil 2 [gemspec_egk_p2]: Hier werden die anwendungsspezifischen Strukturen der egk beschrieben. Der Teil enthält u.a. die Spezifikation der egk mit ihren Dateninhalten, physikalischen Datenstrukturen und den Zugriffsrechten. Gesamtarchitektur [gemgesarch]: Hier wird die Gesamtarchitektur der gematik beschrieben. Spezifikation TelematikTransport-Details [gemspec_ttd]: In diesem Dokument wird die Nachrichtenstruktur der für den Transport durch die Telematikinfrastruktur verwendeten SOAP-Nachrichten beschrieben. Weitere Dokumente finden sich im Anhang F Verwendung von Schlüsselwörtern Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschen Schlüsselwörter verwendet: MUSS. Absolutgültige und normative FESTLEGUNGEN sind durch das Schlüsselwort MUSS gekennzeichnet. DARF NICHT. Absolutgültige und normative AUSSCHLÜSSE sind durch das Schlüsselwort DARF NICHT gekennzeichnet. SOLL. EMPFEHLUNGEN ZU FESTLEGUNGEN sind durch das Schlüsselwort SOLL gekennzeichnet. Abweichungen sind in begründeten Fällen möglich. SOLL NICHT. EMPFEHLUNGEN ZU AUSSCHLÜSSEN sind durch das Schlüsselwort SOLL NICHT gekennzeichnet. Abweichungen sind in begründeten Fällen möglich. KANN. Vollständig FAKULTATIVE EIGENSCHAFTEN sind durch das Schlüsselwort KANN gekennzeichnet und haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. gematik_cms Kartenmanagement_eGK.doc Seite 11 von 81

12 3 Anforderungen und Annahmen 3.1 Einleitung Die fachlichen Anforderungen entstammen dem Fachkonzept Kartenmanagement egk [gemfk_cmsegk] und umfassen sowohl funktionale wie nicht-funktionale als auch Sicherheitsanforderungen. Technische Anforderungen folgen aus architektonischen Vorgaben der Gesamtarchitektur [gemgesarch] und Vorgaben des Architekturboards. 3.2 Anforderungen an das Kartenmanagement der egk Im Rahmen des Kartenmanagements der egk sind zur Sicherstellung der Interoperabilität an der Schnittstelle zwischen Kartenmanagementsystem und Telematikinfrastruktur für Release 2 folgende fachlichen Use Cases (s. a. [gemfk_cmsegk]) zu berücksichtigen: Tabelle 1: Fachliche Use Cases mit Bezug zur Schnittstelle CMS - TI Kennung Beschreibung Kartenlebenszyklusmanagement UC_CM_10 UC_CM_11 egk sperren egk freigeben Validitätsmanagement UC_CM_22 UC_CM_23 Gesundheitsanwendung sperren Gesundheitsanwendung freigeben Kartenanwendungsmanagement UC_CM_33 UC_CM_34 UC_CM_35 UC_CM_36 UC_CM_37 Anwendung auf die egk nachladen Anwendung auf der egk aktivieren Anwendung auf der egk aktualisieren Anwendung auf der egk deaktivieren Anwendung auf der egk löschen Bei den betrachteten Use Cases handelt es sich entweder um die Administration, d. h. das Sperren, Entsperren, Anlegen und Löschen von auf der egk befindlichen Dateien oder um ein Update von Dateiinhalten. Während die Administration von Dateien allein dem Kartenmanagementsystem vorbehalten bleibt, kann ein Update von Dateiinhalten auch von Fachdiensten wie z. B. dem VSDD durchgeführt werden. Die Kommandos und die Berechtigungen (Schlüssel) zur Durchführung dieser Aufgaben sind in [gemspec_egk_p1] und [gemspec_egk_p2] beschrieben und können sich im weiteren Projektverlauf ändern. Die vorliegende beschäftigt sich daher lediglich mit dem Rahmen, in welchem diese Kommandos unter Nutzung der TI an die egk gesendet gematik_cms Kartenmanagement_eGK.doc Seite 12 von 81

13 werden können. Die nachfolgend beschriebenen technischen Use Cases zur Aktualisierung bilden daher auch Grundlage für die Durchführung von Updates durch verschiedene Fachdienste (s. a. [gemfa_vsdm]). In jedem Fall ist die Zusammenstellung der Kommandos zur Aktualisierung abhängig vom Anwendungsfall sowie teilweise vom Chipkartenbetriebssystem und liegt in der Verantwortung der Kartenmanagementsystembetreiber. Neben den in Tabelle 1 beschriebenen fachlichen Use Cases mit direktem Bezug zur Schnittstelle CMS - TI sind im Zusammenhang mit dem Management von ausgegebenen egks noch folgende Use Cases von Bedeutung: Tabelle 2: Fachliche Use Cases mit Bezug zum Management von ausgegebenen egks im Feld ohne Nutzung der Telematikinfrastruktur Kennung Beschreibung Validitätsmanagement UC_CM_20 UC_CM_21 egk für die Online-Nutzung sperren egk für die Online-Nutzung freigeben Die Umsetzung dieser Use Cases liegt in der Verantwortung der Kostenträger und muss nicht zwangsläufig unter Nutzung des CMS erfolgen. Trotzdem werden sie in diesem Dokument der Vollständigkeit wegen erwähnt, um eine besseres Verständnis der Gesamtabläufe zu ermöglichen. Auf der Grundlage dieser fachlichen Use Cases sind in [gemfk_cmsegk] nicht-funktionale Anforderungen und Sicherheitsanforderungen abgeleitet worden, welche nachfolgend noch einmal aufgelistet sind und welche die Grundlage für die Ableitung der technischen Use Cases bilden. Für den Fall, dass in der Tabelle einer Anforderung mehrere Kennungen zugeordnet sind, ist dies gleichbedeutend mit der Tatsache, dass diese Anforderung Bestandteil mehrerer fachlicher Use Cases ist. Der mittlere Teil der Kennung (z. B. CM_01), lässt dabei auf den Use Case (z. B. egk herstellen) schließen für den die Anforderung gestellt wurde. Tabelle 3: Nicht-funktionale Anforderungen Kennung AN_CM_01_01 AN_CM_11_01 AN_CM_20_01 AN_CM_21_01 AN_CM_22_02 AN_CM_23_01 AN_CM_33_01 AN_CM_34_01 AN_CM_35_01 AN_CM_36_01 AN_CM_37_01 AN_CM_34_02 AN_CM_35_02 AN_CM_36_02 AN_CM_37_02 Beschreibung Die Weiternutzung von Anwendungsdaten MUSS dem Versicherten ermöglicht werden. Der Kartenherausgeber MUSS eine eindeutige Zuordnung zwischen Versichertem und egk herstellen können. Die egk MUSS über ein Authentifizierungsmerkmal verfügen. Der Kartenherausgeber MUSS über ein Authentifizierungsmerkmal verfügen. Tabelle 4: Sicherheitsanforderungen gematik_cms Kartenmanagement_eGK.doc Seite 13 von 81

14 Kennung AS_CM_10_01 AS_CM_10_02 AS_CM_10_03 AS_CM_11_01 AS_CM_11_02 AS_CM_11_03 AS_CM_20_01 AS_CM_21_01 AS_CM_22_01 AS_CM_23_01 AS_CM_33_01 AS_CM_34_01 AS_CM_35_01 AS_CM_36_01 AS_CM_37_01 AS_CM_33_02 AS_CM_35_02 AS_CM_36_02 AS_CM_34_02 AS_CM_37_02 AS_CM_33_03 AS_CM_33_04 A_01842 A_01915 Beschreibung Der Versicherte MUSS beim Auslösen einer Kartensperrung zunächst identifiziert werden Der Zeitpunkt und der Grund der Sperrung einer egk MUSS protokolliert werden. Es MUSS sichergestellt werden, dass kein fremder Kartenherausgeber eine Karte sperren kann. Der Versicherte ist beim Auslösen der Entsperrung einer gesperrten egk zu identifizieren Der Zeitpunkt und der Grund der Entsperrung einer egk MUSS protokolliert werden. Es muss sichergestellt werden, dass kein fremder Kartenherausgeber eine Karte entsperren kann. Der Zeitpunkt und der Grund der Sperrung einer egk für die Online-Nutzung MÜSSEN protokolliert werden. Der Zeitpunkt und der Grund der Entsperrung einer egk für die Online-Nutzung MÜSSEN protokolliert werden. Der Zeitpunkt und der Grund der Sperrung der Gesundheitsanwendung einer egk MÜSSEN protokolliert werden. Der Zeitpunkt und der Grund der Freigabe der Gesundheitsanwendung einer egk MÜSSEN protokolliert werden. Die egk MUSS sich gegenüber dem Kartenherausgeber authentifizieren Der Kartenherausgeber MUSS sich gegenüber der egk authentifizieren. Das Nachladen der Anwendung MUSS vertraulich erfolgen. Die Integrität der Daten MUSS beim Nachladen der Anwendung gewährleistet sein. Eine Anfrage zur Notwendigkeit der Aktualisierung der egk durch einen Fachdienst MUSS ohne Nachrichtensignatur der Datenautorität erfolgen. Quelle: Anforderungsmeldung AR-0456 Die Durchführung der Aktualisierung einer egk durch einen Fachdienst MUSS ohne Nachrichtensignatur der Datenautorität erfolgen. Quelle: Anforderungsmeldung AR Annahmen Es sind keine weiteren Annahmen zu berücksichtigen. gematik_cms Kartenmanagement_eGK.doc Seite 14 von 81

15 4 Systemüberblick 4.1 Überblick Primärsysteme Service Consumer Tier InfrastrukturPKIServices PKI-Zeitstempel, OCSP, CRL InfrastrukturNetzwerkServices DNS, NTP SDS Konnektor BrokerService Trusted Service Audit Service Kartenterminal egk Telematik Tier UFS CMS VSDD OCSP- Responder Weitere Fachdienste Service Provider Tier Abbildung 1: Überblick über Komponenten (vereinfacht, aus Kartenmanagement-Sicht) Abbildung 1 zeigt einen Überblick über die für das Kartenmanagement relevanten Komponenten der Telematikinfrastruktur, welche im Bild schraffiert gekennzeichnet sind. Auf der Seite der Leistungserbringer (LE) befinden sich die Komponenten, die der Service Consumer Tier zuzurechnen sind: Primärsysteme der Leistungserbringer (s. Abschnitt 4.2.8) Die Telematik Tier bildet die Verbindungsschicht zwischen Service Consumer Tier und Service Provider Tier und stellt beiden Seiten zahlreiche Dienste zur Verfügung. Für das Kartenmanagement sind insbesondere folgende Komponenten relevant: egk (s. Abschnitt 4.2.4) Kartenterminal (s. Abschnitt 4.2.5) Konnektor (s. Abschnitt 4.2.5) gematik_cms Kartenmanagement_eGK.doc Seite 15 von 81

16 Broker Service (BS, s. Abschnitt 4.2.1) Auf Seite der Kartenherausgeber befinden sich Komponenten, die Backoffice-Dienste für die Telematik Tier und hierüber mittelbar auch für die Service Consumer Tier bereitstellen. Hierzu zählen insbesondere: Update Flag Service (UFS, s. Abschnitt 4.2.9) OCSP-Responder (s. Abschnitt 4.2.7) Card Management System (CMS, s. Abschnitt 4.2.2) verschiedene Fachdienste (s. Abschnitt 4.2.3) 4.2 Beschreibung der Komponenten Broker Service (BS) Der Broker Service integriert einzelne Telematik-Dienste in komplexere Ablauffolgen, Telematik-Sequenzen genannt, die vom Konnektor aufgerufen werden können. Zur Bereitstellung dieser Telematik-Sequenzen verwendet der Broker Service die anderen Dienste der Telematik Tier (z. B. zur Protokollierung, Anonymisierung, usw.) sowie die Dienste der Service Provider Tier (vgl. [gemgesarch]) Card Management System (CMS) Das Card Management System (Kartenmanagementsystem) ist eine Komponente, die das gesamte Management der egk umfasst: das Lebenszyklusmanagement (Card Life Cycle Management CLM), das Anwendungsmanagement (Application Management AM) und das Kartenanwendungsmanagement (Card Application Management CAM). Somit unterstützt das CMS alle Prozesse eines Kartenherausgebers von der Kartenproduktion über die Verwendung der egk durch einen Karteninhaber bis zum Ende des Kartenlebenszyklus Fachdienst Fachdienste im Allgemeinen realisieren die technische Umsetzung von Fachanwendungen wie beispielsweise: Versichertenstammdatendienst (VSDD) Bereitstellung der Versichertenstammdaten Verordnungsdatendienst (VODD) Verarbeitung der Verordnungsdaten epa-dienst Bereitstellung einer elektronischen Patientenakte 1 Im vorliegenden Kontext geht es lediglich um die Schnittstellen zur Telematikinfrastruktur bzw. zu anderen Diensten. Eine Betrachtung von CLM und AM erfolgt nur soweit dies im Bezug auf die Beschreibung der Schnittstellen notwendig ist. gematik_cms Kartenmanagement_eGK.doc Seite 16 von 81

17 4.2.4 egk Die elektronische Gesundheitskarte ist gemäß 291 a SGB V eine personenbezogene Identifikationskarte, die Versicherte der Gesetzlichen Krankenversicherung (GKV) zur Inanspruchnahme ärztlicher und zahnärztlicher Behandlung gemäß 15 SGB V berechtigt. Sie enthält gemäß 291 a SGB V Angaben, die für die Übermittlung elektronisch veranlasster ärztlicher Verordnungen geeignet sind Kartenterminal Das Kartenterminal ist eine technische Einrichtung zum Kontaktieren der im System verwendeten Chipkarten Konnektor Der Konnektor koordiniert die Kommunikation zwischen Primärsystem, egk, HBA/SMC und Telematikinfrastruktur. Er stellt damit das Bindeglied zwischen diesen Komponenten auf Leistungserbringerseite bzw. dem ekiosk und der Telematik Tier dar. Alle im Weiteren gemachten Betrachtungen basieren auf der grundlegenden Sicherheitsanforderung, dass nur autorisierte Zugriffe von Außen auf die Infrastruktur innerhalb einer Arztpraxis, eines Krankenhauses usw. und somit auch auf die egk erlaubt sind. Der Konnektor kontrolliert den externen Zugriff über seine Ablaufsteuerung. Zur Durchführung bestimmter Aufgaben (z. B. Update der egk) kann der Konnektor die Kontrolle nach zuvor durchgeführter Authentifizierung an Fachdienste (z. B. VSDD, CMS) abgeben OCSP-Responder Der OCSP-Responder ist Bestandteil der X.509-PKI und verwaltet Informationen zum aktuellen Sperrzustand der egk-aut-zertifikate Primärsystem Unter einem Primärsystem wird die Komponente eines Leistungserbringers verstanden, typischerweise in einer der folgenden Ausprägungen: PVS Praxisverwaltungssystem AVS Apothekenverwaltungssystem KIS Krankenhausinformationssystem Im erweiterten Sinne können auch der ekiosk und der Anwendungskontext Versicherter@Home als Primärsystem bezeichnet werden, da beide ggf. unter Nutzung der Telematikinfrastruktur auf eine egk zugreifen können Update Flag Service (UFS) Für den Fall, dass ein Fachdienst bzw. ein Kartenmanagementsystem ein Update auf einer egk durchführen möchte, hinterlegt dieser bzw. dieses diese Information an einer für diese egk zentralen Stelle und setzt ein Update Flag im so genannten Update Flag Service. Die- gematik_cms Kartenmanagement_eGK.doc Seite 17 von 81

18 ser Dienst bündelt somit den ggf. vorliegenden Aktualisierungsbedarf aller Fachdienste und des Kartenmanagementsystems und zeigt diesen an. Dadurch entfällt der Aufwand, den Aktualisierungsbedarf einer egk bei verschiedenen Diensten explizit abzufragen, es reicht eine Abfrage beim UFS 2. Möchte also ein Fachdienst (bzw. das Kartenmanagementsystem) eine egk aktualisieren, setzt dieser Fachdienst ein entsprechendes Update Flag im UFS. Sobald die betroffene egk anschließend z. B. im Rahmen eines Arztbesuches oder eines Krankenhausaufenthaltes des Versicherten in der Telematikinfrastruktur verwendet wird und die Versichertenstammdaten eingelesen werden, erfolgt automatisch die Abfrage, ob für diese egk ein oder mehrere Update Flags gesetzt sind. Bei Bedarf wird anschließend eine Verbindung zum anfragenden Fachdienst aufgebaut. Die Operationen des Update Flag Service und der Aufbau von Update-Flags sind in der Schnittstellenspezifikation UFS [gemsst_ufs] definiert. 4.3 Administration und Aktualisierung von ausgegebenen egks Wie schon in Abschnitt 3.2 erwähnt, lässt sich die Mehrzahl der fachlichen Use Cases im Prinzip über ein Kommunikationsmuster abbilden. Dieses Kommunikationsmuster ist in Abbildung 2 in einem Sequenzdiagramm beispielhaft dargestellt, um das Zusammenspiel der einzelnen Komponenten zu verdeutlichen. Das Sequenzdiagramm beschreibt alle Prozessschritte im Zusammenhang mit der Administration bzw. Aktualisierung von Dateien von ausgegebenen egks. Auftretende Fehler werden in dem Sequenzdiagramm nicht betrachtet. Technische Use Cases, welche in dieser lediglich zum besseren Verständnis der Zusammenhänge beschrieben werden, sind in der Abbildung schraffiert dargestellt. Detailinformationen zu den Abläufen der entsprechend gekennzeichneten Use Cases (TUC_KON_xyz] sind in der Konnektorspezifikation [gemspec_kon] nachzulesen. 2 Um die Aktualität der egk für alle betroffenen Fachdienste sicherzustellen, wäre der UFS nach jedem Stecken einer egk innerhalb der Telematik-Infrastruktur aufzurufen. gematik_cms Kartenmanagement_eGK.doc Seite 18 von 81

19 Konnektor Kartenterminal egk OCSP- Responder UFS Fachdienst, CMS 1 opt ref [z.b. egk verlegt] TUC_CM_001 egk-auth-zertifikat suspendieren 2 opt ref [egk wiedergefunden] TUC_CM_002 egk-auth-zertifikat freigeben 3 opt [egk gestohlen] 5 6 ref ref TUC_KON_001 Karte öffnen TUC_KON_038 egk-authzertifikat prüfen ref TUC_CM_003 egk-auth-zertifikat sperren 4 ref TUC_CM_011 Update Flag setzen 7 8 ref ref TUC_CM_012 Notwendigkeit für Aktualisierung prüfen TUC_CM_021 egk aktualisieren 9 ref TUC_CM_013 Update Flag löschen Abbildung 2: Sequenzdiagramm Administration und Aktualisierung von ausgegebenen egks Die einzelnen Prozessschritte sind in der nachfolgenden Tabelle beschrieben. Tabelle 5: Ablauf Administration und Aktualisierung von ausgegebenen egks Schritt Funktion Beschreibung 1 egk-aut-zertifikat suspendieren 2 egk-aut-zertifikat freigeben 3 egk-aut-zertifikat sperren Für den Fall, dass ein Versicherter seine egk nicht auffinden kann, weil er sie z. B. verlegt hat, und seine Krankenkasse darüber informiert, kann diese die weitere Online-Nutzung der egk verhindern, indem sie das AUT-Zertifikat der egk im OCSP-Responder suspendiert (s. Abschnitt 0). Nach Ausgabe einer egk wird das AUT-Zertifikat der egk im OCSP-Responder freigegeben. (s. Abschnitt 5.4). Für den Fall, dass z. B. die egk eines Versicherten gestohlen wurde, und der Versicherte seine Krankenkasse darüber informiert, kann diese die egk für die Online-Nutzung sperren, indem sie das AUT-Zertifikat der egk im OCSP-Responder sperrt (s. Abschnitt 0). 4 Update Flag setzen Für den Fall, dass eine egk aktualisiert werden soll, ist dies der Karte anzuzeigen. Dazu muss ein so genanntes Update Flag im Update Flag Service gesetzt werden (s. Abschnitt 0). gematik_cms Kartenmanagement_eGK.doc Seite 19 von 81

20 Schritt Funktion Beschreibung 5 Karte öffnen Nach Stecken der Karte im Kartenleser öffnet der Konnektor die Karte und liest alle relevanten Informationen (z. B. ICCSN) der Karte aus (Details s. [gemspec_kon]). 6 egk-aut-zertifikat prüfen 7 Notwendigkeit für Aktualisierung prüfen Der Konnektor prüft die (Online-)Gültigkeit der egk durch eine OCSP-Abfrage am OCSP-Responder (Details s. [gemspec_kon]). Der Konnektor fragt beim Update Flag Service (UFS) an, ob für die betroffene egk ein Update vorliegt (s. Abschnitt 5.7). 8 egk aktualisieren Wird über ein gesetztes Flag im UFS Aktualisierungsbedarf für die egk angezeigt, initiiert und steuert der Konnektor die Aktualisierung (s. Abschnitt 5.9) 9 Update Flag löschen Nach erfolgreicher Aktualisierung der egk löscht der Fachdienst bzw. das CMS das zugehörige Update Flag (s. Abschnitt 5.8). gematik_cms Kartenmanagement_eGK.doc Seite 20 von 81

21 5 Detaillierte Beschreibung der technischen Anwendungsfälle 5.1 Vorgaben und generelle Hinweise zur Umsetzung Bei der Erarbeitung der technischen Anwendungsfälle sind folgende Vorgaben zu Vorgehensweise, Modellierung und technischer Umsetzung beachtet worden: In Sequenzdiagrammen wird bewusst auf eine UML-syntaktisch korrekte Modellierung fehlerbedingter Prozess-Abbrüche mittels einer Ja/Nein-Bedingung zu Gunsten einer übersichtlicheren Darstellungsform verzichtet. Alle technisch umzusetzenden Schritte sind in den Diagrammen nummeriert und anschließend näher beschrieben. Prozessschritte, die zu einer Fehlermeldung führen, brechen den Ablauf des Use Cases ab. Das heißt, der Use Case wird an dieser Stelle mit einer entsprechenden Fehlermeldung beendet. Grundsätzlich werden nur die Komponenten modelliert, die direkt im modellierten Kontext für das Kartenmanagement angesprochen und nicht anderen Ortes modelliert werden. Zur Kommunikation mit den Komponenten Kartenterminal und egk wird auf technische Use Cases des Konnektors oder des Kartenmanagements verwiesen. Für jedes Kommando erfolgt eine detaillierte Beschreibung von allgemeinen Anforderungen zur Implementierung, wobei speziell die Schnittstelle Konnektor BrokerService entsprechend der Vorgaben aus [gemspec_ttd] beschrieben wird, um die effiziente Umsetzung der Aufrufe durch SOAP (Simple Object Access Protocol)-Messages zu erleichtern. Die konkrete Umsetzung ist nicht Bestandteil dieses Dokuments sondern wird in den entsprechenden Komponenten spezifiziert (z. B. [gemspec_kon]). Gleiches gilt für die relevanten Funktionsaufrufe (Requests) und Antworten (Responses) des CMS mit ihren jeweiligen Parametern. Im vorliegenden Dokument werden zum besseren Verständnis der Sequenzdiagramme lediglich Elementdiagramme zum Payload der verwendeten Aufrufe bzw. Antworten dargestellt. Eine Detailbeschreibung der Datenelemente befindet sich in [gemsst_ccs] bzw. [gemsst_ufs]. 5.2 Abbildung fachlicher Anwendungsfälle auf technische Use Cases Im Fachkonzept Kartenmanagement egk [gemfk_cmsegk] werden fachliche Anwendungsfälle für das Kartenmanagement unterschieden, die in der vorliegenden entsprechend der nachfolgenden Tabelle auf technische Anwendungsfälle abgebildet wurden. Die Auflistung der technischen Anwendungsfälle erfolgt dabei in chronologischer Reihenfolge entsprechend ihrer Umsetzung im Konnektor (s. [gemspec_kon]). gematik_cms Kartenmanagement_eGK.doc Seite 21 von 81

22 Tabelle 6: Übersicht der abgebildeten Anwendungsfälle Fachliche Anwendungsfälle UC_CM_20 egk für die Online-Nutzung sperren UC_CM_21 egk für die Online-Nutzung freigeben Technische Use Cases zu deren Umsetzung TUC_CM_001 TUC_CM_003 TUC_CM_002 UC_CM_10 egk sperren UC_CM_11 egk freigeben UC_CM_22 Gesundheitsanwendung sperren UC_CM_23 Gesundheitsanwendung freigeben TUC_CM_011 TUC_KON_002 TUC_KON_038 TUC_CM_012 TUC_CM_021 TUC_CM_013 UC_CM_33 Anwendung auf die egk nachladen UC_CM_34 Anwendung auf der egk aktivieren UC_CM_35 Anwendung auf der egk aktualisieren UC_CM_36 Anwendung auf der egk deaktivieren UC_CM_37 Anwendung auf der egk löschen UC_CM_31 Anwendungen der egk auflisten Release 3 UC_CM_32 Verfügbaren Speicher auf der egk ermitteln UC_CM_42 Zugriffsmöglichkeit auf Online- Anwendungsdaten aufrechterhalten Release TUC_CM_001 egk-aut-zertifikat suspendieren (informativ) Dieser Anwendungsfall beschreibt die Suspendierung (vorübergehende Sperrung) eines egk-aut-zertifikats beim OCSP-Responder einer Certification Authority (CA) durch das CMS. Es liegt in der Verantwortung der Kartenherausgeber, wie die Prozesse zum Suspendieren, Freigeben und Sperren von Zertifikaten umgesetzt werden. Das Kartenmanagementsystem ist grundsätzlich das geeignete System für die Steuerung dieser Prozesse. Für den Fall, dass die Suspendierung nicht durch das Kartenmanagementsystem gesteuert wird, ist dieses in jedem Fall über den Vorgang zu informieren. gematik_cms Kartenmanagement_eGK.doc Seite 22 von 81

23 OCSP- Responder CMS 2 SuspendCertificate(Certificate) Bestätigung 1 Abbildung 3: Sequenzdiagramm TUC_CM_001 egk-aut-zertifikat suspendieren Tabelle 7: Beschreibung TUC_CM_001 egk-aut-zertifikat suspendieren Kurzbeschreibung Initiierender Akteur Weitere Akteure Auslöser Vorbedingungen Nachbedingungen Das Kartenmanagementsystem (Card Management System, CMS) veranlasst die Suspendierung des AUT-Zertifikats einer egk beim OCSP-Responder. Kostenträger Betreiber des OCSP-Responders Versicherter meldet den Verlust seiner egk Beendigung der Versicherung Alle lokalen Komponenten sind betriebsbereit und in fehlerfreiem Zustand. AUT-Zertifikat der egk ist gültig. Das AUT-Zertifikat der egk ist vorübergehend gesperrt. die egk ist für die weitere Online-Nutzung gesperrt. Ablauf Aufruf Suspend Certificate Aufruf des Kartenmanagementsystems an den OCSP- Responder. Parameter: P1: Certificate (des Versicherten, welches vorübergehend gesperrt werden soll) Rückmeldung Bestätigung Der OCSP-Responder bestätigt die vorübergehende Suspendierung des Zertifikates Mengengerüst Anforderungen an andere Komponenten Ca. 3% * 78,6 Mio. Versicherte pro Jahr melden den Verlust, Diebstahl oder Defekt ihrer Versichertenkarte Keine gematik_cms Kartenmanagement_eGK.doc Seite 23 von 81

24 5.4 TUC_CM_002 egk-aut-zertifikat freigeben (informativ) Dieser Anwendungsfall dient der Freigabe eines Zertifikats im OCSP-Responder einer Certification Authority (1) ggf. nach der ersten Nutzung einer ausgegebenen Karte bzw. (2) nach vorausgegangener Suspendierung eines egk-aut-zertifikats. Für den Fall, dass die Freigabe nicht durch das CMS gesteuert wird, ist dieses über den Vorgang zu informieren. Andernfalls muss das CMS den Prozess zur Freigabe eines egk- AUT-Zertifikates bei der CA bzw. dem OCSP-Responder der CA anstoßen. OCSP- Responder CMS 2 ActivateCertificate(Certificate) Bestätigung 1 Abbildung 4: Sequenzdiagramm TUC_CM_002 egk-aut-zertifikat freigeben Tabelle 8: Beschreibung TUC_CM_002 egk-aut-zertifikat freigeben Kurzbeschreibung Initiierender Akteur Weitere Akteure Auslöser Vorbedingungen Nachbedingungen Das Kartenmanagementsystem (Card Management System, CMS) veranlasst die Freigabe des AUT-Zertifikats einer egk beim OCSP-Responder. Kostenträger Betreiber des OCSP-Responders Versicherter meldet, dass er seine verloren gemeldete egk wieder gefunden hat Wiederaufnahme der Versicherung Neuausgabe einer Karte Alle lokalen Komponenten sind betriebsbereit und in fehlerfreiem Zustand. AUT-Zertifikat der egk ist im Status vorübergehend gesperrt Das AUT-Zertifikat der egk ist wieder freigeschaltet, die egk ist für die Online-Nutzung freigeschaltet Ablauf Aufruf Activate Certificate Aufruf des Kartenmanagementsystems an den OCSP- Responder. Als Ergebnis wird die Bestätigung durch den OCSP- Responder erwartet. Parameter: P1: Certificate (des Versicherten, welches freigeschaltet werden soll) gematik_cms Kartenmanagement_eGK.doc Seite 24 von 81

25 Rückmeldung Bestätigung Der OCSP-Responder bestätigt die Freigabe des Zertifikates Mengengerüst Anforderungen an andere Komponenten Keine genauen Informationen verfügbar! < 3% * 78,6 Mio. Versicherte pro Jahr, welche zuvor melden den Verlust, Diebstahl oder Defekt ihrer Versichertenkarte gemeldet haben + 6,5% - 8% * 78,6 Mio. pro Jahr (wegen Kassenwechsel) + < 78,6 Mio. Versicherte in 18 Monaten alle 5 Jahre (Annahme, da Zeitdauer für die Erstausgabe (Roll Out) der egk noch nicht festgelegt worden ist!) Keine 5.5 TUC_CM_003 egk-aut-zertifikat sperren (informativ) Dieser Anwendungsfall beschreibt die (endgültige) Sperrung eines egk-aut-zertifikats beim OCSP-Responder einer Certification Authority (CA) durch das CMS. Für den Fall, dass die Sperrung nicht durch das CMS gesteuert wird, ist dieses über den Vorgang zu informieren. Andernfalls muss das CMS den Prozess zur Sperrung eines egk- AUT-Zertifikates bei der CA bzw. dem OCSP-Responder der CA anstoßen. OCSP- Responder CMS 2 RevocateCertificate(Certificate) Bestätigung 1 Abbildung 5: Sequenzdiagramm TUC_CM_003 egk-aut-zertifikat sperren Tabelle 9: Ablaufbeschreibung TUC_CM_003 egk-aut-zertifikat sperren Kurzbeschreibung Initiierender Akteur Weitere Akteure Auslöser Das Kartenmanagementsystem (Card Management System, CMS) veranlasst die Sperrung des AUT-Zertifikats einer egk beim OCSP-Responder. Kostenträger Betreiber des OCSP-Responders Versicherter meldet den Verlust, Diebstahl oder Defekt seiner egk Beendigung der Versicherung Neue egk ist erstellt worden und ersetzt die alte gematik_cms Kartenmanagement_eGK.doc Seite 25 von 81

26 Vorbedingungen Nachbedingungen Alle lokalen Komponenten sind betriebsbereit und in fehlerfreiem Zustand. AUT-Zertifikat der egk ist gültig. Das AUT-Zertifikat der egk ist gesperrt, die egk ist für die weitere Online- Nutzung gesperrt. Ablauf Aufruf Rückmeldung 1) Revocate Certificate 2) Bestätigung Aufruf des Kartenmanagementsystems an den OCSP- Responder. Parameter: P1: Certificate (des Versicherten, welches gesperrt werden soll) Der OCSP-Responder bestätigt die Sperrung des AUT- Zertifikates Mengengerüst Ca. 3% * 78,6 Mio. Versicherte pro Jahr melden den Verlust, Diebstahl oder Defekt ihrer Versichertenkarte Anforderungen an andere Komponenten Keine 5.6 TUC_CM_011 Update Flag setzen (informativ) Für den Fall, dass ein Fachdienst bzw. das Kartenmanagementsystem ein Update auf einer egk durchführen möchte, hinterlegt dieser bzw. dieses diese Information an einer für diese egk zentralen Stelle und setzt ein Update Flag im so genannten Update Flag Service. Dieser Dienst bündelt somit den ggf. vorliegenden Aktualisierungsbedarf aller Fachdienste und des Kartenmanagementsystems. gematik_cms Kartenmanagement_eGK.doc Seite 26 von 81

27 UFS CMS 2 SetUpdateFlag(ICCSN,ServiceLocalization,UpdateID, UpdatePriority, ShortDescription) Bestätigung 1 Abbildung 6: Sequenzdiagramm TUC_CM_011 Update Flag setzen 3 Tabelle 10: Ablaufbeschreibung TUC_CM_011 Update Flag setzen Kurzbeschreibung Initiierender Akteur Weitere Akteure Auslöser Vorbedingungen Nachbedingungen Ein CMS, welches eine Aktualisierung einer egk durchführen möchte, sobald diese egk das nächste Mal innerhalb der Telematikinfrastruktur benutzt wird, setzt ein Update Flag im Update Flag Service (UFS). Kostenträger Betreiber eines Fachdienstes Betreiber des Update Flag Service Kostenträger bzw. Betreiber eines Fachdienstes möchte eine Aktualisierung der egk durchführen Alle lokalen Komponenten sind betriebsbereit und in fehlerfreiem Zustand. Das Kartenmanagementsystem bzw. der Fachdienst muss den UFS über eine definierte Verbindung ansprechen können. Notwendigkeit zur Aktualisierung einer egk wird im UFS angezeigt Ablauf Aufruf 1) SetUpdateFlag Aufruf des Kartenmanagementsystems bzw. des Fachdienstes an den UFS. Als Ergebnis wird die Bestätigung durch den UFS erwartet. Parameter: P1: ICCSN (Seriennummer der egk) P2: ServiceLocalization (Identifikation des Dienstes, hier: CMS) P3: UpdateID (Identifikation des Updates) 4 P4: UpdatePriority (Priorität des Updates) 5 P5: ShortDescription (Beschreibung des Updates) 3 In der Abbildung wird der Ablauf zum Setzen eines Update Flags durch das CMS dargestellt. Die Vorgehensweise für Fachdienste wie z. B. den VSDD ist identisch. 4 Da für eine Karte mehrere Updates vom gleichen Fachdienst vorliegen können, z. B. für unterschiedliche Anwendungen, wird jedes Update durch einen eigenen UpdateIdentifier gekennzeichnet gematik_cms Kartenmanagement_eGK.doc Seite 27 von 81

28 Rückmeldung 2) Bestätigung Der UFS bestätigt den Empfang des Update Flags Mengengerüst Anforderungen an andere Komponenten Beispiele zur Verwendung dieses Anwendungsfalles im Rahmen möglicher Geschäftsprozesse der Kostenträger sind in den Abschnitten B.1 und B.2 zu finden. 5.7 TUC_CM_012 Notwendigkeit für Aktualisierung prüfen Dieser Anwendungsfall beschreibt die Prüfung auf notwendige Updates der egk z. B. durch einen Fachdienst oder das Kartenmanagementsystem. Der Prozess ist grundsätzlich bei jedem Online-Einsatz 6 zu durchlaufen. Primärsystem Konnektor Broker Service UFS 1 CheckUpdates(ICCSN) 2 GetUpdateFlags(ICCSN) ListOfUpdateFlags,Receipt 3 5 GetUpdateFlags (ICCSN) ListOfUpdateFlags,Receipt 4 6 Pflicht-Updates extrahieren ListOfUpdateFlags,Receipt 7 Abbildung 7: Sequenzdiagramm TUC_CM_012 Notwendigkeit für Aktualisierung prüfen Tabelle 11: Ablaufbeschreibung TUC_CM_012 Notwendigkeit für Aktualisierung prüfen Kurzbeschreibung Initiierender Akteur Die Notwendigkeit zur Aktualisierung der egk wird geprüft. Primärsysteme (Praxisverwaltungs-, Krankenhausinformationssysteme) der 5 Die Durchführung eines Updates z. B. im Rahmen des Anwendungsfalles Perform Updates (s. Abschnitt 5.9) hängt ganz wesentlich von der Priorität des Updates (UpdatePriority) sowie den noch zu erstellenden Regelungen zwischen ärztlichen Leistungserbringern und Kostenträgern ab. Während Pflichtupdates (z. B. ein Update der Versichertenstammdaten) in jedem Fall durchgeführt werden müssen, können optionale Updates ggf. vom Leistungserbringer bzw. automatisch von dessen Primärsystem zurückgewiesen werden. 6 Eine feingranulare Festlegung, bei welchen Einsatzszenarien einer egk dieser Anwendungsfall zu durchlaufen ist, erfolgt außerhalb dieses Dokuments. gematik_cms Kartenmanagement_eGK.doc Seite 28 von 81

29 folgenden Gruppen: Ärzte/Arztpraxen Krankenpersonal/Krankenhäuser Zahnärzte/Zahnarztpraxen Psychotherapeuten/Psychotherapeutenpraxen (den Ärzten gleichgestellt) Weitere Akteure Auslöser Vorbedingungen Nachbedingungen Betreiber des Update Flag Service, Konnektor, Broker Zur Prüfung der Aktualität der egk sollen die im UFS abgelegten Update Flags ausgelesen werden. Alle lokalen Komponenten sind betriebsbereit und in fehlerfreiem Zustand. Der Konnektor muss den UFS über eine definierte Telematik-Verbindung ansprechen können. Eine C2C-Validierung ist erfolgt. Die ggf. notwendigen Updates werden zur Anzeige im Primärsystem bereitgestellt. Ablauf Aufruf 1) CheckUpdates Aufruf des Primärsystems an den Konnektor. Parameter: P1: ICCSN (Seriennummer der egk) Aufruf des Broker- Service 2) GetUpdateFlags Aufruf des Konnektors an den BrokerService Parameter: P1: ICCSN (Seriennummer der egk) Aufruf des Update Flag Service 3) GetUpdateFlags Aufruf des BrokerService an den UFS Parameter: P1: ICCSN (Seriennummer der egk) Rückmeldung an den BrokerService 4) Bestätigung Der Update Flag Service bestätigt dem BrokerService die Anfrage und gibt die Liste alle notwendigen Updates zurück. Parameter: P1: ListOfUpdateFlags P2: Quittung über die Anfrage des Leistungserbringers Rückmeldung an den Konnektor 5) Bestätigung Der BrokerService leitet die Antwort des UFS an den Konnektor weiter. Parameter: P1: ListOfUpdateFlags P2: Quittung über die Anfrage des Leistungserbringers gematik_cms Kartenmanagement_eGK.doc Seite 29 von 81

30 Bearbeitung im Konnektor 6) Pflicht- Updates extrahieren Der Konnektor durchsucht die Liste der Updates nach Pflicht-Updates und speichert diese intern für die weitere Verarbeitung. Rückmeldung an das Primärsystem Mengengerüst 7) Bestätigung Der Konnektor leitet die Antwort des BrokerService an das Primärsystem weiter. Parameter: P1: ListOfUpdateFlags P2: Quittung über die Anfrage des Leistungserbringers Keine Informationen verfügbar! Anforderungen an andere Komponenten Keine Beispiele zur Verwendung dieses Anwendungsfalles im Rahmen möglicher Geschäftsprozesse der Kostenträger sind in den Abschnitten B.1 und B.2 zu finden. 5.8 TUC_CM_013 Update Flag löschen (informativ) Nach der erfolgreichen Durchführung eines Updates sowie für den Fall, dass ein Update Flag nicht mehr benötigt wird, muss der Fachdienst bzw. das Kartenmanagementsystem sein zuvor gesetztes Update Flag wieder löschen. Die eindeutige Identifizierung des Flags wird dabei durch den UpdateID unterstützt. UFS CMS 2 DeleteUpdateFlag(ServiceLocalization,ICCSN,UpdateID) Bestätigung 1 Abbildung 8: Sequenzdiagramm TUC_CM_013 Update Flag löschen Tabelle 12: Ablaufbeschreibung TUC_CM_013 Update Flag löschen Kurzbeschreibung Initiierender Akteur Weitere Akteure Nach der erfolgreichen Durchführung oder Hinfälligkeit eines Updates wird das zugehörige Update Flag im UFS gelöscht. Kostenträger Betreiber eines Fachdienstes Betreiber des Update Flag Service gematik_cms Kartenmanagement_eGK.doc Seite 30 von 81

31 Auslöser Vorbedingungen Nachbedingungen Kostenträger bzw. Betreiber eines Fachdienstes möchte Update Flag löschen Alle lokalen Komponenten sind betriebsbereit und in fehlerfreiem Zustand. Das Kartenmanagementsystem bzw. der Fachdienst muss den UFS über eine definierte Verbindung ansprechen können. Notwendigkeit zur Aktualisierung einer egk wurde im UFS gelöscht. Ablauf Aufruf 1) Delete UpdateFlag Aufruf des Kartenmanagementsystems bzw. des Fachdienstes an den UFS. Als Ergebnis wird die Bestätigung durch den UFS erwartet. Parameter: P1: ServiceLocalization (Identifikation des Dienstes, welcher das Update durchführt, hier: CMS) P2: ICCSN (Seriennummer der egk) P3: UpdateID (Identifikation des Updates) Rückmeldung 2) Bestätigung Der UFS bestätigt das Löschen des Update Flags Mengengerüst Keine Informationen verfügbar! Anforderungen an andere Komponenten Keine Ein Beispiel zur Verwendung dieses Anwendungsfalles ist in Abschnitt B.1 zu finden. 5.9 TUC_CM_021 egk aktualisieren Dieser Anwendungsfall beschreibt die Kommunikation zwischen egk und Fachdienst im Rahmen der Durchführung eines Updates der egk, nachdem z. B. durch Abruf der Update Flags (s. Abschnitt 5.7) oder im Rahmen des Anwendungsmanagements z. B. beim Arzt bzw. am ekiosk die Notwendigkeit zur Kontaktierung eines Fachdienstes erkannt wurde. In diesem Zusammenhang ist zu erwähnen, dass der im nachfolgenden Sequenzdiagramm beschriebene Aufruf Perform Updates lediglich einen möglichen Trigger für die Durchführung eines Updates darstellt. Daneben existieren weitere Möglichkeiten z. B. im Rahmen der Prüfung der egk-aut-zertifikate bei negativem Prüfergebnis (s. [gemspec_kon]) sowie im Rahmen des Anwendungsfalles VSD lesen (s.a. [gemfa_vsdm]) Dazu gibt der Konnektor nach dem Verbindungsaufbau zum Fachdienst bzw. Kartenmanagementsystem die Kontrolle über die weitere Kommunikation an den Fachdienst bzw. das Kartenmanagementsystem ab. Der Dienst kommuniziert dann über einen transparenten Kanal direkt mit der Karte. Dementsprechend obliegt es allein dem Kartenmanagementsystem (dem Fachdienst), ggf. notwendige Zugriffsbedingungen für den Zugriff auf Dateien und Verzeichnisse der egk durch Aufbereitung geeigneter Kommandofolgen zu erfüllen (Bsp. Secure Messaging mit Trusted Channel, s. a. Anhang A). Zur Optimierung der Kommunikation ist vorgesehen, dass das Kartenmanagementsystem mehrere Kartenkommandos gebün- gematik_cms Kartenmanagement_eGK.doc Seite 31 von 81