Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme –
elektronischer Medikationsplan/AMTS-Datenmanagement (Stufe A)

    

     

      
Version
      
1.7.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
12.11.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_PS_AMTS
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Hinweis zur Erstellung des Leitfadens

Der Leitfaden wurde mit freundlicher Unterstützung (Stellungnahme) der Verbände

• Bundesverband der Deutschen Apothekensoftwarehäuser (ADAS e. V.),
• Bundesverbandes Gesundheits-IT (bvitg e.V.) sowie dem
• Verband Deutscher Dentalsoftware Unternehmen (VDDS)

erstellt.

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Der Leitfaden definiert fachliche Anforderungen und gibt Handlungsanweisungen und
-empfehlungen, wie Anwendungssysteme in verschiedenen Anwendungsszenarien (Use Cases) die Prozesse des eMP/AMTS-Datenmanagements technisch und prozedural einbinden. Damit soll erreicht werden, dass ein hohes Maß an Daten- und Anwendungskonformität (und damit eine geringe Fehlerrate) und an Akzeptanz bei der Nutzung der Anwendung erzielt wird.

Daher beinhaltet der ILF

• die Beschreibung der Anwendung eMP/AMTS im Prozesskontext der Arztpraxis, des Krankenhaus, der Zahnarztpraxis, der psychotherapeutischen Praxis und der Apotheke,
• die Beschreibung der Anwendungsszenarien, die die Operationen an der Anwendungsschnittstelle des Fachmoduls eMP/AMTS nutzen,
• eine Definition zur erwarteten Handhabung des Anwendungssystems im Falle einer fehlerfreien und fehlerhaften Anbindung,
• die Anforderungen an die Primärsysteme zur konformen Erzeugung der eMP/AMTS-Daten und Überprüfung derselben,
• die vom BMP-Projekt geerbten Rahmenbedingungen bzw. referenziert somit auf diese, um den Rechtsanspruch des Versicherten nach § 31a SGB V sicherzustellen.

Damit definiert der Implementierungsleitfaden die minimale Konformanz, die die hierin betroffenen Primärsysteme erbringen müssen, unabhängig davon, ob sie nach § 31a SGB V zertifiziert oder konform sind, um für das eMP/AMTS-Datenmanagement konform zu sein.

1.2 Zielgruppe

Der Implementierungsleitfaden für eMP/AMTS-Datenmanagement richtet sich an Hersteller von Primärsystemen (Praxisverwaltungssystem, Krankenhausinformationssystem bzw. deren Anwendungskontext-spezifischen Subsysteme, Zahnarztsoftware, psychotherapeutische Primärsoftware, Apothekenverwaltungssystem) im Rahmen der Erprobung des Online-Rollout (2.1).

1.3 Geltungsbereich

Dieses Dokument enthält informative Anforderungen für Primärsysteme. 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

Der nachfolgende Leitfaden ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Leitfaden 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 des Leitfadens angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Dokumentenlandkarte AMTS

Das vorliegende Dokument ist Teil des Dokumentenpaketes eMP/AMTS und leitet sich von der Spezifikation des Fachmoduls AMTS ab, siehe Abbildung 1: Dokumentenlandkarte eMP/AMTS.

Abbildung 1: Dokumentenlandkarte eMP/AMTS

1.5 Abgrenzungen

Das Dokument beschreibt die Nutzung der Schnittstellen zum Fachmodul AMTS, zum Konnektor und die damit verbundenen Anwendungsfälle im Primärsystem. Darüber hinausgehende Anwendungsfälle, die sich nicht dieser Schnittstellen bedienen, sind nicht Bestandteil dieses Dokumentes.

Dieses Dokument verweist auf den Implementierungsleitfaden für Primärsysteme [gemILF_PS], welcher die Nutzung von Komponenten und Schnittstellen der Telematikinfrastruktur (z. B. Verbindungsaufbau zum Konnektor) durch Primärsysteme von Leistungserbringern beschreibt. Insbesondere für Entwickler von Primärsystemen sind die Grundlagen aus dem Leitfaden für die Schnittstellenimplementierung zur Telematikinfrastruktur unverzichtbar.

Der Fokus dieses Dokumentes liegt bei der Definition der fachlichen Anforderungen, der Beschreibung von Abläufen zur Verarbeitung der Datensätze der Fachanwendung eMP/AMTS im Primärsystem, deren Struktur das Informationsmodell eMP/AMTS spezifiziert, und dem Verständnis einer gemeinsamen Fachlogik. Beschreibungen der internen Abläufe der genannten Schnittstellen sind in der Spezifikation des Fachmoduls AMTS [gemSpec_FM_AMTS] und des Konnektors [gemSpec_Kon] zu finden. Anforderungen an andere Produkttypen sind nicht Bestandteil dieses Dokuments.

Nicht Gegenstand des Implementierungsleitfadens sind

• die Nutzung der eMP/ATMS-Daten in den Primärsystemen,
• mobile Szenarien,
• die Datenhaltung im Primärsystem,
• die Erfüllung des Rechtsanspruches des Versicherten nach § 31a SGB V (Erzeugung eines BMP-konformen Papierausdruckes),
• das Betreiben von eMP/AMTS in der AdV-Umgebung (Anwendungsumgebung des Versicherten),
• die Definition und Durchführung von AMTS-Prüfungen,
• Festlegungen der internen Geschäftsprozesse der Leistungserbringer,
• Verfahrenshinweise zur Weiterleitung von Nachrichten oder Fehlermeldungen an andere Systeme (z.B. AMTS-Prüfsysteme),
• Synchronisation der Dateninhalte mit den Anwendungen NDFM, VSDM, und sonstigen Anwendungen nach § 291a und
• die Archivierung der eMP/AMTS-Daten.

1.6 Methodik

1.6.1 Beschreibung von Anwendungsfällen

Im vorliegenden Implementierungsleitfaden werden in Kapitel 6 die einzelnen Anwendungsfälle der Fachanwendung eMP/AMTS im Primärsystem beschrieben und daraus Anforderungen abgeleitet. Die Abläufe der Anwendungsfälle verdeutlichen den Umgang mit den Operationen des Fachmoduls AMTS und des Konnektors. Ferner beschreiben sie die Verwendung und die Reihenfolge der Kommandos, über die das Primärsystem mit dem Kartenterminal die Datenübertragung steuert.

Die Beschreibung der Anwendungsfälle erfolgt nach folgendem Muster:

•     Beschreibung des Standardablaufs (Tabelle)
•     Beschreibung der Umsetzung des Standardablaufs (Tabelle)
•     Sequenzdiagramm (optional).

Die Tabellen zur Anwendungsfallbeschreibung beinhalten neben dem Namen eine Kurzbeschreibung und einen Standardablauf. Darüber hinaus werden Vor- und Nachbedingungen, Auslöser sowie fachliche Akteure angegeben.

Der Standardablauf beschreibt die Durchführung des Anwendungsfalls im Erfolgsfall und besteht aus nummerierten Aktivitäten. Die Umsetzung des Standardablaufs ist in der weiteren Tabelle ausführlicher erläutert. Allgemeine Vorgaben zur Fehlerbehandlung im Primärsystem und Verweise auf die generischen und spezifischen Fehlermeldungen des Fachmoduls AMTS sind im Kapitel 8.1 enthalten.

Sequenzdiagramme der Anwendungsfälle beinhalten neben der Darstellung des Standardablaufs auch Interaktionen des Primärsystems mit anderen Akteuren und Nachbarsystemen. Interne Prozesse der beteiligten Akteure und Nachbarsysteme werden nicht in den Diagrammen dargestellt. Diese Diagramme verdeutlichen den Nachrichtenaustausch zwischen dem Primärsystem und den von der Telematikinfrastruktur angebotenen Außenschnittstellen.

1.6.2 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

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

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=]  angeführten Inhalte.

Hinweise zur Nomenklatur:

Schnittstellen-, Operations-, Parameternamen oder XML-Elemente/-Attribute werden in nicht-proportionaler Schriftart dargestellt.

