Elektronische Gesundheitskarte und Telematikinfrastruktur

Systemspezifisches Konzept eMP/AMTS-Datenmanagement
(Stufe A)

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
26.10.2018
     
     

      
Status
      
Freigegeben für interne QS
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSysL_AMTS_A
     
    

Dokumentinformationen

Änderungen zur Vorversion

Änderungen aus der Änderungsliste P15.9

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das vorliegende Dokument Systemspezifisches Konzept eMP/AMTS Stufe A beschreibt die Umsetzung der Fachanwendung eMP/AMTS-Datenmanagement^{(Für den Begriff eMP/AMTS-Datenmanagement wird nachfolgend auch einfach eMP/AMTS benutzt.)} auf Systemebene. Die Funktionalität der Anwendung wird in insgesamt drei Stufen zur Umsetzung aufgeteilt, wovon dieses Konzept die erste Stufe darstellt. Die Anforderungen werden in übergreifenden Spezifikationen und Produkttypspezifikationen im Verlauf des Projekts AMTS weiter verfeinert und ergänzt.

1.2 Dokumentenlandschaft

Die Abbildung Abb_AMTS_SysL_001 Dokumentenlandkarte AMTS zeigt schematisch die Dokumentenlandschaft, in welche sich das systemspezifische Konzept eMP/AMTS und alle weiteren Dokumente, die die Fachanwendung 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_SysL_001 Dokumentenlandkarte AMTS

Die Abbildung stellt nicht die vollständige Dokumentenhierarchie oder den Trace der Anforderungen dar.

1.3 Zielgruppe

Das Dokument richtet sich auf der einen Seite an Anwendungsarchitekten und Spezifikationsautoren, auf der anderen Seite an die Hersteller, der benötigten zentralen und dezentralen Komponenten für die Fachanwendung eMP/AMTS.

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.

Wichtiger 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

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

Die mobilen Szenarien werden nicht mit Hilfe des in [gemSpec_MobKT] beschriebenen mobilen Kartenterminals umgesetzt. Stattdessen wird dazu ein mobiles Endgerät verwendet, dessen Spezifikation sich aktuell in der Erarbeitung befindet.

Die Fachanwendung eMP/AMTS unterstützt sowohl eGK G2.0 ohne abschaltbare AMTS-PIN^{(Die Begriffe AMTS-PIN und eMP/AMTS-PIN werden synonym verwendet.)} als auch eGK G2.1 mit abschaltbarer AMTS-PIN. Die Einführung der Anwendungen des Versicherten ist zeitlich von eMP/AMTS entkoppelt.

1.6 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 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 innerhalb der Textmarken angeführten Inhalte.

1.7 Hinweis auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:

Offene Punkte, benötigte Entscheidungen etc.

2 Systemzerlegung

Das folgende Kapitel zeigt die Einteilung der Fachanwendung eMP/AMTS (Stufe A) in logische Komponenten und ordnet sie den Architekturschichten der TI-Plattform und ihren angrenzenden Systemen zu. Die Schnittstellen und Operationen zur Umsetzung der Anwendungsfälle werden ebenfalls beschrieben.

2.1 Systemüberblick

Abbildung 2: Abb_AMTS_SysL_002 Systemzerlegung AMTS

Die Systemzerlegung in Abbildung Abb_AMTS_SysL_002 Systemzerlegung AMTS stellt die wichtigsten, an der Fachanwendung eMP/AMTS beteiligten Systeme und Produkttypen auf Konzeptebene dar. Das Fachmodul AMTS und die TI-App AMTS werden nachfolgend auch als AMTS-Komponenten bezeichnet. In der LE-Umgebung (mobil, ortsgebunden) kapseln sie, sofern erforderlich, die Logik der AMTS-Anwendungsfälle^{(Einige Anwendungsfälle können auch vollständig mit den Leistungsmerkmalen der TI-Plattform abgebildet werden.)}.

