Erarbeitung einer Strategie zur Einführung der...

© 2004 Projektgruppe bIT4health Seite 1 von 86

Erarbeitung einer Strategie zur Einführung der Gesundheitskarte Use Case Modell Teil 1 Anwendungsfälle des Vertragsdaten-, Verordnungs- und Behand-lungsmanagements in der Telematikinfrastruktur

Für das Bundesministerium für Gesundheit und Soziale Sicherung Von der IBM Deutschland GmbH unterstützt durch die Firmen Fraunhofer-Institut für Arbeitswirtschaft und Organisation SAP Deutschland AG & Co. KG InterComponentWare AG ORGA Kartensysteme GmbH

Version 1.1 vom 12. August 2004

Autoren:

Richard Lomax (IBM)

Torsten Geiler (SAP)

Rainer Schalk (SAP)


Inhaltsverzeichnis

0 Allgemeines ___________________________________________4

0.1 Änderungsübersicht ________________________________________________4

0.2 Abkürzungsverzeichnis _____________________________________________4

0.3 Referenzierte Dokumente ____________________________________________4

0.4 Glossar ___________________________________________________________4

0.5 Abbildungsverzeichnis ______________________________________________5

0.6 Tabellenverzeichnis_________________________________________________5

1 Zweck des Dokumentes _________________________________6

1.1 Ziele des Dokuments________________________________________________6

1.2 Inhalt und Dokumentenstruktur _______________________________________7

1.3 Einordnung in die Rahmenarchitektur__________________________________7

2 Zusammenfassung ____________________________________10

2.1 Ansatz und methodische Vorgehensweise_____________________________10

2.2 Ergebnisse _______________________________________________________10

3 Einführung in die Modellierung __________________________12

3.1 Das Anwendungsfall-Modell (Use Case Modell)_________________________12

3.2 Was ist ein Anwendungsfall? ________________________________________12

3.3 Notation von Anwendungsfalldiagrammen_____________________________13

3.4 Anwendungsfalldokumentation auf Systemebene_______________________14

3.5 Überblick der betrachteten Anwendungsfälle __________________________15 3.5.1 Vertragsdatenmanagement_____________________________________________ 15 3.5.2 Verordnungsmanagement______________________________________________ 17 3.5.3 Behandlungsmanagement______________________________________________ 18

3.6 Überblick der Akteure ______________________________________________21 3.6.1 Akteure im medizinischen Bereich _______________________________________ 21 3.6.2 Akteure im administrativen Bereich_______________________________________ 22 3.6.3 Akteure in den Szenarios ______________________________________________ 23 3.6.4 Systeme als Akteure __________________________________________________ 23

4 Anwendungsfälle Gesundheitskarte ______________________24


4.1 Vertragsdatenmanagement _________________________________________24 4.1.1 Anwendungsfalldiagramm ______________________________________________ 24 4.1.2 Generische Use Cases ________________________________________________ 25 4.1.3 Szenarios __________________________________________________________ 35 4.1.4 Übersicht Zuzahlungsregelungen ________________________________________ 39

4.2 Verordnungsmanagement __________________________________________41 4.2.1 Anwendungsfalldiagramm ______________________________________________ 41 4.2.2 Generische Anwendungsfälle ___________________________________________ 42 4.2.3 Szenarios für ein Arzneimittel-Rezept (eRezept) ____________________________ 55

4.3 Behandlungsmanagement __________________________________________62 4.3.1 Anwendungsfalldiagramm ______________________________________________ 62 4.3.2 Generische Anwendungsfälle ___________________________________________ 63 4.3.3 Szenarios __________________________________________________________ 76

4.4 Anwendungsfall Steuerung _________________________________________83 4.4.1 Anwendungsfälle zur Steuerung des Gesundheitswesens _____________________ 83

5 Cross-Referenz zum Geschäftsprozessmodell______________86


0 Allgemeines

0.1 Änderungsübersicht

Version Datum Seite Bemerkungen Bearbeiter

1.0 22.03.03 alle Erste Version Richard Lomax, IBM Rainer Schalk, SAP Torsten Geiler, SAP

1.1 12.08.04

Überarbeitete Version aufgrund der öf-fentlichen Kommentierung

Richard Lomax (IBM), Christoph Altenhofen (IAO)

0.2 Abkürzungsverzeichnis AHB Anschlussheilbehandlung AR Anschlussrehabilitation BTM Betäubungsmittel DEÜV Datenerfassungs- und Übermittlungsverordnung DMP Disease Management Programme GKV Gesetzliche Krankenversicherung HBA Elektronischer Heilberufsausweis KVK Krankenversicherungskarte LE Leistungserbringer PKV Private Krankenversicherung QS Qualitätssicherung SAGA Standards und Architekturen für eGovernment-Anwendungen SMC Security Module Card VO Verordnung

0.3 Referenzierte Dokumente Alle referenzierten Dokumente werden in den gemeinsamen Projektreferenzen [b4hReferenzen] geführt.

0.4 Glossar Alle Glossareinträge werden im gemeinsamen Projektglossar [b4hGlossar] geführt.


0.5 Abbildungsverzeichnis Abbildung 1: Dokumente und ihre Beziehungen__________________________________________ 8

Abbildung 2:Anwendungsfalldiagramm: Notationsbeispiel _________________________________ 13

Abbildung 3: Systemkontextdiagramm Vertragsdatenmanagement __________________________ 17

Abbildung 4: Systemkontextdiagramm Verordnungsmanagement ___________________________ 18

Abbildung 5: Systemkontextdiagramm Behandlungsmanagement___________________________ 20

Abbildung 6: Use Case Diagramm Vertragsdatenmanagement _____________________________ 24

Abbildung 7: Use Case Diagramm Verordnungsmanagement ______________________________ 41

Abbildung 8: Use Case Diagramm Behandlungsmanagement______________________________ 62

0.6 Tabellenverzeichnis Tabelle 1: Generische Use Cases Vertragsdatenmanagement _____________________________ 16

Tabelle 2: Szenarios Vertragsdatenmanagement________________________________________ 16

Tabelle 3: Generische Use Cases Verordnungsmanagement ______________________________ 17

Tabelle 4: Szenarios Verordnungsmanagement_________________________________________ 18

Tabelle 5: Generische Use Cases Behandlungsmanagement ______________________________ 19

Tabelle 6: Szenarios Behandlungsmanagement ________________________________________ 19


1 Zweck des Dokumentes

Das Gesetz zur Modernisierung der Gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz) [GMG], mit dem diverse Gesetze aus dem Bereich der gesetzlichen Krankenversicherung (bspw. SGB V) geändert wurden, schreibt die Einführung einer Infor-mations-, Kommunikations- und Sicherheitsinfrastruktur, die den Einsatz der elektronischen Gesundheitskarte ermöglicht, vor. Notwendige Voraussetzung für die Schaffung einer einheitlichen Telematikinfrastruktur ist die Definition einer verbindlichen Rahmenarchitektur, die als Leitlinie für die Beteiligten im Ge-sundheitswesen und den zuliefernden IT-Firmen akzeptiert wird. Diese ermöglicht insbeson-dere die Interoperabilität zwischen medizinischen Informations- und Kommunikationssyste-men und die Entwicklung einer verlässlichen und gemeinsamen Sicherheitsinfrastruktur. Ein wesentliches Kennzeichen der zu erstellenden Rahmenarchitektur ist dabei ihre Genera-lisierbarkeit, die dadurch – abweichend von einer spezifischen Lösungsarchitektur – Ände-rungen und Erweiterungen der Modelle unabhängig von herstellerspezifischen Anwendun-gen, zulässt.

1.1 Ziele des Dokuments Der Einsatz der Gesundheitskarte führt zu Änderungen und Ergänzungen der bisherigen Abläufe von Prozessschritten im Gesundheitswesen bzw. zu ganz neuen Abläufen. Ziel der Anwendungsfalldefinition ist es, diese zu analysieren und die sich daraus ergebenden neuen Abläufe zu dokumentieren. Im nachstehenden Dokument werden die für den Einsatz der Gesundheitskarte relevanten Anwendungsfälle auf einer generischen Ebene (High Level Use Cases) beschrieben. Sie sind aus den Geschäftsprozessen (siehe [b4hGPM]) abgeleitet, die ebenfalls aus einer generischen Sicht definiert worden sind. Ein weiteres Ziel besteht darin, die notwendigen fachlichen Voraussetzungen zu beschrei-ben, um das Informations- bzw. Komponentenmodell in der Spezifikationstiefe einer Rah-menarchitektur zu beschreiben. Für die darauf aufbauende Lösungsarchitektur müssen spe-zielle Anwendungsfälle definiert werden, die auf die Einzelheiten einer spezifischen Umge-bung eingehen. Beim vorliegenden Dokument handelt es sich um Teil 1 des Use Case Modells. Dieser Teil bezieht sich auf die Use Cases zu den Prozessgruppen Vertragsdaten-, Verordnungs- und Behandlungsmanagement des Geschäftsprozessmodells [b4hGPM]. Die Beschreibung der Use Cases zur Prozessgruppe Kartenmanagement mit ihrem impliziten Bezug zum Thema Sicherheit erfolgt im separaten Dokument „Use Case Modell Teil 2 – Anwendungsfälle des Kartenmanagements in der Telematikinfrastruktur“ [b4hUseCaseII].


1.2 Inhalt und Dokumentenstruktur Dieses Dokument ist folgendermaßen aufgebaut. Kapitel 1 beschreibt die Zielsetzung des Dokuments und Kapitel 2 „Zusammenfassung“ fasst die wesentlichen Ergebnisse des Do-kuments im Sinne einer „Management Summary“ zusammen–. Es handelt sich hierbei nicht nur um die Anwendungsfälle selbst, sondern auch um die Problemfelder, die während der Analyse aufgekommen sind. Die darauf folgenden Kapitel vertiefen die Thematik der Anwendungsfälle. So werden in Ka-pitel 3 „Einführung in die Modellierung" die theoretischen Grundlagen vermittelt, die für das Verständnis der Vorgehensweise und Notation in der Anwendungsfallmodellierung notwen-dig sind. Ferner erfolgt ein Überblick über die betrachteten Anwendungsfälle sowie über die beteiligten Akteure. In Kapitel 4 „Anwendungsfälle Gesundheitskarte" sind die einzelnen Anwendungsfälle zu finden. Sie sind in die drei Bereiche „Vertragsdatenmanagement“, „Verordnungsmanage-ment“ und „Behandlungsmanagement“ gegliedert. Alle Anwendungsfälle werden zuerst ge-nerisch betrachtet – sie sind allgemein verfasst und sollen möglichst für alle Leistungserbrin-ger im Gesundheitswesen gelten. Im Anschluss daran werden einige, als besonders wichtig erachtete, Anwendungsfälle in der Form von „Szenarios“ mit einem Bezug zu realen Gege-benheiten des Gesundheitswesens dargestellt. Die Anwendungsfälle orientieren sich an dem Einsatz der Gesundheitskarte. Vorhandene Abläufe bei Leistungserbringern, die nicht im unmittelbaren Zusammenhang mit der Ge-sundheitskarte stehen, werden nicht betrachtet. Das abschließende Kapitel 5 „Cross-Referenz zum Geschäftsprozessmodell" stellt die Ab-hängigkeiten zwischen den übergeordneten Geschäftsprozessen und den beschriebenen Anwendungsfällen dar.

1.3 Einordnung in die Rahmenarchitektur Die nachfolgende Graphik stellt die Beziehungen der Dokumente untereinander dar. Dabei bedeuten die Pfeile eine Beeinflussung der Dokumente untereinander. Insofern ergibt sich eine natürliche Lese-Reihenfolge entlang der Pfeilrichtungen. In der Graphik können natür-lich nicht alle Einflüsse auf ein Dokument dargestellt werden.


Abbildung 1: Dokumente und ihre Beziehungen

Anwendungsfälle verfeinern Aktivitäten, die in einem oder mehreren Geschäftsprozessen vorher definiert worden sind. Insofern ist die Beschreibung von Anwendungsfällen ein Pro-jektschritt, der im Anschluss an die Geschäftsprozessmodellierung stattfindet. Daher gilt die Beschreibung der Geschäftsprozesse im Dokument „Geschäftsprozessmodell“ [b4hGPM] als Input oder Voraussetzung für das Verständnis der Anwendungsfälle. Ebenfalls können nicht-funktionale Anforderungen (siehe [b4hNFA]) die Gestaltung der Anwendungsfälle beeinflus-sen. Aus den Anwendungsfällen lassen sich einerseits durch eine funktionale Betrachtung ein Komponentenmodell [b4hKompMod], andererseits durch Betrachtung der Datenerfordernis-se ein Informationsmodell [b4hInfoMod] abbilden. Ferner können Sicherheitsanforderungen [b4hSichAnf] abgeleitet werden. Es wird erwartet, dass der Inhalt dieses Dokuments auch nach der Ersteinführung der Ge-sundheitskarte aufgrund der angewandten generischen Sicht relativ stabil bleibt. Neue An-wendungen werden zu einer der vorhandenen Kategorien Vertragsdatenmanagement, Ver-ordnungsmanagement oder Behandlungsmanagement gehören und aller Wahrscheinlichkeit nach gemäß den in den Anwendungsfällen beschriebenen Abläufen abgewickelt. Trotzdem können sich Änderungen, insbesondere im Hinblick auf einige Themen, die nicht innerhalb des ursprünglichen Zeitrahmens der Rahmenarchitektur geklärt werden konnten, ergeben. Ob die Gesundheitskarte der ausgebenden Krankenversicherung oder dem Patien-

Geschäfts-prozess- Modell

Use Case

Modell

Existierende Anwendungs-landschaften

Komponenten-modell

Standards und Initiativen im Ge-sundheitswesen

Informations-modell

Operationales Modell

Migrations-aspekte

Sicherheits-anforderungen

Nichtfunktionale Anforderungen

Sicherheits-Architektur

Pflichtenheft eGK


ten gehört, ob mehrere Vertragsverhältnisse (ggf. von unterschiedlichen Versicherungen) auf einer Karte gespeichert werden können – dies sind Beispiele von offenen Fragen, deren noch ausstehende Beantwortung evtl. eine Auswirkung auf die Anwendungsfälle haben kön-nen. Ebenfalls ist denkbar, dass sich Änderungen ergeben können, die in Verbindung mit der Wahrnehmung von Patientenrechten oder in der Handhabung der Karten nach den ersten Praxistests stehen.


2 Zusammenfassung

2.1 Ansatz und methodische Vorgehensweise Ein Anwendungsfall definiert eine Serie von Interaktionen zwischen Akteuren und dem zu betrachtenden System. Er wird von einem Akteur mit einer bestimmten Zielsetzung initiiert und schließt bei erreichtem Ziel erfolgreich ab. Abweichungen vom normalen Ablauf in einem Ausnahmefall bzw. alternative Wege, das Ziel zu erreichen, ergänzen die Beschreibung. Der Ansatz für die Beschreibung der Anwendungsfälle im bIT4health-Projekt ist durch die Beschreibung der Geschäftsprozesse in [b4hGPM] vorgegeben. Einzelne Aktivitäten aus den Prozessgruppen Vertragsdaten-, Verordnungs- und Behandlungsmanagement, die eine In-teraktion zwischen den Akteuren im Gesundheitswesen und der neu zu schaffenden Telema-tikinfrastruktur (das zu betrachtende System) hervorrufen, werden als Anwendungsfälle tie-fergehend analysiert. Die Akteure sind auf der einen Seite der Patient, auf der anderen Seite die Leistungserbringer bzw. die Kostenträger. Ausnahmen kommen insbesondere in den Situationen vor, in denen die Telematikinfrastruktur nicht zur Verfügung steht. Entsprechend der Zielsetzung der Definition einer Rahmenarchitektur sind die aus den gene-rischen Geschäftsprozessen abgeleiteten Anwendungsfälle ebenfalls generisch gehalten. Schon bei der Definition der Geschäftsprozesse sind konkrete Anwendungsumgebungen (z.B. Arztpraxen, Apotheken, Krankenhäuser) betrachtet worden, um die Prozessgemein-samkeiten für die generische Darstellung zu eruieren. Diese Vorgehensweise ist in der Be-schreibung der Anwendungsfälle fortgesetzt worden.

2.2 Ergebnisse In diesem Dokument werden die Anwendungsfälle für die drei Prozessgruppen „Vertragsda-tenmanagement“, „Verordnungsmanagement“ und „Behandlungsmanagement“ dargestellt. Die Themenstellung des Kartenmanagements ist nicht beinhaltet. Hier sei auf das zweite Use Case Dokument „Use Case Modell Teil 2 – Anwendungsfälle des Kartenmanagements in der Telematikinfrastruktur“ [b4hUseCaseII] verwiesen, das die Anwendungsfälle zum Kar-tenmanagement enthält. Die Use Cases sind soweit wie möglich und in Übereinstimmung mit dem Geschäftspro-zessmodell generisch gehalten. Die Abläufe agieren mit generischen Daten und Akteuren. So wird nicht von einem Rezept sondern von einem Übergabedokument, nicht von einem Arzt sondern von einem approbierten Heilberufler, nicht von einer Zuzahlung sondern von einer Zahlungsbeteiligung gesprochen. Mit diesem generischen Ansatz werden die Grund-elemente einer Telematikinfrastruktur definiert. Um die Anwendbarkeit der Anwendungsfälle zu illustrieren, werden zu einzelnen Fällen so-genannte Szenarios beschrieben. In diesen werden konkrete Situationen aufgegriffen, die technisch realisiert werden. Die Szenarios sind so ausgewählt, dass sie Situationen be-schreiben, die schon bei der Einführung der Gesundheitskarte in 2006 relevant werden. So wird beispielsweise im Rahmen des Verordnungsmanagements ein Szenario für das eRe-zept für Arzneimittel beschrieben, im Rahmen des Behandlungsmanagements ein Szenario für den Umgang mit klinischen Basisdaten („Notfalldaten“) und mit der Arzneimitteldokumen-


