Mehrwertanwendung Facharchitektur

Transkript

1 Einführung der Gesundheitskarte Mehrwertanwendung Facharchitektur Mehrwertkommunikation Leistungserbringer Version: Revision: main/rel_main/30 Stand: Status: freigegeben gematik_mwa_facharchitektur_mwkle.doc Seite 1 von 100

2 Dokumentinformationen Änderungen zur Vorversion Es handelt sich um eine Erstveröffentlichung. Referenzierung Diese Dokument wird in weiteren Dokumenten der gematik referenziert unter: [gemfa_mwk_le] gematik: Facharchitektur Mehrwertanwendung Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Neuerstellung, interne QS ITS/AP freigegeben gematik Überarbeitung nach Vorkommentierung IST/AP freigegeben gematik gematik_mwa_facharchitektur_mwkle.doc Seite 2 von 100

3 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokumentes Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokumentes Anforderungen und Annahmen Einschränkungen und Annahmen Anforderungen Beschreibung der technischen Use Cases Einleitung Vorgaben und generelle Hinweise zur Umsetzung Abbildung fachlicher Anwendungsfälle auf Technische Use Cases Bezeichnung der Akteure Mehrwertanwendung TYP Dokument in den MWD einstellen Ablauf_MWKLE_Dokument_schreiben Dokument signieren TUC_MWKLE_05_Empfaenger_suchen Verzeichnis der LE TUC_MWKLE_04_Dokument_schreiben Dokument vom MWD abrufen Ablauf_MWKLE_Dokument_lesen TUC_MWKLE_02_DokumentVerweise_lesen TUC_MWKLE_01_Dokument_lesen TUC_MWKLE_03_Dokument_löschen TUC_MWKLE_09_AbgelaufeneDokumente_löschen Schnittstelle Primärsystem/Konnektor...40 gematik_mwa_facharchitektur_mwkle.doc Seite 3 von 100

4 5.1 WriteDocument Request MetaParameter MDOParameter Response MetaParameter MDOParameter ReadDocument Request MetaParameter MDOParameter Response MetaParameter MDOParameter ReadDocumentPointer Request MetaParameter MDOParameter Response MetaParameter MDOParameter Search Request MetaParameter MDOParameter Response MetaParameter MDOParameter GetCertificate Request MetaParameter MDOParameter Response MetaParameter MDOParameter DeleteDocument Request MetaParameter MDOParameter Response MetaParameter MDOParameter Mehrwertfachdienst MWKLE Komponentenmodell des MWD MWKLE Schnittstelle zum MWD MWKLE...54 gematik_mwa_facharchitektur_mwkle.doc Seite 4 von 100

5 6.3 MWKLE Operationen Ablauf MWKLE Fehlerbehandlung Übergreifende Fehler Konfiguration des MWKLE Dienstes Rechtematrix im MWD Verschlüsselung von Dokumenten Broker-Konfiguration Konfiguration des Service Directory Service (SDS) Modellbeschreibung Einleitung Einschränkungen Grundlagen Gesamtmodell Geschäftsvorgang earztbrief Attribute DokumentenId Dokumententyp Erstellungsdatum Titel Assoziierte Klassen Teilnahme Ausstellende Organisation Teilnahme Patient Teilnahme Empfänger Teilnahme Autor Teilnahme Verantwortlicher Unterzeichner Teilnahme Unterzeichner Teilnahme Beteiligte Geschäftsvorgang Einverständniserklärung Geschäftsvorgang Patientenkontakt Existenz Person Existenz Organisation Inhalt des Arztbriefes Geschäftsvorgang Diagnose Geschäftsvorgang Therapie Geschäftsvorgang Fragestellung Geschäftsvorgang Notizen Geschäftsvorgang Epikrise Geschäftsvorgang Anamnese Geschäftsvorgang Befund Geschäftsvorgang Hinweise Geschäftsvorgang Anrede...75 gematik_mwa_facharchitektur_mwkle.doc Seite 5 von 100

6 Anhang A Fehlermeldungen...76 Anhang B Parametrisierung der MWD Schnittstelle...77 Anhang C Übersicht über die verwendeten Versionen...80 Anhang D Schemata...81 D1 - Arztbrief nach VHitG...81 D2 - Einschränkungen...81 D3 - Schema MWKLE.xsd...81 Anhang E Ausgangsanforderungen...94 Anhang F...96 F1 - Abkürzungen...96 F2 - Abbildungsverzeichnis...96 F3 - Tabellenverzeichnis...97 F4 Referenzierte Dokumente...98 F4.1 Dokumente der gematik...98 F4.2 Weitere Dokumente...99 gematik_mwa_facharchitektur_mwkle.doc Seite 6 von 100

7 1 Zusammenfassung Dieses Dokument spezifiziert die Umsetzung der fachlichen Kommunikation von Leistungserbringern (LE) über die Telematikinfrastruktur. Zur technischen Umsetzung wurde auf die Möglichkeit zurückgegriffen, über den Konnektor Mehrwertfachdienste aufzurufen. Um den fachlichen Rahmen abzugrenzen, wurde die Kommunikation auf das Senden und Abholen von XML- Dokumenten und hier spezialisiert von CDA2-konformen Arztbriefen eingeschränkt. In der jetzigen Stufe wird nur die gerichtete Kommunikation von einem LE an einen anderen LE betrachtet. Das Dokument ist in zwei grobe Abschnitte unterteilt. Der erste informative Abschnitt beschreibt den fachlichen Mehrwertfachdienst MWKLE und die Nutzung der Mehrwertdienstschnittstelle zum Adressieren der Mehrwertfachfunktionen. Ein zweiter Abschnitt geht auf die prototypische Umsetzung des Versendens von VHitGkonformen Arztbriefen ein. Hier werden Aussagen zur Modellierung des Arztbriefes getroffen und es wird auf relevante Beschreibungen in externen Dokumenten verwiesen. gematik_mwa_facharchitektur_mwkle.doc Seite 7 von 100

8 2 Einführung 2.1 Zielsetzung und Einordnung des Dokumentes Die von der gematik spezifizierte Leistungserbringer-Kommunikation (Mehrwertkommunikation Leistungserbringer; MWKLE) nutzt die vorhandenen Sicherheitskonzepte und das spezifizierte Transportprotokoll der gematik. In dem vorliegenden Dokument werden die fachlichen Funktionen des Mehrwertfachdienstes und die Schnittstellen zu den Komponenten der Telematikinfrastruktur beschrieben. Zur Umsetzung der MWKLE-Funktionalitäten werden zwischen verschiedenen Komponenten (technischen Akteuren) innerhalb und außerhalb der Telematik Informationen ausgetauscht. Die hier zu betrachtenden Komponenten sind die Primärsysteme, der Konnektor, der Broker und der Mehrwertfachdienst. Technisch gesehen werden über SOAP jeweils Funktionen, Dienste oder Services aufgerufen, die durch jeweils andere Komponenten angeboten werden. Bei der Erstellung der MWKLE sind verschiedene Annahmen getroffen worden, die in Kapitel 3 dokumentiert sind. Anwendungsfälle, die durch die MWKLE unterstützt werden, werden in Kapitel 4 veranschaulicht. Die Umsetzung der im MWKLE realisierten SOAP- Funktionalitäten wird hier als Schnittstelle bezeichnet und in Kapitel 5 beschrieben. Das Kapitel 6 beschreibt den Mehrwertfachdienst MWKLE und ordnet ihn in den Gesamtkontext Mehrwertanwendungen TYP4 ein. Im Kapitel 7 werden die spezifischen Konfigurationseinstellungen für den Aufruf der Mehrwertfachdienstoperationen aufgelistet. Das Datenmodell des VHitG Arztbriefes wird in Kapitel 8 dargestellt. Die Schnittstelle des Konnektors zum Broker ist transparent und ist deshalb identisch mit der Schnittstelle des Fachdienstes MWKLE. Parameter für den Broker werden im Kapitel 7 dargestellt. 2.2 Zielgruppe Das Dokument richtet sich neben Personengruppen, die grundsätzlich an der MWKLE interessiert sind, an Spezifikateure des Mehrwertfachdienstes MWKLE Primärsystemhersteller die den MWKLE nutzen wollen Konnektorhersteller gematik_mwa_facharchitektur_mwkle.doc Seite 8 von 100