Für die  AdV-Umgebungen Kostenträger und @home ist die KTR-AdV mit den Bestandteilen AdV-Server und AdV-App vorgesehen. Die KTR-AdV enthält AMTS-spezifische Teile, die in Kapitel 4.3 beschrieben sind^{(Es findet kein direkter Anforderungsfluss statt, da das in der Methodik der Dokumentenerstellung auf dieser Ebene nicht vorgesehen ist. Fachliche Anforderungen werden nach Absprache mit dem Projekt AdV direkt in die AdV-Dokumente integriert und in diesem Konzept lediglich informativ referenziert.)}. Eine Anpassung des AdV-Servers wird in Stufe A der Fachanwendung AMTS allerdings nicht benötigt, da sich alle Anwendungsfälle in diesem Kontext lokal auf dem Client-Gerät mithilfe der AdV-App umsetzen lassen.

Die Fachanwendung eMP/AMTS nutzt in Stufe A ausschließlich die eGK als Datenspeicher des eMP/AMTS-Datensatzes.

Weitere Anforderungen zu den Speicherstrukturen der eGK allgemein und der spezifischen Dateistruktur der Fachanwendung eMP/AMTS-Datenmanagement sind in den Dokumenten [gemSpec_Karten_Fach_TIP], [gemSpec_eGK_Fach_AMTS] und [gemSpec_eGK_ObjSys] zu finden.

Zusätzlich ermittelt das Projekt AMTS alle Anforderungen an die Clientsysteme und fasst diese in einem Implementierungsleitfaden zusammen.

2.2 Schnittstellen

Die AMTS-Komponenten stellen den Clientsystemen  ihre Funktionalität über Schnittstellen und Operationen zur Verfügung. Hierbei wird zunächst eine konzeptionelle Trennung durchgeführt, um in späteren Stufen der Fachanwendung eMP/AMTS leicht Änderungen vornehmen zu können^{(In der Spezifikation kann es aber durchaus wieder eine gemeinsame Implementierung geben, falls dies sinnvoll und möglich ist.)}.

Abb_AMTS_SysL_003 Schnittstellen der AMTS-Komponenten zeigt die von den AMTS-Komponenten bereitgestellten Schnittstellen.

AMTS-A_2003 - SysL AMTS: Schnittstellen der AMTS-Komponenten

Das Fachmodul AMTS und die TI-App AMTS MÜSSEN die Schnittstellen nach Abbildung Abb_AMTS_SysL_003 Schnittstellen der AMTS-Komponenten exklusiv für die dargestellten Abnehmer anbieten.

Abbildung 3: Abb_AMTS_SysL_003 Schnittstellen der AMTS-Komponenten

[<=]

Für die AdV-Umgebungen @home und KTR muss die Fachanwendung eMP/AMTS keine spezifische Funktionalität anbieten, weil alle Anwendungsfälle mit Funktionen des AdV-Servers abgedeckt werden sollen.

GrantApproval wird von den Clientsystemen nie direkt über eine Schnittstelle, sondern immer nur durch andere Anwendungsfälle aufgerufen. Die Schnittstellen I_AMTS_Management und I_AMTS_Management_mobil stellen die gleichen Operationen in ihrer spezifischen Umgebung zur Verfügung.

Tabelle Tab_AMTS_SysL_001 Operationen der Komponentenschnittstellen (Außenansicht der AMTS-Komponenten) stellt damit die Außenansicht der Fachanwendung eMP/AMTS dar. Die inhaltliche Beschreibung und die Zuordnung der Anwendungsfälle folgen in Kapitel 4.

3 Informationsmodell

Das Informationsmodell der Fachanwendung eMP/AMTS wird in den Spezifikationsdokumenten erläutert (vgl. AMTS-A_2636 und AMTS-A_2228 in [gemSpec_Info_AMTS]).

4 Anwendungsfälle

Die Anwendungsfälle der Fachanwendung eMP/AMTS-Datenmanagement werden in diesem Dokument nach den initiierenden Akteuren getrennt:

• Leistungserbringer (ortsgebunden und mobil) in Kapitel 4.2
• Versicherter ( KTR-AdV, @home) in Kapitel 4.3

Zuvor wird in Kapitel 4.1 auf die allgemeinen technischen Bedingungen und Voraussetzungen sowie übergreifende Anforderungen eingegangen.

Tabelle Tab_AMTS_SysL_002 Übersicht und Umsetzung der AMTS-Anwendungsfälle listet alle Anwendungsfälle der Fachanwendung eMP/AMTS und zeigt sowohl die Überschneidungen zwischen der LE- und den AdV-Umgebungen als auch die Operation zur konzeptionellen Umsetzung. Einige Anwendungsfälle können vollständig durch die Leistungsmerkmale der TI-Plattform oder die Funktionen der AdV abgebildet werden und erfordern keine Detaillierung durch eine Operation in diesem Dokument.