tation. Szenarios im Vertragsdatenmanagement betreffen verschiedene Formen von Zuzah-lungen. Die Gesundheitskarte wird sowohl in versicherungstechnischen als auch in medizinischen Prozessen eingesetzt. Um die Beteiligung des Bürgers an diesen unterschiedlichen Prozes-se zu verdeutlichen, wird er in versicherungstechnischen Abläufen als „Versicherter", in me-dizinischen Abläufen hingegen als „Patient" bezeichnet. Das Problem der Personenbezeich-nung wird durch die Thematik der Vertretung erschwert, die nicht in jedem betroffenen An-wendungsfall aufgeführt werden kann, sondern einer besonderen Behandlung bedarf. Hier stehen die Bedürfnisse der Anwendbarkeit denen des Datenschutzes gegenüber. Die Bedeutung der Rolle eines Patienten steigt im medizinischen Bereich mit der Einbezie-hung der medizinischen Daten. Auf diese Daten kann der Patient sein informationelles Selbstbestimmungsrecht in einem erheblich größeren Maße als bisher ausüben. Daher liegt in Abläufen mit medizinischen Daten ein Schwerpunkt auf dem patientenorientierten Daten-schutz. Die Analyse der Anwendungsfälle führte zwangsläufig zu einer Auseinandersetzung mit dem im Gesetz zur Modernisierung der Gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz) [GMG] vorgesehenen Einsatz der Gesundheitskarte. Obwohl die allgemeine, optimierende Zielsetzung ihres Einsatzes weitestgehend umgesetzt werden konnte, sind durch die detaillierte Betrachtung im Rahmen der Projektarbeit einige Unklarhei-ten aufgeworfen worden, die nur auf einer Grundsatzebene beantwortet werden können. Das vorliegende Dokument spricht solche Probleme an und macht Empfehlungen, sofern sich aus Ablaufsicht eine bessere Vorgehensweise eignen würde. Zu diesen identifizierten Unklarheiten gehört z.B. die Frage, wem die Gesundheitskarte ge-hört – dem Krankenversicherer (wie bei der bisherigen Krankenversicherungskarte) als Her-ausgeber der Karte und Eigentümer der Vertragsdaten oder dem Patienten, dessen sensitive medizinische Daten auf der Karte gespeichert bzw. mittels der Karte zu erreichen sind. Hier-von abhängig ist u.a. die Frage, ob bei einem Versicherungswechsel die Karte ausgetauscht werden muss oder lediglich ein Fortschreiben der vorhandenen Vertragsdaten vonnöten ist. Das GKV-Modernisierungsgesetz [GMG] führt zu Änderungen im SGB V [SGBV]. Aus streng gesetzlicher Sicht dürften sich daher die Abläufe, die in Verbindung mit einem Kostenträger stehen, nur auf die gesetzliche Krankenversicherung beziehen. Die im [GMG] vorgesehenen medizinischen Anwendungen stehen aber im Sinne einer umfassenden nationalen Gesund-heitsstrategie im Prinzip allen Bürgern und nicht nur gesetzlich Versicherten zu. Daher wurde bei der Beschreibung der Versuch unternommen, mit einem eher generischen Ansatz die relevanten Abläufe zu beschreiben, um damit weitere Kostenträger wie private Krankenver-sicherer, die freie Heilfürsorge oder die Beihilfe einzubeziehen. Folglich wird nicht von einem Akteur „Krankenkasse“ sondern allgemein von einem Krankenversicherer gesprochen. In den Anwendungsfällen werden zudem auch alternative Abläufe beschrieben. Sie betreffen hauptsächlich „fall-back“-Situationen, in denen die Gesundheitskarte aus unterschiedlichsten Gründen nicht zum Einsatz kommen kann. Im wesentlichen werden Papiervarianten vorge-sehen, die oft große Ähnlichkeiten mit den jetzigen Abläufen haben. Hierbei kommt erschwe-rend hinzu, dass der Fall der Nicht-Verwendbarkeit der Karte an einer Stelle innerhalb einer Prozesskette nicht vorhersehbar ist. Damit entsteht die Notwendigkeit, karten- und papierbe-zogene Ausgaben parallel zu erzeugen und zu führen.


3 Einführung in die Modellierung

3.1 Das Anwendungsfall-Modell (Use Case Modell) Im Anwendungsfall-Modell werden die funktionalen Anforderungen an das beschriebene Sy-stem erfasst. Menschliche oder automatisierte Akteure interagieren mit dem betrachteten System und erwarten ein bestimmtes, berechenbares Verhalten des Systems. Anwendungs-fälle spezifizieren das Systemverhalten und beschreiben eine Reihe von Handlungen, die das System durchführt, um den Akteuren ein sichtbares und verwertbares Ergebnis zu lie-fern. Im Anwendungsfall-Modell wird also betrachtet, was das System macht und wie es sich nach außen verhält. Es wird nicht betrachtet, wie dieses Verhalten implementiert wird. Wesentlich für die Anwendungsfall-Modellierung ist die Systemgrenze, die letztlich festlegt, ob die Interaktion mit einer Person oder einem beteiligten System als funktionale Anforde-rung überhaupt wahrgenommen wird. Für die Wahl dieser Systemgrenze existieren keine allgemeingültigen Vorgaben, sie muss aber so gewählt sein, dass alle für die jeweilige Be-trachtung wesentlichen Interaktionen mit dem System dargestellt werden. So wird der Admi-nistrator eines zentralen Dienstes bei der Betrachtung der Interaktion des Systems mit den Endbenutzern innerhalb der Systemgrenze liegen. Betrachtet man aber die Wartung des zentralen Dienstes, wird die Systemgrenze so gezogen, dass der Administrator außerhalb der Systemgrenze liegt. Im Kontext der bIT4health-Rahmenarchitektur wurde die Betrachtung der funktionalen Anfor-derungen in zwei Teile zerlegt, da sich unterschiedliche Systemgrenzen für eine sinnvolle Betrachtung als notwendig erwiesen haben. Teil 1 betrachtet im Wesentlichen die patientenorientierten Interaktionen des Vertragsdaten-managements, des Verordnungsmanagements und des Behandlungsmanagements. Hier gilt als Systemgrenze die Interaktion mit Endanwendern wie Leistungserbringern, Krankenversi-cherern und natürlich Patienten. Damit wird in Teil 1 z.B. die eGK und der HBA als innerhalb des Systems angesehen. Teil 2 betrachtet das Kartenmanagement und das Applikationsmanagement. Diese Prozesse erfordern ein komplexes Zusammenspiel von Akteuren, die zum größten Teil innerhalb der Systemgrenzen liegen, die bei Teil 1 betrachtet wurden. Um ein aussagekräftiges Anwen-dungsfall-Modell zu gestalten, musste die Systemgrenze deutlich enger gefasst werden. Als Systemgrenze wurde daher die Telematikinfrastruktur im engeren Sinne definiert. Damit ist beispielsweise die eGK ein Akteur, der mit dem System interagiert. Gerade dies ist für die Betrachtung der funktionalen Anforderungen an das Kartenmanagement und an das Applika-tionsmanagement wesentlich.

3.2 Was ist ein Anwendungsfall? Ein Anwendungsfall beschreibt einen zusammenhängenden Arbeitsablauf aus der Sicht sei-ner Akteure. Anwendungsfälle beschreiben das gewünschte Systemverhalten aus der Sicht der Systemteilnehmer. Damit werden die wesentlichen funktionalen Anforderungen an das System festgelegt. Beschrieben wird, was das System leisten muss, aber nicht wie es dies leisten soll.


Anwendungsfälle werden grundsätzlich durch einen Akteur initiiert und führen zu Ergebnis-sen, die für die Akteure wahrnehmbar sind. Die Beschreibung von Anwendungsfällen wird im Wesentlichen in allgemeinverständlicher Sprache vorgenommen. Um das Zusammenspiel von Anwendungsfällen und Akteuren in komplexen Szenarien darzustellen, werden Anwendungsfalldiagramme hinzugezogen.

3.3 Notation von Anwendungsfalldiagrammen

Abbildung 2:Anwendungsfalldiagramm: Notationsbeispiel

Ein Anwendungsfalldiagramm besteht aus zwei Grundelementen: den Akteuren (Systemteil-nehmern) und den Anwendungsfällen (Arbeitsabläufen). Diese Elemente können mit vier verschiedenen Beziehungen verbunden werden. Die normale Beziehung (ein einfacher Strich) zwischen Akteur und Anwendungsfall legt

fest, dass der Systemteilnehmer an diesem Arbeitsablauf teilnimmt. Die Generalisierungsbeziehung (ein Pfeil mit einem Dreieck an der Spitze) legt fest, dass

das Ausgangselement alle Eigenschaften und Fähigkeiten des Zielelements besitzt und meist darüber hinaus geht oder spezialisiert ist. Der Geschäftskunde im Beispiel kann al-so jederzeit als Kunde agieren.

Die Erweiterungsbeziehung (Dreieckspfeil mit der Aufschrift «extends») bedeutet, dass ein Anwendungsfall an einer festgelegten Stelle um eine zusätzliche Funktionalität erwei-tert wird. Im Beispiel wird „Bestellung aufgeben“ durch „Eilige Bestellung aufgeben“ er-weitert.

Die Benutzungsbeziehung (Dreieckspfeil mit der Aufschrift «uses») gibt an, dass ein An-wendungsfall einen anderen Anwendungsfall als Arbeitsablauf vollständig integriert. Im Beispiel benutzt „Bestellung aufgeben“ den Anwendungsfall „Warenverfügbarkeit abfra-gen“.

Es ist wichtig, zu verstehen, dass ein Anwendungsfalldiagramm keine zeitliche Abfolge dar-stellen kann und soll.

Kunde

DatenbankBestellung aufgeben

Warenverfügbarkeit abfragenEilige Bestellung

aufgeben

«uses»«extends»

Geschäftskunde

Aktor

Anw endungsfall

"benutzt den Anw endungsfall"erw eitert den Anw endungsfall

ist von ... abgeleitet


3.4 Anwendungsfalldokumentation auf Systemebene Anwendungsfälle werden in einer Tabelle dokumentiert, deren Struktur der nachstehenden Tabelle entspricht.

Anwendungsfall Bezeichner des Anwendungsfalls Name Name des Anwendungsfalls

Initiierender Akteur Der Systemteilnehmer, der den Anwendungsfall auslöst.

Weitere Akteure Weitere am Anwendungsfall beteiligte Systemteilnehmer

Kurzbeschreibung Eine kurze Zusammenfassung des Ablaufs.

Vorbedingung Sachverhalt, der vor Beginn des Anwendungsfalls zugesichert werden muss. Vorbedingungen werden in einem Anwendungs-fall nicht überprüft, sondern als gegeben hingenommen.

Nachbedingung Sachverhalt, der mit Ende des Anwendungsfalls zugesichert wird.

Funktionalität des Anwendungsfalls

Ablauf Schematische Beschreibung der einzelnen Vorgänge und der Be-teiligung der Akteure an diesen Vorgängen. Im Ablauf wird ledig-lich der Gut-Fall (der zu erwartende Normalablauf) beschrieben.

Alternativen Abweichende Abläufe für den Gut-Fall

Ausnahmen Abweichende Abläufe, die sich aus dem Schlecht-Fall ergeben - z. B. aus Schlecht-Ergebnissen von Prüfungen im Ablauf.

Benutzte Anwen-dungsfälle

Eingebettete Anwendungsfälle, die von diesem Anwendungsfall verwendet, erweitert oder ererbt werden.

Szenarios Ein Szenario, das den generischen Ansatz illustriert.

Weitere Information

Spezielle Anforderungen

Hier stehen über Vorbedingungen hinausgehende Anforderungen, die ein Funktionieren des Anwendungsfalls erst ermöglichen, so-wie spezielle Anforderungen an den Anwendungsfall, die dieser erfüllen muss (z. B. Sicherheitsvorgaben).

Annahmen Im Rahmen einer weitergeführten Architekturfestlegung noch zu treffende Entscheidungen, die hier vorweggenommen werden müssen. Sind Annahmen nicht erfüllt, muss der Anwendungsfall im Allgemeinen komplett neu entworfen werden.

Offene Themen Aspekte, die bei der Realisierung des Anwendungsfalls noch ge-klärt werden müssen, aber nicht als Entscheidung der Rahmenar-chitektur gesehen werden.

Referenzen Verweise auf Gesetze und andere Quellen, auf die sich der An-wendungsfall stützt oder die er umsetzt.

Datenanforderungen Im Anwendungsfall beteiligte Daten, sowie durch diese bedingte Anforderungen an die Ausgestaltung des Anwendungsfalls.


Anwendungsfall Bezeichner des Anwendungsfalls Name Name des Anwendungsfalls


Anforderungen an den Anwendungsfall, die sich nicht auf den (lo-gischen) Ablauf auswirken, aber starken Einfluss auf die Realisie-rung nehmen.

3.5 Überblick der betrachteten Anwendungsfälle

Im Folgenden werden die betrachteten generischen Anwendungsfälle zu den folgenden Pro-zessgruppen tabellarisch dargestellt: Vertragsdatenmangement (VD) Verordnungsmanagement (VO) Behandlungsmanagement (BE)

Zu jeder Tabelle werden die zusätzlich betrachteten Szenarios sowie je ein Systemkontext-diagramm dargestellt. Das Systemkontextdiagramm gibt einen Überblick über die verschie-denen Anwendungsfälle mit ihren externen Interaktionen. Es dient dazu, die Systemgrenzen festzulegen und die Schnittstellen zwischen der Gesundheitskarte und den peripheren Kom-ponenten sowie den Akteuren zu identifizieren. Mit „Akteur“ sind immer Personen oder Organisationen gemeint, die mit dem System (direkt oder indirekt) arbeiten. Der Akteur erkennt unter Umständen nicht, dass die Dienste der Ge-sundheitskarte involviert sind, da dies transparent innerhalb der Anwendung geschieht. Dementsprechend stellen die Pfeile im Systemkontextdiagramm keine Datenflüsse im Sinne eines Datenflussdiagramms dar, sondern kennzeichnen die aktiven Komponenten. Das be-deutet, dass die Komponente, von der der Pfeil ausgeht, die beschriebene Aktion startet, während die Komponente, bei der der Pfeil endet, die Aktion ausführt.

3.5.1 Vertragsdatenmanagement

3.5.1.1 Generische Anwendungsfälle zum Vertragsdatenmanagement

Auslösender Akteur Anwendungsfall Nummer

Anwendungsfall Name

Versicherter VD-1 Stammdaten mitteilen

Krankenversicherer VD-2 Vertragsdaten aktualisieren

Administrative Kraft (des Leistungserbringers)

VD-3 Patient identifizieren


VD-4 Vertragsdaten übernehmen


VD-5 Zahlungsbeteiligung in Rechnung stellen

Versicherter VD-6 Zahlungsbeteiligung leisten


VD-7 Zahlungsbeteiligung quittieren



Anwendungsfall Name

Versicherter VD-8 Zahlungsbeteiligung nachweisen Tabelle 1: Generische Use Cases Vertragsdatenmanagement

3.5.1.2 Szenarios im Vertragsdatenmanagement Um den generischen Ansatz zu illustrieren, werden einzelne generische Anwendungsfälle in Verbindung mit Szenarios näher erläutert. Anhand der Zuzahlungsregelung nach § 61 SGB V illustrieren vier Szenarios die unterschiedlichen Zuzahlungen.

Auslösender Akteur Szenario Num-mer

Szenario

Administrative Kraft (der Apotheke)

VD-5-ZuZa1 Zuzahlung für ein Arzneimittel in Rechnung stellen


VD-5-ZuZa2 Zuzahlung für Heilmittel in Rechnung stellen

Administrative Kraft (der gesetzlichen Kranken-kasse)

VD-5-ZuZa3 Zuzahlung für häusliche Krankenpflege in Rech-nung stellen

Administrative Kraft (der Reha-Einrichtung)

VD-5-ZuZa4 Zuzahlung für med. Rehabilitation in Rechnung stellen

Tabelle 2: Szenarios Vertragsdatenmanagement

3.5.1.3 Systemkontextdiagramm Vertragsdatenmanagement Die Bezeichnungen der Pfeile sind die Use Cases.


Abbildung 3: Systemkontextdiagramm Vertragsdatenmanagement

3.5.2 Verordnungsmanagement

3.5.2.1 Generische Anwendungsfälle zum Verordnungsmanagement


Anwendungsfall Name

Verordnungsgeber VO-1 Verordnung/Überweisung erfassen

Administrative Kraft (des Verordnungsgebers)

VO-2 Übergabe-Dokument zusammenstellen

Verordnungsgeber VO-3 Übergabe-Dokument signieren

Administrative Kraft (des Verordnungsgebers)

VO-4 Übergabe-Dokument auf einen Datenträger auf-bringen

Patient VO-5 Verordnung/Überweisung einreichen

Verordnungseinlöser VO-6 Verordnung/Überweisung übernehmen

Verordnungseinlöser VO-7 Übergabe-Dokument entwerten Tabelle 3: Generische Use Cases Verordnungsmanagement

Vertragsdaten-management

Admin.-Kraft Leistungserbringer

Versicherter

Kranken- versicherer

Vertragsdaten aktualisieren

Patient identifizieren

Zahlungs- beteiligung nachweisen

Vertragsdaten übernehmen

Zahlungs- beteiligung in Rechnungstellen

Zahlungs- beteiligungleisten

Zahlungs-beteiligungquittieren

Stammdatenmitteilen


3.5.2.2 Szenarios im Verordnungsmanagement Um den generischen Ansatz zu illustrieren, werden einzelne generische Anwendungsfälle in Verbindung mit Szenarios näher erläutert. Als Beispiel wird die Verordnung von Arzneimitteln („eRezept“) verwendet.


Szenario

Verordnungsgeber VO-1-AVO Arznei-VO erfassen

ArzthelferIn VO-2-AVO Arznei-Rezept zusammenstellen

Patient VO-5-AVO Arznei-VO in einer Apotheke einreichen

Verordnungseinlöser der Apotheke

VO-6-AVO Arznei-VO übernehmen

Tabelle 4: Szenarios Verordnungsmanagement

3.5.2.3 Systemkontextdiagramm Verordnungsmanagement

Abbildung 4: Systemkontextdiagramm Verordnungsmanagement

3.5.3 Behandlungsmanagement

3.5.3.1 Generische Anwendungsfälle zum Behandlungsmanagement


Anwendungsfall Name

Patient BE-1 Einmalige Einwilligung bei der ersten Verwendung einer freiwilligen Anwendung geben

Patient BE-2 Einwilligung zur Verwendung einer freiwilligen Anwendung widerrufen

Verordnungs-management

PatientAdmin.-KraftLeistungserbringer

Verordnungs-geber

Verordnung/ Überweisung erfassen

Admin.-KraftVerordnungsgeber

Übergabe-Dokumentsignieren

Übergabe-Dokumentzusammenstellen

Übergabe -Dokument auf Datentr ägeraufbringen

Verordnung/ Überweisung einreichen

Verordnung/Überweisungübernehmen

Übergabe -Dokument entwerten

Verordnungs-management

PatientVerordnungs-

einlöser

Verordnungs-geber

Verordnung/ Überweisung erfassen

Admin.-KraftVerordnungsgeber

Übergabe-Dokumentsignieren

Übergabe-Dokumentzusammenstellen

Übergabe -Dokument auf Datentr ägeraufbringen

Verordnung/ Überweisung einreichen

Verordnung/Überweisungübernehmen

Übergabe -Dokument entwerten



Anwendungsfall Name

Patient BE-3 Heilberufler für den Zugriff auf medizinische Daten autorisieren

Patient BE-4 Medizinische Daten bereitstellen

Approbierter Heilberufler BE-5 Medizinische Daten fortschreiben

BE-6 reserviert1

Leistungserbringer BE-7 Leistung erbringen

Leistungserbringer BE-8 Patientenquittung erstellen Tabelle 5: Generische Use Cases Behandlungsmanagement

3.5.3.2 Szenarios im Behandlungsmanagement Um den generischen Ansatz zu illustrieren, werden einzelne generische Anwendungsfälle in Verbindung mit Szenarios näher erläutert. Als Beispiele dienen die Verwendung der klini-schen Basisdaten und der Arzneimitteldokumentation.


Szenario

Patient BE-4-KBD Klinische Basisdaten bereitstellen

Patient BE-4-AMD Arzneimitteldokumentation bereitstellen

Approbierter Heilberufler BE-5-KBD Klinische Basisdaten fortschreiben

Approbierter Heilberufler BE-7-KI Kontra-Indikationscheck durchführen

Approbierter Heilberufler BE-7-IA Interaktionscheck durchführen Tabelle 6: Szenarios Behandlungsmanagement

