gemSpec_FM_AMTS_V1.4.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Fachmodul AMTS

    

     

      
Version
      
1.4.0
     
     

      
Revision
      
848168
     
     

      
Stand
      
15.05.2019
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FM_AMTS
     
    

Dokumentinformationen

Änderungen zur Vorversion

Die Änderungen zur Vorversion beruhen auf der Änderungsliste P18.1 und sind gelb markiert.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Fachmodul AMTS in der Stufe A der Fachanwendung eMP/AMTS-Datenmanagement.

Das Fachmodul setzt die Anwendungsfälle in der LE-Umgebung um. Die mobilen Szenarien werden zu einem späteren Zeitpunkt in einem gesonderten Dokument spezifiziert.

1.2 Dokumentenlandschaft

Die Abbildung Abb_AMTS_FM_001 Dokumentenlandkarte AMTS zeigt schematisch die Dokumentenlandschaft, in welche sich die Fachmodulspezifikation AMTS und alle weiteren Dokumente, die die Fachanwendung AMTS beschreiben, eingliedern. Parallel dazu sind, entsprechend den Dokumentenebenen in der gematik, die Spezifikationstypen der TI-Plattform aufgeführt, die das Projekt AMTS und insbesondere das vorliegende Dokument beeinflussen.

Abbildung 1: Abb_AMTS_FM_001 Dokumentenlandkarte AMTS

Die Abbildung stellt nicht die vollständige Dokumentenhierarchie oder den Trace der An-forderungen dar.

1.3 Zielgruppe

Das Dokument richtet sich an Hersteller des Produkttyps Fachmodul AMTS sowie Hersteller und Anbieter von Produkttypen, die hierzu eine Schnittstelle besitzen.

Wenn im Nachfolgenden Begriffe wie Versicherter, Arzt etc. benutzt werden, sind damit gleichzeitig auch immer die femininen Formen Versicherte, Ärztin, etc. gemeint.

1.4 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.5 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang A5).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps Fachmodul AMTS verzeichnet.

Nicht Bestandteil des vorliegenden Dokumentes bzw. der vorliegenden Version sind die Festlegungen zu Folgestufen der Fachanwendung eMP/AMTS.

1.6 Methodik

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.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen der ID und der Textmarke angeführten Inhalte.

Zugriffe auf die eGK werden mithilfe der im Konnektor vorhandenen Funktionalität durchgeführt. Nach der in [gemSpec_Kon] erläuterten Sprechweise muss sich das Fachmodul AMTS an der Außenschnittstelle so verhalten, als würde es die entsprechenden TUCs zum Zugriff auf den AMTS-Container der eGK verwenden.

1.6.1 Hinweis auf offene Punkte

Das Kapitel wird in einer späteren Version des Dokumentes ergänzt.

2 Systemüberblick