9 2.3 Geltungsbereich Das Dokument setzt auf Arbeiten der gematik zur Umsetzung der Verordnung über Testmaßnahmen für die Einführung der elektronischen Gesundheitskarte [RVO2006] in der Bundesrepublik Deutschland auf. MWKLE ist nicht Bestandteil der genannten Arbeiten. Eine Umsetzung ist für die Primärsystemhersteller nicht verpflichtend. Erfolgt eine Realisierung, so muss die Umsetzung den in diesem Dokument genannten Vorgaben entsprechen. Eine Umsetzung des Mehrwertfachdienstes wird ab dem Release Feldtest Online (2.3.4) möglich sein. 2.4 Arbeitsgrundlagen Grundlagen für die Ausführungen dieses Dokuments sind die Anforderungen der Leistungserbringer und die allgemeinen und speziellen Vorgaben durch die gematik, vornehmlich in der Gesamtarchitektur, bezogen auf die Mehrwertfachdienste in. dem Fachkonzept MWKLE der gematik [gemfk_mwk_le], der Facharchitektur MWD TYP4 [gemfa_mwd4] der Gesamtarchitektur [gemgesarch] der Konnektorspezifikation [gemspec_kon] der Spezifikation der Ticket Schnittstelle [gemspec_ticket] der Spezifikation TelematikTransport-Details [gemspec_ttd]. 2.5 Abgrenzung des Dokumentes Innerhalb dieses Dokumentes wird auf die technisch umzusetzenden Aspekte der Nutzung der Mehrwertkommunikation im Zusammenspiel mit VHitG Arztbrief und dem MWKLE Mehrwertfachdienst eingegangen. Für Informationen zum fachlichen Gesamtkontext wird auf das Fachkonzept MWKLE verwiesen. Bei den Facharchitekturen wurde darauf geachtet, dass allgemeingültige Funktionalitäten nicht mehrfach beschrieben werden. So ist zum Beispiel das Prüfen eines Zertifikates auf einem HBA in [gemverw_zert_ti] beschrieben. Darüber hinaus wurden allgemeingültige Architekturfunktionalitäten, wie z. B. das Erstellen eines Objekt Tickets, in eigenständigen, von der einzelnen Facharchitektur unabhängigen Dokumenten beschrieben. Die Erläuterungen setzen teilweise die Kenntnis anderer Komponenten der Telematikinfrastruktur voraus. Die Umsetzung basiert auf Bestandteilen der Infrastruktur, die in weiteren Dokumenten detailliert beschrieben werden. Relevant für das Verständnis sind vor allem: gematik_mwa_facharchitektur_mwkle.doc Seite 9 von 100

10 [gemgesarch] Gesamtarchitektur. Hier wird die Gesamtarchitektur der Telematik beschrieben, wobei insbesondere die Kapitel zum Thema Mehrwertfachdienste, Komponentenmodell und zur Nachrichtenstruktur relevant sind. [gemspec_kon] Spezifikation des Konnektors. Hier werden unter Anderem sämtliche Schnittstellen des Konnektors beschrieben, die durch die Primärsysteme genutzt werden können. Verwiesen sei hier besonders auf die Basisfunktionalitäten, die zum Beispiel das Nutzen der Karten ermöglichen und auf die generische Schnittstelle für die Nutzung der Mehrwertfachdienste. [gemspec_ttd] Spezifikation TelematikTransport-Details mit der Beschreibung der Telematik-Transport-Schnittstelle, der Feinspezifikation der SOAP-Nachrichtenstruktur und der Abarbeitung der generischen Aufrufe auf den Fachdiensten. [gemspec_ticket] Spezifikation der Ticket-Schnittstelle. [gemfa_mwd4] Beschreibt die grundlegende Architektur von Mehrwertfachdiensten des Types 4. gematik_mwa_facharchitektur_mwkle.doc Seite 10 von 100

11 3 Anforderungen und Annahmen 3.1 Einschränkungen und Annahmen Die in diesem Dokument beschriebene Spezifikation einer Mehrwertanwendung dient vor allem dazu, eine prototypische Umsetzung der am Beispiel des Versandes von Arztbriefen zu ermöglichen. Für diesen Einsatzzweck wird von einem beschränkten Nutzerkreis ausgegangen. Nutzer sind hier LE, die an den Tests, die diesen Prototyp betreffen, teilnehmen. Folgende Themen sind nicht abschließend betrachtet worden. Lastverhalten und Antwortzeiten; Mengenbetrachtungen bezogen auf die Anzahl der zu transportierenden Dokumente; Mengenbetrachtungen bezogen auf die Anzahl der teilnehmenden LE in einem Wirkbetrieb; Aspekte des Managements des Verzeichnisses der LE; Fragen des Betriebes und der Verfügbarkeit des Mehrwertfachdienstes; Fragen zu den Themen Betreibermodell und Ausschreibungen. Folgende Annahmen werden getroffen: Die Anzahl der teilnehmenden LE ist nicht wesentlich größer als 200; Die teilnehmenden LE senden jeweils nur eine geringe Anzahl von Arztbriefen pro Tag; Die LE senden nur Arztbriefe und keine anderen XML-Dokumente; Die Verschlüsselungszertifikate der LE werden auf dem Mehrwertfachdienst vorgehalten. Der Eintrag der Verschlüsselungszertifikate und der notwendigen Metadaten erfolgt im Zuge der Implementierung des Mehrwertfachdienstes; Es werden keine Prozesse vorgesehen, die eine Pflege der Metadaten oder der Verschlüsselungszertifikate betreffen. Es wird davon ausgegangen, dass notwendige Änderungen im Zuge der Pilotierung durch den Betreiber des Mehrwertfachdienstes durchgeführt werden können. gematik_mwa_facharchitektur_mwkle.doc Seite 11 von 100

12 3.2 Anforderungen Tabelle 1: Eingangsanforderungen Afo-ID A_03786 N A_03788 N A_03822 N A_03908 F Klasse Titel Beschreibung Umge- 1 setzt durch Genehmigte Akteure MKWLE Genehmigte Artefakte über MKWLE Vorgabe des VHitG: Anpassung an Metamodell gematik Umsetzung MWKLE als Dienst Es MUSS sichergestellt sein, dass über Mehrwertkommunikation der Leistungserbringer alle Leistungserbringer gemäß SGB V 291a MDO versenden und empfangen können. Leistungserbringer KÖNNEN durch die Mehrwertkommunikation der Leistungserbringer alle MDO versenden, die sie im Rahmen der von ihnen zur Sicherstellung der Versorgung des Versicherten notwendigen Aktivitäten benötigen. ( z.b. VHiTG Arztbrief ) Diese Anforderung gilt unter den Bedingungen aus A_03827 (keine Anhänge) und A_03793 (XML). Das Format des MDO Arztbrief KANN mit dem Metamodell der gematik abgeglichen sein. Der MWKLE KANN funktional als Dienst in Analogie zu den Fachdiensten des Releases 2.3.x erstellt werden. A_03996 A_03997 A_03998 A_03999 A_04000 A_04001 A_04002 A_04003 A_04004 A_04005 A_04006 A_04007 A_03996 A_03997 A_03998 A_03999 A_04000 A_04001 A_04002 A_04003 A_04004 A_03996 A_03997 A_03998 A_03999 A_04000 A_04001 A_04002 A_04003 A_04004 A_04005 A_04006 A_04007 A_03996 A_03997 A_03998 A_03999 A_04000 A_04001 A_04002 A_04003 A_04004 A_04005 A_04006 A_ Klasse: F (funktional), N (nicht-funktional), S (Sicherheit), L (Leistungsanforderung), I (informative Anforderungen) gematik_mwa_facharchitektur_mwkle.doc Seite 12 von 100