1 BE-6 ist für den Widerruf einer Dauerautorisierung reserviert. Eine Dauerautorisierung ist eine Autorisierung durch einen Pati-enten für den Zugriff auf medizinische Daten (vgl. BE-3), die für einen definierten Zeitraum gilt. Sie ist nicht mit der Einwilligung (vgl. BE-1) zu verwechseln, die die grundsätzliche Benutzung einer Anwendung gestattet. Sofern ein Heilberufler eine Dauerau-torisierung für den Zugriff auf medizinische Daten von einem Patienten erhalten kann, muss der Patient auch die Möglichkeit haben, diese zu widerrufen. Da diese Thematik noch offen ist (und daher auch im Geschäftsprozess nicht vorgesehen), ist noch kein Use Case hierfür ausformuliert.


3.5.3.3 Systemkontextdiagramm Behandlungsmanagement

Abbildung 5: Systemkontextdiagramm Behandlungsmanagement

Behandlungs-management

Heilberufler

Medizinische Daten fortschreiben

approbierterHeilberufler

Medizinische Daten fortschreiben

Medizinische Datenbereitstellen

Patient

Einmalige Einwilligunggeben

Heilberufler autorisieren

Einmalige Einwilligung widerrufen

Medizinische Datenbereitstellen

Patient

Einmalige Einwilligunggeben

Heilberufler autorisieren

Einmalige Einwilligung widerrufen

Leistungs-erbringer

Patientenquittung erstellen

Leistungerbringen

Leistungs-erbringer


3.6 Überblick der Akteure Die folgenden Akteure werden in den beschriebenen Anwendungsfällen benutzt:

3.6.1 Akteure im medizinischen Bereich Akteur Beschreibung Verwendet in Anwen-

dungsszenario

Patient (Pat) In der Sicht der Gesundheitskarte handelt es sich um eine Person, die Leistungen des Gesundheitswesens beziehen kann. Im Fall einer nicht geschäftsfähigen Person bzw. bei Verhinderung können die Rechte des Pati-enten durch einen Bevollmächtigten wahr-genommen werden.

Im Kontext des bit4health-Projektes besitzt der Patient eine Gesundheitskarte.

Vertragsdatenmanagement

Verordnungsmanagement

Behandlungsmanagement

Heilberufler (HB) Person, die einen Heilberuf ausübt. Der Heilberufler verfügt über einen HBA oder einen entsprechenden Berufsausweis, mit-tels dem er sich legitimieren kann.

Der Heilberufler ist berechtigt, weitere Per-sonen zu beauftragen, auf Verordnungsda-ten und medizinische Daten zuzugreifen (§ 291a Abs. 5 SGB V/GMG). Die Zuord-nung einer solchen Person zum beauftra-genden Heilberufler muss nachprüfbar fest-gehalten werden.



Approbierter Heilberufler (aHB)

Eine approbierte Person (Arzt, Zahnarzt und Apotheker), die berechtigt ist, Heilbehand-lungen durchzuführen. Der approbierte Heil-berufler verfügt über einen HBA und ist da-durch befugt, qualifizierte Signaturen zu leisten.



Verordnungsgeber (VG) Approbierter Heilberufler, der berechtigt ist, Verordnungen (und Überweisungen) auszu-stellen (Arzt oder Zahnarzt).


Verordnungseinlöser (VE)

Verordnungseinlöser sind Leistungserbrin-ger, die gemäß § 291a Abs. 4 Satz 1 a-e SGB V/GMG grundsätzlich berechtigt sind, Verordnungsdaten zu lesen und Verordnun-gen einzulösen.


Nicht approbiertes Me-dizinpersonal (naMP)

Personen, die gemäß § 291a Abs. 4 Satz 2.d. SGB V/GMG berechtigt sind, in einem Notfall klinische Basisdaten zu lesen.


3.6.2 Akteure im administrativen Bereich Akteur Beschreibung Verwendet in Anwen-

dungsszenario

Versicherter (Vers) Person, die in einer Vertragsbeziehung zum Krankenversicherer steht. Im Fall einer nicht geschäftsfähigen Person bzw. bei Verhinde-rung können die Rechte des Versicherten durch einen Bevollmächtigten wahrgenom-men werden.


Krankenversicherer (KrV)

Eine Organisation, die Gesundheitsleistun-gen finanziert bzw. gewährt. Hierzu werden neben der gesetzlichen Krankenversiche-rung (wahrgenommen durch gesetzliche Krankenkassen) oder der privaten Kranken-versicherung (wahrgenommen durch private Versicherungsgesellschaften) auch sonstige Kostenträger wie die Beihilfe (Beamte) ver-standen, auch wenn es sich bei diesen nicht um eine Versicherung im eigentlichen Sinne handelt.


Gesetzliche Kranken-kasse (KK)

Körperschaft des öffentlichen Rechts, die Leistungen der gesetzlichen Krankenversi-cherung für ihre Versicherten gewährt.


Leistungserbringer (LE) Organisation oder Person, die Leistungen des Gesundheitswesens für Patienten er-bringen kann.

Der Begriff „Leistungserbringer“ wird im Rahmen des Projekts bIT4health als „funkti-onale“ Rolle verwendet.



Administrative Kraft 2(Admin)

Eine Person, die in einer Organisation der medizinischen Versorgung administrative Tätigkeiten durchführt – z.B. Arzthelferin, Patientenaufnahme. Sofern die administrati-ven Aufgaben automatisiert durchgeführt werden, kann die Person durch ein System ersetzt werden.

Der Begriff „Administrative Kraft“ wird im Rahmen des Projekts bIT4health als „funkti-onale“ Rolle verwendet.



2 In den Use Cases und Systemkontextdiagrammen wird an manchen Stellen zusätzlich eine Zuordnung der administrativen Kraft zu einem hierarchisch höhergestellten Akteur eingefügt, um Klarheit zu erzeugen, um wessen administrative Kraft es sich handelt.


3.6.3 Akteure in den Szenarios In den Szenarios werden Spezialisierungen der generischen Akteure verwendet:

Akteur Beschreibung Verwendet in Anwen-dungsszenario

Apotheker (Apo) Spezialisierung eines approbierten Heilberuflers


Verordnungseinlöser der Apotheke

Spezialisierung eines Verordnungseinlösers Verordnungsmanagement

ArzthelferIn (Ahe) Spezialisierung einer administrativen Kraft. Einbezogen in die Definition ist auch eine ZahnarzthelferIn.



3.6.4 Systeme als Akteure Neben den Akteuren, die als natürliche oder juristische Personen auftreten, gibt es weitere Akteure, die in der Form von IT-Systemen auftreten:

Akteur Beschreibung Verwendet in Anwen-dungsszenario

Primärsystem Das IT-System eines Leistungserbringers – eine Praxissoftware, ein Krankenhaus-Informationssystem (KIS), eine Apotheken- software, u.ä.




Übergreifende Funktion Einrichtung zur Kontrolle und Steuerung des Gesundheitswesens und potentiell der si-cheren Ablage von gesundheitsbezogenen Informationen.

Steuerungsmanagement


4 Anwendungsfälle Gesundheitskarte

4.1 Vertragsdatenmanagement

4.1.1 Anwendungsfalldiagramm

Abbildung 6: Use Case Diagramm Vertragsdatenmanagement

VD-1

Stammdaten mitteilen

VD-2 Vertragsdaten aktualisieren

VD-3 Patient identifizieren

VD-4 Vertragsdaten übernehmen

VD-5 Zahlungsbeteiligung in Rechnung stellen

VD-6 Zahlungsbeteiligung

leisten


quittieren


nachweisen

Admin. Kraft Admin. Kraft

Patient Patient Kranken-

versicherer Kranken- versicherer

Versicherter Versicherter

In der Rolle In der Rolle

«extend» «extend»


4.1.2 Generische Use Cases

4.1.2.1 Stammdaten mitteilen Use Case Nummer VD-1 Use Case Name Stammdaten mitteilen3 Initiierender Akteur Versicherter

Weitere Akteure Krankenversicherer4

Kurzbeschreibung Eine Änderung5 von Stammdaten (z.B. Änderung der An-schrift oder des Familiennamens) wird mitgeteilt

Vorbedingung Die Stammdaten eines Versicherten haben sich verän-dert.

Nachbedingung Der Krankenversicherer hat ein „Aktualisierungspaket6“ von Vertragsdaten in einem Änderungsbestand zur Ver-fügung gestellt.

Funktionalität des Use Cases

Ablauf 1. Der Versicherte teilt seinem Krankenversicherer die Än-derung der Stammdaten mit.

2. Der Krankenversicherer prüft die Identität des Mitteilen-den sowie seine Berechtigung, für weitere Personen Än-derungen mitteilen zu dürfen7.

3. Der Krankenversicherer verändert seinen Datenbestand. 4. Sofern die Mitteilung zu einer Änderung der gespeicher-

ten Vertragsdaten auf der eGK führt, werden sie als „Ak-tualisierungspaket“ in einen Änderungsbestand aufge-nommen.

5. Sofern die Mitteilung zu einer Änderung der aufgedruck-ten Daten der eGK führt, wird der Versicherte schriftlich aufgefordert, seine eGK zwecks Neuerstellung an den Krankenversicherer zurückzusenden. Hierbei erhält er eine vorübergehende Versicherungsbescheinigung.

3 Unter Stammdaten werden Personendaten verstanden, die durch den Versicherten bestimmt werden. Im Wesentlichen sind dies Name und Anschrift. Die Daten sind Teil der Vertragsdaten nach §291 SGB V/GMG. 4 Der generische Begriff „Krankenversicherer“ wird anstatt „Krankenkasse“ verwendet, um eine Öffnung der eGK für private Krankenversicherer zu ermöglichen. 5 Die Erstaufnahme der Stammdaten im Rahmen eines Vertragsabschlusses gehört zur Prozessgruppe „Kartenmanagement“. 6 Eine ähnliche Vorgehensweise mit „Aktualisierungspaketen“ ist in Behandlungsmanagement bei der nachträglichen Fort-schreibung von medizinischen Daten vorgesehen. 7 Ein gesetzlicher Vertreter kann Änderungen für Personen bekanntgeben, deren Interessen er vertritt. Implizit in dieser Prüfung ist das Thema der Bevollmächtigung.


Use Case Nummer VD-1 Alternativen Schritt 1: Stammdatenänderungen werden auch über andere

Austauschverfahren der gesetzlichen Krankenkasse mitge-teilt, z.B. durch die DEÜV (Arbeitgeber – Krankenkasse) Schritt 5. Da der beschriebene Ablauf verwaltungsintensiv ist, kann als Alternative die bisherige eGK nach Versand der neuen Karte maschinell gesperrt werden und braucht somit erst nach Erhalt der neuen eGK zurückgesendet werden.

Ausnahmen Keine

Benutzte Use Cases Keine

Weitere Information

Spezielle Anforde-rungen

Keine

Annahmen Keine

Offene Themen Keine

Referenzen § 291 SGB V/GMG

Datenanforderungen Vertragsdaten nach § 291 SGB V/GMG


Die neue eGK muss dem Versicherten zeitnah zugeschickt werden.

Ein Versäumnis der rechtzeitigen Meldung der Stammdaten an den Krankenversicherer darf nicht zur Leistungsverweigerung führen

4.1.2.2 Vertragsdaten aktualisieren Use Case Nummer VD-2 Use Case Name Vertragsdaten8 aktualisieren9 Initiierender Akteur Krankenversicherer 10 Weitere Akteure Keine

Kurzbeschreibung Die Vertragsdaten, die sich auf der eGK befinden, werden aktualisiert. Dieser Use Case ist eine Erweiterung des Use Case VD-4 Vertragsdaten übernehmen.

8 Vertragsdaten sind in erster Linie alle Daten, die in § 291 SGB V/GMG aufgeführt sind. 9 Hierunter ist das Einrichten und Ändern zu verstehen. Da es sich um eine Gesundheitskarte und nicht um eine Krankenversi-cherungskarte handelt, wird empfohlen, daß ein Kassenwechsel nicht zum Austausch der eGK sondern nur zu einem Aus-tausch der Vertragsdaten führt. Auch wenn der Versicherungsschutz nicht mehr in der GKV besteht, könnte die Gesundheitskarte ihre Gültigkeit behalten. In einem solchen Fall können entweder die GKV-Vertragsdaten mit einem Ende-Datum versehen oder durch Daten zu einem anderen Vertragsverhältnis ersetzt werden. 10 Der Krankenversicherer wird als initiierender Akteur betrachtet, da er das Aktualisierungspaket zur Verfügung stellt. Er wartet darauf, dass ein elektronischer Kontakt zu seinem System aufgebaut wird. Der Krankenversicherer kann einen Kartenverwalter mit dieser Aufgabe beauftragen.


Use Case Nummer VD-2 Vorbedingung Der Krankenversicherer hat ein „Aktualisierungspaket11“

von Vertragsdaten in einem Änderungsbestand zur Ver-fügung gestellt (VD-1).

Die eGK steht über die Telematikinfrastruktur zur Aktua-lisierung zur Verfügung.12

Nachbedingung Die Vertragsdaten sind aktualisiert.


Ablauf 1. Die Aktualität der Vertragsdaten auf der eGK wird durch einen Abgleich mit dem Änderungsbestand geprüft.

2. Bei fehlender Aktualität werden die Vertragsdaten auf der eGK durch Übernahme des Aktualisierungspakets auf den neuesten Stand gebracht.

3. Die Durchführung der Aktualisierung wird dem Kranken-versicherer elektronisch mitgeteilt.

Alternativen Keine

Ausnahmen Keine


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess „Vertragsdaten lesen und aktualisieren“ (VD 103) [b4hGPM] § 291 SGB V/GMG

Datenanforderungen Vertragsdaten gem. § 291 SGB V/GMG


Antwortzeitverhalten AZ 2 [b4hNFA]

4.1.2.3 Patient identifizieren Use Case Nummer VD-3 Use Case Name Patient identifizieren Initiierender Akteur Administrative Kraft

Weitere Akteure Patient

11 Eine ähnliche Vorgehensweise mit „Aktualisierungspaketen“ wird im Behandlungsmanagement bei der nachträglichen Fort-schreibung von medizinischen Daten vorgeschlagen. 12 Dies kann in den Räumen des Krankenversicherers oder bei einem Leistungserbringer sein


Use Case Nummer VD-3 Kurzbeschreibung Der Patient identifiziert sich gegenüber dem Leistungserbrin-

ger durch Vorlage der eGK.

Vorbedingung Patient möchte Leistungen in Anspruch nehmen

Nachbedingung Patient ist gegenüber Leistungserbringer identifiziert.


Ablauf 1. Die administrative Kraft des Leistungserbringers nimmt die eGK entgegen.

2. Die Identität des Patienten wird im Rahmen der Möglich-keiten, welche durch die eGK geboten werden, über-prüft.13

3. Die Identität wird eindeutig festgestellt.

Alternativen Schritt 1: Falls die eGK nicht vorliegt und der Patient nicht persönlich bekannt ist, muss die Identifizierung auf alternati-ve Weise erfolgen, bspw. durch Vorlage eines Ausweises. Schritt 2: Falls die eGK nicht vom Karteninhaber vorgelegt wird, muss die vorlegende Person in Abhängigkeit der weite-ren Prozessschritte glaubhaft machen, dass sie als dessen berechtigter Vertreter handelt.14

Ausnahmen Ist die Identität nicht zweifelsfrei zu ermitteln, liegt es im Er-messen des Leistungserbringers, den Patienten als Selbst-zahler zu behandeln. In einem Notfall, in dem eine akute Lebensgefahr bzw. Handlungsbedürftigkeit besteht, hat die Akutbehandlung Vor-rang vor der Identifizierung.


Weitere Information


Keine

Annahmen Keine

Offene Themen Die Vertreterregelung ist im Gesetz derzeit nicht geregelt. Im Rahmen der Lösungsarchitektur muss eine abschließende Lösung gefunden werden.

Referenzen Subprozess „Patient identifizieren“ (VD 201) [b4hGPM]

Datenanforderungen Keine

13 Zur Prüfung der Identität des Patienten wird zunächst das auf der Gesundheitskarte aufgebrachte Lichtbild und weitere elekt-ronisch gespeicherte Identifizierungsmerkmale (Name, Alter, Geschlecht) sowie das Authentifizierungszertifikat verwendet. Ggf. können später hier weitere Identitätsprüfungen erfolgen, mit denen z.B. anhand einer PIN oder zusätzlicher biometrischer Merkmale die Identität in höherem Maße festgestellt werden kann. 14 Diese Thematik ist im Gesetz derzeit nicht abschließend geregelt. Eine Möglichkeit ist die Einführung einer zweiten PIN, die vom Versicherten, beispielsweise bei der Abholung eines Rezeptes, an eine dritte Person gegeben werden kann.


Use Case Nummer VD-3 Nichtfunktionale Anforderungen

Keine

4.1.2.4 Vertragsdaten übernehmen Use Case Nummer VD-4 Use Case Name Vertragsdaten übernehmen Initiierender Akteur Administrative Kraft

Weitere Akteure Keine

Kurzbeschreibung Die Vertragsdaten des Versicherten werden in das Primär-system des Leistungserbringers übernommen.

Vorbedingung Patient ist gegenüber dem Leistungserbringer identifiziert (VD-3)

Nachbedingung Die Vertragsdaten liegen dem Leistungserbringer vor


Ablauf 1. Die Vertragsdaten auf der eGK werden gelesen. 2. Falls erforderlich und möglich erfolgt eine Aktualisierung

der Vertragsdaten (VD-2 Vertragsdaten aktualisieren) 3. Die Vertragsdaten werden in das Primärsystem über-

nommen.

Alternativen Schritt 1: Falls die Vertragsdaten nicht elektronisch gelesen werden können15 oder die eGK nicht vorliegt, liegt es im Er-messen des Leistungserbringers, entweder bekannte Daten zu verwenden oder den Patienten als Selbstzahler zu führen.

Ausnahmen Ist die eGK defekt, muss der Kartenverwalter informiert wer-den.

Benutzte Use Cases VD-2 Vertragsdaten aktualisieren

Weitere Information


Keine

Annahmen Es wird davon ausgegangen, dass es unerheblich ist, ob ein gültiges Versicherungsverhältnis besteht oder nicht, da es Aufgabe des Primärsystems ist, auf die übernommenen Da-ten zu reagieren (z.B. „Das Versicherungsverhältnis wurde zu einem bestimmten Datum beendet. Der Patient ist daher als Selbstzahler zu führen“).

Offene Themen Keine

15 Dabei ist es unerheblich, ob die eGK defekt ist oder das Informationssystem des Leistungserbringers nicht funktionsfähig ist.


Use Case Nummer VD-4 Referenzen Prozess „Vertragsdaten lesen und aktualisieren“ (VD 103)

[b4hGPM]

Datenanforderungen Vertragsdaten nach § 291 Abs. 2 SGB V/GMG



4.1.2.5 Zahlungsbeteiligung16 in Rechnung stellen Use Case Nummer VD-5 Use Case Name Zahlungsbeteiligung in Rechnung stellen Initiierender Akteur Administrative Kraft

Weitere Akteure Versicherter

Kurzbeschreibung Eine gegebenenfalls fällige Zahlungsbeteiligung für eine er-brachte Leistung wird in ihrer Höhe berechnet und vom Versi-cherten angefordert.

Vorbedingung Die erbrachte Leistung wird vom Leistungserbringer do-kumentiert und dient als Grundlage für die Zahlungsbetei-ligung.

Die Vertragsdaten mit den individuellen Zahlungsbeteili-gungsregelungen des Versicherten sind bekannt (VD-4).

Nachbedingung Der Versicherte ist zur Entrichtung einer Zahlungsbeteili-gung aufgefordert worden.

Oder Die Notwendigkeit einer Zahlungsbeteiligung liegt nicht

vor.