Tabelle 2: Tab_AMTS_SysL_002 Übersicht und Umsetzung der AMTS-Anwendungsfälle

4.1 Vorbedingungen

Damit die Anwendungsfälle ausgeführt werden können, müssen neben den AMTS-Komponenten weitere dezentrale Komponenten und externe Systeme betriebsbereit sein:

• Übergreifend
• eGK des Versicherten
• LE-Umgebung (ortsgebunden)
• HBA des Leistungserbringers bzw. SMC-B der Leistungserbringerorganisation
• Konnektor, eHealth-KT
• Primärsystem
• LE-Umgebung (mobil)
• HBA des Leistungserbringers bzw. SMC-B der Leistungserbringerorganisation
• mobEG^{(Vgl. Kapitel 1.5)}

Die Vorbedingungen für die AdV-Anwendungsfälle liegen im Verantwortungsbereich des Projektes AdV.

4.1.1 Übergreifende Anforderungen

Zugriffe auf den eMP/AMTS-Datensatz werden zur Einsicht durch den Versicherten auf der eGK protokolliert. Zum Zwecke der Übersichtlichkeit erstellt die Fachanwendung eMP/AMTS pro Ausführung eines Anwendungsfalls genau einen Eintrag im eGK-Log. Darüber hinaus findet eine detaillierte Protokollierung der Anwendungsfälle in den Ausführungsumgebungen der AMTS-Komponenten, insbesondere beim Auftreten von Fehlern, statt. Diese dienen zur Problemanalyse durch den Administrator oder LE. Der Aufbau der Systemmeldungen wird durch das übergeordnete Konzept zum einheitlichen Fehlermanagement bestimmt und die jeweiligen Inhalte durch die Spezifikation definiert.

Da das Protokoll der eGK nur 50 Einträge umfasst, sollen doppelte Lese- und Schreibzugriffe innerhalb einer Behandlung, etwa zum Zwecke der Korrektur eines Tippfehlers, nicht geloggt werden.

In einigen Spezialfällen ist es sinnvoll, Daten auch von einer ungültigen eGK lesen zu können, beispielsweise beim Kartentausch oder Wechsel der Krankenkasse. Voraussetzung dafür ist allerdings, dass der HCA-Container auf der eGK nicht gesperrt wurde (sondern lediglich das Zertifikat ungültig oder gesperrt ist).

Der häufigste Versorgungsprozess in einer Praxis beinhaltet zuerst das Lesen des Medikationsplans und abschließend seine Aktualisierung. Falls die eGK beim Schreibvorgang noch im Kartenterminal steckt, soll der Versicherte seine PIN nicht erneut eingeben müssen.

4.1.2 Berechtigungen

4.1.3 Mapping Anwendungsfallaktivitäten zu TI-Plattform

Tabelle 5: Tab_AMTS_SysL_006 Mapping der AF-Aktivitäten zu Aufrufen der TI-Plattform

Tabelle Tab_AMTS_SysL_006 Mapping der AF-Aktivitäten zu Aufrufen der TI-Plattform führt nur jene Aktivitäten auf, für deren Umsetzung Funktionalität der TI-Plattform benötigt wird. Die Komprimierung von Daten ist beispielsweise nicht enthalten, da sie direkt im Fachmodul stattfindet.

4.2 Anwendungsfälle im Versorgungsprozess

4.2.1 AF.A.01 – Einverständnis erteilen

4.2.1.1 Übersicht

Dieser Anwendungsfall beschreibt die Erteilung des fallbezogenen Einverständnisses durch den Versicherten oder seinen Vertreter gegenüber einem Leistungserbringer zum Zugriff auf die eMP/AMTS-Daten. Diese Aktivität kann nicht direkt über eine Schnittstelle der AMTS-Komponenten aufgerufen werden, sondern läuft im Kontext anderer Anwendungsfälle, wie z.B. AF.A.02 eMP/AMTS-Daten von eGK lesen, ab.

Tabelle 6: Tab_AMTS_SysL_007 Übersicht AF.A.01 Einverständnis erteilen