13 Afo-ID A_03909 F A_03910 F A_03923 F A_03932 F A_03933 F A_03934 N A_03935 F A_03936 F A_03937 N Klasse Titel Beschreibung Umge- 1 setzt durch Löschungen von Artefakten in MWKLE Gelesen-Markierung von Artefakten in MWKLE Verschlüsselung der Fachdaten für den Transport durch Konnektor Realisierung MWKLE als Mehrwertanwendung zum Informationsaustausch Komplette Nutzung der Telematikinfrastruktur für MWKLE Mögliche Dokumente zum Versand VHitG Arztbrief ist Basis für MWKLE Arztbrief Entschlüsselung des Dokumentes beim Abrufen Suchkriterien der Empfänger-Auswahlliste In Abhängigkeit von fachlichen oder technischen Anforderungen KANN ein Löschverfahren festgelegt werden, das als Funktionalität des Mehrwertdienstes nicht mehr benötigte oder außerhalb von zulässigen Aufbewahrungsfristen liegende MDO aus den Mehrwertdiensten entfernt. Eine Gelesen-Markierung KANN (unter Abstimmung der Fachlichkeit) festgelegt werden. Konnektoren MÜSSEN für Typ-4 Mehrwertanwendungen alle über die Telematikinfrastruktur transportierten Fachdaten für die leseberechtigten Empfänger der Daten verschlüsseln. Die Anwendung MWKLE MUSS umgesetzt werden als Beispiel einer Mehrwertanwendung, die einen Informationsaustausch zwischen Leistungserbringern ermöglicht. Die Mehrwertanwendung Kommunikation Leistungserbringer MUSS zu ihrer Realisierung die, in der Gesamtarchitektur für eine Mehrwertanwendung Typ 4 definierten, Anteile der Telematikinfrastruktur nutzen können. Neben dem Arztbrief KANN in der MWKLE jedes andere Dokument (XML- Datei), das Leistungserbringer im Rahmen der von ihnen zur Sicherstellung der Versorgung des Versicherten notwendigen Aktivitäten benötigen, ein Dokument der sein. Die Basis für das Infomodell und die Beschreibung der Daten des MWKLE Arztbriefes MUSS der Implementierungsleitfaden für den VHitG-Arztbrief [VHitG Arztbrief] sein. Mit dem Abrufen des Dokumentes durch den adressierten Empfänger MUSS das Dokument ohne weitere fachliche Aktion entschlüsselt werden. Die Empfänger-Auswahlliste SOLL für den Anwender über Kriterien (z.b. Institu- A_04001 A_04024 A_03996 A_03997 A_04003 A_03996 A_03997 A_03998 A_03999 A_04000 A_04001 A_04002 A_04003 A_04004 A_04005 A_04006 A_04007 Gesetzt durch Gesamtarchitektur A_03996 A_03997 A_03998 A_03999 A_04000 A_04001 A_04002 A_04003 A_04004 A_04003 A_03997 A_04005 A_04006 gematik_mwa_facharchitektur_mwkle.doc Seite 13 von 100

14 Afo-ID A_03938 N A_03939 N A_03940 N A_03941 N A_03942 S A_03943 S A_03944 F A_03945 F A_03973 F A_03974 N A_03975 N Klasse Titel Beschreibung Umgesetzt durch tionsname, Nachname, Vorname, Postleitzahl, Stadt, Straße, Hausnummer) A_04007 Suchkriterien der Empfänger- Auswahlliste: Eingabe Information des Empfängers über bereitgestelltes Versand-Dokument Ausschluss von Dokumenten für den Transport über die MWKLE Löschfrist für Versand- Dokumente auf dem Mehrwertfachdienst Verschlüsselung des Dokumentes beim Bereitstellen Einwilligung des Versicherten in Übermittlung der Daten des Arztbriefs Use Case muss erfüllt werden Use Case muss erfüllt werden Ausschluss anderer Mehrwertfachdienste Schnittstellen in die TI Definition von Fachdaten und Metadaten in Spezifikationen der Mehrwertanwendungen Typ 4 Definition Metadaten in Spezifikationen der Mehrwertanwendungen Typ 4 komfortabel einzuschränken sein. Es SOLL möglich sein, dass die Kriterien der Empfänger-Auswahlliste durch den Anwender auch aktiv eingegeben werden können. Die Information des Empfängers über die Bereitstellung eines Versand-Dokumentes in MWKLE MUSS organisatorisch zwischen Sender und Empfänger erfolgen. Dokumente (XML-Dateien) die über eine bestehende Anwendung aus der RVO2006 abgedeckt sind, DÜRFEN NICHT über die Mehrwertkommunikation Leistungserbringer transportiert werden. Durch das Erreichen der technischen Löschfrist MUSS ein Versand-Dokument automatisch vom Mehrwertfachdienst MWKLE entfernt werden. Das Dokument MUSS ohne jede weitere fachliche Aktion beim Bereitstellen für den adressierten Empfänger verschlüsselt werden. Die Einwilligung des Versicherten zur Übermittlung seiner Daten in einem Arztbrief MUSS erteilt werden, jedoch nicht in technisch (telematisch) unterstützter Form. "UC_130 Versand-Dokument bereitstellen" MUSS erfüllt werden. "UC_132 Versand-Dokument(e) abrufen" MUSS erfüllt werden. Mehrwertfachdienste DÜRFEN NICHT andere Schnittstellen außer gemäß [gemspec_ttd] in die TI anbieten. Spezifikationen für Mehrwertanwendungen Typ 4 MÜSSEN die zu transportierenden Parameter definieren und MÜSSEN festlegen, ob es sich jeweils um Fachdaten bzw. Metadaten handelt. Spezifikationen für Mehrwertanwendungen Typ 4 MÜSSEN Metaparameter so genau spezifizieren, dass eine inhaltliche und qualifizierte Syntaxprüfung im Mehr- A_04005 A_04006 A_04007 A_03998 A_04021 Organisatorische Festlegung. A_04001 A_04003 Organisatorische Festlegung. A_04003 A_04004 A_04005 A_04006 A_04007 A_03996 A_03997 A_03998 A_03999 A_04000 A_04001 A_04002 Dieses Dokument Kapitel 5 Kapitel 5 gematik_mwa_facharchitektur_mwkle.doc Seite 14 von 100