Ablauf 1. Die Zahlungsbeteiligungspflicht des Versicherten wird festgestellt; z.B. die Kosten sind grundsätzlich von der GKV zu übernehmen17, der Versicherte ist grundsätzlich zuzahlungspflichtig aber bis zum Ende des Kalenderjah-res zuzahlungsbefreit.

2. Die Höhe der Zahlungsbeteiligung gemäß Leistungsart wird festgestellt.

3. Der Versicherte wird aufgefordert, die Zahlungsbeteili-gung zu entrichten. Die Aufforderung kann entweder mündlich oder schriftlich erfolgen.

16 Die Zahlungsbeteiligung kann u.a. bestehen in einer vollen Kostenübernahme des Versicherten, unabhängig von einer Kos-tenerstattung bzw. einer Zuzahlungsverpflichtung gem. § 61 SGB V/GMG. 17 Es handelt sich nicht um Kosten, die von einem anderen Kostenträger (Berufsgenossenschaft, Gemeindeunfallversicherung, Bund, u.a.) übernommen werden.


Use Case Nummer VD-5 Alternativen Schritte 2 und 3 entfallen, sofern keine Pflicht zur Zahlungs-

beteiligung besteht.

Ausnahmen Keine


Szenarios VD-5-ZuZa1 Zuzahlung für ein Arzneimittel in Rechnung stellen

VD-5-ZuZa2 Zuzahlung für Heilmittel in Rechnung stellen

VD-5-ZuZa3 Zuzahlung für häusliche Krankenpflege in Rechnung stellen

VD-5-ZuZa4 Zuzahlung für med. Rehabilitation in Rechnung stel-len

Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess „Zahlung abwickeln” (VD 102) [b4hGPM]

Datenanforderungen Zuzahlungsbefreiungen (ggf. zeitlich begrenzt) Die Art der Rechnungsstellung


Keine

4.1.2.6 Zahlungsbeteiligung leisten Use Case Nummer VD-6 Use Case Name Zahlungsbeteiligung leisten Initiierender Akteur Versicherte


Kurzbeschreibung Die Zahlungsbeteiligung für eine Leistung wird vom Versi-cherten erbracht.

Vorbedingung Der Versicherte ist zur Entrichtung einer Zahlungsbeteili-gung aufgefordert worden (VD-5).

Nachbedingung Die Zahlungsbeteiligung ist vom Versicherten entrichtet worden.


Ablauf 1. Die Zahlungsbeteiligung wird durch den Versicherten auf unterschiedlichen Zahlungswegen18 geleistet.

Alternativen Keine

18 Da mehrere Inkassoverfahren bestehen, wird auf diesen Punkt nicht näher eingegangen.


Use Case Nummer VD-6 Ausnahmen Keine


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess „Zahlung abwickeln” (VD 102) [b4hGPM]



Keine

4.1.2.7 Zahlungsbeteiligung quittieren Use Case Nummer VD-7 Use Case Name Zahlungsbeteiligung quittieren Initiierender Akteur Administrative Kraft


Kurzbeschreibung Die Zahlungsbeteiligung wird quittiert, damit der Versicherte gegenüber seinem Krankenversicherer die Gesamthöhe der geleisteten Zahlungsbeteiligungen (z.B. Überschreitung der Belastungsgrenze bzw. Kostenerstattungsverfahren) nach-weisen kann.

Vorbedingung Die Zahlungsbeteiligung ist vom Versicherten geleistet worden (VD-6).

Nachbedingung Die Zahlungsbeteiligung ist quittiert.


Ablauf 1. Der Zahlungseingang der geleisteten Zahlungsbeteili-gung wird registriert.

2. Der Nachweis je geleisteter Zahlungsbeteiligung wird erstellt..

3. Dem Versicherten wird der Nachweis über eine geleiste-te Zahlungsbeteiligung ausgehändigt.


Use Case Nummer VD-7 Alternativen Schritt 2: Wenn möglich, sollte der Nachweis auf elektroni-

schem Wege erstellt und abgelegt werden. Als Speicherort kommt das Patientenfach in Frage. Von hier aus können sie ggf. zur Weiterverarbeitung elektronisch an die zuständige Instanz weitergeleitet werden (siehe Alternative VD-8). Zu-zahlungsquittungen können beispielsweise an die zuständi-ge Krankenkasse weitergeleitet werden, um den Prozess der Gewährung einer Zuzahlungsbefreiung zu unterstützen.

Ausnahmen Keine


Weitere Information


Annahmen Keine

Offene Themen Vorkehrungen müssen in der Lösungsarchitektur getroffen werden, um die Fälschung von elektronischen Nachweisen vorzubeugen, bspw. durch eine elektronische Signatur.

Referenzen Prozess „Zahlung abwickeln” (VD 102) [b4hGPM] Gemeinsames Rundschreiben (GR) der SpiK zum GMG vom 26.11.2003

Datenanforderungen Aus dem Nachweis muss hervorgehen: Der Vor- und Zuname des Versicherten Die Art der Leistung Die Höhe der Zahlungsbeteiligung Das Datum der Abgabe Die abgebende Stelle



4.1.2.8 Zahlungsbeteiligung nachweisen Use Case Nummer VD-8 Use Case Name Zahlungsbeteiligung nachweisen Initiierender Akteur Versicherter

Weitere Akteure Krankenversicherer

Kurzbeschreibung Nachweise über geleistete Zahlungsbeteiligungen werden beim Krankenversicherer eingereicht.

Vorbedingung Die Zahlungsbeteiligungen sind quittiert worden (VD-7).

Nachbedingung Der Nachweis der Zahlungsbeteiligung ist erbracht.


Use Case Nummer VD-8


Ablauf 1. Der Versicherte reicht seine Nachweise über geleistete Zahlungsbeteiligungen beim Krankenversicherer ein.

2. Der Krankenversicherer prüft die Nachweise und trifft entsprechende Entscheidungen – u.a. werden Kosten erstattet oder die Zuzahlungspflicht temporär aufgeho-ben.

Alternativen Schritt 1: Ein elektronisch übermittelter Nachweis bringt er-hebliche Vorteile sowohl für den Versicherten als auch für den Krankenversicherer mit sich. Für alle Beteiligten kann zeitnah eine Zahlungsbeteilungsübersicht erstellt werden. Dies kann auch als Wettbewerbsvorteil genutzt werden.

Ausnahmen Keine


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Dieser Use Case hat keine Referenz zum Geschäftspro-zessmodell. Die Nachweiserbringung ist Bestandteil eines internen Prozesses eines Krankenversicherers zur Prüfung der Belastungsgrenze. Der Use Case wird aufgeführt, um die Vorteile einer elektronischen Quittierung hervorzuheben.

Datenanforderungen Nachweisdaten


Keine


4.1.3 Szenarios Die Szenarios betreffen die Feststellung von Zuzahlungen (als eine Ausprägung einer Zah-lungsbeteiligung) unterschiedlicher Art nach § 61 SGB V. Sie illustrieren die unterschiedli-chen Abläufe je nach Art der Zuzahlung. Zuzahlungen werden nur für Leistungen erhoben, deren Kosten von der GKV übernommen werden. Ein Arzneimittel, das als Folge eines Ar-beitsunfalls verordnet wird, dessen Kosten von einer Berufsgenossenschaft übernommen werden, ist auch für einen gesetzlich Versicherten nicht zuzahlungspflichtig.

4.1.3.1 Zuzahlung für ein Arzneimittel in Rechnung stellen Use Case Nummer VD-5-ZuZa1 Use Case Name Zuzahlung für ein Arzneimittel in Rechnung stellen Initiierender Akteur Administrative Kraft (der Apotheke)


Kurzbeschreibung Für ein verschreibungspflichtiges Arzneimittel wird in einer Apotheke eine Zuzahlung berechnet und vom zuzahlungs-pflichtigen Versicherten eingefordert19.

Vorbedingung Eine Arznei-VO für ein verschreibungspflichtiges Arznei-mittel ist in einer Apotheke eingelöst worden.

Nachbedingung Eine Zuzahlung für ein Arzneimittel wird vom zuzahlungs-pflichtigen Versicherten eingefordert.

Oder Eine Zuzahlung wird nicht erhoben.


Ablauf 1. Die administrative Kraft der Apotheke stellt die Zuzah-lungspflicht anhand der Verordnung20 fest.

2. Die Höhe der Zuzahlung für das Arzneimittel wird im Primärsystem der Apotheke festgestellt21.

3. Der Versicherte wird aufgefordert, die Zuzahlung zu leis-ten.

Alternativen Schritte 2 und 3 werden nicht durchgeführt, weil keine Zuzahlungspflicht besteht.

Ausnahmen Keine


Weitere Information


Keine

Annahmen Keine