4.2.1.2 Umsetzung

Die Operation GrantApproval setzt die in der TI stattfindende Abläufe des Anwendungsfalls AF.A.01 Einverständnis erteilen um.

4.2.1.2.1 Ablaufdiagramm

In einigen anderen Anwendungsfällen wird z.B. ebenfalls der Einwilligungsdatensatz benötigt. Dieser muss dann in einem optimierten Ablauf nur einmal von der Fachwendung gelesen werden.

Abbildung 4: Abb_AMTS_SysL_004 Ablaufdiagramm der Operation GrantApproval

Weil Daten auch bei gesperrtem AUT-Zertifikat gelesen werden sollen, findet bei der Erteilung des Einverständnisses keine Prüfung der technischen Gültigkeit statt. Lesevorgänge werden immer versucht und brechen im Falle eines gesperrten HCA-Containers mit Fehlermeldung durch die TI-Plattform ab. Die Fachanwendung schreibt auch für das Lesen einer ungültigen eGK ein Zugriffsprotokoll.

Die Berechtigungstabellen müssen im Ablauf der Operation GrantApproval berücksichtigt werden.

4.2.1.2.2 Parameter

Der Ausgangsparameter „Fehlermeldung (optional)“ ist hier und in allen anderen Operationen als Platzhalter zu verstehen, der in den nachfolgenden Spezifikationsdokumenten mit Inhalten zu füllen ist. Übergreifende Vorgaben zur Beschreibung enthält [gemSpec_OM].

4.2.1.2.3 Erfolgsbedingungen

– keine zusätzlichen, anwendungsfallspezifischen Anforderungen –

4.2.2 AF.A.02 – eMP/AMTS-Daten von eGK lesen

4.2.2.1 Übersicht

Dieser Anwendungsfall beschreibt das Lesen der eMP/AMTS-Daten von dem Speichermedium zur weiteren Verwendung durch den Leistungserbringer oder den Versicherten.

Tabelle 8: Tab_AMTS_SysL_009 Übersicht AF.A.02 eMP/AMTS-Daten von eGK lesen

4.2.2.2 Umsetzung

Die Operation ReadMP setzt die in der TI stattfindende Abläufe des Anwendungsfalls AF.A.02 eMP/AMTS-Daten von eGK lesen um.

4.2.2.2.1 Ablaufdiagramm

Der Schritt zur Prüfung einer Einwilligung aus AF.A.01 kann in der Operation ReadMP übersprungen werden: Wenn der Vorgang „eMP/AMTS-Daten vom Speichermedium lesen“ erfolgreich von einer AMTS-Komponente durchgeführt werden kann, muss es auch eine Einwilligung geben.

Abbildung 5: Abb_AMTS_SysL_005 Ablaufdiagramm der Operation ReadMP

4.2.2.2.2 Parameter

4.2.2.2.3 Erfolgsbedingungen

4.2.3 AF.A.03 – eMP/AMTS-Daten auf eGK schreiben

4.2.3.1 Übersicht

Dieser Anwendungsfall beschreibt das Schreiben der eMP/AMTS-Daten auf das Speichermedium. Da die Daten immer vollständig, wie vom Clientsystem übergeben, geschrieben werden, deckt der Anwendungsfall gleichzeitig auch das Ändern oder Löschen von Medikationseinträgen ab.

Tabelle 11: Tab_AMTS_SysL_012 Übersicht AF.A.03 eMP/AMTS-Daten auf eGK schreiben

4.2.3.2 Umsetzung

Die Operation WriteMP setzt die in der TI stattfindenden Abläufe des Anwendungsfalls AF.A.03 eMP/AMTS-Daten auf eGK schreiben um.

4.2.3.2.1 Ablaufdiagramm

Abbildung 6: Abb_AMTS_SysL_006 Ablaufdiagramm der Operation WriteMP

Der LE kann mit dem Schreiben eines leeren Datensatzes auch die gesamten eMP/AMTS-Daten löschen.

Die Versicherten-ID (die ersten zehn Stellen aus dem unveränderbaren Teil der KVNR) wird aus den Versichertenstammdaten (EF.PD) extrahiert, um sie mit jener des auf die eGK zu schreibenden eMP/AMTS-Datensatzes abzugleichen. So wird sichergestellt, dass der Versicherte der eGK identisch ist mit dem Versicherten des eMP/AMTS-Datensatzes, bevor letzterer auf die eGK geschrieben wird. Eine Signatur des eMP/AMTS-Datensatzes erfolgt nicht.

