Projekt ebusiness Plattform Gesundheitswesen. Ergebnispapier/Kompendium des Arbeitspaktes 4

Transkript

1 Projekt ebusiness Plattform Gesundheitswesen Ergebnispapier/Kompendium des Arbeitspaktes 4 Anforderungen und Interoperabilität von und zu einrichtungsübergreifenden Aktensystemen Diese Ausarbeitung entstand ihm Rahmen des von der Europäischen Union und dem Land Nordrhein-Westfalen geförderten Projektes ebusiness Plattform Gesundheitswesen und hier innerhalb des Arbeitspaketes 04 Anforderungen und Interoperabilität von und zu einrichtungsübergreifenden Aktensystemen. Vorabversion zur conhit 2014

2 Beteiligte Projektpartner: Leitung des Arbeitspaketes: Michael Meilutat, Siemens AG Unter Mitarbeit von: Gerhard Abel Wilfried Arends Dr. Jacqueline Fedy Daniel Hellmuth Salima Houta Stephan Janz Christian Kohler Robert Mützner Dr. Frank Oemig Wilhelm Penkaitis Roland Riepel Christian Suelmann Dr. Florian Wozak Siemens AG Fachhochschule Dortmund Agfa Healthcare GmbH brightone GmbH Fraunhofer-Institut für Software und Systemtechnik ISST CSC Deutschland Solutions GmbH Siemens AG Fachhochschule Dortmund Agfa Healthcare GmbH Agfa Healthcare GmbH Fraunhofer-Institut für Software und Systemtechnik ZTG Zentrum für Telematik und Telemedizin GmbH Siemens AG

3 Inhaltsverzeichnis INHALTSVERZEICHNIS Inhaltsverzeichnis... I Abbildungsverzeichnis... VII Tabellenverzeichnis... VIII Verzeichnis der Aufzählungen... X 1 Vorwort Konzepte einrichtungsübergreifender Aktensysteme Die Einrichtungsübergreifende Medizinische Fallakte (EFA) Die persönliche Elektronische Patientenakte (pepa) Die einrichtungsübergreifende Elektronische Patientenakte (eepa) Die Elektronische Patientenakte gemäß 291a SGB V ( 291a Akte ) Merkmale einrichtungsübergreifender Elektronischer Patientenakten Health Professional geführte Akte mit Patienten- und Notfallbereich Differenzierte Zugriffsrechte Fallübergreifende und ggf. lebenslange Aktenführung Integration in Primärsysteme und Nutzung von Standards Dokumentenbasierte Akte mit Zugriff auf feingranulare Informationen Funktionsfähigkeit mit Offline-Ticket bzw. ohne Offline-Ticket Benutzeroberfläche einer eepa Fähigkeit zur Einbindung in die Telematik-Infrastruktur Spezifikation bzgl. Betrieb und (Langzeit-) Archivierung einer eepa Aspekte der Standardisierung Organisationen IHE Deutschland HL7 Deutschland Zusammenarbeit IHE/HL Standards CDA Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014 Seite I

4 4.2.2 DICOM Implementierungsleitfäden Abstimmungsverfahren (Ballotierung) Formen der intersektoralen Kommunikation Adressierte Kommunikation Ungerichtete Kommunikation Gerichtete Kommunikation Rahmenbedingungen Grundlegende Festlegungen Akteure und Rollen Rollen und Rechte auf Aktenebene Rollen und Rechte auf Ordnerebene Rollen und Rechte auf Dokumentenebene Weiterführende Aspekte Einheitliches Fundament für Aktensysteme Affinity Domain übergreifender Dokumentenzugriff (XCA) Vertragswerke Patienteneinwilligung Providervertrag Fallbeispiel und Use Cases Referenzprozess / Fallbeispiel Use Cases UC Akte anlegen UC Aktenmoderator bestimmen UC Akten-Attribute lesen UC Akten-Attribute ändern UC Akte sperren UC Akte entsperren UC Akte löschen UC Zugriffsberechtigung erteilen UC Zugriffsberechtigung entziehen UC Ordner erstellen UC Ordner löschen UC Ordnerliste abrufen UC Ordner-Attribute ändern Seite II Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

5 Inhaltsverzeichnis UC Dokument-Ordner-Zuordnung erstellen UC Dokument-Ordner-Zuordnung entfernen UC Dokument einstellen UC Dokumentenliste abrufen UC Dokumente abrufen UC Dokumentenhistorie abrufen UC Dokument aktualisieren UC Dokument sperren UC Dokument entsperren UC Dokument löschen UC Notfalldaten abrufen Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Problemstellung Anwendungsbeispiel koronares Problem Grundsätzliche problemorientierte Ansätze Problemlösungsvorschlag fachlich Analyse der Gesamtstory Kolonkarzinom und Ableitung der fünf häufigsten Abfragen Sonderfall Notfalldaten versus Patient Summary Fortgeschriebene versus generierte Patient Summary Lösungsvorschlag technisch Umsetzung direkt mit CDA Dokumenten Adaptation von Healthcare Events Einschränkungen bei verschlüsselten Daten und Meta-Daten Sonstige spezifische Mehrwertanwendungen Transition Informationsobjekte aus der Mehrwertanwendung heraus Anforderungen an Fachdienste Zentrale Tumordokumentation in der eepa und Meldung an das Krebsregister Informationsobjekte aus der Mehrwertanwendung heraus Anforderungen an Fachdienste Integration von Informationsobjekten aus der eepa in klinische Behandlungspfade Informationsobjekte aus der Mehrwertanwendung heraus Anforderungen an Fachdienste Seite III Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

6 9 Technische Spezifikationen Verwendung von IHE Profilen Technische Use Cases Patient identifizieren (PIX) Patient identifizieren (PDQ) Akte anlegen Demografische Daten halbautomatisch aktualisieren Akte löschen Dokument einstellen Dokumentenliste abrufen Dokumente abrufen Dokument aktualisieren Dokument löschen Dokumentenliste aus entfernter Domain abrufen Dokument aus entfernter Domain abrufen Betriebs- und Langzeitarchivierung Migration in die Telematikinfrastruktur Telematikinfrastruktur (TI) Gesetzliche Anwendungen Mehrwertanwendungen Gesundheitsdatendienste (GDD) Migration der EFA Basis zur Migration weiterer GDD Phase 1 Nutzung der Funktionalitäten der Telematikinfrastruktur Phase 2 Nutzbarmachung der EFA-Sicherheitsarchitektur Anforderungen an Zulassung und Betrieb Bedeutung für die eepa Informationsobjekte Statische Dokumente Dynamische Dokumente Dokumententaxonomie Haupttypen Klassifikationsachsen Inhalte Überblick über nationale und internationale Aktivitäten Seite IV Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

7 Inhaltsverzeichnis HL7 Deutschland ELGA Österreich - Harmonisierungsarbeit für medizinische Dokumente ehealth Suisse/ HL7 Schweiz/ ech-standards DMP Frankreich ehealth Dänemark esanté Luxembourg ehealth Finnland Stylesheets für CDA-Dokumente und deren Ablage PDF/A in Zusammenspiel mit CDA PDF-Varianten Hybrid-Dokumente als Kombination von PDF(/A-3) und CDA Validierung der CDA Dokumente Syntax Validierung Schema Validierung Schematron Validierung Schematron Validatoren Codesysteme Allgemeine CDA Header Daten Arztbrief Entlassungsdokument pflegerisch Radiologie Befund (Kopplung mit entspr. Bild) Notfall Datensatz Patient Summary Medikationsplan Überweisung Pathologiebefund Transitionsbrief Übermittlung meldepflichtiger Krankheiten earztmeldung-ifsg XDS Metadaten Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa AP01 Datenschutz- und Sicherheitsmechanismen Abgleich AP01 - AP AP02 Terminologie- und Ontologieserver AP03 Data-Dictionary Server AP07 Leistungsangebots- und Terminbuchungsplattform Seite V Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

8 A. Anhang A.1. PDF-Varianten A.1.1. PDF/A A.1.2. PDF/A-Versionen im Vergleich A.2. Dokumententaxonomie A.3. Betriebs- und Langzeitarchivierung A.3.1. Ordnungsmäßigkeit der Archivierung A.3.2. Revisionssicherheit A.3.3. Braunschweiger Regeln zur Archivierung mit elektronischen Signaturen im Gesundheitswesen A.3.4. Notwendigkeit von digitalen Archivsystemen A.3.5. Quellen A.4. CDA-XDS-Mapping A.5. Feldbeschreibung für elektronischen Überweisungsschein A.5.1. Muster 2b A.5.2. Muster A.5.3. Muster A.5.4. Detaillierte Feldbeschreibungen A.6. Patienteneinwilligung am Beispiel der EFA A.7. Veröffentlichung in der EHEALTHCOM NATIONAL (UN)VERNETZT - Handlungsempfehlungen zur Etablierung einrichtungsübergreifender Elektronischer Patientenakten in Deutschland A.8. Abkürzungsverzeichnis und Glossar Seite VI Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

9 Inhaltsverzeichnis ABBILDUNGSVERZEICHNIS Abbildung 01: Schematischer Aufbau eines CDA-Dokuments Abbildung 02: CDA-Beispieldokument Abbildung 03: Integrationsstufen für CDA Abbildung 04: Klinischer Überblick koronares Problem Abbildung 05: Filterung koronares Problem aktueller Patientenstatus Abbildung 06: Semantische Beziehung im Beispiel koronares Problem Abbildung 07: ATC-Beispiele (aus 78 Abbildung 08: CDA Ausschnitt aus ELGA Definition Abbildung 09. ELGA Beispiel Abbildung 10. ELGA Beispiel Abbildung 11. Modellausschnitt Primary Record Content aus EPA Abbildung 12. Schema des Dokumentenuploads mit Parsen zur Abbildung auf semantisches Zielsystem Abbildung 13: Ablaufdiagramm Patient anhand der Patienten-ID identifizieren Abbildung 14: Ablaufdiagramm Patient anhand der demografischen Daten identifizieren Abbildung 15: Ablaufdiagramm Akte anlegen Abbildung 16: Ablaufdiagramm Dokument einstellen Abbildung 17: Ablaufdiagramm Dokumentenliste abrufen Abbildung 18: Ablaufdiagramm Dokument abrufen Abbildung 19: Ablaufdiagramm Dokument löschen Abbildung 20: Ablaufdiagramm Dokumentenliste aus einer entfernten Domäne abrufen Abbildung 21: Ablaufdiagramm Dokument aus einer entfernten Domäne abrufen Abbildung 22: Zuordnungsmöglichkeiten eines Stylesheets zu einem CDA-Dokument Abbildung 23: Speicherung der Stylesheets auf Webserver Abbildung 24: Einbettung strukturierter Informationen als CDA-Dokument in PDF/A3 (Nutzung von PDF zur Signatur) Abbildung 25: Einbettung eines beliebigen PDF-Dokumentes in CDA (Nutzung des Headers) Abbildung 26: Einbettung eines beliebigen PDF-Dokumentes in CDA (XML) Abbildung 27: Überweisungsschein Muster 2b Abbildung 28: Überweisungsschein Muster Abbildung 29: Überweisungsschein Muster Seite VII Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

10 TABELLENVERZEICHNIS Tabelle 01: CDA-Templates Tabelle 02: Beispiel für eine Template-Hierarchie Tabelle 03: Rollen und Rechte auf Aktenebene Tabelle 04: Rollen und Rechte auf Ordnerebene Tabelle 05: Rollen und Rechte auf Dokumentenebene Tabelle 06: UC Akte anlegen Tabelle 07: UC Aktenmoderator bestimmen Tabelle 08: UC Akten-Attribute lesen Tabelle 09: UC Akten-Attribute ändern Tabelle 10: UC Akte sperren Tabelle 11: UC Akte entsperren Tabelle 12: UC Akte löschen Tabelle 13: UC Zugriffsberechtigung erteilen Tabelle 14: UC Zugriffsberechtigung entziehen Tabelle 15: UC Ordner erstellen Tabelle 16: UC Ordner löschen Tabelle 17: UC Ordnerliste abrufen Tabelle 18: UC Ordnerattribute ändern Tabelle 19: UC Dokument Ordner zuordnen Tabelle 20: UC Dokumentzuordnung zu Ordner löschen Tabelle 21: UC Dokument einstellen Tabelle 22: UC Dokumentenliste abrufen Tabelle 23: UC Dokument abrufen Tabelle 24: UC Dokumentenhistorie abrufen Tabelle 25: UC Dokument aktualisieren Tabelle 26: UC Dokument sperren Tabelle 27: UC Dokument entsperren Tabelle 28: UC Dokument löschen Tabelle 29: UC Notfalldaten abrufen Tabelle 30: Analyse der fachlichen Abfragen der eepa aus der Gesamtstory heraus Tabelle 31: Generierte vs. fortgeschriebene Patient Summary Tabelle 32: Section und Entries for bestimmte Dokumentationen Tabelle 33: Benötigte Informationstypen für die Transition Tabelle 34: Verwendete IHE Profile Seite VIII Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

11 Inhaltsverzeichnis Tabelle 35: Übersicht über die technischen Use Cases Tabelle 36: Nutzung der HL7 v2 ADT Nachrichten für die Aktenanlage Tabelle 37: Pflichtfelder des Message Header (MSH) Tabelle 38: Pflichtfelder des Segments Event Type Tabelle 39: Pflichtfelder des Segments Patient Identification Tabelle 40: Pflichtfelder des Segments Patient Visit Tabelle 41: Codebeispiel ADT^A01(ITI-8) Tabelle 42: Suchparameter der Transaktion ITI Tabelle 43: Mögliche Klassifikationsachsen für Dokumenttypen Tabelle 44: Abschnitte für verschiedene Dokumenttypen (Beispiel) Tabelle 45: Stylesheet Aufruf Tabelle 46: Verbreitete Kodiersysteme Tabelle 47: Raster für Darstellung der Dokumenten-Steckbriefe Tabelle 48: Steckbrief Arztbrief Tabelle 49: Steckbrief Entlassungsbericht pflegerisch Tabelle 50: Steckbrief Radiologiebefund Tabelle 51: Inhalte eines Radiologiebefundes Tabelle 52: LOINC-Codes für den Radiologiebefund Tabelle 53: Steckbrief Notfalldatensatz Tabelle 54: Steckbrief Patient Summary Tabelle 55: AkdÄ Medikationsplan Tabelle 56: Addendum Medikation Tabelle 57: Steckbrief Überweisung Tabelle 58: Steckbrief Pathologiebefund Tabelle 59: Abschnitte im Pathologiebefund Tabelle 60: Steckbrief Transitionsbrief Tabelle 61: Steckbrief earztmeldung-ifsg Tabelle 62: Dokumententaxonomie (aus dem HL7-Wiki) Tabelle 63: Mapping CDA-XDS Tabelle 64: Feldbeschreibungen zur Bedruckung von Überweisungen Seite IX Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

12 VERZEICHNIS DER AUFZÄHLUNGEN Aufzählungsliste 01: Adressaten des Kompendiums... 1 Aufzählungsliste 02: Beispiele für Nutzen einrichtungsübergreifender Aktensysteme... 2 Aufzählungsliste 03: Filterkriterien für Zugriffsrechte... 7 Aufzählungsliste 04: Grundsätzliche Eigenschaften von CDA-Dokumenten Aufzählungsliste 05: Der Inhalt eines CDA-Headers Aufzählungsliste 06: Die drei Möglichkeiten der Stimmabgabe zu Ballots Aufzählungsliste 07: Annahmevoraussetzungen einer Spezifikation Aufzählungsliste 08: Für die Berechtigung ergänzend wirksame Filterkriterien Aufzählungsliste 09: Akteure der eepa Aufzählungsliste 10: Unterscheidungsmerkmale der verschiedenen Aktenkonzepte Aufzählungsliste 11: Gemeinsame Basis für Interoperabilität Aufzählungsliste 12: Voraussetzungen für den übergreifenden Zugriff auf Informationsobjekte Aufzählungsliste 13: Verschiedene Betreiberkonzepte Aufzählungsliste 14: Finanzierung der Aktensysteme Aufzählungsliste 15: Berechtigungssteuerung Aufzählungsliste 16: Empfehlung zu Providervertragsinhalten Aufzählungsliste 17: Fragestellungen zum Fallbeispiel Aufzählungsliste 18: Wesentliche klinische Abfragen Aufzählungsliste 19: Suchkriterien zur Abfrage existierender Untersuchungen Aufzählungsliste 20: Beispiele für häufig vorkommende Allergie- oder Risiko-Implikationen Aufzählungsliste 21: Funktionale Aspekte einer Problemauflistung Aufzählungsliste 22: Initiativen zur Definition von Notfalldaten Aufzählungsliste 23: Anforderungen der BÄK Aufzählungsliste 24: Daten der Patient Summary Aufzählungsliste 25: Dokumentierte Daten im Basismodul Aufzählungsliste 26: Die drei Level der CDA Aufzählungsliste 27: Maschinenlesbarkeit vs. nur vom Mensch interpretierbar Aufzählungsliste 28: Vor- und Nachteile einer Levelerhöhung eines CDA-Dokmentes Aufzählungsliste 29: ELGA Integrationsstufen Aufzählungsliste 30: Weitere Aspekte des Artikels Aufzählungsliste 31: Hindernisse für direkte Abbildung und Übermittlung von Informationsobjekten. 93 Aufzählungsliste 32: Varianten der Erzeugung von Healthcare Events Aufzählungsliste 33: Herausforderungen zur Erzeugung von Healthcare Events zum Zeitpunkt des Dokumentupdates Seite X Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

13 Inhaltsverzeichnis Aufzählungsliste 34: Einschränkungen der Funktionalität Aufzählungsliste 35: Anwendungsfälle der Tumordokumentation Aufzählungsliste 36: Module einer Tumordokumentation Aufzählungsliste 37: Konfigurierbarkeit Aufzählungsliste 38: Klinisch / funktionale Sicht Aufzählungsliste 39: Anwendungen der egk Aufzählungsliste 40: Charakteristika von Gesundheitsdatendiensten Aufzählungsliste 41: Dienste, die auch anderen Mehrwertanwendungen zur Verfügung stehen Aufzählungsliste 42: Nutzbargemachte Dienste für andere GDD Aufzählungsliste 43: Nachweise zur Zulassung Aufzählungsliste 44: Kriterien für Zulassung zur TI Aufzählungsliste 45: Kategorien von Dokumenttypen Aufzählungsliste 46: Aspekte eines Entlassungsberichts Aufzählungsliste 47: Nationale Aktivitäten Aufzählungsliste 48: Abgeschlossener Harmonisierungsprozess Aufzählungsliste 49: Eckpunkte französische DMP-Leitfäden Aufzählungsliste 50: Funktionen des Portals Aufzählungsliste 51: Mit der EPA-Einführung verbundene Aspekte Aufzählungsliste 52: Funktionalität von KANTA Aufzählungsliste 53: Varianten der Speicherung des Stylesheets Aufzählungsliste 54: Vor-/Nachteile der Speicherung des Stylesheets im gleichen Dateisystem Aufzählungsliste 55: Vor-/Nachteile der Speicherung des Stylesheets im CDA-Dokument Aufzählungsliste 56: Vor-/Nachteile der Speicherung des Stylesheets auf einem Server Aufzählungsliste 57: Schritte zur Erstellung eines PDF/A-3-Dokumentes Aufzählungsliste 58: Schritte zur Erstellung eines signierten PDF/A-Dokumentes Aufzählungsliste 59: Vor- und Nachteile der Nutzung von PDF/A Aufzählungsliste 60: Schritte zur Erstellung eines CDA-Dokumentes mit eingebettetem PDF/A Aufzählungsliste 61: Vor- und Nachteile CDA mit eingebettetem PDF/A Aufzählungsliste 62: Stufen der Validierung von CDA-Dokumenten Aufzählungsliste 63: Struktur eines CDA-Dokumentes Aufzählungsliste 64: Dienste, die auf Basis der Schematron-Regeln die Gültigkeit von CDA- Dokumenten prüfen Aufzählungsliste 65: Aufbau und Inhalt der Header-Daten Aufzählungsliste 66: Im deutschen HL7-Wiki berücksichtigte Dokumententypen Aufzählungsliste 67: Typische Abschnitte eines Arztbriefes Aufzählungsliste 68: Schritte des Pflegeprozesses Aufzählungsliste 69: Medikationsplan Seite XI Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

14 Aufzählungsliste 70: Abschnitte der Meldung über meldepflichtige Krankheiten Aufzählungsliste 71: Kriterien für die Berechtigung ergänzend wirksamen Filterkriterien Aufzählungsliste 72: Beispiel für Berechtigungsvergabe eines Patienten Aufzählungsliste 73: Gegenargumente für diskreten Zugriff Aufzählungsliste 74: Zu berücksichtigende Aspekte bei der Verschlüsselung von Dokumenten Aufzählungsliste 75: Ordnungsmäßigkeit der Archivierung Aufzählungsliste 76: Voraussetzungen einer ordnungsgemäßen Archivierung gem. BSI Aufzählungsliste 77: Anforderungen an ein revisionssicheres Archiv Aufzählungsliste 78: 10 Merksätze zur revisionssicheren elektronischen Archivierung des VOI Aufzählungsliste 79: Braunschweiger regeln zur Archivierung elektronisch signierter Dokumente Aufzählungsliste 80: Notwendigkeit von digitalen Archivsystemen Seite XII Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

15 1 Vorwort 1 Vorwort Im vorliegenden Dokument werden die Ergebnisse des Arbeitspakets 04 (AP04) des Projektes ebusiness Plattform Gesundheitswesen (ebpg) dargestellt. Ziel des Arbeitspakets war die inhaltliche und technologische Spezifikation der Anforderungen und Interoperabilität von und zu einrichtungsübergreifenden Patientenaktensystemen (eepa). Das Projekt wurde vom Land Nordrhein-Westfalen und der EU finanziert und von Agfa Healthcare GmbH, brightone GmbH, CSC Deutschland Solutions GmbH, Duria eg, Fachhochschule Dortmund, Fraunhofer-Institut für Software- und Systemtechnik ISST, Ruhr-Universität Bochum und der Siemens AG getragen. Adressaten dieses Kompendiums sind: Primärsystemhersteller (Krankenhausinformationssysteme und Arztpraxensysteme), welche die Integration ihrer Systeme in einrichtungsübergreifende Aktensysteme sicherstellen wollen. Hersteller, welche einrichtungsübergreifende Aktensysteme entwickeln. Projekte der Interoperabilität, welche fachliche und technische Unterstützung bei der Projektgestaltung suchen. Fachöffentlichkeit in Politik und Gesundheitsmanagement, welche ein tiefergehendes Verständnis für einrichtungsübergreifende Aktensysteme erwerben möchten. Aufzählungsliste 01: Adressaten des Kompendiums Die Ergebnisse des ebpg-projekts und damit auch dieses Kompendiums unterliegen keiner Verwendungsbeschränkung. Die Projektpartner setzen damit bewusst ein Zeichen, dass proprietäre Lösungen nicht in ihrem Interesse liegen. Einrichtungsübergreifende Kommunikation kann nur funktionieren, wenn sowohl technische als auch semantische Interoperabilität gewährleistet ist. Technologie und Semantik muss von beteiligten Gesundheitsdienstleistern und Industriepartnern einheitlich gehandhabt werden. Konsequenterweise wurde im Konostrialprojekt ein wesentlicher Schwerpunkt auf die Spezifikation der Anforderungen und Interoperabilität von und zu einrichtungsübergreifenden Patientenaktensystemen gelegt und dafür das Arbeitspaket 4 als Teilprojekt beantragt und bearbeitet. Bei den Arbeiten wurde auf eine enge Abstimmung mit den Standardisierungsgremien bzw. die Berücksichtigung der von diesen Organsiationen veröffentlichten Standards geachtet. Im Wesentlichen sind hier HL7 Deutschland und IHE Deutschland zu nennen. Die Mitarbeit am IHE Cookbook zur einrichtungsübergreifenden Kommunikation war ein essentieller Arbeitsbestandteil des AP04. Seite 1 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

16 1 Vorwort Der Nutzen einrichtungsübergreifender Aktensysteme ist weitegehend unbestritten und besteht u. a. in 1 der einrichtungsübergreifenden Verfügbarkeit der wichtigsten Behandlungsinformationen für autorisierte Behandelnde für retrospektive Transparenz ( Was war? ), o dadurch Verringerung der Patientenbelastung durch Vermeidung von Doppelmaßnahmen und kontraindizierten Maßnahmen, o dadurch Verbesserung der Patientensicherheit z. B. durch Verordnungsüberprüfungen (AMTS) und explizite Markierung bzw. Dokumentation von Gefährdungsund Risikofaktoren, der prospektiven Transparenz für autorisierte Behandelnde ( Was soll sein? ), z. B. welche Maßnahmen, Verordnungen und Nachsorgepfade geplant sind allgemein die Ermöglichung des Einsatzes einrichtungsübergreifender Behandlungspfade, der Unterstützung eines teamorientierten Behandlungsmanagements mittels teamorientierter und abgestimmter Planung der aktuellen und zukünftigen Behandlung, der Ermöglichung schneller adäquater Reaktion in Notfallsituationen, der Unterstützung einer kontinuierlichen Versorgung bei Umzug, Reisen etc., der Verbesserung der Lebensqualität chronisch Kranker, also insgesamt der Effektivierung und Qualitätssteigerung der Behandlung der Patienten sowie der Prävention. Aufzählungsliste 02: Beispiele für Nutzen einrichtungsübergreifender Aktensysteme Die Umsetzung dieser Ziele bedingt neben technologischem und semantischem Konsens auch die Finanzierung von Einrichtung, Wartung, Infrastruktur und Nutzung einrichtungsübergreifender Aktensysteme. Diese Finanzierung ist in Deutschland nicht geklärt und muss wesentliche Gestaltungsaufgabe der Gesundheitspolitik werden. Ansätze sind aus der vom Bundesgesundheitsministerium im Jahr 2012 in Auftrag gegebenen ehealth Studie erkennbar. 2 Zur Einordnung des AP04 in den ebpg-gesamtprojektkontext wird auf die entsprechende ebpg- Gesamtbeschreibung verwiesen. 3 In diesem Dokument wird zunächst ein Überblick zu einrichtungsübergreifenden Aktensystemen und speziell zu einrichtungsübergreifenden Elektronischen Patientenakten (eepa) auch in Abgrenzung zu persönlichen Patientenakten und zu Fallakten gegeben. Aufbauend darauf werden Rollen und Akteure definiert, welche in Kontakt mit der eepa treten. Dies beinhaltet die Beschreibungen konkreter Prozesse und Nutzungsszenarien (Use Cases). 1 Vgl. Elektronische Akten im Gesundheitswesen, Ergebnisse des bundesweiten Arbeitskreises EPA/EFA, Copyright ZTG Zentrum für Telematik im Gesundheitswesen GmbH, Stand , Version 1.0, S.12 2 Vgl. 3 Vgl. Seite 2 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

17 1 Vorwort Ebenfalls wird darauf eingegangen, dass eine eepa neben dem Austausch von medizinischen Dokumenten auch das Potential für weitere Anwendungen sogenannte Mehrwertanwendungen bietet: Zum Beispiel für die Abfrage konkreter medizinischer Parameter oder die Erstellung von Medical Summaries. Technische Spezifikationen sind Inhalte eines eigenen Kapitels. Hier zeigt sich auch die Abstimmung mit IHE. So ist das IHE-Profil XDS (Cross Enterprise Document Sharing) Basis der eepa-architektur und der eepa-technologie. Ebenso wird auf die sinnvolle Nutzung einer bzw. der Telematik-Infrastruktur in Deutschland eingegangen. Der Austausch medizinischer Inhalte erfolgt über sogenannte Informationsobjekte. Dies sind im Wesentlichen Dokumente, deren Struktur zur Sicherstellung von Interoperabilität von den Beteiligten gleichermaßen akzeptiert werden muss. Die Basis dafür liefert das HL7-Konzept der Clinical Document Architecture (CDA). CDA definiert verschiedene Ebenen (Level) der Strukturiertheit. Je detaillierter Dokumente strukturiert sind, desto besser können Inhalte automatisiert zum Nutzen der Patienten verarbeitet werden. Im AP04 werden der Status und die Planung nationaler und internationaler CDA Dokumenten-Standards analysiert und es werden Handlungsempfehlungen abgeleitet. eepa können nur eingesetzt werden und Akzeptanz finden, wenn Datenschutz und Datensicherheit gewährleistet sind und Bürger bzw. Patienten diese Gewährleistung nicht anzweifeln. Im ebpg- Projekt wird dieser wichtige Themenkomplex in einem eigenen Arbeitspaket (AP01) berücksichtigt und bearbeitet. Soweit Fragen von Datenschutz und -sicherheit unmittelbar Einfluss auf die Usability oder Architektur einer eepa haben, werden diese in diesem Dokument aufgegriffen. Unser besonderer Dank gilt dem Ministerium für Gesundheit, Emanzipation, Pflege und Alter des Landes Nordrhein-Westfalen, welches die Bedeutung der einrichtungsübergreifenden Kommunikation im Gesundheitswesen für das Gemeinwohl der Bürger dauerhaft fokussiert. Insbesondere Herr Ministerialrat Mathias Redders und Frau Nadja Pecquet waren hilfreiche Fürsprecher und engagierter Begleiter während der Projektlaufzeit. Der Dank geht gleichermaßen auch an die fachliche Gesamtprojektleitung, welche bei der Fachhochschule Dortmund, Fachbereich Medizinische Informatik, Herrn Professor Dr. Peter Haas lag. Sehr gerne werden Anregungen und Kritik entgegengenommen, welche zum Beispiel per an die Mitarbeiterinnen und Mitarbeiter des Arbeitspakets per Mail übermittelt werden können, die Adresse hierfür ist Im Sinne einer besseren Lesbarkeit der Texte wurde von uns entweder die männliche oder weibliche Form von personenbezogenen Hauptwörtern gewählt. Dies impliziert keinesfalls eine Benachteiligung des jeweils anderen Geschlechts. Frauen und Männer mögen sich von den Inhalten dieses Kompendiums gleichermaßen angesprochen fühlen. Wir danken für Ihr Verständnis. Seite 3 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

18 1 Vorwort Seite 4 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

19 2 Konzepte einrichtungsübergreifender Aktensysteme 2 Konzepte einrichtungsübergreifender Aktensysteme Es existieren unterschiedliche Konzepte für einrichtungsübergreifende Aktensysteme. Eine begriffliche und inhaltliche Differenzierung der Konzepte welche auch im vorliegenden Dokument verwendet wird ist 2011 im bundesweiten Arbeitskreis EPA/EFA erarbeitet worden. 4 Zum grundlegenden Verständnis des Konzepts der hier betrachteten einrichtungsübergreifenden Elektronischen Patientenakte (eepa) ist es hilfreich, dieses gegen die wesentlichen anderen zentralen Aktentypen abzugrenzen, wesehalb diese im Folgenden kurz erläutert werden. 2.1 Die Einrichtungsübergreifende Medizinische Fallakte (EFA) Eine EFA wird verwendet, wenn mehrere Einrichtungen oder Ärzte gemeinsam fallbezogen in die Behandlung des Patienten eingebunden sind. Zweck ist die Schaffung eines gemeinsamen Wissensstandes zur Koordination der gemeinsamen Behandlung des aktuellen Falles. Die Dokumentation in der EFA wird von Ärzten geführt. Jede der beteiligten Einrichtungen hat die Hoheit über die aus ihrer jeweiligen Behandlungsdokumentation in die einrichtungsübergreifende Dokumentation eingespeisten Informationsobjekte. Der Fokus einer EFA liegt auf einem konkreten Zweck auf der Behandlung eines einzelnen medizinischen Falles. Es besteht nicht der Anspruch eine medizinisch fallübergreifende ggf. lebenslange Akte zu führen. Aus diesem Grund ist die Lebensdauer einer Fallakte auch zeitlich begrenzt. Die Führung der EFA über alle administrativen Fälle eines medizinischen Falls ist selbstverständlich möglich und gewünscht. Datenschutzrechtlich wird eine Fallakte ganzheitlich betrachtet, d.h. alle Beteiligten können alle Dokumente (ein)sehen. 2.2 Die persönliche Elektronische Patientenakte (pepa) Die persönliche Elektronische Patientenakte dient zur Unterstützung eines aktuell noch nicht konkretisierten aber vom Patienten in zukünftigen Bedarfssituationen bestimmbaren Verwendungszweckes. Der Inhalt dieser Dokumentation kann aus ärztlichen fallbezogenen Einzeldokumentationen die dem Patienten zur Verfügung gestellt wurden oder aus von ihm selbst erstellten Informationen bestehen. Zweck dieser Dokumentation ist die Zusammenstellung aller wesentlichen Gesundheitsinformationen über den Patienten für den Fall einer ärztlichen Behandlungsnotwendigkeit. Die Entscheidung über die konkrete Nutzung (Zweckbestimmung) erfolgt durch den Patienten, indem dieser die Informationen bei Bedarf einem behandelnden Arzt zur Verfügung stellt. Die Dokumentation liegt in der Hoheit des Patienten, unabhängig davon, ob dieser hierfür die Informationen in die Dokumentation selbst einstellt oder ggf. einen Arzt damit beauftragt. 4 Vgl. Elektronische Akten im Gesundheitswesen, Stand , Copyright Zentrum für Telematik im Gesundheitswesen GmbH, S. 15 ff. Seite 5 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

20 2 Konzepte einrichtungsübergreifender Aktensysteme 2.3 Die einrichtungsübergreifende Elektronische Patientenakte (eepa) Zweck der eepa ist die Schaffung eines gemeinsamen Wissensstandes zur Koordination sowohl der aktuellen indikationsspezifischen Behandlungen als auch die zukünftige sichere Versorgung über alle Behandlungsfälle des Patienten hinweg. Aufgrund der wechselseitigen Einflüsse zwischen Erkrankungen und den damit verbundenen Therapien ist die eepa vor allem bei multimorbiden Patienten, bei denen mehrere komplexe Behandlungen parallel laufen, ein wichtiges Instrument. Die eepa wird von medizinischen Fachkräften (Health Professionals) geführt. Ergänzungen um einen in der Hoheit des Patienten liegenden Bereiches in dem Patienten selbstständig Daten einstellen können, wie z. B. ein Schmerztagebuch, sind möglich. Innerhalb der Dokumentation kann vom Patienten festgelegt werden, wer bei welchen Behandlungskontexten auf welche Informationen Zugriff hat. 2.4 Die Elektronische Patientenakte gemäß 291a SGB V ( 291a Akte ) Die sogenannte 291a Akte kann (aufgrund teilweise allgemeiner Formulierungen in 291a SGB V) nicht eindeutig einem der drei oben skizzierten Aktenkonzepte zugeordnet werden. Es existieren jedoch Einschätzungen, welche die 291a Akte fokussiert in die Hoheit des Bürgers stellen und diese damit dem Konzept der pepa entspricht. 5 Andere Meinungen sehen die 291a Akte nahe an der eepa, erweitert um Zugriffsmöglichkeiten der Patienten. 6 5 Vgl. Elektronische Patientenakte gemäß 291a SGB V, Kernkonzepte und technische Umsetzung, Fraunhofer-Institut für Software- und Systemtechnik ISST, Fraunhofer-Institut für Sichere Informationstechnologie SIT, Vgl. Elektronische Akten im Gesundheitswesen, Stand , Copyright Zentrum für Telematik im Gesundheitswesen GmbH, S. 41 f. Seite 6 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

21 3 Merkmale einrichtungsübergreifender Elektronischer Patientenakten 3 Merkmale einrichtungsübergreifender Elektronischer Patientenakten Die vorliegende Spezifikation der einrichtungsübergreifenden Elektronischen Patientenakte (eepa) zeichnet sich durch die nachfolgend beschriebenen Merkmale aus. 3.1 Health Professional geführte Akte mit Patienten- und Notfallbereich Die eepa wird im Kernbereich von medizinischen Fachkräften (Health Professionals), welche sich dem entsprechenden Netzwerk zum Dokumentenaustausch angeschlossen haben, geführt und verantwortet. Der Patient kann einen Health-Professional als Aktenmoderator benennen, um ihm damit weiterführende Verwaltungsrechte zu übertragen. Der Patient kann im Kernbereich einzustellende Inhalte nicht beeinflussen, ändern oder löschen. Damit ist sichergestellt, dass die Inhalte der eepa eine Qualität besitzen, auf welcher medizinisches Handeln auch forensisch abgesichert sinnvoll aufbauen kann. Der Patient muss entscheiden, ob er eine eepa überhaupt führen will (sogenanntes Opt- In-Verfahren). 3.2 Differenzierte Zugriffsrechte Eine eepa muß die Vergabe differenzierter Zugriffsrechte ermöglichen. Soweit ein Behandlungsverhältnis vorliegt, kann der Aktenzugriff für den Behandler vom Patienten vor Behandlungsbeginn optional nach Kriterien gefiltert werden. Gewählte Kriterien sind: Gesundheitsdienstleister Dokumententyp Medizinisches Fachgebiet der Dokumente Zeitraum Aufzählungsliste 03: Filterkriterien für Zugriffsrechte Für die Kriterien sind jeweils Wertesets zu hinterlegen. Auf Basis der vergebenen Reche wird geprüft, ob seitens des Patienten Dokumente für den Zugriff gesperrt sind. Gesperrte Dokumente sind grundsätzlich nicht sichtbar. Die jeweils gewährten Zugriffsrechte werden protokolliert. 3.3 Fallübergreifende und ggf. lebenslange Aktenführung In Abhängigkeit von der Patienten-Entscheidung ist die eepa somit eine fallübergreifende, ggf. lebenslang, geführte Akte oder eine Akte, die differenziert für einen oder mehrere konkrete medizinische Fälle (Zwecke) genutzt wird. Im letztgenannten Fall deckt das fachliche Konzept der eepa auch das grundsätzliche Konzept einer Elektronischen Fallakte 7 (EFA) ab. 7 Mit Ausnahme der Berechtigungssteuerung, die bei der EFA nur ganzheitlich erfolgen darf. Seite 7 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

22 3 Merkmale einrichtungsübergreifender Elektronischer Patientenakten Die Spezifikation der eepa erlaubt darüber hinaus in einem klar abgegrenzten Bereich explizit die Integration patientengeführter Dokumente. Hier haben Patienten selber die Rechte z. B. zum Einstellen und Pflegen von Vitalwerten, Fitnessparametern, Körpergewicht u.v.m. Das Konzept der patientengeführten Dokumente kann somit im Sinne der persönlichen Elektronischen Patientenakte (pepa) genutzt werden. Ein weiterer spezieller Dokumententyp sind Notfalldokumente. Auf Wunsch des Patienten bzw. Bürgers können hier durch den Arzt Informationen hinterlegt werden, welche für eine Notfallbehandlung essentiell sind. Typische Beispiele sind Diagnosen, Medikation, Allergien, besondere Hinweise (Schwangerschaft u. a.) und Kontaktinformationen. Notfalldaten können auf verschiedenen Wegen in die eepa eingestellt werden. In Deutschland ist die Hinterlegung von Notfalldaten als freiwillige Anwendung der elektronischen Gesundheitskarte (egk) vorgesehen. Notfalldaten umfassen hier auch persönliche Erklärungen des Patienten u. a. zur Organspendenbereitschaft, zur Patientenverfügung und zur Vorsorgevollmacht. 8 Die Übernahme der Notfalldaten von der egk in die eepa ist zum Beispiel für den Backup der egk- Notfalldaten sinnvoll. Es lassen sich auch Szenarien vorstellen in denen die egk im Notfall nicht verfügbar ist und Notfalldaten deshalb ersatzweise über die eepa abgerufen werden können. Um hierfür die Aktualität der Notfalldaten in der eepa sicherzustellen, ist ein Update der egk mit einer Aktualisierungsschnittstelle der eepa-daten zu koppeln. Ein anderer Weg zur Erstellung der Notfalldokumente ist die automatisierte Ermittlung anhand von verfügbaren ärztlichen Dokumenten. So können aus den Sektionen oder Eingabeebenen strukturierter CDA Dokumente (Level 2 und Level 3, siehe Kapitel ) notfallrelevante Informationen automatisiert herausgefiltert und somit zusammengestellt werden. Die ermittelten Notfalldaten können dabei nicht besser sein, als die Qualität der Inhalte der zugrunde liegenden Dokumente. Auch ist die Existenz von qualitativ hochwertigen und aktuellen Dokumenten notwendige Voraussetzung für die automatisierte Erstellung medizinisch und forensisch gesicherter Notfalldaten. Die Integration von persönlichen Erklärungen ist ergänzend zu berücksichtigen. Insgesamt ist die automatisierte Erstellung von Notfalldaten das im Vergleich zur Übernahme von egk-notfalldaten deutlich anspruchsvollere Szenario. Der Notfallzugriff ermöglicht einem Health Professional mit Health Professional Card den Zugriff auf Notfalldokumente ohne vorherige Autorisierung durch den Patienten. Dieses Vorgehen entspricht auch dem Konzept der Bundesärztekammer. 9 Der Notfallzugriff ist zu loggen, so dass ein eventueller 8 Die Bundesärztekammer hat ein ausführliches Konzept und ein technisches Lastenheft zum Thema Notfalldaten erstellt: Arbeitskonzept Notfalldatenmanagement (NFDM), Version 1.05 vom und Lastenheft Notfalldaten- Management (NFDM), Version: vom Vgl. Arbeitskonzept Notfalldatenmanagement (NFDM), Version 1.05 vom , S. 35 ff. Seite 8 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

23 3 Merkmale einrichtungsübergreifender Elektronischer Patientenakten Missbrauch verfolgt werden kann. Es ist zu überlegen, den Patienten automatisiert über den Zugriff zu informieren. Es existieren weitergehende Überlegungen, im Notfall den nicht autorisierten Zugriff auf die gesamte eepa zu ermöglichen (sog. Broken Glas). Diesen Überlegungen ist eine klare Absage zu erteilen. Zum einen ist das Konzept von Broken Glas datenschutzrechtlich bedenklich und wahrscheinlich unzulässig. Darüber hinaus ist der Nutzen fragwürdig, da im Notfall keine zeitintensive Analyse einer Vielzahl von Dokumenten erfolgen kann. 3.4 Integration in Primärsysteme und Nutzung von Standards Die Daten und Dokumente der eepa sind aus technischen und forensischen Gründen redundante Informationen der institutionellen Akten in den Primärsystemen (u. a. Krankenhaus- und Arztpraxensysteme). Inhalte der eepa können automatisiert in die Primärsysteme heruntergeladen und aus den Primärsystemen hochgeladen werden. Zur Etablierung dieser essentiellen Funktionalität in Kombination mit den verschiedenen Anforderungen (s. o./u.) ist es wesentlich, dass Down- und Upload nicht mit proprietären Lösungen sondern mit Standards erfolgen. Entsprechend ist bei der Erstellung der vorliegenden Spezifikation durchgängig die Konformität mit HL7 und IHE beachtet worden. Beispielsweise erfolgte von Autoren dieser Spezifikation als Bestandteil des ebpg-projekts eine intensive Mitarbeit am in 2011 begonnenen IHE Cookbook zur einrichtungsübergreifenden Kommunikation. 10 HL7 V2.x (für den Identity Feed), das IHE-Profil Cross Enterprise Document Sharing (XDS) und die Clinical Document Architecture (CDA Release 2) bilden somit die zentrale Basis der eepa- Spezifikation. Soweit seitens der Primärsysteme diese Standards noch nicht (durchgängig) unterstützt werden, wird mit Interoperabilitätsmodulen (vgl. AP08) ein technischer Interimsweg ermöglicht. 3.5 Dokumentenbasierte Akte mit Zugriff auf feingranulare Informationen Der inhaltliche Datenaustausch zwischen eepa und Primärsystemen erfolgt im Wesentlichen mit CDA-Dokumenten. Idealerweise sind die Inhalte der Dokumente als strukturierte Daten (CDA Level 3) verfügbar und stehen damit für die weitergehende Verarbeitung der Daten mit semantischer Interoperabilität zur Verfügung. Soweit Primärsysteme (noch) nicht in der Lage sind, strukturierte Informationen zu liefern, können auch (teilweise) unstrukturierte Daten bzw. Dokumente (CDA Level 1 und 2) in die eepa eingestellt werden. Die Ablage strukturierter Daten in CDA-Dokumenten ermöglicht auch Analyse und Recherche in der eepa. So können z. B. Diagnosen, Leistungen oder Medikamente (feingranulare Informationen) dokumentenübergreifend gefiltert und analysiert werden. 10 Vgl. IHE Deutschland e.v. (Herausgeber), IHE-Cookbook: Einrichtungsübergreifende elektronische Bild- und Befundkommunikation, Ein Leitfaden zur Implementierung von medizinischen Netzen, auf Basis der IHE-Profile XDS.b und XDS-I.b in Deutschland, 2012 Seite 9 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

24 3 Merkmale einrichtungsübergreifender Elektronischer Patientenakten Die in der vorliegenden Spezifikation verwendeten Dokumententypen sind nicht (proprietär) neu entwickelt, sondern referenzieren auf bestehende Standards, welche in Zusammenarbeit mit HL7 und IHE geprüft und ggf. weiterentwickelt werden. 3.6 Funktionsfähigkeit mit Offline-Ticket bzw. ohne Offline-Ticket Die eepa-spezifikation lässt die Patientenidentifikation sowohl im Offline- als auch in einem Onlineverfahren zu. Offline bedeutet, dass der Patient Tickets (Barcode, Stick, egk o. a.) besitzt, welche ihn als Patienten eindeutig identifizieren. Ein Ticket kann dem Arzt bzw. der Institution ausgehändigt werden, welche(r) damit im Ergebnis den Zugriff auf die eepa (ggf. eingeschränkt wie oben beschrieben) des Patienten erhält. Online bedeutet, dass für Patienten ein zentrales Register für die Identifikation in der jeweiligen Affinity-Domain besteht (Master Patient Index, vgl. z. B. IHE PIX-Profil und bvitg PID-Profil). Die Vergabe und ggf. der Widerruf von Zugriffsrechten erfolgt über ein Berechtigungssystem, welches internationalen Richtlinien und Standards wie z. B. IHE Cross Enterprise User Assertion bzw. OASIS extensible Access Control Markup Language (XACML) und Security Assertion Markup Language (SAML) genügt. Der Patientenwille wird in einem Primärsystem erfasst und technisch als Policy abgebildet. Die Komponenten des Berechtigungssystems tragen dafür Sorge, dass die durch den Patienten angegebenen Einschränkungen von Infrastrukturkomponenten durchgesetzt werden. 3.7 Benutzeroberfläche einer eepa Grundsätzlich benötigt die eepa keine eigene Benutzeroberfläche. Der Datenaustausch erfolgt über Primärsysteme, welche Dokumente bzw. Daten der eepa abrufen und im Primärsystem nutzen und Dokumente bzw. Daten aus Primärsystemen in die eepa laden. Die Konzeptionierung von Benutzeroberflächen der eepa ist nicht Bestandteil dieser Spezifikation. Die ausschließliche Analyse der eepa-inhalte über Primärsysteme besitzt Grenzen, wenn der Patient autonom Zugriff auf seine eepa bekommen soll. Zum Beispiel ist es für den lesenden Zugriff des Patienten oft nicht praktikabel den Hausarzt aufzusuchen. Sofern die oben genannten patientengeführten Dokumente genutzt werden sollen, ist es zwingend, dass der Patient einen sicheren autonomen Zugriff mit eigener Benutzeroberfläche außerhalb des Primärsystems erhält. Im Übrigen verlangt die gesetzliche Akte nach 291a SGB V, dass der Patient selbst ein Zugriffsrecht auf die Akte besitzt. Schließlich ist eine eigene eepa-benutzeroberfläche als Interimsszenario für den Arzt sinnvoll, sofern das Primärsystem noch keine Kommunikation mit der eepa unterstützt. Auch für technische Administrationsfunktionen der eepa kann ein Frontend notwendig sein. Seite 10 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

25 3 Merkmale einrichtungsübergreifender Elektronischer Patientenakten 3.8 Fähigkeit zur Einbindung in die Telematik-Infrastruktur Die Einbindung der eepa in die Telematik-Infrastruktur kann mit zwei Zielrichtungen erfolgen. Als sogenannte Mehrwertanwendung (keine explizite gesetzliche Spezifikation) oder als gesetzliche Akte nach 291a Abs.3 SGB V. Für die Einbindung als Mehrwertanwendung wird derzeit von der DKG im Auftrag der gematik ein Zertifizierungsverfahren entwickelt. Vor dessen Abschluss sind keine validen Empfehlungen zur Einbindung möglich. Für die gesetzliche Akte ist eine Spezifikation der Vorgaben des 291a SGB seitens des Gesetzgebers bzw. der gematik noch nicht erfolgt. Grundsätzlich wird davon ausgegangen, das aufgrund der flexiblen eepa Architektur insbesondere bei Umsetzung autonomer Zugriffsmöglichkeiten des Patienten und dem Angebot des Patientenordners die eepa das Potenzial als gesetzliche Akte besitzt. Für Aktensystemhersteller bedeutet die erfolgreiche Qualifizierung für die gesetzliche Akte ein wertvolles Produktmerkmal. 3.9 Spezifikation bzgl. Betrieb und (Langzeit-) Archivierung einer eepa Der Langzeitbetrieb eines Aktensystems sollte grundsätzlich so ausgelegt sein, dass z. B. der Wechsel des Aktenanbieters unterstützt werden kann. Soweit Daten der eepa an ein (elektronisches) Archivsystem übergeben werden, ist sicherzustellen, dass die Daten innerhalb gesetzlicher Fristen wieder lesbar gemacht werden können. Seite 11 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

26 3 Merkmale einrichtungsübergreifender Elektronischer Patientenakten Seite 12 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

27 4 Aspekte der Standardisierung 4 Aspekte der Standardisierung 4.1 Organisationen IHE Deutschland Seit 1998 arbeiten bei IHE ( Integrating the Healthcare Enterprise ) Anwender und Firmen in einem kontinuierlichen Prozess zusammen, um durch konsequenten Einsatz von Standards eine maximale Interoperabilität der IT-Systeme im Gesundheitswesen zu erzielen. IHE entwickelt keine neuen Standards, sondern beschreibt detailliert, wie bestehende Standards im Gesundheitswesen anzuwenden sind. Man nennt dies auch Profilierung. IHE formuliert dazu Anforderungen aus der Praxis in so genannten Use Cases, identifiziert relevante Standards und entwickelt technische Leitfäden im so genannten Technical Framework, mit dem ein Hersteller sein Produkt umsetzen kann. Im Rahmen des internationalen Connect-a-thon testen die Hersteller ihre Systeme dann untereinander und bereiten sie auf den Praxiseinsatz vor. Das aktuell größte Projekt von IHE Deutschland ist die Erstellung einer detaillierten Spezifikation ( Cookbook ) für die aktenbasierte, einrichtungsübergreifende Bild- und Befund-Kommunikation in Deutschland. Dabei sollen deutsche Sicherheitsanforderungen, Vokabularien etc. so genau spezifiziert werden, dass darauf eine interoperable Demonstration durch Systeme verschiedener Hersteller aufgebaut werden kann. Die Arbeiten an dem Cookbook wurden im Rahmen des ebpg-projektes unterstützt und mitgetragen HL7 Deutschland Die deutsche Organisation von HL7 International ( Health Level 7 ) ist seit 1993 ein eingetragener Verein. Die Mitgliedschaft in der nationalen HL7-Organisation beruht auf persönlichem Engagement klinischer Nutzer und vor allem auf industriellem Interesse. HL7 wird einerseits als Bezeichnung für die Organisation verwendet, die Standards für das Gesundheitswesen entwickelt, andererseits als Oberbegriff für eine Familie von Standards, zu denen die Versionen 2.x und die Version 3 gehören. Inzwischen arbeiten lokale HL7-Organisationen in über 35 Ländern an der Entwicklung der Standards mit. Die Zahl 7 des Namens HL7 bezieht sich auf die Schicht 7 des ISO/OSI-Referenzmodelles für die Kommunikation (ISO ) und drückt damit aus, dass hier die Kommunikation auf Applikationsebene beschrieben wird. In Deutschland wird HL7 praktisch nur innerhalb von Krankenhäusern ein Seite 13 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

28 4 Aspekte der Standardisierung gesetzt und so gut wie nie zum Austausch von Daten zwischen dem klinischen (stationären) und dem niedergelassenen (ambulanten) Sektor im Gesundheitswesen verwendet. Dies liegt zum Teil daran, dass sich in der Praxis-Software im niedergelassenen Bereich eine Fülle von Datenaustauschformaten entwickelt hat, wobei die xdt-familie wohl die größte Verbreitung hat Zusammenarbeit IHE/HL7 15 Das Interoperabilitätsforum wird gemeinsam von (den technischen Komitees) der HL7-Benutzergruppe, IHE Deutschland, sowie der AG Interoperabilität des bvitg (ehemals VHitG), dem Fachbereich Medizinische Informatik des DIN und der Arbeitsgruppe für Standards und Interoperabilität und EHR der GMDS getragen und veranstaltet. Hier werden Entwicklungen, Fragen und Probleme der Interoperabilität in der Kommunikation zwischen IT-Anwendungen vorgestellt sowie Lösungsansätze eruiert und weitere Aktivitäten festgelegt. 4.2 Standards CDA 16 Die Clinical Document Architecture (CDA) wird seit 1997 von HL7 entwickelt und ist ein Standard zur Speicherung und zum Austausch von strukturierten klinischen Dokumenten. Die momentan weltweit eingesetzte Fassung ist das Release 2, das 2005 freigegeben wurde. CDA kann zur Umsetzung von Arztbriefen, Überweisungen, Befundberichten, Operationsberichten und Rezepten eingesetzt werden. CDA basiert auf XML und ist Teil von HL7 Version 3 - einer Familie von auf XML-basierenden Kommunikationsstandards, die auf dem HL7 Reference Information Model (RIM) basieren. Das RIM ist ein generisches, konzeptuelles Informationsmodell für das gesamte Gesundheitswesen und besteht aus 4+2 Basisklassen, von denen alle Spezifikationen auf der Basis von HL7 Version 3.x abgeleitet werden. Ein CDA-Dokument ist ein im RIM definiertes und vollständiges Informationsobjekt, das außerhalb einer Nachricht existieren kann und neben Texten auch Bilder, Töne, Biosignale und andere multimediale Inhalte beinhalten kann K. Boone: "The CDA Book", Springer-Verlag New York, LLC, Mai 2011, ISBN: Seite 14 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

29 4 Aspekte der Standardisierung Eigenschaften von CDA Ein klinisches Dokument in CDA hat folgende grundsätzliche Eigenschaften: Persistenz Ein klinisches Dokument wird (zu Dokumentationszwecken; im Gegensatz zu Nachrichten) aufgehoben. Dieser Zeitraum wird durch lokale bzw. gesetzliche Anforderungen geregelt. Verantwortung Ein klinisches Dokument wird durch eine Person oder Organisation verwaltet, die mit der Pflege des Dokumentes betraut ist. Möglichkeit zur Authentisierung Ein klinisches Dokument ist eine Sammlung von Informationen, bei der eine gesetzlich gültige Authentisierungsmöglichkeit gegeben ist. Kontext Alle innerhalb des Dokumentes gespeicherten Informationen werden unter Angabe des dazugehörigen Kontextes gespeichert. Ganzheitlichkeit Die Authentisierung eines klinischen Dokumentes trifft auf das Dokument als Ganzes zu und nicht nur auf einzelne Teile, die dem Kontext entnommen werden. Menschliche Lesbarkeit Ein klinisches Dokument ist für den Menschen lesbar. Aufzählungsliste 04: Grundsätzliche Eigenschaften von CDA-Dokumenten CDA-Struktur Ein CDA Dokument wird durch das <ClinicalDocument>-Element verankert und enthält einen Header und einen Body. Abbildung 01: Schematischer Aufbau eines CDA-Dokuments Seite 15 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

30 4 Aspekte der Standardisierung CDA-Header Der Header enthält die Metadaten des Dokumentes und identifiziert, klassifiziert und authentifiziert damit das Dokument sektorübergreifend. Inhalt des CDA-Headers im Überblick: Informationen über das Dokument Dies beinhaltet die eindeutige Identifikationsnummer des Dokumentes, Verweise auf Vorversionen, Titel, Erstellungszeitpunkt und Angaben über den Dokumententypen, Informationen über die beteiligten Personen und Organisationen z. B. welcher Arzt hat für welchen Patienten das Dokument erstellt, wer bekommt das Dokument, wer hat es unterschrieben, wer hat Informationen dazu beigetragen etc. und Informationen über das Ereignis der Behandlungsfall, in dem das Dokument erstellt wurde. Aufzählungsliste 05: Der Inhalt eines CDA-Headers CDA-Body Der Body enthält den eigentlichen Inhalt und muss als menschenlesbarer Text vorhanden sein. Das kann in der einfachsten Form auch die Einbettung eines PDF-Dokuments sein (vgl. 12.6). Zusätzlich kann er strukturierte Tags (Markups) beinhalten. Das folgende Beispiel zeigt einen strukturierten Body, der durch das Element <structuredbody> eingeschlossen wird, und durch rekursiv ineinander verschachtelte Dokumentabschnitte unterteilt ist. Ein CDA Dokument enthält normalerweise mehrere Abschnitte, die durch das Element <section> eingeschlossen werden. Der CDA narrative Block wird durch das <text>-element innerhalb des <section>-elements umschlossen und enthält den menschlich lesbaren Inhalt. CDA-Entries stellen den strukturierten Inhalt dar, der für die weitere Computerverarbeitung bereitgestellt wird. CDA-Entries kodieren für gewöhnlich den Inhalt, der im narrativen Block des gleichen Abschnitts vorhanden ist. CDA Entries können ineinander verschachtelt werden und auch auf externe Objekte verweisen. Externe CDA-Verweise treten immer innerhalb des Kontextes eines CDA-Entry auf. Externe Verweise beziehen sich auf Inhalt, der außerhalb dieses CDA-Dokumentes liegt, wie z. B. ein Bild oder ein anderes CDA- Dokument. Referenziertes Material wird nicht durch die Authentisierung des Dokumentes abgedeckt aus dem heraus der Verweis stattfindet. Seite 16 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

31 4 Aspekte der Standardisierung <?xml version="1.0" encoding="utf-8"?> <ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc " xmlns:xsi=" <typeid root=" " extension="pocd_hd000040"/> <!-- CDA Header --> <!-- CDA Body --> </ClinicalDocument> Abbildung 02: CDA-Beispieldokument CDA-Levels Der Body enthält die Dokumentation über den medizinischen Behandlungsfall und befindet sich immer innerhalb des Tags <structuredbody>. Der <structuredbody> setzt sich aus einer oder mehreren Komponenten (<component>) zusammen, die wiederum aus einer oder mehreren Sektionen (<section>) und die wiederum aus beliebig vielen Einträgen (<entry>) bestehen können. Man unterscheidet, je nachdem wie strukturiert die medizinische Dokumentation ist, zwischen drei Levels Level 1 Level 1 dient dazu, eine Eigenschaft von CDA-Dokumenten zu gewährleisten: die menschliche Lesbarkeit. Es handelt sich um einen beliebig formatierten Text, der sich innerhalb des <text>-tags befindet. Zwar gibt es verschiedene Formatierungsmöglichkeiten, um den Text zu strukturieren, allerdings schreibt CDA keine dieser Möglichkeiten vor, so dass der Text nicht zur maschinellen Auswertbarkeit herangezogen werden kann. Der narrative Text kann in einfachster Form ein unformatierter Text-String sein, der im Tag <text> eingeschlossen ist und die menschliche Lesbarkeit erfüllt, indem dieser Text über ein einfaches Stylesheet angezeigt wird. Andererseits kann der Text über HTML- Markups beliebig formatiert werden, um damit die unterschiedlichsten Zwecke zu erfüllen Level 2 Level 2 unterscheidet sich von Level 1 darin, dass die einzelnen Abschnitte (sections) mit ihren <text>-blöcken durch einen Code eindeutig identifiziert werden. Somit ist es möglich, maschinell bestimmte Abschnitte in dem Dokument wiederzufinden und auszuwerten. Man spricht in diesem Fall auch von maschineller Auswertbarkeit. Allerdings können bei Level 2 noch keine einzelnen Informationen sondern nur die zusammengehörigen Sections ausgewertet werden. Zum vollständigen Auswerten aller Messungen und Angaben muss das Dokument in Level 3 abgebildet werden. Seite 17 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

32 4 Aspekte der Standardisierung Level 3 Der Unterschied zwischen Level 1 und Level 3 besteht hauptsächlich darin, dass bei Level 3, zusätzlich zu Level 1, die Daten (automatisch) weiterverarbeitet werden können, wobei die Freitextinhalte von Level 1 erhalten bleiben. Hinzugefügt werden maschinenlesbare Angaben, so dass automatische Auswertungen der Daten durchgeführt werden können. So können bspw. in einem Diagnoseabschnitt neben der ausformulierten textuellen Darstellung ( Der Patient leidet an einer Blinddarmentzündung. ) für den Arzt der dazugehörige ICD-Code ( K35 ) für den Computer mit übertragen werden. Solche maschinell auswertbaren Angaben werden in so genannten Entry Acts eingeschlossen. Jede <section> kann keine bis mehrere Entries enthalten Umsetzungsstufen Die in dieser Ausarbeitung enthaltene technische Spezifikation der eepa definiert wie Primärsysteme Patienteninformationen über die IHE XDS Schnittstellen einrichtungsübergreifend austauschen können. Die Patienteninformationen können dabei in unterschiedlichen Formaten und divergierender Granularität vorliegen. Die folgenden Abschnitte zeigen sechs Umsetzungsstufen für den Arztbrief auf. Die jeweiligen Umsetzungsstufen adressieren dabei unterschiedliche Standardisierungs- sowie Granularitätsgrade. Die einzelnen Umsetzungsstufen schließen sich gegenseitig nicht aus, sondern können parallel (oder nacheinander) umgesetzt werden. Im Sinne einer hohen Auswertbarkeit von medizinischen Daten ist die Migration auf die Umsetzungsstufe 6 anzustreben. Seite 18 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

33 4 Aspekte der Standardisierung Abschnitte (Sections)/ # participant strukturierte Daten (Entries)/ # Entry Entry Entry Entry Entry legalauthenticator Entry Section Section Section Section Section Section PDF/JPG-Encapsulation custodian Zeit/ t recordtarget author Minimalanforderungen für CDA Abbildung 03: Integrationsstufen für CDA Umsetzungsstufe 1: Austausch proprietärer Dokumente In der ersten Umsetzungsstufe werden proprietäre Daten (z. B. Arztbriefe in PDF oder WORD) über die IHE Schnittstellen der eepa ausgetauscht. Die benötigten IHE XDS Metadaten für die Document Registry werden entweder manuell erfasst oder im Idealfall aus dem System automatisch extrahiert. Diese Umsetzungsstufe wird bereits jetzt von allen Primärsystemen, die IHE XDS Schnittstellen umsetzen, unterstützt. Die Auswertbarkeit der Dokumente beschränkt sich hier auf die angegebenen IHE XDS Metadaten. Damit wird aber noch keinerlei Information in CDA-Strukturen ausgedrückt Umsetzungsstufe 2: Austausch CDA Level 1(a) Dokumente In dieser Umsetzungsstufe werden proprietäre Dokumente (z. B. Arztbrief als PDF) als CDA Level 1 Dokument über die IHE Schnittstellen der eepa ausgetauscht. Die zur Registrierung benötigten IHE XDS Metadaten können automatisch aus dem CDA Header extrahiert werden. Ein CDA Level 1 Dokument ist ein Dokument welches einen strukturierten CDA Header umfasst. Die eigentliche medizinische Information wird entweder Base 64 Encoded oder hexadezimal in den CDA Body eingefügt (manchmal als Level 1a bezeichnet). Diese Umsetzungsstufe setzt voraus, dass Primärsysteme in der Lage sind ein proprietäres Dokument mit einem CDA Header zu versehen. Seite 19 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

34 4 Aspekte der Standardisierung Die Auswertbarkeit der Dokumente beschränkt sich hier auf die angegeben IHE XDS Metadaten und die strukturierten CDA Header Informationen. (Diese Möglichkeit gilt für alle weiteren Umsetzungsstufen.) In der vorangegangenen Abbildung 03 wird dies durch den grauen Bereich symbolisiert Umsetzungsstufe 3: Austausch CDA Level 1(b) Dokumente In dieser Umsetzungsstufe werden die medizinischen Informationen in einem CDA Level 1 Dokument ausgetauscht. Hierbei wird zwar jegliche Information in einzelnen Abschnitten in XML-Darstellung repräsentiert, allerdings nur in rein textueller Form Umsetzungsstufe 4: Austausch CDA Level 2 Dokumente In dieser Umsetzungsstufe werden die medizinischen Informationen in einem CDA Level 2 Dokument ausgetauscht. Die medizinischen Informationen werden in semantisch beschriebenen Abschnitten vorgehalten welche über eine Kodierung erkennbar sind. Diese Umsetzungsstufe setzt voraus, dass Primärsysteme in der Lage sind CDA Level 2 Dokumente zu erzeugen. Die CDA Level 2 Dokumente können geparst werden und es kann eine Auswertung bis hin zu Abschnittsebenen von Dokumenten durchgeführt werden. Wünschenswert ist die Umsetzung in Form von Section Level Templates, d.h. die Abschnitte befolgen konkrete Vorgaben bezüglich der Inhalte Umsetzungsstufe 5: Austausch aggregierter Informationen als CDA Level 3 Dokumente In dieser Umsetzungsstufe werden die medizinischen Informationen in einem CDA Level 3 Dokument ausgetauscht. Die medizinischen Informationen werden in strukturierten und semantisch beschriebenen Abschnitten (Section Level Templates) als strukturierte, granulare Informationen vorgehalten (Entry Level Templates). Ein CDA Dokument in dieser Umsetzungsstufe bildet klinische Dokumente/aggregierte Informationen, wie sie aktuell in Primärsystemen vorliegen, feingranular strukturiert ab. Die CDA Level 3 Dokumente können geparst werden und es kann eine Auswertung bis hin zu den in den einzelnen CDA Level 3 Dokumenten dokumentierten granularen Informationen durchgeführt werden Umsetzungsstufe 6: Austausch granularer Informationen als CDA Level 3 Dokumente Ein CDA Level 3 Dokument muss nicht zwangsweise ein klinisches Dokument/aggregierte Informationen abbilden. Es kann auch einzelne granulare Informationen beinhalten (z. B. eine Diagnose), die über Referenzen zu einem klinischen Dokument aggregiert werden können. Beispiel: ein CDA Level 3 Dokument mit dem Dokumententyp Diagnose umfasst eine Diagnose. Dieses CDA Level 3 Diagnose kann einem CDA Level 3 Dokument mit dem Dokumententyp Arztbrief zugeordnet sein. Der Ansatz auch feingranulare Informationen als strukturiertes Dokument (bspw. über die IHE XDS Schnittstellen) zu übermitteln bietet folgende Möglichkeiten: sowohl strukturierte und unstrukturierte Informationen werden über einheitliche Schnittstellen ausgetauscht. Dies Seite 20 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

35 4 Aspekte der Standardisierung reduziert die Schnittstellenkomplexität und verringert die Einstiegshürde, da viele Systemhersteller bereits den etablierten IHE XDS Standard umsetzen. Die Wahl der generischen IHE XDS Schnittstellen begünstigen zudem die Beständigkeit der Schnittstellen und bieten den Systemherstellern Investitionssicherheit. Die Granularität der Auswertung hängt von der Umsetzungsstufe ab und ist auch sehr feingranular möglich. Ein weiterer Ansatz zur Beschreibung der Umsetzungsstufen der Aktenkommunikation wird in den ELGA CDA Implementierungsleitfäden 17 beschrieben. Unter dem Begriff ELGA Interoperabilitätsstufen (EIS) werden dort anhand der Umsetzung von Vorgaben aus den HL7 V3 CDA Level drei Stufen unterschieden. Die erste Stufe umfasst EIS Basic und EIS Structured. Eine Aktenkommunikation in der Stufe muss lediglich einen strukturierten Header umfassen. EIS Basic kann zudem ein Organisationslogo in Level 3 Kodierung einbetten. EIS Structured erweitert EIS Basic mit medizinischen Inhalten. Diese sind jedoch nur textuell beschrieben. Sie können entweder mit Hilfe von XML-Textelementen oder alternativ als PDF in das Dokument integriert werden. Die zweite Stufe ist EIS Enhanced. Aktenkommunikationen in dieser Stufe sind in der Lage Dokumente auszutauschen die einheitlich strukturiert sind. Minimale Anforderungen an diese Stufe sind die obligatorische Umsetzung von CDA Level 2 und die optionale Umsetzung von CDA Level 3. Die drittte Stufe bildet EIS Full Support. Dokumente, die bei dieser Aktenkommunikation ausgetauscht werden, sind ausnahmslos CDA Level 3 Dokumente. Im Vergleich zu EIS sind die im Rahmen des Projekts definierten Umsetzungsstufen detaillierter. So kann die Aktenkommunikation in Projekten genauer beschrieben und Restriktionen in der Aktenkommunikation in Projekten feiner definiert werden. 17 ELGA CDA Implementierungsleitfäden. 2013;1 218 Seite 21 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

36 4 Aspekte der Standardisierung CDA-Templates 18 Wie aus den vorhergehenden Erläuterungen ersichtlich ist, setzt sich ein Dokument aus verschiedenen Komponenten zusammen, die flexibel miteinander kombiniert werden können. Für ein Zusammensetzen der Einzelteile auf den unterschiedlichen Ebenen gibt es detaillierte Baupläne, die in CDA auch Templates oder Schablonen oder auch Muster genannt werden. Template Beschreibung Inhalt Dokument- Template Header-Template Section-Level- Template Entry-Level- Template Datentypen Tabelle 01: CDA-Templates Angabe der benötigten Einzelteile für eine bestimmte Art von Dokument. So legt die Schablone für einen Arztbrief bspw. fest, dass ein Arzt das Dokument für einen anderen Arzt erstellt und somit sowohl eine Anrede und eine Grußformel enthalten sollte. Bei einem einfachen Meldebogen ist letzteres bspw. nicht der Fall. Angabe, wie die größeren Blöcke im Header eines Dokumentes konkret aussehen sollen. So kann hier bspw. geregelt werden, welche Details zu einem Patienten hinterlegt werden können. Angabe, wie ein bestimmter Abschnitt konkret aussehen soll. Hier werden dann bspw. Vorgaben gemacht, dass Diagnosen in einer tabellarischen Form textuell aufbereitet werden sollen, damit sie einheitlich durch ein Stylesheet zur Anzeige gebracht werden können. Des Weiteren kann hier auf die optionale oder verpflichtende Nutzung von Entry-Level-Templates hingewiesen werden. Angabe, wie die Einzelinformationen in strukturierter und kodierter Form hinterlegt werden sollen, damit sie durch ein Programm ausgewertet und weiter verarbeitet werden können. Hier handelt es sich genaugenommen nicht um Templates, sondern um sog. Flavors, welche beschreiben, wie ein Datentyp in einem bestimmten Use Case genutzt werden soll. So kann es bspw. zwei unterschiedliche Ausprägungen für Adressen geben, die vollständige Adresse lässt Straßennamen oder Postfächer zu, der Geburtsort wird auf die Stadt inkl. Land eingeschränkt. Diese Datentypen werden in den drei vorgenannten Arten von Templates genutzt. Festlegung der Header und Section-Level- Templates sowie weiterer Header-Metadaten Patient, Autor, Unterzeichner, weitere Beteiligte,... Anrede, Diagnose, Maßnahme, ICD-Diagnose, Maßnahmen, Scores & Assessments, Meldeanlässe, Verwendung von Namen und Adressen, Telefonnummern,... Templates stellen somit sog. Profile Components dar, sind also selber konkrete Ausprägungen allgemeiner Vorgaben für einen bestimmten Use Case. Derartige Ausprägungen können hierarchisch vorgenommen werden. Nachfolgend sei das einmal an einem Beispiel erläutert Seite 22 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

37 4 Aspekte der Standardisierung Level Hierarchie Inhalt Einschränkung 1 Autor Originäre Spezifikation aus dem CDA- Header 2 Autor allgemein Ausdifferenzierung inklusiver aller Details Keine Anwendung von Datentypen- Flavors 3 Autor Person Reduzierung auf eine Person als Autor Streichung der Auswahlmöglichkeit 3 Autor Gerät Reduzierung auf ein Gerät als Autor Streichung der Auswahlmöglichkeit Tabelle 02: Beispiel für eine Template-Hierarchie Eine weitere wichtige Eigenschaft ist die Feststellung, ob Templates offen oder geschlossen sind, d.h. ob nicht angekündigte Erweiterungen in einer weiteren Hierarchiestufe erlaubt sind oder nicht. Hier gibt es unterschiedliche Vorgehensweisen. So macht es für die Angaben im Header durchaus Sinn, alle notwendigen Details soweit vorzugeben, so dass in Spezialisierungen nur die Auswahlmöglichkeiten gestrichen werden müssen, während für die Angaben im Body nur bedingt möglich ist, alle Eventualitäten vorzugeben DICOM 19 Digital Imaging and Communications in Medicine (DICOM) ist ein offener Standard zur Speicherung und zum Austausch von Informationen im medizinischen Bilddatenmanagement. Diese Informationen können beispielsweise digitale Bilder, Zusatzinformationen wie Segmentierungen, Oberflächendefinitionen oder Bildregistrierungen sein. DICOM standardisiert sowohl das Format zur Speicherung der Daten, als auch das Kommunikationsprotokoll zum Datenaustausch. Fast alle Hersteller bildgebender oder bildverarbeitender Systeme in der Medizin wie z. B. Digitales Röntgen, Magnetresonanztomografie, Computertomografie oder Sonografie implementieren den DICOM-Standard in ihren Produkten. Dadurch wird im klinischen Umfeld die Interoperabilität zwischen Systemen verschiedener Hersteller ermöglicht. DICOM ist auch die Grundlage für die digitale Bildarchivierung in Praxen und Krankenhäusern (Picture Archiving and Communication System, PACS) DICOM-SR Sogenannte DICOM-SR-Dokumente (DICOM Structured Reporting) enthalten wie auch CDA strukturierte medizinische Befundberichte, die zwischen unterschiedlichen Systemen ausgetauscht werden können. Eine Transformation von DICOM-SR zu CDA ist möglich.referenzen/literatur hierzu: DICOM Basics, Herman Oosterwijk, O Tech, ISBN DICOM-Homepage mit downloadbaren Standards: Seite 23 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

38 4 Aspekte der Standardisierung sluis.pdf 4.3 Implementierungsleitfäden Standardisierungsorganisationen erarbeiten Spezifikationen, die internationale Gültigkeit haben und eingesetzt werden sollen. Um die Akzeptanz der so erarbeiteten Standards sicherzustellen, ist nicht nur die Durchführung von Abstimmungsverfahren, die nachfolgend beschrieben sind, notwendig. Die Standards selber enthalten dadurch aber auch relativ viele Freiheitsgrade, die durch die Anforderungen der einzelnen Benutzergruppen und Hersteller eingebracht worden sind. Mitunter sind diese Freiheitsgrade auch durch die unterschiedlichen internationalen Gegebenheiten bedingt. Für ein konkretes Szenario (Use Case) sind diese Freiheitsgrade jedoch äußerst hinderlich, weil sie von den eigentlichen Anforderungen für diesen speziellen Fall ablenken. Folglich sind diese Freiheitsgrade möglichst zu eliminieren. Dies geschieht über konkretisierte Vorgaben unter Berücksichtigung des Szenarios. Realisiert wird dies über spezielle Dokumente, die den zu nutzenden Standard analysieren und dabei die notwendigen Elemente mit den Konformitätskriterien genau beschreiben und unnötige Elemente ausblenden (verbieten). Ein solches Dokument wird dann Implementierungsleitfaden genannt. Neben den genauen Angaben zu den Details des zu nutzenden Standards enthält er aber auch Zusatzinformationen zum Use Case, Beispiele, Abläufe, Hintergrundinformationen, Referenzen, etc. 4.4 Abstimmungsverfahren (Ballotierung) Standardisierungsorganisationen verabschieden Spezifikationen über eine sogenannte Ballotierung. Darunter ist ein geregeltes Abstimmungsverfahren zu verstehen, an dem man sich beteiligen kann. Das Ziel hierbei ist es, einen Konsens herzustellen. Zunächst werden die Spezifikationen (gemeinschaftlich) erstellt und anschließend in den Arbeitsgruppen vorgestellt und diskutiert. Sobald diese Spezifikation eine gewisse Reife besitzt bzw. als fertig gestellt gilt, wird sie zum Ballot gegeben. Hierunter ist eine angekündigte Zeitspanne zu verstehen, in der die Spezifikation bereitgestellt wird und man die Gelegenheit hat, diese aufmerksam zu prüfen und Kommentare zu verfassen. Diese Ballots müssen mindestens 4 Wochen im Voraus angekündigt werden und eine Laufzeit von 30 Tagen haben. Meistens stehen diese Zeiträume ein Jahr im Voraus fest. Zum Ende der Abstimmungsperiode, zu der man sich rechtzeitig anmelden muss, folgt die Aufforderung zu Stimmabgabe. Seite 24 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

39 4 Aspekte der Standardisierung Hierzu gibt es drei Möglichkeiten: Enthaltung affirmative: man stimmt der Spezifikation zu negative: man lehnt die Spezifikation ab, allerdings sind dann Begründungen mitzuliefern Aufzählungsliste 06: Die drei Möglichkeiten der Stimmabgabe zu Ballots Damit eine Spezifikation als angenommen gilt, muss es eine Mindestbeteiligung geben (Größe des sog. Ballot-Pools) Rückläufer (Mindestanzahl an Antworten) vom Zielstatus (DSTU, Normative, Comment Only) abhängige Anzahl an positiven zu negativen Stimmen Aufzählungsliste 07: Annahmevoraussetzungen einer Spezifikation Als letzter Schritt sind alle Kommentare zu bearbeiten und dem Einsender ein Feedback zu übermitteln. Weitere Details zum Verfahren von HL7 International sind unter dem Link zu finden. 4.5 Formen der intersektoralen Kommunikation Bei der intersektoralen Kommunikation unterscheidet man zwischen verschiedenen Kommunikationsformen, je nachdem, ob der Empfänger bekannt ist oder nicht. Manche Umsetzungen unterscheiden noch etwas genauer und zwar ob gegebenenfalls nur der Empfängerkreis bekannt ist Adressierte Kommunikation Falls der Empfänger bekannt ist, spricht man von einer adressierten Kommunikation. In dem Fall wird die Kommunikation zwischen einem Sender und einem oder mehreren genau festgelegten Empfängern durchgeführt. Im medizinischen Bereich, ist der Entlassbrief ein bekanntes Anwendungsbeispiel für eine adressierte Kommunikation. Hier steht der Empfänger bereits im Briefkopf des Entlassbriefes und somit auch als elektronischer Empfänger fest. Der normale -Verkehr ist ebenfalls eine adressierte Kommunikation Ungerichtete Kommunikation Bei der ungerichteten Kommunikation steht der Empfänger zum Zeitpunkt der Erstellung der medizinischen Dokumente noch nicht fest. Der Empfänger ergibt sich erst aus dem weiteren Behandlungsverlauf des Patienten und dieser kann während einer Behandlung durch die entsprechende Berechtigungsvergabe seitens des Patienten auf die Dokumente zugreifen. Seite 25 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

40 4 Aspekte der Standardisierung Gerichtete Kommunikation Neben der adressierten und der ungerichteten Kommunikation wird noch den Begriff der gerichteten Kommunikation verwendet. In dem Fall steht zwar die Personengruppe fest, aber nicht explizit ein konkreter Empfänger. Es ist somit eine Mischform aus adressierter und ungerichteter Kommunikation. Ein Beispiel für solch eine gerichtete Kommunikation ist die Überweisung an eine Fachabteilung oder das erezept. Dadurch, dass der Patient die freie Arztwahl/Apothekerwahl hat, steht der Empfänger des Dokumentes zum Zeitpunkt der Erstellung noch nicht exakt fest, obwohl der Verwendungszweck schon die Empfängergruppe definiert. Alle drei Kommunikationsformen lassen sich technisch über ein Aktensystem abbilden. Wenn wir von einer einrichtungsübergreifenden Akte sprechen, handelt es sich in der Regel um eine ungerichtete Kommunikation, da sich die Empfänger der Dokumente erst im weiteren Behandlungsverlauf ergeben. Seite 26 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

41 5 Rahmenbedingungen 5 Rahmenbedingungen In diesem Kapitel werden die Annahmen und Festlegungen für die eepa beschrieben. 5.1 Grundlegende Festlegungen Ein Patient kann zu einem Zeitpunkt nur eine eepa in einer Affinity Domain haben. Der Patient entscheidet sich nach der Beratung durch einen Health Professional durch Opt-In für das Anlegen seiner eepa. Die Berechtigung für den Zugriff auf die Dokumente in der Akte erfolgt über mehrere Stufen: die Rolle des Akteurs (z. B. Arzt, Aktenmoderator, Patient), den Behandlungsvertrag, den der Patient mit der Gesundheitseinrichtung abschließt sowie die Filterkriterien für die Sicht des Gesundheitsdienstleisters auf die Akte, die der Patient zum Beginn der Behandlung definiert und die in einer Policy hinterlegt werden. Die für die Berechtigung ergänzend wirksamen Filterkriterien legt der Patient bei der Aufnahme in der Gesundheitseinrichtung oder vorab über das Patientenportal fest. Folgende Kriterien (Und- Verknüpfung) kommen dabei zur Anwendung: Gesundheitsdienstleister: Es sollen nur von ausgewählten Einrichtungen eingestellte Dokumente sichtbar sein. Dokumententyp: Es sollen nur Dokumente ausgewählter technischer Typen freigegeben werden. Medizinisches Fachgebiet der Dokumente: Es sollen nur Dokumente ausgewählter medizinischer Fachbereiche sichtbar sein. Zeitraum: Es wird ein Zeitpunkt in der Vergangenheit festgelegt, ab dem die Dokumente, die ab diesem Zeitpunkt erstellt wurden, zum Zugriff freigegeben werden. Das Ende des Zeitraums ergibt sich durch eine allgemein definierte Frist ab dem Zeitpunkt an dem die Berechtigung erstellt wird. Aufzählungsliste 08: Für die Berechtigung ergänzend wirksame Filterkriterien Die diesen Filterkriterien entsprechenden XDS-Metadaten dürfen nicht durch Verschlüsselungsmaßnahmen verdeckt sein. Die Sicht- bzw. Abrufbarkeit bezieht sich für den Standardanwender nur auf die aktuellste Dokumentenversion (AvailabilityStatus approved ). Aktenmoderatoren können die gesamte Versionshistorie von Dokumenten einsehen. Weiterhin legt der Patient explizit fest, ob der jeweilige Gesundheitsdienstleister Dokumente in die Akte einstellen darf. Der Zeitraum, in dem Dokumente eingestellt werden dürfen, ist ebenfalls befristet. Seite 27 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

42 5 Rahmenbedingungen Soll die Zugriffs-Policy verändert werden, wird die bestehende Policy durch eine neue ersetzt. Als übergeordnetes Kriterium für die Sichtbarkeit der Dokumente (höherwertiger als potentiell existierende Berechtigungen durch Zugriffs-Policies) kommt das Sperren einzelner Dokumente oder der gesamten Akte hinzu. Während sich die vom Patienten definierte Berechtigungs-Policy immer auf einen Gesundheitsdienstleister bezieht, gilt das Sperren für alle Teilnehmer mit einigen unten beschriebenen Ausnahmen. Eine Sperrung hat temporären Charakter und gilt bis zur expliziten Aufhebung durch einen berechtigten Akteur. Für das Sperren und Entsperren von Dokumenten gilt: Durch die Sperrung wird ein Dokument für alle Aktenteilnehmer mit Ausnahme des die Sperrung veranlassenden Akteurs sowie des Aktenmoderators unsichtbar. Dies bedeutet, dass ein gesperrtes Dokument weder in den Suchergebnissen erscheint, noch abrufbar ist. Eine Sperrung ist reversibel und kann nur durch den Teilnehmer wieder aufgehoben werden, der die Sperrung veranlasst hat. Eine Sperrung kann entweder durch den Patienten bzw. den durch ihn beauftragten Aktenmoderator oder durch die Institution, durch die das Dokument erstellt wurde, erfolgen. Aus technischer Sicht erfolgt die Sperrung ausschließlich durch Erstellung von speziellen Zugriffspolicies, die den Teilnehmern den Zugriff auf gesperrte Dokumente verweigern. Durch das Berechtigungssystem werden die entsprechenden Dokumente somit als gesperrt gekennzeichnet. Die Sperrung eines Dokumentes betrifft auch Vorgänger-Versionen dieses Dokumentes. Für das Sperren und Entsperren der gesamten Akte gilt: Durch die Sperrung wird die Akte des Patienten für alle Akteure, mit Ausnahme des Patienten selbst, nicht mehr auffindbar. Somit können keine Dokumente mehr gelesen oder registriert werden. Die Sperrung und Entsperrung der Akte erfolgt selbstständig durch den Patienten oder in seinem Auftrag durch den Aktenmoderator. Da der Aktenmoderator den Patienten bei der Klärung evtl. Ungereimtheiten in der Akte unterstützen soll, kann der Patient ihn beim Sperren der Akte von der Sperrung ausnehmen. Um den Zugriff auf einzelne Dokumente oder die gesamte Akte für die Zukunft zu unterbinden, erfolgt das Löschen. Das Löschen ist irreversibel. Für das Löschen von Dokumenten gilt: Löschen bezeichnet einen starken Patientenwillen, der besagt, dass Dokumente endgültig und unwiederbringlich aus der Akte entfernt werden sollen. Die Löschung erfolgt auf Wunsch des Patienten durch den Aktenmoderator. Die Einwilligung zum Löschen des Dokumentes ist zu dokumentieren. Für das Löschen der Akte gilt: Der Patient will dauerhaft und endgültig nicht mehr an der Akte teilnehmen. Das Löschen der Akte erfolgt auf Wunsch des Patienten durch den Aktenmoderator. Nach Durchführung einer Beratung ist der Aktenmoderator verpflichtet, dem Wunsch des Patienten auf Aktenlöschung nachzukommen. Die Einwilligung zum Löschen der Akte ist zu dokumentieren. Das Löschen der Akte ist nicht reversibel. Wenn der Patient später wieder eine Akte wünscht, wird mit einer Seite 28 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

43 5 Rahmenbedingungen leeren Akte begonnen. Ausgenommen von der Löschung sind Audit-Logs sowie patientenidentifizierende Daten, die nur zu datenschutzrechtlichen oder strafrechtlichen Zwecken genutzt werden dürfen. Zur sachlogischen Strukturierung der Akte können Ordner verwendet werden, denen die Dokumente zugeordnet werden. Sie haben aber keine Funktion für die Zugriffsberechtigung. Akteure die berechtigt sind Dokumente in der jeweiligen Akte anzulegen, sind auch berechtigt Ordner anzulegen. Weiterhin sind sie berechtigt, Dokumente die sie bzw. ihre Organisation erstellt hat, beliebigen Ordnern zuzuordnen. Der Aktenmoderator darf alle Dokumente allen Ordnern zuordnen. Die Abbildung von Bereichen für patientengeführte Dokumente oder Notfalldokumente innerhalb der Akte erfolgt nicht über Ordner, sondern über Dokumenten-Metadaten (classcode). Die Auswahl oder Ausblendung dieser Aktenbereiche erfolgt über entsprechende Filterkriterien bei der Erstellung von Berechtigungs-Policies durch den Patienten oder bei der Suche nach Dokumenten in der Akte durch beliebige berechtigte Akteure. Ordner innerhalb der Akte werden keinem dieser Aktenbereiche zugeordnet. So ist es möglich, dass einem Ordner sowohl arztgeführte als auch patientengeführte Dokumente zugeordnet werden. Wenn z. B. ein Arzt keine vom Patienten eingestellten Dokumente sehen will, kann er sie über eine entsprechende Filterfunktion ausblenden. Die Laufzeit einer Akte kann von der Geburt bis zum Tod des Patienten und darüber hinaus reichen. Hierbei ist auch ein mehrfacher Wechsel des Aktensystems bzw. Aktensystemanbieters, unterstützt durch entsprechende Export- und Importprozesse, möglich. Die Akte kann mit der Geburt des Kindes angelegt werden. Die ersten einzustellenden Dokumente entsprechen in der Regel den Kinderuntersuchungsheften 1-x, welche auch Untersuchungen aus dem Mutterpass beinhalten. Für weitere relevante Daten des Kindes, die vor der Geburt in der Akte der Mutter gespeichert wurden, ist ein Prozess zur Übertragung in die Akte des Kindes zu definieren. Diese Aufgabe könnte der Aktenmoderator durchführen. Bis zu einem gesetzlich festzulegenden Alter vertreten die Eltern (gesetzliche Vertreter) die Belange des Kindes. Der Umgang mit der Akte nach dem Tod des Patienten ist durch den Aktensystembetreiber oder den Gesetzgeber organisatorisch zu regeln und dem Patienten vor der Einrichtung der Akte zur Kenntnis zu bringen. In der Einverständniserklärung, die der Patient beim Anlegen der Akte abgibt, bestimmt er auch wie nach seinem Tod mit der Akte verfahren werden soll. Mögliche Alternativen bestehen in der sofortigen Löschung der Akte nach dem Tod des Patienten oder der Bevollmächtigung eines Dritten, der die Akte bis zu einer maximalen, durch den Gesetzgeber oder den Aktensystembetreiber definierten, Aufbewahrungsfrist nach dem Tod des Patienten weiterführen kann. Seite 29 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

44 5 Rahmenbedingungen Das sofortige Löschen der Akte nach dem Tod des Patienten ist möglich, da die eepa keine Primärdokumentation ist und keine gesetzlichen Aufbewahrungsfristen gelten. Andererseits kann die Einsichtnahme in Patientenakten nach dem Tod des Patienten, neben der Aufdeckung von Behandlungsfehlern auch für die Fragestellung, ob der Verstorbene zu einem bestimmten Zeitpunkt noch geschäfts- oder testierfähig war, von Bedeutung sein. Wenn ein Patient die Einsichtnahme durch Dritte oder Erben wünscht, sollte er dieses zu Lebzeiten in einer Patientenverfügung oder letztwilligen Verfügung bestimmen. Hierdurch wird ein Konflikt bzgl. der Rechtspositionen Recht des Angehörigen oder Erben auf Akteneinsicht einerseits und Verschwiegenheitspflicht des Arztes andererseits vermieden. Dieses gilt für Patientenakten im Allgemeinen und sollte also auch für einrichtungsübergreifende Elektronische Patientenakten anwendbar sein. In der Einwilligungserklärung, die der Patient vor der Einrichtung seiner eepa abgibt, kann dieser Punkt bereits berücksichtigt werden. Ob die einrichtungsübergreifende Patientenakte in diesem Kontext den gleichen Stellenwert wie Patientenakten in Primärsystemen haben kann, ist sicherlich vom Nutzungsgrad der Akte abhängig; sie kann einen Gesamtüberblick über den Krankheitsverlauf und die durchgeführten Behandlungen geben, zumindest aber Hinweise, bei welchen Leistungserbringern ggf. ausführlichere Unterlagen vorhanden sind. Auch für Forschungszwecke kann es wichtig sein, komplette Patientenakten mit Todesursache zur Verfügung zu haben, die, wenn der Patient zustimmt, anonymisiert ausgewertet werden können. Die Beantwortung der Frage, wie das Aktensystem bzw. der Aktensystembetreiber vom Tod des Patienten erfährt und ob die Akte unter definierten Bedingungen automatisch oder manuell durch den Aktenmoderator gelöscht wird, ist vom Betreibermodel des Aktensystems abhängig. Wenn durch organisatorische Maßnahmen nicht sichergestellt ist, dass der Tod des Patienten dem Aktensystem immer bekannt wird, sind Fristen festzulegen, nach denen eine Akte gelöscht wird, wenn keine Nutzung mehr erfolgt. Z. B. könnte eine Löschung erfolgen, wenn der Aktenbetrieb nach mehrfacher Aufforderung innerhalb festgelegter Fristen durch den Patienten nicht bestätigt wird. Auch eine vorausgehende Sperrung der Akte ist denkbar. 5.2 Akteure und Rollen Dieses Kapitel beschreibt die unterschiedlichen Akteure im Zusammenhang mit der eepa, sowie die daraus abgeleiteten Rollen und Rechte im eepa-system. Unter einem Akteur versteht man im Allgemeinen den Urheber einer Handlung. Im Speziellen versteht man darunter Elemente, die mit einem System (hier: der eepa) interagieren. Diese Elemente können sowohl Menschen, z. B. ein Arzt, als auch IT-Systeme, z. B. ein KIS sein. Seite 30 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

45 5 Rahmenbedingungen Aus dem Ablauf der ebpg-gesamtstory ergeben sich in Bezug auf die eepa folgende Akteure: Patient Hausarzt Niedergelassener Facharzt (Gastroenterologe) Niedergelassener Facharzt (Radiologe) Niedergelassener Facharzt (Pathologe) Aufnahmekraft (Krankenhaus) Sozialdienst (Krankenhaus) Stationsarzt Primärsystem (PVS) Primärsystem (KIS) Aufzählungsliste 09: Akteure der eepa Unterschiedliche Akteure haben in Bezug auf die Informationsobjekte in der eepa unterschiedliche Rechte. Zum Beispiel hat ein Patient das Recht, alle Dokumente in der eepa zu lesen, ein Health Professional kann aber nur die von seiner Organisation eingestellten Dokumente einsehen sowie jene, für die er vom Patienten explizit berechtigt wurde. Für eine bessere Administrierbarkeit der Rechte sind diese in sogenannten Rollen gebündelt. Eine Rolle beschreibt alle Rechte bezogen auf die unterschiedlichen Informationsobjekte der eepa, z. B. das Lesen/Schreiben/Löschen von Dokumenten. Einem Akteur können dann eine oder mehrere Rollen zugewiesen werden. Mit dem oben beschriebenen Berechtigungskonzept (detaillierte technische Beschreibung siehe unten) können spezifische Anforderungen flexibel umgesetzt werden. In Anlehnung an 291a SGB-V (Zugriff auf medizinische Daten wie Befunde, Diagnosen, usw. einer Elektronischen Patientenakte nach Absatz 3 Satz 4) werden folgende Rollen vorgeschlagen: Die Rolle Health Professional (Heilberufe) umfasst alle Ärzte, Zahnärzte, Apotheker und Psychotherapeuten. Als Health Professional Assistance (berufsmäßige Gehilfen, medizinische Assistenzberufe) werden die Gesundheitsfachberufe verstanden, die unter ärztlicher Aufsicht ausgeführt werden. Beispiele sind: Aufnahmekraft, Arzthelferin. Der Aktenmoderator stellt eine besondere Rolle dar, da sie sowohl die verwaltungstechnische als auch die medizinisch beratende Kompetenz in sich vereinigt. Ein Patient kann einen Health Professional oder eine Organisation zum Aktenmoderator bestimmen. Es gibt zur eepa eines Patienten zu einem Zeitpunkt nur einen Aktenmoderator. Durch Bestimmung eines neuen Aktenmoderators durch den Patienten wird der bestehende Aktenmoderator ungültig. Der erste Aktenmoderator ist die Organisation oder der Health Professional von der/dem die Akte angelegt wird. Wählt der Patient eine Or- Seite 31 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

46 5 Rahmenbedingungen ganisation als Aktenmoderator dürfen alle Health Professional innerhalb dieser Organisation stellvertretend für diese die Aktenmoderation durchführen. Ein Health Professional kann sich im ebpg-system in der Rolle Health Professional oder, wenn er oder seine Organisation vom Patienten als Aktenmoderator bestimmt wurde, in der Rolle Aktenmoderator anmelden. Beispiel: Die Praxis eines niedergelassenen Arztes wird als Institution vom Patienten als Aktenmoderator berechtigt. Der Arzt ist im Normalfall der einzige Health Professional, der die Aktenmoderation durchführt. Als Sonderfall käme z. B. eine Urlaubsvertretung als weiterer Berechtigter hinzu. Hätte in diesem Beispiel der Patient nicht die Institution, sondern den Arzt als Aktenmoderator bestimmt, müsste der Patient im Bedarfsfall den als Urlaubsvertretung agierenden Health Professional als Aktenmoderator bestimmen und zu einem späteren Zeitpunkt den bisherigen Aktenmoderator wieder einsetzen. Der Aktenmoderator wird vom Patienten durch eine schriftliche Einwilligungserklärung festgelegt. Mit dieser Einwilligungserklärung des Patienten kann sich der Gesundheitsdienstleister als Aktenmoderator im eepa-system eintragen. Der Aktenmoderator handelt nur in Abstimmung mit dem Patienten, den er über die medizinischen Konsequenzen der gewünschten Änderungen in seiner Akte berät. Der Aktenmoderator hat Zugriff auf alle Ordner und Dokumente in der Akte des Patienten und kann die Inhalte aller Dokumente einsehen. Der Aktenmoderator berät den Patienten bei der Sperrung, Entsperrung und Löschung von Dokumenten, sowie der ganzen Akte und führt diese Aktionen auch durch. Die Rolle Notfallbehandler wird, im Unterschied zu den anderen Rollen, vom Patienten keinem Akteur direkt zugewiesen, sondern ermöglicht jedem für das Aktensystem als Notfallbehandler registrierten Akteur im Notfall den Zugriff auf die notfallrelevanten Daten der entsprechenden Person. Der Patient kann generell dem Zugriff auf seine Notfalldaten zustimmen oder ihn verweigern. Die Rechtmäßigkeit des Notfallzugriffs kann durch die Protokollierung und ggf. die automatische Benachrichtigung des Patienten nach einem Zugriff kontrolliert werden. In Anlehnung an 291a SGB-V sind Notfalldaten medizinische Daten die für die Notfallversorgung erforderlich sind. Die für die Notfalldaten auf der EGK festgelegen Zugriffsrechte werden hier entsprechend auf Notfalldokumente in der Patientenakte angewendet. Auf diese Daten sollen neben Ärzten, Zahnärzten, Psychotherapeuten, Apothekern und deren berufsmäßigen Gehilfen unter entsprechender Aufsicht auch Angehörige eines anderen Heilberufs, der für die Berufsausübung oder die Führung der Berufsbezeichnung eine staatlich geregelte Ausbildung erfordert zugreifen können. Hierzu gehören z. B. auch Rettungsassistenten. Da der Personenkreis über die den Rollen Health Professional und Health Professional Assistance zugeordneten Personen hinausgeht, wird eine separate Rolle für den Notfallzugriff vorgesehen. Der Zugriff auf Notfalldokumente von Patienten, auf die ein Akteur im Regelbetrieb keinen Zugriff hat, ist nur in der Rolle Notfallbehandler zulässig. Aus Sicht der Rollen Health Professional, Aktenmoderator, Seite 32 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

47 5 Rahmenbedingungen Health Professional Assistance und Patient sind Notfalldokumente Dokumente, die den üblichen Zugriffsberechtigungen unterliegen. Die Rolle Patient wird vom Patienten selbst, seinem gesetzlichen Vertreter (z. B. Eltern, Betreuer) oder einem vom Patienten selbst bestimmten Vertreter wahrgenommen. Vertreter des Patienten müssen auch im eepa-system registriert sein. Selbstständig agierende Gesundheitsfachberufe (z. B. Logopäden, Ergotherapeuten, Diätassistenten) und Gesundheitshandwerker (z. B. Augenoptiker, Orthopädiemechaniker) werden zunächst mit Ausnahme des Notfallzugriffs für den Zugriff auf die Akte nicht berücksichtigt, können aufgrund des flexiblen Rollen-Rechte-Designs aber leicht ergänzt werden. Im Folgenden sind die Rechte der einzelnen Rollen bezogen auf die verschiedenen Aktenfunktionalitäten aufgeführt. Hierbei ist zu beachten: In den Tabellen ist immer der ausführende Akteur genannt, auch wenn die Entscheidung für die Aktion die des Patienten ist. So handelt z. B. der Aktenmoderator immer nur im Auftrag bzw. in Abstimmung mit dem Patienten und ein Health Professional registriert sich als Aktenmoderator aufgrund einer schriftlichen Erklärung des Patienten. Ist der Patient in der Matrix eingetragen, bedeutet dieses, dass der Patient die Aktion selbstständig über ein Patientenportal oder ein Patiententerminal in einer Gesundheitsorganisation durchführen kann. Abweichende Konventionen sind in konkreten Projekten selbstverständlich zulässig. Die folgenden Aufstellungen sind aber als Best Practice Empfehlungen zu verstehen Rollen und Rechte auf Aktenebene Rolle / Recht Health Professional Aktenmoderator Akte anlegen Aktenmoderat or bestimmen Ak- ten- Attribute lesen Aktenattribute ändern Akte sper ren Akte entsp erren Akte lösch en Zugriffs berechti gung erteilen Zugriffsberechtig ung entziehen Dokume ntenli ste abrufen X X X X X X X X X X X X X X Health Professional X X X X X Assis- tance Patient X X X X X Tabelle 03: Rollen und Rechte auf Aktenebene Seite 33 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

48 5 Rahmenbedingungen Rollen und Rechte auf Ordnerebene Rolle / Recht Ordner erstellen Ordner löschen Ordnerliste abrufen Ordner- Attribute ändern Dokument- Ordner- Zuordnung erstellen Dokument- Ordner- Zuordnung entfernen Health Professional X X *2) X X *2) X *1) X *1) Aktenmoderator X X X X X X Health Professional Assistance X X*2) X X*1) X*1) Patient X X *4) X X *4) X *3) X *3) *1) nur wenn die eigene Organisation Eigentümer des Dokumentes ist *2) nur wenn die eigene Organisation Eigentümer des Ordners ist *3) nur wenn der Patient Eigentümer des Dokumentes ist *4) nur wenn der Patient Eigentümer des Ordners ist Tabelle 04: Rollen und Rechte auf Ordnerebene Rollen und Rechte auf Dokumentenebene Rolle / Recht Dokume nt einstellen Dokument abrufen Dokumente nhistor ie abrufen Dokument aktualisieren Dokument sperren Dokument entspe rren Health Professional X X X *1) X *1) X *1) Dokument löschen Notfalldokument abrufen Aktenmoderator X X X X X X X Health Professional Assistance X X X*1) Notfallbehandler X Patient X X X *2) X X *1) nur wenn die eigene Organisation Eigentümer des Dokumentes ist *2) nur wenn der Patient Eigentümer des Dokumentes ist Tabelle 05: Rollen und Rechte auf Dokumentenebene Seite 34 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

49 5 Rahmenbedingungen 5.3 Weiterführende Aspekte Einheitliches Fundament für Aktensysteme Da zurzeit in Deutschland keine Präferenz für die flächendeckende Einführung einer elektronischen Gesundheitsakte nach einem der beschriebenen Aktenkonzepte (EFA, eepa, PEPA) abzusehen ist, werden sich Modell- und Produktivprojekte der verschiedenen Konzepte parallel etablieren. Der ausschlaggebende Grund dafür ist das föderalistische System in Deutschland, welches eine einheitliche Gesetzgebung und Einführung fast unmöglich macht. In Österreich hat man mit der ELGA- Gesetzgebung einen wichtigen Schritt zur Etablierung einer elektronischen Akte erreicht. In Deutschland fehlt dagegen eine zentrale Institution, welche die Rahmenbedingungen für die Hersteller definiert. Offen ist auch die Frage nach der generellen Nutzung solcher Systeme durch Patienten und Ärzte. Es gibt zurzeit weder gesetzliche Vorgaben, noch eine Bonus- oder Malusregelung durch Gesetzgeber oder Krankenkassen, so dass die technischen Lösungen die bereits existieren, immer dezentral im Rahmen von Förderprojekten oder Eigeninitiativen von Versorgungsgemeinschaften ins Leben gerufen wurden. Um in der Zukunft sowohl zum Wohle des Patienten als auch aus wirtschaftlichen Überlegungen den zügigen und verlustfreien Austausch von Dokumenten zwischen den Aktensystemen zu gewährleisten, sollten die verschiedenen Aktensystemkonzepte eine möglichst breite technologische Basis haben. Dabei gilt es die fachlichen Anforderungen der verschiedenen Aktensysteme miteinander zu kombinieren. Wichtige fachliche Randbedingungen in denen sich die Aktenkonzepte unterscheiden sind: Lebensdauer (medizinischer Fall oder lebenslange Begleitung eines Patienten), Aktennutzer (Dokumente werden durch einen medizinischen Leistungserbringer und/oder Patient eingestellt, Stichwörter: arztgeführte- oder patientengeführte Akte), Berechtigungskonzepte. Aufzählungsliste 10: Unterscheidungsmerkmale der verschiedenen Aktenkonzepte Dokumente müssen ohne Verlust an Informationen von einem Aktensystem in ein anderes migriert werden können (z. B. beim Wechsel des Aktensystembetreibers, bei der Übernahme von Dokumenten aus einer EFA in eine eepa zur langfristigen Speicherung). Seite 35 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

50 5 Rahmenbedingungen Als gemeinsame Basis für technische und semantische Interoperabilität sind demnach anzustreben: Einheitliches Konzept für das deutsche Gesundheitswesen, welches die verschiedenen Aktensysteme adressiert und auf einem internationalen Standard basiert (Das IHE-D-Cookbook zur einrichtungsübergreifenden elektronischen Bild- und Befundkommunikation nutzt auf deutsche Gegebenheiten angepasste IHE-Profile für alle Aktensysteme.) Einheitliche Dokumente, definiert in sogenannten Implementierungsleitfäden. Diese müssen auf einem internationalen Standard wie CDA und den dazu gehörigen Terminologien und Vokabularien basieren. Aufzählungsliste 11: Gemeinsame Basis für Interoperabilität Um einen Zugriff auf Informationsobjekte über die Grenzen der verschiedenen Aktensystemarten (z. B. Zugriff auf Dokumente in einer EFA bei einer Anfrage an eine eepa) zu ermöglichen, sind weitere Voraussetzungen zu erfüllen: Es muss eine eindeutige Identifikation der Aktennutzer vorhanden sein. Dazu sind den einzelnen Aktensystemen übergeordnete, deutschlandweit koordinierte, zentrale Komponenten notwendig wie z. B. zentrale Verzeichnisdienste der Aktensystemanbieter, der Leistungserbringer und der Patienten. Es müssen einheitliche bzw. kompatible Berechtigungskonzepte (einheitliche Rollen, einheitliche Dokumentenmetadaten zur Berechtigungssteuerung) existieren. Einheitliche, überschaubare Berechtigungskonzepte sind darüber hinaus auch für das Verständnis und damit für die Akzeptanz der Akten bei den Patienten wichtig. Aufzählungsliste 12: Voraussetzungen für den übergreifenden Zugriff auf Informationsobjekte Beispiel: Ein Patient hat eine EFA für einen aktuellen Behandlungsfall und eine lebenslange eepa. Beim Anlegen der EFA hat der Patient die Einwilligung gegeben, dass alle am Behandlungsfall beteiligten Leistungserbringer (die einzeln angegeben werden) auf die Akte zugreifen dürfen. Parallel hat der Patient seinem Internisten, der nicht am EFA-Aktensystem beteiligt ist, über seine eepa den Zugriff auf alle internistischen Dokumente in seiner eepa und anderen Aktensystemen von den Leistungserbringern Krankenhaus A, Krankenhaus B und Krankenhaus C für den Zeitraum <Datum1> bis <Datum2> gegeben. Über den deutschlandweiten Verbund aller Aktensysteme würden dann auch beim Zugriff auf die eepa des Patienten Dokumente des Krankenhauses C in der EFA des Patienten gefunden und das EFA-Aktensystem muss dann mit den Berechtigungskriterien aus dem eepa- System das der Patient nutzt prüfen, ob es Dokumente an das anfragende System weiter geben darf. Hierzu ist es einerseits notwendig, dass sowohl Patienten als auch Leistungserbringer eindeutig identifiziert werden können, andererseits muss z. B. das Konzept internistisches Dokument sowohl in den Metadaten der Dokumente im EFA-Aktensystem, als auch in den Berechtigungsregeln im eepa- System durch dasselbe Codesystem bzw. dasselbe Value Set abgebildet werden. Probleme können sich in einem solchen Szenario ergeben, wenn z. B. das CDA-Header-Attribut confidentialitycode, Seite 36 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

51 5 Rahmenbedingungen das in einem Aktensystem für die Berechtigungssteuerung genutzt wird, in einem andern Aktensystem immer mit dem Standardwert code=n (=normal) besetzt wird. Vergleiche hierzu auch den föderalen, dezentralen Lösungsansatz der Schweiz, beschrieben in den Dokumenten Standards und Architektur Empfehlungen (insbesondere Teil III + IV) von ehealth Suisse Affinity Domain übergreifender Dokumentenzugriff (XCA) Affinity Domains sind eine mögliche technische Entsprechung von Netzwerken von Leistungserbringern, die sich nach regionalen, fachlichen oder wirtschaftlichen Gesichtspunkten zum Austausch von Dokumenten zusammengeschlossen und dieses vertraglich geregelt haben. Am Behandlungsprozess eines Patienten können Leistungserbringer beteiligt sein, die unterschiedlichen Affinity Domains angehören. Um einen vollständigen Zugriff auf die Dokumente eines Patienten, also die Patientenakte(n), zu ermöglichen, ist ein domainübergreifender Zugriff notwendig. Zur Realisierung eines flächendeckenden, domainübergreifenden Betriebs, sowohl gleicher als auch unterschiedlicher Aktensystemtypen (eepa, efa, pepa, ), sind neben den technischen Aspekten auch organisatorische und inhaltliche Festlegungen zu treffen. Ohne eine exakte verbindliche Beschreibung der domainübergreifenden Komponenten, ihrer Schnittstellen sowie der notwendigen Prozesse und Akteure, ist der Datenaustausch zwischen den Affinity Domains nicht zu organisieren. Voraussetzung für den Betrieb sind gesetzliche Regelungen, die o.g. Rahmenbedingungen schaffen und die Rechte und Pflichten der beteiligten Akteure deutschlandweit oder sogar europaweit (vgl. EPSOS, Patient Summary über National Contact Point ) regeln. Auch weitergehende grenzüberschreitende Zugriffe auf Aktensysteme im benachbarten, insbesondere auch deutschsprachigen, Ausland und umgekehrt, sind in die Überlegungen mit einzubeziehen, da in Grenzgebieten auch Leistungserbringer mehrerer Länder von den Patienten in Anspruch genommen werden. Rechtliche Regelungen bieten zudem Sicherheit für privatwirtschaftliche Aktivitäten und forcieren diese. Ob sich der Staat nur als Aufsichtsbehörde sieht oder beim Betrieb einzelner Komponenten selbst mitwirkt, ist im politischen Entscheidungsprozess zu klären. Auch der anonymisierte Zugriff auf Patientendaten für Qualitätssicherungsmaßnahmen und Forschungszwecke ist durch den Gesetzgeber zu regeln. Ausgehend von einem Szenario, bei dem die einzelnen Affinity Domains gleichberechtigt nebeneinander agieren und Dokumente nur einmal im Verbund der Aktensysteme, in der Regel in dem Aktensystem in das sie initial eingestellt wurden, vorhanden sind, werden zentrale Komponenten benötigt deren Einrichtung und Betrieb sicherzustellen ist. Informationsobjekte, die domainübergreifend von mehreren Leistungserbringern bearbeitet werden (shared documents), werden hier nicht betrach- Seite 37 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

52 5 Rahmenbedingungen tet. Ein EPSOS National Contact Point (NPC), der den europaweiten Zugriff auf definierte Patientendaten ermöglicht, sollte auch in das Netzwerk integriert werden. Eine der Basiskomponenten ist die Infrastruktur, die den gesicherten Datenaustausch zwischen den Partnersystemen gewährleistet. Hierzu gehören zentrale Komponenten wie XCA Gateways und übergeordnete PIX Manager (Super PIX) (Detailinformationen siehe Kapitel Technische Spezifikationen ). Zur Bereitstellung einer gemeinsamen Infrastruktur sind unterschiedliche Betreiberkonzepte (auch als Mischform der genannten Alternativen) möglich: Der Betrieb der Infrastruktur wird als hoheitliche Aufgabe gesehen und durch staatliche Behörden und nachgeordnete Dienstleister bereitgestellt. Der Betrieb der Infrastruktur wird an Organisationen der Selbstverwaltung oder andere öffentlich-rechtliche Körperschaften delegiert. Wenn die Bereitstellung einer flächendeckenden Infrastruktur und die Vollständigkeit der Patientenakte keine hohe Priorität haben, sind sicherlich auch privatwirtschaftliche Verträge zwischen einzelnen Aktensystem-/Affinity Domain-Betreibern möglich, um eine partielle Vernetzung zu organisieren. Aufzählungsliste 13: Verschiedene Betreiberkonzepte Betriebswirtschaftliche Betrachtungen, auch aus dem benachbarten Ausland, kommen zu der Einschätzung, dass der Nutzen einrichtungsübergreifender Gesundheitsakten hauptsächlich in einer verbesserten Patientenversorgung liegt, die nur schwer monetär zu bewerten ist. Auch Patienten profitieren nicht gleichermaßen; chronisch kranke und multimorbide Patienten, an deren Behandlung mehrere Leistungserbringer parallel beteiligt sind, haben den größten Nutzen. Da die Finanzierung nicht von diesen Patientengruppen oder ihren Krankkassen allein getragen werden kann, ist die Finanzierung aus verschiedenen Quellen zu erbringen: Steuereinnahmen, insbesondere als Anschubfinanzierung für Investitionen in die Infrastruktur. Der Betrieb ist durch die Nutzer der Aktensysteme zu erbringen. Eine Einzel- Abrechnung auf Anfrage- oder Dokumentenlevel erscheint im Rahmen effizienter Informations-und Administrationsabläufe nicht sinnvoll. Es ist aus zeitlichen und ethischen Gründen nicht zumutbar, dass Arzt und Patient im Behandlungsgespräch zunächst eine Kosten-/Nutzen-Abwägung durchführen, welche Dokumente für die Behandlung relevant sein könnten und aus einem anderen Aktensystem anzufordern sind. Die Kenntnis des Ablageortes der Dokumente ist auch fachlich nicht relevant; aus Sicht des Nutzers gehören alle Dokumente zu einer Akte. Hingegen ist ein mengenbasierter Finanzausgleich zwischen über- und unterproportional angefragten Aktensystemen durchaus möglich und im Rahmen der Deckung der gemeinsamen Infrastrukturkosten zu berücksichtigen. Auch ist zu regeln, wie der Zugriff auf Patientendokumente aufrecht erhalten werden kann, die in einem Aktensystem gespeichert sind, dessen Fortbestand z. B. infolge Insolvenz des Aktensystembetreibers gefährdet ist. Seite 38 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

53 5 Rahmenbedingungen Das SGB V 68 regelt zur Finanzierung einer persönlichen elektronischen Gesundheitsakte folgendes: o Zur Verbesserung der Qualität und der Wirtschaftlichkeit der Versorgung können die Krankenkassen ihren Versicherten zu von Dritten angebotenen Dienstleistungen der elektronischen Speicherung und Übermittlung patientenbezogener Gesundheitsdaten finanzielle Unterstützung gewähren. Das Nähere ist durch die Satzung zu regeln. Das SGB V 67 regelt zur Elektronischen Kommunikation : o (1) Zur Verbesserung der Qualität und Wirtschaftlichkeit der Versorgung soll die papiergebundene Kommunikation unter den Leistungserbringern so bald und so umfassend wie möglich durch die elektronische und maschinell verwertbare Übermittlung von Befunden, Diagnosen, Therapieempfehlungen und Behandlungsberichten, die sich auch für eine einrichtungsübergreifende, fallbezogene Zusammenarbeit eignet, ersetzt werden. o (2) Die Krankenkassen und Leistungserbringer sowie ihre Verbände sollen den Übergang zur elektronischen Kommunikation nach Absatz 1 finanziell unterstützen. Aufzählungsliste 14: Finanzierung der Aktensysteme Um die Zulassung einer Affinity Domain zur Teilnahme am Gesamtsystem zu erlangen, hat der Betreiber den Nachweis zu erbringen, dass er die Regeln bzgl. der Hard- und Softwareanforderungen, insbesondere der Schnittstellen, erfüllt und die notwendigen Prozesse beherrscht. Dies kann im Rahmen eines Zertifizierungsverfahrens nachgewiesen werden. Da für den aktuellen medizinischen Behandlungsfall, insbesondere in Notfallsituationen, der schnelle Zugriff auf alle Dokumente eines Patienten in allen Aktensystemen gewährleistet werden muss, sind hohe technische Anforderungen an Reaktionszeiten und Verfügbarkeit des Basissystems und der Partnersysteme zu stellen. Die Definition von konkreten, messbaren Anforderungen an die Partnersysteme kann auf Basis von Service Level Agreements (SLA) definiert werden. Hier sind neben der Verfügbarkeit und Leistungsfähigkeit der Komponenten auch Vereinbarungen zu Reaktionszeiten zur Störungsbeseitigung, zu Fehlerbehebungszeiten, zu Bereitschaftszeiten von Help Desks für fachliche und technische Fragen, zur Sicherheit des Betriebs und zur Datensicherheit sowie zur Berichterstattung über durchgeführte Maßnahmen zu treffen. Vom Gesetzgeber sind hierfür entsprechende Standardisierungsgremien und Kontrolleinrichtungen zu installieren. Um beim domainübergreifenden Zugriff auf Dokumente den Datenschutz zu gewährleisten, sind die Anfragen an Registry und Repository durch eine Berechtigungskomponente zu filtern. Es dürfen Dokumente nur sichtbar und abrufbar sein, für die der Patient dies explizit erlaubt hat. Seite 39 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

54 5 Rahmenbedingungen Um die Berechtigungssteuerung für den Zugriff auf bzw. die Bereitstellung von Dokumenten zu realisieren, sind verschiedene Konzepte möglich: Der Patient legt in jedem (abgebenden) Aktensystem für einzelne Dokumente oder Dokumentgruppen fest, ob der Zugriff aus einer anderen Domain zulässig ist. Der Patient legt in jedem (zugreifenden) Aktensystem für einzelne Dokumente oder Dokumentgruppen fest, ob der Zugriff auf Dokumente aus einer anderen Affinity Domain zulässig ist. Der Patient hat eine Stamm-Affinity Domain (HomeCommunity) in der die im gesamten Aktensystemverbund gültigen Berechtigungen (Berechtigungsattribute) niedergelegt sind. Ein Patient kann zu einem Zeitpunkt immer nur zu einer Stamm-Affinity Domain gehören. Beim Wechsel, z. B. bedingt durch den Umzug des Patienten, sind die Berechtigungsdaten von der alten in die neue Stamm-Affinity Domain zu transferieren. Die Berechtigungspolicies müssen von jedem beteiligten Aktensystem angefordert und interpretiert werden können. Voraussetzung hierfür ist ein einheitliches Berechtigungskonzept mit einheitlichen Rollen und semantischer Interoperabilität der in den Regeln der Berechtigungspolicies verwendeten Metadaten (z. B. Dokumenttypen, Fachbereichsbezeichnungen). Für den Zugriff auf ein Dokument in einer fremden Affinity Domain erfolgt in dem anfragenden System die Identitätsprüfung des anfragenden Akteurs; die Berechtigungsprüfung ob ein Dokument für den Anfragenden sichtbar und abrufbar ist, erfolgt in der antwortenden Affinity Domain mit Hilfe der Berechtigungspolicies aus der Stamm-Affinity Domain des Patienten 20. Aufzählungsliste 15: Berechtigungssteuerung Aus Sicht des Patienten ist die dritte Lösungsmöglichkeit zu bevorzugen, da sie ihm über alle Aktensysteme hinweg einheitliche Entscheidungen zu Berechtigungsregelungen ermöglicht. Durch Templates zu typischen Berechtigungskonstellationen kann der Patient bei der Administrierung der Berechtigungen unterstützt werden. Diese Lösung erfordert aber auch den weitgehendsten Regelungsbedarf über die verschiedenen Aktensystemtypen. Um den Anspruch des Patienten auf Datentransparenz und Selbstbestimmung zu gewährleisten, ist der Zugang des Patienten zu allen ihn betreffenden Dokumenten sicherzustellen. Dies kann durch einen Portalzugang erfolgen, der idealerweise den Zugriff in allen Affinity Domains ermöglicht. Auch die Definition von Berechtigungen kann über eine solche Portalanwendung realisiert werden. Um die Patientenrechte in Bezug auf die Kontrolle der Zugriffe auf die ihn betreffenden Dokumente zu wahren, sind Prozesse zur affinity-übergreifenden Zusammenführung der Zugriffsprotokollierungen zu installieren und diese z. B. auch über die Portalanwendung zugänglich zu machen. Die Aufbewahrungsfrist der Auditeinträge ist festzulegen. Optional können Patienten auch aktiv über Zugriffe auf ihre Dokumente informiert werden. 20 vgl. hierzu auch: ehealth Suisse, Standards und Architektur, Empfehlungen IV, Kommunikation zwischen Gemeinschaften, Seite 40 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

55 5 Rahmenbedingungen 5.4 Vertragswerke In diesem Kapitel werden Vertragswerke beschrieben, die im Rahmen der Nutzung der eepa eine Relevanz haben Patienteneinwilligung Um den Anforderungen der Datenschützer Rechnung zu tragen, ist es erforderlich, dass der Patient beim Anlegen einer eepa sowie bei Änderung von Zugriffsrechten einer eepa eine Patienteneinwilligung unterschreibt. Es wird zwischen Patienteneinwilligung für die Anlage einer eepa und eine Patienteneinwilligung für den konkreten Zugriff für Gesundheitsdienstleister unterschieden. Nachfolgend wird ein Formulierungsbeispiel für die Patienteneinwilligung für das Anlegen einer eepa aufgezeigt. Patienteneinwilligung für das Anlegen einer einrichtungsübergreifenden Elektronischen Patientenakte Für <Name des Patienten>, <Anschrift>, <Geburtsdatum> Ich bin damit einverstanden, dass für mich eine einrichtungsübergreifende Elektronische Patientenakte angelegt wird. Sie ermöglicht den mich behandelnden Ärzten und unter ärztlicher Aufsicht deren berufsmäßigen Gehilfen (z. B. Krankenpflegepersonal, medizinisches Funktionspersonal) auf Daten zuzugreifen und diese zu Behandlungszwecken zu verarbeiten. Der Zugriff ist im Einzelfall für einen bestimmten Zeitraum zu gewähren und kann jederzeit widerrufen werden. Ein gewährter Zugriff kann optional beschränkt werden auf Dokumente von: bestimmten Gesundheitsdienstleistern, bestimmten medizinischen Fachgebieten, bestimmten Dokumententypen, einem bestimmten Zeitraum. Die einrichtungsübergreifende Elektronische Patientenakte kann jederzeit widerrufen werden. In diesem Fall werden die Inhalte der einrichtungsübergreifenden Elektronischen Patientenakte gelöscht. Dies betrifft nicht die von den Gesundheitsdienstleistern lokal gespeicherten Dokumente. <projektspezifische Ausformulierungen> Ich wurde darüber aufgeklärt, dass die einrichtungsübergreifende Elektronische Patientenakte eine technische Lösung ist, um mehreren behandelnden Ärzten bzw. Institutionen Zugriff auf die relevanten Informationen zu ermöglichen, und mir wurde erläutert, wie sie genutzt wird. Ein entsprechendes Informationsblatt habe ich erhalten und gelesen; den Inhalt dieses Informationsblattes betrachte ich als Bestandteil dieser Einwilligung. Ich bin darüber informiert, dass ich jederzeit Auskunft über die zu meiner Person gespeicherten Daten verlangen kann. Ansprechpartner für die einrichtungsübergreifende Elektronische Patientenakte und alle Fragen des Datenschutzes, der Berechtigungen und der Einsichtnahme ist: <Name der Stelle>, <Anschrift> Ort / Datum / Unterschrift / Stempel Seite 41 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

56 5 Rahmenbedingungen Zusätzlich zur Patienteneinwilligung für die Anlage einer eepa muss es eine weitere Einwilligung für den konkreten Zugriff von Gesundheitsdienstleistern inkl. der ggf. gewünschten Einschränkungen geben. Darüber hinaus muss über die Patienteneinwilligung festgelegt werden, was im Todesfall mit der Akte passiert (vgl. Kapitel 5.1). Eine Ausformulierung dieser Einwilligungserklärung ist juristisch abzustimmen und nicht Bestandteil des Kompendiums. Zur Abgrenzung der eepa zur EFA wird im Kompendium das Muster einer Patienteneinwilligung der EFA dargestellt. Die EFA Einwilligung kann in Kapitel A.6 eingesehen werden. Die technische Umsetzung erfolgt auf Basis des IHE BPPC Providervertrag Dies ist der Vertrag, welchen ein Gesundheitsdienstanbieter (Arzt, Krankenhaus etc.) mit dem Provider des eepa-systems schließt. Empfehlungen zur Berücksichtigung sind: Informationen zu Vertragspartnern o Gesundheitsdienstanbieter, Aktensystemprovider Vertragsinhalte o Leistungsbestimmungen o Verfügbarkeit Aktensystem o Verfügbarkeit Primärsystem als Repository für das Aktensystem o Speicherung der Dokumente im Primärsystem (Link im Akten-Repository) oder physikalische Kopie der Dokumente im Aktensystem Rechte & Pflichten o Verfahren zur Autorisierung von teilnehmenden Patienten und zur Dokumentation der Patienteneinwilligung o Technische Konnektierung Primärsystem / Aktensystem o Unterstützung spezifischer Dokumententypen o Datensicherheit des Providers / Verfahren zur Datensicherheit o Datenschutz des Aktensystems / Verahren zur Sicherstellung des Datenschutzes Preise Vertragslaufzeit, Kündigungsfristen Gewährleistung und Haftung Aufzählungsliste 16: Empfehlung zu Providervertragsinhalten Seite 42 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

57 6 Fallbeispiel und Use Cases 6 Fallbeispiel und Use Cases In diesem Kapitel wird ein Fallbeispiel mit typischen Behandlungsszenarien dargestellt und die für die einrichtungsübergreifende Elektronische Patientenakte relevanten Use Cases werden abgeleitet und in tabellarischer Form beschrieben. 6.1 Referenzprozess / Fallbeispiel Als Grundlage für die im folgenden Kapitel beschriebenen Use Cases dient eine ausführlich dargestellte Gesamtstory die im Projekt entwickelt wurde und die hier in Ausschnitten wiedergegeben wird. Als Fallbeispiel dient die Krankengeschichte von Frau Blautopf, die an einem Kolonkarzinom erkrankt ist. Frau Blautopf wird vom ersten Besuch bei ihrem neuen Hausarzt, dem sie ihre Beschwerden schildert, über die Untersuchungen bei verschiedenen Fachärzten, die Operation im Krankenhaus bis hin zur Planung der Nachsorge begleitet. Bei der folgenden Beschreibung werden die Aspekte, die die Elektronische Patientenakte (eepa) der Patientin betreffen, besonders berücksichtigt und es wird auf die jeweiligen Use Cases im nächsten Kapitel verwiesen. Frau Blautopf ist 56 Jahre alt und lebt mit Ihrem Mann seit einigen Monaten in Berlin. Da sie seit längerer Zeit häufigeren Stuhlgang hat als sonst und auch Blut im Stuhl festgestellt hat, sucht sie einen neuen Hausarzt in Berlin, um die Beschwerden abklären zu lassen. Beim ersten Besuch bei ihrem neuen Hausarzt, Herrn Dr. Meier, führt dieser eine Anamnese durch, bei der er Vorerkrankungen, Lebensgewohnheiten und die aktuellen Beschwerden in seinem Praxisverwaltungssystem (PVS) erfasst. Nach den ersten Untersuchungen sieht Herr Dr. Meier die Notwendigkeit einer umfangreicheren einrichtungsübergreifenden Abklärung und empfiehlt Frau Blautopf die Anlage einer einrichtungsübergreifenden Elektronischen Patientenakte, um allen beteiligten Ärzten einen schnellen und umfassenden Überblick über bereits vorliegende Untersuchungsergebnisse zu ermöglichen. Da Frau Blautopf bisher noch keine einrichtungsübergreifende Elektronische Patientenakte besitzt, wird, nach Absprache mit der Patientin, von Herrn Dr. Meier die Anlage einer eepa veranlasst ( Use Case (UC) Akte anlegen). Hierzu muss die Patientin eine Einwilligungserklärung unterschreiben, die Teil der Akte wird. Mit dieser Einwilligungserklärung erlaubt sie Herrn Dr. Meier das Einstellen von Dokumenten in die Akte und das Abrufen von durch Zugriffsregeln definierten Dokumenten aus der Akte. Mit dem Anlegen der Akte wird Herr Dr. Meier auch zum Aktenmoderator für die Patientenakte von Frau Blautopf. Die Patientin kann aber zu jedem Zeitpunkt einen anderen Health Professional zum Aktenmoderator bestimmen ( UC Aktenmoderator bestimmen). Ein Aktenmoderator hat die Berechtigung alle Dokumente der Patientenakte und deren Inhalte einzusehen und sie in Abstimmung mit dem Patienten zu sperren, zu löschen und anderen Ordnern zuzuordnen sowie auch die gesamte Akte zu sperren und zu löschen ( UC Akte sperren, UC Akte entsperren, UC Akte lö- Seite 43 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

58 6 Fallbeispiel und Use Cases schen, UC Dokument sperren, UC Dokument entsperren, UC Dokument löschen, UC Dokument- Ordner-Zuordnung erstellen, UC Dokument-Ordner-Zuordnung entfernen). Da Herr Dr. Meier eine Darmspiegelung inkl. Gewebeentnahme für notwendig erachtet, überweist er Frau Blautopf an einen Gastroenterologen. Nach Abschluss der Behandlung lädt Herr Dr. Meier das von ihm in seinem PVS erstellte Befund-Dokument in die Elektronische Patientenakte von Frau Blautopf ( UC speziellen Dokumententyp gemäß Dokumenttyptaxonomie einstellen, UC Dokument einstellen). Nach der entsprechenden Vorbereitung (Darmreinigung) begibt sich Frau Blautopf am vereinbarten Termin in die gastroenterologische Praxis Dr. Kaiser. Am Empfang übergibt Frau Blautopf der Assistentin der Ärztin ihre Gesundheitskarte und erstellt mit ihr eine Policy, die der Praxis den Zugriff auf ausgewählte Dokumente in Frau Blautopfs Patientenakte erlaubt und das Einstellen neuer Dokumente regelt ( UC Zugriffsberechtigung erteilen). Die Dokumente können bei Bedarf aus der Akte abgerufen werden ( UC Dokumentenliste abrufen, UC Dokument abrufen). Nachdem Frau Dr. Kaiser die Vorbefunde gesichtet hat, führt sie die notwendigen Untersuchungen durch und dokumentiert sie in ihrem PVS. Nach Abschluss der Behandlung werden die Ergebnisse der Untersuchung, Bild- und Textdokumente, in die eepa von Frau Blautopf eingestellt ( UC speziellen Dokumententyp gemäß Dokumenttyptaxonomie einstellen, UC Dokument einstellen). Um dem Pathologen, dem Frau Dr. Kaiser die Gewebeprobe zur histologischen Untersuchung übergibt, auch den Zugriff auf die eepa zu ermöglichen, wird Frau Blautopf noch gebeten, eine entsprechende Zugriffsberechtigung zu erteilen. Da Frau Blautopf keinen eigenen PC besitzt und auch in der Praxis kein Patiententerminal vorhanden ist, druckt die Assistentin von Frau Dr. Kaiser ein Einwilligungsdokument aus, das Frau Blautopf unterschreibt. Anschließend wird das Einwilligungsdokument eingescannt und in die eepa der Patientin eingestellt, sowie die Policy, die dem Pathologen den Zugriff auf die Akte ermöglicht und auf der Einwilligungserklärung basiert, erzeugt. Im weiteren Behandlungsverlauf werden von weiteren Ärzten und Kliniken Dokumente in die Akte von Frau Blautopf eingestellt und aus der Akte abgerufen. 6.2 Use Cases UC Akte anlegen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Akte anlegen_uc Konkret Für einen Patienten, für den im eepa-system noch keine Akte existiert, soll eine solche angelegt werden. Es wird für einen Patienten eine neue Akte angelegt. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der Patient ist identifiziert und authentifiziert. Seite 44 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

59 6 Fallbeispiel und Use Cases Bezeichnung Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen Akte anlegen_uc 4. Die beteiligten Akteure haben die generelle Berechtigung, eine Akte anzulegen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung eine Akte anzulegen. 6. Der Patient wurde über die Patientenakte umfassend informiert. 7. Die Einwilligungserklärung des Patienten zum Anlegen einer Akte liegt vor. Für den Patienten existiert eine Akte im eepa-system. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Für den Patienten soll eine Patientenakte angelegt werden. Health Professional, Health Professional Assistance Primärsystem eepa-system 1. Der direkte Akteur sendet die Anforderung zum Anlegen an das eepa-system. 2. Das eepa-system plausibilisiert die übergebenen Daten. 3. Das eepa-system prüft, ob nicht bereits eine Akte für den Patienten angelegt ist. 4. Das eepa-system legt die Akte an. 5. Das eepa-system speichert die Einwilligungserklärung in der Akte. 6. Das eepa-system gibt die Daten zur Identifizierung der Akte an den anfordernden Akteur. Transportverschlüsselung der zu übertragenden Daten. In der Einwilligungserklärung werden neben der Zustimmung zur Einrichtung der Akte auch Regelungen zum Umgang mit der Akte nach dem Tod des Patienten getroffen. Wesentliche Alternativen sind die sofortige Löschung der Akte oder die Weiterführung der Akte durch einen vom Patienten bestimmten Dritten für eine begrenzte Dauer. Akte Tabelle 06: UC Akte anlegen Seite 45 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

60 6 Fallbeispiel und Use Cases UC Aktenmoderator bestimmen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanfor- Aktenmoderator bestimmen_uc Konkret Auf Wunsch des Patienten soll die Funktion des Aktenmoderators auf einen Health Professional übertragen werden. Dies kann zum Beispiel durch Aufgabe der Praxis des bisherigen Aktenmoderators oder den Umzug des Patienten notwendig werden. Der Aktenmoderator kann eine Person, die ein Health Professional sein muss, oder eine Organisation sein. Im Falle der Organisation sind alle Health Professionals dieser Organisation zur Ausübung der Aktenmoderation berechtigt. Die Meldung als Aktenmoderators erfolgt durch den Health Professional der neuer Aktenmoderator werden soll, nachdem die schriftliche Einverständniserklärung des Patienten vorliegt. Eine selbstständige Bestimmung des Aktenmoderators durch den Patienten über ein Patientenportal wird nicht vorgesehen, da auch das Einverständnis des Heath Professional für die Übernahme des Mandates als Aktenmoderator vorliegen muss (implizit durch die Meldung). Da es zu einem Zeitpunkt nur einen gültigen Aktenmoderator pro Patient bzw. Patientenakte geben kann, wird der bisherige Aktenmoderator ungültig. Für den Patienten ist ein neuer Aktenmoderator im eepa-system hinterlegt. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der Patient ist identifiziert und authentifiziert. 4. Die Willenserklärung des Patienten zur Bestimmung eines neuen Aktenmoderators liegt vor. 5. Der direkte Akteur muss im eepa-system die generelle Systemberechtigung als Aktenmoderator haben. 6. Die beteiligten Akteure haben die generelle Systemberechtigung, um den Aktenmoderator zu ändern. 7. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, um den Aktenmoderator zu ändern. Es wurde ein neuer Aktenmoderator festgelegt. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Der Patient äußert bei einem Health Professional den Wunsch ihn oder seine Organisation als neuen Aktenmoderator bestimmen zu wollen. Health Professional Primärsystem eepa-system 1. Der direkte Akteur stellt die Anfrage an das eepa-system, ihn als neuen Aktenmoderator einzutragen. 2. Das eepa-system prüft die übergebenen Anfragedaten. 3. Das eepa-system speichert den anfragenden Akteur bzw. seine Organisation als Aktenmoderator. Die Willenserklärung des Patienten wird in der Akte abgelegt. Transportverschlüsselung der zu übertragenden Daten. Seite 46 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

61 6 Fallbeispiel und Use Cases Bezeichnung derungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Aktenmoderator bestimmen_uc Es gibt zu einem Zeitpunkt nur einen gültigen Aktenmoderator. Dies ist der Health Professional, den der Patient zuletzt zum Aktenmoderator bestimmt hat. Beim Anlegen einer neuen eepa wird der anlegende Health Professional oder seine Organisation Aktenmoderator dieser Akte. Berechtigungs-Policy Wie ist zu verfahren, wenn sowohl der Patient als auch der Aktenmoderator verstorben sind? Es ist eine, im Aktenvertrag mit dem Patienten festzulegende, organisatorische Regelung zu treffen. Z. B. könnte eine Ombuds-Stelle installiert werden, die einen neuen Aktenmoderator einsetzt. Tabelle 07: UC Aktenmoderator bestimmen Seite 47 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

62 6 Fallbeispiel und Use Cases UC Akten-Attribute lesen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Akten-Attribute lesen_uc Konkret Neben den in der Akte gespeicherten Ordnern und Dokumenten gibt es Attribute zur Akte. Dies sind im Wesentlichen Daten zum Patienten. Attribute/Metadaten der Akte sollen gelesen werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Die zu lesende Akte ist eindeutig identifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Akten zu lesen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Akte zu lesen. Die Akten-Attribute wurden übertragen. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Der lesende Akteur fordert im Rahmen einer Abfrage, z. B. einer Ordnerliste einer Akte, implizit die Aktenattribute ab. Health Professional, Health Professional Assistance, Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung zum Lesen der Akte an das eepa- System. 2. Das eepa-system prüft, ob die zu lesende Akte vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system überträgt die Akten-Attribute an den anfragenden Akteur. Transportverschlüsselung zwischen Primärsystem und eepa-system. Akte Tabelle 08: UC Akten-Attribute lesen Seite 48 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

63 6 Fallbeispiel und Use Cases UC Akten-Attribute ändern Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Akten-Attribute ändern_uc Konkret Neben den in der Akte gespeicherten Ordnern und Dokumenten gibt es Attribute der Akte. Dies sind im Wesentlichen Patientendaten, die teilweise geändert werden können. Attribute und Metadaten der Akte sollen geändert werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Die zu ändernde Akte ist eindeutig identifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Akten- Attribute zu ändern. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Akten-Attribute zu ändern. Die Akten-Attribute wurden geändert. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Die in den Aktenattributen gespeicherten Informationen haben sich geändert. Aktenmoderator Primärsystem eepa-system 1. Der direkte Akteur sendet die zu ändernden Akten-Attribute an das eepa- System. 2. Das eepa-system prüft, ob die zu ändernde Akte vorhanden ist und plausibilisiert die zu ändernden Daten. 3. Das eepa-system protokolliert die Änderungen. 4. Das eepa-system gibt eine Meldung an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Akte Tabelle 09: UC Akten-Attribute ändern Seite 49 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

64 6 Fallbeispiel und Use Cases UC Akte sperren Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Akte sperren_uc Konkret Die gesamte Akte wird durch den Aktenmoderator auf Wunsch des Patienten (schriftliche Willenserklärung) oder durch den Patienten über das Patientenportal gesperrt. Danach kann außer dem Aktenmoderator in Verbindung mit dem Patienten oder dem Patienten über das Patientenportal kein Akteur mehr auf die Akte zugreifen. Anlass hierfür kann sein, dass der Patient der Ansicht ist, dass sich Dokumente in der Akte befinden die fehlerhaft sind oder fehlerhaft eingestellt wurden und die Nutzung der Akte bis zur Klärung der Sachverhalte nicht mehr genutzt werden soll. Die Sichtbarkeit und Zugreifbarkeit auf eine Akte soll verhindert werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Die zu sperrende Akte ist eindeutig identifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Akten zu sperren. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Akte zu sperren. Die Akte ist für die Benutzung gesperrt und nicht mehr sichtbar. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Der Patient hat den Wunsch, dass seine Akte gesperrt wird. Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung zum Sperren der Akte an das eepa- System. 2. Das eepa-system prüft, ob die zu sperrende Akte vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system sperrt die Akte. Transportverschlüsselung zwischen Primärsystem und eepa-system. Akte Tabelle 10: UC Akte sperren Seite 50 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

65 6 Fallbeispiel und Use Cases UC Akte entsperren Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Akte entsperren_uc Konkret Die gesamte Akte wird durch den Aktenmoderator auf Wunsch des Patienten (schriftliche Willenserklärung) entsperrt. Ein eigenständiges Entsperren der Akte durch den Patienten ist nicht vorgesehen. Die Sichtbarkeit und Zugreifbarkeit auf eine gesperrte Akte soll wieder ermöglicht werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Die zu entsperrende Akte ist eindeutig identifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Akten zu entsperren. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Akte zu entsperren. Die Akte kann von allen berechtigten Akteuren wieder genutzt werden. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Der Patient hat den Wunsch, dass seine Akte wieder entsperrt wird. Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung zum Entsperren der Akte an das EPA-System. 2. Das eepa-system prüft, ob die zu entsperrende Akte vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system entsperrt die Akte. Transportverschlüsselung zwischen Primärsystem und eepa-system. Akte Tabelle 11: UC Akte entsperren Seite 51 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

66 6 Fallbeispiel und Use Cases UC Akte löschen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Akte löschen_uc Konkret Die gesamte Akte wird durch den Aktenmoderator auf Wunsch des Patienten (schriftliche Willenserklärung) gelöscht. Nach erfolgter Beratung, muss der Aktenmoderator dem Willen des Patienten auf Löschung der Akte entsprechen. Das Löschen der Akte erfolgt auch nach dem Tod des Patienten entsprechend den Festlegungen, die er in der Einwilligungserklärung beim Anlegen der Akte gemacht hat. Nach dem Löschen der Akte kann kein Akteur mehr auf die Akte zugreifen. Ausgenommen von der Löschung sind Audit-Logs sowie patientenidentifizierende Daten, die nur zu datenschutzrechtlichen oder strafrechtlichen Zwecken genutzt werden dürfen. Die Akte soll endgültig nicht mehr genutzt werden. UC Dokument löschen 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Die zu löschende Akte ist eindeutig identifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Akten zu löschen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Akte zu löschen. Die Akte ist endgültig nicht mehr nutzbar. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Der Patient hat den Wunsch, dass seine Akte gelöscht wird. Aktenmoderator Primärsystem eepa-system 1. Der direkte Akteur sendet die Anforderung zum Löschen der Akte an das eepa-system. 2. Das eepa-system prüft, ob die zu löschende Akte vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system archiviert die Akte für evtl. datenschutzrechtliche Recherchen und löscht sie aus dem aktuellen Bestand. Transportverschlüsselung zwischen Primärsystem und eepa-system. Realisierungshinweise: Es ist sicherzustellen, dass mit dem Einstellen neuer Dokumente nicht implizit wieder eine Akte angelegt wird. Dokumente werden gelöscht analog zum Use Case Dokument löschen. Verweise in der Registry werden gelöscht. Globale Patienten-Id (XAD PID) des betreffenden Patienten wird in der Registry Seite 52 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

67 6 Fallbeispiel und Use Cases Bezeichnung Informationsobjekte Offene Fragen und Themen Akte löschen_uc gelöscht. Demografische Daten des Patienten werden im PIX Manager gelöscht. Akte Für eine Löschung innerhalb des Repositories gibt es noch keine IHE-Transaktion. ( Change Request an IHE) Tabelle 12: UC Akte löschen UC Zugriffsberechtigung erteilen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request Akteur maschinell Response-Akteur Beschreibung Ablauf Zugriffsberechtigung erteilen_uc Konkret Der Patient erteilt einem Health Professional bzw. dessen Organisation im Rahmen der Erteilung des Behandlungsauftrages die Zugriffsberechtigung für den lesenden Zugriff auf eine Auswahl von Dokumenten aus seiner Akte und ggf. die Berechtigung Dokumente in die Akte einzustellen. Dies erfolgt mit Unterstützung der Empfangskraft in der jeweiligen Behandlungseinrichtung oder selbstständig durch den Patienten über das Patientenportal. Die Policy besteht aus Filterkriterien zur Einschränkung des Zugriffs auf die Dokumente in der Akte bzgl. folgender Kriterien: Einrichtung, die die Dokumente erstellt hat, Dokumententyp, Fachrichtung der die Dokumente zuzuordnen sind, Zeitraum in dem die Dokumente erstellt wurden, Zeitraum in dem die Dokumente einsehbar sind. Der Health Professional kann innerhalb eines festgelegten Zeitraums auf eine durch Filterkriterien spezifizierte Auswahl von Dokumenten aus der Akte des Patienten zugreifen und ggf. Dokumente in die Akte einstellen. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der Patient ist identifiziert und authentifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung, eine ZugriffsPolicy zu erstellen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Zugriffs-Policy zu erstellen. Die Zugriffs-Policy für einen Health Professional, um auf ausgewählte Dokumente in der Akte des Patienten zugreifen zu dürfen und ggf. Dokumente in die Akte einstellen zu dürfen, ist im eepa-system hinterlegt. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Ein Patient will einem Health Professional den Zugriff auf die Dokumente in seiner Akte im eepa-system gewähren. Health Professional, Health Professional Assistance, Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet den Auftrag eine spezifizierte Zugriffs-Policy anzule- Seite 53 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

68 6 Fallbeispiel und Use Cases Bezeichnung Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Zugriffsberechtigung erteilen_uc gen an das eepa-system. 2. Das eepa-system plausibilisiert die übergebenen Auftragsdaten. 3. Das eepa-system legt die Zugangs-Policy an. Transportverschlüsselung zwischen Primärsystem und eepa-system. Zugriffs-Policy Tabelle 13: UC Zugriffsberechtigung erteilen Seite 54 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

69 6 Fallbeispiel und Use Cases UC Zugriffsberechtigung entziehen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Zugriffsberechtigung entziehen_uc Konkret Eine vom Patienten für einen definierten Health Professional erteilte Zugriffsberechtigung soll zurückgenommen oder geändert werden. (Eine Änderung einer Zugriffs- Policy erfolgt durch das Löschen der bestehenden und Neuanlage.) Einem Health Professional soll eine bestehende Zugriffsberechtigung zum Schreiben und/oder Lesen von Dokumenten in einer Akte entzogen werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der Patient ist identifiziert und authentifiziert. 4. Die Akten-ID und die Identität des Akteurs dem die Zugriffsberechtigung entzogen werden soll sind bekannt. 5. Die beteiligten Akteure haben die generelle Systemberechtigung, die Entziehung der Zugriffsberechtigung an das eepa-system weiterzuleiten. 6. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Entziehung der Zugriffsberechtigung an das eepa-system weiterzuleiten. Der entsprechende Health Professional kann nicht mehr auf die Dokumente in der eepa des Patienten zugreifen. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Ein Patient will einem Health Professional den erteilten Zugriff auf die Dokumente in seiner Akte im eepa-system entziehen bzw. das Ablegen von Dokumenten in die Akte widerrufen und beauftragt seinen Aktenmoderator dies auszuführen oder führt es selbst über das Patientenportal aus. Health Professional, Health Professional Assistance, Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet den Auftrag eine spezifizierte Zugriffsberechtigung anzulegen an das eepa-system. 2. Das eepa-system plausibilisiert die übergebenen Auftragsdaten. 3. Das eepa-system speichert die Zugriffsberechtigung. Transportverschlüsselung zwischen Primärsystem und eepa-system. Berechtigungs-Policy Tabelle 14: UC Zugriffsberechtigung entziehen Seite 55 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

70 6 Fallbeispiel und Use Cases UC Ordner erstellen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Ordner erstellen_uc Konkret Um durch eine Gruppierung der Dokumente die Übersichtlichkeit der Patientenakte zu verbessern können Ordner erstellt werden. Es wird ein neuer Ordner in der Akte des Patienten im eepa-system angelegt. Für einen Patienten soll ein neuer Ordner in seiner Akte erstellt werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der Patient ist identifiziert und authentifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Ordner anzulegen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, in der Akte des Patienten einen Ordner anzulegen. Der neue Ordner wurde in die Akte des Patienten eingefügt. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Fachliche Anforderung einen Ordner anzulegen um die Akte zu strukturieren. Health Professional, Aktenmoderator, Health Professional Assistance, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung mit entsprechenden Metadaten an das eepa-system. 2. Das eepa-system plausibilisiert die übergebenen Daten. 3. Das eepa-system prüft, ob für den Patienten eine Akte angelegt ist. 4. Das eepa-system fügt den spezifizierten Ordner in die Akte des eepa- Systems ein. 5. Das eepa-system protokolliert die Einfügung. 6. Das eepa-system gibt eine Meldung an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Ordner Tabelle 15: UC Ordner erstellen Seite 56 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

71 6 Fallbeispiel und Use Cases UC Ordner löschen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Ordner löschen_uc Konkret Ein Ordner kann von dem Akteur der ihn angelegt hat oder vom Aktenmoderator auf Wunsch des Patienten gelöscht werden. Die dem Ordner zugeordneten Dokumente werden nicht gelöscht. Die Gruppierung von Dokumenten durch einen benannten Ordner ist nicht mehr sinnvoll. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der spezifizierte Ordner ist vorhanden. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Ordner zu löschen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung Ordner zu löschen. Der gewünschte Ordner wurde gelöscht. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Ein Ordner soll auf Wunsch des Patienten gelöscht werden. Health Professional, Aktenmoderator, Health Professional Assistance, Patient Primärsystem, Patientenportal eepa-system 1. Der direkter Akteur sendet die Anforderung zum Löschen des Ordners an das eepa-system. 2. Das eepa-system prüft, ob der zu löschende Ordner vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system löscht den benannten Ordner. 4. Die Dateien werden in den Überordner verschoben. Transportverschlüsselung zwischen Primärsystem und eepa-system. Ordner Tabelle 16: UC Ordner löschen Seite 57 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

72 6 Fallbeispiel und Use Cases UC Ordnerliste abrufen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Ordnerliste abrufen_uc Konkret Es wird eine Liste aller Ordner, für die ein Akteur die Zugriffsberechtigung hat, aus dem eepa-system abgerufen. Die Zugriffsberechtigung für einen Ordner ist gegeben, wenn sich in ihm Dokumente befinden, für die der zugreifende Akteur die Zugriffsberechtigung hat. Zusätzlich kann der Umfang der Ordnerliste durch Filterkriterien eingeschränkt werden. Neben den Ordnernamen gehören weitere Attribute des Ordners zum Auskunftsumfang. Der Akteur erhält einen Überblick über die für ihn sichtbaren Ordner eines benannten Patienten. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der Patienten ist eindeutig identifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung, um Ordnerlisten abzurufen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung eine Ordnerliste abzurufen. Die angeforderte Ordnerliste wurde an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Anfrage für eine Ordnerliste. Health Professional, Aktenmoderator, Health Professional Assistance, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung einer Ordnerliste an das eepa- System. 2. Das eepa-system plausibilisiert die übergebenen Anfragedaten. 3. Das eepa-system gibt die Ordnerliste an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Ordnerliste Tabelle 17: UC Ordnerliste abrufen Seite 58 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

73 6 Fallbeispiel und Use Cases UC Ordner-Attribute ändern Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Ordner-Attribute ändern_uc Konkret Es können Attribute eines Ordners, z. B. der Ordnername, durch berechtigte Akteure geändert werden. Ein Akteur ist berechtigt, wenn er als Aktenmoderator agiert oder der Ordner von seiner Organisation angelegt wurde. Attribute/Metadaten des Ordners sollen geändert werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der zu ändernde Ordner ist eindeutig identifiziert. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Ordner- Attribute zu ändern. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Ordner-Attribute zu ändern. Die Ordner-Attribute wurden geändert. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Ein berechtigter Akteur, z. B. ein Aktenmoderator bei der Restrukturierung einer Patientenakte, möchte Attribute eines Ordners, z. B. den Namen, ändern. Health Professional, Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die zu ändernden Akten-Attribute an das eepa- System. 2. Das eepa-system prüft, ob die zu ändernde Akte vorhanden ist und plausibilisiert die zu ändernden Daten. 3. Das eepa-system protokolliert die Änderungen. 4. Das eepa-system gibt eine Meldung an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Ordner Tabelle 18: UC Ordnerattribute ändern Seite 59 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

74 6 Fallbeispiel und Use Cases UC Dokument-Ordner-Zuordnung erstellen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Das benannte Dokument und der Ordner dem das Dokument zugeordnet werden sollen sind im eepa-system vorhanden. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumente Ordnern zuzuordnen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung um das Dokument einem Ordner zuzuordnen. Das benannte Dokument wurde dem benannten Zielordner zugeordnet. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Ein Dokument in der Akte des Patienten soll einem Ordner zugeordnet werden, um durch eine Strukturierung die Übersichtlichkeit der Akte zu verbessern. Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokument-Ordner-Zuordnung erstellen_uc Konkret Ein in der Akte gespeichertes Dokument wird einem Ordner zugeordnet. Durch die Zuordnung der Dokumente zu Ordnern soll die Übersichtlichkeit in der Akte des Patienten verbessert werden. Health Professional, Health Professional Assistance, Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung zum Zuordnen des Dokumentes zu einem Ordner an das eepa-system. 2. Das eepa-system plausibilisiert die übergebenen Auftragsdaten. 3. Das eepa-system führt die Zuordnung des Dokumentes zum angegebenen Ordner durch. 4. Das eepa-system protokolliert die durchgeführte Zuordnung des Dokumentes zum Ordner. 5. Das eepa-system gibt eine Meldung an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Ordner, alle Spezialisierungen des Typs Dokument Tabelle 19: UC Dokument Ordner zuordnen Seite 60 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

75 6 Fallbeispiel und Use Cases UC Dokument-Ordner-Zuordnung entfernen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokument-Ordner-Zuordnung entfernen_uc Konkret Durch die Zuordnung von Dokumenten zu Ordnern soll die Übersichtlichkeit in der Akte des Patienten verbessert werden. Ist die Zuordnung eines Dokumentes zu einem Ordner fachlich nicht mehr sinnvoll, ist diese zu entfernen. Die Zuordnung des in der Akte des Patienten gespeicherten Dokumentes zu einem Ordner soll aufgehoben werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Das benannte Dokument und der Ordner, zu dem die Zuordnung des Dokumentes aufgehoben werden soll, sind im eepa-system vorhanden. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um die Zuordnung von Dokumenten zu Ordnern aufzuheben. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung um die Zuordnung von Dokumenten zu Ordnern aufzuheben. Die Zuordnung des benannten Dokumentes zu dem benannten Zielordner wurde aufgehoben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Diese Zuordnung eines Dokumentes zu einem Ordner ist unter aktuellen Gesichtspunkten nicht mehr sinnvoll. Health Professional, Health Professional Assistance, Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung zur Auflösung der Zuordnung des Dokumentes zu einem Ordner an das eepa-system. 2. Das eepa-system plausibilisiert die übergebenen Auftragsdaten. 3. Das eepa-system führt die Zuordnung des Dokumentes zum angegebenen Ordner durch. 4. Das eepa-system protokolliert die durchgeführte Zuordnung des Dokumentes zum Ordner. 5. Das eepa-system gibt eine Meldung an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Ordner, alle Spezialisierungen des Typs Dokument Tabelle 20: UC Dokumentzuordnung zu Ordner löschen Seite 61 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

76 6 Fallbeispiel und Use Cases UC Dokument einstellen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokument einstellen_uc Abstrakt Ein auf einen Patienten bezogenes Dokument wird von einem berechtigten Akteur in dessen eepa eingestellt. Ein Dokument für einen Patienten wird in seine eepa eingestellt und ist für andere Akteure entsprechend den vom Patienten vergebenen Zugriffsberechtigungen abrufbar. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Das Dokument liegt vor. 4. Die Metadaten zum Dokument liegen vor. 5. Der spezifizierte Dokumenttyp ist gültig. 6. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumente einzufügen. 7. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, das Dokument einzufügen. Das Dokument wurde in die Akte im eepa-system eingefügt und ist für berechtigte Akteure abrufbar. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Dokument-Übermittlungsauftrag im Primärsystem. Health Professional, Aktenmoderator, Health Professional Assistance, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet das Dokument inkl. ggf. notwendiger Metadaten an das eepa-system. 2. Das eepa-system prüft, ob das Dokument schon vorhanden ist. 3. Das eepa-system fügt das Dokument in die Akte ein. 4. Das eepa-system protokolliert die Einfügung. 5. Das eepa-system gibt eine Meldung an den einstellenden Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Alle Spezialisierungen des Typs Dokument Tabelle 21: UC Dokument einstellen Seite 62 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

77 6 Fallbeispiel und Use Cases UC Dokumentenliste abrufen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokumentenliste abrufen_uc Konkret Es wird eine Liste mit für den abfragenden Akteur sichtbaren Dokumenten zu einem oder mehreren vorgegebenen Ordnern oder für die gesamte Akte aus der eepa abgerufen. Ergänzend werden auch Metadaten der Dokumentenordner übertragen. Es können zusätzlich Filterkriterien angegeben werden, um die Dokumentenliste einzuschränken. Ein Akteur will sich einen Überblick über die für ihn sichtbaren Dokumente in der Akte eines Patienten verschaffen. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Die benannten Ordner aus denen die Dokumentenliste erstellt werden soll sind gültig. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumentenlisten abzurufen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung um die Dokumentenliste abzurufen. Die angeforderte Dokumentenliste wurde an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Anfrage für eine Dokumentenliste. Health Professional, Aktenmoderator, Health Professional Assistance, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung einer Dokumentenliste an das eepa-system. 2. Das eepa-system plausibilisiert die übergebenen Anfragedaten. 3. Das eepa-system gibt die Dokumentenliste an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Es ist auch der Aspekt eines affinityübergreifenden Abrufs der Dokumente zu berücksichtigen. Dokumentenliste Tabelle 22: UC Dokumentenliste abrufen Seite 63 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

78 6 Fallbeispiel und Use Cases UC Dokumente abrufen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokumente abrufen_uc Abstrakt Ein oder mehrere spezifizierte Dokumente werden von berechtigten Akteuren aus der eepa abgerufen. Ein oder mehrere Dokumente des Patienten werden aus der eepa abgerufen und stehen im Primärsystem oder Patientenportal zur Verfügung. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der spezifizierte Dokumententyp jedes einzelnen Dokumentes ist gültig. 4. Der eindeutige Schlüssel jedes einzelnen Dokumentes liegt vor. Sie wurden z. B. aus einer Liste der im Behandlungskontext sichtbaren Dokumente selektiert ( Dokumentenliste abrufen_uc). 5. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumente abzurufen. 6. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, die Dokumente abzurufen. Die angeforderten Dokumente wurden an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Dokument-Übermittlungsauftrag im Primärsystem oder Patientenportal. Health Professional, Aktenmoderator, Health Professional Assistance, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet eine Anforderung von Dokumenten an das eepa- System. 2. Das eepa-system prüft, ob das abzurufende Dokument vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system gibt die angeforderten Dokumente an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Es ist auch der Aspekt eines affinityübergreifenden Abrufs der Dokumente zu berücksichtigen. Alle Spezialisierungen des Typs Dokument Tabelle 23: UC Dokument abrufen Seite 64 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

79 6 Fallbeispiel und Use Cases UC Dokumentenhistorie abrufen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokumentenhistorie abrufen_uc Konkret Zu einem in der aktuellen Version vorliegenden Dokument wird eine Liste aller Versionen dieses Dokumentes aus der eepa abgerufen. Diese Funktion steht nur dem Aktenmoderator zur Verfügung. Es wird eine Liste aller Versionen eines Dokumentes aus der eepa des Patienten abgerufen. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Der eindeutige Schlüssel des Dokumentes liegt vor. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um die Dokumentenhistorie abzurufen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung um die Dokumentenhistorie abzurufen. Die angeforderte Dokumentenliste mit allen Versionen des spezifizierten Dokumentes wurde an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Um Ungereimtheiten in der Akte zu analysieren will der Aktenmoderator die Liste der Versionen eines bestimmten Dokumentes einsehen. Aus dieser Liste kann er in einem anschließenden Schritt eine Dokumentenversion auswählen und mit Dokument abrufen_uc dieses Dokument anfordern. Aktenmoderator Primärsystem eepa-system 1. Der direkte Akteur sendet die Anforderung der Dokumentenhistorie zu einem benannten Dokument an das eepa-system. 2. Das eepa-system prüft, ob das spezifizierte Dokument vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system gibt die Dokumentenliste an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Technischer Hinweis: Die Dokumentenhistorie ist die Liste aller Versionen eines Dokumentes, d. h. der neusten Version (Status approved ) und aller alten Versionen (Status deprecated ). Dokumentenliste Tabelle 24: UC Dokumentenhistorie abrufen Seite 65 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

80 6 Fallbeispiel und Use Cases UC Dokument aktualisieren Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokument aktualisieren_uc Abstrakt Eine neue Version eines bereits in der eepa vorhandenen Dokumentes wird von einem berechtigten Akteur eingestellt. Der Akteur ist nur berechtigt ein Dokument zu aktualisieren, welches von seiner Organisation in die Akte eingestellt wurde. Die neue Version eines bereits in der eepa vorhandenen Dokumentes wird für einen Patienten in die eepa eingestellt und ist für berechtigte Nutzer abrufbar. Dokument einstellen_uc 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Das Dokument liegt vor. 4. Die Metadaten zum Dokument liegen vor. 5. Der spezifizierte Dokumenttyp ist gültig. 6. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumente zu aktualisieren. 7. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, das Dokument zu aktualisieren. Die neue Version des Dokumentes wurde in das eepa-system eingefügt. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Fachliche Notwendigkeit ein Dokument zu aktualisieren. Health Professional, Aktenmoderator, Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet das Dokument inkl. notwendiger Metadaten an das eepa-system. 2. Das eepa-system prüft, ob das Dokument schon vorhanden ist. Anmerkung: Prüfung über mitgesandte, unverschlüsselte Metadaten oder eindeutige externe Objekt-ID des Dokumentes. 3. Das eepa-system fügt die neue Version des Dokumentes in die eepa ein. 4. Das eepa-system protokolliert die Einfügung. 5. Das eepa-system gibt eine Meldung an den Akteur zurück. Transportverschlüsselung zwischen Primärsystem und eepa-system. Alle Spezialisierungen des Typs Dokument. Tabelle 25: UC Dokument aktualisieren Seite 66 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

81 6 Fallbeispiel und Use Cases UC Dokument sperren Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokument sperren_uc Konkret Ein Dokument kann vom Patienten selbst, auf Wunsch des Patienten von seinem Aktenmoderator oder vom Eigentümer (Health Professional) des Dokumentes gesperrt werden. Ein gesperrtes Dokument ist, mit Ausnahme des Aktenmoderators und des sperrenden Akteurs, für keinen anderen Akteur mehr sichtbar und zugreifbar. Die Sichtbarkeit und Zugreifbarkeit auf ein Dokument soll verhindert werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Das zu sperrende Dokument ist eindeutig identifiziert. 4. Das zu sperrende Dokument ist im eepa-system vorhanden. 5. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumente zu sperren. 6. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, das Dokument zu sperren. Das Dokument ist für die Benutzung gesperrt und nicht mehr sichtbar. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Der Patient oder der Eigentümer eines Dokumentes haben den Wunsch, dass ein Dokument gesperrt wird. Aktenmoderator, Health Professional (eigene Dokumente), Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung zum Sperren des Dokumentes an das eepa-system. 2. Das eepa-system prüft, ob das zu sperrende Dokument vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system sperrt das benannte Dokument. Transportverschlüsselung zwischen Primärsystem und eepa-system. Realisierungshinweise: Die Sperrung des Dokumentes wird durch eine Policy realisiert. Alle Spezialisierungen des Typs Dokument. Tabelle 26: UC Dokument sperren Seite 67 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

82 6 Fallbeispiel und Use Cases UC Dokument entsperren Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Dokument entsperren_uc Konkret Ein gesperrtes Dokument kann von dem Akteur der es gesperrt hat auch wieder entsperrt werden. Ein entsperrtes Dokument ist wieder für alle berechtigten Akteure sichtbar. Ein gesperrtes Dokument soll wieder sichtbar und zugreifbar gemacht werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Das zu entsperrende Dokument ist eindeutig identifiziert. 4. Das zu entsperrende Dokument ist im eepa-system vorhanden und gesperrt. 5. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumente zu entsperren. 6. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, das Dokument zu entsperren. Das Dokument ist für berechtigte Akteure wieder sichtbar und zugreifbar. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Der Patient hat den Wunsch, dass ein Dokument entsperrt wird. Aktenmoderator, Health Professional (eigene Dokumente), Patient Primärsystem, Patientenportal eepa-system 1. Der direkte Akteur sendet die Anforderung zum Entsperren des Dokumentes an das eepa-system. 2. Das eepa-system prüft, ob das zu entsperrende Dokument vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system entsperrt das benannte Dokument. Transportverschlüsselung zwischen Primärsystem und eepa-system. Die Sperrung des Dokumentes wird durch eine Policy realisiert. Es soll eine Benutzeroberfläche geben, die es dem Benutzer erlaubt, die von ihm gesperrten Dokumente anzuzeigen und die Sperrung ggf. aufzuheben. Die Listung der gesperrten Dokumente betrifft ausschließlich den Benutzer der die Sperrung veranlasst hat (die entsprechende Kennzeichnung eingestellt hat). Die Aufhebung der Sperrung erfolgt durch die Entfernung der Gesperrt-Kennzeichnung. Die Aufhebung der Sperrung eines Dokumentes betrifft auch Vorgänger-Versionen dieses Dokumentes. Alle Spezialisierungen des Typs Dokument. Tabelle 27: UC Dokument entsperren Seite 68 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

83 6 Fallbeispiel und Use Cases UC Dokument löschen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Dokument löschen_uc Konkret Ein Dokument wird auf Wunsch des Patienten vom Aktenmoderator gelöscht. Das gelöschte Dokument wird endgültig und unwiederbringlich aus der Akte entfernt. Ein Dokument soll endgültig aus der Akte entfernt werden. 1. Der direkte Akteur ist identifiziert und authentifiziert. 2. Der veranlassende indirekte Akteur ist identifiziert und authentifiziert. 3. Das spezifizierte Dokument ist vorhanden. 4. Die beteiligten Akteure haben die generelle Systemberechtigung um Dokumente zu löschen. 5. Die beteiligten Akteure haben im speziellen Nutzungskontext die Berechtigung, Dokumente zu löschen. Das gewünschte Dokument wurde gelöscht. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine (technisch signierte) Bestätigung an den Akteur zurückgegeben. 1. Es wird eine Protokollierung geschrieben. 2. Es wird eine Benachrichtigung/Fehlermeldung an den Akteur zurückgegeben. Dem Akteur wird eine Fehlermeldung mit definiertem Fehlercode übermittelt. Ein Patient wünscht, dass ein Dokument aus seiner Akte gelöscht wird. Aktenmoderator Primärsystem eepa-system 1. Der direkte Akteur sendet die Anforderung zum Löschen des Dokumentes an das eepa-system. 2. Das eepa-system prüft, ob das zu löschende Dokument vorhanden ist und der Akteur die erforderliche Berechtigung besitzt. 3. Das eepa-system löscht das benannte Dokument. Transportverschlüsselung zwischen Primärsystem und eepa-system. Technische Hinweise: Im Rahmen der Löschung werden die Metadaten des Dokumentes in der Registry durch die Transaktion Delete Document Set [ITI-62] entfernt. Das Dokument wird physisch aus dem Repository gelöscht, falls es sich dabei nicht um das Originaldokument im Sinne von einem sog. Embedded Source/Repository handelt. Eine Kennzeichnung von Dokumenten als gelöscht ohne physikalische Löschung wird nicht unterstützt. Die IHE Transaktion Delete Document Set [ITI-62] ist aktuell nur für die Document Registry definiert. Eine Erweiterung dieser Transaktion auf das Repository zur physischen Löschung der Dokumente wird als Change Request vom ebpg Projekt bei der IHE eingebracht. Eine Löschung der Dokumente aus dem Repository darf nur dann ausgeführt werden, falls es sich bei den im Repository gespeicherten Dokumenten um ein Replikat des Originals handelt. Dies ist im Allgemeinen dann nicht der Fall, wenn es sich um Embedded Source/Repository handelt, welches als dokumentenführendes System auftritt und somit keine Replikate der Dokumente erzeugt werden. Hierfür sind ge- Seite 69 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

84 6 Fallbeispiel und Use Cases Bezeichnung Informationsobjekte Offene Fragen und Themen Dokument löschen_uc sonderte organisatorische Vereinbarungen zu treffen. Bei einer Löschung eines Dokumentes werden auch die Vorgänger-Versionen dieses Dokumentes gelöscht. Dokumente Die IHE Transaktion Delete Document Set [ITI-62] ist aktuell nur für die Document Registry definiert. Eine Erweiterung dieser Transaktion auf das Repository zur physischen Löschung der Dokumente wird als Change Request vom ebpg Projekt bei der IHE eingebracht. Verantwortlich: N/N. Tabelle 28: UC Dokument löschen Seite 70 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

85 6 Fallbeispiel und Use Cases UC Notfalldaten abrufen Bezeichnung UC-Typ Beschreibung Ziel UC Erbt von UC Inclusions UC Extensions Vorbedingungen Resultat beim Erfolg Nachbedingungen beim Erfolg Nachbedingungen beim Fehlschlag Fehlerbehandlung Auslösendes Ereignis Request-Akteur menschlich Request-Akteur maschinell Response-Akteur Beschreibung Ablauf Sicherheitsanforderungen Alternativen Hinweise Informationsobjekte Offene Fragen und Themen Notfalldaten abrufen_uc Konkret In Anlehnung an 291a SGB-V sind Notfalldaten medizinische Daten, die für die Notfallversorgung erforderlich sind. Die für die Notfalldaten auf der EGK festgelegten Zugriffsrechte werden hier entsprechend auf Notfalldokumente in der Patientenakte angewendet. Auf diese Daten sollen neben Ärzten, Zahnärzten, Psychotherapeuten, Apothekern und deren berufsmäßigen Gehilfen unter entsprechender Aufsicht auch Angehörige eines anderen Heilberufs, der für die Berufsausübung oder die Führung der Berufsbezeichnung eine staatlich geregelte Ausbildung erfordert zugreifen können. Hierzu gehören z. B. auch Rettungsassistenten. Zugriff auf wichtige medizinische Informationen im Notfall, um die Notfallmaßnahmen sicherer und an evtl. Vorerkrankungen des Patienten ausgerichtet durchführen zu können. Dokument abrufen_uc Ein Patient befindet sich in einem lebensbedrohlichen Zustand und es sollen medizinische Notfallmaßnahmen eingeleitet werden. Notfallbehandler Nicht gefüllte Tabellenfelder siehe UC Dokument abrufen_uc von dem geerbt wird. Der Zugriff auf Notfalldokumente von Patienten, auf die man im Regelbetrieb keinen Zugriff hat, ist nur in der Rolle Notfallbehandler zulässig. Aus Sicht der Rollen Health Professional, Aktenmoderator, Health Professional Assistance sind Notfalldokumente Dokumente, die den üblichen Zugriffsberechtigungen unterliegen. Notfalldokument Tabelle 29: UC Notfalldaten abrufen Seite 71 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

86 6 Fallbeispiel und Use Cases Seite 72 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

87 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Dieses Kapitel beschreibt die Analyse von Aktenmodellen aus der fachlichen Mehrwertsicht unter Berücksichtigung der dazu notwendigen Granularität der klinischen Informationseinheiten und deren Verbindungen untereinander. Anhand der Problemstellung wird erörtert wie eine fachliche Lösung abgeleitet werden kann. 7.1 Problemstellung Ziel dieses Kapitels ist es, das Aktenmodell aus der fachlogischen Sichtweise heraus zu betrachten. Hierzu werden die wichtigsten fachlichen Anforderungen exemplarisch beschrieben, damit daraus abgeleitet die bestmögliche Modellierung und semantische Indizierung- bzw. Typisierung erfolgen kann. Im Folgenden ist dafür eine Analyse des zuvor beschriebenen Fallbeispiels aus der Perspektive eines medizinischen Akteurs vorgenommen worden. Hieraus ergeben sich folgende Fragestellungen: Was sucht ein Arzt in den Akten? Wie definieren sich Suchkriterien anhand der Patienten- / Krankheitssituation? Was wird als Notfalldaten markiert? Wie könnte eine Medical Summary entstehen? Aufzählungsliste 17: Fragestellungen zum Fallbeispiel Es ergibt sich die Notwendigkeit die Informationsobjekte entsprechend zu indizieren, so dass gezielte Abfragen möglich sind. Ideal wäre der Einsatz expliziter klinischer Probleme als Indikatoren. Die Anwendung von Problemen als Definition für den Aktenordner ermöglicht eine Suche nach klinischen Kriterien (Episoden-Orientierung) was den Überblick zum Beratungs- und Behandlungsverlauf eines einzelnen Problems mit dem jeweiligen vollständigen Rückblick auf das problemspezifische Geschehen verbessern könnte Anwendungsbeispiel koronares Problem Das folgende Beispiel beschreibt den klinischen Denkprozess eines Arztes und wie er im Verlauf eines koronaren Problems zu einer Diagnose kommt. Die folgende Grafik verdeutlicht die für den Kliniker relevante Sicht auf Patienteninformationen in einer typischen Patientenhistorie und sowie deren Herkunft und klinische Klassifizierung. Sie beinhaltet sowohl die dokumentierten Symptome der Herzprobleme, als auch den diesbezüglich relevanten Patientenkontext, insbesondere relevanter Risikofaktoren wie z. B. Feststellung ist Raucher inkl. der Dosis. Klinisch wichtig sind auch die medizinischen Zeitpunkte (die auch unscharf sein können) wie bekannt seit..., oder Datum des Myokardin- Seite 73 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

88 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene farkts. Diese Sicht sollte daher dem behandelnden Arzt ohne großen Aufwand mittels einer manuellen Suche zur Verfügung gestellt werden. Abbildung 04: Klinischer Überblick koronares Problem Eine wichtige Filtermöglichkeit auf diese Sicht ist durch den Ausschluss der nicht mehr relevanten Informationen definiert. Dadurch würde der Healthcare-Provider auf einen Blick die jetzt noch bestehenden Problemfaktoren angezeigt bekommen. Abbildung 05: Filterung koronares Problem aktueller Patientenstatus Seite 74 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

89 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Grundsätzliche problemorientierte Ansätze Ideal für einen Healthcare Professional wäre auch eine Darstellung der klinischen Beziehungen zwischen den Informationsobjekten. Im Beispiel ist ontologisch die Dokumentation koronare Erkrankung mit der Relation ist Komplikation von Myocardinfarkt verbunden. Die koronare Erkrankung ist das Root-Problem in diesem Beispiel. Abbildung 06: Semantische Beziehung im Beispiel koronares Problem 7.2 Problemlösungsvorschlag fachlich Im Folgenden wird durch Analyse der Gesamtstory eine Beschreibung der bedeutendsten Abfragen an eine eepa ermittelt und fachlich beschrieben. Im Weiteren erfolgt eine Beschreibung verwandter Projekte wie EPSOS, EGK, etc. mit dem Ziel zu ermitteln, welche Informationen dort auf welchem Granularitätslevel übertragen und gespeichert werden Analyse der Gesamtstory Kolonkarzinom und Ableitung der fünf häufigsten Abfragen Im Folgenden wird die exemplarische Gesamtstory Kolonkarzinom analysiert, um die fünf häufigsten klinischen Abfragen an eine eepa zu extrahieren Analyse der Gesamtstory Kolonkarzinom Die nachfolgende Tabelle listet alle in der Gesamtstory Kolonkarzinom in ebpg auftretenden klinischen Fragestellungen an eine eepa und denkbare erweiterte Szenarien auf, die nicht explizit in den Stories beschrieben sind. Ziel dieser Auflistung ist es herauszufinden, welche Attribute in den Dokumenten (Metadaten oder Dokumentstruktur) erforderlich sind, damit die gelisteten Abfragen gezielt ausführbar sind. Seite 75 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

90 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Klin. Domäne Dokumentationsart Fachlicher use case Arztbrief Existenz Krebserkrankungen in Familie Familienanamnese: Kolonkarzinom? Medikation Medikation (Medikament / Dosis / Start / Stop) aktuelle Medikation Labor (Arztbrief) Labor Stuhl Dokumentation Labor: Blut in Stuhl Allgemeinzustand (Arztbrief) Anamnese + aktuelle Beschwerden (HH) Überblick Patientenzustand Radiologie Befund/Bild Röntgen-thorax, Abdomen Radiologischer Vorbefund?: Existiert ein Röntgen-Thorax oder eine Abdomen- Bildgebung? Allergie Allgemeindokumentation Allergien Radiologie-Vorbereitung: Allg. Allergien + spezifisch Jodallergie Problem Problemdokumentation Radiologie-Vorbereitung: Herzschrittmacher, Klaustrophobie Labor (Arztbrief) Labor Blut Radio-Vorbereitung: Laboruntersuchung: Kreatinin, T3, T4, TSH, Radiologie Befund/Bild Koloskopie, CT Radiologische Befunde: Koloskopie, CT Labor (Arztbrief) Labor Blutgerinnung OP-Vorbereitung (e.g. Gerinnungsbilanz fehlt ) Allergie Allgemeindokumentation Allergien OP-Vorbereitung: relevante Allergien (e.g. Latex), Medikamente EKG/Arztbrief Arztbriefe? EKG Vorbefunde Sonografie Sonografiebefund/Arztbrief Sonografische Vorbefunde Allergie Allgemeindokumentation Allergien, Arztbrief Anästhesie Konsil: Allergien insbes. Medikamentenallergien, Latex. Anästhesie OP Dokumentation (Problemliste?) Anästhesie Konsil: Abfrage Anästhetische Vorfälle, schwierige Intubation, etc. Anästhesie OP Dokumentation (Problemliste?) Anästhesie Konsil: Frühere Anästhesie, Prämedikationsbogen Problem Allgemeindokumentation, Arztbrief Anästhesie Konsil: Abfrage Risikofaktoren: Tabak, Alkohol, ). Kardiolog. Probleme? Anästhesie Konsil: kardiologische Probleme. Gastroenterologie Befund Gastroenterologie Dokumentation und Lesezugriff Bericht Gastroenterologie OP OP Bericht (vorläufig, final) OP Erfassung Pathologie Pathologiebefund Dokumentation und Lesezugriff OP- Pathologie und Ableitung Nachbehandlung Onkologie TNM Klassifikation Dokumentation Tumor-Klassifikation Diagnosecodierung ICD Stationär ICD Codierung: (Adenokarzinom - M814 M838 Adenome und Adenokarzinome) oder C19 Bösartige Neubildung am Rektosigmoid, Übergang) Entlassbrief stationär (Kolorektales Karzinom) Codierung mit ICD-10 Dokumentation stat. Aufenthalt Seite 76 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

91 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Klin. Domäne Dokumentationsart Fachlicher use case Reha Epikrise Reha Dokumentation Patientenzustand Nachsorge Spezieller Patientenzustand evtl. gyn. Untersuchung (Menopause?) Radiologie Befund Röntgenthorax Radiologie: Röntgenthorax (CP) Vergleich Diagnosecodierung ICD Codierung Abfrage Diagnostik Übersicht (ICD) ICD Problem Problemdokumentation Überblick gesamte Problemliste Sonografie Abdomensonografie Befund Suche und Vergleich mit bestehender Abdomensonografie Onkologie/Labor Labuntersuchung e.g. Tumormarker Dokumentation Tumormarker Überweisung Überweisung HH Überweisungsgrund Tabelle 30: Analyse der fachlichen Abfragen der eepa aus der Gesamtstory heraus Legende zu den Spalten: Klin. Domäne: Klassifikation in welcher klinischen Domäne die Daten relevant sind Dokumentationsart: Klassifikation, in welcher Art die entsprechende Dokumentation im Primärsystem vorliegt. Fachlicher Use Case: Anwendungsfall der sich klinisch ergibt Ableitung der fünf bedeutsamsten klinischen Abfragen Aus dem vorigen Kapitel leiten wir die folgenden fünf bedeutsamsten klinischen Abfragen ab: Aktuelle Medikation Existierende radiologische Befunde/Bilder (z. B. Röntgen-Thorax) Liste bekannter Allergien und Risiken Allgemeine übergreifende Problemliste Abfrage Diagnostik - Übersicht aller ICD Kodierungen. Aufzählungsliste 18: Wesentliche klinische Abfragen Abfrage aktuelle Medikation Idealerweise sollte die aktuelle Medikation bzgl. Verabreichungszeitraum, Dosierung (kodiertes Arzneimittel, Dosierungsmuster) ermittelbar sein. Damit könnte man schließen, dass eine Medikation ab einem bestimmten Zeitpunkt nicht mehr aktuell ist und sie anschließend aus der Gesamttreffermenge herausfiltern. Es ergibt sich hier natürlich auch zwingend die Anforderung der zeitnahen Aktualisierung durch den behandelnden Arzt. Bsp. als Freitext: Zweimal täglich eine Tablette Sulfamethoxazol 800 Milligramm ab dem für eine Woche. Seite 77 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

92 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Hierin sind alle notwendigen Angaben wie die Dosierung (1-1), die Darreichungsform (Tablette), der Wirkstoff (Sulfamethoxazol), die Dosis (800 Milligramm), der Zeitpunkt ( ) und die Dauer (eine Woche), womit implizit auch das Medikationsende ( ) beschrieben ist, enthalten. Klinisch interessant wäre auch die semantische Kodierung verwendeter Arzneimittel mit einem klinischen Medikamentenstandard, so dass auf den darin enthaltenen Wirkstoff rückgeschlossen werden kann (bspw. ATC Code 21 J01EC01 für sulfamethoxazole) und direkt das Arzneimittel angegeben werden kann. Abbildung 07: ATC-Beispiele (aus Eine realisierbare, eingeschränkte Alternative wäre die Ermittlung einer simplen Freitextliste (über die globale semantische Annotation der Medikation) aller dokumentierten Medikationen, die dann allerdings vom Benutzer interpretiert und gefiltert werden muss. Damit wäre die Suche nach aktueller Medikation automatisiert jedoch nicht oder nur eingeschränkt möglich. Bsp. Penicillin V1 Mega von ct, morgens, mittags und abends, je eine Filmtablette (aus Leitfaden VHITG Arztbrief V150) Abfrage existierender radiologischer Untersuchungen Viele radiologische Untersuchungen machen nur dann Sinn, wenn man Vergleichsaufnahmen aus der Patientenhistorie zu Grunde legt. Beispielsweise der Vergleich der Thoraxaufnahmen bzgl. Herz / Lunge, um z. B. pathologische Vergrößerungen zu beurteilen. Damit man diesen Vergleich durchführen kann, muss man die bestehenden Aufnahmen klassifiziert suchen können. Also bspw. Suche nach allen Röntgen-Thorax Aufnahmen oder nach Aufnahmen einer anderen bestimmten Körperregion (Unterarm, Hand). Dies gilt natürlich auch für andere bildgebenden Verfahren, u. a. Sonografie und ECG. 21 Hierbei ist zu beachten, dass einige Codesysteme wie bspw. ATC eine Lizenz verlangen. Seite 78 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

93 Mögliche Suchkriterien sind: 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Lokalisation (idealerweise kodiert, z. B. Anatomie in SNOMED CT) Prozedur der durchgeführten bildgebenden Untersuchung aus Prozedurenkatalog Freitextsuche über codierte Schlagworte in der zugeordneten Befunddokumentation Aufzählungsliste 19: Suchkriterien zur Abfrage existierender Untersuchungen Abfrage bekannter Allergien und Risiken Die Abfrage bekannter und klinisch bestätigter Allergien und Risiken ist eine sehr bedeutsame funktionale Anforderung an einen Patientenordner. Diese Information muss möglichst jederzeit sichtbar zur Patientenrisikovermeidung dargestellt werden und im Behandlungskontext berücksichtigt werden. Beispiele für häufig vorkommende Allergie- oder Risiko-Implikationen sind: CT mit Kontrastmittelverabreichung und bekannter Kontrastmittelallergie. Geplante OP und bestätigte Latex-Allergie. Medikationsanordnung und bestätigte Antibiotika-Allergie, möglichst mit Angabe der Substanz. Endoskopieanordnung und per aktuellem Laborresultat bestätigte Problematik bzgl. Blutgerinnung. Aufzählungsliste 20: Beispiele für häufig vorkommende Allergie- oder Risiko-Implikationen Abfrage der Patienten-Problemliste Die Grundidee der problemorientierten klinischen Dokumentation ist die explizite Formulierung von Problemen zur Erleichterung der Zuordnung der Patientendaten und das systematische Abarbeiten der Probleme 22. Für einen externen Patientenordner könnte die explizite Auflistung der Probleme inkl. Zuordnung der beinhaltenden Patientendokumentation folgende funktionale Aspekte ermöglichen: Fokussierter Überblick nach bestimmten Kriterien über die ganze Patientengeschichte. Überblick über den Verlauf einer chronischen Krankheit (e.g. Diabetes), inkl. aller zugehörigen Ereignisse (Events). Filterkriterium bzgl. der Patientendatensuche. Aufzählungsliste 21: Funktionale Aspekte einer Problemauflistung Ein Beispiel für die Suche wäre die Einschränkung der Problemliste z. B. auf koronare Probleme. Damit könnten alle darunter gelinkten Dokumente jemals erfolgter und dokumentierter koronarer Behandlungen ermittelt werden auch über den Behandlungskontext eines medizinischen Falles hin- 22 siehe Jürgen Dahmer Anamnese und Befund (Georg Thieme Verlag 2006) Kapitel 22.0 problemorientierte Dokumentation Seite 79 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

94 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene aus. Zwingend notwendig hierfür ist eine semantische Kodierung der einzelnen Probleme mit klinischer Standardterminologie, idealerweise mit SNOMED CT oder LOINC. Anmerkung zur Realisierbarkeit: Die im deutschen Markt ausgerollten KIS Systeme bieten bislang praktisch keine Funktionalität zur problemorientierten Dokumentation. Daher müssten zum Zeitpunkt des Sendens der Dokumente an die eepa, Probleme manuell erstellt und den Dokumenten ebenfalls manuell zugeordnet werden. Da sich die Problemliste im zyklischen Prozess der Untersuchung und Diagnostik verändert, ist dies ein komplexer Vorgang. Beispiel für die Iteration eines Problems: Blut im Sputum, Verdacht auf Tumor in rechter Lunge, Diagnose bösartiger Tumor rechte Lunge. In Anbetracht der Tatsache, dass die einzige gesetzlich verpflichtende Kodierung im Deutschen Gesundheitsbereich die Diagnosen- (ICD10) und Prozeduren- (ICPM) Kodierung ist, wäre es eine pragmatische Alternative diese zu benutzen. Hierzu wäre es möglich, dynamisch eine Liste der dokumentierten Abrechnungsdiagnosen zu ermitteln und damit eine explizite Problemliste zu simulieren, siehe nächster Abschnitt. Die aktuellen Ansätze anderer ähnlicher europäischer Initiativen wie DMP in Frankreich oder ELGA in Österreich begrenzen sich derzeit allerdings auf die Erstellung einzelner Dokumente (CDA Level 1 bis 2) ohne die Verwendung von feingranularen Elementen Abfrage der kodierten Diagnosen Eine zeitlich geordnete Liste der kodierten Diagnosen gibt einen recht guten Überblick über die Patientenhistorie und lässt sich normalerweise recht zuverlässig und einfach ermitteln, da die Kodierung gesetzlich verpflichtend ist. Allerdings ist die detaillierte klinische Aussagekraft eingeschränkt, da die dokumentierten Diagnose-Codes nicht sehr feingranular sind und aus abrechnungstechnischen Gründen häufig optimiert werden, speziell bei ICD Kodes. Man darf hier also nicht dieselbe Aussagekraft erwarten, wie es mit SNOMED CT oder LOINC klinisch kodierten Patientenakten theoretisch möglich wäre. Die von der DIMDI (Deutsches Institut für Medizinische Dokumentation und Information) spezifizierte ALPHA ID ist eine Möglichkeit Diagnosen detaillierter zu klassifizieren, insbesondere durch die Synonyme und Krankheitsbezeichnungen Seite 80 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

95 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Sonderfall Notfalldaten versus Patient Summary Gemeinsamkeiten / Unterschiede Im Wesentlichen kann man sagen, dass die Notfalldaten weitestgehend einen speziellen Ausschnitt der Patient Summary darstellen. In den Notfalldaten tauchen im Gegensatz zur Patient Summary nur notfallrelevante Diagnosen auf, jedoch nicht alle aktuell bestätigten Diagnosen. Es wird in den Betrachtungen allerdings nicht explizit beschrieben, wann Diagnosen notfallrelevant sind. Zusätzliche Informationen im Notfalldatensatz sind: Persönliche Erklärungen des Patienten wie z. B. Willenserklärungen des Patienten zum Behandlungsverlauf oder zur Organ- und Gewebespende sowie Kontaktperson- und Hausarztdaten. Eine Literaturrecherche im europäischen Raum hat ergeben, dass das Ziel einer Patient Summary (EPSOS oder SCR- Summary Care Record von der NHS in UK) oft als die Übergabe der wesentlichen medizinischen Information an einen Healthcare Provider im Fall eines ungeplanten Arzt/ Krankenhaus-Besuchs verstanden wird. Folglich scheint die Hauptnutzung der Patient Summary der sogenannte Notfall zu sein Literaturrecherche Aktuell existieren einige Initiativen oder Projekte, die die Definition von Notfalldaten oder der Patient Summary zum Ziel haben. Folgende Projekte werden im Folgenden genauer analysiert: gematik Gesundheitskarte epsos, Summary Care Record MIND3 (Minimaler Notfalldatensatz) Bundesärztekammer Aufzählungsliste 22: Initiativen zur Definition von Notfalldaten Seite 81 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

96 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Notfalldaten egk, bzw. Forderung Bundesärztekammer Im Folgenden wurden Spezifikationen der egk und der Bundesärztekammer (BÄK) auf Gemeinsamkeiten und Unterschiede analysiert. Beide Spezifikationen sind sehr ähnlich, die Anforderungen der BÄK gehen allerdings etwas weiter Liste der Anforderungen: Organ- und Gewebespendeerklärung Demographische Patientendaten Notfallrelevante Diagnosen (BÄK: möglichst ICD10-kodiert) Aktuelle Medikation Allergien / Unverträglichkeiten (Freitext + Arznei + Reaktion) Besondere Hinweise (als Freitext + Datum): o Schwangerschaft ja/nein + errechneter Entbindungstermin o Implantate einschließlich exakter Typenbezeichnung + Datum der Implantation o Kommunikationsstörungen o Weglaufgefährdung o Sonstige Hinweise Behandelnder Arzt oder Institution (Name + Tel.) Zu benachrichtigende Person bzw. Institution (Name + Tel.) nur in der BÄK: o Patienten-Verfügung o Vorsorge-Vollmacht o Zusätzliche medizinische Informationen auf Wunsch des Patienten (z. B. Blutgruppe), aber nicht klinisch verwendbar. o Letzte Aktualisierung o Versionskennung des Notfalldatensatzes o Einverständniserklärung des Patienten o Kennzeichen je Attribut als Fremdbefund, falls keine eigene diagnostische Erhebung Aufzählungsliste 23: Anforderungen der BÄK gematik -Fachkonzept Daten für die Notfallversorgung (Notfalldaten) Version Seite 82 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

97 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene epsos Patient Summary Die sogenannte Patient Summary im europaweiten Projekt epsos 26 beinhaltet folgende Daten: Demografische Patientendaten (inkl. Geschlecht) Medical summary beinhaltet die wichtigsten Patientendaten, wie: o Allergien und Intoleranzen (Alerts / CAVE) 27 o Patientengeschichte beinhaltet: - Impfungen - Liste der abgeschlossenen, inaktiven Probleme (Teil der Patientengeschichte) - Chirurgische Prozeduren (älter als 6 Monate) o Aktuelle medizinische Probleme o Implantate o Bedeutende operative Eingriffe innerhalb der letzten 6 Monate o Behandlungsempfehlung o Autonomie / Invaliditätsdaten Aktuelle Medikation (alle verschriebenen Medikamente mit gültiger Behandlungsdauer, unabhängig ob sie administriert worden sind) Sozialgeschichte Schwangerschaftsgeschichte Physische Untersuchung Diagnostik / Tests u. a. Blutgruppe Aufzählungsliste 24: Daten der Patient Summary Im Zuge der detaillierten Inhaltsdefinition hat sich herausgestellt, dass Allergien und Medikamentenunverträglichkeit die am einfachsten und verständlichsten zu übertragenen Daten wären. Meta-Information der Patient Summary (z. B. durch wen und wann wurde die Patient Summary angelegt od. geändert) werden auch für Protokollierungs- und Sicherheits- Anforderungen verwendet. Die aktuelle Definition der Patient Summary von EPSOS berücksichtigt die Reife (maturity level) der in der europäischen Gemeinschaft existierenden Healthcare Systeme, was konkret bedeutet, dass die minimalen Anforderungen (Minimum Data Set und Mandatory Data Set) sehr gering sind. Folglich sind weder die Kodierung noch das vollständige Ausfüllen eines Feldes verpflichtend (auch nicht als Freitext). Lediglich Patientenverwaltungsdaten müssen ausgefüllt werden. Es ist nicht beschrieben wie der behandelnde Arzt die Patient Summary erzeugt. Die Inhalte sind dem Notfall-Datensatz der egk sehr ähnlich Das Feld Alerts ist ursprünglich definiert worden, um wichtige und objektive medizinische Information zu unterstreichen wie z. B.: Allergien, Thrombose, Immunitäre Defizienz Seite 83 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

98 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Der Minimale Notfalldatensatz MIND3 MIND3 ist eine Spezifikation zur Beschreibung eines minimalen Notfalldatensatzes aus Sicht der Notfallmedizin (DIVI 2011). Im Gegensatz zu den vorigen Spezifikationen wird hier festgelegt, welche Daten bei einem Notfall dokumentiert werden sollen. Basismodul (allgemein zu erhebende Daten. Es existieren auch spezifische Erweiterungen): Strukturdaten und rettungsdienstliche Einsatzdaten (beteiligte Rettungsmittel, Qualifikation des eingesetzten Rettungsdienstpersonals, Ablaufzeiten) Patientendaten (Geschlecht und Alter) Erstbefund bei Eintreffen des Rettungsteams Diagnose (Erkrankungen oder Verletzungen/Trauma) Scores (MEES, M-NACA) Rettungsdienstliche Maßnahmen und Medikamente (inkl. Basisdaten Reanimation) Übergabebefund in der Zielklinik Einsatzrelevante Besonderheiten. Aufzählungsliste 25: Dokumentierte Daten im Basismodul Der MIND3 übernimmt dabei unverändert die von den jeweiligen Fachgesellschaften erstellten und validierten Erhebungsmerkmale und Scores. Dazu gehören beispielsweise der Mainz Emergency Evaluation Score MEES, die Glasgow-Coma-Scale GCS und Face-Arms-Speech-Time FAST. Die Daten sind sehr stark auf die Dokumentation des präklinischen Notfalleingriffs zugeschnitten und haben wenig Potential zur allgemeinen Wiederverwendung. Im Allgemeinen folgt eine weitere ambulante Notfallversorgung. Die dabei und im weiteren Behandlungsverlauf dokumentierten Daten sind wesentlich relevanter als Quelle der zentralen Notfall-Daten-Speicherung. Seite 84 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

99 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Fortgeschriebene versus generierte Patient Summary Den klinisch wichtigsten Überblick auf einen Patienten mittels eepa bietet eine sogenannte Patientsummary. Idealerweise gibt Sie dem behandelnden Arzt einen Gesamtüberblick über den aktuellen Patientenstatus inklusive existierender Erkrankungen, Allergien und aktueller Medikation. Benutzt man CDA Dokumente als zu speichernde Informationseinheiten, dann kann die Patientsummary auf zwei unterschiedliche Vorgehensweisen abgebildet werden: Gemeinsam fortgeschriebene Patientsummary: Ein gemeinsam benutztes Patientsummary-Dokument wird von allen Autoren fortgeschrieben, indem relevante Daten nach jedem Behandlungsschritt geprüft und aktualisiert werden. Hierfür ist immer ein Download + Upload Vorgang notwendig. Generierte Patientsummary: Man nutzt die Strukturiertheit von CDA (mind. Level 2), selektiert die entsprechenden Sektionen und kumuliert und oder mischt die Inhalte. Das kann allerdings nur dann feingranular funktionieren, wenn die entsprechenden Inhalte vergleichbar sind, d.h. auf Entry Level spezifiziert sind. Man kann die generierte Patientsummary auch als Subanwendungsfall von Healthcare Events (siehe Kapitel 7.3.2) auf Diagnosen, Allergien und Medikation sehen. Im Folgenden sind wichtige Aspekte vergleichend für die fortgeschriebene und generierte Patientsummary gegenübergestellt: Ärztl. Signatur Aufwand Zusätzliche technische Komponenten Notwendige Dokumente Kritische Punkte Generiert Nur indirekt über die Signatur der Einzeldokumente Zur Laufzeit automatisiert, aber technisches Setup notwendig Abfragen zur Extraktion inhaltlich gleicher Sections Algorithmus festlegen (last wins, merge, historisierte Liste) OID-Verwaltung zur eindeutigen Identifikation der Informationseinheiten oder Ähnliches Minimal: Entlassbriefe, zusätzlich Mutterpass, Laborbefunde, Allergologie-Befund, etc. Redundanzvermeidung erfordert Identifikation und Vergleichbarkeit der klinischen Statements fortgeschrieben Der letzte Autor (HCP) signiert Dokumenten-update Workflow notwendig Keine Nur Patientsummary Akzeptanz der gemeinsamen Fortschreibung auf einem Dokument Tabelle 31: Generierte vs. fortgeschriebene Patient Summary Seite 85 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

100 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene 7.3 Lösungsvorschlag technisch Das folgende Kapitel gibt eine Übersicht ob und wie tief man feingranulare klinische Abfragen über die beschriebenen Lösungsansätze mit CDA und IHE Profilen implementieren kann. Auf eine technische Berücksichtigung der serverseitigen Verschlüsselungsarchitektur wurde in den Lösungsansätzen ausdrücklich verzichtet und davon ausgegangen, dass die Verschlüsselungslösung weitestgehend transparent für den Endanwender auf einem technischen Layer abläuft. In einem separaten Kapitel werden die funktionalen Einschränkungen der Verschlüsselung einer eepa beschrieben Umsetzung direkt mit CDA Dokumenten Die am häufigsten technisch favorisierte Lösung ist, die eepa über eine vordefinierte Menge von genau spezifizierten CDA Dokumenten zu beschreiben. Hierbei wird zu bestimmten Zeitpunkten im Behandlungsprozess ein in der Regel ärztlich validiertes, vollständiges, fachspezifisches Dokument im Primärsystem erzeugt und in die eepa hochgeladen. Dieser Vorgang spiegelt die briefliche Korrespondenz von Arztbriefen, Befunddokumentationen und Laborergebnissen in elektronischer Form wieder Beschreibung/Vorteile/Nachteile Die Grundidee ist einfach: Eine Menge von vordefinierten klinischen Dokumententypen wird als CDA Templates spezifiziert, wodurch festgelegt wird, welche vordefinierten Informationseinheiten im Rahmen der eepa ausgetauscht werden können. Die Semantik der Daten und die Granularität ist hierdurch eindeutig festgelegt. CDA (siehe Kapitel 4.2) beschreibt drei Level. Diese bedeuten für die fachliche Auswertbarkeit: CDA Level 1: o Keine automatisierte fachliche Auswertbarkeit der medizinischen Daten, sondern nur binärer Dokumentenblock als elektronisches Papieräquivalent. CDA Level 2: o Eingeschränkte automatisierte, fachliche Auswertbarkeit ist möglich und somit auch die Verarbeitung von Einzelaussagen und Extraktion von Textblöcken mit Dokumentationsdatum. Allerdings lassen sich hier klinische Aussagen nicht feingranular ableiten. Das Beispiel in Kapitel zeigt exemplarisch welche Informationen nicht maschineninterpretierbar sind. CDA Level 3: o Strukturierte Information innerhalb einer Sektion durch Entry Level. Ermöglicht durch Schlussfolgerungen (Semantic-reasoning) auch die Extraktion von semantisch vernetzten Daten. Aufzählungsliste 26: Die drei Level der CDA Seite 86 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

101 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Beispiel Asthma Dokumentation Im CDA-Beispiel (technisch Level 3 mit teilweise Level 2 Codierung) einer Anamnese mit gemischter Section- und Entry-Level Codierung lassen sich einige, aber nicht alle Strukturelemente vollständig maschineninterpretierbar und damit semantisch interoperabel klinisch auswerten: Abbildung 08: CDA Ausschnitt aus ELGA Definition Maschinenlesbar: o Erhebung im Rahmen der Anamnese, da LOINC Code: o Observation (Beobachtung) ist Asthma, codiert als SNOMED CT Code asthma (Type:= clinical finding) Nur vom Menschen interpretierbar und nicht maschinenlesbar: o Temporaler Kontext := seit seiner Jugend und Periodizität := mehrmals pro Jahr Krankenhaus. Aufzählungsliste 27: Maschinenlesbarkeit vs. nur vom Mensch interpretierbar Beispiel Entry Level Interpretation (funktionales Beispiel) Das folgende Beispiel illustriert wie man das Kardiologische Patienten-Beispiel aus Kapitel mittels CDA Sektionen und Entry Levels darstellen könnte. Dazu werden zunächst zwei fiktive und unvalidierte CDA Abschnitte illustriert und danach die wesentlichen Daten über die man klinische Suchen realisieren könnte, tabellarisch aufgelistet. Seite 87 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

102 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Beispiel 1 Problem Entry analog allgemeiner Implementierungsleitfaden ELGA 28 : Abbildung 09. ELGA Beispiel 1 Beispiel 2 Medikationshistorie analog ärztlichem Entlassbrief ELGA 29 : Abbildung 10. ELGA Beispiel ementation_guide_for_cda_r2_-_allgemeiner_implementierungsleitfaden_fuer_elga_cda_dokumente.pdf 29 ntlassungsbrief_aerztlich.htm#id Seite 88 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

103 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Codierte Fakten aus dem Beispiel koronares Problem, Palpationen, Labor und Medikation (siehe Kapitel 7.1.1, bei gefilterter Sicht auf CDA Sections und Entries (Filter z. B. koronare Diagnosen, Laborwerte und Medikation): Dokumentation Zeitraum Section Entry Vater an Koronarkrankheit verstorben Koronare Erkrankung - LOINC History of family member diseases Seit 2000 SNOMED CT diagnosis Myocardinfarkt 2002 SNOMED CT diagnosis supra ventrikuläre Fibrillation Seit 2/2003 Akut Digitoxin Kalium (Potassium) SNOMED CT diagnosis LOINC History of present illness LOINC History of medication use? SNOMED CT laboratory test Creatinine? SNOMED CT laboratory test SNOMED CT FH: Cardiac disorder ICD 10 I25 Chronische ischämische Herzkrankheit ICD 10 I21.9 Akuter Myokardinfarkt ICD 10 I48.2 Vorhofflimmern, permanent ICD 10 R00.2 Palpitationen ATC C01AA04 Digitoxin LOINC Potassium in Serum LOINC Creatinine, Serum / Plasma Tabelle 32: Section und Entries for bestimmte Dokumentationen Anmerkungen: Mögliche Redundanzen sind in der Tabelle nicht berücksichtigt. Notwendig wäre auch ein crossterminology mapping oder zumindest eine Klassifizierung (Implizit in SNOMED CT), so dass koronare Erkrankungen in ICD und SNOMED CT für die Filterung klassifiziert werden können. Der akute Myokardinfarkt war 2002 akut, ist aber zu einem späteren Zeitpunkt nicht mehr akut. Verwendet man diese Information also in einer generierten Summary, könnte es zu Interpretationsproblemen kommen. Erweiterbarkeit über Levelerhöhung Hat man die auszutauschenden Dokumenttypen spezifiziert, so kann man die Semantik und damit die fachliche Auswertbarkeit der Daten über eine Erhöhung der CDA Level erreichen. Die Levelerhöhung kann auch über Implementierungsstufen einzelner CDA Spezifikationen erreicht werden. Beispielsweise sind im BVITG Arztbrief 2014 (siehe Kapitel ) sechs Implementierungsstufen beschrie- Seite 89 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

104 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene ben. Mit Stufe 6 lassen sich Informationen sicherlich auch semantisch vernetzt abfragen. Mit Stufe 6 könnte sich die Anforderung an Healthcare Events (siehe Kapitel 7.3.2) abbilden lassen. Vorteile / Nachteile: (-) Redundanz (+) Strukturiertheit (+) Level, (++) ärztliche Validierung/Signatur Aufzählungsliste 28: Vor- und Nachteile einer Levelerhöhung eines CDA-Dokmentes Semantik im Meta-Layer Setzt man IHE als Kommunikationsprotokoll ein, so hat man auch die Möglichkeit CDA Dokumente gezielt zu filtern. Speziell die Attribute Dokumententyp, Medizinisches Fachgebiet und Datum können hier die Informationen der gesamten eepa spezialisieren, so dass in einer zweiten Stufe die verbleibenden Dokumente besser nach Detailinformationen durchsucht werden können Anwendung von CDA in ELGA Anwendung in ELGA Das ELGA Projekt in Österreich (siehe Kapitel ) setzt auf eine komplett CDA-basierte Patientenakte. Semantische Auswertbarkeit ist klar als Ziel gesetzt und wird durch einen Phasen-Plan mit aufeinander aufbauenden Integrationsstufen angestrebt. Es wird allerdings auch angemerkt, dass vollständige semantische Interoperabilität nicht erreicht werden kann, obwohl teilweise CDA Entry Level beschrieben sind. Zum Zeitpunkt der Dokumentenerstellung (2013) sind in ELGA fünf CDA Dokumente spezifiziert. Die einzelnen CDA-Leitfäden beschreiben alle drei ELGA Integrationsstufen. Elga Integrationsstufen: EIS Basic = unstrukturiertes PDF oder nicht komplett EIS extended EIS (Elga Integrationsstufe) Extended := CDA Level 2 / sehr selten 3 EIS (Elga Integrationsstufe) Full support := CDA Level 2-3 Aufzählungsliste 29: ELGA Integrationsstufen Andere Beispiele Ein interessanter, wenn auch schon alter, Artikel wurde 2005 verfasst. Er beschreibt das Potential der CDA in verteilten Gesundheitsinformationssystemen 30, wobei eine mehrschichtige Architektur, in der CDA Dokumente als zentrale verteilte Datenhaltung spezifiziert sind, thematisiert wird. Idealerweise wird die Datenhaltung über eine XML-Datenbank realisiert. Als Middleware wird ein Informati Seite 90 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

105 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene ons-mediator mit Verbindung zu einem Semantischen Bezugssystem oder formalen Ontologien beschrieben. Im Informations-Mediator kann man folglich Semantik definieren, um auch feingranulare Abfragen zu ermöglichen. Allerdings hängt das auch vom Implementierungs-Level der CDA Dokumente ab. Es wird ausdrücklich erwähnt, dass hierzu eine Konfiguration von Domänenexperten vorgenommen werden muss und idealerweise Werkzeuge vorzusehen sind, die ohne tiefes IT-Wissen bedienbar sind. Weitere Aspekte des Artikels sind: Auch CDA-Meta-Daten enthalten semantische Informationen und können schon semantische Information auf Level 1 bereitstellen. Dokumentenbasierte Dokumentation ist Realität,etabliert in den Arbeitsabläufen und ermöglicht beste Entkopplung zwischen Primärsystem und Informationsobjekten. Ein rein dokumentenbasiertes System ist nicht ausreichend, da hier zwangsläufig redundante Informationen existieren und bestehende Dokumente nicht aktualisiert werden. Aufzählungsliste 30: Weitere Aspekte des Artikels Seite 91 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

106 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Adaptation von Healthcare Events Im Rahmen des NRW Projektes EPA2015 wurde u. a. der Aufbau eines dezentralen, semantischen Netzes als Basis für semantische Interoperabilität innerhalb der Patientenakte analysiert. Ein wesentlicher Ansatz darin ist die Abbildung der Daten der Primärsysteme in ein Modell, das dokumentierte Informationseinheiten mit Healthcare Events verknüpft. Die Healthcare Events stellen einen zeitlichen und prozessorientierten Bezug zu den Informationseinheiten her. Damit wird implizit ein semantisches Netz über den einzelnen Informationseinheiten definiert. Abbildung 11. Modellausschnitt Primary Record Content aus EPA2015 In der obigen Abbildung ist ein Teilabschnitt des Modells Primary Record Content aus dem ergebnisdokument des Projektes EPA2015, S. 37, abgebildet. Man sieht darin die zentralen Klassen HCEvent (:= Healthcare Event) und Document. Erläuterungen zu den Klassen sind im Ergebnisdokument EPA2015 ebenfalls beschrieben. Im Rahmen dieses Arbeitspaketes wurde nun analysiert, ob und wie gut man den beschriebenen Ansatz mit IHE und CDA auf das Modell mit Healthcare Events abbilden kann. Im Folgenden werden die einzelnen diskutierten Ansätze beschrieben. Seite 92 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

107 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Abbildung der Healthcare Events zum Zeitpunkt des Auftretens: Die direkte Abbildung und Übermittlung von Informationsobjekten zum Zeitpunkt der Erzeugung im Primärsystem erscheint zum gegenwärtigen Zeitpunkt aus mehreren Gründen in Projekten jenseits des reinen Forschungslevels nur schwer realisier- und durchsetzbar, denn: Die Primärsysteme haben aufgrund der bislang nicht vollständig feingranular implementierten und genutzten Dokumentationsfunktionalität und der häufig nicht realisierten Verbindung zum klinischen Event nicht die Möglichkeit alle Daten eventorientiert zu übermitteln. Das hat seine Ursache in der im Augenblick nach wie vor abrechnungsorientierten, aber nicht wirklich feingranular medizinischen Dokumentation, weshalb die Primärsysteme diese Funktionalität erst schrittweise entwickeln müssen. Die ärztliche Signatur würde im Gegensatz zum dokumentbasierten Ansatz komplett fehlen und der damit verbundene Validierungsschritt wäre nicht abgebildet. Dasheißt die komplette Stornierungslogik, die bislang autonom im Primärsystem geschieht, müsste berücksichtigt werden. Darüber hinaus muss man festlegen, ab welchem Zeitpunkt klinische Dokumentation des primären Leistungserbringers im Behandlungskontext automatisiert nach Außen gegeben werden kann, denn das manuelle Freigeben würde Mehraufwand bedeuten. International vergleichbare Projekte wie EPSOS, ELGA und ehealth Suisse verwenden auch einen CDA basierten Ansatz, so dass man hier von einem gelebten Standard sprechen kann. Der beschriebene Ansatz implementiert eine Healthcare Ontologie, so dass die Kommunikationsobjekte und Schnittstellen vermutlich wenig standardisiert und damit sehr projektspezifisch wären. Aufzählungsliste 31: Hindernisse für direkte Abbildung und Übermittlung von Informationsobjekten Erzeugung von Healthcare Events zum Zeitpunkt des Dokumentupdates: Eine diskutierte Variante ist die automatisierte Erzeugung von Healthcare Events nach dem CDA Upload als Alternative zum eventbasierten Vorgehen. Hier wären also nicht die Healthcare Events die Trigger, sondern die CDA Upload Events. Varianten der Erzeugung sind: Explizite Erzeugung aus IHE oder CDA Metadaten Parsen der Klassifikationsinhalte und Zeitstempel der CDA Dokumente Aufzählungsliste 32: Varianten der Erzeugung von Healthcare Events Natürlich bedingt auch dieser Ansatz einen hohen CDA Implementationslevel (> 2). Grundsätzlich sollten sich auf diese Weise aber Healthcare Events erzeugen lassen. Seite 93 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

108 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Abbildung 12. Schema des Dokumentenuploads mit Parsen zur Abbildung auf semantisches Zielsystem In der Abbildung oben ist der Gesamt-Workflow des Dokumentenuploads beschrieben. Im letzten Sequenzabschnitt erfolgt ein parsen des Dokuments zur Abbildung in das vordefinierte semantische Zielsystem. Die Grafik veranschaulicht den stufenweisen Ausbau eines solchen Systems durch Erhöhung der Dokumentstrukturiertheit. Durch enge Synchronisation des Mappings auf das semantische Zielsystem lässt sich pro Iterationsstufe die Feingranularität der klinischen Daten der eepa erhöhen. Grundsätzliche Herausforderungen: Die Ontologie muss so gestaltet werden, dass klinisch relevante Abfragen möglich sind. Der beschriebene Ansatz kann nur dann erfolgreich sein, wenn standardisierte Healthcare Ontologien entwickelt und eingesetzt werden. Entsprechende Ansätze sind nicht bekannt. Aufzählungsliste 33: Herausforderungen zur Erzeugung von Healthcare Events zum Zeitpunkt des Dokumentupdates Seite 94 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

109 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Einschränkungen bei verschlüsselten Daten und Meta-Daten Verschlüsselte Dokumente und verschlüsselte Metadaten sollen es einem unbefugten Benutzer unmöglich machen gezielt nach klinisch aufschlussreichen Patienteninformationen zu suchen. Unglücklicherweise ist das aber auch genau die Funktionalität, die es dem Arzt ermöglichen würde, gezielt Dokumente für einen nachgelagerten Download ins Primärsystem vorzuselektieren. Liegen Metadaten nur verschlüsselt vor, so ergeben sich erhebliche Einschränkungen für die zuvor in diesem Kapitel beschriebenen Funktionalität: Die serverseitige Analyse der CDA-Dokumente beschränkt sich auf die nicht verschlüsselten Attribute der IHE Metadaten. Jegliche Nutzung von Healthcare Events ist unmöglich gemacht. Aufzählungsliste 34: Einschränkungen der Funktionalität Als Workaround bleibt nur der Download aller Dokumente. Nach anschließender Entschlüsselung im Beisein des Patienten, der dies mit seinem Schlüssel unterstützen muss, kann die beschriebene Funktionalität dann nur im Primärsystem durchgeführt werden. Seite 95 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

110 7 Mehrwertanwendungen und Aktenanalysen auf granularer Ebene Seite 96 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

111 8 Sonstige spezifische Mehrwertanwendungen 8 Sonstige spezifische Mehrwertanwendungen 8.1 Transition Die geplante und gezielte Überführung von Jugendlichen und jungen Erwachsenen mit chronischen Erkrankungen von Pädiatern zu Erwachsenenmedizinern (Transition) ist ein bislang unzureichend gelöstes Problem in der Versorgungsmedizin. Die hohe Zahl der Betroffenen unterstreicht die Bedeutung dieser Thematik. Die Gesellschaft für Sozialpädiatrie und Jugendmedizin e. V. gibt an, dass 1,3 Millionen Kinder und Jugendliche in Deutschland chronisch erkrankt sind und voraussichtlich mehr als 90 Prozent von diesen werden das Erwachsenenalter erreichen. Der Aufbau einer organisationsübergreifenden kontinuierlichen Betreuung des Patienten vom Pädiater bis hin zum Erwachsenenmediziner ist daher sowohl aus medizinischer Sicht, als auch aus gesundheitsökonomischer Sicht, sehr bedeutsam. Die Transition weist aktuell noch viele Problemstellungen und Herausforderungen auf. Viele der chronisch erkrankten Jugendlichen verlieren im Prozess der Transition den Kontakt zur Spezialversorgung. Neben den negativen Auswirkungen (z. B. Transplantatsverlust) für die medizinische Situation des Patienten ist dies mit hohen Krankheitskosten verbunden. In Deutschland ist die Transition bisher nicht einheitlich geregelt. Ein geplanter Übergang in eine erwachsenenmedizinische Spezialbetreuung erfolgt nur für einzelne Krankheitsbilder auf der Basis lokaler Initiativen. Das Berliner Transitionsprogramm ist ein Strukturkonzept, das auf unterschiedliche Krankheitsbilder, verschiedene Versorgungsstrukturen (Spezialambulanzen, Schwerpunktpraxen u. a.) sowie unterschiedliche Regionen übertragbar ist und das eine geregelte Kostenübernahme der transitionsspezifischen Leistungen im Rahmen eines IV-Vertrages durch die Krankenkassen vorsieht. Maßnahmen und Instrumente zielen darauf ab, möglichst umfangreich und nachhaltig die Fähigkeiten zum Selbstmanagement zu fördern und den Jugendlichen die größtmögliche Selbstständigkeit zu ermöglichen. Erfahrungen im Berliner Transitionsprogramm zeigen, dass die Epikrise als zentrales Element für den Informationstransfer an weiterbehandelnde Ärzte in den Vordergrund rückt. Andere Werkzeuge wie z. B. Fallkonferenzen oder gemeinsame Sprechstunden werden wegen des damit verbundenen hohen zeitlichen Aufwandes nur selten genutzt. Die Erstellung von Epikrisen von chronisch erkrankten jungen Erwachsenen für die Übergabe an weiterbehandelnde Ärzte stellt bisher noch eine große Herausforderung dar. Keine oder eine mangelhafte Informationsweitergabe wirkt sich negativ auf die Behandlungsqualität des Patienten aus. Gemeinsam mit den verschiedenen Fachgesellschaften wird daher eine Einigung auf die Inhalte einer Epikrise bzw. eines Transitionsbriefes getroffen. Im Rahmen des Projekts ist es ein Ziel auf Basis der inhaltlichen Einigung einen standardisierten elektronischen Transitionsbrief zu spezifizieren. Der zu entwickelnde Implementierungsleitfaden soll im Hinblick auf die Zukunftsfähigkeit auf dem CDA Arzt- Seite 97 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

112 8 Sonstige spezifische Mehrwertanwendungen brief basieren. Dieser wird um transitionsspezifische Inhalte ergänzt. Im Zuge der Spezifikation wurde eine Reihe von Informationsinhalten/Informationsabschnitten identifiziert, die in der Dokumentenontologie ergänzt werden sollen, um eine semantische Vereinheitlichung der Abschnitte zu erreichen Informationsobjekte aus der Mehrwertanwendung heraus Die Analyse der elektronischen Epikrisen verschiedener Fachgesellschaften hat ergeben, dass die in der nachfolgenden Tabelle dargestellten Informationsobjekte wesentlich sind und in der Dokumentenontologie berücksichtigt werden müssen. Informationsobjekt Transitionsbrief Mobilität Psychosoziale Aspekte Bisherige Förderungsmaßnahmen Ausbildung und Beruf Grad der Behinderung Gesetzliche Betreuung Partnerschaft und Sexualität Aktueller Beruf Schichtarbeit Potentielles arbeitsassoziiertes Gefährdungspotential Behindertengerechter Arbeitsplatz Erweiterter Kündigungsschutz Ketogene Diät Einnahme Lebensmittel Kinderwunsch Kinder Beschreibung Spezielle Form des Arztbriefes, welcher bei der Überführung von Kindern und Jugendlichen in die Erwachsenenmedizin erstellt wird. Ein Abschnitt im Transitionsbrief, welcher angibt welche Fahrerlaubnis der chronisch kranke Jugendliche hat. Ein Abschnitt im Transitionsbrief, welcher die psychosozialen Aspekte des chronisch kranken Jugendlichen beschreibt. Ein Abschnitt im Transitionsbrief, der die bisherigen Fördermaßnahmen des chronisch kranken Jugendlichen darstellt (z. B. Logopädie). Ein Abschnitt im Transitionsbrief, der Informationen zum bisherigen Werdegang und der aktuellen beruflichen/schulischen Situation des chronisch kranken Jugendlichen wiedergibt. Ein Abschnitt im Transitionsbrief, der Informationen zu Behinderungen des chronisch kranken Jugendlichen beinhaltet. Ein Abschnitt im Transitionsbrief, der angibt in welchen Angelegenheiten (Gesundheitsfürsorge, Vermögensangelegenheiten etc.) der chronisch kranke Jugendliche gesetzlich betreut wird. Ein Abschnitt im Transitionsbrief, der Informationen zu Partnerschaft, Kinderwunsch und Verhütung umfasst. Ein Unterabschnitt im Abschnitt Ausbildung und Beruf, der Informationen zum aktuellen Beruf des chronisch kranken Jugendlichen wiedergibt. Ein Parameter des Abschnitts aktueller Beruf, welcher angibt, ob der chronisch kranke Jugendliche Schichtarbeit leistet. Ein Parameter des Abschnitts aktueller Beruf, welcher potentielle Gefährdungspotentiale der aktuellen Arbeit des chronisch kranken Jugendlichen beschreibt. Ein Parameter des Abschnitts aktueller Beruf, der angibt ob der aktuelle Arbeitsplatz eines chronisch kranken Jugendlichen behindertengerecht ist. Ein Parameter des Abschnitts aktueller Beruf, der angibt ob der chronisch kranke Jugendliche einen erweiterten Kündigungsschutz hat. Ein Abschnitt im Transitionsbrief der angibt, ob der Patient eine ketogene Diät gehalten hat und wenn ja, den Diätplan und die erzielte Wirkung beschreibt. Ein Unterabschnitt des Abschnitts ketogene Diät welcher angibt, ob eine Angabe (g oder kcal) eines Lebensmittels pro/tag oder pro/mahlzeit gezählt wird. Für Angabe der Lebensmittel innerhalb des Abschnitts ketogene Diät werden Codes zur Unterscheidung zwischen Fett, Protein und Kohlenhydraten benötigt. Ein Unterabschnitt im Abschnitt Partnerschaft und Sexualität, welcher angibt ob ein Kinderwunsch besteht. Ein Unterabschnitt im Abschnitt Partnerschaft und Sexualität, welcher angibt ob der Patient Kinder hat. Seite 98 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

113 8 Sonstige spezifische Mehrwertanwendungen Informationsobjekt Verhütungsmethode Beschreibung Ein Unterabschnitt im Abschnitt Partnerschaft und Sexualität, welcher angibt welche Verhütungsmethode benutzt wird. Tabelle 33: Benötigte Informationstypen für die Transition Anforderungen an Fachdienste Für die Unterstützung bei der Erstellung des Transitionsbriefes können Inhalte, die ohnehin in der eepa gespeichert sind, für dessen Erstellung genutzt werden. Anhand der semantisch eindeutigen Informationstypen können diese Informationen gefiltert und in die benötigte CDA Struktur eingefügt werden. Ein Mehrwertdienst für die Unterstützung der Erstellung des Transitionsbriefes könnte in Form eines digitalen Formulars umgesetzt werden. Anhand des Schemas für einen CDA Transitionsbrief können Felder im Formular mit bestehenden Informationen aus der eepa vorausgefüllt werden. Der Anwender,in der Regel der Pädiater, kann diese Informationen prüfen, aktualisieren und ggf. ergänzen. Nach Bestätigung der Daten kann ein ETransitionsbrief generiert werden, welcher als Informationsobjekt in die eepa eingestellt wird und bei entsprechenden Zugriffsberechtigungen dem weiterbehandelnden Erwachsenenmediziner zur Verfügung steht. Gemeinsam mit Vertretern der Fachgesellschaften, dem Fraunhofer ISST und der HL7- Benutzergruppe e.v. wird aktuell (Jan. 2013) eine Spezifikation eines ETransitionsbriefs auf Basis von HL7 CDA erarbeitet. Die Spezifikation befindet sich noch in Bearbeitung und kann auf der HL7- Wiki Seite eingesehen werden Zentrale Tumordokumentation in der eepa und Meldung an das Krebsregister Eine komplette Dokumentation bei Tumorerkrankungen erfordert die Zusammenarbeit von erstbehandelnder federführender Klinik und allen an der Therapie mitbeteiligten Kliniken, pathologischen Instituten und niedergelassenen Ärzten. In den medizinischen Einrichtungen wird die Tumordokumentation aktuell in verschiedenen Systemen erfasst und gepflegt, was zu redundanter Datenhaltung und hohem administrativen Aufwand bei der Zusammenführung der Daten führt. Darüber hinaus ist die Standardisierung der Daten auch in Richtung eines Datenqualitätsmanagement bislang mangelhaft. Die Schaffung einer gemeinsamen Datenbasis für die Tumordokumentation über die eepa unterstützt die kooperative und behandlungsbegleitende Entwicklung der Tumordokumentation Seite 99 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

114 8 Sonstige spezifische Mehrwertanwendungen Folgende Anwendungsfälle spielen u. a. im Rahmen der Tumordokumentation eine Rolle: Ersterhebung nach Erstbehandlung Verlaufsdokumentation Abschlussdokumentation Änderung der Diagnose Export an Register und Wissensdatenbanken Aufzählungsliste 35: Anwendungsfälle der Tumordokumentation Das Krebsregistergesetz NRW regelt die Krebsregistrierung für ganz NRW. Seit dem 1. Juli 2005 sind alle Ärzte verpflichtet Krebserkrankungen zu melden. Zu diesem Zweck wird in NRW ein Epidemiologisches Krebsregister geführt sowie aktuell klinische Krebsregister aufgebaut. Die Datenübermittlung an dieses Krebsregister erfolgt ausschließlich elektronisch und in pseudonymisierter Form. Das Krebsregister nutzt die Datengrundlage, um Analysen zur Optimierung der Krebstherapie durchzuführen (z. B. Ursachenforschung, Bewertung verschiedener Therapieverfahren). Viele Kliniken nutzen für die Meldung an das Tumorregister den ADT Basisdatensatz. Dabei handelt es sich um einen einheitlichen onkologischen Basisdatensatz für alle Krebsarten, der in Zusammenarbeit mit den epidemiologischen Krebsregistern, der Deutschen Krebsgesellschaft der Deutschen Krebshilfe, den Leistungserbringern und der Politik entstanden ist. Ziel des Standards ist die bundesweite organisationsübergreifende vergleichbare Erfassung und Auswertung von Krebsbehandlungen. Die oben beschriebene zentrale Tumordokumentation in der eepa könnte die Basis für die Datenübermittlung an das Krebsregister bilden Informationsobjekte aus der Mehrwertanwendung heraus Für die Tumordokumentation sowie die Meldung an das Krebsregister sind verschiedene Informationen relevant. Eine Tumordokumentation nach dem ADT Basisdatensatz umfasst beispielsweise folgende Module, die im Rahmen der eepa abgebildet werden müssen: Patientendaten o Patienten-ID o Krankenkasse o Telefon o Name o Geschlecht o Geburtsdatum o Staatsangehörigkeit o Straße o PLZ/Ort Tumorspezifische Basisdaten o Meldende Institution Seite 100 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

115 8 Sonstige spezifische Mehrwertanwendungen o Tumordiagnose (ICD) o Datum der Wiedervorstellung o Ort der Wiedervorstellung o Zentrumspezifische Items o Datum (Datum der Dokumentation durch den Arzt) o Unterschrift des Arztes o Datum (Datum der Dokumentation durch den MDA) o Unterschrift MDA o Tumordiagnose (ICD 10) o Diagnosedatum o Diagnosesicherheit o Hauptlokalisation, Seitenlokalisation, Nebenlokalisation o Frühere Tumorerkrankungen o Diagnoseanlass o Chemotherapie in der Anamnese o Strahlentherapie in der Anamnese o Wichtige Begleiterkrankungen Tumorspezifische histologische Daten o Pathologisches Institut o Histologie-Einsendenummer, Histologie-Datum o Histologie o Grading o Anzahl der untersuchten Lymphknoten o Anzahl der befallenen Lymphknoten o Anzahl der untersuchten Sentinel-Lymphknoten o Anzahl der befallenden Sentinel-Lymphknoten o Lymphgefäßinvasion o Veneninvasion Tumorklassifikation o Klinischer TNM o Pathologischer TNM o Ann Arbor Klassifikation o Anderes Stadium Binet o Anderes Stadium Rai o Anderes Stadium FAB o Anderes Stadium CML o Anderes Stadium Durie und Salmon Verlaufsdaten o Untersuchungs-Datum o Stationär o Ambulant Seite 101 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

116 8 Sonstige spezifische Mehrwertanwendungen o Zustand nach Primärtherapie o Zustand nach Rezidivtherapie o Beginn der Primärtherapie o Beginn der Rezidivtherapie o Therapien o Untersuchungsanlass o Allgemeiner Leistungszustand o Untersuchungen o Gesamtbeurteilung des Tumorstatus o Tumorausbreitung o Abweichung von Leitlinien Operationen o Mikroskopische Sicherung der Malignität vor Operationen o Operationen o OP-Datum o Ziel o Komplikationen Strahlentherapie o Zielgebiet o Applikationsart o Seite o Beginn o Ende o Gesamtdosis o Intention o Beendigung der Strahlentherapie o Nebenwirkungen nach CTC (Common Toxicity Criteria) Systemische Therapie o Systemische Therapie (Therapieart) o Intention o Protokoll o Zyklen geplant o Zyklen durchgeführt o Beginn o Substanzen o Dosisreduktion o Unterbrechung vom o Unterbrechung bis o Gründe der Unterbrechung o Beendigung der systemischen Therapie o Erfolg Seite 102 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

117 8 Sonstige spezifische Mehrwertanwendungen o Nebenwirkungen nach WHO-Grade o Gleichzeitig Strahlentherapie Abschlussdaten o Nachsorge abgeschlossen o Nachsorge abgebrochen o Gesamtbeurteilung des Tumorstatus o Vitalstatus o Patient verstorben o Autopsie durchgeführt Autopsiedaten TNM o Datum der Autopsie o TNM-Klassifikation Autopsiedaten sonstige Klassifikationen o Ann Arbor Klassifikation o Anderes Stadium Binet o Anderes Stadium Rai o Anderes Stadium FAB o Anderes Stadium CML o Anderes Stadium Durie und Salmon Autopsiedaten Tumorhistologie o Pathologische Institut, Histologie-Datum, Histologie o Grading o Anzahl der untersuchten/befallenen Lymphknoten o Lymphgefäßinvasion o Veneninvasion o Tumorausbreitung Aufzählungsliste 36: Module einer Tumordokumentation Die modulare Struktur der Tumordokumentation kann ebenfalls auf die eepa abgebildet werden. Hierfür ist es erforderlich, dass sämtliche Informationen neben der Tumordokumentation als Typ in die Dokumentenontologie aufgenommen werden. Zudem sind Relationen zwischen Dokumenten/Informationsobjekten umzusetzen. Die Projektgruppe Onkologische Datenübermittlung hat in Kooperation mit der HL7-Benutzergruppe e.v. eine Spezifikation der Tumordokumentation auf Basis von HL7 CDA erarbeitet. Anforderungen aus dem ADT Basisdatensatz sind ebenfalls in die Spezifikation mit eingeflossen. Die Spezifikation befindet sich aktuell (Jan. 2013) in Bearbeitung und kann auf der HL7-Wiki Seite eingesehen werden Seite 103 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

118 8 Sonstige spezifische Mehrwertanwendungen Anforderungen an Fachdienste Um eine Schnittstelle der eepa zum Tumorregister zu schaffen, sind übergeordnete Funktionalitäten umzusetzen. Es müssen Exportmechanismen unterstützt werden, die die Anforderungen seitens der Krebsregister erfüllen. Bereits in der Akte befindliche Daten können für die Generierung des Datensatzes für das Krebsregister identifiziert und genutzt werden. Für die meldende Einrichtung kann beispielsweise ein formularbasierter Fachdienst zur Eingabe des Datensatzes für das Krebsregister umgesetzt werden. Daten, die für eine Meldung relevant und bereits in der eepa vorhanden sind, können zur Vorbefüllung des Formulars verwendet werden. Ein Arzt hat die Möglichkeiten diese Daten zu überprüfen, zu ergänzen und dann als strukturieren Datensatz zu exportieren und an das Krebsregister zu senden. Eine wichtige Rolle spielt zudem die Pseudonymisierung von Versorgungsdaten. 8.3 Integration von Informationsobjekten aus der eepa in klinische Behandlungspfade Im Rahmen von AP06 wird das Thema der Klinischen Behandlungspfade adressiert. Klinische Behandlungspfade stellen eine zeitliche Abfolge von medizinischen Behandlungsschritten dar. Zur Durchführung dieser Behandlungsschritte sind in der Regel unterschiedliche Informationen erforderlich. Eine Radiologische Befundung setzt beispielsweise voraus, dass die radiologischen Bilder vorliegen. Diese Informationen können einerseits aus den Primärsystemen oder andererseits aus der eepa gelesen werden. Um eine IT-gestützte Bereitstellung benötigter Informationen umzusetzen ist es notwendig, dass der Behandlungsschritt um die Information, welcher als Informationsinput für den Behandlungsschritt benötigt wird, strukturiert und semantisch annotiert erweitert wird. Für den Behandlungsschritt Radiologische Befundung bedeutet dies, dass eine strukturierte Erweiterung existiert, die angibt, dass ein Dokument vom Typen radiologisches Bild benötigt wird. Diese Information kann dann automatisch aus der eepa geladen und angezeigt werden. Es können zusätzlich weitere Rahmenbedingungen definiert werden. Insbesondere sind zeitliche Aspekte von medizinischen Informationen zu berücksichtigen Informationsobjekte aus der Mehrwertanwendung heraus Die Informationsobjekte sind vom Anwendungsfall abhängig. Prozessrelevante Informationstypen müssen in der Domänenontologie berücksichtigt werden ( Anforderungen aus AP06) Anforderungen an Fachdienste Es werden Dienste benötigt, die in der Lage sind, den Informationskontext von Prozessen (Input, Output) zu bewerten und entsprechende Suchanfragen an die eepa zu senden. Es besteht zudem die Anforderung, dass bei der Modellierung der klinischen Behandlungspfade die Informationsflüsse strukturiert dargestellt werden. Für die semantische Beschreibung der Informationen ist auf eine gemeinsame Ontologie zurückzugreifen. Seite 104 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

119 9 Technische Spezifikationen 9 Technische Spezifikationen Die technische Spezifikation dieser Use Cases wird in Zusammenarbeit mit der IHE Redaktion auf Basis des IHE Standards erstellt. Die Zielgruppe der technischen Spezifikation sind die Produktmanager von Primärsystemen. 9.1 Verwendung von IHE Profilen In der nachfolgenden tabellarischen Übersicht werden die für die Spezifikation genutzten Profile aufgelistet und kurz beschrieben. IHE Profil IHE Cross-Enterprise Document Sharing (XDS) IHE Patient Identifier Cross-referencing (PIX) IHE Patient Demographics Query (PDQ) IHE Cross-Community Access (XCA) IHE Healthcare Provider Directory (HPD) IHE Basic Patient Privacy Consents (BPPC) Kurze Beschreibung IHE XDS ermöglicht den einrichtungsübergreifenden Dokumentenaustausch. Dokumente (also auch Bilder und andere binäre Objekte) werden in einer einrichtungsübergreifenden Patientenakte registriert und gespeichert und können abgerufen werden. IHE PIX ermöglicht die Verknüpfung von Patientenkennungen in einem Netzwerk von Einrichtungen, die für einen Patienten jeweils eigene Kennungen vergeben. Dafür werden dem sogenannten Patient Identifier Cross-reference Manager (PIX Manager) demografische Patientendaten und IDs übergeben. IHE PDQ ermöglicht die Abfrage von Patientendaten auf Basis von deren demografischen Informationen, d.h. die Identifikatoren eines Patienten werden anhand vorhandener Informationen erfragt. IHE XCA ermöglicht die netzwerkübergreifende Kommunikation über Gateways. IHE HPD ermöglicht die Verwaltung und Abfrage eines Verzeichnisses mit Informationen zu Leistungserbringern im Gesundheitswesen. Das IHE BPPC ermöglicht es, die Zustimmung des Patienten zum Austausch seiner personenbezogenen Daten in einem Netzwerk kooperierender Einrichtungen festzuhalten. Tabelle 34: Verwendete IHE Profile Seite 105 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

120 9 Technische Spezifikationen 9.2 Technische Use Cases Die nachfolgend beschriebenen Use Cases leiten sich aus den in Kapitel 6.2 beschriebenen fachlichen Anforderungen ab. Für die einzelnen Use Cases werden Vorbedingungen, Akteure/Systemkomponenten, Ablauf, Trigger sowie Nachrichtenstrukturen (Anfrage/Antwort) beschrieben. Use Case Patient identifizieren (PIX) Patient identifizieren (PDQ) Akte anlegen Demografische Daten halbautomatisch aktualisieren Einwilligungserklärung Patient Aktenticket erzeugen Aktenmoderator bestimmen Akte sperren Akte entsperren Akte löschen Zugriffsberechtigung Akte erteilen Zugriffsberechtigung Akte entziehen Dokument einstellen Dokumentenliste abrufen Dokument abrufen Dokument aktualisieren Dokument verschieben Dokument einem weiteren Ordner zuordnen Dokument entfernen Dokument sperren Dokument entsperren Dokument löschen Dokumentenliste aus entfernter Domain abrufen Dokument aus entfernter Domain abrufen Anmerkung zur Umsetzung Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Technische Spezifikation ist Bestandteil AP01 Technische Spezifikation ist Bestandteil AP01 Technische Spezifikation ist Bestandteil AP01 Technische Spezifikation ist Bestandteil AP01 Technische Spezifikation ist Bestandteil AP01 Im AP04 Kompendium spezifiziert Technische Spezifikation ist Bestandteil AP01 Technische Spezifikation ist Bestandteil AP01 Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Wird in der 1. Phase nicht berücksichtigt Wird in der 1. Phase nicht berücksichtigt Wird in der 1. Phase nicht berücksichtigt Technische Spezifikation ist Bestandteil AP01 Technische Spezifikation ist Bestandteil AP01 Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Im AP04 Kompendium spezifiziert Tabelle 35: Übersicht über die technischen Use Cases Seite 106 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

121 9 Technische Spezifikationen Patient identifizieren (PIX) Dieser Use Case beschreibt die Identifikation von Patienten bei Verwendung des IHE PIX Profils. Vorbedingungen Patient wurde angelegt Akteure (Systemkomponenten) Patient Identifier Cross-Reference (PIX) Consumer: Systemkomponente, die anhand der lokalen Patienten-ID die domänenweite Patienten-ID holt. PIX Manager: Systemkomponente, welche die lokale Patienten-ID verwaltet und für jeden Patienten einen domänenweiten MPI erzeugt. Policy Enforcement Point (PIX Manager): Mit dem PIX Manager gruppierte Systemkomponente, die prüft, ob die Abfrage der domänenweiten Patienten-ID zulässig ist. Ablauf Abbildung 13: Ablaufdiagramm Patient anhand der Patienten-ID identifizieren Patient/Akte identifizieren Das Primärsystem oder das Portal ruft in der Rolle des PIX Consumers die Transaktion PIX Query auf. Hierbei sind zwei Alternativen möglich: ITI-9 (HL7v2-Spezifikation: ITI Volume 2a, Kapitel 3.9) und ITI-45 (HL7v3-Spezifikation: ITI Volume 2b, Kapitel 3.45). Der PIX Manager fragt beim Policy Enforcement Point an, ob die Abfrage zulässig ist. Wenn erlaubt, ruft der PIX Manager die domänenweite Patienten-ID ab und liefert diese an den PIX Consumer zurück. Häufig ist die PIX/PDQ Cross- Reference Domäne mit der XDS-Affinity Domäne identisch. Andernfalls muss angegeben werden, welche MPI aus welcher Affinity Domäne zurückgegeben werden soll. Bei ITI-9 (PIXv2) besteht bei Seite 107 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

122 9 Technische Spezifikationen MLLP keine Möglichkeit 33, ein SAML-Ticket mitzuliefern. Daher müsste die V2-Nachricht über http(s) oder Webservices getunnelt werden. Trigger Der Anwender ruft manuell über eine entsprechende Schaltfläche die Patientensuche auf. Nachrichtenstruktur - Request (ITI-9) Bei der Transaktion wird eine HL7 2.5 Nachricht übermittelt. Diese umfasst die folgenden Segmente: MSH (Message Header) QPD (Query Parameter Definition) RCP (Response Control Parameter) Die Pflichtfelder der einzelnen Segmente können im Technical Framework nachgesehen werden (Spezifikation: ITI Volume 2a, Kapitel ). Nachrichtenstruktur - Response (ITI-9) Bei dieser Transaktion wird eine HL7 2.5 Nachricht übermittelt. Diese umfasst folgende Segmente: MSH (Message Header) MSA (Message Acknowledgement) ERR (Error segment) QAK (Query Acknowledgement) QPD (Query Parameter Definition) PID (Patient Identification) Die Pflichtfelder der einzelnen Segmente können im Technical Framework nachgesehen werden (Spezifikation: ITI Volume 2a, Kapitel ). Nachrichtenstruktur - Request (ITI-45) Bei dieser Transaktion wird eine HL7 V3 Nachricht als XML Struktur mit Hilfe eines Webservices übermittelt. Grundlage für diese Nachricht bildet HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic. Die detaillierte Struktur der Nachricht kann im Technical Framework nachgesehen werden (Spezifikation: ITI Volume 2b, Kapitel ). Nachrichtenstruktur - Response (ITI-45) Als Response wird eine HL7 V3 Nachricht übermittelt. Diese Response umfasst alle dem PIX Manager bekannten Patienten Identifier inkl. der MPID sowie entsprechende Status- und Fehlermeldungen. 33 Genaugenommen gibt es die Möglichkeit, eine SAML-Assertion als Blob in einem OBX-Segment mit zu übermitteln, was in ADT-Nachrichten zulässig ist. Seite 108 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

123 9 Technische Spezifikationen Die detaillierte Struktur der Nachricht kann im Technical Framework nachgesehen werden (Spezifikation: ITI Volume 2b, Kapitel ) Patient identifizieren (PDQ) Vorbedingungen Patient wurde angelegt (siehe UC Patient anlegen) Akteure (Systemkomponenten) Patient Demographics (PDQ) Consumer: Systemkomponente, die anhand von demografischen Daten eines Patienten eine Patientenliste liefert, die den Suchkriterien entspricht. Diese Trefferliste enthält analog zur PIX Query auch die domänenweite Patienten-ID. PDQ Supplier: Systemkomponente, die meistens mit dem PIX Manager gruppiert ist und die die demografischen Daten eines Patienten verwaltet und suchbar macht. Policy Enforcement Point (PDQ Supplier): Mit dem PDQ Supplier gruppierte Systemkomponente, die prüft ob die Abfrage der Patienten anhand demografischer Daten zulässig ist. Ablauf Abbildung 14: Ablaufdiagramm Patient anhand der demografischen Daten identifizieren Patient/Akte identifizieren (PDQ) Das Primärsystem oder das Portal ruft in der Rolle des PDQ Consumers die Transaktion Patient Demographic Query auf und übergibt dabei demografische Daten. Hierbei sind zwei Alternativen möglich: ITI-21 (Spezifikation: ITI Volume 2a, Kapitel 3.21) und ITI-47 (Spezifikation: ITI Volume 2b, Kapitel 3.47). Der PDQ Supplier fragt beim Policy Enforcement Point an, ob die Suche von Patienten entsprechend der demografischen Daten zulässig ist. Hierbei wird überprüft, ob die anfragende Per- Seite 109 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

124 9 Technische Spezifikationen son in der Rolle Gesundheitsdienstleister auftritt. Somit wird sichergestellt, dass nur Gesundheitsdienstleister die Abfrage durchführen können. Falls erlaubt, führt der PDQ Supplier die Suche durch und liefert dem PDQ Consumer eine Liste aller Patienten, die den Suchkriterien entsprechen. Es besteht die Möglichkeit über eine Konfiguration beim PDQ Supplier die maximale Anzahl von Treffern zu beschränken. Wird dieser Schwellenwert erreicht oder überschritten, wird eine entsprechende Meldung zur Verfeinerung der Suchanfrage zurückgegeben. Trigger Der Anwender ruft manuell über eine entsprechende Schaltfläche die Patientensuche auf. Nachrichtenstruktur - Request (ITI-21) Bei dieser Transaktion wird eine HL7 V2.5 Nachricht übermittelt. Diese umfasst die Segmente: MSH (Message Header) QPD (Query Parameter Definition) RCP (Response Control Parameter) DSC (Continuation Pointer) Die detaillierte Nachrichtenstruktur kann im Technical Framework nachgesehen werden (Spezifikation: ITI Volume 2a, Kapitel ). Nachrichtenstruktur - Response (ITI-21) Als Response wird bei dieser Transaktion eine HL7 V2.5 Nachricht übermittelt. Diese enthält die Liste der Patienten, die den Suchkriterien entsprechen. Die Nachricht umfasst die folgenden Segmente: RSP (Segment Pattern Response) MSH (Message Header) MSA (Message Acknowledgement) ERR (Error) QAK (Query Acknowledgement) QPD (Query Parameter Definition) PID (Patient Identification) DSC (Continuation Pointer) Die detaillierte Nachrichtenstruktur kann im Technical Framework nachgelesen werden (Spezifikation: ITI Volume 2a, Kapitel ). Nachrichtenstruktur - Request (ITI-47) Bei dieser Transaktion wird eine HL7 V3 Nachricht in einem Webservice Aufruf übermittelt. Die Nachricht enthält die demografischen Patientendaten als Suchkriterien. Die detaillierte Struktur der Nach- Seite 110 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

125 9 Technische Spezifikationen richt kann im Technical Framework nachgelesen werden (Spezifikation: ITI Volume 2b, Kapitel ). Nachrichtenstruktur - Response (ITI-47) Bei dieser Transaktion wird eine HL7 V3 Nachricht in einem Webservice Aufruf übermittelt. Die Nachricht enthält die Patientenliste, die den Suchkriterien entspricht. Die detaillierte Struktur der Nachricht kann im Technical Framework nachgelesen werden (Spezifikation: ITI Volume 2b, Kapitel ) Akte anlegen Vorbedingungen Demografische Daten liegen in entsprechender Qualität vor Akteure (Systemkomponenten) Patient Identity Source: System, welches u. a. Patienten(-identifikationen) erstellt und aktualisiert. Benachrichtigt den Patient Identifier Cross-Reference Manager und die Document Registry über neue/aktualisierte Patientenidentitäten. Patient Identifier Cross-Reference Manager: System, welches das Management von Crossreferenzen von Patientenidentitäten ermöglicht, welche die Patient Identity Sourcen zur Verfügung stellen. Document Registry: System, welches Metadaten zu den registrierten Dokumenten verwaltet und diese suchbar macht. Sie kommuniziert mit der Patient Identity Source, um sicherzustellen, dass die Dokumentenmetadaten dem richtigen Patienten zugeordnet sind. Seite 111 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

126 9 Technische Spezifikationen Ablauf Abbildung 15: Ablaufdiagramm Akte anlegen Patient aufklären Der Patient wird über die eepa aufgeklärt. Dies ist ein rein organisatorischer Schritt. In der Regel erhält der Patient papierbasierte Informationen und ein Einwilligungsformular. Patient und Akte anlegen Um eine Akte anzulegen, muss der Patient zunächst der Registry initial bekannt gemacht werden. Die XDS-Registry darf jedoch für eine bestimmte Affinity Domain nur von einem System mit Patientenidentifikationen versorgt werden. Deshalb gibt es hier entsprechend zwei Möglichkeiten, dies in einem krankenhausübergreifenden Szenario zu realisieren: Entweder füttert a) jedes System (bspw. ein Krankenhaus-KIS) seine Patientenidentifikatoren direkt über eine eigene Affinity Domain in die XDS- Registry oder überlässt dies einem Master-Patient-Index (PIX-Manager), der hier eine neue ID er- Seite 112 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

127 9 Technische Spezifikationen zeugt und diese dann bei der XDS-Registry registriert. Hierzu wird vom Primärsystem die entsprechende Nachricht an den PIX-Manager übermittelt. Der PIX-Manager legt den Patienten an und übermittelt die neue ID an die Registry weiter. Die Bekanntmachung kann sowohl über die HL7 V2 Nachricht ( Patient Identity Feed (ITI-8)) (Spezifikation: ITI Volume 2a, Kapitel 3.8) als auch über die HL7 V3 Nachricht (ITI-44) erfolgen. Beide Nachrichtentypen sind denkbar und zulässig und bieten ihre jeweiligen Vor- und Nachteile. So kann z. B. über HL7 V3 die Security- und Netzwerkkommunikation vereinfacht abgebildet werden (Netzwerkkommunikation, Firewall, Kommunikation über HTTPs und Security). Auf der anderen Seite ist HL7 V2 die im KIS-Umfeld gängige Art der Nachrichtenkommunikation. Aus diesem Grund wird für die Variante a) empfohlen, die HL7 V2- Nachricht zu verwenden, während für die Variante b) auf HL7 V3 gesetzt wird. Patienteneinwilligung registrieren Optional kann die unterschriebene und gescannte Patienteneinwilligung registriert werden. Zusätzlich muss dazu eine entsprechende technische Policy existieren. Da es sich bei der Patienteneinwilligung auch nur um ein Dokument handelt, wird dieser Use Case im Kapitel Dokument einstellen detailliert beschrieben. Trigger Für die ITI-8 sind folgende Trigger definiert, die in der Regel für die internen Abläufe genutzt werden. Die nachfolgende Tabelle zeigt auf, welche Trigger für die Anlage einer Akte genutzt werden können (ADT^A01, ADT^A04, ADT^A05). Diese Trigger könnten genutzt werden, um automatisch eine Akte anzulegen. Das Primärsystem muss in diesem Fall jedoch verhindern, dass die Nachrichten nicht an den PIX Manager weitergeleitet werden, wenn keine Patienteneinwilligung vorliegt. Event Krankenhausinterne Kommunikation Aktensystemkommunikation UC - relevant ADT^A01: Stationäre Einweisung eines Patienten Akte anlegen x ADT^A04: Ambulante Einweisung eines Patienten Akte anlegen x ADT^A05: Ankündigung einer Patienteneinweisung Akte anlegen x ADT^A08: Aktualisierung von Patienteninformationen Metadaten aktualisieren ADT^A40: Zusammenführen ( Merge") von verschiedenen Patienten Akten zusammenlegen Tabelle 36: Nutzung der HL7 v2 ADT Nachrichten für die Aktenanlage Das Anlegen der Akte geschieht typischerweise nach Aufklärung und Einwilligung des Patienten über eine entsprechende Schaltfläche. Für den Akteninhaber ist eine Default-Policy festgelegt, die es dem Akteninhaber ermöglicht, Operationen auf die Akte (z. B. Zugriffsberechtigung erteilen, Patienteneinwilligung einstellen) durchzuführen. Seite 113 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

128 9 Technische Spezifikationen Nachrichtenstruktur - Request (ITI-8) Die ADT Nachrichtenstruktur umfasst folgende Segmente: MSH (Message Header) EVN (Event Type) PID (Patient Identification) PV1 (Patient Visit) Die Pflichtfelder des Segments Message Header sind: Lfd.Nr. Section Opt. Beschreibung (Beispiel) 1 Feldtrennzeichen R 2 Weitere Trennzeichen R 3 Sendende Anwendung / Sendender Bereich R hier SendingApp 4 Sendender Prozess / Sendende Einrichtung R hier SendingFacility 5 Empfangende Anwendung / Empfangender Bereich R hier ReceivingApp 6 Empfangender Prozess / Empfangende Einrichtung R hier ReceivingFacility innerhalb Bereich 7 Zeitpunkt Nachrichtenerstellung R Nachrichtentyp und Ereigniscode R ADT A01 10 Nachrichtenkontrollnummer R Verarbeitungsmodus / Processing ID R P (steht für "Production") 12 HL7-Versionsnummer R Tabelle 37: Pflichtfelder des Message Header (MSH) Die Pflichtfelder des Segments Event Type sind: Lfd.Nr. Section Opt. Beschreibung 2 Recorded Date/Time R Tabelle 38: Pflichtfelder des Segments Event Type Die Pflichtfelder des Segments Patient Identification: Lfd.Nr. Section Subsection (Datentyp) Opt. (Beispiel) Beschreibung (Beispiel) 3 Patient Identifier List R 3.1 ID R 3.4 Affinity Domain R Im Profil: assigning authority 5 Patient Name R Patientenname, hier Max Mustermann, Name Type: L (legal name) 6 Mother's Maiden Name R+ Geburtsname der Mutter, hier Musterfrau, Name Type: B (birth name) 7 Date/Time of Birth R+ Geburtstag des Patienten 8 Administrative Sex R+ Geschlecht des Patienten Seite 114 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

129 9 Technische Spezifikationen Lfd.Nr. Section Subsection (Datentyp) Opt. Beschreibung (Beispiel) 11 Patient Address R2 Adresse des Patienten 13 Phone Number Home R2 Private Telefonnummer des Patienten 14 Phone Number Business R2 Geschäftliche Telefonnummer des Patienten Tabelle 39: Pflichtfelder des Segments Patient Identification Die Pflichtfelder des Segments Patient Visit sind: Lfd.Nr. Section Opt. Beschreibung (Beispiel) 2 Patient Class R I (steht für Inpatient ) Tabelle 40: Pflichtfelder des Segments Patient Visit Hier müssen wir noch einmal auf die Verwendung und Vergabe der globalen ID zu sprechen kommen. MSH ^~\& SendingApp SendingFacility ReceivingApp ReceivingFacility ADT^A01^ADT_A P EVN PID ID^^^AssigningAuthority^^^MR Mustermann^Max^^^^^L Musterfrau^^^^^^B M PV1 I Tabelle 41: Codebeispiel ADT^A01(ITI-8) Nachrichtenstruktur - Response (ITI-8) Siehe Spezifikation: ITI Volume 2a (Kapitel 3.8) Demografische Daten halbautomatisch aktualisieren Vorbedingungen Patient ist registriert (UC Akte anlegen) Akteure (Systemkomponenten) PIX Manager Patient Identity Source Ablauf Die Patient Identity Source meldet aktualisierte demografische Daten eines Patienten an den PIX Manager. Dabei wird die Transaktion Patient Identity Feed mit einer ADT A08 Nachricht ausgelöst (Spezifikation: ITI Volume 2a, Kapitel 3.8). Seite 115 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

130 9 Technische Spezifikationen Trigger Sobald demografische Daten eines registrieren Patienten im Primärsystem aktualisiert worden sind, wird die Transaktion ausgelöst. Es muss konfigurierbar sein, dass die Transaktion nicht aufgerufen wird, wenn der Patient nicht zugestimmt hat. Nachrichtenstruktur - Request Siehe UC Akte anlegen. Es wird im Gegensatz zu UC Akte anlegen eine ADT A08 versendet. Nachrichtenstruktur - Response Siehe UC Akte anlegen Akte löschen Für das Löschen einer Akte gibt es in IHE XDS bisher keine entsprechende Transaktion. Für eine technische Umsetzung einer eepa kann die Spezifikation der Elektronischen Fallakte für das Schließen von Akten berücksichtigt werden 34. IHE arbeitet derzeit an einer Erweiterung von XDS unter dem Namen XDS Metadata Update mit dem ein neuer Akteur namens Document Administrator eingeführt wird. Dieser Document Administrator soll zwei neue Transaktionen ausführen, die Update Document Set [ITI-57] und Delete Document Set [ITI-62] genannt werden. Bei letzterem ist allerdings zum aktuellen Stand (Feb. 2014) nicht klar, ob dabei nur die Metadaten oder auch ganze Dokumente gelöscht werden können Dokument einstellen Wenn man vom dem Einstellen eines Dokumentes oder eines Informationsobjektes in eine Akte spricht, bedeutet das auf technischer Ebene, dass man das Dokument mit seinen Metainformationen der Registry bekannt macht. Vorbedingungen Akte wurde angelegt (siehe UC Akte anlegen) Patienteneinwilligung zum Einstellen von Dokumenten liegt vor (siehe UC Zustimmung erteilen) Akteure (Systemkomponenten) Document Source: System, welches Dokumente zur Registrierung freigibt. Document Repository oder integriertes Dokumenten Source/Repository: Ein Speicherort für Dokumente, welcher Metadaten an eine Registry überträgt. Document Registry: System welches Dokumente registriert. Die Registry empfängt und speichert Metainformationen zu Dokumenten Seite 116 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

131 9 Technische Spezifikationen Ablauf Abbildung 16: Ablaufdiagramm Dokument einstellen Dokument einstellen Das Dokument wird im Primärsystem zur Registrierung freigegeben. Es wird die Transaktion Provide and Register Document Set (ITI-41) durch das Primärsystem in der Rolle Document Source aufgerufen (Spezifikation: ITI Volume 2b, Kapitel 3.41). Hierbei wird das Dokument gemeinsam mit den XDS Metadaten an das Repository übermittelt. Das Document Repository prüft anhand hinterlegter Polices, ob das Dokument in die eepa gespeichert werden darf. Falls erlaubt, wird das Dokument in dem Document Repository im Speicherort (Datenbank oder Filesystem) abgespeichert. Das Repository aktualisiert Teile der Metadaten, die sich aufgrund des abgespeicherten Dokumentes ergeben (z. B. Hash, Size). Anschließend ruft das Document Repository die Transaktion Register Document Set (ITI-42) auf und übergibt die aktualisierten XDS Metadaten (Spezifikation: ITI Volume 2b, Kapitel 3.42). Die Document Registry meldet dem Document Repository den Register-Status. Das Document Repository gibt an den Document Consumer eine Rückmeldung mit dem Gesamtergebnis der Transaktionen. Seite 117 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

132 9 Technische Spezifikationen Trigger (ITI-41) Die Transaktion wird von der Document Source entweder durch eine manuelle (über eine Schaltfläche) oder automatische Interaktion (hinterlegtes Regelwerk) ausgelöst. Hierbei wird ein Dokumentoder werden ggf. mehrere Dokumente in die eepa eingestellt. Nachrichtenstruktur - Request (ITI 41) Das Dokument wird in einer Transaktion (Document Submission Set) gemeinsam mit den Metadaten übermittelt. Die Metadaten befinden sich in der Übersicht im Anhang Weitere Informationen zur Nachrichtenstruktur können in der Spezifikation nachgelesen werden (Spezifikation: ITI Volume 2b, Kapitel ). Nachrichtenstruktur - Response (ITI 41) Ein ITI-41 Response wird an die Document Source übermittelt, sobald die Metadaten des Dokuments in der Document Registry hinterlegt wurden. Die Response enthält alle Status- und Fehlermeldungen des gesamten Einstellungsprozesses (von der Document Registry und der Document Repository). Trigger (ITI-42) Das Repository hat das Dokument erfolgreich im Speicherort abgelegt und löst die Transaktion ITI 42 Register Document Set aus. Nachrichtenstruktur - Request (ITI 42) Die XDS Metadaten des eingestellten Dokuments werden in dieser Transaktion in einer ebxml Nachricht an die Document Registry übermittelt. Für Aufbau der Metadaten siehe Mapping XDS CDA. Nachrichtenstruktur - Response (ITI 42) Die Response beinhaltet Status und Fehlermeldungen. Die genaue Spezifikation der Nachrichtenstruktur wird in der Spezifikation: ITI Volume 2b, Kapitel in beschrieben Dokumentenliste abrufen Bevor man die Dokumente abrufen kann, muss man sich einen Überblick über die vorhandenen Dokumente verschaffen. Dies geschieht, in dem man eine Liste von Dokumenten abruft. Vorbedingungen Akte muss angelegt sein (siehe UC Akte anlegen) Die domänenweite Patienten-ID muss bekannt sein (siehe UC Patient identifizieren) Die Affinity Domain muss bekannt sein Es muss eine technische Policy existieren, die den Patientenwillen ausdrückt und ggf. Einschränkungen in der Abfrage definiert (siehe UC Zustimmung erteilen) Seite 118 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

133 9 Technische Spezifikationen Akteure (Systemkomponenten) Document Consumer: Systemkomponente, welche Dokumentenabfragen durchführt. In der Regel ist dies das Primärsystem. Document Registry: System, welches Metadaten zu den registrierten Dokumenten verwaltet und diese suchbar macht. Sie kommuniziert mit der Patient Identity Source, um sicherzustellen, dass die Dokumentenmetadaten dem richtigen Patienten zugeordnet sind. Policy Enforcement Point: Komponente des Access Control Systems, gruppiert mit der Document Registry. In diesem Use Case nimmt der Policy Enforcement Point eine Filterung der abgefragten Dokumentenliste anhand hinterlegter Policies (vom Patienten definierte Einschränkungen) vor. Ablauf Abbildung 17: Ablaufdiagramm Dokumentenliste abrufen Dokumentenliste abrufen Das Primärsystem sendet in der Rolle Document Consumer im Rahmen der ITI-18 Transaktion eine FindDocuments Abfrage (Spezifikation: ITI Volume 2a, Kapitel ). Die Dokumentensuche kann anhand der unten beschriebenen Parameter vom Arzt abhängig von der konkreten medizinischen Fragestellung eingeschränkt werden. Pflichtparameter ist die Patienten-ID. Werden keine weiteren Parameter eingegeben, erfolgt eine Suche nach allen Dokumenten zu diesem Patienten. Die Document Registry führt die Suche aus. Die Liste der Ergebnisse (XDS Document Entry Objects) wird durch einen mit der Document Registry gruppierten Policy Enforcement Point gefiltert. Diese Filterung erfolgt anhand der technischen Policies, die die gewünschten Einschränkungen des Patienten wiederspiegeln. Die gefilterte Liste wird dem Primärsystem (Document Consumer) zurückgeliefert. Seite 119 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

134 9 Technische Spezifikationen Trigger Der Gesundheitsdienstleister sucht im System nach Dokumenten zu seinem Patienten. Die Transaktion wird über eine Schaltfläche manuell ausgelöst, um ggf. Suchparameter zu berücksichtigen. Nachrichtenstruktur - Request Für den Abruf der Dokumentenliste wird die Methode FindDocuments der ITI-18 Transaktion genutzt. Die Suchanfrage kann mittels der in der folgenden Tabelle dargestellten Parameter eingeschränkt werden. Der Übermittlung der Suchanfrage erfolgt durch ebxml Nachrichten gemäß ITI-18 Find Documents Spezifikation. Parameter Name Attribute Opt Mult $XDSDocumentEntryPatientId XDSDocumentEntry. patientid R -- $XDSDocumentEntryClassCode1 XDSDocumentEntry. classcode O M $XDSDocumentEntryTypeCode1 XDSDocumentEntry.typeCode O M $XDSDocumentEntryPracticeSettingCode1 XDSDocumentEntry. O M $XDSDocumentEntryCreationTimeFrom $XDSDocumentEntryCreationTimeTo $XDSDocumentEntryServiceStartTimeFrom $XDSDocumentEntryServiceStartTimeTo $XDSDocumentEntryServiceStopTimeFrom $XDSDocumentEntryServiceStopTimeTo $XDSDocumentEntryHealthcareFacilityTypeC ode1 $XDSDocumentEntryEventCodeList1 $XDSDocumentEntryConfidentialityCode1 Lower value of XDSDocumentEntry. creationtime Upper value of XDSDocumentEntry. creationtime Lower value of XDSDocumentEntry. servicestarttime Upper value of XDSDocumentEntry. servicestarttime Lower value of XDSDocumentEntry. servicestoptime Upper value of XDSDocumentEntry. servicestoptime XDSDocumentEntry. healthcarefacilitytypecode XDSDocumentEntry. eventcode- List3 XDSDocumentEntry. confidentialitycode3 O -- O -- O -- O -- O -- O -- $XDSDocumentEntryAuthorPerson4 XDSDocumentEntry. author O M $XDSDocumentEntryFormatCode1 XDSDocumentEntry. formatcode O M $XDSDocumentEntryStatus XDSDocumentEntry. status R M O O O M M M Tabelle 42: Suchparameter der Transaktion ITI-18 Seite 120 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

135 9 Technische Spezifikationen Nachrichtenstruktur - Response Es werden die Metadatenobjekte der einzelnen Dokumente als XDSDocumentEntry zurückgegeben. Für jedes gefundene Dokument wird genau ein Metadatenobjekt zurückgegeben. Die Metadatenobjekte beinhalten u. a. die folgenden Informationen, die für den Dokumentenabruf benötigt werden: homecommunityid: Identifikation der Affinity Domain, die das Document Repository beinhaltet, in dem das Dokument gespeichert ist. RepositoryUniqueID: Identifikation des konkreten Document Repositories, in dem das Dokument gespeichert ist. DocumentUniqueID: Eindeutige Identifikation des Dokuments. Weitere Metadaten befinden sich in der Übersicht im Anhang A.4. Die Response-Objekte werden in ebxml-nachrichten gemäß ITI-18 Find Documents Spezifikation verpackt Dokumente abrufen Aus der Liste der Dokumente wird ein Dokument ausgewählt, um dieses dann abzurufen. Vorbedingungen Dokumentenliste wurde abgerufen (UC Dokumentenliste abrufen) Es muss eine technische Policy existieren, die den Patientenwillen ausdrückt und ggf. Einschränkungen in der Abfrage definiert (siehe UC Zustimmung erteilen) Akteure (Systemkomponenten) Document Consumer: Die ist eine Systemkomponente, welche Dokumentenabfragen durchführt. In der Regel ist dies das Primärsystem. Document Repository: Im Document Repository sind die physischen Dokumente abgespeichert. In einer Affinity Domain können mehrere Document Repositories vorhanden sein. Typischerweise ist ein Document Repository immer einer Organisation zugeordnet. Policy Enforcement Point: Dies ist eine Komponente des Access Control Systems gruppiert mit dem Document Repository. In diesem Use Case überprüft der Policy Enforcement Point ob das Dokument abgerufen werden darf. Seite 121 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

136 9 Technische Spezifikationen Ablauf Abbildung 18: Ablaufdiagramm Dokument abrufen Dokument abrufen Der Gesundheitsdienstleister wählt aus der Dokumentenliste die Dokumente aus, die abgerufen werden sollen. Dabei kann es sich um Dokumente aus unterschiedlichen Document Repositories handeln. Das Primärsystem ruft pro abzurufendem Dokument die ITI-43 Transaktion zum jeweiligen Document Repository auf (Spezifikation: ITI Volume 2b, Kapitel 3.43). Bevor das Document Repository das Dokument vom Speicherort bezieht, wird eine Anfrage an den mit dem Document Repository gruppierten Policy Enforcement Point, gesendet. Der Policy Enforcement Point entscheidet anhand hinterlegter technischer Policies, ob der Abruf des Dokuments erlaubt ist. Trigger Diese Transaktion wird durch den Gesundheitsanbieter im Primärsystem über entsprechende Schaltflächen für jeden ausgewählten Eintrag in der Dokumentenliste ausgelöst. Seite 122 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

137 9 Technische Spezifikationen Nachrichtenstruktur - Request Folgende Daten werden für die Abfrage der Dokumente benötigt: homecommunityid: Identifikation der Affinity Domain, die das Document Repository beinhaltet, in dem das Dokument gespeichert ist. RepositoryUniqueId: Identifikation des konkreten Document Repositories, in dem das Dokument gespeichert ist. DocumentUniqueId: Eindeutige Identifikation des Dokuments. Die Übermittlung des Requests erfolgt gemäß Spezifikation ITI-43 als ebxml-nachricht, welche im Webservice eingebettet ist. Nachrichtenstruktur - Response Die Response umfasst u. a.: Das Dokument in dem Format XOP Infoset (XML-binary Optimized Packaging) Der MIME type des Dokuments Fehlermeldung und Warnungen, falls das Dokument nicht erfolgreich abgerufen werden konnte Die Übermittlung der Response erfolgt gemäß Spezifikation ITI-43 als ebxml-nachricht, welche im Webservice eingebettet ist Dokument aktualisieren Eine neue Version eines bereits eingestellten Dokumentes wird eingestellt. Vorbedingungen Es muss die eindeutige ID des Metadatenobjekts des zu aktualisierenden Dokuments bekannt sein Diese ID wird als Metainformation dem neuen Metadatenobjekt mitgegeben Kennzeichnung des neuen Metadatenobjekts als Replacement (Verlinkung mit dem bereits eingestellten Dokument) Akteure (Systemkomponenten) Siehe UC Dokument einstellen Ablauf Siehe UC Dokument einstellen Trigger Es wird eine neue Version eines bereits existierenden Dokumentes im Primärsystem erstellt. Dieses soll registriert werden. Seite 123 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

138 9 Technische Spezifikationen Nachrichtenstruktur - Request Siehe UC Dokument einstellen Nachrichtenstruktur - Response Siehe UC Dokument einstellen Dokument löschen Dieser Use Case beschreibt die unwiderrufliche Löschung eines Dokumentes. Eine temporäre Sperrung einzelner Dokumente ist über das Berechtigungssystem möglich. Vorbedingungen Dokument wurde eingestellt (siehe UC Dokument einstellen) Akteure (Systemkomponenten) Document Registry: System, welches Dokumente registriert. Die Registry empfängt und speichert Metainformationen zu Dokumenten. Document Administrator: System, welches den Löschvorgang triggert. Dabei kann es sich beispielsweise um ein Portal oder ein Primärsystem handeln. Document Repository: Im Document Repository sind die physischen Dokumente abgespeichert. In einer Affinity Domain können mehrere Document Repositories vorhanden sein. Typischerweise ist ein Document Repository immer einer Organisation zugeordnet. Policy Enforcement Point: Dies ist eine Komponente des Access Control Systems gruppiert mit dem Document Registry. In diesem Use Case überprüft der Policy Enforcement Point ob das Dokument gelöscht werden darf. Seite 124 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

139 9 Technische Spezifikationen Ablauf Abbildung 19: Ablaufdiagramm Dokument löschen Dokument löschen Das Dokument wird im Primärsystem/Portal ausgewählt. Es wird die Transaktion Delete Document Set (ITI-62) durch das Primärsystem/Portal in der Rolle Document Administrator aufgerufen (Spezifikation: ITI Supplement XDS Metadata Update Kapitel 3.62). Anhand der UUID wird festgelegt, welches Metadatenset aus der Registry gelöscht werden. IHE definiert keine Transaktion für das physikalische Löschen des Dokuments aus dem Repository. Es muss jedoch sichergestellt werden, dass das Dokument auch im Repository gelöscht wird. Trigger (ITI-62) Die Transaktion wird von dem Document Administrator entweder durch eine manuelle (über eine Schaltfläche) oder automatische Interaktion (hinterlegtes Regelwerk) ausgelöst. Nachrichtenstruktur - Request (ITI 62) (Spezifikation: ITI Supplement XDS Metadata Update Kapitel ) Nachrichtenstruktur - Response (ITI 62) (Spezifikation: ITI Supplement XDS Metadata Update Kapitel ) Seite 125 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

140 9 Technische Spezifikationen Dokumentenliste aus entfernter Domain abrufen Dieser Use Case beschreibt wie eine Dokumentenliste aus einer entfernten Affinity Domain abgerufen wird. XCA Gateways ermöglichen dabei eine Verbindung zwischen zwei autarken Affinity Domains. Vorbedingungen Es wird eine übergreifende Patienten-ID benötigt. Akteure (Systemkomponenten) Es werden die ähnlichen Akteure wie beim Use Case Dokumentenliste abrufen benötigt. Weitere Akteure, die bei diesem Use Case eine Rolle spielen sind: Initiating Gateway: Übermittelt Anfrage(n) eines Document Consumers (transparent) an entfernte Affinity Domains und bereitet Antworten für den Consumer auf. Responding Gateway: Nimmt Anfragen aus anderen Affinity Domains entgegen, führt die Dokumenten Suche in der eigenen Domain aus und übermittelt das Ergebnis an Initiating Gateway. Ablauf Abbildung 20: Ablaufdiagramm Dokumentenliste aus einer entfernten Domäne abrufen Seite 126 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

141 9 Technische Spezifikationen Dokumentenliste aus einer entfernten Affinity Domain abrufen Das Initiating Gateway nimmt die Anfrage des Document Consumers entgegen und sendet eine Anfrage für die Dokumentensuche mit Patienten-ID der Zieldomäne an das Responding Gateway dieser Domäne. Das Responding Gateway nimmt die Anfrage des Initiating Gateways entgegen und führt innerhalb der entfernten Domäne eine Dokumentensuche in deren Registry aus. Das Ergebnis wird an das Responding Gateway übermittelt. Dieses leitet es an das Initiating Gateway der lokalen Domäne weiter. Dieses wertet das Ergebnis aus und liefert es an den Document Consumer der eigenen Domäne weiter. Trigger Es wird eine Dokumentensuche in einer entfernten Affinity Domain durchgeführt. Nachrichtenstruktur - Request (ITI-38) Spezifikation: ITI Volume 2b (Kapitel ) Nachrichtenstruktur - Response (ITI-38) Spezifikation: ITI Volume 2b, Kapitel Dokument aus entfernter Domain abrufen Dieser Use Case beschreibt wie Dokumente aus entfernten Affinity Domains abgerufen werden. XCA Gateways ermöglichen dabei eine Verbindung zwischen zwei autarken Affinity Domains. Vorbedingungen Es wird eine übergreifende Patienten-ID benötigt. Dokumente werden immer in der eigenen (lokalen) Domain registriert, niemals in einer entfernten. Akteure (Systemkomponenten) Es werden die ähnlichen Akteure wie beim Use Case Dokument abrufen benötigt. Weitere Akteure, die bei diesem Use Case eine Rolle spielen sind Initiating Gateway: Übermittelt Anfrage(n) eines Document Consumers (transparent) an entfernte Affinity Domains und bereitet Antworten für den Consumer auf. Responding Gateway: Nimmt Anfragen aus anderen Affinity Domains entgegen, führt die Dokumentensuche in der eigenen Domain aus und übermittelt das Ergebnis an das Initiating Gateway. Seite 127 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

142 9 Technische Spezifikationen Ablauf Abbildung 21: Ablaufdiagramm Dokument aus einer entfernten Domäne abrufen Dokument aus entfernter Domain abrufen Das Initiating Gateway sendet Cross Gateway Retrieve [ITI-39] (Semantisch gleichwertig zu Retrieve Document Set [ITI-43]) zum Abruf von spezifischen Dokumenten aus einer entfernten Affinity Domain an das Responding Gateway der entfernten Affinity Domain weiter. Das Responding Gateway der entfernten Affinity Domain nimmt die Anfrage des Initiating Gateway entgegen und ruft die gewünschten Dokumente aus dem repository/den Repositories der entfernten Affinity Domain(s) ab und übermittelt die abgerufenen Dokumente an das Initiating Gateway. Trigger Der Nutzer fragt Dokumente aus einer entfernten Affinity Domain an. Nachrichtenstruktur - Request (ITI-39) (Spezifikation: ITI Volume 2b, Kapitel ) Nachrichtenstruktur - Response (ITI-39) (Spezifikation: ITI Volume 2b, Kapitel ) Seite 128 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

143 10 Betriebs- und Langzeitarchivierung 10 Betriebs- und Langzeitarchivierung Insbesondere im korrespondierenden Anhang A.3 wird aufgezeigt, welche Parameter die Betriebs- und Langzeitarchivierung eines eepa Systems determinieren. Existierende rechtliche und funktionale Anforderungen an Akten- und Archivsysteme sind evaluiert und auf Relevanz geprüft. Einzelne Aspekte können nur je nach Projektvereinbarung relevant sein. Gesetzliche Aspekte Da die eepa nur eine redundante Kopie bzw. Referenz auf Dokumente im Primärsystem implementiert, sind die gesetzlichen Aspekte der Archivierung (vgl. auch Anhang A.3) nach Ansicht der Autoren nicht relevant. Konfigurierbarkeit Je nach spezifischer Projektdefinition können vertragliche Aspekte relevant sein. Das System sollte daher entsprechend konfigurierbar sein. Aus technischer Betriebssicht können Backup und Sicherstellung der Datenverfügbarkeit relevant werden und sollten daher vorgesehen werden. Vertraglich kann (sollte) der eepa Betreiber die Verfügbarkeit von Dokumenten über einen definierten Zeitraum garantieren. Dann müssen Primärsysteme (wenn Repository) diese Frist auch garantieren. Vorratsdatenhaltung: In bestimmten klinischen Anwendungsfällen müssen nach bestimmten Zeitfristen die gemeinsam genutzten Daten gelöscht werden (Beispiel Rhön: Tumorkonferenzen Löschung der Daten nach 90 Tagen). Aufzählungsliste 37: Konfigurierbarkeit Klinisch / funktionale Sicht Ein Arzt muss darauf vertrauen, dass externe Dokumente, die er seinem Handeln zu Grunde gelegt hat, verfügbar sind. In jedem Fall muss dem Mediziner bekannt sein, welche Verfügbarkeitsgarantieren existieren. Gegebenenfalls muss der Arzt alle genutzten Dokumente in sein Primärsystem übernehmen. Je nach Projektspezifikation müssen die Primärsysteme in der eepa referenzierte Daten oder Dokumente länger als die gesetzlich geforderte Mindestdauer bereitstellen (Stichwort: Lebenslange Akte). Aufzählungsliste 38: Klinisch / funktionale Sicht Seite 129 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

144 10 Betriebs- und Langzeitarchivierung Seite 130 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

145 11 Migration in die Telematikinfrastruktur 11 Migration in die Telematikinfrastruktur Grundsätzlich besteht die Möglichkeit, die eepa als Gesundheitsdatendienst (GDD) in die Telematikinfrastruktur (TI) zu integrieren. Die Zulassung der Elektronischen Fallakte als Mehrwertdienst könnte als Beispiel für eine entsprechende Zulassung der eepa dienen. Das Verfahren wurde 2010 begonnen. Im Rahmen des Projektleitermodells ist die Deutsche Krankenhausgesellschaft damit beauftragt, die Elektronische FallAkte (EFA) als Mehrwertanwendung in die Telematikinfrastruktur zu migrieren. Neben der Migration der EFA ist es Ziel dieses Projekts, einen allgemeinen Migrationspfad in die TI zu evaluieren, auf dem bestehende Anwendungen auf der technischen und organisatorischen Plattform der TI verfügbar gemacht werden können, ohne diese grundsätzlich in ihrer wesentlichen Funktion und Realisation ändern zu müssen. Es sollen nur einzelne Schichten der Anwendung durch Dienste der TI erweitert bzw. ersetzt werden. Die im Kontext der EFA-Migration notwendigen Anpassungen an der TI sollen internationale Standards nutzen und so sicherstellen, dass diese auch für andere Gesundheitsdatendienste (GDD) nutzbar sind Telematikinfrastruktur (TI) Die Telematikinfrastruktur ist gemäß 291a SGB V eine interoperable und kompatible Informations-, Kommunikations- und Sicherheitsinfrastruktur, die für die Einführung und Anwendung der elektronischen Gesundheitskarte erforderlich ist. Seite 131 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

146 11 Migration in die Telematikinfrastruktur 11.2 Gesetzliche Anwendungen Auf Basis der Telematikinfrastruktur sollen gemäß 291 Abs. 2b, 291a Abs. 2 und 3 SGB V folgende Anwendungen realisiert werden: Pflichtanwendungen o Versichertenstammdatenmanagement o Elektronische Verordnung Freiwillige Anwendungen o Notfalldaten o Elektronischer Arztbrief o Arzneimitteltherapiesicherheit o Elektronische Patientenakte o Elektronisches Patientenfach o Elektronische Patientenquittung o Erklärungen der Versicherten zur Organ- und Gewebespende o Hinweise der Versicherten auf das Vorhandensein und den Aufbewahrungsort von Erklärungen zur Organ- und Gewebespende o Hinweise der Versicherten auf das Vorhandensein und den Aufbewahrungsort von Vorsorgevollmachten oder Patientenverfügungen nach 1901a des Bürgerlichen Gesetzbuchs Aufzählungsliste 39: Anwendungen der egk 11.3 Mehrwertanwendungen Neben den gesetzlichen Anwendungen soll die TI auch Plattform für weitere Anwendungen einer einrichtungsübergreifenden medizinischen Versorgung, den sogenannten Mehrwertanwendungen, sein Gesundheitsdatendienste (GDD) Eine Kategorie solcher Mehrwertanwendungen sind die Gesundheitsdatendienste. Diese haben im Sinne des Migrationskonzepts spezifische Zusammenstellungen medizinischer Daten von Versicherten zum Gegenstand. Wesentliches Unterscheidungsmerkmal ist das dienstindividuelle Inhaltsmodell. Seite 132 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

147 11 Migration in die Telematikinfrastruktur Ferner haben Gesundheitsdatendienste folgende Charakteristika: Sie werden vom Leistungserbringer geführt und verantwortet. Die Daten verbleiben in den Systemen der Leistungserbringer, in denen sie angelegt wurden. Über den GDD werden nur Kopien zur Verfügung gestellt. Der Datenzugriff beschränkt sich auf eine überschaubare Gruppe von Leistungserbringern. Er kann synchron oder asynchron erfolgen. Die Leistungserbringer sind von Versicherten über eine informierte Einwilligung zum Zugriff auf die Daten berechtigt. Die technische Realisierung ist nicht vorgeschrieben. Eine PIN-Autorisierung des Zugriffs des Leistungserbringers durch den Versicherten ist zwingend vorzusehen. Eine nachträgliche transparente Einsicht in die Nutzung seiner Daten muss allerdings gewährleistet werden. Eine Ende-zu-Ende- Verschlüsselung der Daten über die egk ist nicht zwingend notwendig. Aufzählungsliste 40: Charakteristika von Gesundheitsdatendiensten Aus Sicht des Patienten ist für Mehrwertanwendungen ein zu den gesetzlichen ( 291a-) Anwendungen materiell vergleichbares Datenschutzniveau herzustellen, auch wenn dieses technisch abweichend realisiert wird. Im Rahmen der EFA wurde das Datenschutzkonzept in enger Abstimmung mit den zuständigen Datenschutzstellen erarbeitet Migration der EFA Basis zur Migration weiterer GDD Phase 1 Nutzung der Funktionalitäten der Telematikinfrastruktur In einem ersten Schritt sollen die Dienste der TI für die Elektronische Fallakte nutzbar gemacht werden. Dabei sollen die Schnittstellen so gestaltet werden, dass die Dienste auch anderen Mehrwertanwendungen zur Verfügung stehen. Dazu zählen: Dienste zur Identifizierung und Authentifizierung der Leistungserbringer über die Heilberufsausweise als einheitlicher Zugang zu Gesundheitsdatendiensten. Dienste zur Registrierung, Identifikation, Authentisierung und Lokalisierung von Mehrwertdiensten in der TI zur Herstellung von Kommunikationsverbünden anstelle anwendungsspezifischer Mechanismen. Eine gesicherte Transportschicht, die anwendungsunabhängig genutzt werden kann. Dienste zur Vermittlung von Verweisen auf Einwilligungen zur Nutzung von Mehrwertdiensten. Aufzählungsliste 41: Dienste, die auch anderen Mehrwertanwendungen zur Verfügung stehen Seite 133 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

148 11 Migration in die Telematikinfrastruktur Phase 2 Nutzbarmachung der EFA-Sicherheitsarchitektur In einer zweiten Phase sollen Dienste der EFA-Sicherheitsarchitektur für andere GDD über die TI nutzbar gemacht werden. Diese sind: Die Kodierung von Identitäts- und Authentizitätsnachweisen in einem einheitlichen, standardisierten Format. Dadurch wird ein Single Sign-On sowie die Nutzung standardisierter Kommunikationsmechanismen möglich, was die Umsetzung von Mehrwertdiensten vereinfacht. Die transparente Weiterleitung von Sicherheitstoken zur Umsetzung eines policybasierten anwendungsübergreifenden Berechtigungsmanagements. Aufzählungsliste 42: Nutzbargemachte Dienste für andere GDD Anforderungen an Zulassung und Betrieb Zulassung Die Zulassungsbedingungen werden sich an die für 291a-Dienste anlehnen. Der Anbieter eines GDD, der die TI nutzt, muss im Rahmen der Zulassung durch die gematik die folgenden Nachweise erbringen: Bescheinigung über die Konformität des Dienstes mit seiner Spezifikation Bescheinigung über Einhaltung des Datenschutzes durch Analyse des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) Bescheinigung über Einhaltung der Datensicherheit durch Sicherheitsanalyse des Bundesamts für Sicherheit in der Informationstechnik (BSI) Nachweis, dass keine Beeinträchtigung der gesetzlichen Anwendungen durch die Nutzung der TI durch den GDD zu erwarten ist Aufzählungsliste 43: Nachweise zur Zulassung Gemäß Lastenheft sind die Prozesse der TI-Plattform aus Test, Migration und Zulassung zu unterstützen durch: Übergabe einer spezifikationskonformen Anwendung in die Testverfahren Bereitstellung der Anwendung in mehreren Systemumgebungen Definition eigener fachlicher Tests für die Anwendung Organisatorische Unterstützung der Test- und Migrationsplanung Durchführung aller für die Zulassung benötigten Aktivitäten Aufzählungsliste 44: Kriterien für Zulassung zur TI Nach heutigem Stand sind die Zulassungsbedingungen für Mehrwertdienste noch nicht erstellt. Seite 134 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

149 11 Migration in die Telematikinfrastruktur Betrieb Die Anforderungen an den Betrieb müssen diensttypindividuell festgelegt werden. Mehrwertdienstanbieter sind in Anlehnung an 291b Abs. 1b SGB V in einem transparenten und diskriminierungsfreien Verfahren zuzulassen, wenn die verwendeten Komponenten und Dienste zugelassen sind, der Nachweis erbracht wird, dass Verfügbarkeit und Sicherheit des Betriebs gewährleistet wird, und der Anbieter sich vertraglich verpflichtet, die Rahmenbedingungen für Mehrwert- Betriebsleistungen der gematik einzuhalten. Nach heutigem Stand sind die Zulassungsbedingungen für Betreiber von Mehrwertdiensten noch nicht erstellt Bedeutung für die eepa Das in der EFA Spezifikation vorgeschlagene GDD-Referenzmodel 35 könnte ggf. auch als Grundlage für die Migration der eepa in die Telematikinfrastruktur dienen. Allerdings werden die Arbeiten - Erarbeitung eines Pflichtenheftes - zur Zeit nicht weitergeführt. Stand 03/2014 sind keine öffentlichen Quellenverweise auf detaillierte Dokumente verfügbar. Da auch von der gematik die Zulassungsverfahren für Dienste und Anbieter der Mehrwertdienste noch nicht definiert sind, ist mit einer Realisierung von Gesundheitsdatendiensten in den nächsten Jahren nicht zu rechnen. Möglicherweise ergeben sich auf Grund der Ergebnisse der vom Bundesministerium für Gesundheit in Auftrag gegebenen ehealth Planungsstudie Interoperabilität veränderte Rahmenbedingungen für den Betrieb einrichtungsübergreifender Aktensysteme in Verbindung mit der Telematikinfrastruktur. 36 In Ihrer Broschüre zur Einführung der Gesundheitskarte Für ein Gesundheitswesen mit Zukunft. Die elektronische Gesundheitskarte (Mai 2012) 37 geht die gematik davon aus, dass mit der Gesundheitskarte der Zugriff auf eine einrichtungsübergreifende Patientenakte möglich werden soll: Es ist zum Beispiel geplant, dass die Karte den Zugriff ermöglicht auf Notfalldaten, Patientenverfügungen, Therapiemaßnahmen, Organspendeerklärungen, Arzneimitteldokumentationen, eine Impfdokumentation oder sogar auf die komplette elektronische Patientenakte, wenn ein Versicherter das wünscht. Ob das in der Broschüre beschriebene Szenario, bei dem für jeden Zugriff auf die Patientenakte sowohl der Arzt seinen Heilberufeausweis, als auch der Patient seine Gesundheitskarte, in ein Kartenterminal steckt und darüberhinaus auch seine PIN eingeben muss, alltagstauglich ist, bedarf jedoch noch einer genaueren Überprüfung Seite 135 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

150 11 Migration in die Telematikinfrastruktur Seite 136 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

151 12 Informationsobjekte 12 Informationsobjekte Informationsobjekte im eepa-kontext sind hauptsächlich fachliche Dokumente (wie z. B. Entlassungsdokumente oder klinische Befunde) die neben der Inhaltskomponente die Beschreibung von Syntax, Struktur und Semantik enthalten. Die Dokumentenstruktur beinhaltet beschreibende Daten (Metadaten) der Dokumente selbst, sowie entsprechende Metadaten zur Suche von Dokumenten in der Akte. Informationsobjekte umfassen statische und dynamische Dokumente Statische Dokumente Statische Dokumente sind unveränderlich. Der Inhalt steht zum Zeitpunkt der Erstellung vollständig fest und ist unveränderbar. Spätere Korrekturen bzw. Änderungen resultieren in einer neuen Version des Dokumentes. Statische Dokumente können mit einer digitalen Signatur versehen werden. Typische Beispiele hierfür sind Entlassungsdokumente und Befundberichte Dynamische Dokumente Dynamische Dokumente repräsentieren den aktuell bei der Generierung vorliegenden Informationsstand. Bei der Registrierung von dynamischen Dokumenten wird der Infrastruktur lediglich die Existenz eines solchen Dokumentes bekannt gegeben. Der Inhalt selbst wird bei Abruf vom Primärsystem dynamisch gemäß dem aktuellsten Informationsstand gefüllt. Die so abgerufenen Dokumente sind auf diese Weise ebenfalls versioniert. Typische Beispiele für dynamische Dokumente sind Medikationsdaten und Dokumente, welche klinische Fragestellungen betreffen, die bei Bedarf aus existierenden Dokumenten extrahiert werden können sowie die diversen Pässe (Impfpass, Röntgenpass). Seite 137 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

152 12 Informationsobjekte 12.3 Dokumententaxonomie Die Aufbereitung der verschiedenen Dokumenttypen in einer eindeutigen Hierarchie ist schwierig bzw. sogar unmöglich, weil unterschiedlichste Aspekte (Ziel des Dokumentes oder der Inhalt selbst etc.) eine Rolle spielen und je nach Gewichtung dadurch andere Hierarchien entstehen ( Grundsätzlich gilt es die verschiedenen Dokumenttypen hinreichend zu präzisieren Haupttypen Als pragmatisch hat sich erwiesen, alle Dokumenttypen auf der obersten Ebene in eine der folgenden drei Kategorien einzusortieren: Administrative Informationen o Überweisung, Konsens, Einwilligungserklärung, Quittungen,... Feingranulare Daten o Anamnese, Diagnose, Maßnahme, Labordaten,... Aggregierte Informationen o Bericht/Befund (Arztbrief) o Evaluation und Management Note o Pass (Impfpass, Mutterpass, Röntgenpass,...) o Gutachten o Formular o Meldungen (IfSG, Krebsregister,...) o Planung (Therapien) Aufzählungsliste 45: Kategorien von Dokumenttypen Klassifikationsachsen Wie bereits erwähnt und durch die vorhergehende Aufstellung dargestellt, ist es schwierig die Dokumenttypen in eine einzige Hierarchie einzusortieren (Eine Auflistung findet sich in A.2.). Es wird deutlich einfacher, wenn die Dokumenttypen gemäß folgender Eigenschaften klassifiziert werden: Aspekt Inhalt Kontext In welchem Zusammenhang wird das entsprechende Dokument erstellt. Inhalt Was ist in dem Dokument enthalten, bspw. Fragestellung, Krankengeschichte, Untersuchungsergebnis, Beurteilung, Behandlungsempfehlung. Art des Inhalts Daten, Interpretation, Empfehlungen. Aktivitäten Ein Arzt oder Heilberufler hat einen anderen Heilberufler nach seiner Meinung gefragt oder das Dokument beantwortet eine frühere Anfrage. Zweck Dokumentation der Untersuchungsergebnisse und ihrer Interpretation durch den Untersuchenden. Autor Wer hat das Dokument erstellt/verfasst (Arzt, Apotheker, Patient,...). Adressat An wen richtet sich das Dokument, d.h. für wen ist es geschrieben worden (niedergelassener Arzt, Patient, Behörde). Seite 138 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

153 12 Informationsobjekte Aspekt Rechte und Pflichten Datenschutz Verwendung Abgrenzung Grundlage Spezialisierung Inhalt Urheberrecht und Aufbewahrungspflicht des Autors, Aufbewahrungspflicht des Empfängers. Inwieweit darf das Dokument identifizierende Merkmale (auch) im Freitext enthalten. Patientenakte, Forschung. Bericht für Patienten, Angehörige oder andere Nicht-Heilberufler. Zweitbefundung. Berufsordnung Ärzte o.ä. Welche Spezialformen dieser Dokumentart gibt es (Entlassbrief als spezielle Form des Arztbriefes). Tabelle 43: Mögliche Klassifikationsachsen für Dokumenttypen Nachfolgend beispielsweise die Aspekte eines Entlassungsberichtes: Name: Entlassungsbericht, en: Discharge Summary Kontext: Zusammenfassende Darstellung eines Klinikaufenthaltes zum Zeitpunkt der Entlassung Inhalt: Aufnahmegrund, durchgeführte diagnostische, therapeutische und pflegerische Maßnahmen, Zustand und Prognose bei Entlassung, Behandlungsempfehlung Art des Inhalts: Daten, Interpretation, Empfehlungen Aktivitäten: Klinikaufenthalt ist abgeschlossen Zweck: Information des Weiterbehandelnden Autor: Arzt in der Klinik Adressat: Arzt oder Heilberufler Rechte und Pflichten: Urheberrecht und Aufbewahrungspflicht des Autors, Aufbewahrungspflicht des Empfängers Datenschutz: Kann identifizierende Merkmale (auch) im Freitext enthalten Verwendung: Ablage in Patientenakte, ggf. Forschung Grundlage: Berufsordnung Ärzte o.ä., lokale Regeln Aufzählungsliste 46: Aspekte eines Entlassungsberichts Inhalte Ein Dokument setzt sich typischerweise aus einer Reihe von Absätzen zusammen, die unterschiedlichste Aspekte berücksichtigen und je nach Dokumenttyp 38 relevant sind. So enthält ein Arztbrief eine bestimmte Form der Anrede, ein Formular jedoch nicht. Nachfolgend sind beispielhaft die Strukturen aufgezeigt, um das Schema zu verdeutlichen: 38 Seite 139 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

154 12 Informationsobjekte Dokumenttyp: Absatz ( Sektion ): Arztbrief Radiologiebefund Pathologiebefund Meldung Infektionsschutz Anrede Ja R2* Ja Nein Anforderung Nein Ja Nein Nein Fragestellung Nein Ja Vielleicht Nein Anamnese Ja Ja Nein Nein Familienanamnese R2 R2 Nein Nein Krankengeschichte, Voruntersuchungen Ja R2 Nein Nein Befunde Ja Ja Ja Nein Diagnosen (ICD, ICD-O, TNM) Vielleicht (ICD) Ja Ja (ICD-O, TNM) Ja (ICD) Risikofaktoren, bes. Hinweise (CAVE) R2 R2 Nein Nein Diagnostische Maßnahme R2 Ja Nein Nein Therapien/Behandlungsmaßnahmen Ja R2 Nein Nein Behandlungsempfehlungen Ja Nein Nein Nein Epikrise Ja Nein Nein Nein Epidemiologische Situation Nein Nein Nein Ja Anhänge (z. B. Bilder, Labor) R2 Ja Nein Nein Schlusstext Ja Ja Ja Nein *R2: required if known ; gemäß IHE ein Pflichtfeld, welches nur gefüllt werden muss, wenn Daten vorliegen. Tabelle 44: Abschnitte für verschiedene Dokumenttypen (Beispiel) 12.4 Überblick über nationale und internationale Aktivitäten Folgende nationale und internationale Aktivitäten finden derzeit zur Harmonisierung von Informationsobjekten im Umfeld elektronischer Gesundheitsakten statt. In den folgenden Abschnitten erfolgt eine Überblicksdarstellung dieser Aktivitäten. Hier beschriebene Ergebnisse dienen als Ausgangsbasis für die inhaltliche Beschreibung der Informationsobjekte. Eine Abstimmung mit HL7 und IHE Deutschland, sowie mit klinischen Anwendern ist nötig, um den praktischen Einsatz zu gewährleisten. Es existieren folgende nationale Aktivitäten: HL7 Deutschland ELGA CDA Harmonisierung ehealth Suisse /HL7 Schweiz /ech-standards DMP Frankreich ehealth Dänemark ehealth Finnland Aufzählungsliste 47: Nationale Aktivitäten Seite 140 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

155 12 Informationsobjekte HL7 Deutschland HL7 Deutschland 39 wurde 1993 als das erste HL7 Affiliate weltweit gegründet. Die erste Aufgabe des neu gegründeten Vereins bestand darin, den HL7 V2.x Standard zu übersetzen (zu interpretieren) und über den Z-Segment Mechanismus an die deutschen Gegebenheiten anzupassen. Dieser Prozess ist noch nicht abgeschlossen. Als Ergebnis entstanden 2003 die ersten deutschen Nachrichtenprofile, die 2005 noch einmal ergänzt wurden wurde das Projekt zum Abgleich mit dem IHE ITI PAM-Profil zum Patient Administration Management erfolgreich abgeschlossen. Neben diesen Arbeiten gibt es eine Reihe von (internen) Projekten, d.h. Themen, an denen der Verein arbeitet: Arztbrief 2006 Arztbrief 2014 CDA für elektronische Patientenakten CDA-Kernkomponenten Body CDA-Kernkomponenten Header DRV-Bund Reha-Entlassbrief Datenaustausch Dialyse Datentypen Diagnosen Diagnosen englisch Dokumentenklassifizierung eprivatabrechnung etrainingsplan etransitionsbrief ewundbericht HL7 Consolidated CDA für Deutschland IHE-Cookbook Medikationsplan (epsos + AKdÄ) Meldewesen und Infektionsschutz Notarzteinsatzprotokoll Onkologische Versorgung PAM-Profil Abgleich PDF/A-Leitfaden Pathologiebefund Patienteneinwilligung Patientenpass RIS/PACS Value Sets für Deutschland Vocabulary Binding Syntax Details dazu lassen sich auf den Projektseiten im Wiki von HL7-Deutschland nachlesen. 40 Einen Schwerpunkt bilden dabei die Arbeiten am Arztbrief , dem Nachfolger des VHitG- Arztbriefes. Im Rahmen dieses Projektes (und weiterer assoziierter Projekte wie bspw. dem Transitionsbrief sowie der Krebsregistermeldung) werden eine Reihe von Templates (Dokument, CDA-Header, Section und Entries) erarbeitet, die den Aufbau weiterer Implementierungsleitfäden deutlich vereinfachen ELGA Österreich - Harmonisierungsarbeit für medizinische Dokumente Verantwortlich für die Harmonisierungsarbeit der medizinischen Dokumente in Österreich ist die 2009 gegründete ELGA GmbH. 42 Die Gesellschafter Bund, Länder und Sozialversicherung repräsentieren die maßgeblichen Entscheidungs- und Kostenträger im österreichischen Gesundheitswesen. Seit Ende 2011 existieren Leitfäden zur Implementierung von CDA Dokumenten, die im Rahmen der österreichischen elektronischen Gesundheitsakte (ELGA) zum Einsatz kommen und 2015 verpflich- 39 Verantwortliche Institution: HL7 Deutschland e.v., An der Schanz 1, Köln Website: (letzter Zugriff ) 40 (letzter Zugriff ) 41 (letzter Zugriff ) 42 Verantwortliche Institution: ELGA GmbH Treustrasse 35-43/ Stg. 4/ 1. Stock; 1200 Wien, Website: (letzter Zugriff ) Seite 141 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

156 12 Informationsobjekte tend werden. Umsetzungsvorschläge wurden von Standardisierungsgremien ausgearbeitet und mit Ärzteschaft, Pflege, Krankenanstalten, Forschung, Softwarehersteller für Spitäler, Institute und Ordinationen (insgesamt ca. 200 Personen) abgestimmt. Nach Abschluss der Harmonisierungsarbeit erfolgte eine öffentliche Kommentierungsphase. Ein Allgemeiner CDA Implementierungsleitfaden spezifiziert dokumentenübergreifende Anforderungen wie z. B. Header Daten und Code Systeme. Bis dato wurde der Harmonisierungsprozess für folgende Dokumente abgeschlossen. Entlassungsbrief ärztlich Entlassungsbrief Pflege Laborbefund, allgemein Laborbefund, bakteriologisch Befund bildgebende Diagnostik Aufzählungsliste 48: Abgeschlossener Harmonisierungsprozess Zeitgleich mit der Harmonisierung der CDA Dokumente wurden auch Vorgaben zur Semantik der XDS Metadaten abgestimmt. Zurzeit findet die Harmonisierung weiterer Dokumente (z. B. Pathologie Befund) statt ehealth Suisse/ HL7 Schweiz/ ech-standards Ziel der Strategie ehealth Schweiz ist es allen Menschen in der Schweiz selbst und von ihnen berechtigten Leistungserbringern unabhängig von Ort und Zeit den elektronischen Zugriff auf behandlungsrelevante Informationen zu ermöglichen. Zur Umsetzung dieser Strategie gründeten Bund und Kantone das Koordinationsorgan ehealth Suisse, das auf kantonaler Ebene Projekte und Anwendungen zur elektronischen Vernetzung medizinischer und administrativer Informationen und Prozesse im Gesundheitswesen steuert und koordiniert. Es wird ein föderaler dezentraler Lösungsansatz verfolgt, der aus schweizweit koordinierten Komponenten (gesicherter Kommunikationsraum, zentrale Verzeichnisdienste) und dezentralen organisatorischen Einheiten (Gemeinschaften), in denen sich Leistungserbringer zusammengeschlossen haben, besteht. Die rechtlichen Voraussetzungen für das elektronische Patientendossier sollen durch ein Bundesgesetz geregelt werden. Ein Gesetzesentwurf wurde im Mai 2013 an das Parlament überwiesen. Im Rahmen der Umsetzung der Strategie ehealth Schweiz" wurden Standards geprüft und Empfehlungen erarbeitet, die die Interoperabilität zwischen Regionen und Kantonen gewährleisten sollen. Die Strategie ehealth Schweiz basiert in wichtigen Elementen auf IHE (letzter Zugriff ) 44 (letzter Zugriff ) Seite 142 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

157 12 Informationsobjekte Als Teil eines ehealth strategiekonformen dezentral gehaltenen elektronischen Patientendossiers (EPD) wurden mit dem Austauschformat Elektronisches Impfdossier und dem Austauschformat der Laborbefunde im Transplantationsprozess die am verabschiedet wurden, die ersten national koordinierten ehealth"-vorhaben realisiert. 45, Es sind interdisziplinäre Arbeitsgruppen zur Definition weiterer Austauschformate geplant, z. B. eaustrittsbericht, emedikation, eallergiepass. Grundlage hierfür sind von der HL7- Benutzergruppe Schweiz erstellte Dokumente zur Spezifikation von CDA-Vorlagen, die auch als ech- Standards genehmigt wurden (ech fördert, entwickelt und verabschiedet E-Government- Standards. Die ech-trägerschaft bilden Bund, Kantone, Städte und Gemeinden sowie Wirtschaft und Wissenschaft. ech-standards haben den Status von Empfehlungen. Der Einsatz der Standards kann auf Stufe Bund, Kantone oder Städte und Gemeinden für verbindlich erklärt werden.). Weitere Publi kationen sind auf der Homepage der HL7-Benutzergruppe Schweiz und der des ech zu finden DMP Frankreich Die Einführung des Dossier Medical Personnel (DMP) 50 ist ein vom französischen Gesundheitsministerium initiiertes Projekt mit dem Ziel, für jeden Franzosen eine eigene elektronische medizinische Akte mit seiner gesamten Krankengeschichte zu erstellen. Die Gesundheitsdienstanbieter sind verpflichtet, dem Wunsch des Patienten zu folgen und entsprechende medizinische Dokumente (Entlassungsbriefe, Befunde, Bilder, etc.) in das DMP einzustellen. Verantwortlich für die Entwicklung und den Betrieb des DMP ist die "Agence des systèmes d information partagés de santé" (ASIP Santé) 51, die durch das französische Gesundheitsministerium sowie die nationalen Krankenversicherungen und die Sozialkasse getragen wird. Seit 2011 existieren Spezifikation und Leitfäden, die im Rahmen des französischen DMP zum Einsatz kommen (letzter Zugriff ) 46 (letzter Zugriff ) 47 (letzter Zugriff ) 48 (letzter Zugriff ) 49 (letzter Zugriff ) 50 (letzter Zugriff ) 51 (letzter Zugriff ) Seite 143 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

158 12 Informationsobjekte Aus der funktionalen und technischen Spezifikation (Dossier de spécifications fonctionnelles et techniques des interfaces DMP des Logiciels de Professionnels de Santé) kann man folgende Eckpunkte extrahieren: Der Patient sowie der Gesundheitsdienstanbieter, mit Autorisierung durch den Patienten, haben Zugriff auf die Akte. Die Patientidentifizierung mit der e-card carte SESAM-Vitale erfolgt über die eindeutige INS Nummer identifiant National de Sante (= Versicherungsnummer), die jedem Versicherten zugeteilt wird. Die Arztidentifizierung erfolgt mit der elektronischen Professional card carte CPS identifiant national (N ADELI oder N RPPS). OID als eindeutige Identifizierung von ISO Objekten. Gesundheitsdokumente entsprechen der HL7 Clinical Document Architecture, Release 2.0 (CDA R2) Ausgabe: Edition Normative HL7 v3 de mai Zur Zeit sind nur Dokumente vom CDA-Level 1 im Einsatz. Es gibt verschiedene Ordner (Zweckordner) im DMP: o Medizinische Zusammenfassung (Patient summary), o Behandlung und Therapie, o Befunde, o Bilder, o Laborergebnisse und o Vorsorge. Aufzählungsliste 49: Eckpunkte französische DMP-Leitfäden Technische Einzelheiten stehen im Health Information Systems Interoperability Framework (HIS- IF) ehealth Dänemark Seit Mitte der 90-er Jahre wird E-Health im dänischen Gesundheitswesen vorangetrieben und hat sich erfolgreich etabliert. Den Ärzten und Patienten steht seit 2003 ein unter erreichbares Gesundheitsportal zur Verfügung, welches sich aus einem öffentlichen und einem geschützten Bereich zusammensetzt. Dieses Portal wurde seit dem Zeitpunkt seiner Entstehung ständig weiterentwickelt und den technischen, den menschlichen sowie den rechtlichen Anforderungen angepasst. Während der öffentliche Bereich Informationen zu den Institutionen des Gesundheitswesens, z. B. zu den Ärzten und Krankenhäusern, enthält, können über einen persönlichen Login Arzttermine vereinbart, gesicherter Mail-Verkehr zwischen Arzt und Patient geführt, Überweisungen übermittelt und auf eigene Gesundheitsdaten wie Bild- und Laborbefunde und ebenso auf die gesamte Krankengeschichte zugegriffen werden. Ärzte können seit dem Jahr 2007 auf Befunde eines Patienten zugreifen, wel- 52http://esante.gouv.fr/en/services/referentiels/referentiels-d-interoperabilite/health-information-systems-interoperability-fr (letzter Zugriff ) Seite 144 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

159 12 Informationsobjekte che von anderen Gesundheitsdienstanbietern erstellt wurden. Dies erfordert unbedingt eine digitale Signatur. Für den Abruf von Patientendaten durch den Arzt, wird immer die Zustimmung des Patienten benötigt. Das Portal zeichnet zudem alle Zugriffe und Veränderungen von gespeicherten Daten auf Der Portalservice basiert auf dem IBM WebSpere Portal Server und umfasst folgende Funktionen 55 : Patientendossiers o Patientendaten werden in einer Datenbank gespeichert o Patientendaten sind nach internationalen Standards strukturiert o Medizinische Informationen sowie auch persönliche Informationen sind vorhanden o Abgleich und Zugriff der Patientendaten zwischen den verschiedenen Regionen möglich o Strukturen zur Abbildung der situations- oder krankheitspfadspezifischen Formate wie Schwangerschaft oder Zuckerkrankheit sind enthalten Informationen der Leistungserbringer o Einheiten und Organisationen des Gesundheitswesens repräsentieren sich o 800 Editoren pflegen, überprüfen und schalten Inhalte frei Datenaustausch o Hohe Migrationsfähigkeit und Erweiterbarkeit ist vorhanden o Über 250 definierte Dateiformate für den Informationsaustausch (Überweisung, Abrechnung, Rezept, ) Telemedizinische Beratungen Sicherheit und Systemmanagement Aufzählungsliste 50: Funktionen des Portals Weitere Literatur: Country Brief: Denmark 2010 (zuletzt aufgerufen am ) 56 ehealth in Denmark (zuletzt aufgerufen am ) 57 Interessante Präsentation, u. a. mit Bildern der sundhed-architektur ( ) Freisleben C.; ( ) 54 Trill R. (2008), Praxisbuch ehealth: Von der Idee zur Umsetzung 55 Nufer M; ( ) 55 Nufer M; ( ) Seite 145 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

160 12 Informationsobjekte esanté Luxembourg 59 Die Agentur für verteilte Informationen im Gesundheitswesen (L Agence esanté) wurde 2010 mit dem Ziel gegründet, für jeden Bürger eine nationale Patientenakte verfügbar zu machen. Hierzu sollte bis Januar 2014 eine entsprechende und auf IHE-Profilen aufbauende Infrastruktur etabliert werden. Angedacht ist die Umsetzung folgender Profile, Standards bzw. Use Cases: MPI, PIX/PDQ, CDA, HPD, SAML. Zum Teil befinden sich die Spezifkationen noch (2013) in der Ausarbeitung. Die Hersteller sollen jedoch durch Einsatz eines Toolkits Unterstützung bei der Umsetzung erhalten ehealth Finnland Die finnische Regierung erklärte im Jahr 2002 zum Ziel, dass bis Ende des Jahres 2007 in allen ambulanten sowie stationären Gesundheitseinrichtungen der öffentlichen sowie der privaten Trägerschaften eine flächendeckende elektronische Patientenakte mit identischen Kerninhalten eingesetzt werden soll. Bereits im Jahr 2005 nutzten 95,6% der Gesundheitszentren und 18 von 20 Krankenhausbezirken eine elektronische Patientenakte. Die Tatsache, dass zwei Jahre zuvor nur fünf Krankenhausbezirke eine EPA im Betrieb hatten, zeigt die rasante Umsetzung des Zieles aus dem Jahr Die Entwicklung der EPA wurde nicht zentral vom Staat vorgegeben. Stattdessen griff man auf bereits bestehenden regionalen Lösungen der ambulanten Gesundheitszentren bzw. Krankenhausbezirke zurück. Diese Lösungen wurden bereits vor 2002 von IT-Unternehmen und den Einrichtungen des Gesundheitswesens entwickelt. Eine vom Gesundheitsministerium berufene Kommission, bestehend aus Vertretern der entsprechenden Einrichtungen und Organisationen des Gesundheitswesens, einigte sich auf die gemeinsamen Inhalte sowie auf eine gemeinsame Datenstruktur der elektronischen Patientenakte. 50% der entstandenen Entwicklungskosten wurden durch staatliche Gelder abgedeckt. Die andere Hälfte der Kosten übernahmen die für die Finanzierung und Sicherstellung der gesundheitlichen Versorgung zuständigen Kommunen 60. Mit der EPA-Einführung verbundene Aspekte sind: Digitalisierung sämtlicher für die Patientenakte erforderlicher Daten Technische und semantische Kompatibilität der unterschiedlichen EPA-Ansätze sicherstellen Aufbau einer landesweiten ehealth-infrastruktur Entwicklung von Identifikations- und Verifikationslösungen Implementierung einer elektronischen Signatur Aufzählungsliste 51: Mit der EPA-Einführung verbundene Aspekte Dtsch Arztebl 2008; 105(9): A 452 6; Unabhaengig-von-Raum-und-Zeit ( ) Seite 146 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

161 12 Informationsobjekte Die HL-7-Kommision war für die Kompatibilität der unterschiedlichen regionalen Lösungen verantwortlich und legte die Schnittstellen fest, die alle EPA-Lösungen verwenden müssen. Somit sollte die Interoperabilität der unterschiedlichen Lösungen der IT-Unternehmen, Behörden und Einrichtungen des Gesundheitswesens gewährleistete werden 60. Die Weiterentwicklung führte bis zum nationalen Elektronikarchiv KANTA 61 62, welches die regionalen EPA-Lösungen in einem Online-Portal als ein einziges elektronisches Patientenaktenarchiv zusammenführt. Es wurde 2011 ein Gesetz verabschiedet, welches die Gesundheitsdienstleistenden dazu verpflichtet, dem Portal KANTA beizutreten und ihre EPAs anzubinden. Elektronische Rezepte werden zukünftig ebenfalls über KANTA abgewickelt. Link zum earchive KANTA: <nachzutragen> Funktionalitäten: Patientenakte(n) einsehen Elektronische Rezepte einsehen Einwilligungen / Aktenzugriffsberechtigungen verwalten Aktenaufrufe kontrollieren Patientenverfügungen / Organspenden Aufzählungsliste 52: Funktionalität von KANTA KANTA ist patientengeführt. Gesperrte Informationen können nach vorheriger Einwilligung des Patienten in Notfällen von Gesundheitsdienstleistenden aufgerufen werden. Weitere Literatur: A portfolio of e-health Applications in European Sparsely Populated Areas 200: ehealth Informationen zu Finnland, Schweden, Norwegen: 63 Country Brief: Finland ehealth strategy and implementation activities in Finland 65 Country focus: Finland 66 Establishing the Finnish ehealth platform - involving all professionals and providers 67 ehealth Finland Check Point (letzter Zugriff ) ec4e33ffc (letzter Zugriff ) 63 ehealth_applications_final_web.pdf (letzter Zugriff ) 64 (letzter Zugriff ) 65 (letzter Zugriff ) 66 (letzter Zugriff ) Seite 147 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

162 12 Informationsobjekte 12.5 Stylesheets für CDA-Dokumente und deren Ablage Im Rahmen dieses Projektes wurde evaluiert inwiefern CDA Dokumente mittels Style-Sheet Transformation in für den Endbenutzer lesbare Dokumente gerendert werden könnten. Im Folgenden wurden technische Rahmenbedingungen dafür erörtert. Ein Ausschlusskriterium für CDA als alleiniges Format für elektronische medizinische Dokumente ist die Trennung von Dokumenteninhalt (CDA-Dokument) und Dokumentendarstellung (XSLT- Stylesheet), da ein erfolgreicher Aufruf des Stylesheets von dessen Speicherort abhängt. So führen manche Browser das Stylesheet nicht bzw. nur mit einem Workaround aus, wenn es im gleichen Verzeichnis wie das CDA-Dokument liegt. Browser Tabelle 45: Stylesheet Aufruf Wenn ein Arzt A einen CDA-Arztbrief mithilfe des zugehörigen, im gleichen Verzeichnis gespeicherten Stylesheets in seinem Browser betrachtet, muss er davon ausgehen können, dass auch seine Kollegen das Dokument in ihrem Browser betrachten können. Verwendet der Dokumentenbetrachter einen für die Ausführung des Stylesheets ungeeigneten Browser, so wird der Inhalt der CDA-Datei nicht aufbereitet und nur schwer leserlich oder gar nicht im Browser angezeigt. Um das beschriebene Problem zu vermeiden, ist eine Einigung auf einen sogenannten Dokumenten- Hybriden erforderlich, welcher maschinell verarbeitet werden kann (CDA) und zugleich menschenlesbar (PDF/A) ist. In einem verteilten System stellt sich die Frage, wo zu einem CDA-Dokument das zugehörige Stylesheet zu finden ist. Je nach Ansatz kann Inhalt und Aussehen als eine Einheit betrachtet werden und beide Dateien gehören eng zusammen, andererseits ist aber auch denkbar, einen mehr modularen Baukasten aus Stylesheets aufzubauen, bei dem diese gesondert gehalten und abgerufen werden können. Relativ zum aktuellen Pfad Aufruf des Stylesheets durch den Browser bei unterschiedlicher Einbindung des Stylesheets in das CDA-Dokument? Absoluter Pfad im Dateisystem IE 8 Ja Ja Ja IE 9 Nur mit Workaround Nur mit Workaround Ja Firefox 15 Ja Nein Ja Chrome 21 Nur mit Workaround Nur mit Workaround Ja Safari 5 Ja Nein Ja Webserver (andere Domain) 67 (letzter Zugriff ) 68 (letzter Zugriff ) Seite 148 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

163 12 Informationsobjekte Prinzipiell sind also folgend aufgelisteten Varianten möglich: CDA-Dokument und das zugehörige Stylesheet werden als getrennte Dateien in der gleichen Domain bzw. im gleichen Dateisystem gespeichert. Das Stylesheet kann dabei im gleichen oder übergeordneten Verzeichnis, also relativ zum Verzeichnis des CDA-Dokuments, abgelegt werden. Alternativ lässt sich das Dokument in einem beliebigen Verzeichnis speichern. Hierbei wird von der Einbindung des Stylesheets über einen relativen oder absoluten Pfad gesprochen. CDA-Dokument und Stylesheet werden in einer einzigen Datei gespeichert und bilden somit eine Einheit. Hierbei wird der Inhalt des Stylesheets in das CDA- Dokument integriert. CDA-Dokument und Stylesheet werden getrennt in unterschiedlichen Domains gespeichert. In diesem Falle existiert in einer Domain ein Server, welcher die zugehörigen Stylesheets bereitstellt. Der Zugriff auf das zugehörige Stylesheet erfolgt dann über das entsprechende Netzwerk bzw. über das Internet. Aufzählungsliste 53: Varianten der Speicherung des Stylesheets Abbildung 22: Zuordnungsmöglichkeiten eines Stylesheets zu einem CDA-Dokument Seite 149 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

164 12 Informationsobjekte Die verschiedenen Varianten haben ihre Vorteile aber es sind auch Nachteile damit verbunden. Vorteile o Lokales Stylesheet ist jederzeit verfügbar, sofern es zusammen mit dem CDA- Dokument empfangen und im Dateisystem abgelegt wurde. Nachteile o Redundanz. Im ungünstigsten Fall wird für jedes CDA-Dokument des gleichen Typs jeweils das gleiche Stylesheet versendet/empfangen. o Gefahr des Verlustes bzw. der versehentlichen Löschung des Stylesheets. Der Betrachter muss dafür sorgen, dass das Stylesheet im Pfad abgelegt wurde, welcher im CDA-Dokument vorgegeben ist. o In der Regel bleibt die letzte lokal gespeicherte Version auch die letzte Version, die für das CDA-Dokument verwendet wird. Fehlerhafte Stylesheets werden somit nicht aktualisiert. o Mehrere Versionen des Stylesheets im Umlauf: Unterschiedliche Darstellung eines Dokumentes. o Elektronische Signatur problematisch, da Daten und Darstellung getrennt sind. Aufzählungsliste 54: Vor-/Nachteile der Speicherung des Stylesheets im gleichen Dateisystem Vorteile o Stylesheet bildet zusammen mit dem CDA-Dokument in einer einzigen Datei eine Einheit. o Darstellung des Dokumentes auch offline möglich. o Elektronische Signatur unproblematisch, da Daten und Darstellung nicht getrennt sind. Nachteile o In der Regel bleibt die letzte lokal gespeicherte Version auch die letzte Version, die für das CDA-Dokument verwendet wird. Fehlerhafte Stylesheets werden somit nicht aktualisiert. Aufzählungsliste 55: Vor-/Nachteile der Speicherung des Stylesheets im CDA-Dokument Seite 150 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

165 12 Informationsobjekte Speicherung der Stylesheets auf einem (Web-)Server / in einem Repository Abbildung 23: Speicherung der Stylesheets auf Webserver Vorteile o Das Stylesheet steht unabhängig vom Speicherort des CDA-Dokumentes zur Verfügung und kann nicht versehentlich verloren gehen bzw. gelöscht werden. o Da alle CDA-Dokumente auf die zentralen Stylesheets zugreifen, sehen diese auch für jeden Betrachter gleich aus. o Von einer Aktualisierung eines Stylesheets profitieren alle CDA-Dokumente. o Fehlerhafte Stylesheets können zentral verbessert werden. o Keine fehlerhaften oder veralteten Stylesheets im Umlauf. o Der Dokumentenbetrachter muss sich nicht mehr darum kümmern, mit welchem Stylesheet er das CDA-Dokument darstellen lassen kann. Durch die Referenz im CDA-Dokument auf das Stylesheet auf dem (Web-)Server wird dieses automatisch ausgeführt. Nachteile o Abhängigkeit von einer intakten Netzwerkinfrastruktur. Wenn aufgrund von Netzwerkproblemen nicht auf das Stylesheet zugegriffen werden kann, so kann ein CDA-Dokument nicht dargestellt werden. o Korrekte Ausführung des Stylesheets kann gegebenenfalls vom Betrachtungswerkzeug (Browser) abhängen. Hier muss ein Browser gewählt werden, der diese Art der Stylesheet-Ausführung unterstützt. Aufzählungsliste 56: Vor-/Nachteile der Speicherung des Stylesheets auf einem Server Seite 151 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

166 12 Informationsobjekte 12.6 PDF/A in Zusammenspiel mit CDA PDF-Varianten Ein PDF-Dokument (Portable Document Format) dient der Speicherung und dem Transport von Informationen in Form eines elektronischen Dokumentes, das mit den entsprechenden Programmen unabhängig vom verwendeten Betriebssystem erstellt, bearbeitet und betrachtet werden kann. Dabei wird der Aufbau des Dokumentes originalgetreu auf dem Bildschirm oder ausgedruckt auf Papier wiedergegeben, da das PDF alle Inhalte wie Texte, Bilder oder Grafiken in sich selbst trägt. Das PDF-Format bringt zwar die erforderlichen Eigenschaften für eine Langzeitarchivierung mit sich, jedoch wird keine exakt reproduzierbare Darstellung von Inhalten garantiert, da hierfür in der PDF- Spezifikation die entsprechenden Vorgaben fehlen. Der PDF/A-Standard legt dagegen die erforderlichen Merkmale eines für die Langzeitarchivierung qualifizierten Dokumentes fest und untersagt zugleich die zu vermeidenden Merkmale. Weitere Details dazu finden sich im Anhang Hybrid-Dokumente als Kombination von PDF(/A-3) und CDA Es gibt mehrere Möglichkeiten, die verschiedenen PDF-Varianten mit CDA zu kombinieren. So kann sowohl das CDA-Dokument in PDF eingebettet werden als auch umgekehrt. Die verschiedenen Optionen, deren Erstellung und die dazugehörigen Use Cases werden nachfolgend beschrieben PDF/A-3 mit eingebettetem CDA Die Schritte zur Erstellung eines PDF/A-3-Dokumentes sehen wie folgt dargestellt aus: Das CDA-Dokument wird von einer Software generiert; z. B. erstellt ein Facharzt in einer Arztbrief-Anwendung des Krankenhausinformationssystems (KIS) per Baukastensystem einen Entlassungsbrief für einen Patienten. Durch eine speziell für die Erstellung eines Arztbriefes erstellte XSL-FO-Datei (Extensible Stylesheet Language Formatting Objects), welche die genaue Formatierung des zu erstellenden Zieldokumentes festlegt, wird aus den strukturierten CDA- Daten ein leserliches PDF/A-Dokument generiert. Der Facharzt bekommt eine Vorschau des PDF/A-Dokumentes auf dem Bildschirm angezeigt und überprüft den Inhalt. Ist der Facharzt mit dem Inhalt des generierten PDF/A-Dokumentes einverstanden, so kann er es mit einem Klick finalisieren. Das KIS bzw. die Arztbriefanwendung bettet daraufhin folgende Dateien bzw. Informationen in das PDF/A-Dokument ein: o CDA-Quelldatei o XSL-FO-Datei o Erstellungsprotokoll / Fehlerprotokoll o Informationen über die Erstellungssoftware in den PDF/A-Metadaten o Sonstige für die Reproduktion der Dokumentenerstellung erforderlichen Daten bzw. Informationen. Anschließend wird der Facharzt von der Anwendung aufgefordert, den Dokumenten-Hybriden (PDF/A mit eingebettetem CDA) zu signieren. Seite 152 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

167 12 Informationsobjekte Ausführung der Signatur über die Signaturanwendungskomponente. Hierbei wird das gesamte PDF/A-Dokument signiert (inkl. eingebetteter Dateien). Aufzählungsliste 57: Schritte zur Erstellung eines PDF/A-3-Dokumentes CDA in PDF/A3 XSL (XML) CDA (XML) PDF/A3 (XML) 1.: Erstellen 2.: Preview erzeugen DB 0.: strukturierte Daten PDF/A3 (XML) CDA (XML) PDF/A3 (XML) CDA (XML) 3.: CDA einbetten 4.: Signieren Abbildung 24: Einbettung strukturierter Informationen als CDA-Dokument in PDF/A3 (Nutzung von PDF zur Signatur) Validierung o Schritt 1 - Validierung des PDF/A-3-Formats Grundlage: ISO , ISO Hilfsmittel: PDF/A-Validierer Prüfgegenstand: korrektes A-3 Format, langzeitarchivierbar o Schritt 2 - Validierung der CDA-Struktur Grundlage: XML-Schema (HL7 v3 CDA Schemata) Hilfsmittel: XSD-Validierer Prüfgegenstand: syntaktisch korrektes CDA-Dokument o Schritt 3 - Validierung der Signatur Grundlage: ISO , ETSI (PAdES), ggf. CommonPKI, XMLDSig Hilfsmittel: Signatur-Validierer Prüfgegenstand: Integrität + Authentizität o Schritt 4 - Visuelle Inhaltskontrolle durch Dokumentenerzeuger Aufzählungsliste 58: Schritte zur Erstellung eines signierten PDF/A-Dokumentes Seite 153 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

168 12 Informationsobjekte Die Vor- und Nachteile dieser Lösungsvariante sind: Vorteile o PDF/A als Hauptdokument kann jederzeit vom Anwender geöffnet werden o Betrachtungswerkzeuge (PDF-Viewer) sind verbreitet o Maschinelle Verarbeitung ist ebenfalls möglich o Darstellungstreue des PDF/A-Formates o Langzeitarchivierbar (mit Signatur) o Visueller und non-visueller Dokumententeil in einer Datei Nachteile o Mögliche Probleme bei der Validierung von PDF/A o Unterschiedliche PDF-Viewer können möglicherweise Probleme mit der Signatur haben o Aktuell sind in den Anwendungssystemen keine Schnittstellen implementiert, die ein PDF/A-Dokument empfangen und die darin eingebettete CDA-Datei extrahieren können. Aufzählungsliste 59: Vor- und Nachteile der Nutzung von PDF/A CDA mit eingebettetem PDF/A-3 Die Erstellung eines CDA-Dokumentes mit eingebettetem PDF/A-3 läuft in folgenden Schritten ab: 1. Das CDA-Dokument wird von einer Software generiert; z. B. erstellt ein Facharzt in einer Arztbrief-Anwendung des Krankenhausinformationssystems (KIS) per Baukastensystem einen Entlassungsbrief für einen Patienten. 2. Durch eine speziell für die Erstellung eines Arztbriefes erstellte XSL-FO-Datei (Extensible Stylesheet Language Formatting Objects), welche die genaue Formatierung des zu erstellenden Zieldokumentes festlegt, wird aus den strukturierten CDA- Daten ein leserliches PDF/A-Dokument generiert. 3. Der Facharzt bekommt eine Vorschau des PDF/A-Dokumentes auf dem Bildschirm angezeigt und überprüft den Inhalt. 4. Ist der Facharzt mit dem Inhalt des generierten PDF/A-Dokumentes einverstanden, so bestätigt er dies mit einem Klick. 5. Anschließend wird der Facharzt von der Anwendung aufgefordert, das PDF/A- Dokument zu signieren. Aufzählungsliste 60: Schritte zur Erstellung eines CDA-Dokumentes mit eingebettetem PDF/A-3 Seite 154 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

169 12 Informationsobjekte Nach der erfolgreichen Signatur des PDF/A-Dokumentes wird dieses Base64 encoded in das CDA- Dokument eingebettet. Auch dieses Verfahren hat Vor- und Nachteile: Vorteile o Anwendungssysteme können mit dem CDA-Standard umgehen, entsprechende Schnittstellen für den Empfang und die Weiterverarbeitung von CDA- Dokumenten sind bereits vorhanden. o Nutzung des CDA-Headers für die Festlegung von Metadaten, somit für beliebige Dokumente (bspw. Fax) anwendbar. o Maschinelle Verarbeitung ist möglich. o Darstellungstreue des eingebetteten PDF/A-Formates. o Langzeitarchivierung (mit Signatur) ist auch bei CDA möglich. Entsprechende Signatur-Spezifikationen sind vorhanden. o Visueller und non-visueller Dokumententeil in einer einzigen Datei. Nachteile o PDF/A muss zur Betrachtung erst aus der CDA-Datei extrahiert bzw. decoded werden. Die menschliche Lesbarkeit wird somit der maschinellen Lesbarkeit untergeordnet. Der visuelle Teil ist kodiert in der CDA-Datei gespeichert und kann in diesem Zustand nicht betrachtet werden. o Maschinenlesbares Dokument als Trägerdokument für das menschenlesbare Dokument aus den oben genannten Gründen unvorteilhaft. Aufzählungsliste 61: Vor- und Nachteile CDA mit eingebettetem PDF/A CDA mit eingebettetem PDF Im Gegensatz zu der vorhergehenden Variante wird hier in das CDA-Dokument in ein beliebiges 0.: ausgedrucktes Dokument (mit Signatur) PDF in CDA: XDS-SD PDF CDA (XML) 1.: Einscannen 2.: Metadaten zuordnen DB PDF-Dokument eingebettet, d.h. eines, das nicht den Regeln von PDF/A-3 unterliegt. Dieser Use Case macht bspw. dann Sinn, wenn das Dokument nur im Original vorliegt und eingescannt wird, oder ein beliebiges System nur einfache PDF-Dokumente erzeugen kann bzw. diese über einen PDF-Drucker erzeugt wurden. CDA (XML) PDF 3.: PDF einbetten (Lvl 1a mit base64 oder hex) Abbildung 25: Einbettung eines beliebigen PDF-Dokumentes in CDA (Nutzung des Headers) Seite 155 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

170 12 Informationsobjekte Damit kann anschließend der komplette Dokumenten-Hybrid aus PDF und CDA signiert werden. Jedoch sollte der Dokumentenersteller nur den visuellen Teil des Dokumentes signieren. Demnach haftet er nur für den visuellen Teil des Dokumentes, also für den Inhalt in Form eines PDF-Dokumentes, welches er vor der Signatur angezeigt bekommen hat. Das Base64 encoded PDF-Dokument wird in der CDA-Datei im sogenannten unstrukturierten Body (im Element nonxmlbody) gespeichert. <ClinicalDocument xmlns="urn:hl7-org:v3"> CDA Header <component> <!-- strukturierter CDA Body --> <nonxmlbody> <text mediatype="application/pdf" representation="b64"> </text> </nonxmlbody> </component> </ClinicalDocument> Abbildung 26: Einbettung eines beliebigen PDF-Dokumentes in CDA (XML) 12.7 Validierung der CDA Dokumente Die Validierung von CDA-Dokumenten kann abhängig vom Strukturierungsgrad in mehreren Stufen nach Syntax, Semantik und Inhalt erfolgen. Stufe 1: Validierung der Syntax durch den XML-Parser Stufe 2: XML-Schema-Validierung durch den XML-Parser Stufe 3: Schematron-Validierung des Inhalts Aufzählungsliste 62: Stufen der Validierung von CDA-Dokumenten Die Validierung der CDA-Dokumente erfolgt im Rahmen des Registrierungsvorganges durch das Aktensystem an der Schnittstelle zum Primärsystem. Ein Fehlschlag der Validierung führt dazu, dass das entsprechende Dokument nicht registriert werden kann Syntax Validierung Bei der Syntaxvalidierung durch den XML-Parser handelt es sich um den einfachsten Validierungsvorgang, der ohne zusätzliche Information über die Bedeutung des Inhalts (Semantik) auskommt. Die Syntaxvalidierung erkennt ungültige XML-Dokumente, die gegen die Bildungsregeln der XML-Syntax verstoßen (z. B. fehlende öffnende bzw. schließende Tags, fehlende Anführungseichen bei Attributen), erfordert aber spezielle Parser wie bspw SAX. XML-Syntaxfehler haben in der Praxis mittlerweile an Bedeutung verloren, da die Generierung der CDA-Dokumente meist durch entsprechende Softwarebibliotheken erfolgt, die dafür verantwortlich sind, ein syntaktisch korrektes XML zu generieren. Erfolgt die Erstellung des CDA-Dokumentes ohne entsprechende Softwarebibliotheken z. B. durch String-Operationen, so besteht diese Gefahr weiter- Seite 156 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

171 12 Informationsobjekte hin. Syntaktisch inkorrekte Dokumente können durch einen Standard-XML-Parser (wie bspw. DOM) nicht verarbeitet werden. Die erfolgreiche Syntaxvalidierung ist als Minimalvariante eine Voraussetzung für die erfolgreiche Registrierung. Dadurch wird ausgeschlossen, dass Dokumente beim Abruf aufgrund inkorrekter Syntax durch einen XML-Parser nicht mehr verarbeitet werden können. Die weiteren Validierungsmechanismen beinhalten implizit die Syntaxvalidierung Schema Validierung Das Absolvieren der Schema-Prüfung ist der erste Teil der technischen Validierung. Eine Prüfung gegen das CDA-Schema prüft die gültige Struktur eines CDA-Dokuments, wie beispielsweise: ob die XML-Struktur generell gültig ist ob alle Elemente die richtigen Namen haben ob alle Elemente an der richtigen Stelle platziert sind ob alle gemäß Schema erforderlichen Elemente vorhanden sind Aufzählungsliste 63: Struktur eines CDA-Dokumentes Die Schema-Prüfung stellt sicher, dass es sich beim geprüften CDA-Dokument tatsächlich um eine gültige CDA-Struktur handelt. Die Gültigkeit der Inhalte wird nur in Bezug auf den erforderlichen Datentyp der Elemente geprüft. Hiermit kann beispielsweise sichergestellt werden, dass ein id - Element (technisch) immer eine gültige ID enthält. Damit ein CDA-Dokument als gültig erachtet wird, wird die fehlerfreie Validierung mit dem CDA- Schema als Mindestvoraussetzung dringend empfohlen Schematron Validierung Im Unterschied zu einer CDA Schema Prüfung kann mittels einer Schematron-Prüfung jede beliebige Inhaltsvorschrift geprüft werden. Das Schematron-Prüfmittel wird gemäß der Spezifikationen des jeweiligen Implementierungsleitfadens angefertigt und stellt sicher, dass das geprüfte CDA-Dokument auch jene Anforderungen erfüllt, die über rein strukturelle Anforderungen des CDA-Schemas hinausgehen. Dazu gehören dann auch interne Querbeziehungen und gegenseitige Abhängigkeiten, die nur über Regeln ausgedrückt werden können. Solche Anforderungen sind beispielsweise die gegenseitige In- bzw. Exklusion von Elementen oder die Validierung von Datumsabhängigkeiten oder Wertebereichen. Da ein Schema keine kontextbezogenen Inhalte, Beziehungen oder Abhängigkeiten der Elemente definiert, werden für die konkreten Daten des CDA-Dokumentes eine oder mehrere Inhaltsvorschrif- Seite 157 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

172 12 Informationsobjekte ten in Form von sogenannten Schematron-Skripten festgelegt, welche die Einhaltung von Geschäftsregeln für Elemente oder Abschnitte sicherstellen. Diese Geschäftsregeln können technisch zu Templates zusammengefasst werden und enthalten Bestimmungen über Datentypen, Wertebereiche, Abhängigkeiten, Optionalitäten und Multiplizitäten der Inhalte. Ein CDA-Dokument gilt somit als gültig, wenn es die Vorschriften des Schemas und des Schematons erfüllt. Das Absolvieren der Schematron-Prüfung ist der zweite Teil der technischen Konformitätsprüfung und stellt sicher, dass das geprüfte Dokument sämtliche in dem jeweiligen Implementierungsleitfaden beschriebenen Geschäftsregeln befolgt. Die Schematron Validierung wird insbesondere für CDA-Level-2- und CDA-Level-3-Dokumente empfohlen Schematron Validatoren In der Praxis werden verschiedene Dienste angeboten, die auf Basis der Schematron-Regeln die Gültigkeit von CDA-Dokumenten prüfen: Lantana Group ( NIST ( ART-DECOR (in Arbeit, medshare ELGA (prüft noch den Aufbau eines eigenen Validators oder eine Kooperation mit HL7 Schweiz) Aufzählungsliste 64: Dienste, die auf Basis der Schematron-Regeln die Gültigkeit von CDA-Dokumenten prüfen Seite 158 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

173 12.8 Codesysteme 12 Informationsobjekte Zur eindeutigen Festlegung von Semantik werden Informationen kodiert abgelegt, d.h. man legt nicht die textuelle Information männlich oder weiblich für das administrative Geschlecht in der Datenbank ab, sondern einen repräsentativen Code. Das ist dann häufig eine Durchnummerierung der Elemente ('1', '2', '3', etc.) oder wie in diesem Beispiel vielleicht auch 'm' oder 'w'. Damit diese Codes verständlich werden, werden sie in Form von Codesystemen zusammengestellt und veröffentlicht. Die nachfolgende Tabelle gibt einen Überblick über Codesysteme aus dem medizinischen Bereich. Kodiersystem Inhalt (Beschreibung) Organisation ICD Codierung von Diagnosen im Bereich CDA Level 3 WHO ICD-10-GM ICD-Diagnosen für Deutschland (hier gibt es jährlich DIMDI, D aktualisierte Fassungen) OPS Kodierung abrechnungsrelevanter Prozeduren DIMDI, D DKGNT Deutsche Krankenhausgesellschaft, Normaltarif DKG, D EBM Einheitlicher Bewertungsmaßstab KBV GOÄ Gebührenordnung Ärzte KBV LOINC Dokumente und Prozeduren Regenstrief, USA UCUM Maßeinheiten Regenstrief, USA ISO Länder ISO ISO 639-1:2002 Sprachen ISO Postleitzahlen Snomed CT Systematisierte Nomenklatur der Medizin IHTSDO ATC Wirkstoffe Tabelle 46: Verbreitete Kodiersysteme Die Integration der verwendeten Code Systeme in den ebpg Terminologieserver ermöglicht eine einheitliche Verwaltung der Code-Listen und -Systeme und erlaubt eine Validierung der Informationsobjekte bei der Erstellung sowie innerhalb der Akte. Seite 159 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

174 12 Informationsobjekte 12.9 Allgemeine CDA Header Daten Die im folgenden Kapitel beschriebenen Dokumententypen basieren auf HL7 CDA Release 2. CDA erlaubt beschreibende Daten des jeweiligen Dokumentes (wie z. B. demografische Daten des Patienten, Autor, Institution oder Erstellungszeitpunkt) im CDA-Header zu erfassen. Soweit anwendbar sollten Aufbau und Inhalt dieser Header-Daten für die in ebpg zu verwendenden Dokumente identisch sein. Nachfolgend eine kurze Übersicht: einfache Metadaten: o Dokumenttyp o Dokumenttitel o Dokumenten-ID o Version o Erstellungsdatum o.. komplexe Metadaten: o Patient o Autor/Ersteller o Unterzeichner o Empfänger o Aufzählungsliste 65: Aufbau und Inhalt der Header-Daten Die genaue Festlegung der Header-Datenfür ausgewählte Dokumenttypen findet sich im deutschen HL7 Wiki. 69 In den folgenden Abschnitten wird zum einen der aktuelle Stand der Definition wesentlicher Dokumententypen erläutert, zum anderen werden Anwendungsfälle beschrieben. Dieser Überblick ermöglicht in konkreten Projekten die zielgerichtete Evaluierung von Einsatzszenarien. Der Definition folgt jeweils die Beschreibung des fachlichen Inhalts und der zugehörigen Leitfäden. Abgeschlossen wird jeder Dokumententyp mit einer Empfehlung zur praktischen Umsetzung (letzter Zugriff ) Seite 160 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

175 12 Informationsobjekte Berücksichtigte Dokumententypen sind: Arztbrief ( Entlassungsdokument pflegerisch ( Radiologie Befund (Kopplung mit entsprechendem Bild) Notfalldatensatz Patient Summary Medikation (aktuell verschriebene Medikation) Leitfaden der deutschen Ärzteschaft Elektronische Überweisung Pathologiebefund ( Transitionsbrief ( Übermittlung meldepflichtiger Krankheiten Aufzählungsliste 66: Im deutschen HL7-Wiki berücksichtigte Dokumententypen Ein wesentlicher Bestandteil aller Dokumenttypen sind dabei die Absätze, die ein Dokument enthalten kann. Die nachfolgenden Auflistungen orientieren sich an folgendem Schema: Titel <Titel des Dokumenttyps> Definition Referenz Formale Beschreibung Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Historie Nächste Schritte Herausforderungen Weiterführende Informationen Ansprechpartner Empfehlungen für die Umsetzung Tabelle 47: Raster für Darstellung der Dokumenten-Steckbriefe Seite 161 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

176 12 Informationsobjekte Arztbrief Titel Arztbrief 2014 Definition Referenz Formale Beschreibung Ein Arztbrief ist ein Bericht, der in Form eines Briefes von einem Arzt erstellt und unterschrieben wird. Der Brief richtet sich typischerweise an einen anderen Arzt. Die häufigsten Formen sind: Entlassbericht Behandlungsbericht Verlaufsbericht Dokumenttypen (inhaltliche Struktur) CDA Level 1 (Header und Text) CDA Level 2 (Kodierung der Abschnitte) CDA Level 3 (in Teilen auch kodierte Informationen umgesetzt, z. B. Diagnosen und Medikation) Verbreitung in Deutschland Umsetzung im Echtbetrieb (Projekt eefa Düren, CDA Level 1) Verbreitung analoger Dokumente außerhalb von Deutschland Historie VHitG-Arztbrief (2005) Nächste Schritte Herausforderungen Es existiert eine Verordnung zum ELGA Gesetz, die die Verwendung der CDA Leitfäden im Rahmen der ELGA für Spitäler (bis 01. Januar 2015) und in weiterer Folge für niedergelassene Ärzte vorschreibt. 1. Abgleich mit ELGA und IHE PCC 2. Fertigstellung der Ausarbeitung 3. Akkreditierung als National Extension für XDS-MS bei IHE International 4. Weitere Ausarbeitung als Templates (Section, Entry) 5. Bessere Formalisierung (Schematron Regeln für Level 1, 2,3) Bisher existiert keine deutsche National Extension; international ist bisher auch keine registriert. Weiterführende Informationen VHitG Arztbrief 2005 ( ztbrief/leitfaden-vhitg-arztbrief-v150.pdf) CDA-CH II (Schweiz) ELGA (Österreich, Arztbrief 2014 (neue Ausarbeitung über das Interoperabilitätsforum, wiki.hl7.de) International gibt es mehrere Projekte, die versuchen, die verschiedenen Initiativen zu harmonisieren, z. B. IHE PCC und das "Consolidated CDA IG"-Projekt in den USA. Ansprechpartner Empfehlungen für die Umsetzung Dr. Kai Heitmann (kai.heitmann@hl7.de), Dr. Frank Oemig (frank.oemig@hl7.de) Grundlage für alle anderen Arbeiten in Deutschland, die auf CDA basieren Tabelle 48: Steckbrief Arztbrief Seite 162 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

177 12 Informationsobjekte Fachliche Anmerkungen Ein Arztbrief setzt sich aus mehreren Abschnitten zusammen, wovon die meisten optional sind. Typische Abschnitte eines Arztbriefes sind: Anrede Fragestellung Anamnese Familienanamnese Krankengeschichte, Voruntersuchungen Befunde Diagnosen Besondere Hinweise (CAVE) Therapien/Behandlungsmaßnahmen Behandlungsempfehlungen Risikofaktoren Notizen Epikrise Anhänge Schlusstext Aufzählungsliste 67: Typische Abschnitte eines Arztbriefes Seite 163 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

178 12 Informationsobjekte Entlassungsdokument pflegerisch Titel Entlassungsbericht pflegerisch Definition Referenz Ähnlich dem Arztbrief [earztbrief] dient der Pflegebericht in Verlegungs- oder Entlassungsszenarien als Dokument zur Weiterleitung pflegerischer Informationen über Institutionsgrenzen hinweg. Dies gilt unabhängig von der Form der Versorgung oder Institution. Mithilfe des Pflegeberichts aggregieren ausgebildete Pflegekräfte ihre Pflegedokumentation, die auf dem gesetzlich festgeschriebenen Pflegeprozesses basiert. Der Pflegebericht bildet auf diesem Wege die Basis für eine Kommunikation mit nachgeordneten pflegerischen Einrichtungen, darf aber nicht als Weiterleitung der pflegerischen Verlaufsdokumentation gesehen werden. Der epflegebericht wird im Rahmen eines FuE-Projektes zur elektronischen Patientenakte gemäß 291a SGB V (gefördert durch das BMG) als Anwendungsfall für die epa 291a genutzt. Mit dem Projekt soll die Nutzbarkeit der epa 291a durch den Bürger evaluiert werden. Die Übernahme der Ergebnisse durch IHE Patient Care Coordination, Nursing Subcommittee, wird derzeit geprüft. Formale Beschreibung CDA Level 1 CDA Level 2 CDA Level 3 (in Teilen umgesetzt) Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Historie Nächste Schritte Umsetzung in Piloten (Pflegenetzwerk Osnabrück Es existiert eine Verordnung zum ELGA Gesetz, die die Verwendung der CDA Leitfäden im Rahmen der ELGA für Spitäler (bis ) und in weiterer Folge niedergelassene Ärzte vorschreibt. In Kooperation mit Pflegenetzwerk ausgearbeitet Dieser Implementierungsleitfaden basiert auf vorangegangenen Implementierungsleitfäden: IG:Arztbrief_2006 Konzept zur Patientenidentifikation auf Basis HL7 Version 3 v0.9 sowie auf dem CDA Section-Level-Template: IG:HL7 Diagnosen Die Spezifikationen der HL7 Clinical Document Architecture release 2 beruhen auf der HL7 v3 Normative Edition Für die Modellierung innerhalb dieses Implementierungsleitfadens wurde die HL7 v3 Normative Edition 2010 genutzt. Momentan findet eine Übertragung der Spezifikation auf die HL7 Wiki-Seiten statt. Die Inhalte sollen, genau wie beim earztbrief in wiederverwendbare Templates (Header und Body-Templates) aufgeschlüsselt und beschrieben werden. Das hat den Vorteil, dass man sowohl für den earztbrief als auch den epflegebericht die gleichen Informationen (z. B. über den Patienten) in derselben Darstellungsform austauscht. Ausgehend von dem epflegebericht, wird gerade der ewundbericht (Abschlussdokumentation einer Versorgungsepisode chronischer Wunden) entwickelt. Die Konsentierung der Inhalte mit den drei zentralen Fachgesellschaften ist fast abgeschlossen, so dass im 2. HJ Seite 164 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

179 12 Informationsobjekte Titel Entlassungsbericht pflegerisch Herausforderungen 2013 mit der Entwicklung des Implementierungsleitfadens begonnen wird. Übernahme (Integration) der Spezifikation durch das IHE Nursing Subcommittee Weiterführende Informationen epflegebericht_v60_ zip Ansprechpartner Daniel Flemming Dr. Kai Heitmann Dr. Frank Oemig Empfehlungen für die Umsetzung Tabelle 49: Steckbrief Entlassungsbericht pflegerisch Fachliche Anmerkungen Neben notwendigen medizinischen Daten werden auch pflegerische Informationen als zentraler Bestandteil der Gesundheitsinformationen mehr an Bedeutung gewinnen. Unabhängig von den Versorgungsformen ergeben sich diese immer aus dem Pflegeprozess, der zyklisch mit den vier Kontrollpunkten Einschätzen, Planen, Durchführen und Verfolgen iteriert wird. Der Pflegeprozess umfasst als Schritte eine Informationssammlung als Darstellung des aktuellen Zustand des Patienten die Ableitung von Pflegediagnosen bzw. Pflegeproblemen daraus resultierende Ziele pflegerischen Handelns die Planung pflegerischer Maßnahmen die Durchführung pflegerischer Maßnahmen und die Evaluation der durchgeführten Maßnahmen, die wieder zur Informationssammlung führt Aufzählungsliste 68: Schritte des Pflegeprozesses Seite 165 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

180 12 Informationsobjekte Radiologie Befund (Kopplung mit entspr. Bild) Titel Definition Referenz Formale Beschreibung Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Historie Nächste Schritte Herausforderungen Radiologie Befund Ein Radiologie Befund ist ein Bericht als Antwort auf eine bilddiagnostische Anforderung, der in Form eines Briefes von einem Arzt (Radiologen) erstellt und unterschrieben wird. Der Befundbrief richtet sich typischerweise an einen anderen Arzt. Sobald der Befundbrief die erstellende Institution verlässt, soll dieser mit den dazugehörigen Bildern (gesamte Studie und/oder Key Images) gekoppelt sein. ELGA Harmonisierungsarbeit für medizinische Dokumente : CDA Level 1 (Header und Text) CDA Level 2 (Kodierung der Abschnitte) Keine Die vorliegende Spezifikation kommt aus Östereich. Es existiert eine Verordnung zum ELGA Gesetz, die die Verwendung der CDA Leitfäden im Rahmen der ELGA für Spitäler (bis ) und in weiterer Folge für niedergelassene Ärzte vorschreibt. n.a. Fertigstellung der Ausarbeitung im HL7 Wiki. Bisher existiert keine Erfahrung aus Umsetzungen in Deutschland. Es ist zu evaluieren, ob die Verwendung eines solchen Befundbriefes im institutionsübergreifenden Workflow klinisch akzeptiert wird. Weiterführende Informationen ELGA (Österreich, perspektivische Prüfung Ansprechpartner Empfehlungen für die Umsetzung Dr. Florian Wozak (florian.wozak@ith-icoserve.com), Dr. Martin Grandy (martin.grandy@siemens.com) Empfehlung für die nächste Version des Radiologiebefundbriefes: Angabe von Modalität und untersuchter Körperregion in codierter Form, damit diese Daten zum Filtern bzw. Suchen in der Akte herangezogen werden können (z. B. Anzeige aller radiologischen Befundbriefe, die sich auf das Abdomen beziehen). Denkbar wäre auch eine Verlinkung im Befundbrief: Schriftlicher Hinweis auf einen Vorbefund ist als Link realisiert und öffnet direkt das zugehörige Befunddokument. Tabelle 50: Steckbrief Radiologiebefund Fachliche Anmerkungen Radiologiebefunde werden auf Basis von CDA erstellt und bilden eine Einheit mit dem zugrundeliegenden DICOM Bild. Die Definition des Radiologie Befundes erfolgt in Anlehnung an die CDA Harmonisierungsdokumente der ELGA Seite 166 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

181 12 Informationsobjekte Optionalität Sektion / Titel Section Code (LOINC) [R2] DICOM Object Catalog [O] Brieftext (Anrede, Grußformel etc.) BRIEFT (ToDo: Ersetzen durch entsprechenden Code aus CDA-Arztbrief) Anrede = X-SALUT (Arztbrief 1.5) [M] Anforderung [M] Anamnese [O] Familienanamnese [M] Indikation / Fragestellung [O] Patientenstatus / Patientenangaben [R2] Risikofaktoren, Hinweise (CAVE) [M] Aktuelle Untersuchung [O] Frühere Untersuchungen [O] Frühere Befunde [O] Komplikationen [M] Befund [O] Zusammenfassung / Ergebnis [O] Verdachtsdiagnose [O] Schlussfolgerung [O] Empfehlung [O] Schlüsselbilder* Tabelle 51: Inhalte eines Radiologiebefundes Die technische Kopplung zwischen Bild und Befund ist hierfür wesentlich und wird kann durch ein Mapping der DICOM Metadaten mit den XDS Metadaten erreicht werden. Sollte für den Befund der bildgebenden Diagnostik ein CDA-Dokument aus einem vorhandenen DICOM Structured Report erzeugt (transformiert) werden, so wird auf den in Zusammenarbeit von HL7 und NEMA erstellten Implementierungsleitfaden Implementation Guide for CDA Release 2: Imaging Integration. Levels 1, 2, and 3. verwiesen 71, welcher dazu wesentliche zusätzliche Definitionen und Vorgaben beinhaltet. Der allgemeine Befund Bildgebende Diagnostik umfasst die in der folgenden Tabelle dargestellten Modalitäten-spezifischen Detailausprägungen. Die Klassifizierung eines Befunds Bildgebende Diagnostik erfolgt mit dem für die durchgeführte Untersuchung zutreffendsten Code aus der untenstehenden Tabelle. Sollte kein spezifischer Code wählbar sein, so ist der übergeordnete Code für das Dokument zu wählen. 71 HL7 Inc. / NEMA: Implementation Guide for CDA Release 2: Imaging Integration. Levels 1, 2, and 3. Basic Imaging Reports in CDA and DICOM Diagnostic Imaging Reports (DIR) Universal Realm; Release 1.0, 2009, ( Seite 167 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

182 12 Informationsobjekte Bei der Registrierung des Dokuments in einer Registry wird in den XDS-Daten zum gewählten Code, der als TypeCode abgebildet wird, immer auch der übergeordnete Code als ClassCode eingetragen. LOINC Code Display Name Beschreibung Diagnostic Imaging Report Befund bildgebende Diagnostik (übergeordneter Code) CT Report Computertomografie-Befund MRI Report Magnetresonanztomografie-Befund Ultrasound Report Ultraschall-Befund Nuclear Medicine Report Nuklearmedizinischer Befund PET Scan Report Positronen-Emissions-Tomografie-Befund Cardiac Catheterization Report Herzkatheter-Befund Echocardiography Report Echokardiografie-Befund X-ray Report Radiologie-Befund Colonoscopy Report Kolonoskopie-Befund Endoscopy Report Endoskopie-Befund Obstetrical Ultrasound Report Geburtshilfliche Ultraschalluntersuchung Tabelle 52: LOINC-Codes für den Radiologiebefund Alle Befunde Bildgebende Diagnostik werden abhängig von Inhalt oder verwendeter Untersuchungsmethode aus Tabelle 1 codiert. Sollte eine Spezialisierung nicht möglich bzw. gewünscht sein, so ist folgender LOINC Code anzugeben: , Diagnostic Imaging Report. Es existieren zurzeit zwei Leitfäden: IHE Rad Structured Reporting und ELGA Radiologiebefund. Seite 168 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

183 12 Informationsobjekte Notfall Datensatz Titel Definition Referenz Notfalldatensatz Patient summary und Notfalldatensatz sind ähnlich im intented use, man kann den Notfalldatensatz als Teil der Patient Summary betrachten. Siehe Kapitel Notfalldaten egk, bzw. Forderung Bundesärztekammer. Ein wichtiger Bestandteil sind Medikationsdaten. Standardisierungsbemühungen und Projekte im Umfeld der Medikation sind in Kapitel aufgelistet. Spezifikationen der egk und der Bundesärztekammer (BÄK) Formale Beschreibung Siehe Kapitel Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Keine Unbekannt Historie Siehe Kapitel Nächste Schritte Aus pragmatischen Gründe (Reifengrad des Primarsystems als Information Provider) empfiehlt sich der Notfalldatensatz als Teil der manuell gepflegten Patienten Summary umzusetzen. Herausforderungen Siehe Kapitel Weiterführende Informationen Ansprechpartner Empfehlungen für die Umsetzung zept.pdf gematik - Fachkonzept Daten für die Notfallversorgung (Notfalldaten) Version Johannes Schenkel; Jürgen Albert; Georgios Raptis Spezifikationen der Bundesärztekammer (BÄK) folgend Als Teil der Patient Summary Tabelle 53: Steckbrief Notfalldatensatz Seite 169 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

184 12 Informationsobjekte Patient Summary Titel Definition Referenz Formale Beschreibung Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Patient Summary Intended use: Ein Patient Summary (Patientenkurzakte) bietet ÄrztInnen einen Überblick über den Patienten, ohne eine langwierige Recherche in verschiedene Dokumenten zu benötigen. Es ist besonders nützlich für den Erstkontakt und kann in Notfallsituationen Patienteninformationen für die behandelnden Ärzte bereitstellen und somit die Qualität und Sicherheit der Behandlung verbessern (z. B. indem die Verschreibung unverträglicher Medikamente bzw. Medikamentenkombinationen verhindert wird). Daher sind Patient Summary und Notfalldatensatz ähnlich im intented use, man kann den Notfalldatensatz als ein Teil der patient summary betrachten. Inhalte beschrieben in Kapitel Not intented use: ersetzt nicht andere Dokumenten (Entlassungsbrief...) Abgrenzung/ Schnittstellen zu anderen Dokumententypen: es ist mehr einen Abstrakt aus anderen Dokumenten und die Qualität eines Patient Summary ist hochgradig von seiner Aktualität abhängig! (up dates und Datum/Verfasser klar beschrieben!) EPSOS _Pivot_Document_Specifications_01.pdf HL7 CDD/ CCR IHE PCC XDS-MS (siehe auch EPSOS: _Pivot_Document_Specifications_01.pdf) Keine EPSOS in Europa in Pilotprojekt, UK SCR ( /impguidpm/deploy) Historie EPSOS Patient Summary (siehe ) SCR Summary Care Record (UK, published by NHS) 2011 Nächste Schritte Aus pragmatischen Gründen (Reifegrad des Primarsystems als Information Provider) wird man sich in der ersten Stufe auf einen manuell gepflegten Patienten Summary einigen. Das ist auch die Empfehlung von EPSOS. Zukunftszenario: Basiert auf CDA Level 2 und 3 automatischer Extraktion von granularen Informationen. 1. auf Sektionsebene. Extraktion von letztgeschriebene Anamnese/ Allergien/ Medikation 2. auf Kodierungslevel: Extraktion von Diagnosen/ Problemen/ etc Herausforderungen Bereitstellung der Daten für Dokumente mit CDA Level 2 und 3 durch die Primärsysteme Weiterführende Informationen impguidpm/deploy Seite 170 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

185 12 Informationsobjekte Titel Patient Summary ion_functional_service_req_patient_summary.pdf Ansprechpartner Empfehlungen für die Umsetzung Dr. Jacqueline Fedy, Prof. Dr. Sylvia Thun Akzeptierter internationaler Standard vorhanden, jedoch aktuell national kein Bestreben, diesen Standard umzusetzen, bekannt. Tabelle 54: Steckbrief Patient Summary Medikationsplan Fachlicher Rahmen Der fachliche Rahmen unterscheidet sich bei den jeweiligen Standards/Projekten. Dabei werden die genauen fachlichen Bedingungen nicht bei allen Standards im Detail angegeben, so dass der fachliche Rahmen nicht immer spezifiziert werden kann. Der Medikationsplan umfasst in der Regel: Aktuelle Medikation Vormedikation Medikation bei Aufnahme Medikation bei Entlassung aus dem Krankenhaus Klinischer Zustand des Patienten Aufzählungsliste 69: Medikationsplan Nachfolgend werden verschiedene Standardisierungsansätze zur Medikation beschrieben. Seite 171 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

186 12 Informationsobjekte AkdÄ Medikationsplan Name Definition Referenz Formale Beschreibung Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Medikationsplan Hauptziel des Medikationsplans ist es, dem einzelnen Patienten eine zusammenfassende Information über die von ihm aktuell einzusetzenden Arzneimittel bereit zu stellen und ihm Hinweise für deren richtige Anwendung zu geben. Grundlage dafür sind die Vorgaben, die von einem Heilberufler bei der Verordnung oder dem Erwerb zur Selbstmedikation gegeben werden. Darüber hinaus soll der Medikationsplan auch die verschiedenen am Medikationsprozess beteiligten Heilberufler (insbesondere in Arztpraxis, Krankenhaus, Apotheke, Pflegeeinrichtung) über die Gesamtmedikation des jeweiligen Patienten informieren. Im Rahmen des Projekts wurde 2012 mit der Spezifikation des AkdÄ Medikationsplan auf Basis CDA gestartet ( Der AkdÄ Medikationsplan verwendet zwei Komponenten. Zum einen den sogenannten DataMatrix Barcode, um auf dem Medikationsplan einen 2D Code abbilden zu können. Mit Hilfe des Barcodes haben unterschiedliche Institutionen die Möglichkeit den Medikationsplan in das eigene System einzuscannen. Des Weiteren kommt die ATC-Klassifikation zum Einsatz, um die Wirkstoffbezeichnungen darzustellen. Der AkdÄ Medikationsplan bildet dabei die aktuelle (jetzige) Medikation ab. Technisch umgesetzt in Piloten Unbekannt Historie Angestoßen durch den Aktionsplan AMTS im Mai 2012 Nächste Schritte Herausforderungen Weiterführende Informationen Ansprechpartner BMG Aktionsplan (AMTS) (Präsentation Dr. Aly) (letzter Zugriff ) Abgleich und Harmonisierung der diversen Aktivitäten Medikationsplan V2.0: Dr. Farid Aly Dr. Gunther Hellmann Dr. Horst Möller Referenzen Medikationsplan (letzter Zugriff ) Empfehlungen für die Umsetzung Basiert nicht auf anerkannten internationalen Standards. Ausdrucksmächtigkeit der formalen Beschreibung (Barcode) reicht nicht aus, um die Medikation inhaltlich umfassend darzustellen (Dosierungsangaben sind ausreichend für den Arzt, aber nicht für die Systemdarstellung). Für die Daten im Barcode gibt es keine Grammatik, um den Inhalt einfach parsen zu können. Tabelle 55: AkdÄ Medikationsplan Seite 172 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

187 12 Informationsobjekte Addendum Medikation Name Definition Referenz VHitG Addendum Medikation Das von der VHitG vorgelegte Addendum Medikation soll zur Abbildung von Medikamentenverordnung und - verabreichung im Kontext des elektronischen Arztbriefs eingesetzt werden. Dabei soll speziell das Addendum Medikation in den stationären Entlassbrief bzw. in den Facharztbrief eingebettet werden. Laut Autor besteht das Problem bei der Medikationsvergabe zum größten Teil in der fehlenden Auswertbarkeit. Entsprechende Informationen würden häufig nur als narrativer Text (Listen, Tabelle, etc.), als CDA Brief in Level 1 oder Level 2 übermittelt. Formale Beschreibung CDA Level 1 CDA Level 2 CDA Level 3 Folgende Ausprägungen der Medikation sind im Addendum Medikation definiert: Medikamenten Anamnese Medikation bei Aufnahme Medikamente bei Entlassung aus dem Krankenhaus Jetzige Medikation Impfungen Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Historie Keine Pilotprojekte vorhanden. Allerdings bauen bekannte Ansätze darauf auf (z. B. Elektronische Patientenakte gemäß 291A SGB V). Unbekannt VHitG Arztbrief Version 1.5 Stand Aktuell wird an der VHitG Arztbrief Version 2012 gearbeitet Nächste Schritte Herausforderungen Weiterführende Informationen Ansprechpartner Empfehlungen für die Umsetzung Andreas Kassner (andreas.kassner@bvitg.de) Hohe Relevanz, Nutzung dieser spezifizierten Sektion auch in weiteren Kontexten (z. B. Medikationsplan, Transitionsbrief, Notfalldatensatz etc.) Tabelle 56: Addendum Medikation Seite 173 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

188 12 Informationsobjekte Überweisung Titel Definition Referenz Formale Beschreibungen Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Historie Überweisung Die Überweisung häufig auch als Einweisung bezeichnet findet in der gerichteten/adressierten Kommunikation Verwendung z. B. als bedruckte Formulare. Dennoch ist eine ergänzende Übernahme als CDA-Dokument in eine eepa denkbar, da mit der Überweisung auch medizinische Informationen transportiert werden. Weitere Verwendungszwecke: Vergleiche auch essdigitalisierung_durch_mehrwertanwendungen.pdf Als Grundlage für den Überweisungsschein dienen die von der Kassenärztlichen Bundesvereinigung (KBV) in [Vereinbarung über Vordrucke für die vertragsärztliche Versorgung] vorgeschriebenen Formularvordrucke. Im Folgenden werden dazu die Vordrucke Muster 2b (Verordnung von Krankenhausbehandlung), Muster 6 (Überweisungsschein) und Muster 10 (Überweisungsschein für Laboruntersuchungen als Auftragsleistung) näher betrachtet, die sowohl die Überweisung von ambulant zu ambulant als auch die Einweisung von ambulant zu stationär abdecken. In [Technisches Handbuch Blankoformularbedruckung: uch.pdf ] werden zu jedem der zuvor genannten Formulare die darin enthaltenen Datenfelder aufgelistet. Anhand dieser Daten kann eine Analyse der Felder (siehe Anhang A.5), die eine entsprechende CDA-Instanz abdecken müssten unkompliziert durchgeführt werden. Es zeigt sich, dass die auf den jeweiligen Formularen erfassten Daten sehr ähnlich sind, so dass es sich anbietet, einen gemeinsamen Leitfaden für alle drei Formulare zu entwerfen. inhaltliche Beschreibung (Vordruckvereinbarung siehe: Leitfaden im Rahmen dieses Kompendiums. Keine Unbekannt Keine Nächste Schritte Erstellung / Etablierung eines initialen Leitfadens Erweiterung auf weitere Anforderungen Herausforderungen Einbringung in eine Standardisierungsinstitution Weiterführende Informationen Ansprechpartner Empfehlungen für die Umsetzung Stephan Janz (CSC) Siehe nächste Schritte Tabelle 57: Steckbrief Überweisung Seite 174 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

189 12 Informationsobjekte Pathologiebefund Titel Definition Referenz Formale Beschreibung Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Historie Nächste Schritte Herausforderungen Ansprechpartner Pathologiebefund Der Pathologiebefund wird als Abschlussbericht zu einer Gewebeuntersuchung bzw. Obduktion verfasst und bezieht sich somit auf eine Sammlung eingesandter Materialien bzw. den menschlichen Körper als Ganzes. Eine Spezialform ist der Schnellbefund, der noch während einer laufenden OP erstellt wird und Handlungsrückschlüsse für den Operateur in Bezug auf eine vorliegende Erkrankung zulässt. IHE AP APSR (Spez. auf Basis von CDA mit sehr stark detaillierten und strukturierten Templates, die jeweils organspezifisch sind); Umstellung über HL7 AP APSR auf einen generischen Ansatz Diverse Projekte, u. a. Digital Pathology der EU Nicht bekannt, allerdings wird Existenz angenommen. Erster Draft 2009 (HL7-Wiki); danach Versuch der Kontaktaufnahme mit dem Pathologenverband, was zwei Jahre gedauert hat; inzwischen Gründung von IHE AP mit Erarbeitung von APSR; jetzt Abgleich der Spezifikationen. Auf dem F2F im August 2013 wurde beschlossen, den generischen Ansatz zu folgen, ein Change Proposal wurde akzeptiert und befindet sich derzeit in Umsetzung. Vertreter des Pathologenverbandes arbeiten an der Spezifikation. Herausarbeitung der notwendigen Ergänzungen als individuelle Templates: mplate plate Abgleich mit dem onkologischen Leitfaden, der in Kooperation mit der dt. Krebsgesellschaft erarbeitet wird. Vgl. Change Proposal zu APSR Prof. Haroske (Unikl. Dresden) Prof. Schrader (Co-Chair IHE AP) Weiterführende Informationen IHE AP APSR ELGA Pathologiebefund (noch in Arbeit) HL7-D Pathologiebefund: Empfehlungen für die Umsetzung Bisher sind die alten Spezifikationen von IHE AP APSR in (europäischen) Pilotprojekten für spezielle Entitäten umgesetzt worden. Aufgrund des Detaillierungsgrades der bisher ausgearbeiteten Templates ist eine nachhaltige Pflege der Umsetzungen nicht dauerhaft zu gewährleisten. Daher ist derzeit eine Überarbeitung der Spezifikation geplant, bei der auf ein generisches Modell gewechselt werden soll, dessen Umsetzung dann eine höhere Nachhaltigkeit und Stabilität verspricht. Diese Arbeiten laufen aber noch. Tabelle 58: Steckbrief Pathologiebefund Seite 175 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

190 12 Informationsobjekte Fachliche Anmerkungen Für die Dokumenttypen Pathologisch- anatomische Begutachtung/Erstbericht und Obduktions-/ Sektionsgutachten soll ein Pathologiebefund folgende Abschnitte umfassen: Lvl Dokumentabschnitt Pathologischanatomische Begutachtung/ Erstbericht 1 Anrede Vorbefunde Klinische Information Fragestellung Anamnese "Active problem" Material-Klinische Information 0..* 0..* 1 Intraoperative Untersuchung 0..* 2 - Material-Intraoperative Untersuchung 0..* 0..* 2 - Prozess-Intraoperative Untersuchung 0..* 0..* 1 Makroskopische Beschreibung 1..* 2 - Material-Makroskopie 0..* 0..* 1 Mikroskopische Beschreibung 1..* Material-Mikroskopie 0..* 0..* 2 - Immunhistologie 0..* 0..* 1 Diagnose 1..* 2 - Material-Diagnose 1..* 2 - TNM-Diagnose 0..* 2 - ICD-O-Diagnose 0..* 2 - R-Klassifikation 0..* 2 - ausführliche kritische gutachterliche Stellungnahme/Epikrise/Kommentar Materialaufbereitung 1..* Materialangaben 1..* 2 Grundleiden/Todesursache (klinisch) Grundleiden/Todesursache (autoptisch) Äußere Leichenschau Innere Leichenschau Unterbeauftragung 0..* 0..* 1 Diagnose(n) konsiliarischer Untersuchungen 0..* 0..* 1 Schlusstext Tabelle 59: Abschnitte im Pathologiebefund Obduktions-/ Sektions- Gutachten Seite 176 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

191 12 Informationsobjekte Transitionsbrief Titel Definition Referenz Transitionsbrief Der Transitionsbrief ist eine Sonderform des CDA Arztbriefes. Er dient im Rahmen der Transition als Werkzeug zur Informationsweitergabe vom Kinderarzt zum Erwachsenenmediziner. Neben den typischen Abschnitten eines Arztbriefes (Anrede, Diagnose, Therapie etc.) umfasst der Transitionsbrief weitere spezifische Sektionen: Psychosoziale Aspekte, Ausbildung und Beruf, Sexualität, Mobilität (z. B. Führerschein), Behinderung. Formale Beschreibung CDA Level 1 CDA Level 2 CDA Level 3 Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Fachkonzept verbreitet für verschiedene Fachbereiche (Epilepsie, Rheumatologie, Diabetologie, Nephrologie); technischer Standard gewünscht Unbekannt Historie Angestoßen durch Fraunhofer ISST und DRK Kliniken Berlin in 2011; 1. Version der Spezifikation zur fachlichen Abstimmung veröffentlich (2013). Mit Fachanwendern erarbeitet. Nächste Schritte Herausforderungen Weiterführende Informationen Ansprechpartner Empfehlungen für die Umsetzung Fachliche Abstimmung im Sommer Technische Abstimmung im Interoperabilitätsforum ab Herbst Transitionsbrief ist fachbereichsübergreifend <Link einfügen> Dr. Silvia Müther (s.muether@drk-kliniken-berlin.de) Salima Houta (salima.houta@isst.fraunhofer.de) Bisher keine technische Umsetzung des Konzepts Hohe Relevanz Thematik wird von Fachgesellschaften vorangetrieben Tabelle 60: Steckbrief Transitionsbrief Seite 177 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

192 12 Informationsobjekte Übermittlung meldepflichtiger Krankheiten earztmeldung-ifsg Titel Definition Referenz Formale Beschreibung Verbreitung in Deutschland Verbreitung analoger Dokumente außerhalb von Deutschland Historie Nächste Schritte Herausforderungen earztmeldung-ifsg Die Arztmeldung nach 6 IfSG ist eine Meldung über meldepflichtige Krankheiten, die von einem Arzt in der Praxis oder im Krankenhaus erstellt wird. Eine Unterschrift ist nicht erforderlich. Die Meldung richtet sich an das zuständige Gesundheitsamt. Von dort aus werden die geprüften Fälle elektronisch über die Landesstellen an das Robert Koch-Institut weitergeleitet. Inhalt der Meldungen nach IfSG ist die Übermittlung meldepflichtiger Infektionskrankheiten bzw. Erregernachweise durch Ärzte und Labore an die zuständigen Behörden. In den meisten Fällen sind dies die Gesundheitsämter entweder am Ort des Krankenhauses oder dem Wohnort des Patienten. Dies dient u. a. dazu, dass die zuständigen Behörden geeignete seuchenhygienische Maßnahmen zum Schutz der Bevölkerung einleiten können und ein umfassendes Lagebild bei Epidemien erhalten. _Krankheiten CDA Level 1 (Header und Text) CDA Level 2 (Kodierung der Abschnitte) CDA Level 3 (in Teilen auch kodierte Informationen umgesetzt, z. B. Diagnosen) Umsetzung im Pilotprojekt (Rhein-Kreis Neuss) Aktuell wird in Österreich an der Entwicklung einer elektronischen Meldung für Infektionskrankheiten gearbeitet. Es bestehen bereits erste Kontakte zum dortigen Projekt und es wird angestrebt die Dokumente und Leitfäden zu harmonisieren. Dieser Implementierungsleitfaden basiert auf vorangegangenen Implementierungsleitfäden: IG:Arztbrief_2006: IG:Arztbrief_2014: sowie auf dem CDA Header-Level-Template: Patient_(recordTarget) Target%29_%28Template%29 Teilweise beruhen die verwendeten Templates bereits auf Consolidated CDA. In Zusammenarbeit mit dem Gesundheitsamt Grevenbroich, der NRW-Landesstelle und dem Robert Koch-Institut ausgearbeitet. Nach Auflösung der Kommentare aus dem Ballot (August/September 2013) sollen noch fehlende Value-Sets (z. B. Symptome) zum Implementierungsleitfaden ergänzt werden. Die earztmeldung-ifsg wurde 2011 entwickelt und prototypisch umgesetzt. Es ist geplant basierend auf der earztmeldung ebenfalls einen HL7/CDA-Implementierungsleitfaden für die Labormeldung nach 7 IfSG über meldepflichtige Erreger und Nachweise zu erstellen. Über die bereits erfolgte inhaltliche Abstimmung zu Informationsmodell und Value-Sets hinaus, soll eine weitgehende Kompatibilität mit Seite 178 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

193 12 Informationsobjekte den Entwicklungen des DEMIS-Projektes erreicht werden, so dass die earztmeldung-ifsg auch zukünftig bei einem bundesweit einheitlichen Meldesystem eingesetzt werden kann. Im Kontext mit der Labormeldung besteht die Herausforderung eine einheitliche Terminologie für die Abbildung der Erreger, Nachweise und Materialien zu finden, die eine Kodierung auf CDA-Level 3 und damit eine teilweise automatisierte Auswertung der Meldung erlauben. Weiterführende Informationen Ansprechpartner Projektsteckbrief ( Projekt%29) Lars Treinat (l.treinat@ztg-nrw.de), Mathias Aschhoff (m.aschhoff@ztg-nrw.de) Dr. Kai Heitmann (kai.heitmann@hl7.de), Dr. Frank Oemig (frank.oemig@hl7.de) Empfehlungen für die Umsetzung Das System sollte den Meldepflichtigen bei der Erfüllung seiner gesetzlichen Meldepflicht unterstützen und entlasten. Die Meldung könnte weitgehend automatisch generiert werden und bräuchte nur noch vom Meldepflichtigen selbst ausgelöst zu werden. Bei der Implementierung der earztmeldung-ifsg kann für die Erkennung eines potentiell meldepflichtigen Falles auf eine in den meisten PVS/AIS vorhandene Funktionalität zugegriffen werden, welche ein Kennzeichen zur Meldepflicht in den vom DIMDI herausgegebenen ICD-10 Metadaten nutzt. Tabelle 61: Steckbrief earztmeldung-ifsg Fachliche Anmerkungen: Die Arztmeldung bildet die Anforderungen der namentlichen Meldung über meldepflichtige Krankheiten nach 6 IfSG ab und setzt sich aus mehreren Abschnitten zusammen, wovon die meisten optional sind. Typische Abschnitte sind: Diagnose Symptom Angaben zum Tod Zusatzangaben, z. B. Erkrankungshäufung Betreuung in Krankenhäusern oder anderen Einrichtungen Angaben zu beruflichen Tätigkeiten des Patienten Impfstatus Angaben zu Auslandsaufenthalten, möglicher Exposition zu Erregern sowie bei Tuberkulose zu Geburtsland und Staatsangehörigkeit Angaben über ggf. erfolgte Blut-, Gewebe-, Zell- oder Organspenden in den letzten 6 Monaten Angaben zur beauftragten Untersuchungsstelle (beauftragtes Labor) Aufzählungsliste 70: Abschnitte der Meldung über meldepflichtige Krankheiten Seite 179 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

194 12 Informationsobjekte XDS Metadaten Das IHE XDS.b Integration Profile definiert Metadaten, die den Dokumenten zugeordnet und in der XDS Registy abgespeichert werden. Anhand dieser Metadaten kann eine Suche nach Dokumenten erfolgen. Die im Rahmen von ebpg definierten XDS Metadaten sind, soweit technisch durch ein eindeutiges Mapping möglich, mit den CDA Header Daten (siehe Kapitel 12.9) semantisch identisch. Im Anhang in Kapitel A.4 ist eine Mappingtabelle von CDA auf XDS eingefügt. Seite 180 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

195 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa 13.1 AP01 Datenschutz- und Sicherheitsmechanismen Die in AP01 konzipierte Basisrahmensicherheitsarchitektur dient der Absicherung der ebpg-plattform und ihrer Clients gegen interne und externe Bedrohungen. Die technische Abbildung der Sicherheitsaspekte wird durch Interoperabilitäts-Profile beschrieben. Für die eepa besonders relevante Aspekte sind z. B. das Identitätsmanagement und das Policy-basierte Berechtigungsmanagement. Im Arbeitspaket AP01.08 wurde weiterhin eine Lösung zur Realisierung von Ende-zu-Ende- Vertraulichkeit im IHE- Umfeld entwickelt. Die XDS konforme Dokumentenverschlüsselung erfolgt mittels eines Krypto-Moduls, das als Software-Plugin oder als eigenständiges Hardware-Modul realisiert werden kann. Zur der Speicherung von vertraulichen Patientendaten (Dokumente, Referenzen auf Dokumente, Metadaten) in einer eepa sind diese beim Verlassen des Primärsystems des Leistungserbringers zu verschlüsseln. Erst bei einem autorisierten Leistungserbringer, der die Dokumente aus der Akte abruft, sind diese wieder zu entschlüsseln. Zu den schutzwürdigen Daten gehören nicht nur die Dokumente selbst, sondern teilweise auch die Metadaten der Dokumente (z. B. Namen des Patienten und des Leistungserbringers). Im IHE-Kontext sind dies Teile von XDS-Metadaten, bei den Inhalten sind es CDA-Header-Daten. Zur CDA-konformen Speicherung von verschlüsselten Dokumenten in einem XDS Repository werden die verschlüsselten Dokumente inkl. der verschlüsselten Metadaten und Informationen zum Verschlüsselungsverfahren, in ein Wrapper-CDA eingebettet. Die nach außen sichtbaren Metadaten im Header des Wrapper-CDA und in der XDS-Registry werden um datenschutzrechtlich kritische Daten bereinigt. Eine patienten-kontrollierte Ver- und Entschlüsselung kann durch Speicherung des kryptographischen Schlüssels auf seiner Smartcard (z. B. elektronische Gesundheitskarte) oder Ausdruck eines Tickets realisiert werden. Da der Patient zur Aushändigung des Schlüssels nicht immer physisch anwesend sein kann, muss der Schlüssel auf verschiedenen Wegen an den Leistungserbringer übergeben werden können (z. B. fernmündlich). Der Patient muss aber jedem Leistungserbringer den Schlüssel übermitteln, der Zugriff erhalten soll. Der Besitz des Schlüssels kann auch als eine Komponente der Autorisierung dienen. Eine Aufteilung des Schlüssels in mehrere Segmente und Verteilung an mehrere Akteure kann die Sicherheit weiter erhöhen. Beispielsweise wird ein Teilschlüssel vom Patienten verwaltet und ein weiterer Teilschlüssel liegt auf einem Schlüsselserver. Seite 181 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

196 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Abgleich AP01 - AP04 Aus den im AP01.08 unter primärer Ausrichtung auf Datenschutzaspekte erarbeiteten Ergebnissen und den im AP04 ermittelten Anforderungen an eine eepa ergeben sich diese konkurrierenden Aspekte: Berechtigungen und Metadaten AP01.08: Aus Datenschutzgesichtspunkten sollen nur die für die Identifizierung der Dokumente unbedingt notwendigen XDS-Metadaten verwendet werden. Je mehr Metadaten der CDA-Wrapper unverschlüsselt für Dritte, z. B. bei Dienstleistern die Aktensysteme oder Speicherressourcen bereitstellen, einsehbar sind, desto größer ist die Gefahr, dass Unbefugte durch Kombination dieser Daten Informationen über den Patienten und dessen Krankheitsbild erhalten. Um gezielt nach Dokumenten suchen zu können, ist es notwendig sofern für die Suche relevante XDS-Metadaten verschlüsselt sind alle Dokumente in das Primärsystem des Leistungserbringers zu transferieren und zu entschlüsseln, um mit Hilfe der kompletten Metadaten eine entsprechende Filterung vorzunehmen. Der Leistungserbringer kann dann aber auch auf alle Dokumente zugreifen. Eine gezielte feingranulare Berechtigungssteuerung durch den Patienten ist nicht mehr möglich. Die im vorgeschlagenen Berechtigungskonzept von AP04 vorgeschlagenen Metadaten authorinstitution und practicesettingode werden aus Datenschutzgesichtspunkten von AP01.08 nicht zur Verwendung empfohlen. AP04: Um dem Patienten bei der Erstellung von Berechtigungs-Policies eine möglichst feingranulare Steuerung zu ermöglichen, sind auch aus Datenschutzgesichtspunkten von AP01.8 als kritisch eingestufte Metadaten (Fachbereich, Ersteller des Dokuments) unverschlüsselt zu belassen. Es ist gängige Umsetzung (Best Practice), dass die Zugriffskontrollentscheidung am Speicherort der Daten - dem Server - erfolgt und nicht im Client-System. Seite 182 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

197 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Die für die Berechtigung ergänzend wirksamen Filterkriterien legt der Patient bei der Aufnahme in der neuen Gesundheitseinrichtung oder vorab über das Patientenportal fest. Folgende Kriterien (und- Verknüpfung) kommen dabei zur Anwendung: Gesundheitsdienstleister: Es sollen nur von ausgewählten Einrichtungen eingestellte Dokumente sichtbar sein (IHE/XDS-Attribut: authorinstitution). Dokumententyp: Es sollen nur Dokumente ausgewählter technischer Typen freigegeben werden (IHE/XDS-Attribut: mimetype). Medizinisches Fachgebiet der Dokumente: Es sollen nur Dokumente ausgewählter medizinischer Fachbereiche sichtbar sein (IHE/XDS-Attribut: practicesettingcode). Zeitraum: Es wird ein Zeitpunkt in der Vergangenheit festgelegt, ab dem die Dokumente, die ab diesem Zeitpunkt erstellt wurden, zum Zugriff freigegeben werden. Das Ende des Zeitraums ergibt sich durch eine allgemein definierte Frist ab dem Zeitpunkt an dem die Berechtigung erstellt wird (Bezugsdatum im Dokument, IHE/XDS-Attribut: creationtime). Aufzählungsliste 71: Kriterien für die Berechtigung ergänzend wirksamen Filterkriterien Beispiel für eine Berechtigungsvergabe des Patienten: Opt-In Aktenanlage: o Der Patient muss aktiv der Anlage seiner Akte zustimmen. Opt-In Aktenzugriff: o Variante 1: Opt-In auf die Akte wird durch einen Behandlungsvertrag geregelt. Der Behandlungsvertrag legt fest, dass alle Ärzte/Institutionen, die im Rahmenvertrag aufgeführt sind, per default auf die Akte zugreifen dürfen. o Variante 2: Opt-In auf die Akte erfolgt explizit durch ein entsprechendes Verfahren (z. B. Ticketverfahren). Hier wird kein Rahmenvertrag zur Erstellung der Default-Policy verwendet, sondern der Zugriff durch die aktive Handlung des Patienten im Behandlungskontext festgelegt. o Ob Variante 1 und/oder Variante 2 bei einem Aktensystem zum Einsatz kommt, ist eine projektspezifische Vereinbarung. Wichtig ist, dass die in den Aktensystemen hinterlegten Policies untereinander kompatibel sind. Berechtigungskriterien (Opt-Out für Dokumente): o keine Einschränkungen (Default) Der Zugriff auf alle Aktendokumente des Patienten ist zulässig. o Zeitraum bis plus Fachrichtung ungleich Psychiatrie plus Krankenhaus gleich Krankenhaus Düren. o Auswirkungen: Es werden nur Dokumente im genannten Zeitraum aus dem Krankenhaus Düren, die nicht in der Psychiatrie erstellt wurden, maximal in das Praxensystem des Arztes heruntergeladen. Zweckmäßigerweise hat der Arzt die Möglichkeit, das Maximalvolumen der Dokumente weiter einzuschränken. Aufzählungsliste 72: Beispiel für Berechtigungsvergabe eines Patienten Seite 183 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

198 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Dieses in b) beispielhaft definierte Verfahren funktioniert nicht, wenn die für die Berechtigungsprüfung notwendigen Metadaten der Dokumente nicht in der XDS-Registry vorhanden sind. Das Vorhandensein der aufgeführten Metadaten als Klartext (Zeitraum, Fachrichtung, Gesundheitseinrichtung und Dokumententyp) wird bewusst in Kauf genommen. Wenn die Entschlüsselung von Metadaten in den Clients erfolgt, kann der Patient die dem Arzt zur Verfügung gestellten Dokumente nicht einschränken es werden immer alle Aktendokumente geladen. Das AP04 Konzept sieht aber die optionale Beschränkung nach Zeitraum, Fachrichtung, Gesundheitseinrichtung und Dokumententyp durch den Patienten vor. Die Alternative, Berechtigungen durch den Patienten nur für bestimmte Dokumente vergeben zu lassen (diskreter Zugriff), wird nicht empfohlen weil: Die Berechtigungseinschränkung auf einzelne Dokumente wird bei einer Vielzahl von Dokumenten unübersichtlich und demzufolge fehleranfällig. Die Berechtigungseinschränkung für jedes Dokument ist umständlich. Wenn die Berechtigungsadministration gemeinsam von Ärzten und Patienten durchgeführt wird, werden Ärzte unzumutbar mit medizinfremden Tätigkeiten belastet. Die Berechtigungseinschränkung ist zum Zeitpunkt der Dokumentenerstellung nicht bekannt oder unsicher. Änderungen sind nur aufwändig handhabbar. Aufzählungsliste 73: Gegenargumente für diskreten Zugriff Der Schutz des Patienten wird zudem durch Pseudonymisierung verbessert, wenn die von der XDS- Registry gespeicherten Metadaten keinen direkten Bezug zu den demografischen Patientendaten haben. Die Referenz auf diese demografischen Daten wird durch die globale Patienten-ID hergestellt, die nur durch einen unabhängigen Service (PIX-Manager) aufgelöst werden kann. Zur Auflösung der demografischen Daten ist ebenfalls eine Authentifizierung und gegebenenfalls eine Autorisierung am PIX-Manager erforderlich. Wird kein PIX-Manager verwendet (z. B. bei direkter Verwendung einer Versichertennummer) ist diese zusätzliche Schutzmaßnahme unwirksam. Seite 184 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

199 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Verschlüsselung von Dokumenten Bezüglich der Verschlüsselung von Dokumenten sind folgende Aspekte zu berücksichtigen: Es ist zu entscheiden, ob die Dokumente innerhalb des Repository verschlüsselt abgelegt werden sollen. Der Nachteil einer aus Datenschutzsicht wünschenswerten Verschlüsselung ist, dass generierte Zusammenfassungen von klinischen Fakten serverseitig nicht erzeugt werden können. Hierzu finden sich weitere Ausführunge in Kapitel 7. Logischer Bestandteil eines IHE Repository sind auch Dokumente, welche das Primärsystem nicht verlassen haben, sofern das Primärsystem als XDS-Repository fungiert. IHE speichert hier lediglich einen Link auf das Primärsystem. Von Primärsystemen werden Dokumente oft nicht verschlüsselt bereitgehalten. Unverschlüsselte Kopien der eepa Dokumente können sich auch in Primärsystemen befinden, soweit Dokumente aus der eepa heruntergeladen wurden. In Abhängigkeit von den durch den Patienten erteilten Zugriffsberechtigungen können sich ggf. Kopien der gesamten Akte unverschlüsselt in mehreren Primärsystemen befinden. Aufzählungsliste 74: Zu berücksichtigende Aspekte bei der Verschlüsselung von Dokumenten 13.2 AP02 Terminologie- und Ontologieserver Im Arbeitspaket AP02 wurde ein CTS2-konformer Terminologieserver konzipiert und implementiert. Ein Terminologieserver in der ebpg dient zur rechnergestützten Repräsentation medizinischer Codesysteme sowie dem Bereitstellen von Diensten zum Abrufen der Codesysteme oder Value-Sets. Diese, als Webservices realisierten Dienste, sind unterteilt in: Administration (Import, Export, Domainverwaltung), Authoring (Pflege von Vokabularen, Begriffen, Beziehungen und ValueSets), Concept Association (Anlegen und Pflegen von Beziehungen zwischen Begriffen) und Search (Abruf von Inhalten). Weiterhin gibt es einen Terminologie-Browser mit dem die Inhalte des Terminologieservers angezeigt und von autorisierten Akteuren erfasst und geändert werden können. Im eepa Umfeld kommen diverse Vokabulare und Value-Sets zum Einsatz: In medizinischen Dokumenten wie Arztbriefen oder Medikationsplänen werden Codesysteme zur Kodierung von Diagnosen, Maßnahmen, Symptomen, zur Beschreibung von Wirkstoffen und Darreichungsformen von Arzneimitteln usw. verwendet. Beispiele hierfür sind ICD, OPS und LOINC. Auch den Metadaten der Dokumente liegen oft Vokabulare zu Grunde, wie Listen von Fachbereichen medizinischer Einrichtungen, technische Typen von Dokumenten sowie fachliche Klassifikation von Dokumenten (Arztbrief, Transitionsbrief). Um die Interoperabilitätsanforderungen zu gewährleisten, müssen sich alle Partner der ebpg bzw. der einrichtungsübergreifenden elektronischen Patientenakte auf gemeinsame Codesysteme verständigen. Da eine Pflege der Vokabulare in allen Primärsystemen aufwändig und fehleranfällig ist, bietet sich der Einsatz des Terminologieservers als Infrastrukturkomponente der ebpg an. Neben der Seite 185 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

200 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa zentralen Dokumentation der Codesysteme im Terminologieserver ist auch ein maschineller Abruf der Vokabulare durch die Primärsysteme notwendig. Wünschenswert wäre darüber hinaus der Einsatz eines nationalen Terminologieservers, der alle branchenweit vereinbarten und auch international abgestimmten Codesysteme zur Verfügung stellt AP03 Data-Dictionary Server Ziel des Arbeitspaketes AP03 ist die Konzeption und Evaluierung einer Plattformkomponente (Data Dictionary Server), die klinische Konzepte und andere Datenstrukturen einrichtungsübergreifend verwaltet und zeit- und ortsunabhängig zur Verfügung stellt. Die Konzepte sollen maschineninterpretierbar und auswertbar sein. Während der Terminologieserver die semantische Interoperabilität unterstützt, dient der Data Dictionary Server (DDS) der Verbesserung der strukturellen Interoperabilität. Die Strukturinformationen für die Konzepte der auszutauschenden Informationen werden durch diesen DDS auch Meta Data Repository genannt beschrieben und verwaltet. Die Konzepte sollen sowohl menschlichen Nutzern als auch maschinellen Akteuren zur Laufzeit zugänglich sein. Ein Beispiel für ein klinisches Konzept ist das Konzept Blutdruck, welches ein berechnetes/aggregiertes Konzept aus den Konzepten systolischer Blutdruck und diastolischer Blutdruck ist. Diese genannten Konzepte haben jeweils eigene Attribute und bieten in Kombination eine Struktur. Diese Informationen sollen durch den DDS zur Verfügung gestellt werden, sowohl für auszutauschende Informationen innerhalb der Plattformartefakte als auch für auszutauschende Informationsobjekte zwischen externen Anwendungssystemen. Beispiel für den Einsatz des DDS zur Entwicklungszeit: Um ein neues Software-Modul zu erstellen, das eine strukturierte Information zu einem spezifischen Konzept als Output haben soll, bedient sich der Entwickler des DDS. So kann er ein bereits von den zuständigen Gremien seiner Branche abgestimmtes Konzept abrufen und diese Strukturinformationen als Grundlage für die Programmierung nutzen. Beispiel für den Einsatz des DDS zur Laufzeit: Ein medizinischer Leistungserbringer erhält auf elektronischem Wege Patienteninformationen. Die Daten wurden von einem anderen Leistungserbringer auf Basis von Strukturinformationen und Attributdefinitionen aus einem DDS erstellt und mit Referenz auf diese versandt. Mit der Referenz auf die Strukturinformationen in den erhaltenen Daten kann das Primärsystem des Empfängers deren Syntax und Semantik beim DDS anfragen und mit diesen Informationen die erhaltenen Daten interpretieren und automatisch in das Zielsystem übernehmen. Strukturinformationen zu Informationsobjekten sind, wie in fast allen Arbeitspaketen, auch im AP04 von Interesse. Die in der eepa vorhandenen Dokumente werden in den Primärsystemen der Leistungserbringer erzeugt und sind von anderen Primärsystemen zu interpretieren. Mit Dokumenten die dem CDA-Level 3 entsprechen ist syntaktische und semantische Interoperabilität realisierbar. Die Strukturinformationen für diese CDA-Dokumente könnten zentral in einem Data Dictionary Server Seite 186 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

201 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa hinterlegt werden, um den Software-Entwicklern der verschiedenen Hersteller von Primärsystemen als Basis für die Entwicklung zu dienen. In einer späteren Ausbaustufe könnten Primärsysteme die Informationen direkt zur Laufzeit nutzen AP07 Leistungsangebots- und Terminbuchungsplattform Im AP07 erfolgt die Konzeption einer Leistungsangebots- und Terminbuchungsplattform, die es Patienten und auch Ärzten erlaubt, nach Angeboten von Leistungserbringern aus dem ambulanten und stationären Sektor zu einer vorgegebenen Leistung zu suchen. Bei der Suche werden weitere Randbedingungen wie z. B. Entfernung von einem vorgegebenen Standort, Barrierefreiheit der Einrichtung, Sprachkenntnisse der Behandler usw. berücksichtigt. Anschließend können zu diesem Leistungsangebot Terminangebote angefordert und verbindlich online gebucht werden. Der Berührungspunkt zum AP04 ist ggf. die Möglichkeit im Rahmen der Terminbuchung dem Leistungserbringer den Zugang zur eepa des Patienten zu ermöglichen, damit er sich schon vor dem ersten persönlichen Erscheinen des Patienten über dessen Gesundheitszustand informieren kann, um ggf. schon vorbereitende Maßnahmen zu ergreifen. Dies könnte durch Übertragung von Zugriffsdaten für die eepa an den Leistungserbringer zusammen mit den Buchungsdaten erfolgen. Weiterhin könnte der Patient über ein gemeinsames Portal für alle Anwendungen der ebpg komfortabel aus der Terminbuchung in die Berechtigungsadministration für die eepa wechseln. Seite 187 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

202 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Seite 188 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

203 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A. Anhang A.1. PDF-Varianten A.1.1. PDF/A Der PDF/A-1-Standard für die Langzeitarchivierung elektronischer Dokumente wurde im Jahr 2005 von der International Organization for Standardization (ISO) als ISO :2005 veröffentlicht und basiert auf PDF 1.4. Im Jahr 2011 veröffentlichte die ISO den auf PDF 1.7 basierenden PDF/A-2- Standard als ISO :2011. Am 17. Oktober 2012 ist PDF/A-3 erscheinen, welches das Einbinden beliebiger Dateien erlaubt und sich sonst nicht weiter von PDF/A-2 unterscheidet. Das Ziel des PDF-A-Standards ist, dass sich Dokumente auch in der fernen Zukunft in ihrem ursprünglich definierten Erscheinungsbild mit jedem beliebigen PDF-Viewer darstellen lassen. Um das PDF/A-Dokument vor nachträglichen Veränderungen zu schützen bzw. spätere Manipulationen nachzuweisen, muss es digital signiert werden. Eine digitale Signatur ist laut der PDF/A-Spezifikation erlaubt, aber nicht zwingend vorgegeben. Durch die Integration von XMP 72 -konforme Metadaten (z. B. Dokumententitel, Verfasser, Thema, Stichwörter, Erstellungsdatum, Erstellungsprogramm, ), die das Dokument über die konkreten Inhalte hinaus beschreiben, lassen sich archivierte Dokumente effizient wieder auffinden und sortieren. A.1.2. PDF/A-Versionen im Vergleich A PDF/A-1 Ein PDF-Dokument gilt als PDF/A-1-konform, wenn keine Zugriffsrechte für dessen Anzeige festgelegt wurden und es nicht verschlüsselt ist. Es darf keine transparente Objekte und keine interaktiven Inhalte wie beispielsweise JavaScript, 3D- oder Multimedia-Inhalte enthalten. Die Einbettung von Fremdformaten (Office-Dokumente, XML, Filme) ist nicht erlaubt, und das Hinzufügen von Bildern ist auf bestimmte Bildformate wie JPG oder TIFF beschränkt. Die verwendeten Zeichensätze (TrueType, Type1, Type3) müssen eingebettet werden und die Farbräume müssen durch einen Output Intent (dt. Ausgabeabsicht) gekennzeichnet werden; er hält fest wie das Dokument dargestellt und gedruckt werden soll. Es müssen XMP-basierte Metadaten verwendet werden, um das Dokument als PDF/A-1 zu identifizieren. Alle weiteren im PDF 1.4 -Spezifikation definierten Dokumentenmerkmale, z. B. die elektronische Signatur oder Formularfelder (ohne JavaScript), dürfen in ein PDF/A-1-Dokument integriert werden. Weiterhin wird zwischen den Konformitätsstufen 1a (accessible) und 1b (basic) unterschieden. Während der Fokus von 1b-konformen Dokumenten auf der Visualisierung der Inhalte liegt, 72 XMP steht für Extensible Metadata Platform und ist ein XML-basierter Standard um Metadaten in digitale Medien (Dokumente, Fotos, usw.) einzubetten. Seite 189 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

204 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa müssen 1a-konformen Dokumenten zusätzliche Informationen zum semantischen Aufbau (Überschrift, Absätze, Spalten ) enthalten und jeder Buchstabe muss nach Unicode abgebildet werden können. Somit wird Copy&Paste aus PDF/A-Dateien und eine fehlerfreie Textsuche innerhalb des Dokumentes durch Indizierung gewährleistet. A PDF/A-2 PDF/A-2 erlaubt aufbauend auf PDF/A-1 die Einbettung von OpenType Fonts und die Verwendung von transparenten Objekten und des Grafikformats JPEG2000 zur Bildspeicherung. Ebenen (optional content) erlauben es, an der gleichen Stelle verschiedene Inhalte ein- und auszublenden. Die erlaubte Einbettung von weiteren PDF/A-1- oder PDF/A-2-konformen Dateien ermöglicht die Sammlung mehrere Dokumente in einer einzigen PDF-Datei. So können zusammenhängende Dokumente als digitale Mappe zusammengefasst werden und müssen nicht über den Umweg einer Dokumentenverwaltung zusammengeführt werden. PDF/A-2 hat die Konformitätsstufen a, b und u (unicode). Level u erfordert den Unicode-Zeichensatz und gleicht sonst dem Konformitätslevel b. A PDF/A-3 PDF/A-3 unterscheidet sich von PDF/A-2 insofern, dass nun beliebige mit einem MIME Type versehene Dateien eingebettet werden können. PDF/A-3-Dokumente können somit maschinenlesbare Informationen in Form von strukturierten XML-Dateien in sich aufnehmen, wodurch quasi ein Hybrid- Dokument entsteht, das dem Betrachter als Visualisierungsmedium dient und gleichzeitig die Vorteile der XML-basierten Datenhaltung im Rahmen der automatisierten Datenverarbeitung mit sich bringt. Während das PDF/A-3-Dokument weiterhin eine (langzeit-)archivierbare und eine sich zukünftig nicht ändernde Darstellung garantiert, gilt diese Garantie nicht für die eingebetteten Dateien, die lediglich dem Zweck der Weiterverarbeitung dienen. In der Praxis kann aus einem CDA-Dokument und einem XSLT-Stylesheet ein PDF/A-3-Dokument erstellt werden. Referenzen/Literatur: Webinar von Carsten Heiermann/Luratech: Webinar von Dr. Bernd Wild/Intarsys: (Folien sind ebenfalls als Download verfügbar) Seite 190 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

205 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.2. Dokumententaxonomie Lvl Bezeichnung 1 Administrative Informationen 2 Versichertendaten 2 Überweisung 3 ambulante Überweisung 3 stationäre Einweisung 2 Konsens 3 efa-einwilligung 3 BPPC-Dokument 3 Organspendeerklärung 2 Behandlungsvertrag 3 Selektiv-Vertrag 2 Transaktion 3 efa-in-a-box 2 Quittung 3 charge ticket or encounter form attachment 2 Rechnung 1 Feingranulare Daten 2 Anamnese 2 Diagnose 3 ICD-Diagnose 3 ICD-O-Diagnose 3 Tumor-Diagnose 2 Prozedur 2 Notfalldaten 2 Labordaten 2 Medikation 3 Dauermedikation 2 Impfung 2 Allergie 2 EKG-Kurve 2 Cave 1 aggregierte Informationen/Dokumente (Zusammenfassung) 2 Berichte, Befunde 3 Entlassbrief 4 Zusammenfassung bei Entlassung (Discharge summarization note) 4 Pflegerischer Entlassbrief 3 Zusammenfassung der Behandlungsepisode (Summarization of Episode Note) 3 Anamnese und Befund (History and physical note) 3 Verlaufsbericht (Progress note) 3 administrative note (generic) 3 Bericht über einen Patientenbesuch (Visit note) Seite 191 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

206 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Lvl Bezeichnung 4 Bericht über ambulanten Besuch (Ambulatory visit note) 4 visit note: emergency department 3 Einweisungsbrief 3 Verlegungsbrief 4 Verlegungsbrief Arzt (Transfer summary): physician 4 Verlegungsbrief Pflegedienst (Transfer summary): nurse 4 Zusammenfassung bei Verlegung (Transfer summarization note) 3 Protokoll 4 OP-Bericht 4 Konferenzprotokoll 4 Tumorboardprotokoll 3 Bericht des Sozialdienstes (Social service report) 3 Strahlentherapiebericht 3 Chemotherapiebericht 3 Pflegebericht 3 Konsilbericht (Consultation note) 4 Consultation note (general medicine) 4 Consultation note (hospital) 4 Consultation note (pulmonary) 4 Consultation note (physical therapy) 4 Consultation note (ophthalmology) 4 Consultation note (gastroenterology) 3 Operationsbericht (Operative note) 3 Therapiebericht (Procedure note) 3 Athroskopischer Bericht (Arthroscopy report) 3 Autopsiebericht (Autopsy report) 3 Notfallbericht (Emergency visit note) 3 EKG Befund (Echocardiogram Report) 3 Endoskopie-Befund 3 Herzkatheterbericht (Cardiac catheterization report) 3 Koloskopiebefund 3 Laborbefund 4 Mikrobiologiebefund 3 MRT-Befund 3 Nachsorgebefund 3 Pathologisch-anatomische Begutachtung 3 Obduktionsgutachten 3 (Neuropathologiebefund ) 3 (Pathologiebefund ) 4 Pathologischer Bericht (Surgical pathology report) 4 Cytology Cervical or vaginal smear or scraping study 4 Non-gynecological cytology method study 4 Autopsy report 4 Bone marrow Pathology biopsy report 3 Rektoskopiebefund 3 Radiologiebefund Seite 192 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

207 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Lvl Bezeichnung 4 Röntgenbefund (Radiology report) 4 Radiology Study 4 CT-Bericht (CT report CT) 3 Sonografiebefund 3 Wunddokumentation 3 Tumordokumentation 3 Epikrise 2 Evaluation and Management Note 3 evaluation and management note (diabetology) 3 evaluation and management note (inpatient) 3 evaluation and management note (generic) 3 evaluation and management note (oncology) 3 evaluation and management note (cardiology) 3 evaluation and management note (neurology) 3 evaluation and management note (Emergency Medicine) 3 evaluation and management note (nephrology) 3 evaluation and management note (Infectious Diseases) 3 evaluation and management note (dermatology) 2 Pass 3 Impfpass 3 Röntgen-Pass 3 Mutterpass 3 Kinderuntersuchungsheft 3 Zahnarztpass 3 Notfalldaten 2 Gutachten 3 Psychiatrisches Gutachten 2 Formular 3 Anamnesebogen 3 QS-Dokument 3 Anordnungsbogen 3 Verordnung 4 Rezept 4 Heilmittel 5 Stimm-Sprech-Therapie 5 Physikalische Therapie 5 Ergo-Therapie 5 Häusliche Krankenpflege 4 Hilfsmittel 4 Krankenbeförderung 2 Meldungen 3 Infektionsschutz 4 IfSG-Meldung des Arztes 4 IfSG-Meldung des Labors 4 Health Care associated infection report 3 Unerwünschte Arzneimittelwirkungen Seite 193 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

208 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Lvl Bezeichnung 3 Tumorregister (klinische und epidemiologische Turmorregister) 4 Diagnose-Meldung 4 Therapie-Meldung 4 Verlaufsmeldung 4 Abschlussmeldung 2 Planung 3 Therapieplan 3 Trainingsplan Tabelle 62: Dokumententaxonomie (aus dem HL7-Wiki) A.3. Betriebs- und Langzeitarchivierung Folgend werden Regeln und Empfehlungen im Kontext der Betriebs- und Langzeitarchivierung skizziert. Die Auflistung ermöglicht einen Überblick. Der Anspruch auf Vollständigkeit besteht nicht. Für die Vertiefung ausgewählter Themen sind zahlreiche Quellen angegeben. Da die eepa nur eine redundante Kopie bzw. Referenz auf Dokumente im Primärsystem implementiert, sind die gesetzlichen Aspekte der Archivierung nach Ansicht der Autoren für eine eepa nicht relevant. Gleichwohl wird die Archiv-Gestaltung maßgeblich durch die Verträge determiniert, welche der eepa zu Grunde liegen. A.3.1. Ordnungsmäßigkeit der Archivierung 73 Rechtliche Grundlage für die Ordnungsmäßigkeit: o Handelsgesetzbuch (HGB) o Abgabenordnung (AO) o Grundsätze ordnungsgemäßer Buchführung (GoB) Anforderungen aus HGB und GoB an die Aufzeichnungen: o Vollständig, korrekt, zeitgerecht und geordnet o Abgesichert gegenüber möglichen Änderungen o Nachvollziehbarkeit für sachverständige Dritte o Verfügbarkeit und Lesbarkeit o Übereinstimmung mit dem Original (inhaltlich und bildlich) Aufzählungsliste 75: Ordnungsmäßigkeit der Archivierung Laut dem Maßnahmenkatalog M Regelmäßige Aufbereitung von archivierten Datenbeständen des BSI muss für eine ordnungsgemäße Archivierung über den gesamten Zeitraum der Archivierung sicher gestellt werden, dass 73 Lehmann S. (2006): 3LGM 2 -basiertes Referenzmodell für die digitale Archivierung von Patientenunterlagen. Diplomarbeit angefertigt an der Universität Leipzig. Seite 194 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

209 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa das benutzte Datenformat dem Stand der Technik entspricht und von den verwendeten Anwendungen derzeit und zukünftig verarbeitet werden kann die gespeicherten Daten auch zukünftig lesbar sind und unter Beibehaltung der Semantik und der Nachweiskraft reproduziert werden können das benutzte Dateisystem auf dem Speichermedium von allen beteiligten Komponenten verarbeitet werden kann, die Speichermedien jederzeit physikalisch einwandfrei gelesen werden können die verwendeten kryptographischen Verfahren zur Verschlüsselung und zur digitalen Signatur dem Stand der Technik entsprechen für alle Komponenten der Speichereinheit (Speichermedien, Laufwerke, Jukeboxen sowie die Steuersoftware) Ersatz- und Wartungsmöglichkeiten bestehen Aufzählungsliste 76: Voraussetzungen einer ordnungsgemäßen Archivierung gem. BSI A.3.2. Revisionssicherheit Von einem revisionssicheren Archiv ist die Rede, wenn es den Anforderungen aus den Grundsätzen ordnungsgemäßer Buchführung (GoB) gerecht wird. Hierzu zählen der ordnungsmäßige Betrieb und die verfälschungssichere Archivierung der Dokumente. Dies erfordert folgende organisatorische und technische Maßnahmen: Protokollierung und Auswertung aller Zugriffe (Einsicht, Veränderung, ) der archivierten Dokumente Verhinderung von unzulässigen Zugriffen und Löschungen Sichere Transformation der Daten Einrichtung einer Benutzerverwaltung mit Zugangskontrollen und Zugriffsberechtigungen Sicherung von Daten und Programmen Aufzählungsliste 77: Anforderungen an ein revisionssicheres Archiv Zehn Merksätze des VOI (Verband Organisations- und Informationssysteme e.v.) zur revisionssicheren elektronischen Archivierung 74 : 1. Jedes Dokument muss nach Maßgabe der rechtlichen und organisationsinternen Anforderungen ordnungsgemäß aufbewahrt werden. 2. Die Archivierung hat vollständig zu erfolgen kein Dokument darf auf dem Weg ins Archiv oder im Archiv selbst verloren gehen. 3. Jedes Dokument ist zum organisatorisch frühestmöglichen Zeitpunkt zu archivieren. 4. Jedes Dokument muss mit seinem Original übereinstimmen und unveränderbar archiviert werden. 5. Jedes Dokument darf nur von entsprechend berechtigten Benutzern eingesehen werden. 74 Abrufbar auf Seite 195 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

210 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa 6. Jedes Dokument muss in angemessener Zeit wiedergefunden und reproduziert werden können. 7. Jedes Dokument darf frühestens nach Ablauf seiner Aufbewahrungsfrist vernichtet, d.h. aus dem Archiv gelöscht werden. 8. Jede ändernde Aktion im elektronischen Archivsystem muss für Berechtigte nachvollziehbar protokolliert werden. 9. Das gesamte organisatorische und technische Verfahren der Archivierung kann von einem sachverständigen Dritten jederzeit geprüft werden. 10. Bei allen Migrationen und Änderungen am Archivsystem muss die Einhaltung aller zuvor aufgeführten Grundsätze sichergestellt sein. Aufzählungsliste 78: 10 Merksätze zur revisionssicheren elektronischen Archivierung des VOI Seite 196 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

211 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.3.3. Braunschweiger Regeln zur Archivierung mit elektronischen Signaturen im Gesundheitswesen 75 Ein wichtiger Aspekt ist die ordnungsgemäße Archivierung von digital signierten Dokumente. Hierzu hat das CCSIG in Braunschweig den Leitfaden Empfehlungen für den Einsatz elektronischer Signaturen und Zeitstempel in Versorgungseinrichtungen des Gesundheitswesens herausgegeben. Als Quintessenz des Leitfadens werden auf der entsprechenen Internetseite folgende regeln angegeben: 1. Generelle Verwendung archivgeeigneter Dateiformate (z. B. PDF/A sowie akkreditierte Signatur bzw. akkreditierter Zeitstempel) Verfügbarkeit der Verifikationsdaten mindestens 30 Jahre sichergestellt 2. Akkreditierte Signatur originär elektronischer Dokumente, für die gesetzliche Regelungen, die Schriftform fordern. Ersetzung der Schriftform durch elektronische Form gemäß 126a Abs. 1 BGB Ausnahmefälle! 3. Akkreditierte Signatur für Dokumente zur externen Verwendung und für interne Dokumente, die einen besonders hohen Stellenwert (z. B. Beweisinteresse) haben 4. Akkreditierter ( Eingangs- ) Zeitstempel für Dokumente externer Einsender Kann auch durch Regel Nr. 6 umgesetzt werden 5. Geeignetes Authentifizierungsverfahren für alle sonstigen Dokumente 6. Archivierung muss zeitnah (innerhalb 24h) und in einem revisionssicheren Archiv mit akkreditiertem ( Archiv- ) Zeitstempel erfolgen 7. Absicherung des Betriebes des elektronischen Archivs Stand der Technik, Umsetzung von Regelungen und Normen 8. Hash- und Signaturerneuerungen gemäß den Vorgaben der Bundesnetzagentur; Datei- und Medienkonvertierungen gemäß den Empfehlungen der BMWi-Studie TransiDoc 9. Vermeidung von Medienbrüchen Bei ersetzendem Scannen: Originaldokumente (Urkunden) aufbewahren, abgesichertes Scanverfahren mit akkreditierter Signatur / akkreditierten Zeitstempel, Sicherung des Fortbestands des Versicherungsschutzes 10. Dokumentation und Handlungsanweisungen in Archivordnung festlegen Aufzählungsliste 79: Braunschweiger regeln zur Archivierung elektronisch signierter Dokumente 75 Seite 197 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

212 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.3.4. Notwendigkeit von digitalen Archivsystemen Möglichkeit der Zusammenführung von Dokumenten und Daten aus mehreren Subsystemen zur zentralen, langfristigen und revisionssicheren Aufbewahrung Einheitliche Ablage von Dokumenten in archivwürdigen Standardformaten fördert den einrichtungsübergreifenden Informationsaustausch Entlastung der Primärsysteme durch Archivierung der älteren Dokumente und Daten, führt bspw. zu besserem Antwortzeitverhalten eines Klinischen Arbeitsplatzsystems Archivierte Dokumente und Daten auch nach vielen Jahren wieder nutzbar Archivierungssysteme sind im Vergleich zu den Primärsystemen komplex. Erstere haben eine relativ einfache und einheitliche Ablagestruktur, während letztere zur Datenspeicherung meist auf eine Datenbankstruktur setzen Datenmigrationen aufgrund der einfachen Ablagestruktur einfacher Zeitaufwändige Datensicherungen von "Altdaten" der klinischen Anwendungssysteme entfallen Digitales Archivierungssystem kann gleichzeitig als Sekundärspeicher dienen und wird Bestandteil des Ausfallkonzeptes Die Beweiskraft elektronisch erzeugter und signierter Dokumente kann einfacher in einer zentralen Archivlösung sichergestellt werden. Dies geschieht durch eine weitgehend unveränderbare Speicherung und durch eine automatisierte Neusignierung im Falle eines Sicherheitseignungsverlustes von kryptografischen Algorithmen Aufzählungsliste 80: Notwendigkeit von digitalen Archivsystemen Seite 198 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

213 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.3.5. Quellen gmds-praxisleitfaden, Schmücker P.; Dujat C.; Seidel C. (Hrsg., 2012): gmds-praxisleitfaden. Dokumentenmanagement, digitale Archivierung und elektronische Signaturen im Gesundheitswesen; Dietzenbach: Antares Computer Verlag Lehmann S. (2006): 3LGM 2 -basiertes Referenzmodell für die digitale Archivierung von Patientenunterlagen. Diplomarbeit angefertigt an der Universität Leipzig. Schmücker P.; Dujat C.; Seidel C. (Hrsg., 2012): gmds-praxisleitfaden. Dokumentenmanagement, digitale Archivierung und elektronische Signaturen im Gesundheitswesen; Dietzenbach: Antares Computer Verlag Seidel, C.; Kosock, H.; Brandner, A.; Balfanz, J.; Schmücker, P.: Empfehlungen für den Einsatz elektronischer Signaturen und Zeitstempel in Versorgungseinrichtungen des Gesundheitswesens. Shaker Verlag GmbH, Aachen, Vortrag von Kosock H.; Duwenkamp C. ( ): Nutzung von unterschiedlichen Signaturniveaus in Informationssystemen des Gesundheitswesen: A.4. CDA-XDS-Mapping Die folgende Tabelle zeigt eine vereinfachte Version der CDA-XDS-Mapping-Daten. Die vollständige Tabelle ist auf der Projektwebseite unter dem Namen ebpg_ap04_xds_interop_cda_mappingtabelle_v1-6.xlsx zu finden. Seite 199 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

214 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa CDA - XDS Metadaten-Mapping Quellen: ELGA, IHE/XDS, bvitg Arztbrief Metadaten Element Quelle (meist CDA-Dokument) Ziel (IHE/XDS Registry) Opt. Beschreibung Quelle Element Opt. IHE/XDS XDS CDA ClinicalDocument/author/assignedAuthor R authorperson R2 Person, welche das Dokument inhaltlich verfasst hat (Daten) CDA ClinicalDocument/legalAuthenticator/assignedEntity/representedOrganization - ELGA ClinicalDocument/author - IHE PPC O R authorinstitution R2 Organisation (als OID), der die Person angehört, die das Dokument verfasst hat. - Im Falle von Entlassungsinformationen das dokumenterzeugende Krankenhaus / Rehabzentrum - Im Falle von Befundbericht Radiologie die dokumenterzeugende Röntgenordination/-institut - Im Falle von Befundbericht Labor das dokumenterstellende Labor CDA ClinicalDocument/author/functionCode - ELGA ClinicalDocument/author/participationFunction - IHE PPC O R Die Verwaltung der Institutionen kann über eine IHE Healthcare Provier Directory (HPD) erfolgen. authorrole R2 Rolle der Person. Die Verwaltung der Institutionen kann über eine IHE Healthcare Provier Directory (HPD) erfolgen. Das Element enthält im Attribut "@code" den vom HPD vorgegebenen kodierten Wert der Rolle und in Attribut "@displayname" den Anzeigenamen des kodierter Wert der Anzeigename der Rolle. Beispiel: Diensthabender Oberarzt", CDA ClinicalDocument/author/assignedAuthor/code O authorspeciality R2 Fachbereichscode der Person CDA ClinicalDocument/effectiveTime R creationtime R Technischer Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Format: YYYYMMDDhhmmss[+/-]HHMM (Zeitzone) CDA ClinicalDocument/code R classcode R Dokumentenklasse (Oberklasse - grobe Granularität) als LOINC Code. Z.B Discharge summarization note CDA ClinicalDocument/confidentialityCode R confidentialitycode R Veraulichkeitscode des Dokuments. Die Konzeption des Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich über Policies zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt. Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen: Zulässige Werte eingeschränkt auf: "ebpg_confidentiality". CDA ClinicalDocument/languageCode O languagecode R Sprachcode des Dokuments (z.b. "de-de"). CDA ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value O servicestarttime R2 Beginn-Zeitpunkt der Leistung (z.b. Aufnahmedatum) CDA ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value O servicestoptime R2 Ende-Zeitpunkt der Leistung (z.b. Entlassdatum) CDA ClinicalDocument/recordTarget/patientRole/id R sourcepatientid R Patienten-ID im lokalen Informationssystem des Erstellers, zusammengesetzt aus root + extension CDA ClinicalDocument/recordTarget/patientRole R sourcepatientinfo R Demograpische Daten des Patienten als zusammengesetztes Element CDA ClinicalDocument/title O title O Titel des Dokuments CDA ClinicalDocument/code R typecode R Dokumentenklasse (Unterklasse - feine Granularität) als LOINC Code. Z.B Discharge summarization note (physician) CDA ClinicalDocument/id R uniqueid R Global eindeutige ID des Dokuments. Dieser Identifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des Erstellers übernommen. CDA ClinicalDocument/documentationOf/serviceEvent O eventcodelist O Liste von Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt CDA ClinicalDocument/legalAuthenticator/assignedEntity O legalauthenticator O Rechtlicher Unterzeichner des Dokuments, analog zu AuthorPerson in Notation HL7 v2 XCNFormat zu befüllen Seite 200 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

215 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa CDA ClinicalDocument/relatedDocument - ELGA ClinicalDocument/relatedDocument/parentDocument/id - IHE PCC O parentdocumentid R2 ID eines referenzierten Parent-Dokuments (wie in DocumentRelationship beschrieben ist) CDA ClinicalDocument/relatedDocument@typeCode (ClinicalDocument/relatedDocument/parentDocument - ELGA) O parentdocumentrelationship R2 Typ der Relation zu dem referenzierten Parent-Dokuments (Ergänzung, Versionierung, Transformation, z.b. Übersetzung)? Affinitydomainspezifischer Wert (z.b. Familie, Labor, Radiologie) x practicesettingcode R Fachliche Zuordnung des Dokuments. Es soll den Fachbereich wiedergeben, dem der Inhalt des Dokuments am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung. Hierfür könnte eine Deutschlandweite Richtline der Fachabteilung gemäß Anhang 1 der BPflV (SGB V 301, Schlüssel 6) zum Einsatz kommen. PS XDS Patienten-ID muss vom Primärsystem verwaltet und mitgegeben werden x patientid R Globale Patienten-ID in der XDS Affinity Domain. Diese ID wird über die Transaktion mitgeliefert. A Wert beim Einstellen immer 'Approved' x availabilitystatus R Gültigkeit des Dokuments (Approved, Deprecated) K Affinitydomainspezifischer Wert (z.b. CDAR2.IHE 1.0) x formatcode R Das formatcode Element beschreibt das (semantische) Format des Dokuments. Er ermöglicht einem, das Dokument zur Weiterverarbeitung empfangenden System (Document Consumer Actor) die Identifizierung des zu erwartenden Dokumentenformats und somit die korrekte Darstellung des Dokuments. Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.? ClinicalDocument/code x healthcarefacilitytypecode R Typ der Gesundheitsorganisation.Der healthcarefacilitytypecode enthält die OID der Institution (gleich authorinstitution) sowie eine textuelle Bezeichnung der Institution, die auf folgende Werte eingeschränkt ist: z.b. Universitätsklinikum xyz: K Im Fall von CDAR2 ist es immer "text/xml" x mimetype R MimeType des Dokuments CDA ClinicalDocument/effectiveTime R submissiontime R CDA ClinicalDocument/author/assignedAuthor R authorperson O Person des Submissionsets CDA ClinicalDocument/legalAuthenticator/assignedEntity/representedOrganization O authorinstitution R2 Organisation, der die Person angehört CDA ClinicalDocument/author/functionCode O authorrole R2 Rolle der Person CDA ClinicalDocument/author/assignedAuthor/code O authorspeciality R2 Funktionscode der Person CDA ClinicalDocument/author/assignedAuthor R authortelecommunication O Kommunikation-Details A Wert beim Einstellen immer 'Approved' x availabilitystatus R Status (Submitted, Approved) K kein Wert x comments O Anmerkungen zum Submission Set CDA ClinicalDocument/code (falls 1 Dokument im Submission Set) R contenttypecode R Typ des Inhalts eines Submission Sets. Der typecode wird automatisch dem classcode des DocumentEntry gleichgesetzt, sofern in einem SubmissionSet ein einzelnes Dokument enthalten ist. K kein Wert x intendedrecipient O Kann dazu verwendet werden einen bereits bekannten Empfänger einzutragen. Dies ist vorallem im Fall von Benachrichtigungen (IHE NAV Profil) oder der direkten Dokumentenübermittlung über XDR relevant.? XDS Patienten-ID x patientid R Siehe XDSDocumentEntry -> patientid K OID der Documentsource x sourceid R OID von Documentsource K kein Wert x title O Titel für Submission Set A Wird von Documentsource erstellt x uniqueid R Eindeutige ID für Submission Set A Wird von Repository automatisch befüllt x hash R Hash Wert des Dokuments A Wird von Registry/Repository automatisch befüllt x homecommunityid R Eindeutige ID der Community A Wird von Repository automatisch befüllt x repositoryuniqueid R Eindeutige ID des Repositories A Wird von Repository automatisch befüllt x size R Größe des Dokuments in Bytes. Legende Spalte Quelle Legende Spalte Optionalität CDA Legende Spalte Optionalität XDS CDA CDA-Dokument R Verpflichtend ( Required ) Code Bedeutung A automatisch O Optional R Verpflichtend ( Required ) K konstant x keine CDA-Entsprechung R2 Verpflichtend wenn bekannt ( Required if Known )? unbekannt O Optional Tabelle 63: Mapping CDA-XDS Seite 201 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

216 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.5. Feldbeschreibung für elektronischen Überweisungsschein A.5.1. Muster 2b Abbildung 27: Überweisungsschein Muster 2b Seite 202 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

217 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.5.2. Muster 6 Abbildung 28: Überweisungsschein Muster 6 A.5.3. Muster 10 Abbildung 29: Überweisungsschein Muster 10 Seite 203 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

218 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.5.4. Detaillierte Feldbeschreibungen Die detailierten Feldbeschreibung für die Formularbedruckung für Überweisungen sind im Technischen Handbuch der KBV dokumentiert, es sind die folgenden felder enthalten 76 : Muster 2b Muster 6 Muster 10 Feldbezeichnung Typ Bemerkung Formularcode NUM Formularcodeergänzung STR Familienname STR Vorname STR Geburtsdatum DAT Bis-Datum der Gültigkeit DAT IK NUM Versichertennummer oder Versichertennummer egk oder SKT-Zusatz STR Versichertenstatus NUM Statusergänzung/DMP-Kennzeichnung STR Vertragsarzt-(N)BSNR des Erstveranlassers NUM Erstveranlasser LANR NUM Vertragsarzt-(N)BSNR des Überweisers NUM Überweiser LANR NUM Ausstellungsdatum DAT Geschlecht STR m; f Titel STR Namenszusatz STR Ländercode STR Straße mit Hausnummer STR Ort STR Kassenname STR PLZ STR WOP-Kennzeichen (KV-Bereich) NUM Kurativ/Präventiv/ESS/ bei belegärztl. Behandlung/ STR 26 Behandlung gemäß 116b SGBV BOOL Unfall /Unfallfolgen BOOL 15 Belegarztbehandlung BOOL 16 Notfall BOOL 17 Unfall BOOL kurativ; präventiv; Empfängnisregelung, Sterilisation, Schwangerschaftsabbruch; belegärztl. Behandlung 18 BVG BOOL 19 Diagnoseart STR ICD10; Klartext 28 OP-Datum DAT 29 Überweisung an STR 76 Siehe Seite 204 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

219 Muster 2b Muster 6 Muster Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Feldbezeichnung Typ Bemerkung 30 AU bis DAT 31 Untersuchungsart STR 32 Eingeschränkter Leistungsanspruch gemäß 16 Abs. 3a SGB V BOOL 29 Kontrolluntersuchung einer bekannten Infektion BOOL 30 Ausnahmeindikation NUM 31 Abnahmedatum DAT 32 Abnahmezeit TIM 33 Behandlung gemäß 116b SGBV BOOL 34 Eingeschränkter Leistungsanspruch gemäß 16 Abs. 3a SGB V BOOL 35 Befundübermittlung eilt (Dringlichkeitsstatus) BOOL 36 Telefon-Nr. STR 37 Fax-Nr. STR Diagnose/Verdachtsdiagnose STR Befund/Medikation STR Auftrag STR x Untersuchungsergebnisse STR x Bisherige Maßnahmen (z. B. Medikation) STR x Fragestellung/Hinweise (z. B. Allergie) STR x Mitgegebene Befunde STR Tabelle 64: Feldbeschreibungen zur Bedruckung von Überweisungen Auftragsleistung; Konsiliaruntersuchung; Mit-/Weiterbehandlung Seite 205 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

220 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.6. Patienteneinwilligung am Beispiel der EFA Zur Abgrenzung der eepa zur EFA wird im Folgenden das Muster einer Patienteneinwilligung der EFA dargestellt. Die eepa Einwilligung kann in Kapitel eingesehen werden. Im Rahmen der EFA 1.2 Spezifikation wurde ein Beispiel für eine Patienteneinwilligung erstellt. Diese wird im Folgenden dargestellt. Patienteneinwilligung in die Führung einer Elektronischen Fallakte Für <Name des Patienten>, <Anschrift>, <Geburtsdatum>[, <Fallnummer>] die Behandlung [im Bereich <Fachbereich>][mit der Diagnose <ICD10, evtl. in Verkürzung> ]. Ich bin damit einverstanden, dass zu dem oben beschriebenen Krankheitsbild (Behandlungsfall) eine Elektronische Fallakte angelegt wird. Sie ermöglicht den mich behandelnden Ärzten und unter ärztlicher Aufsicht deren berufsmäßigen Gehilfen (z. B. Krankenpflegepersonal, medizinisches Funktionspersonal) auf die folgenden Daten zuzugreifen und diese zu Behandlungszwecken zu verarbeiten: Behandlungsdaten (z. B. Laborwerte, Röntgenbilder) Befunde und Therapieberichte (insbesondere OP-Berichte) Arztbriefe Administrative Informationen (z. B. Name, Geburtsdatum, Adressen) Ich bin damit einverstanden, dass die nachfolgend benannten Ärzte und deren berufsmäßige Gehilfen diese Elektronische Fallakte nutzen, wenn und soweit dies im Rahmen meiner Behandlung erforderlich ist. 1. <Name Arzt>, <Anschrift Arzt> 2. Ärzte de[rs] <Name Institution>, [<Abteilung>, ], <Anschrift Institution> Die Elektronische Fallakte wird nach Abschluss der Behandlung [aber spätestens zum <Datum des Ablaufs>] gesperrt. Ich wurde darüber aufgeklärt, dass die Elektronische Fallakte eine technische Lösung ist, um mehreren behandelnden Ärzten bzw. Institutionen Zugriff auf die relevanten Informationen zu ermöglichen, und mir wurde erläutert, wie sie genutzt wird. Ein entsprechendes Informationsblatt habe ich erhalten und gelesen; den Inhalt dieses Informationsblattes betrachte ich als Bestandteil dieser Einwilligung. Die Zustimmung zur elektronischen Datenübermittlung ist jederzeit widerruflich, ohne dass für mich Nachteile entstehen, auch bezogen auf einzelne der genannten Institutionen oder Ärzte. Ich bin darüber informiert, dass ich jederzeit Auskunft über die zu meiner Person gespeicherten Daten verlangen kann. Ansprechpartner für die Elektronische Fallakte und alle Fragen des Datenschutzes, der Berechtigungen und der Einsichtnahme ist: <Name der Stelle>, <Anschrift> Ort / Datum / Unterschrift Seite 206 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

221 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa In einigen EFA-Umsetzungsprojekten wird die Einwilligung für die Nutzung einer EFA im Rahmen des Behandlungsvertrages festgelegt. In diesem wird festgehalten, dass alle im Behandlungsvertrag definierten sowie an der Behandlung beteiligten Leistungserbringer Zugriff auf die EFA erhalten sollen. Der Patient unterschreibt in diesem Fall lediglich zu Beginn der Behandlung den Behandlungsvertrag, inkl. Zustimmung zum Datenaustausch über die EFA. Dies setzt voraus, dass der Patient davor über die EFA informiert wird. In der EFA 2.0 Spezifikation wird ein strukturiertes Eiwilligungsmanagement auf Basis von IHE Privacy Consent Directive umgesetzt. Die Fertigstellung ist für Anfang 2014 geplant. Seite 207 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

222 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa A.7. Veröffentlichung in der EHEALTHCOM NATIONAL (UN)VERNETZT - Handlungsempfehlungen zur Etablierung einrichtungsübergreifender Elektronischer Patientenakten in Deutschland Seite 208 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

223 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Seite 209 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

224 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Seite 210 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

225 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Seite 211 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014

226 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Seite 212 Projekt ebusiness Plattform im Gesundheitswesen. Gefördert von der Europäischen Union und dem Land Nordrhein-Westfalen.

227 13 Ergebnisse anderer Arbeitspakete und ihr Bezug zur eepa Seite 213 Ergebnispapier des Arbeitspaketes Einrichtungsübergreifende Elektronische Patientenakte (eepa) Version 1.0 zur conhit 2014