19 Der Zuzahlungsbetrag wird mit der Krankenkasse verrechnet. 20 Der Verordnungsgeber muss den Kostenträger für ein verordnetes Arzneimittel festlegen (vgl. Use Case VO-1 „Verord-nung/Überweisung erfassen“. 21 Der Algorhythmus für die Berechnung der Zuzahlungshöhe wird hier nicht aufgeführt.


Use Case Nummer VD-5-ZuZa1 Offene Themen Keine

Referenzen Keine

Datenanforderungen Information über das dispensierte Arzneimittel.


Keine

4.1.3.2 Zuzahlung für Heilmittel in Rechnung stellen Use Case Nummer VD-5-ZuZa2 Use Case Name Zuzahlung für Heilmittel in Rechnung stellen Initiierender Akteur Administrative Kraft (des Leistungserbringers)


Kurzbeschreibung Für ein verordnetes Heilmittel wird eine Zuzahlung berechnet und vom zuzahlungspflichtigen Versicherten eingefordert 22.

Vorbedingung Eine Heilmittel-VO für ein verschreibungspflichtiges Heil-mittel ist bei einem Leistungserbringer eingelöst worden.

Nachbedingung Eine Zuzahlung für die Heilmittel wird vom Patienten ein-gefordert.



Ablauf 1. Die administrative Kraft des Leistungserbringers (Physio-therapeuten) stellt die Zuzahlungspflicht anhand der Ver-ordnung fest.

2. Handelt es sich um den ersten Besuch in einer Serie von Behandlungen (z.B. 5 Massagen sind verordnet worden), wird die Verordnungsblattgebühr (10,00 €) erhoben.

3. Der Zuzahlungsbetrag je geleisteter Massage wird er-rechnet.

4. Der zuzahlungspflichtige Versicherte wird aufgefordert, die Zuzahlung zu leisten.

Alternativen Schritte 2 bis 4 werden nicht durchgeführt, weil keine Zuzah-lungspflicht besteht.


Weitere Information


Keine

Annahmen Keine

22 Der Zuzahlungsbetrag wird mit der Krankenkasse verrechnet.


Use Case Nummer VD-5-ZuZa2 Offene Themen Keine

Referenzen Keine

Datenanforderungen Informationen über die erbrachte Leistung


Keine

4.1.3.3 Zuzahlung für häusliche Krankenpflege in Rechnung stellen Use Case Nummer VD-5-ZuZa3 Use Case Name Zuzahlung für häusliche Krankenpflege in Rechnung

stellen Initiierender Akteur Administrative Kraft (der gesetzlichen Krankenkasse)

Weitere Akteure Leistungserbringer Versicherter

Kurzbeschreibung Die gesetzliche Krankenkasse stellt eine Zuzahlung für die Durchführung einer verordneten häuslichen Krankenpflege in Rechnung

Vorbedingung Eine verordnete und von der gesetzlichen Krankenkasse genehmigte häusliche Krankenpflege ist durchgeführt worden.

Nachbedingung Eine Zuzahlung für die häusliche Krankenpflege wird vom Patienten eingefordert.



Ablauf 1. Die gesetzliche Krankenkasse erhält eine Rechnung von einem Pflegedienst (dem Leistungserbringer) für die häusliche Krankenpflege eines Versicherten.

2. Die gesetzliche Krankenkasse stellt die Zuzahlungspflicht des Versicherten fest.

3. Die gesetzliche Krankenkasse errechnet anhand der eingereichten Rechnung den Zuzahlungsbetrag.

4. Der Versicherte wird schriftlich aufgefordert, die Zuzah-lung zu leisten.



Weitere Information


Keine


Use Case Nummer VD-5-ZuZa3 Annahmen Es wird davon ausgegangen, dass die Rechnung der gesetz-

liche Krankenkasse gleichzeitig als Quittung dient. Offene Themen Keine

Referenzen Keine

Datenanforderungen Informationen über die geleistete häusliche Krankenpflege


Keine

4.1.3.4 Zuzahlung für med. Rehabilitation in Rechnung stellen Use Case Nummer VD-5-ZuZa4 Use Case Name Zuzahlung für med. Rehabilitation in Rechnung stellen. Initiierender Akteur Administrative Kraft (der Reha-Einrichtung)


Kurzbeschreibung Für eine durchgeführte Rehabilitationsmaßnahme wird eine Zuzahlung durch die Reha-Einrichtung in Rechnung ge-stellt23.

Vorbedingung Eine durch die gesetzliche Krankenkasse genehmigte Rehabilitationsmaßnahme wurde durchgeführt.

Nachbedingung Eine Zuzahlung für eine Rehabilitationsmaßnahme wird vom Patienten eingefordert.

oder Eine Zuzahlung wird nicht erhoben.


Ablauf 1. Die Reha-Einrichtung stellt die Zuzahlungspflicht des Versicherten fest.

2. Der Zuzahlungsbetrag wird durch die Reha-Einrichtung errechnet.

3. Der Zuzahlungsbetrag wird vom zuzahlungspflichtigen Versicherten eingefordert.



Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

23 Der Zuzahlungsbetrag wird nach Erhalt von der Einrichtung an die Krankenkasse weitergeleitet.


Use Case Nummer VD-5-ZuZa4 Referenzen Keine

Datenanforderungen Informationen zu der Rehabilitationsmaßnahme


Keine

4.1.4 Übersicht Zuzahlungsregelungen24 Zuzahlungen bei Regelungen Hinweise

... Arztbesuch Praxisgebühr von 10 EUR pro Quartal beim Arzt oder Zahnarzt

Überweisungen:

Wer von einem Arzt zu einem anderen Arzt überwiesen wird, zahlt dort keine Praxisgebühr mehr, wenn der zweite Arztbe-such in dasselbe Quartal fällt.

10 EUR pro Quartal bedeutet:

egal, wie oft man zu einem Arzt geht, und egal, zu wie vielen Ärz-ten man (mit Überweisung) geht: man zahlt insgesamt nicht mehr als 10 EUR Praxisgebühr inner-halb eines Quartals.

Einzug der Praxisgebühr:

Die zu entrichtende Praxisgebühr wird verrechnet.

... Arzneimitteln und Verbandmitteln

Zuzahlung von 10% des Prei-ses, jedoch mindestens 5 EUR und maximal 10 EUR pro Arz-neimittel. In jedem Fall nicht mehr als die Kosten des Mittels.

Einzug der Zuzahlung:

Die Zuzahlungsbeträge werden mit der Krankenkasse verrechet.

... Heilmitteln

Zuzahlung von 10% der Kosten des Mittels zuzüglich 10 EUR je Verordnung (bei häuslicher Kranken- pflege auf 28 Tage pro Kalenderjahr begrenzt)


Die Verordnungsgebühr und der Zuzahlungsbetrag werden mit der Krankenkasse verrechnet.

... Hilfsmitteln Zuzahlung von 10% für jedes Hilfsmittel (z.B. Hörgerät, Roll-stuhl), jedoch mindestens 5 EUR und maximal 10 EUR. In jedem Fall nicht mehr als die Kosten den Mittels.


Der Zuzahlungsbetrag wird mit der Krankenkasse verrechnet.

... Soziotherapie, Inanspruchnahme einer

Zuzahlung von 10% der kalen-dertäglichen Kosten, jedoch höchstens 10 EUR und mindes-


Die Krankenkasse ist für den Ein-zug der Zuzahlung zuständig

24 Stand 31.01.2004


Haushaltshilfe tens 5 EUR zug der Zuzahlung zuständig.

Rechnungsstellung erfolgt durch die Krankenkasse.

… häuslicher Krankenpflege

Zuzahlung von 10% der Kosten des Mittels zuzüglich 10 EUR je Verordnung (bei häuslicher Kranken- pflege auf 28 Tage pro Kalenderjahr begrenzt)


Die Krankenkasse ist für den Ein-zug der Zuzahlung zuständig.

Rechnungsstellung erfolgt durch die Krankenkasse.

… Fahrkosten

Zuzahlung von 10% des Fahr-preises, jedoch mindestens 5 EUR und maximal 10 EUR je Fahrt.

Versicherte, die das 18. Le-bensjahr noch nicht vollendet haben, sind ebenfalls zuzah-lungspflichtig.


Bei Fahrten mit Rettungsdiensten (in Verbindung mit § 60 Abs. 1 SGB V) berechnet die Kranken-kasse den Zuzahlungsbetrag und stellt diese dem Versicherten in Rechnung. Der Einzug des Betra-ges erfolgt ebenfalls durch die Krankenkasse.

... der stationären Behandlung und AHB / AR

Zuzahlung von 10 EUR pro Tag, begrenzt auf 28 Tage in Kalenderjahr.


Die Versicherten haben den Zu-zahlungsbetrag an die Einrichtung zu entrichten. Diese führt dann den Zuzahlungsbetrag an die Kranken-kasse ab.

... der ambulanten und stationären Rehabilitation (Vorsorge)

... der medizinischen Rehabilitation für Mütter und Väter

Zuzahlung von 10 EUR pro Tag Einzug der Zuzahlung:

Die Versicherten haben den Zu-zahlungsbetrag an die Einrichtung zu entrichten. Diese führt dann den Zuzahlungsbetrag an die Kranken-kasse ab.


4.2 Verordnungsmanagement

4.2.1 Anwendungsfalldiagramm25

VO-2Übergabe-Dokument

zusammenstellen


signieren


auf Datenträger aufbringen

VO-5Verordnung/

Überweisung einreichen

VO-6Verordnung/

Überweisung übernehmen


entwerten

PatientPatient

Admin. KraftAdmin. Kraft

VerordnungsgeberVerordnungsgeber

VerordnungsgeberVerordnungsgeber

VO-1Verordnung/Überweisung

erfassen

VO-Geber beschäftigtVO-Geber beschäftigt

VerordnungseinlöserVerordnungseinlöser

Abbildung 7: Use Case Diagramm Verordnungsmanagement

25 Die Assoziationen zwischen Akteuren sind nicht methodenkonform. Sie verdeutlichen lediglich, um wessen administrative Kraft es sich handelt.


4.2.2 Generische Anwendungsfälle

4.2.2.1 Verordnung/Überweisung erfassen Use Case Nummer VO-1 Use Case Name Verordnung/Überweisung erfassen Initiierender Akteur Verordnungsgeber

Weitere Akteure Administrative Kraft

Kurzbeschreibung Einzelleistungen, die bei einem weiteren, zwar kategorisier-ten aber nicht individualisierten26 Leistungserbringer erbracht werden sollen, werden verordnet.

Vorbedingung Die Notwendigkeit einer externen Fortsetzung der Be-handlung durch den Verordnungsgeber ist festgestellt worden.

Die medizinische Verordnungsfähigkeit ist durch den Verordnungsgeber geprüft worden (bspw. für Medika-mente durch Kontraindikations- und Interaktionschecks).

Nachbedingung Verordnung/Überweisung ist beim Verordnungsgeber erfasst.


26 § 24 Abs. 5 Bundesmantelvertrag – Ärzte [BMV-Ä] lässt Ausnahmen zur freien Arztwahl zu: „Zur Gewährleistung der freien Arztwahl soll die Überweisung nicht auf den Namen eines bestimmten Vertragsarztes, sondern auf die Gebiets-, Teilgebiets- oder Zusatzbezeichnung ausgestellt werden, in deren Bereich die Überweisung ausgeführt werden soll. Eine namentliche Überweisung kann zur Durchführung bestimmter Untersuchungs- oder Behandlungsmethoden an hierfür ermächtigte Ärzte bzw. ermächtigte ärztlich geleitete Einrichtungen erfolgen".


Use Case Nummer VO-1 Ablauf 1. Der Kostenträger der Verordnung wird bestimmt27. Der

Kostenträger ist nicht automatisch die gesetzliche Kran-kenkasse. Es kann sich bspw. handeln um:

(verschreibungspflichtige) Verordnungen für einen Selbstzahler;

Verordnungen, deren Kosten von einer Berufsgenossen-schaft als Folge eines Arbeitsunfalls getragen werden – siehe offenes Thema;

Verordnungen, deren Kosten von der Gemeindeunfall-versicherung als Folge eines Schulunfalls getragen wer-den;

Verordnungen, deren Kosten vom Bund (mittels eines Bundesbehandlungsscheins) als Folge einer Kriegsver-letzung getragen werden.

2. Abhängig von der Art der Verordnung (Arznei-VO, BTM-VO, Überweisung zu einem weiteren Arzt, Einweisung in eine stationäre Einrichtung) werden die notwendigen De-tails der Verordnung (einschl. verordnungsbegleitende Informationen28) im Informationssystem des Verord-nungsgebers erfasst.

Alternativen Keine. Ggf. ergeben sich spezielle Alternativen im Szenario.

Ausnahmen Keine. Ggf. ergeben sich spezielle Ausnahmen im Szenario.


Szenarios VO-1-AVO Arzneimittel-VO erfassen

Weitere Information


Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.

Annahmen Keine. Ggf. ergeben sich spezielle Annahmen im Szenario.

27 Informationen zum Kostenträger werden auf Verordnungsebene und nicht auf Rezeptebene gemacht, um eine Differenzie-rung innerhalb eines Rezeptes zu machen. Hiermit können bspw. medizinisch notwendige Verordnungen zusammen mit Ver-ordnungen, die der persönlichen Lebensführung dienen (z.B. Anti-Baby-Pille), auf einem Rezept aufgebracht werden. Solche Zusammenfassungen sind allerdings nur in Verbindung mit elektronischen Rezepten möglich, da die bisherigen Rezeptvordru-cke hierfür nicht geeignet sind. 28 Z.B. Einnahme-Anweisungen für ein Arzneimittel.


Use Case Nummer VO-1 Offene Themen Ein Verordnungsgeber hat bei der Erstellung einer Verord-

nung die Aufgabe, den Kostenträger zu bestimmen. Diese Aufgabe kann bei Arbeitsunfällen aufwendig sein, da u.a. die Berufsgenossenschaft, die für den Arbeitnehmer zuständig ist, ermittelt werden muss. Es ist zu überlegen, ob nicht die-se Information auf der eGK geführt werden kann. Ferner können Verordnungen als Folge von weit zurücklie-genden Ursachen wie Arbeitsunfällen, Berufskrankheiten oder Kriegsschäden erstellt werden. Jede Ursache hat einen festgelegten Kostenträger. Die Führung von solchen histori-schen Ursachen in Verbindung mit der eGK kann die Ermitt-lung des Kostenträgers durch den Verordnungsgeber eben-falls erleichtern.

Referenzen Prozess „eÜbergabe-Dokument schreiben“ (VO 101) [b4hGPM]

Datenanforderungen Allgemein gültige Verordnungsdaten – Kostenträger und Art der Verordnung.



4.2.2.2 Übergabe-Dokument zusammenstellen Use Case Nummer VO-2 Use Case Name Übergabe-Dokument zusammenstellen Initiierender Akteur Administrative Kraft


Kurzbeschreibung Ein Übergabe-Dokument wird aus den Daten der Verord-nungen/Überweisung zusammengestellt. Dabei wird der Typ dieses Dokuments festgelegt und ggf. die Verordnungen in mehreren Einzelpositionen vermerkt.

Vorbedingung Verordnung/Überweisung ist erfasst (VO-1).

Nachbedingung Das Übergabe-Dokument ist im Primärsystem des Ver-ordnungsgebers zusammengestellt.


Use Case Nummer VO-2


Ablauf 1. Ein Übergabe-Dokument29 wird mit einer eindeutigen Identifikation angelegt.

2. Informationen der Verordnungen/Überweisung, die in das Übergabe-Dokument übernommen werden sollen, wer-den in das Dokument übertragen.30 Im Falle, dass meh-rere Verordnungen in einem Übergabe-Dokument zu-sammengefasst werden sollen, werden diese als Einzel-positionen angelegt.

3. Angaben zum Verordnungsgeber werden übertragen, damit der Leistungserbringer einen Adressat für Rückfra-gen hat.

Alternativen Schritt 1: Die eindeutige Identifikation wird extern angefordert (speziell: Sicherheitsmerkmal für ein BTM-Rezept). Schritt 3: Die Daten zum Patienten befinden sich auf der eGK. Sofern die Verordnung nicht auf der eGK gespeichert wird, müssen zusätzlich auch die Angaben zum Patienten übertragen werden.

Ausnahmen Keine. Ggf. ergeben sich spezielle Ausnahmen im Szenario.


Szenarios VO-2-AVO Arznei-Rezept zusammenstellen

Weitere Information




29 Das Übergabe-Dokument ist der Träger für Verordnungen/Überweisungen eines Verordnungsgebers an einen Leistun-gerbringer. Es ist an dieser Stelle unerheblich, ob es sich bei dem erwähnten Datenträger um die eGK, ein zentrales IT-System oder sogar um das Papierrezept handelt. Die eindeutige Identifikation kommt allerdings nur bei elektronischen Medien (und BTM-Rezepten) vor. 30 Eine Auswahlmöglichkeit wird vorgesehen, damit Verordnungen auch selektiv zusammengefaßt werden können. Dies ist u.a. wegen der jetzigen zweckgebundenen Vordrucke notwendig.


Use Case Nummer VO-2 Offene Themen Die bisherigen Übergabedokumente auf Papier dienten z.T.

als Grundlage für die Abrechnung der verordneten Leistun-gen mit den gesetzlichen Krankenkassen. Daher war deren Verwendung enge Grenzen gesetzt. Verschreibungspflichti-ge Medikamente erschienen entweder auf einem Kassenre-zept oder auf einem Privatrezept. Ein Kassenrezept mit meh-reren Arznei-VO konnte nur in einer Apotheke eingelöst wer-den. Ein elektronisches Übergabedokument ermöglicht die Be-freiung von solchen Restriktionen. Verschiedenartige Ver-ordnungen (sowohl bzgl. der Kostenträgerschaft als auch bzgl. der Art) können in einem Übergabe-Dokument zusam-mengefasst werden. Die Use Cases widerspiegeln diese Befreiung, schließen aber die restriktivere Vorgehensweise - z.B. im Rahmen ei-ner ersten Implementierung - nicht aus.


Datenanforderungen Die Kopfdaten des Übergabedokuments, die den Verord-nungsgeber und Dokument identifizieren. Die Daten für die einzelnen Einträge im Übergabedokument in ihrem von der Verordnungsart abhängigen Format.



Anmerkungen für die Umsetzung: Dieser Anwendungsfall wird bereits derzeit, aber auch in Zukunft wahrscheinlich durch die Systeme des Verordnungsgebers IT-technisch unterstützt. Im Hinblick auf die Zusammenar-beit von Telematikinfrastruktur und dem System des Verordnungsgebers ergeben sich hauptsächlich notwendige Festlegungen für die Datenformate. Die Telematikinfrastruktur wird für diesen Anwendungsfall ggf. unterstützende Services bereitstellen.

4.2.2.3 Übergabe-Dokument signieren Use Case Nummer VO-3 Use Case Name Übergabe-Dokument signieren Initiierender Akteur Verordnungsgeber


Kurzbeschreibung Ein Übergabe-Dokument wird signiert.


Use Case Nummer VO-3 Vorbedingung Übergabe-Dokument ist im Primärsystem des Verord-

nungsgebers zusammengestellt (VO-2). Beim Datenträger Papier muss das Dokument vorher

gedruckt worden sein.

Nachbedingung Übergabe-Dokument ist signiert.


Ablauf 1. Das Dokument wird vom Verordnungsgeber (elektronisch mit qualifizierter Signatur) signiert.

Alternativen Schritt 1: Bei einem Übergabe-Dokument auf Papier erfolgt die Signatur handschriftlich

Ausnahmen Sollte es bei der qualifizierten elektronischen Signatur zu einem Fehler kommen, so ist der papiergebundene Pro-zessweg im Weiteren zu verfolgen.


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess „eÜbergabe-Dokument schreiben“ (VO 101) [b4hGPM] § 291a, Abs. 4 und 5 SGB V/GMG

Datenanforderungen (elektronische) Signatur


Antwortzeitverhalten: AZ1 [b4hNFA]

4.2.2.4 Übergabe-Dokument auf einen Datenträger aufbringen Use Case Nummer VO-4 Use Case Name Übergabe-Dokument auf einen Datenträger aufbringen Initiierender Akteur Administrative Kraft31


Kurzbeschreibung Ein Übergabe-Dokument wird auf einen Datenträger – in erster Linie die eGK - aufgebracht und dem Patienten über-geben.

31 Laut §291a Abs. 4 SGB V/GMG dürfen nur Ärzte bzw. Zahnärzte Verordnungen erstellen. Dieser Use Case beschreibt den administrativen Schritt des physischen Erstellens des Übergabe-Dokuments. Es ist zu klären, ob dieser Schritt von einer admi-nistrativen Kraft durchgeführt werden darf.


Use Case Nummer VO-4 Vorbedingung Übergabe-Dokument ist im Primärsystem des Verord-

nungsgebers zusammengestellt (VO-2) Bei einem elektronischen Datenträger muss das Doku-

ment vorher signiert sein (VO-3).

Nachbedingung Das Übergabe-Dokument ist an den Patienten überge-ben worden.


Ablauf 1. Die Art des Datenträgers wird bestimmt. Wenn beim Verordnungsgeber kein Primärsystem zur

Verfügung steht, womit ein elektronisches Übergabe-Dokument geschrieben werden kann, muss sichergestellt sein, dass der Patient es als Papierdokument erhält.

Wenn die berechtigte Annahme besteht, dass der an-nehmende Leistungserbringer kein Primärsystem im Ein-satz hat, womit elektronische Dokumente gelesen wer-den können, muss sichergestellt sein, dass der Patient das Übergabe-Dokument als Papierdokument erhält.

2. Das Dokument wird auf einen, dem Patienten direkt zu-geordneten Datenträger (in der Regel die eGK) aufge-bracht.

3. Der Inhalt eines auf einem elektronischen Datenträger gespeicherten Übergabe-Dokuments wird auf Papier (als „Übergabe-Dokument-Quittung32“) ausgegeben, damit der Patient einen schriftlichen Nachweis über die verord-neten Leistungen hat. Die vergebenen Kennungen sind Bestandteile des Ausdrucks und ermöglichen eine ma-nuell angesteuerte Übernahme und/oder nachträgliche Entwertung der Verordnung bzw. des gesamten Überga-be-Dokuments. Der Ausdruck (die Übergabe-Dokument-Quittung) darf nicht unterschrieben werden.

4. Übergabe-Dokument und Quittung werden dem Patien-ten übergeben33.

Alternativen Schritt 2: Ist der Datenträger ein anderer als die eGK selbst (z.B. server-basierend), wird eine auf das Übergabe-Dokument hinweisende Referenz auf die eGK aufgebracht. Schritt 3 entfällt bei Verwendung des Datenträgers „Papier“.

32 Die Quittung ist eine „Hard Copy“ des elektronischen Dokuments. Sie stimmt im Aufbau nicht mit einem herkömmlichen Pa-pierrezept überein. 33 Unabhängig von der Art der technischen Realisierung der Speicherung im elektronischen Fall wird dem Patienten seine elektronische Gesundheitskarte und damit ein wichtiges Hilfsmittel für den Zugriff auf das elektronsiche Übergabe-Dokument übergeben.


Use Case Nummer VO-4 Ausnahmen Bei einem Hausbesuch kann das Übergabe-Dokument voll-

kommen handschriftlich erstellt werden. Die enthaltenen Verordnungen müssen bei der Rückkehr in die Praxis vom Verordnungsgeber nachträglich im Primärsystem erfasst werden. Alternativ können bei Hausbesuchen mobile Erfas-sungs- und Ausgabegeräte eingesetzt werden. Sollte es bei der Aufbringung des elektronischen Übergabe-Dokuments zu einem Fehler kommen, so ist der papierge-bundene Prozessweg im Weiteren zu verfolgen.


Weitere Information



Annahmen Keine

Offene Themen Keine


Datenanforderungen Keine. Die Datenanforderungen an das Übergabe-Dokument sind in den vorhergehenden Use Cases erwähnt worden.



4.2.2.5 Verordnung/Überweisung einreichen Use Case Nummer VO-5 Use Case Name Verordnung/Überweisung einreichen Initiierender Akteur Patient

Weitere Akteure Verordnungseinlöser 34

Kurzbeschreibung Ein gesamtes Übergabe-Dokument oder einzelne Positionen eines Übergabe-Dokuments werden von einem Patienten bei einem Leistungserbringer zur Einlösung eingereicht.35

Vorbedingung Das Übergabe-Dokument ist an den Patienten überge-ben worden (VO-4)

Nachbedingung Das gesamte Übergabe-Dokument oder einzelne Positi-onen eines Übergabe-Dokuments stehen bei einem Leis-tungserbringer zur Einlösung zugriffsbereit.

34 Ein Verordnungseinlöser ist berechtigt, bei einem Leistungserbringer Verordnungen entgegenzunehmen. 35 Abhängig von der Art des Übergabe-Dokuments kann entweder nur das gesamte Übergabe-Dokument (z.B. Überweisung) oder ggf. Einzelpositionen (z.B. Rezept) eingelöst werden.


Use Case Nummer VO-5 Funktionalität des Use Cases

Ablauf 1. Der Patient nimmt Kontakt mit der Einrichtung auf, in der er die Verordnung einlösen möchte.

2. Der Patient bestimmt (im Rahmen der technischen Mög-lichkeiten), welches Übergabe-Dokument bzw. welche of-fenen36 Positionen eines Übergabe-Dokuments er vom Leistungserbringer eingelöst haben möchte37. Im Rah-men seiner Selbstbestimmung kann der Patient ent-scheiden, Verordnungen/Überweisungen gar nicht bzw. bei verschiedenen Leistungserbringern einzulösen.

3. Die Echtheit des Übergabe-Dokumentes wird durch Vali-dierung der Signatur des Verordnungsgebers geprüft.

4. Der Verordnungseinlöser erhält nach Authentifizierung Zugriff auf die ausgewählte(n) Verordnung(en) / die Überweisung.

Alternativen Schritt 1 kann sich entweder auf einen „konventionellen“ o-der auf einen über elektronische Medien (wie Internet) er-reichbaren Leistungserbringer beziehen. Im Schritt 4 kann der Patient den notwendigen Zugriff auf elektronisch geführte Verordnung(en)/Überweisung durch ein geeignetes technisches Verfahren autorisieren (vgl. § 291a Abs. 5 SGB V, letzter Satz). Hiermit entfällt die Authentifizie-rung des Leistungserbringers bei der Übernahme der Ver-ordnung/Überweisung in dessen System.

Ausnahmen Wenn die Verordnung in elektronischer Form nicht über-nommen werden kann, so steht das papiergebundene Ver-fahren als Ersatzverfahren zur Verfügung. Der Patient hat vom Verordnungsgeber eine Übergabe-Dokument-Quittung erhalten, welche für den weiteren Ablauf als Original ver-wendet werden kann. Der Verordnungseinlöser überprüft die Richtigkeit der Übergabe-Dokumenten-Quittung und doku-mentiert dies durch Unterschrift auf dem Papierdokument. Die nachträgliche Entwertung des elektronischen Übergabe-dokuments ist auszulösen38.

36 Eine offene Position bedeutet, dass eine verordnete Einzelposition noch nicht in verordneter Höhe vom Patienten eingelöst worden ist, z.B. von den verordneteten 2 Packungen Anti-Baby-Pille ist nur eine Packung abgefordert worden; von den verord-neten 10 Massagen sind nur 3 abgefordert worden. Die noch offene Teilmenge kann anderweitig eingelöst werden. 37 Die Auswahl soll vom Patienten ohne Einsicht des Leistungserbringers auf andere Positionen des Übergabedokuments erfol-gen können. Dies schließt nicht aus, dass der Patient die Einsicht gewähren kann. 38 Das hier beschriebene Ausnahmeverfahren soll für alle Ausfallszenarien gelten (die mit einer Verordnung versehene eGK geht verloren, technische Probleme beim Verordnungseinlöser,usw.) und verfolgt das primäre Ziel, dass ein Patient das Verord-nete so schnell wie möglich erhält. Dies geht zu Lasten der Sicherheit. Die Quittung wird bei der Erstellung der elektronischen Verordnung durch den Verordnungsgeber nicht unterschrieben, um eine Parallelität zur eGK zu vermeiden. Ihre Echtheit kann beispielsweise durch einen Rückruf beim Verordnungsgeber erfolgen. Die nachträgliche Entwertung ist ebenfalls schwierig, sofern das Übergabe-Dokument ausschließlich auf der eGK gespeichert ist.


Use Case Nummer VO-5 Benutzte Use Cases Keine

Szenario VO-5-AVO Arznei-VO in einer Apotheke einreichen

Weitere Information



Annahmen Keine

Offene Themen Keine

Referenzen Prozess „Verordnung einlösen“ (VO 102) [b4hGPM] § 291a, Abs. 5 SGB V/GMG, bzgl. Autorisierung durch den Patienten

Datenanforderungen Daten für Verordnung / Überweisung nach dem jeweiligen Format



4.2.2.6 Verordnung/Überweisung übernehmen Use Case Nummer VO-6 Use Case Name Verordnung/Überweisung übernehmen Initiierender Akteur Verordnungseinlöser


Kurzbeschreibung Eine Verordnung / Überweisung wird vom Verordnungseinlö-ser angenommen und auf Einlösbarkeit geprüft. Sofern die Prüfung positiv verläuft und die Leistung erbracht werden kann, wird die Verordnung / Überweisung als „eingelöst“ ge-kennzeichnet. Im Falle einer Teileinlösung werden die Ein-zelpositionen als solche gekennzeichnet. Mit der Einlösung eines gesamten Übergabe-Dokuments erfolgt dessen Ent-wertung. Die Erbringung der Leistung erfolgt im Rahmen der Prozess-gruppe „Behandlungsmanagement“.

Vorbedingung Eine oder mehrere Verordnungen / Überweisungen ste-hen bei einem Leistungserbringer zur Einlösung zugriffs-bereit (VO-5).

Sofern die Vertragsdaten des Versicherten für den weite-ren Prozessablauf notwendig sind (bspw. für eine Ab-rechnung mit der gesetzlichen Krankenkasse), liegen sie dem Leistungserbringer vor.


Use Case Nummer VO-6 Nachbedingung Verordnung / Überweisung ist als „eingelöst“ gekenn-

zeichnet oder Verordnung / Überweisung ist als „teileingelöst“ gekenn-

zeichnet oder Verordnung / Überweisung ist nicht übernommen, da

Leistung nicht durchführbar oder Verordnung / Überweisung ist wegen Ungültigkeit nicht

übernommen.


Ablauf 1. Der Lesezugriff des Verordnungseinlösers auf die Ver-ordnung / Überweisung wird protokolliert.

2. Die Echtheit des Übergabe-Dokuments wird geprüft. Ei-nerseits ist die Integrität des Dokuments in Bezug auf die qualifizierte Signatur zu prüfen, andererseits die Mehr-facheinlösung/-abrechnung (durch unerlaubtes Kopieren) auszuschließen.

3. Die Ordnungsmäßigkeit der Verordnung / Überweisung wird geprüft. Sie muss zeitlich gültig und noch „offen“ (noch nicht eingelöst) sein.

4. Die Verfügbarkeit der Leistung39 wird geprüft. Kann die Leistung nicht in einer für den Patienten zufriedenstel-lenden Zeit eingelöst werden, besteht keine Notwendig-keit der Einlösung.

5. Die Daten der Verordnung / Überweisung werden in das Primärsystem übernommen.

6. Die Verordnung wird als „eingelöst“ gekennzeichnet40. Sie kann dadurch nicht nochmals zur Einlösung vorge-legt werden.

39 Bspw. könnte das verordnete Arzneimittel nicht vorhanden sein oder eine verordnete Massage kann nicht innerhalb eines – für den Patienten – akzeptablen Zeitrahmens durchgeführt werden. 40 Die Verordnung wird erst nach Übernahme in das Primärsystem als „eingelöst" gekennzeichnet. Ansonsten kann ein defektes Primärsystem zu einer nicht gewollten Einlösung führen.


Use Case Nummer VO-6 Alternativen Schritt 5: Enthält das Übergabe-Dokument keine Einzelposi-

tionen, wird das Dokument als „entwertet“ gekennzeichnet (vgl. Use Case VO-7 „Übergabe-Dokument entwerten“) Schritt 5: wird die Verordnungsposition nicht komplett einge-löst, ist die abgegebene Teilmenge zu vermerken. Die Ver-ordnungsposition gilt dann als „teileingelöst“. Erst nach Ab-gabe der letzten Teilmenge ist die Position als „eingelöst“ zu kennzeichnen. Schritt 5: Bei einem BTM-Rezept muss das Sicherheits-merkmal auch auf dem zentralen Rezeptserver geprüft und entwertet werden (vgl. VO-2)

Ausnahmen Obwohl das Übergabe-Dokument elektronisch erstellt wor-den ist, kann es wegen technischen Schwierigkeiten nicht eingelöst werden. In diesem Fall dient die Übergabe-Dokument-Quittung als Ersatz. Der Leistungserbringer kann sich mit der eindeutigen Kennung auf der Quittung beim Ver-ordnungsgeber vergewissern, dass es sich um ein „bona fide“ Dokument handelt. In diesem Fall kann nur das Ge-samtdokument eingelöst werden; eine Teileinlösung ist dann ausgeschlossen. Die eindeutige Kennung der Verordnung erlaubt: die nachträgliche Kennzeichnung der Verordnung als

„eingelöst“; die einmalige Abrechnung der Leistung. Eine nochmalige

Abrechnung ist nicht möglich.

Benutzte Use Cases VO-7 Übergabe-Dokument entwerten

Szenario VO-6-AVO Arznei-VO übernehmen

Weitere Information


Die Kennzeichnung der Einlösung sollte vom Leistungserb-ringer signiert werden, um Manipulationen hinsichtlich einer Mehrfacheinlösung vorzubeugen.


Offene Themen Keine

Referenzen Prozess „Verordnung einlösen“ (VO 102) [b4hGPM] § 291a Abs. 4 u. 5 SGB V/GMG, bzgl. Zugriffsberechtigung und –protokollierung

Datenanforderungen Angaben zur Einlösung der Verordnung



Die Erbringung der verordneten Leistung erfolgt im Rahmen des Behandlungsmanagements.


4.2.2.7 Übergabe-Dokument entwerten Use Case Nummer VO-7 Use Case Name Übergabe-Dokument entwerten Initiierender Akteur Verordnungseinlöser


Kurzbeschreibung Nach der Einlösung einer Verordnung / Überweisung wird geprüft, ob das Übergabe-Dokument noch offene Einzelposi-tionen enthält. Sofern dies nicht der Fall ist, wird das Über-gabe-Dokument entwertet.

Vorbedingung Die Verordnung / Überweisung ist als „eingelöst“ ge-kennzeichnet (VO-6).

Oder Die Verordnung / Überweisung ist wegen Ungültigkeit

nicht übernommen (VO-6). Oder Übergabe-Dokument soll nachträglich entwertet werden

(VO-5 Ausnahme).

Nachbedingung Das Übergabe-Dokument ist entwertet. Oder Das Übergabe-Dokument ist noch offen.


Ablauf 1. Die vorhandenen Einzelpositionen des Übergabe-Dokuments werden daraufhin geprüft, ob sie schon ein-gelöst bzw. nicht eingelöst aber zeitlich abgelaufen (und dadurch ungültig) sind.41

2. Ergibt die Prüfung, dass alle vorhandenen Einzelpositio-nen eingelöst bzw. zeitlich abgelaufen sind, wird das Ü-bergabe-Dokument entwertet.

Alternativen Schritt 2. Sofern das Übergabe-Dokument sich physisch auf der eGK befindet, sollte die Entwertung in der Form eines physischen Löschens bzw. einer Freigabe des Speicherplat-zes erfolgen, da die Speicherkapazität der eGK relativ be-grenzt ist.

Ausnahmen Konnte das Übergabe-Dokument in elektronischer Form nicht gelesen werden und wurde statt dessen die Übergabe-Dokument-Quittung verwendet, muss die Quittung selbst (wie bei einem herkömmlichen Papierrezept) eingezogen und entwertet werden. Hierbei ist eine nachträgliche Entwer-tung des elektronischen Übergabe-Dokuments zu veranlas-sen.

41 Die Gültigkeit ist von der Art der Verordnung abhängig (z.B. Kassenrezepte für Arzneimittel sind für 4 Wochen gültig, Privat-rezepte für Arzneimittel für 6 Monate).


Use Case Nummer VO-7 Benutzte Use Cases Keine

Weitere Information


Keine

Annahmen Keine

Offene Themen Das physische Löschen eines Übergabe-Dokumentes führt dazu, dass der Protokollsatz ins Leere zeigt. Daher wird vor-geschlagen, dass ein Rumpfeintrag bestehen bleibt, aus dem hervorgeht, dass ein Übergabe-Dokument der Art „xyz" am „tt.mm.jjjj" gelöscht wurde.

Referenzen Prozess „Verordnung einlösen“ (VO 102) [b4hGPM]



Antwortzeitverhalten AZ1 [b4hNFA]

4.2.3 Szenarios für ein Arzneimittel-Rezept (eRezept)

4.2.3.1 Arznei-VO erfassen Use Case Nummer VO-1-Arznei-VO Use Case Name Arznei-VO erfassen Initiierender Akteur Verordnungsgeber

Weitere Akteure ArzthelferIn

Kurzbeschreibung Ein Arzneimittel wird verordnet und erfasst.

Vorbedingung Die Notwendigkeit einer medikamentösen Behandlung ist durch den Verordnungsgeber festgestellt worden.

Die medizinische Verordnungsfähigkeit ist geprüft wor-den. Soweit klinische Basisdaten und/oder eine Arznei-mitteldokumentation zur Verfügung stehen und ein Zu-gang zu einem entsprechenden Server vorhanden ist, kann die Verträglichkeit des Arzneimittels bzw. Wirkstoffs maschinell geprüft werden. Werden mehrere Arzneimittel / Wirkstoffe gleichzeitig verordnet, sind alle in die Prüfung einzubeziehen (siehe Behandlungsmanagement).

Nachbedingung Arznei-VO ist erfasst.



Use Case Nummer VO-1-Arznei-VO Ablauf 1. Die Verschreibungspflicht der Verordnung wird geprüft.

In bestimmten Fällen (bspw. Kinder bis zur Vollendung des 12. Lebensjahres) können nicht verschreibungs-pflichtige Medikamente zu Lasten der gesetzlichen Ver-sicherung vom Arzt als verordnungsfähig deklariert wer-den. Die Begründung für die Ausnahme ist in Verbindung mit der Verordnung zu dokumentieren.

2. Der Kostenträger für das Arzneimittel wird bestimmt. Die Kosten für verschreibungspflichtige Arzneimittel werden in der Regel von der GKV getragen, sofern der Patient pflichtversichert ist. Die Kosten für verschreibungspflich-tige Arzneimittel, die der persönlichen Lebensführung dienen, sind vom Patienten selbst zu tragen. Entsteht die medizinische Notwendigkeit der Verordnung aus einem Arbeitsunfall, trägt die zuständige Berufsgenossenschaft die Kosten. Entsteht sie als Folge einer Kriegsverletzung, werden die Kosten (mittels eines Bundesbehandlungs-scheins) vom zuständigen Versorgungsamt getragen.

3. Die Details des zu verordnenden Arzneimittels bzw. Wirkstoffs werden erfasst. Hierzu gehört evtl. auch ein Einnahmeplan.

Alternativen Keine

Ausnahmen Keine


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess „eÜbergabe-Dokument schreiben“ (VO 101) [b4hGPM] Bundesmanteltarif für Ärzte, § 29, Verordnung von Arzneimit-teln [BMV-Ä] § 31 Abs. 1 SGB V/GMG – bzgl. Verschreibungsfähigkeit. § 34 SGB V/GMG


Use Case Nummer VO-1-Arznei-VO Datenanforderungen Arznei-VO-Daten.

Unterscheidung zwischen Verordnung nach Wirkstoffbe-zeichnung oder Arzneimittel (mit oder ohne aut-idem Rege-lung); Rechtfertigung der Verordnungsfähigkeit eines nicht ver-schreibungspflichtigen Arzneimittels zwecks Einbeziehung in die Leistungspflicht der GKV bei der Einlösung der Verord-nung.


Keine

4.2.3.2 Arznei-Rezept zusammenstellen Use Case Nummer VO-2-Arznei-VO Use Case Name Arznei-Rezept zusammenstellen Initiierender Akteur ArzthelferIn


Kurzbeschreibung Ein Arznei-Rezept für eine oder mehrere Arznei-VO wird zusammengestellt

Vorbedingung Arznei-VO ist erfasst

Nachbedingung Das Arznei-Rezept ist zusammengestellt


Ablauf 1. Ein Arznei-Rezept wird mit einer eindeutigen Identifikati-on angelegt.

2. Die einzelnen Arznei-VO werden in das Rezept übertra-gen.

3. Angaben zum Verordnungsgeber werden übertragen.

Alternativen Schritt 1: Bei einem BTM-Rezept wird die eindeutige Identifi-kation von einem zentralen Server vergeben.

Ausnahmen Keine


Weitere Information


Keine

Annahmen Ob es sich um eine Arznei-VO für einen gesetzlich Ver-sicherten oder einen Privatversicherten handelt, ist für den Anwendungsfall unerheblich. Für verschreibungspflichtige Arzneimittel muss eine ärztliche Verordnung vorliegen.


Use Case Nummer VO-2-Arznei-VO Offene Themen Die bisherige Mengenbegrenzung von 3 Arznei-VO pro Re-

zept könnte bei einer elektronischen Realisierung aufgeho-ben werden, insbesondere wenn die einzelnen Arznei-VO in verschiedenen Apotheken eingelöst werden dürfen.

Referenzen Prozess „eÜbergabe-Dokument schreiben (VO 101) [b4hGPM] Bundesmanteltarif für Ärzte, § 29, Verordnung von Arznei-mitteln [BMV-Ä] § 31 Abs. 1 SGB V/GMG – bzgl. Verschreibungsfähigkeit. § 34 SGB V/GMG § 129 SGB V/GMG



Keine

4.2.3.3 Arznei-VO in einer Apotheke einreichen Use Case Nummer VO-5-Arznei-VO Use Case Name Arznei-VO in einer Apotheke einreichen Initiierender Akteur Patient

Weitere Akteure Verordnungseinlöser der Apotheke

Kurzbeschreibung Eine oder mehrere Arznei-VO42 werden von einem Patienten in einer Apotheke zur Einlösung eingereicht.

Vorbedingung Patient hat das Rezept angenommen

Nachbedingung Eine oder mehrere Arznei-VO stehen einer Apotheke zur Einlösung zugriffsbereit.


Ablauf 1. Der Patient sucht die Apotheke auf, in der er die Arznei-VO einlösen möchte.

2. Der Patient bestimmt, welche offene Arznei-VO aus ei-nem oder mehreren Arznei-Rezepten er in dieser Apo-theke einlösen möchte43.

3. Die Echtheit des Übergabe-Dokumentes wird durch Vali-dierung der Signatur des Verordnungsgebers geprüft.

4. Die Apotheke erhält nach Authentifizierung Zugriff auf die ausgewählten Arznei-Verordnungen

42 Eine Arznei-VO ist eine Einzelposition auf einem Rezept. 43 Da der Patient nicht Bediener des Primärsystems der Apotheke ist, ist für die Entscheidung, welche Verordnungen er einlö-sen möchte, eine entsprechende technische Ausstattung, bspw. mittels eines angeschlossenen Kartenlesegeräts, notwendig.


Use Case Nummer VO-5-Arznei-VO Alternativen Schritt 1 kann sich entweder auf eine „konventionelle“ oder

auf eine Versandapotheke44 beziehen. Schritt 4: Der Patient kann den notwendigen Zugriff auf elekt-ronisch geführte Arznei-VO durch ein geeignetes techni-sches Verfahren autorisieren (z.B. durch einen PIN-Code). Dies ist insbesondere beim Umgang mit einer Versandapo-theke über Internet interessant (obwohl auch für eine Ver-sandapotheke eine Dauerautorisierung vorliegen könnte), setzt allerdings das Vorhandensein entsprechender Hard- und Software beim Patienten voraus..

Ausnahmen Keine


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess „Verordnung einlösen“ (VO102) [b4hGPM]

Datenanforderungen Arznei-Verordnungsdaten


Keine

4.2.3.4 Arznei-VO übernehmen Use Case Nummer VO-6-Arznei-VO Use Case Name Arznei-VO übernehmen Initiierender Akteur Verordnungseinlöser der Apotheke


Kurzbeschreibung Eine Arznei-VO wird durch eine Apotheke angenommen und auf Einlösbarkeit geprüft. Sofern die Prüfung positiv verläuft und die Leistung erbracht werden kann, wird die Verordnung als „eingelöst“ gekennzeichnet. Die Dispensierung gehört zur Prozessgruppe „Behand-lungsmanagement“.

Vorbedingung Eine oder mehrere Arznei-VO stehen der Apotheke zur Einlösung zugriffsbereit

44 Das Aufsuchen einer Versandapotheke erfolgt elektronisch.


Use Case Nummer VO-6-Arznei-VO Nachbedingung Die Arznei-VO ist als „eingelöst“ gekennzeichnet.

Oder Die Arznei-VO ist als „teileingelöst“ gekennzeichnet.

Oder Die Arznei-VO ist nicht übernommen, da das Arzneimittel

in der Apotheke nicht verfügbar ist. Oder Die Arznei-VO ist wegen Ungültigkeit nicht übernommen.


Ablauf 1. Der Lesezugriff auf die Arznei-VO wird protokolliert. 2. Die Echtheit des Arznei-Rezepts wird geprüft. Einerseits

ist die Integrität des Rezepts in Bezug auf die qualifizierte Signatur zu prüfen, andererseits die Mehrfacheinlösung (durch unerlaubtes Kopieren) auszuschließen.

3. Die Ordnungsmäßigkeit der Verordnung wird geprüft. Sie muss zeitlich gültig und noch „offen“ (noch nicht einge-löst) sein. Arznei-VO, die über eine GKV abgerechnet werden, haben generell eine Gültigkeit von 4 Wochen, BTM Verordnungen von 7 Tagen, Privat-Rezepte von 6 Monaten.

4. Die Verfügbarkeit des verordneten Arzneimittels wird geprüft. Kann es nicht in einer für den Patienten zufrie-denstellenden Zeit dispensiert werden, besteht keine Notwendigkeit der Einlösung der Arznei-VO.

5. Sofern nicht schon vorhanden, werden die Vertragsdaten auf der eGK in das Primärsystem der Apotheke über-nommen.

6. Die Arznei-VO wird in das Primärsystem übernommen. 7. Die Arznei-VO wird als „eingelöst“ gekennzeichnet. Sie

kann dadurch nicht nochmals zur Einlösung vorgelegt werden..

Alternativen Schritt 7: Bei einer Teileinlösung wird die abgegebene Teil-menge vermerkt und die Position als „teileingelöst“ gekenn-zeichnet. Nach Abgabe der letzten Teilmenge wird die Posi-tion als „eingelöst“ gekennzeichnet.

Ausnahmen Keine

Benutzte Use Cases

Weitere Information


Keine

Annahmen Keine


Use Case Nummer VO-6-Arznei-VO Offene Themen Keine

Referenzen Prozess „Verordnung einlösen“ (VO 102) [b4hGPM]

Datenanforderungen (Teil-) Einlösungsdaten für die Arznei-VO


Keine


4.3 Behandlungsmanagement

4.3.1 Anwendungsfalldiagramm

Abbildung 8: Use Case Diagramm Behandlungsmanagement

BE-1Einmalige Einwillg. für

freiwillige Anwendg. geben

BE-2Einwillg. für freiwilligeAnwendg. widerrufen

BE-3Heilberufler für Zugriff

auf med. Daten autorisieren

BE-4Medizinische Daten

bereitstellen

BE-5Medizinsche Daten

fortschreiben

BE-7Leistung erbringen

BE-8Patientenquittung

erstellen

PatientPatient

Admin. KraftAdmin. Kraft

Approbierter Heilberufler

Approbierter Heilberufler

LeistungserbringerLeistungserbringer

Leistungserbringer beschäftigtLeistungserbringer beschäftigt

«include»«include»

«include»«include»


4.3.2 Generische Anwendungsfälle

4.3.2.1 Einmalige Einwilligung bei der ersten Verwendung einer freiwilligen Anwen-dung geben

Use Case Nummer BE-1 Use Case Name Einmalige Einwilligung bei der ersten Verwendung einer

freiwilligen Anwendung geben Initiierender Akteur Patient

Weitere Akteure Approbierter Heilberufler

Kurzbeschreibung Bevor eine freiwillige Anwendung45 erstmals verwendet wird, muss der Patient seine grundsätzliche Einwilligung zu deren Verwendung geben.

Vorbedingung Der approbierte Heilberufler ist berechtigt, medizinische Daten des Patienten zu verarbeiten.

Der Heilberufler kann sich durch einen HBA ausweisen. Die freiwillige Anwendung befindet sich auf der eGK.

Nachbedingung Der Patient hat seine Einwilligung zur Verwendung der freiwilligen Anwendung gegeben.

Oder Der Patient konnte seine Einwilligung nicht geben.


Ablauf 1. Der Patient äußert seinen Wunsch, eine bestimmte frei-willige Anwendung verwenden zu wollen.

2. Der approbierte Heilberufler wählt die freiwillige Anwen-dung aus.

3. Der Patient identifiziert sich (z.B. durch die Eingabe sei-ner PIN) und autorisiert damit den approbierten Heilberufler, die Anwendung frei zu schalten.

4. Der approbierte Heilberufler schaltet die Anwendung frei.5. Der approbierte Heilberufler fragt den Patienten, mit wel-

chem Sicherheitsmechanismus bzgl. Zugriffsautorisie-rungen er zukünftig arbeiten möchte – z.B. könnte der Patient entscheiden, eine generelle Zugriffsautorisierung auf die freigeschaltete Anwendung für alle Heilberufler zu erteilen, die Einzelautorisierungen per PIN-Eingabe un-nötig macht.

6. Die Einwilligung des Patienten wird schriftlich dokumen-tiert.

45 Eine freiwillige Anwendung ist in der Nutzung für den Patienten nicht verpflichtend (vgl. §291a Abs.3 SGB V/GMG), im Ge-gensatz bspw. zur Anwendung „elektronisches Rezept“. Insofern ist deren Nutzung ein Ausdruck der informationellen Selbstbe-stimmung eines Patienten. Eine freiwillige Anwendung verwaltet üblicherweise eine Kategorie von medizinischen Daten. Es gibt bspw. eine Anwendung für die Verwaltung der klinischen Basisdaten, eine weitere für die Arzneimitteldokumentation oder die elektronische Patientenakte.


Use Case Nummer BE-1 Alternativen Keine

Ausnahmen Der Patient möchte einwilligen, kann es aber nicht, z.B. weil er seine PIN vergessen hat, oder weil die technischen Vor-aussetzungen nicht gegeben sind.


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess-Schritt BE 201 – Zugriffsberechtigung prüfen [b4hGPM] § 291a Abs. 3 SGB V/GMG

Datenanforderungen • Einwilligung zu der jeweiligen Anwendung


Keine

4.3.2.2 Einwilligung zur Verwendung einer freiwilligen Anwendung widerrufen Use Case Nummer BE-2 Use Case Name Einwilligung zur Verwendung einer freiwilligen Anwen-

dung widerrufen Initiierender Akteur Patient


Kurzbeschreibung Die Einwilligung zur Verwendung einer freiwilligen Anwen-dung wird vom Patienten widerrufen.

Vorbedingung Der Patient hat seine Einwilligung zur Verwendung der freiwilligen Anwendung gegeben (BE-1).

Der approbierte Heilberufler ist berechtigt, medizinische Daten des Patienten zu verarbeiten.

Der Heilberufler kann sich durch einen HBA ausweisen.

Nachbedingung Weder approbierter Heilberufler noch Patient können auf die freiwillige Anwendung zugreifen.


Use Case Nummer BE-2


Ablauf 1. Der Patient bringt gegenüber einem approbierten Heilbe-rufler zum Ausdruck, dass er seine Einwilligung für eine bestimmte freiwillige Anwendung widerrufen möchte.

2. Der approbierte Heilberufler wählt die freiwillige Anwen-dung aus.

3. Der Patient identifiziert sich z.B. durch die Eingabe sei-ner PIN46 und autorisiert damit den approbierten Heilbe-rufler, die Anwendung zu sperren.

4. Der Patient bestätigt ausdrücklich, z.B. durch die erneute Eingabe seiner PIN, dass die Einwilligung widerrufen wird.

5. Die Einwilligung wird widerrufen. Hiermit hat zukünftig kein Akteur Zugriff auf die Daten der freiwilligen Anwen-dung47.

Alternativen Schritt 5: Sofern die Daten in der Hoheit des Patienten lie-gen, werden sie auch physisch gelöscht48.

Ausnahmen Der Patient bestätigt seinen Widerrufswunsch nicht (bspw. weil er seine PIN nicht kennt). Der Widerruf wird nicht vollzo-gen.


Weitere Information


Die Revisionssicherheit muss gewährleistet bleiben. Daten, die eine erbrachte Leistung dokumentieren und dadurch in der Hoheit eines Leistungserbringers liegen (z.B. die Doku-mentation einer Krankenhausbehandlung), dürfen in ihrer Ursprungsform nicht gelöscht werden. Allenfalls wird der eGK-Verweis auf solche Daten (z.B. falls ein Link zu der Do-kumentation besteht) gelöscht.

Annahmen Keine

Offene Themen Sofern Daten gelöscht sind, zeigen Protokollsätze (für Lese- und Schreibzugriffe auf die Daten der gesperrten Anwen-dung) ins Leere.

Referenzen Siehe BE-1

Datenanforderungen Widerruf der Einwilligung zu der jeweiligen Anwendung (z.B. als zeitliche Begrenzung der Einwilligung)

46 Die Identifizierung und Bestätigung durch PIN wird immer verlangt – auch wenn der Patient die Zugriffsautorisierung durch PIN hat ausschalten lassen. 47 Trotz Löschen der Daten bleibt die Anwendung selbst sowie ihre Einwilligungsdaten auf der eGK bestehen. 48 Dies impliziert nicht, dass die Daten auf den Primärsystemen der Leistungserbringer ebenfalls gelöscht werden. Diese Daten liegen in der Hoheit der Leistungserbringer.


Use Case Nummer BE-2 Nichtfunktionale Anforderungen

Keine

4.3.2.3 Heilberufler für den Zugriff auf medizinische Daten autorisieren Use Case Nummer BE-3 Use Case Name Heilberufler für den Zugriff auf medizinische Daten49 au-

torisieren Initiierender Akteur Patient


Kurzbeschreibung Der Patient autorisiert einen approbierten Heilberufler für den Zugriff auf freiwillige Anwendungen der Gesundheitskarte. Mit der Autorisierung des Patienten ist ein approbierter Heil-berufler berechtigt, auf dessen medizinische Daten zuzugrei-fen.

Vorbedingung Der approbierte Heilberufler ist berechtigt, medizinische Daten des Patienten zu verarbeiten.

Der Heilberufler kann sich durch einen HBA ausweisen. Die Behandlung bei einem approbierten Heilberufler

macht es notwendig, dass medizinische Daten gelesen bzw. verändert werden müssen.

Der Patient hat seine Einwilligung zur Verwendung der freiwilligen Anwendung gegeben (BE-1).

Es ist bekannt, auf welche freiwillige(n) Anwendung(en) zugegriffen werden soll.

Nachbedingung Der approbierte Heilberufler ist autorisiert, auf medizini-sche Daten des Patienten zuzugreifen.

Oder Der approbierte Heilberufler ist nicht autorisiert, auf me-

dizinische Daten des Patienten zuzugreifen.


Ablauf 1. Der Patient autorisiert durch die Eingabe seiner PIN oder ein vergleichbares Verfahren den Zugriff auf seine medi-zinischen Daten.

49 Unter medizinische Daten werden die klinischen Basisdaten (§291a, Abs. 3, Satz 1 Nr. 1), die erweiterten klinischen Daten (§291a, Abs. 3, Satz 1 Nr. 2 - 4) verstanden. Diese Daten werden mittels freiwilliger Anwendungen verarbeitet.


Use Case Nummer BE-3 Alternativen Die Autorisierung wird nicht für einen Einzelzugriff sondern

für einen längeren Zeitraum („Dauerautorisierung“) ausge-sprochen. In einem solchen Fall muss die Autorisierung auf der eGK oder in einem noch zu spezifizierenden externen Verzeichnisdienst festgehalten werden. Ferner muss die Möglichkeit bestehen, die Autorisierung vorzeitig aufzuhe-ben. Siehe offenes Thema. Die aufgeführten Alternativen sind Beispiele für die Handha-bung der Autorisierung: Die Autorisierung kann für einen bestimmten Zeitraum

bzw. für die Dauer einer Behandlung (z.B. eines Kran-kenhausaufenthaltes) gegeben werden.

Die Autorisierung kann einem einzelnen Heilberufler, einer Gruppe von Heilberuflern – z.B. gegenüber allen Ärzten eines Krankenhauses oder einer Gemeinschafts-praxis – oder generell allen Heilberuflern gegeben wer-den.

Die Autorisierung kann auf eine bestimmte Anwendung eingeschränkt werden.

Die Autorisierung wird nach Zugriffsart differenziert (Le-sen, Schreiben, Ändern, Löschen).

Ausnahmen Der Patient gibt keine Autorisierung. Die medizinischen Daten dürfen nicht verarbeitet werden.


Weitere Information


Keine

Annahmen Keine

Offene Themen Ein Autorisierungskonzept, das die skizzierten Alternativen insbesondere hinsichtlich Dauerautorisierungen umfasst, muss erstellt werden. Sofern Dauerautorisierungen vorgesehen werden, müssen sie auch vom Patienten widerrufen werden können.

Referenzen Prozess-Schritt BE 201 – Zugriffsberechtigung prüfen [b4hGPM] § 291a Abs. 5 SGB V/GMG

Datenanforderungen Wenn die Autorisierung für einen Zeitraum gegeben wird, muss sie festgehalten werden (für wen und für wie lange)50.

50 Die gespeicherte Autorisierung ist nicht mit einer Zugriffsprotokollierung zu verwechseln, die trotz dauerhafter Autorisierung weiterhin notwendig ist.


Use Case Nummer BE-3 Nichtfunktionale Anforderungen

Keine

4.3.2.4 Medizinische Daten bereitstellen Use Case Nummer BE-4 Use Case Name Medizinische Daten bereitstellen Initiierender Akteur Patient


Kurzbeschreibung Der Patient stellt seine medizinischen Daten dem approbier-ten Heilberufler zur Information oder zur Weiterverarbeitung bereit. Die Besonderheiten für die Bereitstellung von klinischen Ba-sisdaten („Notfalldaten“) sind im entsprechenden Szenario zu finden.

Vorbedingung Die eGK liegt vor. Der approbierte Heilberufler ist berechtigt, medizinische

Daten des Patienten zu verarbeiten. Der Heilberufler kann sich durch einen HBA ausweisen.

Nachbedingung Die medizinischen Daten sind bereitgestellt. Oder Die medizinischen Daten sind nicht bereitgestellt.


Ablauf 1. Der Patient bestimmt die freiwillige(n) Anwendung(en), auf die der approbierte Heilberufler zugreifen soll.

2. Der Patient autorisiert den approbierten Heilberufler zur (lesenden) Nutzung der freiwilligen Anwendung(en) – siehe benutzten Use Case Heilberufler für den Zugriff auf medizinische Daten autorisieren

3. Das Primärsystem des approbierten Heilberuflers greift auf die medizinischen Daten mittels eGK zu. Hierbei wird der Zugriff protokolliert.

4. Die relevanten medizinischen Daten des Patienten wer-den in das Primärsystem übernommen, wo sie ein un-veränderbarer51 Teil der Behandlungsdokumentation werden (Versionierung im Primärsystem).

51 Daten, die von der eGK geholt werden, bilden die Grundlage für die Behandlung. Aus Revisionsgründen muss der Urzustand beibehalten werden. Da bei einer möglichen Rückspeicherung der Daten (insbesondere klinische Basisdaten oder Arzneimittel-dokumentation) dieser Urzustand überschrieben wird, muss eine Kopie im Primärsystem des Leistungserbringers gespeichert werden.


Use Case Nummer BE-4 Alternativen Schritt 2: Die Autorisierung liegt schon vor - in der Form ei-

ner auf der eGK gespeicherten Dauerautorisierung für den approbierten Heilberufler. Schritte 1-4: Der Ablauf ist auch vorhanden, wenn der Pati-ent seine eigenen Daten unabhängig von einer Behandlung einsehen möchte. Sofern die Einsicht ohne approbierten Heilberufler erfolgen soll, sind die technischen und rechtli-chen Randbedingungen für diesen Zugriff noch näher zu spezifizieren.

Ausnahmen Die medizinischen Daten konnten wegen technischer Prob-leme nicht gelesen werden. Wenn kein Protokollsatz geschrieben werden kann, darf der Zugriff nicht durchgeführt werden (auch für klinische Basis-daten).

Benutzte Use Cases BE-3 Heilberufler für den Zugriff auf medizinische Daten au-torisieren

Szenarios BE-4-KBD Klinische Basisdaten bereitstellen BE-4-AMD Arzneimitteldokumentation bereitstellen

Weitere Information


Keine. Ggf. ergeben sich spezielle Anforderungen in den Szenarios.

Annahmen Keine. Ggf. ergeben sich spezielle Annahmen in den Szena-rios.

Offene Themen Keine

Referenzen Prozess-Schritt BE 101 – Medizinische Daten bereitstellen [b4hGPM] § 291a Abs. 5. SGB V/GMG

Datenanforderungen Daten der freiwilligen Anwendungen




4.3.2.5 Medizinische Daten fortschreiben Use Case Nummer BE-5 Use Case Name Medizinische Daten fortschreiben Initiierender Akteur Approbierter Heilberufler


Kurzbeschreibung Die in Verbindung mit der eGK zu führenden medizinischen Daten werden sicher und nachprüfbar fortgeschrieben52.

Vorbedingung Die eGK liegt vor Der approbierte Heilberufler ist berechtigt, medizinische

Daten des Patienten zu verarbeiten. Der Heilberufler kann sich durch einen HBA ausweisen.

Nachbedingung Die medizinischen Daten wurden fortgeschrieben. Oder Die medizinischen Daten wurden nicht fortgeschrieben.


52 Zum Fortschreiben gehört neben der Ergänzung der Daten durch den Heilberufler auch das Löschen von Daten auf Wunsch eines Patienten (§291a Abs. 6). Hierbei muss zwischen der internen Dokumentation eines Heilberuflers und der Dokumentation, unterschieden werden.


Use Case Nummer BE-5 Ablauf 1. Der approbierte Heilberufler erzeugt im Rahmen seiner

Behandlungsdokumentation medizinische Daten in sei-nem Primärsystem53.

2. Der approbierte Heilberufler fragt den Patienten, ob diese Daten (bzw. ein patientengeeigneter Extrakt davon) zu-sätzlich in Verbindung mit der eGK gespeichert werden sollen. Er weist darauf hin, dass Lücken in der Patienten-Dokumentation entstehen können, wenn die Daten nicht gespeichert werden und dass diese Lücken bei einer nachfolgenden Behandlung schwerwiegende Folgen ha-ben können.

3. Der approbierte Heilberufler bzw. sein Primärsystem wählt die freiwillige Anwendung aus, mit der er fort-schreiben möchte.

4. Der Patient autorisiert den approbierten Heilberufler zur (schreibenden) Nutzung der freiwilligen Anwendung(en) – siehe benutzten Use Case Heilberufler für den Zugriff auf medizinische Daten autorisieren.

5. Die Daten werden nach den Erfordernissen der freiwilli-gen Anwendung bereitgestellt.

6. Der neue Stand der medizinischen Daten wird in Verbin-dung mit den jeweiligen Anwendungen der eGK gespei-chert und protokolliert.

7. Die Fortschreibung wird vom approbierten Heilberufler qualifiziert signiert.

8. Auf Anforderung des Patienten kann der neue Stand der Daten ausgedruckt werden.

53 Die Dokumentation einer Krankenhausbehandlung gehört auch hierzu.


Use Case Nummer BE-5 Alternativen Schritt 4: die Autorisierung liegt schon vor.

Schritte 2-5: Nachträgliche Dokumentation, wenn z.B. die eGK zum Zeitpunkt der Entstehung der Dokumentation nicht vorliegt54: a) Der approbierte Heilberufler schreibt die ergänzende