Beispiele werden hervorgehoben dargestellt. Bei der Auswertung der (informativen) Beispiele ist zu beachten, dass die zugrunde liegenden XML-Schemadateien und WSDLs versioniert sind und einem Releasemanagement unterliegen. Eine Orientierung über die an der Konnektorschnittstelle zu verwendenden Schemaversionen und Namensräume bietet [gemSpec_Kon#AnhD].

2 Systemüberblick und Kontext

2.1 Schnittstellen zur Telematikinfrastruktur

Dieser Implementierungsleitfaden beschreibt die Nutzung der Schnittstellen der dezentralen Umgebung der Telematikinfrastruktur (Fachmodul AMTS (Spezifikation Fachmodul AMTS [gemSpec_FM_AMTS]) und des Konnektors (Spezifikation Konnektor [gemSpec_Kon])) durch das Primärsystem von berechtigten Akteuren im Rahmen der Fachanwendung eMP/AMTS.

2.2 Akteure und Rollen

Akteure interagieren mit den in diesem Dokument vorgestellten Anwendungsfällen. Sie greifen mittels des Primärsystems auf eMP/AMTS-Daten, die sich auf der eGK des Versicherten befinden, und auf den Datenbestand des Primärsystems zu.

Berechtigte Akteure sind diejenigen Personen, die den Anwendungsfall erfolgreich durchführen können, für die Zugriffsrechte im Fachmodul AMTS definiert ist und evtl. von anderen Personen mit elektronischem Heilberufsausweis (HBA) autorisiert sind. Über ihre Rolle, die technisch durch das Zugriffsprofil ihrer Smartcard repräsentiert wird, erhalten die Akteure die benötigte Berechtigung zum Zugriff auf den eMP/AMTS-Datensatz der eGK.

Berechtigte Akteure können folgende sein: der Versicherte, der Vertreter des Versicherten, Ärzte, Zahnärzte, Mitarbeiter medizinischer Institution, Nicht-ärztlicher Psychotherapeut, Apotheker und Mitarbeiter Apotheke.

2.3 Beteiligte Systeme

Direkt vom Primärsystem erreichbare Systeme sind:

    Konnektor einschließlich Fachmodul AMTS

Das Primärsystem bedient sich als Clientsystem an den Außenschnittstellen des Fachmoduls AMTS und des Konnektors. Das Fachmodul AMTS ist integraler Bestandteil des Konnektors.

Mittels des Konnektors werden folgende Systeme bedient:

    Stationäres Kartenterminal

Das Primärsystem kann nicht direkt auf das stationäre Kartenterminal zugreifen, in dem die eGK des Versicherten steckt, sondern nur mittels des Fachmoduls AMTS bzw. des Konnektors. Somit stellt das stationäre Kartenterminal ein weiteres beteiligtes System dar, auf welches das Primärsystem nur mittelbar zugreifen kann, siehe [gemILF_PS].

3 Voraussetzungen

Es wird vorausgesetzt, dass das Primärsystem betriebsbereit ist. Dieses soll in der Lage sein, dem berechtigten Akteur die vollständige Nutzung der Fachanwendung eMP/AMTS zu gewährleisten. Um das zu erreichen, muss das Primärsystem folgende Voraussetzungen erfüllen:

• Verbindung zum Konnektor (HTTP oder HTTPS) ist aufgebaut,
• Informationen über verfügbare Dienste des Konnektors sind beschafft worden,
• Außenschnittstelle des Konnektors kann mittels des SOAP-Protokolls angesprochen werden,
• bestimmte Ereignisse wurden bei dem Ereignisdienst des Konnektors abonniert,
• Kontext von Karten ist erfahren oder abgefragt worden,
• Verfügbarkeit vorhandener Kartenterminals ist abgefragt worden,
• Leistungserbringer-Karte (HBA bzw. SMC-B) ist freigeschaltet,
• die Konfiguration (Parameter des Aufrufkontextes) von Primärsystem und Konnektor wurde aneinander angeglichen.

Im Folgenden werden diese Voraussetzungen grob beschrieben, es wird auf gematik-eigene Spezifikationen verwiesen, wo diese Voraussetzungen ausführlicher beschrieben sind. Diese Spezifikationen beinhalten auch nützliche Implementierungshilfen.

Das Primärsystem kommuniziert mit dem Konnektor auf Basis des HTTP-Protokolls. Für die sichere Datenübertragung zwischen dem Primärsystem und dem Konnektor kann Transport Layer Security (TLS) angewendet werden. Welche Transportsicherungsmethode bei dem Datenaustausch mit dem Konnektor angewendet werden kann und wie sich das Primärsystem gegenüber dem Konnektor authentisieren kann, ist in [gemILF_PS#4.1.1] beschrieben. Aus Sicherheitsgründen ist es bei der Kommunikation des Primärsystems mit dem Fachmodul AMTS und mit anderen Diensten des Konnektors zu empfehlen, die gesicherte Datenübertragung mittels TLS zu verwenden.

Die erste Verbindung wird zum Dienstverzeichnisdienst des Konnektors aufgebaut. Dabei wird der URL des Dienstverzeichnisdienstes verwendet, der bereits in der Primärsystemkonfiguration hinterlegt ist. Durch das Auslesen des Dienstverzeichnisdienstes erfährt das Primärsystem existierende Webservice-Endpunkte von weiteren Diensten des Konnektors, unter anderem auch über die Schnittstellen des Konnektors. Ausführliche Informationen und Implementierungshilfen zum Auslesen des Dienstverzeichnisdienstes sind in [gemILF_PS#4.1.2] zu finden.

Das Primärsystem kann die Schnittstellen nur über Webservice auf Basis SOAP nutzen. Das Primärsystem muss die Vorgaben zur Nutzung (WebService-Schnittstellen zum Konnektor [gemILF_PS#4.1.3]) (WebService-Schnittstellen zum Fachmodul AMTS [gemSpec_FM_AMTS#6.1.1]) von Webservice-Schnittstellen beachten.

Mittels des Systeminformationsdienstes (EventService) kann das Primärsystem konnektorspezifische Ereignisse zeitnah in einem Push-Mechanismus empfangen. Um diese Ereignisse überhaupt empfangen zu können, müssen bestimmte Ereignisse beim Systeminformationsdienst ([gemILF_PS#4.1.4]) abonniert werden. Das Primärsystem soll folgende, für die Fachanwendung eMP/AMTS relevante Ereignisse bei dem Systeminformationsdienst abonnieren:

Tabelle 1: Relevante Ereignisse für die Nutzung der Fachanwendung eMP/AMTS

Wird z. B. eine eGK in ein Kartenterminal gesteckt, sendet der Konnektor ein CARD/INSERTED-Ereignis an das angemeldete Primärsystem. Das Ereignis enthält Angaben zum Kartenterminal, in dem die Karte steckt, sowie das CardHandle zur eindeutigen Identifizierung der Karte während eines Steckzyklus. Das CardHandle dient bei weiteren Konnektoraufrufen zur Adressierung der Karte.

Dies ist die schnellste Möglichkeit, ein CardHandle einer Karte zu erlangen. Es gibt eine andere Möglichkeit ([gemILF_PS#4.2]) durch das Primärsystem Kartensitzungen aufzubauen. Dabei stellt das EventService dem Primärsystem entsprechende Operationen zur Nutzung bereit. Mit diesen Operationen können vorhandene Karten abgefragt und je nach Anwendungsfall dem Akteur zur Auswahl angeboten werden. Ferner kann das Primärsystem mittels der Operationen des EventService die dem Primärsystem zugeordneten Kartenterminals abfragen. Dies kann sinnvoll sein, falls die Verfügbarkeit der Kartenterminals im Betrieb durch das Primärsystem geprüft werden soll.

Für eine Nutzung der Fachanwendung eMP/AMTS wird vorausgesetzt, dass ein HBA oder eine SMC-B freigeschaltet (Freischaltung von Karten [gemILF_PS #4.1.5.3]) ist. Dies wird auch als „erhöhter Sicherheitszustand“ bezeichnet. Dieser ist in Abhängigkeit vom Anwendungsfall und vom Verwendungszweck der einzelnen Operationen der Fachanwendung eMP/AMTS erforderlich. Bei erstmaliger Benutzung der PIN.CH des HBA können sie sich noch im Transportstatus befinden. In diesem Fall kann das Primärsystem auf Anforderung des Akteurs den PIN-Status des HBA abfragen (Beschreibung von Operationen des Kartendienstes zur Abfrage des Kartenstatus und zur PIN-Änderung [gemSpec_Kon#4.1.5.5]) und die Änderung der PIN durchführen.

Eine PIN.CH-Initialisierung für eGK G2 ist nicht notwendig, da die Karte mit einer Echt-PIN an den Versicherten ausgeliefert wird.

Operationen des Konnektors verlangen vom Primärsystem die Übergabe eines Aufrufkontextes, der aus Angaben zum Mandant (MandantId), Arbeitsplatz (WorkplaceId) und Primärsystem (ClientSystemId) besteht. Die Identifikation des Benutzers (UserId) wird in dem Aufrufkontext bei der Beteiligung eines HBA angegeben.

Mittels dieser Parameter kann der Konnektor die Aufrufberechtigung des Primärsystems überprüfen. Diese Parameter sind im Primärsystem konfiguriert. In der Konfiguration lässt sich die Zuordnung zwischen Mandanten, Karten, Arbeitsplätzen und Kartenterminals verwalten sowie die eindeutige Zuordnung zwischen Heilberuflern und ihren UserIDs. Die Zuordnung dieser Daten wird auch im Konnektor administriert (Aufbau des Aufrufkontextes [gemILF_PS#3.3]) und sie muss der Konfiguration im Primärsystem entsprechen.

Für den Aufruf der Operation an der Außenschnittstelle des Fachmoduls AMTS bzw. des Konnektors wird vorausgesetzt, dass das Primärsystem in der Lage ist, den Aufrufkontext gemäß [gemILF_PS#3.3.1] aufzubauen und die Parameter dieses Aufrufkontextes mit entsprechenden Daten aus der eigenen Konfigurationsverwaltung zu befüllen.

Für die in Kapitel 5 beschriebenen Anwendungsprozesse und in Kapitel 6 beschriebenen Anwendungsfälle gelten übergreifende Vorbedingungen gemäß der Systemlösung eMP/AMTS ([gemSysL_AMTS#4.1]), dem Implementierungsleitfaden Primärsysteme [gemILF_PS], sowie die folgenden Vorbedingungen:

• Das Primärsystem ist betriebsbereit.
• Das Primärsystem kennt die Schnittstellen zur TI.
• Konfigurationseinheiten (Primärsystem, Mandant, Arbeitsplatz, Kartenterminals) des Primärsystems sind auch in der Konfiguration des Konnektors enthalten.
• Die berechtigte Karte (HBA bzw. SMC-B) ist freigeschaltet und steckt in einem durch das Primärsystem erreichbaren Kartenterminal.
• Der Akteur hat bereits die für den jeweiligen Anwendungsfall entsprechende Leistungserbringer-Karte (HBA bzw. SMC-B) selektiert und verwendet das CardHandle zur eindeutigen Identifizierung der Karte.
• Die durch das Zugriffsprofil der beteiligten Karte (HBA bzw. SMC-B) repräsentierte fachliche Rolle ist zur Ausführung der Operationen des Fachmoduls AMTS bzw. des Konnektors berechtigt.
• Das Primärsystem hat bereits Abonnements auf die relevanten Topics der Tabelle 1 beim Konnektor (Systeminformationsdienst) angemeldet.

4 Übergreifende Festlegungen

4.1 Berechtigungsregeln

Beim Zugriff auf den eMP/AMTS-Datensatz der eGK des Versicherten sind Berechtigungsregeln maßgeblich, die vom jeweiligen fachlichen Akteur abhängig sind. Die Berechtigungsregeln für einzelne Akteure (siehe Tabelle 2) werden über das Fachmodul AMTS gesteuert.

Tabelle 2: Tab_ILF_AMTS_028 Berechtigungsmatrix „Berechtigungen der Anwendung eMP/AMTS für Leistungserbringer“

Beschreibung: xA = Berechtigt nach Autorisierung durch den Versicherten; xVP = Berechtigt nach Autorisierung durch den Vertreter; (leer) = keine Berechtigung

Die Fachmodule im EHealth-Konnektor verwenden ausdifferenzierte Berechtigungsregeln zur Kontrolle der Zugriffe auf die medizinischen Daten der eGK. Die anwendungsspezifischen Implementierungsleitfäden machen hierzu detaillierte Vorgaben.

Auf Berufsgruppen bezogene Rollendefinitionen werden technisch in den Zugriffsregeln der SMC-Bs und HBA der jeweiligen Berufsgruppen abgebildet. Anhand dieser technischen Zugriffsregeln werden im Zuge der Card-to-Card-Authentisierung zwischen eGK einerseits und SMC-B bzw. HBA andererseits die Anwendung auf der eGK ggf. freigeschaltet.

Die Berechtigungen der SMC-Bs einer Berufsgruppe sind im Allgemeinen von den Berechtigungen der HBAs einer Berufsgruppe abgeleitet, weil sie ihre SMC-B selbst nutzen und die Heilberufler auch ihre Gehilfen im Allgemeinen dafür autorisieren können, auf die Anwendungen der eGK mit den gleichen Rechten zuzugreifen.

Eine Ausnahme hiervon liegt ausschließlich im Falle des Psychotherapeuten vor, der seine Gehilfen nicht komplett für die Zugriffsmöglichkeiten autorisieren darf, mit denen die SMC-B ausgestattet ist.

4.2 PIN-Handhabung

4.2.1 Einverständnis erteilen für den Zugriff auf eGK

Bei vorhandener Einwilligung kann der berechtigte Akteur  auf die eGK des Versicherten zugreifen, nachdem der Versicherte durch die PIN-Eingabe sein Einverständnis erklärt hat. Bei der Aufforderung des Versicherten oder des Vertreters des Versicherten, die entsprechende PIN am Kartenterminal einzugeben, kann der Versicherte oder dessen Vertreter selbst entscheiden, ob er dem Akteur den Zugriff auf seine eGK erteilen will. Durch diesen PIN-Schutzmechanismus wird verhindert, dass beliebige Akteure direkt auf die eMP/AMTS-Daten zugreifen können.

Im Falle einer abgeschalteten PIN kann der Zugriff direkt nach Stecken der eGK erfolgen.

Bei der Auslieferung der eGK G2 an die Versicherten verfügt die Karte über eine Echt-PIN und somit ist es nicht erforderlich die PIN.CH dieser Karte zu initialisieren.

Im Falle eines „zeitversetzten“ Schreibens der eMP/AMTS-Daten, also dann, wenn die eGK nach dem Lesen und noch vor dem eigentlichen Schreibvorgang aus dem Kartenterminal gezogen wird, muss trotz deaktivierter MRPIN.AMTS die Anwendung erneut freigeschaltet werden.

4.3 Verarbeitung der Ereignismeldungen

Fordert das Kartenterminal den Versicherten, den Vertreter des Versicherten oder den Arzt zur PIN-Eingabe auf, erhält das Primärsystem eine entsprechende Ereignismeldung vom Konnektor. Für den Erhalt dieser Ereignismeldung abonniert das Primärsystem Ereignisse (Topics) der Tabelle 1 bei dem Systeminformationsdienst des Konnektors.

Mittels der Ereignismeldungen meldet der Konnektor dem Primärsystem nicht nur die Aufforderung des Versicherten oder des Vertreter des Versicherten zur PIN Eingabe, sondern auch Informationen über den Status der Karte, die schon unmittelbar zum Zeitpunkt des Steckens zur Verfügung gestellt werden können. Um diese Informationen zeitnah zu empfangen, soll das Primärsystem die Anforderung [gemILF_PS#TIP1-A_4970] umsetzen.

4.4 Fehlersituation

Antwortet das Fachmodul AMTS oder der Konnektor mit einer Fehlermeldung, muss das Primärsystem diese Fehlermeldung verarbeiten und den Akteur über den Inhalt der Fehlermeldung informieren. Angaben zur Fehlerverarbeitung sind in Kapitel 8.1 enthalten.

5 Anwendungsprozesse

Dieses Kapitel beschreibt die Anwendungsprozesse der Fachanwendung eMP/AMTS entsprechend den Kontexten:

• ambulante Behandlung (AP.A.01),
• stationäre Behandlung (AP.A.02),
• zahnärztliche Behandlung (AP.A.03),
• Psychotherapeutische Behandlung (AP.A.04) und
• Arzneimittelabgabe in einer öffentlichen Apotheke (AP.A.05)

aus Sicht des berechtigten Akteurs bezüglich der Verarbeitung der eMP/AMTS-Daten des Versicherten im Primärsystem. Das Kapitel stellt Anforderungen an die Funktionalität des Primärsystems und gibt Implementierungshilfen.

5.1 Zusammenhang Anwendungsprozess – (regelhafter) Anwendungsfall

Für jeden Anwendungsprozess erfolgt eine Detaillierung mittels einer tabellarischen Beschreibung. Der Standardablauf einzelner Anwendungsprozesse ist durch ein Sequenzdiagramm dargestellt.

Abbildung 2: Übersicht über alle Anwendungsprozesse mit den jeweils aufzurufenden Anwendungsfällen

5.2 Anforderungen an alle Systeme

Für alle Anwendungsprozesse (ambulante Behandlung, stationäre Behandlung, zahnärztliche Behandlung, psychotherapeutische Behandlung und Arzneimittelabgaben in der öffentlichen Apotheke) gelten die folgenden Anforderungen für die Erstellung von eMP/AMTS-Daten.

Kategorie eMP/AMTS-Daten

Kategorie Letzter eMP/AMTS-Aktualisierung

Kategorie Medikationseintrag

Kategorie Ausdruck – Transformation BMP

Kategorie Neuanlage

Hinweis: Der vorliegende Implementierungsleitfaden gilt nur für Stufe A, die folgenden Ausbaustufen sind hier nicht beschreiben.

Kategorie Kompatibilität – auch für nicht BMP-Einträge

Hinweis: Abwärtskompatibilität zum BMP, um einen maximal dreiseitigen Ausdruck erzeugen zu können.

Kategorie Codierung

Kategorie Datenvolumen

Hinweis: Der zur Verfügung stehende Netto-Speicherplatz für die Anwendung eMP/AMTS beträgt 13.506 Byte, wobei die kompletten eMP/AMTS-Daten intern vor der Speicherung noch komprimiert werden.

Prämisse

Zusätzlich wird davon ausgegangen, dass in allen Primärsystemen, bis auf die Apothekenverwaltungssysteme, die Versicherten-ID des Versicherten vor einem Schreiben von eMP/AMTS-Daten separat ermittelt wurde, z. B. im Rahmen des Einlesens der eGK zur Klärung des Versicherungsanspruches.

5.2.1 Standardablauf

Es ergeben sich folgende Anforderungen im Standardablauf der Anwendungsfälle:

5.2.2 Allgemeine Anforderungen für die Ersterstellung/Aktualisierung von eMP/AMTS-Daten

Kategorie Codes

Hinweis: Die Speicherplatzlimitierung des Carriers des 2D-Barcodes kann dazu führen, dass sich nicht alle Inhalte von BMP-gekennzeichneten Einträgen in einen Ausdruck wandeln lassen. Dies soll im Vorfeld verhindert werden.

5.3 Anforderungen an alle schreibenden Systeme

Für alle Anwendungsprozesse (ambulante Behandlung, stationäre Behandlung, zahnärztliche Behandlung und Arzneimittelabgaben in der öffentlichen Apotheke) außer der psychotherapeutischen Behandlung gelten die folgenden Anforderungen für die Erstellung von eMP/AMTS-Daten.

5.3.1 Ablaufaktivitäten und Standardablauf

Es ergeben sich folgende Anforderungen:

5.3.2 Anforderungen für die Ersterstellung von eMP/AMTS-Daten

Die allgemeinen Anforderungen aus 5.4.1 gelten für die Ersterstellung, aber nicht ausschließlich.

Hilfestellung bei Strukturierung von Anforderungen

In den Phasen der Ersterstellung sind unterschiedliche Aktivitäten möglich, bevor ein beliebiges Datum übernommen wird. Die Abläufe der unterschiedlichen Aktivitäten eines Dateneintrages folgen dem folgenden Hilfsdiagramm (Abbildung 3: Hilfsdiagramm möglicher Aktivitäten während der Ersterfassung zum Zwecke der Strukturierung der Anforderungen), welches nicht normativ ist, sondern dem Zwecke dient, die folgenden Anforderungen zu strukturieren. Das Hilfsdiagramm erhebt keinen Anspruch an Vollständigkeit der Abläufe in einem Primärsystem, sondern dient einzig der Zuordnung und Vervollständigung der Anforderungen.

Ein einfacher Ablauf eines zu erstellenden Datums durchläuft folgende Schritte:

Nach dem Neu-Anlegen eines Datums, dem Befüllen oder Verändern des Datums, wird das Datum zusammenstellen und anschließend wird das Datum mit dem Ziel der Speicherung in den eMP/AMTS-Daten auf der eGK übernommen. Alternativ zum Neu-Anlegen lassen sich Daten von Papiermaterial nutzen. Das Befüllen bzw. Verändern eines Datums kann durch eine Suche im Primärsystem unterstützt werden, wobei die resultierenden Daten vor der Zusammenstellung zu bestätigen sind. Die zusammengestellten Daten können gesichtet werden, wobei ergänzend die Ansicht in Form des BMP möglich sein sollte. Bevor die zusammengestellten Daten übernommen werden, lassen sich dieses noch entfernen.

Abbildung 3: Hilfsdiagramm möglicher Aktivitäten während der Ersterfassung zum Zwecke der Strukturierung der Anforderungen

Kategorie Aktion Neu anlegen

Kategorie Aktion Befüllen/Verändern

Hinweis: In anderen Anwendungskontexten (Verordnung, BMP, Anamnese, Arztbrief ...) sind Medikationseinträge geschaffen worden, die im Primärsystem abgelegt (hinterlegt) sind.

Kategorie Aktion Suchen

Hinweis: Trifft hauptsächlich für Medikamente, Allergien/Unverträglichkeiten, sonstige Parameter zu.

Kategorie Kennzeichen der Medikationseinträge

Kategorie Überschrift

Kategorie Leerzeile

Hinweis: Leerzeilen können dem Akteur und dem Versicherten zur optischen Strukturierung des BMP-Ausdruckes dienen.

Kategorie Aktion Zusammenführen

Kategorie Aktion Sichten

Kategorie Aktion Entfernen

Kategorie Code

Hinweis: Ein Wechsel von codierten Inhalten zu freitextlichen Inhalten und umgekehrt ist hiervon unberührt, wenn alternative Darstellungsvarianten vorhanden sind.

Kategorie Aktion Speichern

5.3.3 Anforderungen für die Aktualisierung von eMP/AMTS-Daten

Die allgemeinen Anforderungen aus 5.4.1 und die Anforderungen für die Ersterstellung aus 5.4.2 gelten für die Aktualisierung.

Der Begriff der Zusammenführung von Daten muss bei der Aktualisierung, speziell der Aktualisierung von medizinischen Daten, als Konsolidierung verstanden werden.

Hilfestellung bei Strukturierung von Anforderungen

In den Phasen der Ersterstellung sind unterschiedliche Aktivitäten möglich, bevor ein beliebiges Datum übernommen wird. Die Abläufe der unterschiedlichen Aktivitäten eines Dateneintrages folgen dem folgenden Hilfsdiagramm (Abbildung 4: Hilfsdiagramm möglicher Aktivitäten während der Aktualisierung zum Zwecke der Strukturierung der Anforderungen), analog der Ersterstellung, welches nicht normativ ist, sondern dem Zwecke dient, die folgenden Anforderungen zu strukturieren. Das Hilfsdiagramm erhebt keinen Anspruch an Vollständigkeit der Abläufe in einem Primärsystem, sondern dient einzig der Zuordnung und Vervollständigung der Anforderungen.

Ein einfacher Ablauf eines zu aktualisierenden Datums durchläuft folgende Schritte:

Nach dem Einlesen des Datums, dem Verändern des Datums, wird das Datum mit vorhandenen, vergleichbaren Werten zusammengeführt (der Anwender wählt aus unterschiedlichen Inhalten zu einem Datumseintrag den für ihn geeigneten aus, wobei das Primärsystem den Anwender geeignet unterstützt z.B. durch vergleichende oder optische Gegenüberstellung mit Hervorheben der Unterschiede), bevor das Datum mit dem Ziel der Speicherung in den eMP/AMTS-Daten auf der eGK übernommen wird. Das Verändern eines Datums kann durch einen Vergleich mit Daten im Primärsystem unterstützt werden, wobei die resultierenden Daten vor der Zusammenstellung zu bestätigen sind. Hierbei können auch Daten, die potenziell veraltet sind (z. B. deren Ersterfassungsdatum älter als 6 Monate ist) zur Übernahme ausgeschlossen werden.  Die zusammengestellten Daten können gesichtet werden, wobei ergänzend die Ansicht in Form des BMP möglich sein sollte. Anstatt die zusammengestellten Daten zu übernehmen, lassen sich diese verwerfen, werden somit entfernt.

Abbildung 4: Hilfsdiagramm möglicher Aktivitäten während der Aktualisierung zum Zwecke der Strukturierung der Anforderungen

Kategorie Allgemein

Kategorie Aktion Verändern

Hinweis: Da hier eine Aktualisierung stattfindet muss das Datum letzte Änderung, wie in der Ersterstellung festgelegt, auf das aktuelle Datum gesetzt werden.

Kategorie Aktion Vergleichen

Kategorie Aktion Vergleichen/Bestätigen

Hinweis: Da eine Ersterstellung auch außerhalb der Arzt-/Zahnarztpraxis erfolgen kann, wo keine VSD vorliegen, muss bei fehlender Versicherten-ID der gesamte eMP/AMTS-Datensatz als fraglich betrachtet werden. D. h., eine Klärung ist notwendig.

Kategorie Aktion Bestätigen

Kategorie Aktion Zusammenführen

Hinweis: Da die Anwendung VSDM und eMP/AMTS-Datenmanagement entkoppelt sind, können hier ggf. die Inhalte abweichen.

5.3.4 Anforderungen für Vorbereitung zur Speicherung der eMP/AMTS-Daten

Hinweis: Der zur Verfügung stehende Netto-Speicherplatz für die Anwendung eMP/AMTS beträgt 13.560 Byte, wobei die kompletten eMP/AMTS-Daten intern vor der Speicherung noch komprimiert werden.

5.4 Anwendungsprozess AP.A.01 Ambulante Behandlung

Der Anwendungsprozess der ambulanten Behandlung ist von Primärsystemen für die ambulante Behandlung umzusetzen.

Tabelle 3: Tab_ILF_AMTS_001 ambulante Behandlung AP.A.01

Abbildung 5: Abb_ILF_AMTS_001 – Standardablauf – ambulante Behandlung

5.4.1 Allgemeine Anforderungen für die Ersterstellung/Aktualisierung von eMP/AMTS-Daten

Hinweis: Das Zusammenstellen von eMP/AMTS-Daten kann in mehreren unabhängigen Schritten erfolgen, die zeitlich nicht in direkter Aufeinanderfolge stattfinden müssen. Hier wird der Situation in Arztpraxen etc. Rechnung getragen, dass Arbeitsabläufe unterbrochen und zu einem späterem Zeitpunkt fortgesetzt werden können. Zusätzlich können mehrere berechtigte Akteure in die Zusammenstellung eingebunden sein.

Kategorie Codes

Forderungen aus § 31a SGB V Anlage 3

5.4.2 Anforderungen für die Ersterstellung von eMP/AMTS-Daten

Die allgemeinen Anforderungen aus 5.4.1 gelten für die Ersterstellung, aber nicht ausschließlich.

Kategorie Aktion Befüllen/Verändern

5.5 Anwendungsprozess AP.A.02 Stationäre Behandlung

Der Anwendungsprozess der stationären Behandlung ist von Krankenhausinformationssystemen umzusetzen.

Tabelle 4: Tab_ILF_AMTS_003 stationäre Behandlung AP.A.02

Abbildung 6: Abb_ILF_AMTS_002 Standardablauf – stationäre Behandlung

5.5.1 Allgemeine Anforderungen für die Ersterstellung/Aktualisierung von eMP/AMTS-Daten

Hinweis: Das Zusammenstellen von eMP/AMTS-Daten kann in mehreren unabhängigen Schritten erfolgen, die nicht zeitlich in direkter Aufeinanderfolge stehen. Hier wird der Situation in Arztpraxen etc. Rechnung getragen, dass Arbeitsabläufe unterbrochen und zu einem späterem Zeitpunkt fortgesetzt werden können. Zusätzlich können mehrere berechtigte Akteure in die Zusammenstellung eingebunden sein.

Kategorie Codes

Forderungen aus § 31a SGB V Anlage 3

5.5.2 Anforderungen für die Ersterstellung von eMP/AMTS-Daten

Die allgemeinen Anforderungen aus 5.4.1 gelten für die Ersterstellung, aber nicht ausschließlich.

Hinweis: Die VSD sind mit ISO8859-15, die AMTS-Daten sind mit ISO8859-1 codiert. Sonderzeichen sind vom Primärsystem zu überführen.

5.6 Anwendungsprozess AP.A.03 Zahnärztliche Behandlung

Der Anwendungsprozess der zahnärztlichen Behandlung ist von Primärsystemen für die zahnärztliche Behandlung umzusetzen.

Tabelle 5: Tab_ILF_AMTS_005 zahnärztliche Behandlung AP.A.03

Abbildung 7: Abb_ILF_AMTS_003 Standardablauf – zahnärztliche Behandlung

5.6.1 Allgemeine Anforderungen für die Ersterstellung/Aktualisierung von eMP/AMTS-Daten

Hinweis: Das Zusammenstellen von eMP/AMTS-Daten kann in mehreren unabhängigen Schritten erfolgen. Es ist nicht notwendig, dass diese Schritte zeitlich direkt aufeinanderfolgen. Hier wird der Situation in Arztpraxen etc. Rechnung getragen, dass Arbeitsabläufe unterbrochen und zu einem späterem Zeitpunkt fortgesetzt werden können. Zusätzlich können mehrere berechtigte Akteure in die Zusammenstellung eingebunden sein.

Forderungen aus § 31a SGB V Anlage 3

5.6.2 Anforderungen für die Ersterstellung von eMP/AMTS-Daten

Die allgemeinen Anforderungen aus 5.4.1 gelten für die Ersterstellung, aber nicht ausschließlich.

Kategorie Aktion Befüllen/Verändern

Kategorie Aktion Suchen

Hinweis: Die VSD sind mit ISO8859-15, die AMTS-Daten sind mit ISO8859-1 codiert. Sonderzeichen sind vom Primärsystem zu überführen.

Kategorie Aktualisierung

5.7 Anwendungsprozess AP.A.04 Psychotherapeutische Behandlung

Der Anwendungsprozess der psychotherapeutischen Behandlung ist von Primärsystemen für die psychotherapeutische Behandlung umzusetzen.

Tabelle #: Tab_ILF_AMTS_007 psychotherapeutische Behandlung AP.A.01

Abbildung 8: Abb_ILF_AMTS_004 Standardablauf – psychotherapeutische Behandlung

5.8 Anwendungsprozess AP.A.05 Arzneimittelabgabe in einer öffentlichen Apotheke

Der Anwendungsprozess der Arzneimittelabgabe in einer öffentlichen Apotheke ist von Apothekenverwaltungssystem umzusetzen.

Tabelle 6: Tab_ILF_AMTS_009 Arzneimittelabgabe in einer öffentlichen Apotheke AP.A.05

Abbildung 9: Abb_ILF_AMTS_005 Standardablauf – Arzneimittelabgabe in einer öffentlichen Apotheke

5.8.1 Allgemeine Anforderungen für die Ersterstellung/Aktualisierung von eMP/AMTS-Daten

Hinweis: Das Zusammenstellen von eMP/AMTS-Daten kann in mehreren unabhängigen Schritten erfolgen. Es ist nicht notwendig, dass diese Schritte zeitlich direkt aufeinanderfolgen. Hier wird der Situation in Arztpraxen etc. Rechnung getragen, dass Arbeitsabläufe unterbrochen und zu einem späterem Zeitpunkt fortgesetzt werden können. Zusätzlich können mehrere berechtigte Akteure in die Zusammenstellung eingebunden sein.

Kategorie Codes

Kategorie Patient

Apothekenspezifische Anforderungen

Hinweis: Die Versicherten-ID ist verpflichtend und muss daher vorab gelesen werden.

5.8.2 Anforderungen für die Ersterstellung von eMP/AMTS-Daten

Die allgemeinen Anforderungen aus 5.4.1 gelten für die Ersterstellung, aber nicht ausschließlich.

Kategorie Aktion Befüllen/Verändern

6 Anwendungsfälle

Dieses Kapitel beschreibt die Anwendungsfälle der Fachanwendung eMP/AMTS aus Sicht des berechtigten Akteurs bezüglich der Verarbeitung der eMP/AMTS-Daten des Versicherten im Primärsystem. Das Kapitel stellt Anforderungen an die Funktionalität des Primärsystems und gibt Implementierungshilfen.

Für jeden Anwendungsfall erfolgt eine Detaillierung mittels einer tabellarischen Beschreibung. Der Standardablauf einzelner Anwendungsfälle kann durch ein Sequenzdiagramm dargestellt werden.

Dieses Kapitel gilt für alle Akteure und alle Anwendungsprozesse aus Kap. 5.

6.1 Überblick über die Anwendungsfälle

Die Anwendungsfälle der Anwendung eMP/AMTS werden in zwei Klassen unterschieden:

„Regelmäßige“ Anwendungsfälle sind wiederkehrende Bestandteile eines oder mehrerer Anwendungsprozesse.

Diese sind

• AF.A.01    Einverständnis erteilen
• AF.A.02    eMP/AMTS-Daten von eGK lesen
• AF.A.03    eMP/AMTS -Daten auf eGK schreiben

„Ad-hoc“-Anwendungsfälle werden im Bedarfsfall ausgeführt und können von regelmäßigen Anwendungsfällen oder ggfs. auch losgelöst von Anwendungsprozessen und anderen Anwendungsfällen aktiviert werden.

Diese sind

• AF.A.50    Einwilligung anzeigen
• AF.A.51    Einwilligung erteilen
• AF.A.52    Einwilligung widerrufen
• AF A.53    Vertreter-PIN ändern
• AF.A.54    Datenübertragung bei Kartentausch durchführen
• AF.A.55    eMP/AMTS-PIN aktivieren
• AF.A.56    eMP/AMTS-PIN deaktivieren

6.2 Akteur-Anwendungsfall-Beziehungen

Die folgenden Diagramme stellen die Beziehungen zwischen Akteuren der Anwendung eMP/AMTS und den Anwendungsfällen dar:

Abbildung 10#: Use-Case-Diagramm der regelmäßigen Anwendungsfälle

Abbildung 11: Use-Case-Diagramm der Ad-hoc-Anwendungsfälle

6.3 Funktionelle Anforderungen

Die Anforderungen der nachfolgenden Kapitel sind normativ.

6.3.1 Allgemeine Anforderungen

Folgende Anforderungen gelten allgemein für die Primärsysteme:

Die Parameter der Webservice-Operationen sind in [AMTSService.xsd] spezifiziert und direkt in das WSDL-Dokument eingebunden.

Kategorie Aktion Vergleichen

Kategorie Historisiert/veraltet

Hinweis: Der Begriff „historisierte Daten“ bezeichnet Medikationseinträge, deren Medikation aktuellen Tagesdatum nicht mehr eingenommen wird.

Hinweis: Idealerweise wird der Anwender mit entsprechenden Hinweisen und der Möglichkeit, diese Einträge zu historisieren oder zu löschen, unterstützt.

Tabelle 7 Tab_ILF_AMTS_033 Bedingung für die Identifikation eines Eintrages als potenziell veraltet

Hinweis: Der Begriff „potenziell veraltete Daten“ bezeichnet Medikationsdaten, die dem Leistungserbringer als potenzieller Löschkandidat angeboten werden sollen (siehe auch AF.A.02.02).

Kategorie Vertreter-PIN

Hinweis: Das Primärsystem steuert das Kartenlesegerät an, so dass die richtige PIN abgefragt wird. D. h., am Kartenlesegerät wird der entsprechende Text angezeigt unter der Vorbedingung, dass der Akteur erkannt/erfragt hat, ob es sich um den Versicherte oder dessen Vertreter handelt. Es soll somit verhindert werden, dass der Vertreter versucht die PIN des Versicherte oder umgekehrt einzugeben und somit ein erfolgloser Versuch unternommen wird.

Kategorie Einwilligung

6.3.2 Angepasste Anforderungen

Folgende Anforderungen an die Primärsysteme werden durch das Fachmodul mittels Abfrage am Kartenterminal umgesetzt und sind somit für die Primärsysteme transparent:

• ILF-AMTS-A_2578 Eingabe der Vertreter-PIN und
• ILF-AMTS-A_2579 Keine Vertreter-PIN bei abgeschalteter eMP/AMTS-PIN.

6.3.3 Einverständnis erteilen AF.A.01

Der Anwendungsfall „Einverständnis erteilen“ (AF.A.01) ist nicht als eigene Operation an der Schnittstelle des Konnektors verfügbar. Da die Erteilung des Einverständnisses immer in einem fachlichen Kontext stehen muss (z. B. eMP/AMTS-Daten lesen oder schreiben), ist sie stattdessen direkter Bestandteil dieser Operationen. Die Umsetzung findet folglich im Fachmodul AMTS statt und muss aus Sicht der Primärsysteme bei der Implementierung nicht weiter beachtet werden.

Die Erteilung des Einverständnisses erfordert in der Regel eine PIN-Eingabe am Kartenterminal. Es sei daher daraufhin gewiesen, dass jeder Hersteller natürlich frei entscheiden kann, hier eventuelle Bedienungshilfen umzusetzen. Denkbar wäre auch, einen LE darauf hinzuweisen, dass ein Versicherter eventuell das Display am Kartenterminal beachten oder eine PIN-Eingabe durchführen muss.

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

Tabelle 8: Tab_ILF_AMTS_011 eMP/AMTS-Daten von eGK lesen

Tabelle 9: Tab_ILF_AMTS_012 Ablaufaktivitäten – eMP/AMTS-Daten von eGK lesen

Es ergeben sich folgende Anforderungen:

Hinweis: Der Hinweis kann beispielsweise eine Empfehlung darstellen, dass veraltete Medikationseinträge, die nicht mehr benötigt werden, ggf. zu löschen sind.

Abbildung 12: Abb_ILF_AMTS_006 Standardablauf – eMP/AMTS-Daten von der eGK lesen

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

Tabelle 10: Tab_ILF_AMTS_013 eMP/AMTS-Daten auf eGK schreiben

Tabelle 11: Tab_ILF_AMTS_0146 – Ablaufaktivitäten eMP/AMTS-Daten auf eGK schreiben

Es ergeben sich folgende Anforderungen:

Abbildung 13: Abb_ILF_AMTS_007 Standardablauf – eMP/AMTS-Daten auf eGK schreiben

6.3.6 Einwilligung anzeigen AF.A.50

Tabelle 12: Tab_ILF_AMTS_015 Einwilligung lesen

Tabelle 13: Tab_ILF_AMTS_016 Ablaufaktivitäten – Einwilligung von eGK lesen

Es ergeben sich folgende Anforderungen:

Abbildung 14: Abb_ILF_AMTS_008 Standardablauf – Einwilligung von der eGK lesen

6.3.7 Einwilligung erteilen AF.A.51

Tabelle 14#: Tab_ILF_AMTS_017 Einwilligung auf eGK schreiben

Tabelle 15: Tab_ILF_AMTS_018 Ablaufaktivitäten Einwilligung auf die eGK schreiben

Es ergeben sich folgende Anforderungen:

Abbildung 15: Abb_ILF_AMTS_09 Standardablauf – Einwilligung auf eGK schreiben

6.3.8 Einwilligung widerrufen AF.A.52

Tabelle 16: Tab_ILF_AMTS_019 Referenz der Einwilligung von eGK löschen

Tabelle 17: Tab_ILF_AMTS_020 Ablaufaktivitäten – Referenz der Einwilligung von eGK löschen

Es ergeben sich folgende Anforderungen:

Abbildung 16: Abb_ILF_AMTS_010 Standardablauf – Referenz der Einwilligung auf eGK löschen

6.3.9 Vertreter-PIN ändern AF.A.53

Tabelle 18: Tab_ILF_AMTS_021 Vertreter-PIN ändern

Tabelle 19: Tab_ILF_AMTS_022 Ablaufaktivitäten – Vertreter-PIN ändern

Es ergeben sich folgende Anforderungen:

Abbildung 17: Abb_ILF_AMTS_011 Standardablauf – Vertreter-PIN ändern

6.3.10 Datenübertragung bei Kartentausch AF.A.54

Zu Beginn dieser Operation wird die Versicherten-ID von der eGK gelesen und zwischengespeichert. Mit dieser wird sichergestellt, dass Quell- und Zielkarte demselben Versicherten gehören. Die Versicherten-ID der Quellkarte muss demzufolge über eine Kartensession hinweg gespeichert werden. 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 direkt nach dem Steckvorgang auszulesen und zwischenzuspeichern.

Hinweis: Die Anpassungen der eGK G2.1 beheben diese Einschränkung.

Tabelle 20: Tab_ILF_AMTS_023 Datenübertragung bei Kartentausch

Tabelle 21: Tab_ILF_AMTS_024 Ablaufaktivitäten – Datenübertragung bei Kartentausch

Hinweis: Details über Eingangs- und Ausgangsparameter zu den Funktionen DeleteConsent, DeleteConsentResponse, ReadConsent, ReadConsentResponse, ReadMP, ReadMPResponse, WriteConsent, WriteConsentResponse, WritewMP und WriteMPResponse finden sich in den vorausgehenden Unterkapiteln.

Hinweis: Auf Wunsch des Versicherten können die Daten der Einwilligung und die eMP/AMTS-Daten auf der Quell-eGK gelöscht werden, indem einzig die Daten der Einwilligung auf der Quell-eGK zu löschen sind (AF.A.52).

Es ergeben sich folgende Anforderungen:

Der Vorgang zur Übertragung des eMP/AMTS-Datensatzes auf eine neue eGK muss unter Benutzung eines Kartenterminals stattfinden. So hat der Versicherte die vollständige Kontrolle über den Ablauf und sieht alle Nachrichten und Fehlermeldung an dem Kartenterminal, in welches er initial seine alte eGK gesteckt hat.

6.3.11 eMP/AMTS-PIN aktivieren AF.A.55

Tabelle 22: Tab_ILF_AMTS_029 eMP/AMTS-PIN aktivieren

Tabelle 23: Tab_ILF_AMTS_030 Ablaufaktivitäten – eMP/AMTS-PIN aktivieren

Es ergeben sich folgende Anforderungen:

Abbildung 18: Abb_ILF_AMTS_013 Standardablauf – eMP/AMTS-PIN aktivieren

6.3.12 eMP/AMTS-PIN deaktivieren AF.A.56

Tabelle 24: Tab_ILF_AMTS_031 eMP/AMTS-PIN deaktivieren

Tabelle 25: Tab_ILF_AMTS_032 Ablaufaktivitäten – eMP/AMTS-PIN deaktivieren

Es ergeben sich folgende Anforderungen:

Abbildung 19: Abb_ILF_AMTS_014 Standardablauf – eMP/AMTS-PIN deaktivieren

Hinweis: Nicht alle Leistungserbringer sind zur Identitätsprüfung des Kartenüberbringers verpflichtet. Die Sperrung der eGK wird erst nach einem VSD-Update wirksam.

7 Ergänzende Funktionalitäten

7.1 Empfehlung zur Archivierung

Auf der Grundlage gesetzlicher Regelungen besteht eine Archivierungspflicht für die medizinischen Dokumente des Versicherten. Die Archivierung ist korrekt, verständlich, vollständig, nachvollziehbar und zeitnah durchzuführen. Je nach gesetzlicher Regelung sind damit dokumentierte Inhalte mit Aufbewahrungszeiträumen verbunden.

Zur Aufbewahrungsfrist wird auf die jeweils aktuelle Fassung der „Empfehlungen zur ärztlichen Schweigepflicht, Datenschutz und Datenverarbeitung in der Arztpraxis“ der BÄK und KBV, siehe [BÄK_KBV], und auf die einschlägigen gesetzlichen Normen verwiesen.

7.2 Zeichensatzkonvertierung

8 Nichtfunktionale Aspekte

8.1 Fehlerbehandlung

Bei erwarteten oder unbeabsichtigten Abweichungen antwortet das Fachmodul AMTS oder eine andere Konnektor-Komponente dem Primärsystem mit einer Warnung oder einer Fehlermeldung. Fehlermeldungen werden mittels eines gematik-eigenen SOAP-Faults (Struktur der Fehlermeldung: [gemILF_PS#6.3]) an das Primärsystem gemeldet.

Bei der Nutzung der Operationen des Fachmoduls AMTS oder einer anderen Konnektor-Komponente über Webservices sind die Vorgaben für die Struktur und Inhalte von Fehlermeldungen identisch. Empfehlungen zur Fehlerverarbeitung und die Struktur der SOAP-Fault-Nachricht, die das Primärsystem verarbeiten muss, sind in [gemILF_PS#6.2] und [gemILF_PS#6.3] beschrieben.

Das Primärsystem soll eine fehlertolerante Verarbeitung aufweisen. Dazu gehört:

• Eine planmäßige Verarbeitung von Fehlern und Warnungen der Konnektorschnittstellen, ohne abzubrechen oder die Arbeit des Akteurs zu blockieren.
• Verständliche Anzeige von Fehlerzuständen.

Idealerweise lässt sich das Verhalten bei Fehlern oder Warnungen über Konfigurationsparameter einstellen (Timeout für SOAP-Requests, Responses etc.).

Im Folgenden werden allgemeine Vorgaben zur Fehlerbehandlung innerhalb der Fachanwendung eMP/AMTS im Primärsystem definiert, siehe ergänzend [gemILF_PS].

Hinweis: Es sind ggf. Fehlermeldungen etc. geeignet zu dokumentieren.

Tabelle 26: Tab_ILF_AMTS_025 Generische und spezifische Fehlermeldungen

8.2 Verlagerung von Schreibvorgängen in den Hintergrund

8.3 Versicherten-PIN als Voreinstellung

[Hinweis: Das Primärsystem muss dem LE eine Auswahl ermöglichen, ob der Versicherte oder sein Vertreter anwesend ist und die Fachanwendung eMP/AMTS-Datenmanagement verwenden möchte. Abhängig von der Auswahl muss das Primärsystem das entsprechende PIN-Objekt zur Autorisierung benutzen (AMTS-PIN oder Vertreter-PIN).]

8.4 Visuelle Darstellung von Daten im Primärsystem

Für die visuelle Darstellung der eMP/AMTS-Daten oder der Daten zur Einwilligung ist eine grafische Benutzeroberfläche im Primärsystem erforderlich, auf der diese Daten fachlich, strukturiert und übersichtlich dem Akteur dargestellt werden.

Um die Qualität der Darstellung von Daten im Primärsystem sicherzustellen, wird auf die Verwendung der Norm EN ISO 9241 (Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten – [DIN EN ISO 9241]) hingewiesen.

Die Darstellung der Daten in den eMP/AMTS-Daten, die für den BMP relevant sind, hat nach den Vorgaben des BMP [Ver_KBV_BÄK_DAV] zu erfolgen. Die Darstellung des eMP/AMTS-Daten im Primärsystem bleibt dem Primärsystemhersteller überlassen, soll sich an den Vorgaben des Ausdruckes des BMP orientieren. Die Anforderungen aus dem Bereich der Aktualisierung von eMP/AMTS-Daten (Kap. 5.3.3) sind zu beachten.

8.5 Umgang mit eMP/AMTS-Schemata

Die gematik wird dem Primärsystemhersteller das aktuelle eMP/AMTS-Schema zusammen mit der Information zur Integration und Umsetzung zur Verfügung stellen. Der Primärsystemhersteller wird das aktuelle XML-Schema in bevorstehende Primärsystem-Aktualisierungen integrieren.

Bei künftigen Änderungen am eMP/AMTS-Schema werden neben dem Schema auch die Überleitungshinweise veröffentlicht. Die Überleitungshinweise sollen entstandene Änderungen an dem aktuellen XML-Schema beschreiben, so dass sie für den Primärsystemhersteller nachvollziehbar sind. Ferner wird mitgeteilt, ab wann das veröffentlichte XML-Schema gültig ist.

8.6 Abweichende Inhalte der Arzneimitteldatenbanken

[Hinweis: Der eMP/ATMS-Datensatz enthält für Fertigarzneimittel redundante Dateninhalte zusätzlich zur PZN. Diese Inhalte stammen aus der AM-DB eines zuvor Schreibenden. Es kann dabei zu Abweichungen zu den Inhalten aus der eigenen Datenbank kommen. Daher ist in Fälle einer Abweichung eine Akteuraktion notwendig.]

8.7 BMP-Erzeugung

Die Ableitung bzw. Erstellung des bundeseinheitlichen Medikationsplans aus den Daten des eMP/AMTS-Datensatzes ist Aufgabe der Primärsysteme. Dabei gilt, dass Attribute des Datenmodells, die nicht im Datenmodell des BMPs existieren, nicht zu übernehmen sind, also für den BMP keine Bedeutung haben.

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

9.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

9.5.2 Weitere Dokumente

10 Anhang B – Beispiele

Um einen besseren Überblick über die Nachrichten, die zwischen Primärsystem und Fachmodul AMTS ausgetauscht werden, zu geben, wird im Folgenden die Struktur dieser Nachrichten (Request und Response) mit Beispieldaten vorgestellt. Diese haben einen informativen Charakter.

Die folgenden Beispieldaten bieten eine Implementierungshilfe zu den in diesem Dokument vorgestellten Anwendungsfällen an. Die Beispieldaten der Anwendungsfälle aus dem Kapitel 6 sind identisch mit den Folgenden und werden nicht explizit beschrieben. Die Namen der aufgerufenen Operationen sind unterschiedlich, z.B. ReadMP.

Der Austausch dieser Nachrichten erfolgt dabei mittels des SOAP-Protokolls. Das in der AMTSService.wsdl angegebene SOAP-Encoding document/literal sorgt für die Prüfung des Inhalts des Elementes SOAP-ENV:Body auf die Gültigkeit gegenüber dem Schema AMTSService.xsd.

10.1 ReadMP

Beispiel #: Beispiel für den SOAP-Aufruf der Operation ReadMP

<SOAP-ENV:Envelope

xmlns:SOAP-ENV=„http://schemas.xmlsoap.org/soap/envelope/“

xmlns:SOAP-ENC=„http://schemas.xmlsoap.org/soap/encoding/“ xmlns:xsi=„http://www.w3.org/2001/XMLSchema-instance“ xmlns:xsd=„http://www.w3.org/2001/XMLSchema“ xmlns:m0=„http://ws.gematik.de/conn/ConnectorContext/v2.0“ xmlns:m1=„http://ws.gematik.de/conn/ConnectorCommon/v5.0“>

    <SOAP-ENV:Body>

        <m:ReadMP xmlns:m=
     „http://ws.gematik.de/conn/amtss/AMTSService/WSDL/v1.0“>

            <m0:Context>

                <m1:MandantId>m0001</m1:MandantId>

                <m1:ClientSystemId>cs0001</m1:ClientSystemId>

                <m1:WorkplaceId>wp007</m1:WorkplaceId>

                <m1:UserId>ui123</m1:UserId>

            </m0:Context>

            <m1:EhcHandle>ehc0123456789</m1:EhcHandle>

            <m1:HpcHandle>hpc112233</m1:HpcHandle>

            <m1:UsingPIN>MRPIN.AMTS</m1:UsingPIN>

        </m:ReadMP>

    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

In obigem SOAP-Aufruf wird die Operation ReadMP mit folgenden Parametern aufgerufen:

Context^{(Aufrufkontext ist ausführlicher in [gemILF_PS#3.3.1] beschrieben.)}:

• MandantId ist eine alphanumerische ID des Mandanten und ist sowohl im Primärsystem als auch im Konnektor hinterlegt.
• ClientSystemId ist eine alphanumerische ID des Primärsystems. Sie ist sowohl im Primärsystem als auch im Konnektor konfiguriert und dem Mandanten mit der MandantId zugeordnet.
• WorkplaceId ist eine alphanumerische ID und ist sowohl im Primärsystem als auch im Konnektor konfiguriert. Sie ist im Konnektor dem Mandanten mit der MandantId als auch dem Primärsystem mit der ClientSystemId zugeordnet.
• Die Angabe eines Benutzers UserID ist notwendig, wenn HpcHandle zu einem HBA gehört.

Karten-Handle:

• EhcHandle adressiert die eGK des Versicherten, von der die eMP/AMTS-Daten ausgelesen werden soll. Die Adressierung wurde zuvor über eine Meldung des Ereignisdienstes des Konnektors oder über EventService.getCards() ermittelt.
• HpcHandle adressiert den HBA oder die SMC-B, die zur Authentisierung verwendet werden soll.

Auf die obige Anfrage zum Fachmodul AMTS sind verschiedene Antworten möglich. Dabei sind drei Fälle zu unterscheiden:

• OK: Rückgabe der eMP/AMTS-Daten.
• ERROR: Das Fachmodul AMTS meldet einen Fehler. Die eMP/AMTS-Daten werden nicht an das Primärsystem zurückgeliefert. Die Struktur der SOAP-Fault-Nachricht ist in [gemILF_PS#6.3] beschrieben.

Beispiel #: ReadMPResponse bei Erfolg

<?xml version=„1.0“ encoding=„UTF-8“?>

<soapenv:Envelope

xmlns:soapenv=„http://schemas.xmlsoap.org/soap/envelope/“ xmlns:v1=„http://ws.gematik.de/conn/amtss/AMTSService/WSDL/v1.0“

<soapenv:Header/>

<soapenv:Body>

<v1:ReadMPResponse>

      <v1:Status>

        <v1:Result>OK</v1:Result>

      </v1:Status>

    <v1:AMTSDocument>[Base64-Block]</v1:AMTSDocument>

    <v1:EGKValid>true</v1:EGKValid>

</v1:ReadAMTSResponse>

</soapenv:Body>

</soapenv:Envelope>

Ergebnis:

Im Element Status/Result hat das Fachmodul AMTS die Antwort der aufgerufenen Operation ReadMP hinterlegt. Die Durchführung war erfolgreich und die eMP/AMTs-Daten konnten von der in der Anfrage adressierten eGK ausgelesen werden.

eMP/AMTS:

Die von der eGK des Versicherten ausgelesenen eMP/AMTS-Daten sind im Element AMTSDocument hinterlegt.

eGK-Gültigkeit:

Der Kartenstatus wird über das Element EGKValid hinterlegt.