4.2.3.2.2 Parameter

4.2.3.2.3 Erfolgsbedingungen

Zusätzlich zu den übergreifenden Erfolgsbedingungen gelten:

4.2.4 AF.A.50 – Einwilligung anzeigen

4.2.4.1 Übersicht

Dieser Anwendungsfall beschreibt das Anzeigen der Einwilligung zur Teilnahme am eMP/AMTS-Datenmanagement in der LE- oder AdV-Umgebung.

Tabelle 13: Tab_AMTS_SysL_014 Übersicht AF.A.50 Einwilligung anzeigen

4.2.4.2 Umsetzung

Die Operation ReadConsent setzt die in der TI stattfindenden Abläufe des Anwendungsfalls AF.A.50 Einwilligung anzeigen um.

4.2.4.2.1 Ablaufdiagramm

Abbildung 7: Abb_AMTS_SysL_007 Ablaufdiagramm der Operation ReadConsent

4.2.4.2.2 Parameter

4.2.4.2.3 Erfolgsbedingungen

– keine zusätzlichen, anwendungsfallspezifischen Anforderungen –

4.2.5 AF.A.51 – Einwilligung erteilen

4.2.5.1 Übersicht

Dieser Anwendungsfall beschreibt die Erteilung der Einwilligung durch den Versicherten zur Teilnahme am eMP/AMTS-Datenmanagement.

Tabelle 15: Tab_AMTS_SysL_016 Übersicht AF.A.51 Einwilligung erteilen

4.2.5.2 Umsetzung

Die Operation WriteConsent setzt die in der TI stattfindenden Abläufe des Anwendungsfalls AF.A.51 Einwilligung erteilen um.

4.2.5.2.1 Ablaufdiagram

Abbildung 8: Abb_AMTS_SysL_008 Ablaufdiagramm der Operation WriteConsent

4.2.5.2.2 Parameter

4.2.5.2.3 Erfolgsbedingungen

Zusätzlich zu den übergreifenden Erfolgsbedingungen gelten:

4.2.6 AF.A.52 – Einwilligung widerrufen

4.2.6.1 Übersicht

Dieser Anwendungsfall beschreibt den Widerruf der Einwilligung durch den Versicherten zur Teilnahme am eMP/AMTS-Datenmanagement.

Tabelle 17: Tab_AMTS_SysL_018 Übersicht AF.A.52 Einwilligung widerrufen

4.2.6.2 Umsetzung

Die Operation DeleteConsent setzt die in der TI stattfindenden Abläufe des Anwendungsfalls AF.A.52 Einwilligung widerrufen um.

4.2.6.2.1 Ablaufdiagramm

Abbildung 9: Abb_AMTS_SysL_009 Ablaufdiagramm der Operation DeleteConsent

4.2.6.2.2 Parameter

4.2.6.2.3 Erfolgsbedingungen

4.2.7 AF.A.53 – Vertreter-PIN ändern

Die Funktionalität zur Änderung des Vertreter-PIN-Objekts wird als Leistung der TI-Plattform zur Verfügung gestellt und kann direkt von den jeweiligen Clientsystemen aufgerufen werden.

Entsprechend dazu erfolgt der Aufruf zur Änderung der Vertreter-PIN in der LE-Umgebung durch die Primärsysteme. Schnittstellen, Parameter und die Vorbedingungen werden im Implementierungsleitfaden beschrieben.

4.2.8 AF.A.54 – Datenübertragung bei Kartentausch durchführen

Der Anwendungsfall beschreibt den Prozess der Datenübertragung von einer alten auf eine neue eGK, bedingt beispielsweise durch den Ablauf des AUT-Zertifikats.

Da die TI-Plattform in dem für die Stufe A geplanten Ausbau nicht über das Leistungsmerkmal des Daten- und Berechtigungserhalts bei Kartentausch verfügt, wird diese Funktionalität durch die Fachanwendungen, zumindest temporär, selbst durchgeführt. Eine anwendungsübergreifende Lösung durch die TI-Plattform kann diese Projektimplementierung später ersetzen.