Dokumentation zur Abholung durch den Patienten auf ei-nem Server fort – als „Aktualisierungspaket“ („Update Package“).

b) Beim nächsten Kontakt eines Patienten mit einer eGK-bearbeitenden Organisation wird geprüft, ob ein „Aktuali-sierungspaket“ vorliegt.

c) Der Patient wird darüber informiert, dass ein Aktualisie-rungspaket von einem vorbehandelnden Heilberufler vor-liegt.

d) Der Patient autorisiert die Übernahme des Aktualisie-rungspakets in seine medizinischen Daten auf der eGK

Ausnahmen Der Patient möchte trotz ärztlichem Hinweis nicht, dass sei-ne medizinischen Daten fortgeschrieben werden. Wenn kein Protokollsatz geschrieben werden kann, darf die Änderung nicht durchgeführt werden.

Benutzte Use Cases BE-3 Heilberufler für den Zugriff auf medizinische Daten au-torisieren

Szenario BE-5-KBD Klinische Basisdaten fortschreiben

Weitere Information


Sofern die Autorisierung nicht im voraus gegeben worden ist, bedeutet der Autorisierungsschritt, dass die Fortschreibung der Dokumentation im Beisein des Patienten erfolgt. Dies kann sich auf den Ablauf in einer Praxis auswirken.


