erarbeitung einer strategie zur einführung der...
Post on 18-Oct-2019
0 Views
Preview:
TRANSCRIPT
© 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)
© 2004 Projektgruppe bIT4health Seite 2 von 86
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
© 2004 Projektgruppe bIT4health Seite 3 von 86
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
© 2004 Projektgruppe bIT4health Seite 4 von 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.
© 2004 Projektgruppe bIT4health Seite 5 von 86
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
© 2004 Projektgruppe bIT4health Seite 6 von 86
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].
© 2004 Projektgruppe bIT4health Seite 7 von 86
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.
© 2004 Projektgruppe bIT4health Seite 8 von 86
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
© 2004 Projektgruppe bIT4health Seite 9 von 86
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.
© 2004 Projektgruppe bIT4health Seite 10 von 86
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-
© 2004 Projektgruppe bIT4health Seite 11 von 86
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.
© 2004 Projektgruppe bIT4health Seite 12 von 86
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.
© 2004 Projektgruppe bIT4health Seite 13 von 86
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
© 2004 Projektgruppe bIT4health Seite 14 von 86
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.
© 2004 Projektgruppe bIT4health Seite 15 von 86
Anwendungsfall Bezeichner des Anwendungsfalls Name Name des Anwendungsfalls
Nichtfunktionale Anforderungen
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
Administrative Kraft (des Leistungserbringers)
VD-4 Vertragsdaten übernehmen
Administrative Kraft (des Leistungserbringers)
VD-5 Zahlungsbeteiligung in Rechnung stellen
Versicherter VD-6 Zahlungsbeteiligung leisten
Administrative Kraft (des Leistungserbringers)
VD-7 Zahlungsbeteiligung quittieren
© 2004 Projektgruppe bIT4health Seite 16 von 86
Auslösender Akteur Anwendungsfall Nummer
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
Administrative Kraft (des Leistungserbringers)
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.
© 2004 Projektgruppe bIT4health Seite 17 von 86
Abbildung 3: Systemkontextdiagramm Vertragsdatenmanagement
3.5.2 Verordnungsmanagement
3.5.2.1 Generische Anwendungsfälle zum Verordnungsmanagement
Auslösender Akteur Anwendungsfall Nummer
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
© 2004 Projektgruppe bIT4health Seite 18 von 86
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.
Auslösender Akteur Szenario Num-mer
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
Auslösender Akteur Anwendungsfall Nummer
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
© 2004 Projektgruppe bIT4health Seite 19 von 86
Auslösender Akteur Anwendungsfall Nummer
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.
Auslösender Akteur Szenario Num-mer
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.
© 2004 Projektgruppe bIT4health Seite 20 von 86
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
© 2004 Projektgruppe bIT4health Seite 21 von 86
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.
Verordnungsmanagement
Behandlungsmanagement
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.
Verordnungsmanagement
Behandlungsmanagement
Verordnungsgeber (VG) Approbierter Heilberufler, der berechtigt ist, Verordnungen (und Überweisungen) auszu-stellen (Arzt oder Zahnarzt).
Verordnungsmanagement
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.
Verordnungsmanagement
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.
© 2004 Projektgruppe bIT4health Seite 22 von 86
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.
Vertragsdatenmanagement
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.
Vertragsdatenmanagement
Gesetzliche Kranken-kasse (KK)
Körperschaft des öffentlichen Rechts, die Leistungen der gesetzlichen Krankenversi-cherung für ihre Versicherten gewährt.
Vertragsdatenmanagement
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.
Vertragsdatenmanagement
Behandlungsmanagement
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.
Vertragsdatenmanagement
Verordnungsmanagement
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.
© 2004 Projektgruppe bIT4health Seite 23 von 86
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
Behandlungsmanagement
Verordnungseinlöser der Apotheke
Spezialisierung eines Verordnungseinlösers Verordnungsmanagement
ArzthelferIn (Ahe) Spezialisierung einer administrativen Kraft. Einbezogen in die Definition ist auch eine ZahnarzthelferIn.
Vertragsdatenmanagement
Verordnungsmanagement
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.ä.
Vertragsdatenmanagement
Verordnungsmanagement
Behandlungsmanagement
Übergreifende Funktion Einrichtung zur Kontrolle und Steuerung des Gesundheitswesens und potentiell der si-cheren Ablage von gesundheitsbezogenen Informationen.
Steuerungsmanagement
© 2004 Projektgruppe bIT4health Seite 24 von 86
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
VD-7 Zahlungsbeteiligung
quittieren
VD-8 Zahlungsbeteiligung
nachweisen
Admin. Kraft Admin. Kraft
Patient Patient Kranken-
versicherer Kranken- versicherer
Versicherter Versicherter
In der Rolle In der Rolle
«extend» «extend»
© 2004 Projektgruppe bIT4health Seite 25 von 86
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.
© 2004 Projektgruppe bIT4health Seite 26 von 86
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
Nichtfunktionale Anforderungen
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.
© 2004 Projektgruppe bIT4health Seite 27 von 86
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.
Funktionalität des Use Cases
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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
Nichtfunktionale Anforderungen
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
© 2004 Projektgruppe bIT4health Seite 28 von 86
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.
Funktionalität des Use Cases
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.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 29 von 86
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
Funktionalität des Use Cases
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
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 30 von 86
Use Case Nummer VD-4 Referenzen Prozess „Vertragsdaten lesen und aktualisieren“ (VD 103)
[b4hGPM]
Datenanforderungen Vertragsdaten nach § 291 Abs. 2 SGB V/GMG
Nichtfunktionale Anforderungen
Antwortzeitverhalten AZ 1 [b4hNFA]
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 31 von 86
Use Case Nummer VD-5 Alternativen Schritte 2 und 3 entfallen, sofern keine Pflicht zur Zahlungs-
beteiligung besteht.
Ausnahmen Keine
Benutzte Use Cases 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
Spezielle Anforde-rungen
Keine
Annahmen Keine
Offene Themen Keine
Referenzen Prozess „Zahlung abwickeln” (VD 102) [b4hGPM]
Datenanforderungen Zuzahlungsbefreiungen (ggf. zeitlich begrenzt) Die Art der Rechnungsstellung
Nichtfunktionale Anforderungen
Keine
4.1.2.6 Zahlungsbeteiligung leisten Use Case Nummer VD-6 Use Case Name Zahlungsbeteiligung leisten Initiierender Akteur Versicherte
Weitere Akteure Keine
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 32 von 86
Use Case Nummer VD-6 Ausnahmen Keine
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
Annahmen Keine
Offene Themen Keine
Referenzen Prozess „Zahlung abwickeln” (VD 102) [b4hGPM]
Datenanforderungen Keine
Nichtfunktionale Anforderungen
Keine
4.1.2.7 Zahlungsbeteiligung quittieren Use Case Nummer VD-7 Use Case Name Zahlungsbeteiligung quittieren Initiierender Akteur Administrative Kraft
Weitere Akteure Versicherter
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 33 von 86
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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
Nichtfunktionale Anforderungen
Antwortzeitverhalten AZ 1 [b4hNFA]
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.
© 2004 Projektgruppe bIT4health Seite 34 von 86
Use Case Nummer VD-8
Funktionalität des Use Cases
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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
Nichtfunktionale Anforderungen
Keine
© 2004 Projektgruppe bIT4health Seite 35 von 86
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)
Weitere Akteure Versicherter
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.
Funktionalität des Use Cases
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 36 von 86
Use Case Nummer VD-5-ZuZa1 Offene Themen Keine
Referenzen Keine
Datenanforderungen Information über das dispensierte Arzneimittel.
Nichtfunktionale Anforderungen
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)
Weitere Akteure Versicherter
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.
Oder Eine Zuzahlung wird nicht erhoben.
Funktionalität des Use Cases
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.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
Annahmen Keine
22 Der Zuzahlungsbetrag wird mit der Krankenkasse verrechnet.
© 2004 Projektgruppe bIT4health Seite 37 von 86
Use Case Nummer VD-5-ZuZa2 Offene Themen Keine
Referenzen Keine
Datenanforderungen Informationen über die erbrachte Leistung
Nichtfunktionale Anforderungen
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.
Oder Eine Zuzahlung wird nicht erhoben.
Funktionalität des Use Cases
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.
Alternativen Schritte 3 bis 4 werden nicht durchgeführt, weil keine Zuzah-lungspflicht besteht.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
© 2004 Projektgruppe bIT4health Seite 38 von 86
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
Nichtfunktionale Anforderungen
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)
Weitere Akteure Versicherter
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.
Funktionalität des Use Cases
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.
Alternativen Schritte 2 bis 3 werden nicht durchgeführt, weil keine Zuzah-lungspflicht besteht.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
Annahmen Keine
Offene Themen Keine
23 Der Zuzahlungsbetrag wird nach Erhalt von der Einrichtung an die Krankenkasse weitergeleitet.
© 2004 Projektgruppe bIT4health Seite 39 von 86
Use Case Nummer VD-5-ZuZa4 Referenzen Keine
Datenanforderungen Informationen zu der Rehabilitationsmaßnahme
Nichtfunktionale Anforderungen
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)
Einzug der Zuzahlung:
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.
Einzug der Zuzahlung:
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-
Einzug der Zuzahlung:
Die Krankenkasse ist für den Ein-zug der Zuzahlung zuständig
24 Stand 31.01.2004
© 2004 Projektgruppe bIT4health Seite 40 von 86
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)
Einzug der Zuzahlung:
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.
Einzug der Zuzahlung:
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.
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.
... 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.
© 2004 Projektgruppe bIT4health Seite 41 von 86
4.2 Verordnungsmanagement
4.2.1 Anwendungsfalldiagramm25
VO-2Übergabe-Dokument
zusammenstellen
VO-3Übergabe-Dokument
signieren
VO-4Übergabe-Dokument
auf Datenträger aufbringen
VO-5Verordnung/
Überweisung einreichen
VO-6Verordnung/
Überweisung übernehmen
VO-7Übergabe-Dokument
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.
© 2004 Projektgruppe bIT4health Seite 42 von 86
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.
Funktionalität des Use Cases
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".
© 2004 Projektgruppe bIT4health Seite 43 von 86
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.
Benutzte Use Cases Keine
Szenarios VO-1-AVO Arzneimittel-VO erfassen
Weitere Information
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 44 von 86
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.
Nichtfunktionale Anforderungen
Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.
4.2.2.2 Übergabe-Dokument zusammenstellen Use Case Nummer VO-2 Use Case Name Übergabe-Dokument zusammenstellen Initiierender Akteur Administrative Kraft
Weitere Akteure Keine
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.
© 2004 Projektgruppe bIT4health Seite 45 von 86
Use Case Nummer VO-2
Funktionalität des Use Cases
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.
Benutzte Use Cases Keine
Szenarios VO-2-AVO Arznei-Rezept zusammenstellen
Weitere Information
Spezielle Anforde-rungen
Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.
Annahmen Keine. Ggf. ergeben sich spezielle Annahmen im Szenario.
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.
© 2004 Projektgruppe bIT4health Seite 46 von 86
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.
Referenzen Prozess „eÜbergabe-Dokument schreiben“ (VO 101) [b4hGPM]
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.
Nichtfunktionale Anforderungen
Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.
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
Weitere Akteure Keine
Kurzbeschreibung Ein Übergabe-Dokument wird signiert.
© 2004 Projektgruppe bIT4health Seite 47 von 86
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.
Funktionalität des Use Cases
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.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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
Nichtfunktionale Anforderungen
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
Weitere Akteure Patient
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.
© 2004 Projektgruppe bIT4health Seite 48 von 86
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 49 von 86
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.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.
Annahmen Keine
Offene Themen Keine
Referenzen Prozess „eÜbergabe-Dokument schreiben“ (VO 101) [b4hGPM]
Datenanforderungen Keine. Die Datenanforderungen an das Übergabe-Dokument sind in den vorhergehenden Use Cases erwähnt worden.
Nichtfunktionale Anforderungen
Antwortzeitverhalten: AZ2 [b4hNFA]
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.
© 2004 Projektgruppe bIT4health Seite 50 von 86
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.
© 2004 Projektgruppe bIT4health Seite 51 von 86
Use Case Nummer VO-5 Benutzte Use Cases Keine
Szenario VO-5-AVO Arznei-VO in einer Apotheke einreichen
Weitere Information
Spezielle Anforde-rungen
Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.
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
Nichtfunktionale Anforderungen
Antwortzeitverhalten: AZ1 [b4hNFA]
4.2.2.6 Verordnung/Überweisung übernehmen Use Case Nummer VO-6 Use Case Name Verordnung/Überweisung übernehmen Initiierender Akteur Verordnungseinlöser
Weitere Akteure Keine
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.
© 2004 Projektgruppe bIT4health Seite 52 von 86
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 53 von 86
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
Spezielle Anforde-rungen
Die Kennzeichnung der Einlösung sollte vom Leistungserb-ringer signiert werden, um Manipulationen hinsichtlich einer Mehrfacheinlösung vorzubeugen.
Annahmen Keine. Ggf. ergeben sich spezielle Annahmen im Szenario.
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
Nichtfunktionale Anforderungen
Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.
Die Erbringung der verordneten Leistung erfolgt im Rahmen des Behandlungsmanagements.
© 2004 Projektgruppe bIT4health Seite 54 von 86
4.2.2.7 Übergabe-Dokument entwerten Use Case Nummer VO-7 Use Case Name Übergabe-Dokument entwerten Initiierender Akteur Verordnungseinlöser
Weitere Akteure Keine
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.
Funktionalität des Use Cases
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).
© 2004 Projektgruppe bIT4health Seite 55 von 86
Use Case Nummer VO-7 Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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]
Datenanforderungen Keine
Nichtfunktionale Anforderungen
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.
Funktionalität des Use Cases
© 2004 Projektgruppe bIT4health Seite 56 von 86
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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
© 2004 Projektgruppe bIT4health Seite 57 von 86
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.
Nichtfunktionale Anforderungen
Keine
4.2.3.2 Arznei-Rezept zusammenstellen Use Case Nummer VO-2-Arznei-VO Use Case Name Arznei-Rezept zusammenstellen Initiierender Akteur ArzthelferIn
Weitere Akteure Keine
Kurzbeschreibung Ein Arznei-Rezept für eine oder mehrere Arznei-VO wird zusammengestellt
Vorbedingung Arznei-VO ist erfasst
Nachbedingung Das Arznei-Rezept ist zusammengestellt
Funktionalität des Use Cases
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 58 von 86
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
Datenanforderungen Keine
Nichtfunktionale Anforderungen
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 59 von 86
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
Annahmen Keine
Offene Themen Keine
Referenzen Prozess „Verordnung einlösen“ (VO102) [b4hGPM]
Datenanforderungen Arznei-Verordnungsdaten
Nichtfunktionale Anforderungen
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
Weitere Akteure Keine
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.
© 2004 Projektgruppe bIT4health Seite 60 von 86
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.
Funktionalität des Use Cases
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
Spezielle Anforde-rungen
Keine
Annahmen Keine
© 2004 Projektgruppe bIT4health Seite 61 von 86
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
Nichtfunktionale Anforderungen
Keine
© 2004 Projektgruppe bIT4health Seite 62 von 86
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»
© 2004 Projektgruppe bIT4health Seite 63 von 86
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 64 von 86
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.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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
Nichtfunktionale Anforderungen
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
Weitere Akteure Approbierter Heilberufler
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.
© 2004 Projektgruppe bIT4health Seite 65 von 86
Use Case Nummer BE-2
Funktionalität des Use Cases
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.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 66 von 86
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
Weitere Akteure Approbierter Heilberufler
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 67 von 86
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.
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 68 von 86
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
Weitere Akteure Approbierter Heilberufler
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 69 von 86
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
Spezielle Anforde-rungen
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
Nichtfunktionale Anforderungen
Antwortzeitverhalten AZ 2 [b4hNFA]
© 2004 Projektgruppe bIT4health Seite 70 von 86
4.3.2.5 Medizinische Daten fortschreiben Use Case Nummer BE-5 Use Case Name Medizinische Daten fortschreiben Initiierender Akteur Approbierter Heilberufler
Weitere Akteure Patient
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 71 von 86
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.
© 2004 Projektgruppe bIT4health Seite 72 von 86
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
Spezielle Anforde-rungen
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.
Annahmen Keine. Ggf. ergeben sich spezielle Annahmen im Szenario.
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
Nichtfunktionale Anforderungen
Keine. Ggf. ergeben sich spezielle Anforderungen im Szena-rio.
54 Eine ähnliche Vorgehensweise, allerdings ohne Autorisierung, ist für die Aktualisierung von Vertragsdaten vorgesehen.
© 2004 Projektgruppe bIT4health Seite 73 von 86
4.3.2.6 Leistung erbringen Use Case Nummer BE-7 Use Case Name Leistung erbringen Initiierender Akteur Leistungserbringer
Weitere Akteure Patient
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.
Funktionalität des Use Cases
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
Benutzte Use Cases Keine
Szenarios BE-7-KI Kontra-Indikationscheck durchführen BE-7-IA Interaktionscheck durchführen
Weitere Information
Spezielle Anforde-rungen
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 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.
© 2004 Projektgruppe bIT4health Seite 74 von 86
Use Case Nummer BE-7 Datenanforderungen Ggf. Schnittstellen zu unterstützenden Software-Systemen
(z.B. Arzneimittel-IS)
Nichtfunktionale Anforderungen
Keine. Ggf. ergeben sich spezielle Anforderungen in den Szenarios.
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
Funktionalität des Use Cases
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
© 2004 Projektgruppe bIT4health Seite 75 von 86
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
Nichtfunktionale Anforderungen
Keine
© 2004 Projektgruppe bIT4health Seite 76 von 86
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.
Funktionalität des Use Cases
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.
© 2004 Projektgruppe bIT4health Seite 77 von 86
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
Spezielle Anforde-rungen
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
Nichtfunktionale Anforderungen
Antwortzeitverhalten AZ 2 [b4hNFA]
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.
Funktionalität des Use Cases
© 2004 Projektgruppe bIT4health Seite 78 von 86
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
Spezielle Anforde-rungen
Keine
Annahmen Keine
Offene Themen Keine
Referenzen Prozess-Schritt BE 101 – Medizinische Daten bereitstellen [b4hGPM] § 291a Abs. 5 SGB V/GMG.
Datenanforderungen Arzneimitteldokumentation
Nichtfunktionale Anforderungen
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
Weitere Akteure Patient
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.
Funktionalität des Use Cases
© 2004 Projektgruppe bIT4health Seite 79 von 86
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Ä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
© 2004 Projektgruppe bIT4health Seite 80 von 86
Use Case Nummer BE-5-KBD Referenzen Prozess-Schritt BE 103 – Medizinische Daten fortschreiben
[b4hGPM]
Datenanforderungen Klinische Basisdaten gemäß ISO-21549
Nichtfunktionale Anforderungen
Antwortzeitverhalten AZ2 [b4hNFA].
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
Weitere Akteure Keine
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.
Funktionalität des Use Cases
56 Inwieweit die Nebenwirkung toleriert wird, liegt im Ermessen des Heilberuflers.
© 2004 Projektgruppe bIT4health Seite 81 von 86
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
Annahmen Keine
Offene Themen Keine
Referenzen Prozess-Schritt BE 102 – Medizinische Maßnahme durchfüh-ren [b4hGPM]
Datenanforderungen Vertragsdaten Klinische Basisdaten Schnittstellen zu leistungserbringender Software
Nichtfunktionale Anforderungen
Antwortzeitverhalten AZ2 [b4hNFA].
© 2004 Projektgruppe bIT4health Seite 82 von 86
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
Weitere Akteure Keine
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.
Funktionalität des Use Cases
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
© 2004 Projektgruppe bIT4health Seite 83 von 86
Use Case Nummer BE-7-IA Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
Keine
Annahmen Keine
Offene Themen Keine
Referenzen Prozess-Schritt BE 102 – Medizinische Maßnahme durchfüh-ren [b4hGPM]
Datenanforderungen Offene Arznei-VO Arzneimitteldokumentation Schnittstellen zum IA-Check-Verfahren
Nichtfunktionale Anforderungen
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
© 2004 Projektgruppe bIT4health Seite 84 von 86
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
Funktionalität des Use Cases
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
Benutzte Use Cases Keine
Weitere Information
Spezielle Anforde-rungen
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.
© 2004 Projektgruppe bIT4health Seite 85 von 86
Use Case Nummer ST-1 Datenanforderungen Daten zu den freiwilligen Anwendungen
Nichtfunktionale Anforderungen
Keine
© 2004 Projektgruppe bIT4health Seite 86 von 86
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
top related