15 Afo-ID A_03976 N Klasse Titel Beschreibung Umgesetzt durch wertfachdienst möglich ist. Insbesondere sind freie Definitionen (wie z.b. Any-Elemente, base64 encoding ohne zusätzliche Strukturangabe oder xs:string ohne Längenbeschränkung) nicht zulässig. Einhaltung Schutzbedarf für Metadaten der Mehrwertanwendungen Typ 4 A_03977 F Mehrwertfachdienste Prüfung Parameter I A_03978 F Mehrwertfachdienste Prüfung Parameter II A_03979 F A_04066 S DS: Mehrwertdienst Kommunikation zwischen Leistungserbringern Spezifikationen für Mehrwertanwendungen Typ 4 DÜRFEN NICHT Parameter als Metaparameter definieren, die Informationsobjekte mit Schutzbedarf höher als mittel beinhalten. Mehrwertfachdienste MÜSSEN prüfen, dass Nachrichten nur die spezifizierten Parameter enthalten und MÜSSEN die Verarbeitung mit einem Fehler abbrechen, wenn benötigte Parameter fehlen oder nicht spezifizierte Parameter vorhanden sind. Mehrwertfachdienste MÜSSEN sicherstellen, dass laut Spezifikation definierte Fachdaten verschlüsselt sind und nur aus einem xenc:encrypteddata-element bestehen. Mehrwertfachdienste MÜSSEN prüfen, dass Metaparameter inhaltlich der Spezifikation entsprechen und eine qualifizierte Syntaxprüfung durchführen. Für das Release wird als erster Mehrwertdienst eine Kommunikation zwischen Leistungserbringern pilotiert. Dieser Dienst ermöglicht den Austausch von beliebigen personenbezogenen medizinischen Daten mit einem Schutzbedarf bezüglich der Vertraulichkeit und Authentizität von bis zu sehr hoch und die Daten werden mit den entsprechenden Schlüsseln der Karten des Absenders signiert und des Empfängers verschlüsselt und die Authentizität der Teilnehmer wird vom Dienst geprüft. Jeder Leistungserbringer mit einer personengebundenen oder Institutionenkarte (HBA/BA/SMC-B) KANN diesen Dienst nutzen und beliebige Daten schreiben sowie die für ihn bestimmten Daten lesen und löschen. Für die Einhaltung der Datenschutzrechtlichen Voraussetzungen für den Datenaustausch u.a. Einwilligung des Versicherten beim Austausch personenbezogener medizinischer Daten ist der jeweilige Leistungserbringer verantwortlich und muss entsprechend in der Behandlungsdokumentation aufgenommen Kapitel 5 Kapitel 6 Kapitel 6 Kapitel 6 Dieses Dokument gematik_mwa_facharchitektur_mwkle.doc Seite 15 von 100

16 Afo-ID A_04067 S A_04387 F A_04388 F A_04389 F A_04390 F Klasse Titel Beschreibung Umgesetzt durch werden. Eine Versichertenzentrierte Auditierung der Kommunikationsvorgänge findet im Release noch nicht statt. DS: MWD Typ4 bedingt versichertenzentrierten Audit Unterschreiten der technischen Löschfrist "Hinweise zum Empfänger" beim Versand Lesbarkeit der "Hinweise zum Empfänger" beim Abrufen Information des Empfängers über bereitgestelltes Dokument durch das Primärsystem Bei Mehrtwertanwendungen vom Typ4, die personenbezogene medizinische Daten eines Versicherten austauschen, MUSS der versichertenzentrierte Audit- Service zur Datenschutzkontrolle verwendet werden. Der Sender MUSS die technische Löschfrist eines Dokumentes auf dem Mehrwertdienst durch die Angabe eines maximalen Aufbewahrungszeitraumes (Datum YYYYMMDD) beim Bereitstellen unterschreiten können. Zur näheren Beschreibung des Empfängers, wie z.b. einer Person oder Abteilung innerhalb einer Institution, MUSS die MWK_LE dem Sender 5-mal 200 Zeichen Freitext ("Hinweise zum Empfänger") beim Versand eines Dokumentes zur Verfügung stellen. Einträge in "Hinweise zum Empfänger" MUSS der Empfänger lesen können, ohne das Dokument zu öffnen. Durch ein regelmäßiges Abrufen der Dokumente vom Mehrwertdienst, SOLL das Primärsystem des Empfängers die technische Information des Empfängers über die Bereitstellung eines Dokumentes ü- bernehmen können. Dieses Dokument gematik_mwa_facharchitektur_mwkle.doc Seite 16 von 100

17 4 Beschreibung der technischen Use Cases 4.1 Einleitung Vorgaben und generelle Hinweise zur Umsetzung Bei der Erarbeitung der technischen Anwendungsfälle sind folgende Vorgaben zu Vorgehensweise, Modellierung und technischer Umsetzung beachtet worden: Die Modellierung der Sequenzen konzentriert sich auf den fachlichen bzw. technischen Ablauf und die Schnittstellen zwischen: o Primärsystem und Konnektor. o Konnektor und Mehrwertfachdienst o Der Transport der Nachrichten zum Mehrwertfachdienst wird durch [gemspec_ttd] spezifiziert und ist für die Modellierung der Sequenzen transparent. Arbeitsabläufe des Brokers werden hier in den Use Cases aus Gründen der Übersichtlichkeit nicht berücksichtigt. Sie werden in [gembroker] ausreichend beschrieben. In Sequenzdiagrammen wird zu Gunsten einer übersichtlicheren Darstellung bewusst auf eine syntaktisch korrekte UML-Modellierung fehlerbedingter Prozessabbrüche mittels einer Ja/Nein-Bedingung verzichtet. Prozessschritte, die zu einer nicht auf ein spezifisches Datenobjekt bezogenen Fehlermeldung führen, brechen den Ablauf des Use Cases ab. Das heißt der Use Case wird an dieser Stelle mit einer entsprechenden Fehlermeldung beendet. Prozessschritte, die zu einer auf ein spezifisches Datenobjekt bezogenen Fehlermeldung führen, brechen den Ablauf für dieses Datenobjekt ab. Die Abarbeitung von weiteren Datenobjekten in dem Use Case wird damit nicht unterbrochen. Zusammenhängende Aktionen eines LE werden in so genannten Abläufen beschrieben. Abläufe sind als Sequenzdiagramme abgebildet und stellen eine Abfolge von Aktivitäten, die durch TUC beschrieben werden dar. Der Ablauf dient der Erläuterung und ist nicht verpflichtend. Um ein klareres Verständnis zur Nutzung der durch verschiedene Komponenten bereitgestellten Funktionen zu ermöglichen, sind zu jedem TUC ein oder mehrere Sequenzdiagramme beigefügt worden Abbildung fachlicher Anwendungsfälle auf Technische Use Cases Es werden folgende fachliche Anwendungsfälle für die Mehrwertkommunikation unterschieden, die in der Tabelle 2 auf technische Anwendungsfälle abgebildet wurden: gematik_mwa_facharchitektur_mwkle.doc Seite 17 von 100

18 Tabelle 2: Übersicht der abgebildeten Anwendungsfälle Fachliche Anwendungsfälle Technische Use Cases UC_130 Dokument bereitstellen UC_132 Dokument(e) abrufen Ablauf_MWKLE_Dokument_schreiben TUC_MWKLE_05_Empfaenger_suchen TUC_MWKLE_04_Dokument_schreiben Ablauf_MWKLE_Dokument_lesen TUC_MWKLE_01_Dokument_lesen TUC_MWKLE_02_DokumentVerweise_lesen TUC_MWKLE_03_Dokument_löschen Die Tabelle führt die am Konnektor aufrufbaren TUC und die sie nutzenden Ablaufbeschreibungen auf. Die durch diese TUC aufgerufenen weiteren TUC werden hier nicht aufgelistet Bezeichnung der Akteure Grundsätzlich sind alle im Fachkonzept genannten Akteure berechtigt, die Operationen des Mehrwertfachdienstes zu nutzen. Das Signieren unterliegt bezüglich der berechtigten Akteure einer Einschränkung. Um eine wiederholte Auflistung aller Akteure in jeder TUC Beschreibung zu vermeiden, werden die Akteure in den TUC Beschreibungen durch die folgenden Synonyme bezeichnet: 1. Leistungserbringer (LE) Gemeinsames Merkmal ist hier, dass sie alle über einen HBA verfügen bzw. ihnen der Zugriff auf eine SMC-B erlaubt wurde. Der Begriff bezeichnet im Folgenden die Akteure: Arzt Mitarbeiter medizinische Institution Apotheker Mitarbeiter Apotheke Psychotherapeut 2. Signaturberechtigte Leistungserbringer (SigLE) Gemeinsames Merkmal ist hier, dass sie alle über einen HBA verfügen und diesen zur Erstellung einer Qualifizierten Elektronischen Signatur nutzen können. Der Begriff bezeichnet im Folgenden die Akteure: Arzt Apotheker Psychotherapeut gematik_mwa_facharchitektur_mwkle.doc Seite 18 von 100