Offene Themen Keine

Referenzen Prozess-Schritt BE 103 –Medizinische Daten fortschreiben [b4hGPM] § 291 Abs. 5 SGB V in Verbindung mit den Gesetzesbe-gründungen zu § 291 Abs. 5 SGB V/GMG.

Datenanforderungen Daten zu den freiwilligen Anwendungen



54 Eine ähnliche Vorgehensweise, allerdings ohne Autorisierung, ist für die Aktualisierung von Vertragsdaten vorgesehen.


4.3.2.6 Leistung erbringen Use Case Nummer BE-7 Use Case Name Leistung erbringen Initiierender Akteur Leistungserbringer


Kurzbeschreibung Eine Leistung55 wird im Rahmen der medizinischen Versor-gung durch einen Leistungserbringer erbracht.

Vorbedingung Medizinische Notwendigkeit ist festgestellt worden oder Eine Leistung ist verordnet worden

Nachbedingung Die Leistung ist erbracht.


Ablauf 1. Die notwendige Leistung wird unter möglicher Hinzu-nahme der bereitgestellten medizinischen Daten er-bracht.

2. Das Ergebnis der Leistungserbringung wird dokumen-tiert. Sofern die erforderlichen Berechtigungen seitens des Heilberuflers und die erforderlichen Autorisierungen seitens des Patienten vorhanden sind, kann dies unter Einbeziehung der eGK erfolgen.

Alternativen Schritt 1: die medizinischen Daten stehen nur zur Verfügung, wenn es sich um einen approbierten Heilberufler als Leis-tungserbringer handelt. Sie stehen z.B. dem orthopädischen Schuhmacher nicht zur Verfügung.

Ausnahmen Keine


Szenarios BE-7-KI Kontra-Indikationscheck durchführen BE-7-IA Interaktionscheck durchführen

Weitere Information



Annahmen Keine. Ggf. ergeben sich spezielle Annahmen in den Szena-rios.

Offene Themen Keine

Referenzen Prozess-Schritt BE 102 – Medizinische Maßnahme durchfüh-ren [b4hGPM]

55 Unter Leistung im Sinne des SGB V (§§ 27-52) werden u.a. folgende Leistungsarten verstanden: eine stationäre Heilbehand-lung in einem Krankenhaus, eine Reha-Maßnahme, ein Arztbesuch, die Dispensierung eines Arzneimittels, die Anfertigung eines Hilfsmittels, die häusliche Krankenpflege.


Use Case Nummer BE-7 Datenanforderungen Ggf. Schnittstellen zu unterstützenden Software-Systemen

(z.B. Arzneimittel-IS)



4.3.2.7 Patientenquittung erstellen Use Case Nummer BE-8 Use Case Name Patientenquittung erstellen Initiierender Akteur Patient

Weitere Akteure Administrative Kraft