Das Fachmodul AMTS ist eine Softwarekomponente des Konnektors, welche die Anwendungsprozesse der Fachanwendung eMP/AMTS-Datenmanagement umsetzt. Es bietet Clientsystemen in der stationären LE-Umgebung  seine Funktionalität an und nutzt dazu die vom Konnektor bereitgestellten Basisdienste der TI-Plattform. Die Systemzerlegung der Fachanwendung eMP/AMTS-Datenmanagement in Komponenten und Produkttypen sowie deren Verteilung auf Produkttypen der Telematikinfrastruktur ist in [gemSysL_AMTS#2] definiert.

3 Systemkontext

3.1 Akteure und Rollen

Mit dem Fachmodul AMTS  interagiert ausschließlich das Clientsystem in der LE-Umgebung.

Das Fachmodul muss sicherstellen, dass nur im jeweiligen Nutzungskontext (Mandant, Arbeitsplatz, Sitzung) berechtigte Clientsysteme zur Ausführung von Operationen autorisiert werden.

Fachliche Akteure (Arzt, Apotheker, usw.) rufen mittels des Clientsystems die Operationen des Fachmoduls AMTS auf, um auf die eGK zuzugreifen. Über ihre Rolle, die technisch durch das Zugriffsprofil ihrer Smartcard repräsentiert wird, erhalten die Akteure die benötigte Berechtigung zum Zugriff.

3.2 Nachbarsysteme

Das Fachmodul ist integraler Bestandteil des Konnektors. Auf der logischen Ebene sind das Clientsystem und der Anwendungskonnektor als einbettende Komponente Nachbarsysteme.

4 Zerlegung des Produkttyps

Eine weitere Untergliederung der Aufbaustruktur des Fachmoduls AMTS ist nicht erforderlich.

5 Übergreifende Festlegungen

5.1 Technologien und Standards

Als Schnittstellentechnologie wird SOAP verwendet. Um Interoperabilität zwischen verschiedenen SOAP-Implementierungen [SOAP1.1] zu gewährleisten, erfolgt die technische Umsetzung der Schnittstellen konform zum WS-I Basic Profile in der Version 1.2 [Basic-Profile1.2].

Die Schnittstellen des Fachmoduls AMTS werden in Form von WSDL-Dokumenten [WSDL1.1] und XML-Schemas definiert. Die aus WSDL resultierenden Nachrichten müssen SOAP in der Version 1.1 entsprechen und die Übertragung mittels HTTP in der Version 1.1 erfolgen.

Die WSDL-Dateien und XML-Schemadateien müssen mit dem vorliegenden Dokument zur Verfügung gestellt werden, um eine einfache Implementierung zu gewährleisten und eine maschinelle Prüfung der spezifizierten Elemente zu ermöglichen. Die in den WSDLs verwendete Kodierungsmethode der SOAP-Nachrichten muss „wrapped document/literal“ sein, um Interoperabilität zu gewährleisten.

Das Clientsystem muss alle Requests in UTF-8 kodieren. Diese Festlegungen gelten nur für die eigentliche SOAP-Nachricht. Sind in der SOAP-Nachricht base64-kodierte XML-Elemente vorhanden, so können diese XML-Elemente andere Zeichenkodierungen aufweisen.

Für die Fehlerbehandlung gelten die Festlegungen von [gemSpec_Kon#3.5.2].

5.2 Transportsicherung

Die betriebliche Steuerung erfolgt über den relevanten Konfigurationsparameter des Konnektors (ANCL_TLS_MANDANTORY). Ist dieser gesetzt, so ist für die Kommunikation zwischen Clientsystem und Konnektor (und damit auch dem Fachmodul AMTS) ein TLS-gesicherter Kanal zu verwenden (vgl. [gemSpec_Kon#3.4.1]). Die Kommunikation des Clientsystems mit dem Fachmodul AMTS sollte aus Sicherheitsgründen verschlüsselt erfolgen. Falls diese Kommunikation unverschlüsselt erfolgt, übernimmt der Leistungserbringer die Verantwortung für die Sicherstellung der vertraulichen Übertragung (vgl. auch [gemSpec_Kon#2.7]).

Der Konnektor bietet zudem im Rahmen der Transportsicherung die Möglichkeit, eine Authentifizierung des Clientsystems zu erzwingen. Standardmäßig ist der relevante Konfigurationsparameter des Konnektors (ANCL_CAUT_MANDANTORY) so gesetzt, dass Clientsysteme sich gegenüber dem Konnektor (und damit auch dem Fachmodul AMTS) authentifizieren müssen. Über den Konfigurationsparameter ANCL_CAUT_MODE kann der Authentifizierungsmodus konfiguriert werden (vgl. [gemSpec_Kon#3.4.1]).

5.3 Versionierung

Das Fachmodul AMTS ist integraler Bestandteil des Konnektors und Teil von dessen Firmware-Version. Bezüglich der Selbstauskunft gelten die Festlegungen in [gemSpec_Kon#TIP1-A_4812].

5.4 Fehlerbehandlung

Treten bei der Ausführung einer Operation des Fachmoduls Fehler auf, die zum Abbruch der Operation führen, so werden diese an das aufrufende System über eine SOAP-Fault-Nachricht gemeldet. Im Erfolgsfalle oder bei Fehlern, die nicht zum Abbruch der Operation führen, wird ein Status-Element gemäß [gemSpec_Kon#3.5.2] zurückgegeben.

Für das Fehlermanagement gelten neben den hier aufgeführten spezifischen Anforderungen für das Fachmodul AMTS die Anforderungen aus Kapitel 3 der übergreifenden Spezifikation [gemSpec_OM#3].

5.5 Protokollierung

5.5.1 Protokollierung im Fachmodul AMTS (Logging)

Das Fachmodul soll Protokolldateien im Konnektor ablegen, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren, die Performance zu analysieren und interne Abläufe zu beobachten. Dazu stellt der Konnektor den TUC_KON_271 „Schreibe Protokolleintrag“ des Protokollierungsdienstes zur Verfügung (siehe [gemSpec_Kon#4.1.10.4.1]). Um die Anforderungen an den Datenschutz zu gewährleisten, dürfen weder medizinische noch personenbezogene Daten geschrieben werden.

Die Protokolldateien folgen einem einheitlichen Format, das vom Hersteller festgelegt und dokumentiert wird. Es muss geeignet sein, um automatische Auswertungen mit wenig Aufwand durch Dritte zu ermöglichen. Ein Vorbild ist das Weblog des Apache Webservers. Um mehrere Protokolleinträge zu korrelieren, soll bei Aufruf einer Operation, sprich Aufruf einer Schnittstelle, eine Vorgangsnummer gebildet werden. Diese Vorgangsnummer wird in allen Protokolleinträgen dieses Operationsaufrufs genutzt. Die Vorgangsnummer wird vom Konnektor pseudozufällig gebildet.

Der Zugriff auf Protokolldateien muss auf autorisierte Personen durch angemessene technische oder organisatorische Maßnahmen eingeschränkt werden. Die Zugriffseinschränkungen werden über Mechanismen des Konnektors umgesetzt. Die Logdateien können auf ein separates Speichermedium kopiert werden (siehe [gemSpec_Kon#TIP1-A_4716]).

Der TUC_KON_271 „Schreibe Protokolleintrag“ unterscheidet drei verschiedene Logging-Protokolle:

• Fachmodulprotokoll (eventType = „Op“): Das Fachmodulprotokoll soll die internen Ausführungsschritte enthalten, die einen Einblick in den internen Ablauf für Administratoren, Betreiber und Tester ermöglichen und die Analyse von Fehlersituationen erleichtern.
• Sicherheitsprotokoll (eventType = „Sec“): Das Sicherheitsprotokoll dient der Protokollierung von sicherheitsrelevanten Fehlern und Ereignissen.
• Performanceprotokoll (eventType = „Perf“): Das Performanceprotokoll dient dem Vergleich der tatsächlichen Ausführungszeiten des Fachmoduls AMTS und den Vorgaben aus [gemSpec_Perf].

Abhängig von der Schwere (Severity), werden die Einträge der drei Protokolle in folgende Klassen eingeteilt:

Tabelle 1: Tab_AMTS_FM_019 Einteilung der Protokolleinträge in Abhängigkeit der Schwere

Hinweis: Der Parameter „Schwere“ wird für einen Eintrag im Performanceprotokoll nicht verwendet.

5.5.2 Zugriffsprotokolleinträge auf der eGK

Die Zugriffsprotokolleinträge werden mittels TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ des Kartendienstes erstellt (siehe [gemSpec_Kon#4.1.5]).

Tabelle 7: Tab_AMTS_FM_001 Werte der Zugriffsprotokolleinträge auf der eGK G2.0

Um in einem normalen Behandlungsverlauf (1. von eGK Lesen 2. Behandlung oder Medikament ausgeben 3. auf eGK schreiben) eine Mehrfach-PIN-Eingabe zu vermeiden, ist es für eGK G2.0 notwendig, ausschließlich bei der ersten Freischaltung der eGK einen Log-Eintrag für den gesamten Behandlungsverlauf, der mit dieser Freischaltung abläuft, zu schreiben. Die Anpassungen der eGK G2.1 beheben diese Einschränkung.

Tabelle 8: Tab_AMTS_FM_020 Werte der Zugriffsprotokolleinträge auf der eGK G2.1

5.6 Konfiguration

Tabelle 9: Tab_AMTS_FM_002 Konfigurationsparameter des Fachmodules AMTS

Die Einsicht von Protokolldateien und Administration der Konfigurationsparameter erfolgen über die Managementschnittstelle des Konnektors (vgl. [gemSpec_Kon#4.3.4]).

5.7 Berechtigungen

5.7.1 Clientsysteme

Das Fachmodul AMTS muss sicherstellen, dass nur im jeweiligen Nutzungskontext (Mandant, Arbeitsplatz, Sitzung) berechtigte Clientsysteme zur Ausführung der Operationen des Fachmoduls autorisiert werden.

Zu diesem Zweck bietet der Konnektor den Fachmodulen den internen TUC_KON_000 „Prüfe Zugriffsberechtigung“ (vgl. [gemSpec_Kon#4.1.1.4.1]).

5.7.2 Fachliche Rollen

Die Akteure, die in der LE-Umgebung über das Clientsystem die Operationen des Fachmoduls AMTS aufrufen, erhalten mittels ihrer fachlichen Rolle, die technisch durch das Zugriffsprofil ihrer Smartcard repräsentiert wird, die Autorisierung zum Zugriff auf die eGK. Tabelle [gemSpec_PKI#Tab_PKI_254] beschreibt die fachlichen Rollen und die zugehörige Flaglist.

5.7.3 Umsetzung der Berechtigungen

Das Objektsystem der eGK, im Speziellen die Zugriffsbedingungen in Form von benötigten CV-Flags (C2C) und PIN-Eingaben, setzt den größten Teil der Zugriffsberechtigungen um (vgl. [gemSpec_eGK_ObjSys#5.4.15]). Alle ergänzenden Anforderungen werden in diesem Dokument getroffen.

5.8 Skalierbarkeit

Anforderungen zur Skalierbarkeit und Performance für die Fachanwendung eMP/AMTS-Datenmanagement sind im Dokument [gemSpec_Perf] enthalten.

5.9 Verwendung des Dienstverzeichnisdienstes

Das Fachmodul AMTS muss seine für die Clientsysteme vorgesehen Services mittels des Dienstverzeichnisdienstes des Konnektors verfügbar machen. Zur Registrierung kann der interne TUC_KON_041 „Einbringen der Endpunktinformationen während der Bootup-Phase“ verwendet werden.

Tabelle 10: Tab_AMTS_FM_004 Service-Information für AMTSService (Umsetzung der Schnittstelle I_AMTS_Management)

5.10 Nachnutzung der persönlichen Versichertenstammdaten

Die persönlichen Versichertenstammdaten der Fachanwendung VSDM werden durch die Fachanwendung eMP/AMTS-Datenmanagement in der Stufe A nicht nachgenutzt, sondern redundant in der Datei EF.AMTS gespeichert.

6 Funktionsmerkmale

Das Kapitel enthält die vollständige Beschreibung der Funktionsmerkmale, welche das Fachmodul AMTS den Clientsystemen und anderen Fachmodulen anbietet. Das methodische Vorgehen der Spezifikation gliedert sich in drei Schritte, die sich in der Kapitelstruktur widerspiegeln:

• Dienste (technische Schnittstelle): Hier wird die technische Schnittstellenbeschreibung der SOAP-Web-Services inklusive ihrer Operationen erläutert, welche das Fachmodul AMTS externen Komponenten und Systemen anbietet.

Entwickler von Clientsystemen und Spezifikationsautoren anderer Fachmodule finden hier alle für sie relevanten Festlegungen.

• Operationen (Semantik der Schnittstelle): Der Abschnitt enthält eine semantische Beschreibung der zuvor definierten Operationen und Parameter. Er gibt eine im Vergleich zu den technischen Methodensignaturen im XML-Format leichter lesbare, aber inhaltlich tiefergehende, Erläuterung.
• Umsetzung (Außenverhalten der Operationen): Dieses Unterkapitel enthält alle normativen Anforderungen, welche die Funktionalität des Fachmoduls AMTS als Black-Box beschreiben. Die Gliederung lehnt sich an die extern angebotenen Operationen an und wird um übergreifende Anforderungen ergänzt. Die Fokussierung auf das Verhalten der Außenschnittstelle des Fachmoduls führt dazu, dass z.B. bestimmte Aufrufe im Konnektor (TUCs) nur informativ vorgegeben werden und nicht auf die Herkunft der Parameter eingegangen wird. Auch sind die Abläufe nur noch indirekt durch die Zusammenfassung aller für eine Operation relevanter Anforderungen sichtbar^{(Die Aktivitätsdiagramme aus dem systemspezifischen Konzept eMP/AMTS-Datenmanagement werden allerdings zur besseren Lesbarkeit in dieses Dokument übernommen.)}. Daraus folgt ein maximaler Freiheitsgrad für die Umsetzung.

Der Teil des Kapitels richtet sich in erster Linie an die Auftragnehmer zur Implementierung des Fachmoduls im Konnektor.

6.1 Schnittstellen des Produkttyps

Eindeutig spezifizierte Schnittstellen an den Außengrenzen der Telematikinfrastruktur sind Grundlage für die Interoperabilität zwischen der TI und den angeschlossenen Systemen. Produkte verschiedener Hersteller und Anbieter müssen die spezifizierten Schnittstellen nutzen, um die geforderte Funktionalität und Interoperabilität zu gewährleisten. Dieses Unterkapitel spezifiziert die Schnittstellen des Fachmodules AMTS, die von den Clientsystemen  zum Lesen und Schreiben des eMP/AMTS-Datensatzes genutzt werden.

Das Systemspezifische Konzept eMP/AMTS [gemSysL_AMTS_A] gibt für das Fachmodul AMTS folgende Schnittstelle vor:

• I_AMTS_Management wird als externe Schnittstelle von den Clientsystemen benutzt und wird daher analog den Schnittstellen anderer Fachanwendung via SOAP umgesetzt. Die Umsetzung erfolgt durch AMTS_Service.

6.1.1 AMTS_Service

Der Web Service AMTS_Service implementiert die in der Systemlösung AMTS aufgezeigte Schnittstelle I_AMTS_Management. Der Service darf ausschließlich von den Clientsystemen in der LE-Umgebung genutzt werden.

Tabelle #: Tab_AMTS_FM_005 Beschreibung des Web Services AMTS_Service

6.2 Außenschnittstelle – Operationen

6.2.1 ReadMP

Tabelle 11: Tab_AMTS_FM_007 Schnittstellenbeschreibung der Operation ReadMP

Name	ReadMP
Beschreibung	Die Daten werden entpackt und an das aufrufende System übergeben.
Aufrufparameter
	Name	Beschreibung
	EhcHandle	Verweis auf die eGK gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], von der die eMP/AMTS-Daten gelesen werden sollen
	HpcHandle	Verweis auf LE-Karte (HBA/SMC-B) gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], die zum Zugriff auf die eGK verwendet werden soll
	Context	Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] bzw. [ConnectorContext.xsd] MandantId ClientSystemId WorkplaceId UserId
	UsingPIN	PIN-Objekt, das zur Freischaltung der eGK genutzt werden soll (AMTS-PIN oder Vertreter-PIN)
Rückgabeparameter
	Name	Beschreibung
	Status	Status nach [gemSpec_Kon#3.5.2]
	MPData	Von der eGK gelesene und bearbeitete eMP/AMTS-Daten nach dem Informationsmodell AMTS
	EGKValid	Kennzeichen, ob die eGK gültig ist DF.HCA nicht gesperrt Offline-Prüfung  gültig Online-Prüfung  gültig oder nicht ermittelbar
	EGKUsage	Nutzungsgrad des Speicherplatzes von EF.AMTS in Prozent

6.2.2 WriteMP

Tabelle 12: Tab_AMTS_FM_008 Schnittstellenbeschreibung der Operation WriteMP

Name	WriteMP
Beschreibung	Die Operation WriteMP schreibt die vom aufrufenden System übergebenen eMP/AMTS-Daten in die Datei EF.AMTS auf der eGK. Die Daten werden zuvor validiert, in das Speicherformat transformiert und komprimiert.
Aufrufparameter
	Name	Beschreibung
	EhcHandle	Verweis auf die eGK gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], auf die eMP/AMTS-Daten geschrieben werden sollen
	HpcHandle	Verweis auf LE-Karte (HBA/SMC-B) gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], die zum Zugriff auf die eGK verwendet werden soll
	Context	Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] bzw. [ConnectorContext.xsd] MandantId ClientSystemId WorkplaceId UserId
	MPData	Die auf der eGK zu speichernden eMP/AMTS-Daten nach dem Informationsmodell AMTS
	UsingPIN	PIN-Objekt, das zur Freischaltung der eGK genutzt werden soll (AMTS-PIN oder Vertreter-PIN)
Rückgabeparameter
	Name	Beschreibung
	Status	Status nach [gemSpec_Kon#3.5.2]
	EGKValid	Kennzeichen, ob die eGK gültig ist DF.HCA nicht gesperrt Offline-Prüfung  gültig Online-Prüfung  gültig oder nicht ermittelbar

6.2.3 ReadConsent

Tabelle 13: Tab_AMTS_FM_009 Schnittstellenbeschreibung der Operation ReadConsent

Name	ReadConsent
Beschreibung	Die Operation ReadConsent liest die Einwilligungsdaten aus der Datei EF.AMTS von der eGK und gibt sie an das aufrufende System zurück.
Aufrufparameter
	Name	Beschreibung
	EhcHandle	Verweis auf die eGK gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], von der die Einwilligungsdaten gelesen werden sollen
	HpcHandle	Verweis auf LE-Karte (HBA/SMC-B) gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], die zum Zugriff auf die eGK verwendet werden soll
	Context	Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] bzw. [ConnectorContext.xsd] MandantId ClientSystemId WorkplaceId UserId
Rückgabeparameter
	Name	Beschreibung
	Status	Status nach [gemSpec_Kon#3.5.2]
	ConsentData	Auf der eGK gespeicherte Einwilligungsdaten der Fachanwendung eMP/AMTS-Datenmanagement
	EGKValid	Kennzeichen, ob die eGK gültig ist DF.HCA nicht gesperrt Offline-Prüfung  gültig Online-Prüfung  gültig oder nicht ermittelbar

6.2.4 WriteConsent

Tabelle 14: Tab_AMTS_FM_010 Schnittstellenbeschreibung der Operation WriteConsent

Name	WriteConsent
Beschreibung	Die Operation WriteConsent schreibt die vom aufrufenden System übergebenen Einwilligungsdaten in die Datei EF.AMTS auf die eGK.
Aufrufparameter
	Name	Beschreibung
	EhcHandle	Verweis auf die eGK gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], auf die die Einwilligungsdaten geschrieben werden sollen
	HpcHandle	Verweis auf LE-Karte (HBA/SMC-B) gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], die zum Zugriff auf die eGK verwendet werden soll
	Context	Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] bzw. [ConnectorContext.xsd] MandantId ClientSystemId WorkplaceId UserId
	ConsentData	Vom aufrufenden System übergebenen Einwilligungsdaten, die auf die eGK geschrieben werden soll
Rückgabeparameter
	Name	Beschreibung
	Status	Status nach [gemSpec_Kon#3.5.2]
	EGKValid	Kennzeichen, ob die eGK gültig ist DF.HCA nicht gesperrt Offline-Prüfung  gültig Online-Prüfung  gültig oder nicht ermittelbar

6.2.5 DeleteConsent

Tabelle 15: Tab_AMTS_FM_011 Schnittstellenbeschreibung der Operation DeleteConsent

Name	DeleteConsent
Beschreibung	Die Operation DeleteConsent löscht die Einwilligungsdaten und die eMP/AMTS-Daten (eMP/AMTS-Datensatz) von der eGK.
Aufrufparameter
	Name	Beschreibung
	EhcHandle	Verweis auf die eGK gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], von der der eMP/AMTS-Datensatz gelöscht werden soll
	HpcHandle	Verweis auf LE-Karte (HBA/SMC-B) gemäß [gemSpec_Kon#4.1.1.1] bzw. [ConnectorCommon.xsd], die zum Zugriff auf die eGK verwendet werden soll
	Context	Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] bzw. [ConnectorContext.xsd] MandantId ClientSystemId WorkplaceId UserId
Rückgabeparameter
	Name	Beschreibung
	Status	Status nach [gemSpec_Kon#3.5.2]
	EGKValid	Kennzeichen, ob die eGK gültig ist DF.HCA nicht gesperrt Offline-Prüfung  gültig Online-Prüfung  gültig oder nicht ermittelbar

6.3 Umsetzung

Die im Systemspezifischen Konzept [gemSysL_AMTS_A] aufgezeigte Operation GrantApproval wird auf Spezifikationsebene nicht separat umgesetzt, sondern ist Bestandteil der übergreifenden Anforderungen. Der entsprechende Anwendungsfall „Einverständnis erteilen“ kann nur im Kontext anderer Anwendungsfälle existieren. Daher gibt es für diese Operation auch keine Außenschnittstelle am Fachmodul.

6.3.1 Übergreifende Anforderungen

Die meisten Operationen erfordern zur Durchführung sowohl eine eGK, als auch einen HBA bzw. eine SMC-B. Sollte eine benötigte Karte nicht gesteckt sein (oder z.B. ein als Parameter übergebenes Karten-Handle ungültig), bricht das Fachmodul AMTS die aufgerufene Operation ab.

Alle Operationen werden bei Aufruf auf Vollständigkeit hinsichtlich ihrer Parameter überprüft.

Die Prüfung der Zugriffsberechtigung auf vom Konnektor verwaltete externe Ressourcen (z.B. Kartenterminal mit Slots) erfolgt anhand der vom Clientsystem übergebenen Parameter. Sie werden mit der durch den Administrator im Zugriffsberechtigungsdienst abgelegten Konfiguration der Umgebung abgeglichen. Die Abläufe werden durch TUC_KON_000 “Prüfe Zugriffsberechtigung” in [gemSpec_Kon] beschrieben.

Die Fachanwendung eMP/AMTS benötigt eine eGK der 2. Generation oder höher. [gemSpec_Kon#4.1.5] beschreibt den Kartendienst des Konnektors und enthält alle TUCs für Lese- und Schreibzugriffe auf die eGK. Werte für die benötigten Parameter des TUCs finden sich in den Dokumenten [gemSpec_eGK_ObjSys#5.4.15] und [gemSpec_eGK_Fach_AMTS].

Um bei fehlerbedingten Abbrüchen (z. B. vorzeitiges Entfernen der eGK) das korrekte Funktionieren der Anwendung zu ermöglichen, wird der jeweilige Transaktionsstatus auf der eGK gespeichert. Die dafür verwendete Speicherstruktur ist in [gemSpec_eGK_Fach_AMTS] dokumentiert.

Die Notwendigkeit für eine PIN-Abfrage über ein Kartenterminal ergibt sich aus Objektsystemspezifikation der eGK. Diese kennt zwei PIN-Objekte zur Freischaltung des Containers EF.AMTS. Das Fachmodul muss vor dem Zugriff wissen, welches der beiden PIN-Objekte benutzt werden soll. Diese Information wird den Operationen ReadMP und WriteMP als Parameter von dem aufrufenden System übergeben (vgl. Kapitel 6.3.4 und 6.3.5). Die MRPIN.HOME darf  nicht verwendet werden.

Zur Sicherstellung, dass nur Daten des Karteninhabers auf die eGK gespeichert werden, wird bei einem Schreibzugriff die Versicherten-ID der übergebenen Daten mit der Versicherten-ID auf der eGK verglichen. Da bei einem Verzeichniswechsel auf der eGK G2.0 die erreichten Sicherheitszustände von PIN-Objekten zurückgesetzt werden, ist es für die Vermeidung unnötiger PIN-Eingaben zweckmäßig, die Versicherten-ID zu Beginn einer Operation auszulesen und zwischenzuspeichern. Die Anpassungen der eGK G2.1 beheben diese Einschränkung.

Bei deaktivierter Anwendung liefert TUC_KON_202 „LeseDatei“ den Fehlercode 4086 „Verzeichnis deaktiviert“ zurück.

Bei einem aktiven Ordner DF.HCA und im OCSP-Responder gesperrtem C.CH.AUT-Zertifikat liest die Fachanwendung zwar noch Daten von der eGK, verhindert aber das Schreiben. Wird z. B. bei einem Krankenkassenwechsel des Versicherten die alte eGK gesperrt, soll es dennoch möglich sein, die Daten zu Lesen und bei einem LE auf eine neue eGK zu übertragen. Außerdem ist das Löschen von Daten auf einer gesperrten Karte möglich.

Der Parameter EGKValid wird bei jeder Operation, die auf die eGK zugreift, zurückgegeben, d.h. es findet mindestens einmal pro Kartensitzung eine vollständige Prüfung der Gültigkeit, wie in TUC_KON_018 beschrieben, statt.

Die Operation des Fachmoduls AMTS können auf zwei verschiedene Arten vorzeitig beendet werden. Das Ziehen der eGK kann im Gegensatz zum kontrollierten Abbruch über das Terminal zu einem Datenverlust führen.

Der Vertreter darf nicht auf die Einwilligung des Versicherten zugreifen und daher die Operation ReadConsent nicht ausführen. Allerdings muss er grundsätzlich die Berechtigung zum Lesen der Einwilligung im Objektsystem haben, damit das Fachmodul vor dem Lesen oder Schreiben der eMP/AMTS-Daten die Einwilligung auf Vorhandensein kontrollieren kann. Die Anforderung erscheint etwas widersprüchlich, lässt sich aber durch das Fachmodul AMTS umsetzen, da die Einwilligung beim Lesen der eMP/AMTS-Daten nicht an das Clientsystem zurückgegeben wird.

6.3.2 Allgemeine Ausgaben am Kartenterminal

Tabelle 16: Tab_AMTS_FM_013 Terminalanzeigen für PIN-Eingaben

6.3.3 GrantApproval

Abbildung Abb_AMTS_FM_002 stellt informativ den Ablauf der Operation GrantApproval dar.

Abbildung 2: Abb_AMTS_FM_002 Ablaufdiagramm der Operation GrantApproval

Der Zugriff auf EF.AMTS erfordert erstens die Freischaltung der eGK mithilfe von PIN und C2C und zweitens das Vorhandensein einer nichtleeren Einwilligung.

6.3.4 ReadMP

Abbildung Abb_AMTS_FM_003 stellt informativ den Ablauf der Operation ReadMP dar.

Abbildung 3: Abb_AMTS_FM_003 Ablaufdiagramm der Operation ReadMP

Das exakte Format und die Komprimierungsanforderungen befinden sich in [gemSpec_eGK_Fach_AMTS].

6.3.5 WriteMP

Abbildung Abb_AMTS_FM_004 stellt informativ den Ablauf der Operation WriteMP dar.

Abbildung 4: Abb_AMTS_FM_004 Ablaufdiagramm der Operation WriteMP

Hinweis: Das exakte Format und die Komprimierungsanforderungen befinden sich in [gemSpec_eGK_Fach_AMTS].

6.3.6 ReadConsent

Abbildung Abb_AMTS_FM_005 stellt informativ den Ablauf der Operation ReadConsent dar.

Abbildung 5: Abb_AMTS_FM_005 Ablaufdiagramm der Operation ReadConsent

Hinweis: Hierbei ist das in [gemSpec_eGK_Fach_AMTS] beschriebene Speicherformatzu berücksichtigen.

6.3.7 WriteConsent

Abbildung Abb_AMTS_FM_006 stellt informativ den Ablauf der Operation WriteConsent dar.

Abbildung 6: Abb_AMTS_FM_006 Ablaufdiagramm der Operation WriteConsent

6.3.8 DeleteConsent

Abbildung Abb_AMTS_FM_007 stellt informativ den Ablauf der Operation DeleteConsent dar.

Abbildung 7 : Abb_AMTS_FM_007 Ablaufdiagramm der Operation DeleteConsent

Tabelle 17: Tab_AMTS_FM_015 Sicherheitsabfrage bei DeleteContent

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Glossar

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis

7.5 Referenzierte Dokumente

7.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 jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

7.5.2 – Weitere Dokumente

8 Anhang B – Zusatzinformationen

8.1 Fehlermeldungen

Die nachfolgende Tabelle Tab_AMTS_FM_199 enthält die spezifischen Fehlercodes und -beschreibungen gemäß [gemSpec_OM] der Fachanwendung eMP/AMTS-Datenmanagement.

Tabelle 18: Tab_AMTS_FM_199 Fehlermeldungen des Fachmoduls AMTS