19 4.2 Mehrwertanwendung TYP4 MWKLE wird als Mehrwertanwendung TYP 4 [gemgesarch] umgesetzt. Die Kommunikation des PS mit dem MWD und die Umsetzung des MWD folgen den in [gemfa_mwd4] beschriebenen Grundsätzen und Regeln. Grundlegenden Funktionen, die ein MWD TYP 4 bereitstellen muss, werden hier nur erwähnt, wenn sich aus der konkreten Umsetzung des Mehrwertfachdienstes MWKLE besondere, nicht allgemein abbildbare Ausprägungen ergeben. Einzelheiten dazu sind in Kapitel 6 ausgeführt. In [gemfa_mwd4] ist der generische technische UseCase TUC_MWD4_01_Mehrwertdienst_Operation_aufrufen beschrieben, der grundsätzlich den Aufruf von Mehrwertfachdienst-Operationen des TYP4 durch Primärsysteme beschreibt. Dieser TUC wird nachfolgend verwendet, um die Operationen des MWD anzusprechen. Durch die entsprechende Parametrisierung der TUC-Schnittstelle können die Operationen des MWD jeweils adressiert und parametrisiert werden. 4.3 Dokument in den MWD einstellen Das in [gemfk_mwk_le] beschriebene Aktivitätsdiagramm Dokument bereitstellen beschreibt das Einstellen eines Dokumentes auf den MWKLE. Der unter beschriebene Ablauf Ablauf_MWKLE_Dokument_schreiben stellt die Umsetzung in der Facharchitektur dar. Im Folgenden die Darstellung der Aktivitäten aus dem Fachkonzept zu den TUC in der Facharchitektur. Tabelle 3: Zuordnung Fachkonzept zu Facharchitektur (einstellen) Aktivität im Fachkonzept Dokument im Primärsystem auswählen Empfänger auswählen Dokument signieren [Hinweise zum Empfänger eingeben] [Maximalen Aufbewahrungszeitraum festlegen] Dokument auf dem Mehrwertdienst speichern TUC in der Facharchitektur Keine technische Abbildung da außerhalb der TI. TUC_MWKLE_05_Empfaenger_suchen TUC_KON_060 Dokument signieren TUC_MWKLE_041_Dokument_schreiben gematik_mwa_facharchitektur_mwkle.doc Seite 19 von 100

20 4.3.1 Ablauf_MWKLE_Dokument_schreiben Im Folgenden wird der Ablauf zum Schreiben von XML Dokumenten auf den Mehrwertfachdienst in Einzelschritten dargestellt. Voraussetzung ist, dass am Primärsystem ein XML-Dokument vorliegt. Ablauf_MWKLE_Dokument_schreiben beschreibt den fachlichen Ablauf des Schreibens von Dokumenten auf den MWD am PS. sd Ablauf_MWKLE_Dokument_schreiben SigLE LE :Primärsystem Mehrwert Komponente :Anwendungskonnektor Mehrwertdienst :Fachdienst opt Dokument signieren [Dokument soll signiert werden] ref TUC_KON_060 Dokument signieren opt Verschlüsselungszertifikat des Empfängers ermitteln [Verschlüsselungszertifikat des Empfängers nicht im PS vorhanden] ref TUC_MWKLE_05_Empfaenger_suchen ref TUC_MWKLE_041_Dokument_schreiben Abbildung 1: Ablauf_MWKLE_Dokument_schreiben Vor dem Versenden KANN das Dokument durch einen SigLE mit dessen Zertifikat qualifiziert signiert werden. [A_04011] Arztbriefe MÜSSEN vor dem Versenden durch einen SigLE mit dessen Zertifikat qualifiziert signiert werden. [A_04221] Ist das Dokument schon entsprechend den Anforderungen signiert, so kann der Schritt entfallen. gematik_mwa_facharchitektur_mwkle.doc Seite 20 von 100

21 Im nächsten Schritt muss der LE das zu dem Empfänger (LE) gehörige Verschlüsselungszertifikat in das Primärsystem laden. Ist das Zertifikat schon im PS vorhanden, kann dieser Schritt entfallen, ansonsten wird TUC_MWKLE_05_Empfaenger_suchen aufgerufen. Als Ergebnis des Schrittes liegt das Verschlüsselungszertifikat (ENC) des Empfängers im PS vor. Es obliegt dem LE zu entscheiden, ob er das Dokument an einen Leistungserbringer oder an dessen Institution sendet. Der Sender kann, bezogen auf ein konkretes Dokument, zusätzliche Adressierungsinformationen angeben. Diese dienen dazu, eine Adressierung von organisatorischen Bereichen innerhalb einer adressierten Organisation zu ermöglichen. Zu dem Format dieser Informationen werden keine Vorgaben gemacht. Eine maschinelle Auswertung durch das Primärsystem des Empfängers wird nicht gefordert, kann aber durch bilaterale Absprachen zwischen Sender und Empfänger erreicht werden. Als letzter Schritt werden das Dokument, eventuelle Metadaten und das Verschlüsselungszertifikat dem Konnektor, unter Nutzung der Mehrwertfachdienstoperation CallMWD übergeben. Hierbei kann die maximale Aufbewahrungszeit des Dokumentes auf dem MWKLE angegeben werden. Die Aufbewahrungszeit beträgt maximal 90 Tage, dieser Wert wird angenommen wenn keine Angaben erfolgen. Der TUC TUC_MWD4_01_Mehrwertfachdienst-Operation_aufrufen nutzt den TUC_KON_095 Mehrwertdienst Typ 4 aufrufen des Konnektors, zum Verschlüsseln und Versenden des Dokumentes. Der Konnektor bildet beim Verschlüsseln für jedes Dokument eine ObjectID die sowohl im Objekt-Ticket als auch an dem verschlüsselten Dokument eingetragen wird. Das verschlüsselte Dokument und das Objektticket werden dann an den MWD übermittelt. Näheres dazu ist in [gemspec_kon] beschrieben. Auf dem Mehrwertfachdienst MUSS vor dem Schreiben des Dokuments geprüft werden, ob ein Dokument mit dieser ObjectID schon vorliegt. [A_04012] Der Mehrwertfachdienst MUSS sicherstellen, dass zu einer ObjectID nur genau ein Dokument abgelegt wird. [A_04013] Wenn ein Dokument mit dieser ObjectID vorliegt, wird das Speichern nicht durchgeführt. Das Dokument MUSS auf dem Mehrwertfachdienst persistent abgelegt werden. [A_04014] Soll ein Dokument an mehrere LE gesandt werden, so muss die Operation CallMWD für jeden Empfänger aufgerufen werden. Gegebenenfalls muss vorher der TUC_MWKLE_05_Empfaenger_suchen mehrfach aufgerufen werden, um die verschiedenen Verschlüsselungszertifikate in das PS zu übertragen Dokument signieren Zum Signieren eines XML-Dokumentes wird die facharchitekturübergreifende Funktion TUC_KON_060_Dokument signieren des Signaturdienstes des Konnektors genutzt (siehe [gemspec_kon]). Die verwendetet Signaturpolicy für Primärsysteme ist in [gemspec_kon] Anhang A2 definiert und erläutert. Durch TUC_KON_060_Dokument signieren wird das XML-Dokument signiert und danach an das Primärsystem (PS) zurückgegeben, welches das signierte Dokument bis zur Übergabe an den MWD verwalten muss. Das Datum und die Uhrzeit der Signatur sind in der Signatur enthalten. gematik_mwa_facharchitektur_mwkle.doc Seite 21 von 100