Grob gliedert sich der Anwendungsfall, unabhängig von der Umgebung, in die folgenden Schritte:

1. alte eGK stecken
2. Einwilligung und eMP/AMTS lesen
3. neue eGK stecken
4. Einwilligung und eMP/AMTS schreiben
5. alte eGK stecken
6. Einwilligung widerrufen

In der LE-Umgebung übernimmt das Clientsystem die Aufgabe der Datenübertragung. Der genaue Ablauf ist zu finden unter [gemILF_PS_AMTS#6.3.10 - Datenübertragung bei Kartentausch AF.A.54]. Hierbei werden die bereits vorhandenen Operationen des Fachmoduls AMTS zum Lese- und Schreibzugriff auf die Einwilligung und eMP/AMTS-Daten verwendet, d.h. eine Erweiterung der Schnittstelle I_AMTS_Management ist nicht notwendig.

Tabelle 19: Tab_AMTS_SysL_020 Übersicht AF.A.54 – Datenübertragung bei Kartentausch durchführen (LE-Umgebung)

4.2.9 AF.A.62 – eMP/AMTS-PIN aktivieren

Die Funktionalität der Aktivierung von PIN-Objekten (vgl. [gemSpec_COS#14.6.3 Enable Verification Requirement]) wird als Leistung der TI-Plattform zur Verfügung gestellt und kann direkt von den jeweiligen Clientsystemen aufgerufen werden.

Entsprechend dazu erfolgt der Aufruf zur Aktivierung des PIN-Objektes in der LE-Umgebung durch die Primärsysteme. Schnittstellen, Parameter und die Vorbedingungen werden im Implementierungsleitfaden beschrieben.

4.2.10 AF.A.63 – eMP/AMTS-PIN deaktivieren

Die Funktionalität der Deaktivierung von PIN-Objekten (vgl. [gemSpec_COS#14.6.2 Disable Verification Requirement]) wird als Leistung der TI-Plattform zur Verfügung gestellt und kann direkt von den jeweiligen Clientsystemen aufgerufen werden.

Entsprechend dazu erfolgt der Aufruf zur Deaktivierung des PIN-Objektes in der LE-Umgebung durch die Primärsysteme. Schnittstellen, Parameter und die Vorbedingungen werden im Implementierungsleitfaden beschrieben.

4.3 Anwendungsfälle in den AdV-Umgebungen

Die nachfolgenden Anwendungsfälle in den AdV-Umgebungen sind stark mit der Systemlösung des Projekts AdV [gemSysL_AdV] verbunden. Der startende Akteur ist immer der Versicherte, der sich in einer AdV-Umgebung (KTR-AdV-Terminal und @home) befindet und seine Rechte auf informationelle Selbstbestimmung in der Telematikinfrastruktur ohne einen Leistungserbringer wahrnehmen möchte. Während die fachlichen Anforderungen innerhalb des Projekts AMTS und anderen Fachprojekten erstellt und an das Projekt AdV weitergereicht werden, liegen die Gesamtarchitektur mit allen Komponenten der AdV und damit auch die Einstiegspunkte in die Prozessabläufe in dessen Verantwortungsbereich.

4.3.1 AF.A.04.03 Vertreter-PIN ändern

Der Anwendungsfall Vertreter-PIN ändern wird in den AdV-Umgebungen wie in der Abbildung Abb_AMTS_SysL_011 Umsetzung AF.A.04.03 Vertreter-PIN ändern in allen AdV-Umgebung und der Tabelle Tab_AMTS_SysL_022 Ablauf / Konfiguration von AdV-UC_01 in allen AdV-Umgebungen beschrieben, umgesetzt.

Abbildung 10: Abb_AMTS_SysL_011 Umsetzung AF.A.04.03 Vertreter-PIN ändern in allen AdV-Umgebungen

Tabelle 20: Tab_AMTS_SysL_022 Ablauf / Konfiguration von AdV-UC_01 in allen AdV-Umgebungen

4.3.2 Vertreter-PIN entsperren

Die Vertreter-PIN wird nach dreifacher Falscheingabe gesperrt. Zum Entsperren muss nicht eine PUK eingegeben werden wie etwa bei der PIN.CH, sondern lediglich die AMTS-PIN. Die Umsetzung erfolgt durch das Projekt AdV in [gemSysL_AdV].

4.3.3 AF.A.04.04 Protokolldaten zu eMP/AMTS anzeigen

Die Protokolldaten über Zugriffe auf die eGK werden von allen Fachanwendungen in die gleiche Datei auf der eGK geschrieben und können nur als Ganzes gelesen werden. Festlegungen zu deren Anzeige trifft das Projekt AdV.

4.3.4 AF.A.04.06 eMP/AMTS-Datensatz verbergen

Der Versicherte kann mit diesem Anwendungsfall die gesamte AMTS-Datei auf der eGK verbergen.

Er wird in den AdV-Umgebungen wie in der Abbildung Abb_AMTS_SysL_013 Umsetzung AF.A.04.06 eMP/AMTS-Datensatz verbergen in allen AdV-Umgebungen und der Tabelle Tab_AMTS_SysL_024 Ablauf / Konfiguration von AdV-UC_14 in allen AdV-Umgebungen beschrieben, umgesetzt.

Abbildung 11: Abb_AMTS_SysL_013 Umsetzung AF.A.04.06 eMP/AMTS-Datensatz verbergen in allen AdV-Umgebungen

Tabelle 21: Tab_AMTS_SysL_024 Ablauf / Konfiguration von AdV-UC_14 in allen AdV-Umgebungen

4.3.5 AF.A.04.07 eMP/AMTS-Datensatz sichtbar machen

Der Versicherte kann mit diesem Anwendungsfall eine verborgende AMTS-Datei auf der eGK wieder sichtbar machen.

Er wird in den AdV-Umgebungen wie in der Abbildung Abb_AMTS_SysL_014 Umsetzung AF.A.04.07 eMP/AMTS-Datensatz sichtbar machen in allen AdV-Umgebungen und der Tabelle Tab_AMTS_SysL_025 Ablauf / Konfiguration von AdV-UC_15 in allen AdV-Umgebungen beschrieben, umgesetzt.

Abbildung 12: Abb_AMTS_SysL_014 Umsetzung AF.A.04.07 eMP/AMTS-Datensatz sichtbar machen in allen AdV-Umgebungen

Tabelle 22: Tab_AMTS_SysL_025 Ablauf / Konfiguration von AdV-UC_15 in allen AdV-Umgebungen

4.3.6 AF.A.04.15 eMP/AMTS-PIN deaktivieren

Der Anwendungsfall AMTS-PIN deaktivieren wird in den AdV-Umgebungen wie in der Abbildung Abb_AMTS_SysL_015 Umsetzung AF.A.04.15 AMTS-PIN deaktivieren in allen AdV-Umgebungen und der Tabelle Tab_AMTS_SysL_026 Ablauf / Konfiguration von AdV-UC_04 in allen AdV-Umgebungen beschrieben, umgesetzt.

Abbildung 13: Abb_AMTS_SysL_015 Umsetzung AF.A.04.15 AMTS-PIN deaktivieren in allen AdV-Umgebungen

Tabelle 23: Tab_AMTS_SysL_026 Ablauf / Konfiguration von AdV-UC_04 in allen AdV-Umgebungen

4.3.7 AF.A.04.16 eMP/AMTS-PIN aktivieren

Der Anwendungsfall AMTS-PIN aktivieren wird in den AdV-Umgebungen wie in der Abbildung Abb_AMTS_SysL_016 Umsetzung AF.A.04.16 AMTS-PIN aktivieren in allen AdV-Umgebung und der Tabelle Tab_AMTS_SysL_027 Ablauf / Konfiguration von AdV-UC_03 in allen AdV-Umgebungen beschrieben, umgesetzt.

Abbildung 14: Abb_AMTS_SysL_016 Umsetzung AF.A.04.16 AMTS-PIN aktivieren in allen AdV-Umgebungen

Tabelle 24: Tab_AMTS_SysL_027 Ablauf / Konfiguration von AdV-UC_03 in allen AdV-Umgebungen

5 Nichtfunktionale Anforderungen(Vgl. Kapitel 1.7 Hinweis auf offene Punkte)

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

Weitere Begriffe werden in dem eigenständigen Dokument [gemGlossar] erläutert.

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

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

6.5.2 Weitere Dokumente