Kurzbeschreibung Die an der vertragsärztlichen Versorgung teilnehmenden Ärzte, ärztlich geleiteten Einrichtungen und medizinischen Versorgungszentren haben die Versicherten auf Verlangen schriftlich in verständlicher Form, direkt im Anschluss an die Behandlung oder mindestens quartalsweise spätestens vier Wochen nach Ablauf des Quartals, in dem die Leistungen in Anspruch genommen worden sind, über die zu Lasten der gesetzlichen Krankenkassen erbrachten Leistungen und deren vorläufige Kosten (Patientenquittung) zu unterrichten. Satz 1 gilt auch für die vertragszahnärztliche Versorgung. Der Versicherte erstattet für eine quartalsweise schriftliche Unterrichtung nach Satz 1 eine Aufwandspauschale in Höhe von einem Euro zuzüglich Versandkosten. (Originaltext § 305 Abs.2 SGB V/GMG)

Vorbedingung Die Leistung ist erbracht (BE-7).

Nachbedingung Die Patientenquittung ist erstellt


Ablauf 1. Der Patient verlangt eine Quittung vom Leistungserbrin-ger über die in Anspruch genommenen Leistungen.

2. Die Quittung wird in verständlicher Form erstellt. 3. Die Quittung wird dem Patienten übergeben. 4. Die Aufwandspauschale wird vom Patienten an den Leis-

tungserbringer entrichtet.

Alternativen Keine

Ausnahmen Keine


Weitere Information


Keine


Use Case Nummer BE-8 Annahmen Keine

Offene Themen § 291a Abs. 3 Satz 1 Nr. 6 SGB V/GMG sieht vor, dass die Patientenquittung in Verbindung mit der eGK gespeichert wird. Die Quittung ist aber für den Patienten bestimmt. Die elektronische Speicherung setzt voraus, dass der Patient den Leistungserbringer physisch aufsucht, da die Karte für die Quittierung physisch vorliegen muss; und dass der Pati-ent die geeignete Hard- und Software-Einrichtungen besitzt, um die Informationen zu lesen. Hier ist eine Papierquittung einfacher zu handhaben (§ 305 SGB V sieht sogar Regelun-gen für die Portokosten vor).

Referenzen Prozess-Schritt BE 104 – Patientenquittung erstellen [b4hGPM] § 305 Abs. 2 SGB V/GMG. § 291a, Abs.3, Satz 1 Nr.6 SGB V/GMG

Datenanforderungen Die Einzelheiten der Patientenquittung


Keine


4.3.3 Szenarios Die dargestellten Szenarios illustrieren den Umgang mit klinischen Basisdaten (einschließlich der Sondersituation eines Notfalls) und mit der Arzneimitteldokumentation hinsichtlich der Bereitstellung und Fortschreibung sowie der Hinzuziehung der Daten im Kontext einer Wechselwirkungsprüfung als Teil der Heilberuflertätigkeit.

4.3.3.1 Klinische Basisdaten bereitstellen Use Case Nummer BE-4-KBD Use Case Name Klinische Basisdaten bereitstellen Initiierender Akteur Patient

Weitere Akteure Approbierte Heilberufler Nicht approbiertes Medizinpersonal

Kurzbeschreibung Der Patient stellt seine klinischen Basisdaten bereit. Hierbei sind die besonderen Rahmenbedingungen eines Notfalls zu berücksichtigen.

Vorbedingung Der Patient befindet sich nicht in einem lebensbedrohli-chen Zustand, der jeglichen zusätzlichen Schritt aus-schließt.

Die eGK liegt vor. Der Patient ist identifiziert. Der approbierte Heilberufler ist durch einen HBA bzw.

das nicht approbiertes Medizinpersonal durch entspre-chenden Berufsausweis authentifiziert.

Nachbedingung Die klinischen Basisdaten sind bereitgestellt. Oder Die klinischen Basisdaten konnten nicht bereitgestellt

werden.


Ablauf 1. Der Patient bestimmt, dass der approbierte Heilberufler oder das nicht approbierte Medizinpersonal auf seine kli-nischen Basisdaten zugreifen darf.

2. Der Patient autorisiert den lesenden Zugriff. 3. Der approbierte Heilberufler oder das nicht approbierte

Medizinpersonal greift auf die klinischen Basisdaten mit-tels eGK zu.

4. Der aktuelle Stand der klinischen Basisdaten des Patien-ten wird in das Primärsystem des Leistungserbringers übernommen. Hierbei wird der Zugriff protokolliert.


Use Case Nummer BE-4-KBD Alternativen Schritt 1 – 2. In einer Notfallsituation, bei der der Patient sein

Selbstbestimmungsrecht nicht ausüben kann, sind approbierte Heilberufler und nicht approbiertes Medizin-personal berechtigt, ohne Autorisierung auf die klinische Basisdaten zuzugreifen. Schritte 1 – 3. Der Patient führt seine klinischen Basisdaten nicht auf der eGK, sondern in Papierform als europäischer Notfall-Ausweis (ENA).

Ausnahmen Klinische Basisdaten werden auf der eGK nicht geführt.

Benutzte Use Cases Keine zusätzlichen.

Weitere Information


Die Rahmenbedingungen eines Notfalls, bei dem der Patient ggf. nicht ansprechbar ist.

Annahmen Keine

Offene Themen Keine

Referenzen Prozess-Schritt BE 101 – Medizinische Daten bereitstellen [b4hGPM] § 291a Abs. 5 SGB V/GMG

Datenanforderungen Die klinischen Basisdaten – vgl. ISO 21549-3



4.3.3.2 Arzneimitteldokumentation bereitstellen Use Case Nummer BE-4-AMD Use Case Name Arzneimitteldokumentation bereitstellen Initiierender Akteur Patient

Weitere Akteure Approbierte Heilberufler

Kurzbeschreibung Der Patient stellt seine Arzneimitteldokumentation dem ap-probierten Heilberufler zur Information oder zur Weiterverar-beitung bereit.

Vorbedingung Die eGK liegt vor. Der approbierte Heilberufler ist durch einen HBA authen-

tifiziert.

Nachbedingung Die Arzneimitteldokumentation ist bereitgestellt. Oder Die Arzneimitteldokumentation wurde nicht bereitgestellt.



Use Case Nummer BE-4-AMD Ablauf 1. Der Patient bestimmt, dass der approbierte Heilberufler

auf seine Arzneimitteldokumentation zugreifen soll. 2. Der Patient autorisiert den approbierten Heilberufler zur

(lesenden) Nutzung der Arzneimitteldokumentation. 3. Das Primärsystem des approbierten Heilberuflers greift

auf die Arzneimitteldokumentation mittels eGK zu. Hier-bei wird der Zugriff protokolliert.

4. Der aktuelle Stand der Arzneimitteldokumentation des Patienten wird in das Primärsystem übernommen.

Alternativen Keine speziellen.

Ausnahmen Keine speziellen.

Benutzte Use Cases Keine zusätzlichen.

Weitere Information


Keine

Annahmen Keine

Offene Themen Keine

Referenzen Prozess-Schritt BE 101 – Medizinische Daten bereitstellen [b4hGPM] § 291a Abs. 5 SGB V/GMG.

Datenanforderungen Arzneimitteldokumentation


Antwortzeitverhalten AZ2 [b4hNFA].

4.3.3.3 Klinische Basisdaten fortschreiben Use Case Nummer BE-5-KBD Use Case Name Klinische Basisdaten fortschreiben Initiierender Akteur Approbierter Heilberufler


Kurzbeschreibung Ein neuer Stand der klinischen Basisdaten wird sicher und nachprüfbar fortgeschrieben.

Vorbedingung Die eGK liegt vor. Der approbierte Heilberufler ist durch einen HBA authen-

tifiziert.

Nachbedingung Die klinische Basisdaten wurden fortgeschrieben. Oder Die klinische Basisdaten wurden nicht fortgeschrieben.



Use Case Nummer BE-5-KBD Ablauf 1. Der approbierte Heilberufler erzeugt einen neuen Stand

der klinischen Basisdaten in seinem Primärsystem. Hier-bei wird der bisherige Stand gesichert.

2. Der approbierte Heilberufler fragt den Patienten, ob der neue Stand zusätzlich in Verbindung mit der eGK ge-speichert werden sollen. Er weist hierbei auf die eminen-te Bedeutung von aktuellen klinischen Basisdaten in ei-nem Notfall hin.

3. Der approbierte Heilberufler wählt die Anwendung „klini-sche Basisdaten“ aus.

4. Der Patient autorisiert den approbierten Heilberufler zur Fortschreibung der klinischen Basisdaten.

5. Die Daten werden nach den Erfordernissen der freiwilli-gen Anwendung bereitgestellt.

6. Der neue Stand der klinischen Basisdaten wird auf die eGK gespeichert und elektronisch signiert. Er ersetzt den bislang gültigen Stand. Hierbei wird die Änderung proto-kolliert.

7. Die Änderung wird vom approbierten Heilberufler qualifi-ziert signiert.

8. Auf Anforderung des Patienten kann der neue Stand der klinischen Basisdaten ausgedruckt werden.

Alternativen Schritt 5 – 8: Erfolgt die Speicherung der klinischen Basisda-ten nicht auf der eGK, sollen die Daten mindestens in Papierform – als europäischer Notfall-Ausweis -ausgegeben werden. Schritte 2-5: Die Alternative der nachträglichen Dokumenta-tion gilt auch für klinische Basisdaten.

Ausnahmen Keine


Weitere Information


Änderungen der klinischen Basisdaten und der Arzneimittel-dokumentation sind Aktualisierungen eines evtl. vorhande-nen Datenbestandes. Daher muss der Ursprungszustand (vor der Änderung) aus Revisionsgründen - zumindest im Primärsystem des approbierten Heilberuflers - wiederher-stellbar sein (Versionierung). Die in Schritt 7 beschriebene qualifizierte Signatur bezieht sich auf den kompletten neuen Stand.

Annahmen Keine

Offene Themen Keine


Use Case Nummer BE-5-KBD Referenzen Prozess-Schritt BE 103 – Medizinische Daten fortschreiben

[b4hGPM]

Datenanforderungen Klinische Basisdaten gemäß ISO-21549



Die Fortschreibung der Arzneimitteldokumentation erfolgt in der selben Art und Weise wie für die klinischen Basisdaten. Hierbei ist zu berücksichtigen, dass es eine Überlappung zwi-schen den beiden Datenkategorien gibt. Eine Dauermedikation im chronischen Krankheitsfall ist sowohl Teil der Arzneimitteldokumentation als auch der klinischen Basisdaten.

4.3.3.4 Kontra-Indikationscheck durchführen Use Case Nummer BE-7-KI Use Case Name Kontra-Indikationscheck durchführen Initiierender Akteur Approbierter Heilberufler


Kurzbeschreibung Anhand der Personendaten und der klinischen Basisdaten auf der eGK wird ein Kontra-Indikationscheck (KI-Check) für ein zu verordnendes bzw. zu dispensierendes Arzneimittel durchgeführt, um den Patienten vor ungewollten Nebenwir-kungen einer medikamentösen Behandlung zu schützen.

Vorbedingung Eine eGK liegt vor. Ein Arzneimittel soll verordnet bzw. dispensiert werden. Ein maschinelles KI-Check-Verfahren steht zur Verfü-

gung.

Nachbedingung Die Anwendung des Arzneimittels würde eine schwer-wiegende Nebenwirkung hervorrufen56.

Oder Die Anwendung des Arzneimittels ruft keine schwerwie-

gende Nebenwirkung hervor.


56 Inwieweit die Nebenwirkung toleriert wird, liegt im Ermessen des Heilberuflers.


Use Case Nummer BE-7-KI Ablauf 1. Die Personendaten des Patienten werden bereitgestellt.

Hieraus geht das Geschlecht und Alter des Patienten hervor.

2. Die klinischen Basisdaten des Patienten werden bereit-gestellt. Hieraus geht bspw. hervor, ob der Patient chro-nische Erkrankungen hat (z.B. Diabetes). Siehe hierzu Szenario Klinische Basisdaten bereitstellen

3. Die Daten werden gemäß der Schnittstelle zum KI-Prüfverfahren formatiert.

4. Ggf. werden weitere Daten, die für den KI-Check erfor-derlich sind, manuell ergänzt.

5. Das KI-Prüfverfahren wird mit der Schnittstelle aufgeru-fen.

6. Der KI-Check wird durchgeführt. 7. Das Ergebnis des KI-Checks wird mitgeteilt.

Alternativen Schritt 1-4: das KI-Verfahren greift selbst auf die eGK zu. Schritt 1-7: der KI-Check wird manuell durchgeführt.

Ausnahmen Keine


Weitere Information


Keine

Annahmen Keine

Offene Themen Keine


Datenanforderungen Vertragsdaten Klinische Basisdaten Schnittstellen zu leistungserbringender Software




4.3.3.5 Interaktionscheck durchführen Dieser Use Case hat große Ähnlichkeiten mit „Kontra-Indikationscheck durchführen“ – mit dem Unterschied, dass anstatt Personendaten und klinischer Basisdaten die Arzneimitteldo-kumentation und ausstehende Arzneiverordnungen gelesen werden. Es ist anzunehmen, dass beide Checks in Verbindung zueinander laufen werden

Use Case Nummer BE-7-IA Use Case Name Interaktionscheck durchführen Initiierender Akteur Approbierter Heilberufler


Kurzbeschreibung Anhand der Arzneimitteldokumentation und den offenen Arznei-VO (siehe Use Case Arznei-VO erstellen) wird ein Interaktionscheck (IA-Check) für ein zu verordnendes bzw. zu dispensierendes Arzneimittel durchgeführt, um den Pati-enten vor ungewollten Wechselwirkungen einer medikamen-tösen Behandlung zu schützen.

Vorbedingung Eine eGK liegt vor. Ein Arzneimittel soll verordnet bzw. dispensiert werden. Ein maschinelles IA-Check-Verfahren steht zur Verfü-

gung.

Nachbedingung Die Anwendung des Arzneimittels würde eine Wechsel-wirkung hervorrufen.

Oder Die Anwendung des Arzneimittels ruft keine Wechselwir-

kung hervor.


Ablauf 1. Die Arzneimitteldokumentation des Patienten wird bereit-gestellt. Hierbei ist die laufende Medikation einschließlich gewählter Dispensierung von hoher Bedeutung. Siehe hierzu Szenario Arzneimitteldokumentation bereitstellen.

2. Offene Arznei-VO werden gelesen – siehe hierzu Szena-rio Arznei-VO übernehmen

3. Die Daten werden gemäß der Schnittstelle zum IA-Prüfverfahren formatiert.

4. Das IA-Prüfverfahren wird mit der Schnittstelle aufgeru-fen

5. Der IA-Check wird durchgeführt 6. Das Ergebnis des IA-Checks wird mitgeteilt.

Alternativen Schritt 1-2: das IA-Check-Verfahren greift selbst auf die eGK zu – sofern die notwendige Autorisierung vorliegt.

Schritt 1-6: der IA-Check wird manuell durchgeführt.

Ausnahmen Keine


Use Case Nummer BE-7-IA Benutzte Use Cases Keine

Weitere Information


Keine

Annahmen Keine

Offene Themen Keine


Datenanforderungen Offene Arznei-VO Arzneimitteldokumentation Schnittstellen zum IA-Check-Verfahren


Antwortzeitverhalten AZ2 [b4hNFA]

4.4 Anwendungsfall Steuerung

4.4.1 Anwendungsfälle zur Steuerung des Gesundheitswesens Auslösender Akteur Anwendungsfall

Nummer Anwendungsfall Name

Übergreifende Funktio-nen

ST-1 Qualitätssicherung und Bereitstellung statistischer Auswertungen


4.4.1.1 Qualitätssicherung und Bereitstellung statistischer Auswertungen Use Case Nummer ST-1 Use Case Name Qualitätssicherung und Bereitstellung statistischer

Auswertungen Initiierender Akteur Übergreifende Funktion

Weitere Akteure

Kurzbeschreibung Die Informationen, die im Bereich des Vertrags-, Verord-nungs- und Behandlungsmanagement anfallen und doku-mentiert werden, können von berechtigten übergeordneten Funktionen verarbeitet werden, sofern sie auf einem Server vorliegen. Mögliche Ziele dafür sind beispielsweise die fall-übergreifende Qualitätssteuerung (z.B. DMP), Controlling im Gesundheitswesen oder die allgemeine Qualitätssicherung im Gesundheitswesen (z.B. Erfolgskontrolle bei Behandlun-gen).

Vorbedingung Verfügbarkeit von server-basierten Informationen im Ver-trags-, Verordnungs- und Behandlungsmanagement

Die Verfügbarkeit zertifizierter Pseudo- und anonymisie-rungsverfahren und autoriserter Datenannahmestellen57

Nachbedingung Keine


Ablauf 1. Überprüfung der Autorisierung der übergreifenden Funk-tion

2. Zugriff auf (möglicherweise) anonymisierte Information 3. Verarbeitung der Information für die jeweilige Zielsetzung

Alternativen Keine

Ausnahmen Keine


Weitere Information


Für die Beschreibung der Sicherheitsanforderungen wird auf die entsprechenden Dokumente verwiesen. Für verschiedene Funktionen muss die Information in ano-nymisierter Form vorliegen, sodass keine Querbeziehung zwischen den Verordnungen und den Versicherten möglich ist.

Annahmen Keine

Offene Themen Keine

Referenzen Keine

57Z.B. bei Disease-Management-Programmen ist eine Pseudonymisierung erforderlich, um ggf. doch bei auftretenden Komplika-tionen oder Fehlentwicklungen im Behandlungsmanagement auf den einzelnen Patienten rückschliessen zu können -> s.a. TMF-Verfahren zur Pseudo- und Anonymisierung.


Use Case Nummer ST-1 Datenanforderungen Daten zu den freiwilligen Anwendungen


Keine


5 Cross-Referenz zum Geschäftsprozessmodell

VD 101

VD 102

VD 103

VO 101

VO 102

BE 101

BE 102

BE 103

BE 104

Generische Anwendungs-fälle

Maß

nahm

e ei

nlei

-te

n

Zahl

ung

abw

icke

ln

Ver

trags

date

n le

sen

und

aktu

ali-

sier

en

eÜbe

rgab

e-D

okum

ent s

chre

i-be

n

Vero

rdnu

ng e

inlö

-se

n

Med

izin

isch

e D

aten

be

reits

telle

n

Med

izin

isch

e M

aß-

nahm

e du

rchf

ühre

n

Med

izin

isch

e D

aten

fo

rtsch

reib

en

Patie

nten

quitt

ung

erst

elle

n

Vertragsdatenmanagement Stammdaten mitteilen Vertragsdaten aktualisieren X Patient identifizieren X Vertragsdaten übernehmen X Zahlungsbeteiligung in Rechnung stellen

X

Zahlungsbeteiligung leisten X Zahlungsbeteiligung quittie-ren

X

Zahlungsbeteiligung nach-weisen

Verordnungsmanagement Verordnung/Überweisung erfassen

X

Übergabe-Dokument zu-sammenstellen

X

Übergabe-Dokument signie-ren

X

Übergabe-Dokument auf einen Datenträger aufbrin-gen

X

Verordnung/Überweisung einreichen

X

Verordnung/Überweisung übernehmen

X

Übergabe-Dokument entwer-ten

X

Behandlungsmanagement Einmalige Einwilligung bei der ersten Verwendung einer freiwilligen Anwendg. geben

X X

Einwilligung zur Verwendung einer freiwilligen Anwendung widerrufen

X X

Heilberufler für den Zugriff auf medizinische Daten au-torisieren

X X

Medizinische Daten bereit-stellen

X

Medizinische Daten fort-schreiben

X

Leistung erbringen X Patientenquittung erstellen X

Erarbeitung einer Strategie zur Einführung der...

Documents

Transcript of Erarbeitung einer Strategie zur Einführung der...