22 Die Anzeige des zu signierenden Dokuments in einem Trusted Viewer MUSS den Anforderungen an die zu erstellende Signatur folgen. [A_04015] TUC_MWKLE_05_Empfaenger_suchen Der TUC dient dem Suchen des zu dem Leistungserbringer gehörigen Verschlüsselungs- (ENC-)Zertifikates. Das Suchen eines LE in der Liste der im Mehrwertfachdienst vorgehaltenen Informationen zu den an der Mehrwertanwendung teilnehmenden LE wird durch den MWD unterstützt. Durch die Eingabe von Suchparametern kann die Liste der ermittelten LE eingeschränkt werden. Wurde der LE in der Liste gefunden, dann kann der Ergebnisliste die Ordnungsnummer des Zertifikates des LE entnommen werden. Die Ordnungsnummer stellt einen Schlüssel dar, unter dem der MWKLE das Zertifikat eindeutig ermitteln kann. In einem folgenden Schritt wird unter Angabe der Ordnungsnummer das ENC-Zertifikat des LE vom Mehrwertfachdienst auf das Primärsystem geladen. Dieser TUC beschreibt den Aufruf der Mehrwertfachdienstoperationen Search und GetCertificate. Das PS ruft am Konnektor die Mehrwertdienstschnittstelle CallMWD auf. Die Parametrisierung ist in Abschnitt 5.4 für die Fachdaten und im Anhang B für die Identitäten und den Transport in der Telematikinfrastruktur beschrieben. sd TUC_MWKLE_05_Empfaenger_suchen :Primärsystem Mehrwert Komponente :Anwendungskonnektor Mehrwert Dienst :Fachdienst MWKLE loop LE suchen [TelematikID des LE nicht bekannt] EingabeSuchparameter() CallMWD() Search(Suchparameter) ref TUC_MWD4_01_Mehrwertfachdienst-Operation_aufrufen ref :Liste: Metadaten + Ordnungsnummer TUC_MWKLE_052_Empfaenger_suchen Auswahl LE TelematikID aus Liste() CallMWD() ref TUC_MWD4_01_Mehrwertfachdienst-Operation_aufrufen GetCertificate(Ordnungsnummer) :Certificate ref TUC_MWKLE_051_Zertifikat_holen Abbildung 2: TUC_MWKLE_05_Empfaenger_suchen Für das Suchen des Leistungserbringers kann die Ergebnismenge durch die Angabe folgender Suchparameter eingeschränkt werden: 1. Name entweder: gematik_mwa_facharchitektur_mwkle.doc Seite 22 von 100

23 a. Nachname der Person b. Name der Institution 2. Vorname (nur bei der Suche nach einer Person) 3. Ort 4. Postleitzahl 5. Straße und optional Hausnummer Für die Suche können Wildcards angegeben werden: * steht für beliebig viele Zeichen. Leere Suchparameter werden bei der Suche ignoriert. sd TUC_MWKLE_052_Empfaenger_suchen MWKLE Leistungserbringer Datenbank Search(Suchparameter) Finde LE(Suchparameter) :Liste: Metadaten + TelematikID :Liste: Metadaten + Ordnungsnummer Abbildung 3: TUC_MWKLE_052_Empfaenger_suchen Unter Angabe der Ordnungsnummer des LE kann dessen ENC-Zertifikat vom Mehrwertfachdienst in das Primärsystem geladen werden. gematik_mwa_facharchitektur_mwkle.doc Seite 23 von 100

24 sd TUC_MWKLE_051_Zertifikat_holen MWKLE Leistungserbringer Datenbank GetCertificate(TelematikID) HoleZertifkat(Ordnungsnummer) :Zertifikat :Certificate Abbildung 4: TUC_MWKLE_051_Zertifikat_holen Tabelle 4: TUC_MWKLE_05_Empfaenger_suchen Kurzbeschreibung Initiierender Technischer Akteur Weitere Technische Akteure Auslöser Vorbedingungen Nachbedingungen Empfänger suchen Primärsysteme (Praxisverwaltungs- und Krankenhausinformationssysteme) der LE Konnektor, SMC-B oder HBA, Broker, Mehrwertfachdienst Ein LE möchte ein Dokument an einen LE versenden. Dazu benötigt er das ENC-Zertifikat des anderen LE. Alle Komponenten sind betriebsbereit und in fehlerfreiem Zustand. Die HBA bzw. SMC-B sind gesteckt und auf ihre technische Funktionsfähigkeit geprüft. ENC Zertifikat des Empfängers liegt im PS vor. Loop TUC_MWD4_01_ Mehrwertfachdienst- Operation_aufrufen CallMWD: Search Die den LE (Empfänger) näher bezeichnenden Parameter werden durch den LE (Sender) am PS eingegeben Die Suchparameter werden dem MWD übermittelt Parameter: P1: Suchparameter P*: Parametrisierung der CallMWD Schnittstelle Ergebnis: E1: Liste von LE mit Metadaten und TelematikID/OrganisationsID TUC_MWKLE_052_ Empfaenger_suchen Fehlerbehandlung: Fehler: Jeder CallMWD spezifische Fehlerbehandlung und Fehlermeldung, siehe [gemspec_kon]. Fachoperation auf dem MWD. Suchen der LE anhand der Suchparameter- P1: Suchparameter Rückmeldung: gematik_mwa_facharchitektur_mwkle.doc Seite 24 von 100

25 E1: Liste von LE mit Metadaten und Ordnungsnummer oder Fehlermeldung Fehlerbehandlung: Fehler: Ergebnismenge zu groß, Suche bitte einschränken. Fehlercode: 2012 Aktion: Kein Abbruch Auswertung der Ergebnisliste im PS durch den LE. Ist der Empfänger in der Liste enthalten; Abbruch des Loops. Ende Loop (Empfänger in Liste enthalten) Auswahl LE TUC_MWD4_01_ Mehrwertfachdienst- Operation_aufrufen CallMWD: GetCertificate Der Empfänger wird aus der Liste ausgewählt. Die Ordnungsnummer wird in das PS übernommen Die Ordnungsnummer des Zertifikates des Empfängers wird dem MWD übermittelt. Der MWD liefert das zu der Ordnungsnummer abgelegte ENC Zertifikat. Parameter: P1: Ordnungsnummer P*: Parametrisierung der CallMWD Schnittstelle Ergebnis: ENC Zertifikat des Empfängers. TUC_MWKLE_051 _Zertifikat_holen Fehlerbehandlung: Fehler: Jeder CallMWD spezifische Fehlerbehandlung und Fehlermeldung, siehe [gemspec_kon]. Übergabe des Verschlüsselungszertifikates, das zu der Ordnungsnummer gehört, an den Aufrufer. Fehlerbehandlung: Fehler: Leistungserbringer nicht bekannt. Fehlercode:2020: Aktion: Abbruch Verzeichnis der LE Für die prototypische Umsetzung der Mehrwertkommunikation zwischen LE am Beispiel des VHitG-Arztbriefes wird die Liste der teilnehmenden LE durch den MWD vorgehalten. Es werden keine Vorgaben gemacht, wie die Liste auf dem MWD technisch vorgehalten oder umgesetzt wird. Eine Umsetzung als standardisierter Verzeichnisdienst wie LDAP s ist nicht erforderlich. Es MUSS möglich sein, eine Liste der LE oder Teile der Liste vom MWD abzurufen. [A_04018] Es MUSS möglich sein, die Liste durch die Übergabe von Suchparametern einzuschränken [A_04019]. Die Liste der LE wird ausschließlich zu dem Zweck vorgehalten, zu einem vorher bekannten LE das Verschlüsselungszertifikat zu ermitteln. Zu jedem Verschlüsselungszertifikat muss eine Ordnungsnummer existieren, unter der das Zertifikat im Zuge der Zertifikatssuche abfragbar ist. Diese Ordnungsnummer ist ein beliebiger, durch den Verzeichnisanbieter frei wählbarer, String der einem Primärschlüssel entspricht. gematik_mwa_facharchitektur_mwkle.doc Seite 25 von 100

26 Der MWD kann in späteren Versionen auf bestehende Verzeichnisdienste auch in der Telematikinfrastruktur zugreifen, um von dort die gesuchten Informationen zu erhalten. Ebenfalls kann das PS des LE in späteren Versionen auf bestehende Verzeichnisdienste in der Telematikinfrastruktur zugreifen, um von dort die gesuchten Informationen zu erhalten. Die Verschlüsselungszertifikate, die der MWD vorhält, MÜSSEN dieselben sein, die auf den jeweiligen HBA oder SMC-B der LE als ENC-Zertifikate aufgebracht sind. [A_04020] Über Informationen aus diesen Zertifikaten werden die verschlüsselten Dokumente auf dem MWD über die Objekttickets den jeweiligen LE zugeordnet TUC_MWKLE_04_Dokument_schreiben Dieser TUC beschreibt den Aufruf der Mehrwertfachdienstoperation WriteDocument. Das PS ruft am Konnektor die Mehrwertfachdienstschnittstelle CallMWD auf. Die Parametrisierung ist in Kapitel 5.1 für die Fachdaten und im Anhang B für die Identitäten und den Transport in der Telematikinfrastruktur beschrieben. sd TUC_MWKLE_04_Dokument_schreiben :Primärsystem Mehrwert Komponente :Anwendungskonnektor Mehrwertdienst :Fachdienst MWKLE CallMWD() WriteDocument(Document [1-n]) ref ref TUC_MWD4_01_Mehrwertfachdienst-Operation_aufrufen TUC_MWKLE_041_Dokument_schreiben Abbildung 5: TUC_MWKLE_04_Dokument_schreiben Dem MWD wird eine Liste mit 1-n verschlüsselten Dokumenten, eine optionale Liste mit erweiterten Adressierungsinformationen und eine Liste der Objekttickets übergeben. In dem Objektticket ist unter anderem der Empfänger des Dokumentes als Eigentümer des Dokumentes vermerkt. Über das Objektticket ist es dem lesenden LE später möglich, die für ihn auf dem MWD hinterlegten Dokumente zu identifizieren. Ein verschlüsseltes Dokument wird auf dem MWD unter der gelieferten ObjectID in einer Dokumenten Datenbank abgelegt. Hierbei werden zusätzlich zu dem Dokument die Metadaten zu dem Dokument vermerkt. Die Metadaten bestehen aus dem Einstelldatum, dem Objekttype und den optionalen erweiterten Adressierungsinformationen. Über die Adressierungsinformationen ist es möglich, weitere Angaben zu dem Empfänger innerhalb einer Organisation zu definieren. Die Auswertung dieser Informationen erfolgt durch den Empfänger. Zu jedem Dokument muss dem Objektticket die Lebensdauer entnommen und in den Metadaten vermerkt werden. Es muss sichergestellt werden, dass unter ObjectID nur ein Dokument abgelegt wird. gematik_mwa_facharchitektur_mwkle.doc Seite 26 von 100

27 sd TUC_MWKLE_041_Dokument_schreiben MWKLE Dokument Datenbank WriteDocument(Liste[OBID, Dokument, Ticket, Metadaten]) loop Schreibe alle Dokumente [für jedes Dokument] Prüfe_ob_ObjectID_vorhanden(OBID) opt Neues Dokument [OBID nicht vorhanden] Schreibe Document(Dokument, Einstelldatum, Type, Adressinformation) ref TUC_TKS_05_SchreibeObjektTicket(Ticket) Abbildung 6: TUC_MWKLE_041_Dokument_schreiben Zu dem Dokument wird ein entsprechendes, durch die Ticketkomponente des Konnektors erzeugtes, Objektticket angelegt. Die Ablage und die Behandlung dieses Objekttickets sind in [gemspec_ticket] definiert. Die identitätsbezogene Autorisierung [gemgesarch] der Datenautorität findet an dieser Stelle explizit nicht statt. Da jeder LE grundsätzlich berechtigt ist, Dokumente auf dem MWKLE abzulegen, reicht die rollenbasierte Autorisierung aus. Die Anzahl der in einem Aufruf zu versendenden Dokumente ist technisch durch eine Maximalgrößendefinition für die TTD Nachricht beschränkt. Tabelle 5 TUC_MWKLE_04_Dokument_schreiben Kurzbeschreibung Initiierender Technischer Akteur Weitere Technische Akteure Auslöser Vorbedingungen Nachbedingungen XML Dokument schreiben Ein adressiert ein LE das XML Dokument an einen LE und versendet diesen über das Primärsystem Primärsysteme (Praxisverwaltungs- und Krankenhausinformationssysteme) der LE Konnektor, SMC-B oder HBA, Broker, Mehrwertdienst LE möchte signiertes Dokument versenden. Alle Komponenten sind betriebsbereit und in fehlerfreiem Zustand. Die HBA bzw. SMC-B sind gesteckt und auf ihre technische Funktionsfähigkeit geprüft. Das XML Dokument liegt im Primärsystem vor. Das Verschlüsselungszertifikat des Empfänger LE liegt im PS vor. Das XML Dokument ist verschlüsselt auf dem Mehrwertdienst gespeichert. gematik_mwa_facharchitektur_mwkle.doc Seite 27 von 100

28 Primärsystem TUC_MWD4_01_Me hrwertfachdienst- Operation_aufrufen CallMWD: WriteDocument Aufruf vom Primärsystem an den Konnektor. Der Konnektor erstellt eine nach [gemspec_ttd] konforme Telematiknachricht und sendet diese an den MWD. Als Ergebnis wird eine Rückmeldung über erfolgreiches Schreiben in den Fachdienst erwartet. Parameter: P1: signiertes XML Dokument(e). P*: Parametrisierung der CallMWD Schnittstelle Ergebnis: E1: ObjectID(s) Der Konnektor schickt an das PVS eine Rückmeldung darüber, dass das Schreiben erfolgreich war oder eine Fehlermeldung. TUC_MWKLE_041_ Dokument_schreiben Fehlerbehandlung: Fehler: Jeder CallMWD spezifische Fehlerbehandlung und Fehlermeldung, siehe [gemspec_kon]. Fachoperation auf dem MWD. Die verschlüsselten XML- Dokument(e) werden unter den übergebenen ObjectID auf dem MWD abgelegt. P1: signiertes und verschlüsseltes Dokument Rückmeldung: Der MWD schickt eine Rückmeldung über das erfolgreiche Speichern der Arztbriefe an den Konnektor. Fehlerbehandlung: Fehler: Dokument kann nicht geschrieben werden. Fehlercode: 2010 Aktion: Kein Abbruch, Abarbeiten der verbleibenden Dokumente. Fehler: Dokument mit ObjectID bereits vorhanden. Fehlercode: 2011 Aktion: Kein Abbruch, Abarbeiten der verbleibenden Dokumente. 4.4 Dokument vom MWD abrufen Das in [gemfk_mwk_le] beschriebene Aktivitätsdiagramm Dokument(e) abrufen beschreibt das Abrufen von Dokumenten von dem MWKLE. Der unter beschriebene Ablauf Ablauf_MWKLE_Dokument_lesen stellt die Umsetzung in der Facharchitektur dar. Im Folgenden ist die Zuordnung der Aktivitäten aus dem Fachkonzept zu den TUC in der Facharchitektur tabellarisch dargestellt. Tabelle 6: Zuordnung Fachkonzept zu Facharchitektur (Abrufen) Aktivität im Fachkonzept Dokumente vom Mehrwertdienst in das Primärsystem verschieben TUC in der Facharchitektur TUC_MWKLE_02_DokumentVerweise_lesen TUC_MWKLE_01_Dokument_lesen TUC_MWKLE_03_Dokument_löschen TUC_MWKLE_09_AbgelaufeneDokumente_löschen gematik_mwa_facharchitektur_mwkle.doc Seite 28 von 100

29 4.4.1 Ablauf_MWKLE_Dokument_lesen Dieses Kapitel beschreibt den Ablauf zum Lesen der XML-Dokumente auf dem Mehrwertfachdienst. Das Abrufen der Dokumente wird durch den abrufenden LE oder sein PS angestoßen. Das PS kann zyklisch nach bereitgestellten Dokumenten auf dem MWD suchen. Es obliegt den jeweiligen LE, jeweils für alle seine genutzten Identitäten auf dem MWD Dokumente abzufragen. Dies ist vor allem in Zusammenhang mit der Konstellation von Interesse, dass ein LE sowohl unter seiner Identität als Person in einer entsprechenden Rolle (z. B. als Arzt), als auch unter der Identität seiner Institution (zum Beispiel der Praxis oder dem Krankenhaus) Empfänger eines Dokumentes sein kann. Das Lesen erfolgt in zwei Stufen. In einem ersten Schritt werden die ObjectIDs aller für den Empfänger vorliegenden Dokumente ermittelt. Zu jeder ObjectID werden das Einstellungsdatum des Dokuments auf dem MWD sowie eine Markierung, ob das Dokument schon einmal gelesen wurde, mitgeliefert. Die Anzahl der in einem Aufruf lieferbaren ObjektIDs ist technisch durch eine Maximalgrößendefinition für die TTD Nachricht beschränkt. Die Mehrwertfachdienstoperation wurde so gestaltet, dass auch Teilmengen abgefragt werden können. Siehe dazu 5.3. Es MUSS durch das PS sicherstellt werden, dass im arithmetischen Mittel nicht öfter als alle 10 Minuten ein Abrufen der ObjectIDs der für den LE verfügbaren Dokumente erfolgt. [A_04021] In einem zweiten Schritt können für eine oder mehrere dieser ObjectIDs die eigentlichen Dokumente abgerufen werden. Jedes Dokument wird auf dem Konnektor automatisch entschlüsselt. Hierzu wird zu dem verschlüsselten Dokument auch der Hybridschlüssel des Dokumentes auf den Konnektor geladen und dort zum Entschlüsseln genutzt. Der Hybridschlüssel wird nicht an das PS übergeben. Der MWD MUSS sicherstellen, dass durch das Zurückliefern mehrerer Dokumente die Größe der Telematiknachricht nicht die in [gemspec_ttd] definierte Maximalgröße überschreitet. [A_04022] Es dürfen nur so viele Dokumente in einer Nachricht geliefert werden, dass diese Bedingung nicht verletzt wird. Dem Primärsystem wird zu jedem gelieferten XML-Dokument die ObjectID mitgeliefert, so dass das PS erkennen kann, ob alle Dokumente geliefert wurden. Zu den ObjectIDs, zu denen entweder kein Dokument gefunden wurde oder aber die nicht geliefert wurden, weil die Maximalgröße der Telematiknachricht überschritten worden wäre, wird jeweils eine entsprechende technische Fehlermeldung generiert. gematik_mwa_facharchitektur_mwkle.doc Seite 29 von 100

30 sd Ablauf_MWKLE_Dokument_lesen LE :Primärsystem Mehrwert Komponente :Anwendungskonnektor Mehrwert Dienst :Fachdienst ref TUC_MWKLE_02_DokumentVerweise_lesen:Liste: OBID opt XML Dokumente vorhanden [Anzahl OBID mindestens 1] ref TUC_MWKLE_01_Dokument_lesen(Liste: OBID) ref TUC_MWKLE_03_Dokument_löschen(Liste: OBID) loop Periodischer Ablauf [Startzeitpunkt erreicht] ref TUC_MWKLE_09_AbgelaufeneDokumente_löschen Abbildung 7: Ablauf_MWKLE_Dokument_lesen Auf dem MWD MUSS für jedes Dokument (MDO) vermerkt werden, ob es schon einmal abgerufen wurde. [A_04023] Ein gelesenes Dokument wird durch den Abruf nicht automatisch gelöscht. Um das Dokument nachfolgend von MWD zu entfernen, muss vom PS der TUC_MWKLE_03_LöscheDokument angestoßen werden. Nach dem erfolgreichen Einlesen von Dokumenten vom MWD in das PS MÜSSEN diese Dokumente auf dem MWD gelöscht werden. [A_04222] Schlägt das Löschen fehl, so kann anhand der Markierung sowohl vom PS als auch vom MWD erkannt werden, dass das betroffene Dokument schon einmal abgerufen wurde. Dies dient einem PS als Hilfestellung um zu erkennen, welche Dokumente gelöscht werden müssen. gematik_mwa_facharchitektur_mwkle.doc Seite 30 von 100

31 4.4.2 TUC_MWKLE_02_DokumentVerweise_lesen Dieser TUC beschreibt den Aufruf der Mehrwertfachdienstoperation ReadDocumentPointer. Das PS ruft am Konnektor die Mehrwertdienstschnittstelle CallMWD auf. Die Parametrisierung ist in Kapitel 5.3 für die Fachdaten und im Anhang B für die Identitäten und den Transport in der Telematikinfrastruktur beschrieben. sd TUC_MWKLE_02_DokumentVerweise_lesen :Primärsystem Mehrwert Komponente :Anwendungskonnektor Mehrwert Dienst :Fachdienst MWKLE CallMWD() ReadDocumentPointer() ref ref TUC_MWD4_01_Mehrwertfachdienst-Operation_aufrufen TUC_MWKLE_021_DokumentVerweise_lesen :Liste: OBID + Metadaten :Liste: OBID + Metadaten Abbildung 8: TUC_MWKLE_02_DokumentVerweise_lesen Für alle auf dem MWD für den LE vorliegenden Dokumente wird durch das Ermitteln der durch den LE zugreifbaren Objekte die jeweilige ObjectID ermittelt. Zusätzlich werden die Metadaten zu den gespeicherten Dokumenten ermittelt. Metadaten sind das Einstelldatum, der Typ des Dokumentes und die zusätzlichen Adressierungsinformationen. Das Einstellungsdatum ist der Zeitpunkt zu dem das Dokument dem MWD übergeben wurde. Zu TUC_TKS_03_FindeZugreifbareObjekte sei auf [gemspec_ticket] verwiesen. gematik_mwa_facharchitektur_mwkle.doc Seite 31 von 100