IHE-D Cookbook Aktenbasierten einrichtungsübergreifende Bild- und Befund-Kommunikation

Transkript

1 IHE-D Cookbook Aktenbasierten einrichtungsübergreifende Bild- und Befund-Kommunikation Ziele Methodik und aktueller Stand Dr. Ralf Brandner, ICW AG Oliver Heinze, Universitätsklinikum Heidelberg Agenda 1. Einleitung Motivation Zielsetzung Methodik 2. Aktueller Stand Rechtliche und technische Rahmenbedingungen Anwendungsfälle Lösungsarchitektur mit Beispiel PEPA 3. Ausblick 1

2 Einleitung MOTIVATION, ZIELSETZUNG UND VORGEHEN Motivation Fehlende nationale Strategien für ehealth und Interoperabilität Unterschiedliche Aktenmodelle zur einrichtungsübergreifenden Befund- und Bildkommunikation in Deutschland Proprietäre Aktenspezifikationen machen Entwicklung, Rollout und Integration kostenintensiv Geringe Berücksichtigung von IHE Profilen in deutschen IT- Ausschreibungen 2

3 Zielsetzung Erstellung einer Richtlinie für Anwender, Softwarehersteller und Berater zum Aufbau einrichtungsübergreifender elektronischen Akten auf IHE Basis Zusammenfassung deutscher Rahmenbedingungen und Besonderheiten Verwendung vorhandener IHE Profile und internationaler Standards Berücksichtigung verschiedener Aktenmodelle Erarbeitung grundlegender, gemeinsamer Konzepte Spezifikation nationaler Erweiterungen und Profile Vorgehen Beschluss der Mitgliederversammlung (26. Oktober 2011) Autoren, Redaktion Anwender + Forschungseinrichtungen Industrie Initiale öffentliche Workshops Abstimmung von Dokumentbestandteilen in Arbeitsgruppen Rahmenbedingungen (rechtlich, technisch) Anwendungsfälle Architektur + Datenflüsse Arbeitsgruppe efa-verein und bvitg Öffentliche Kommentierung des Dokuments 23. April bis 5. Juni April bis 31.Mai

4 Rahmenbedingungen RECHTLICHE UND TECHNISCHE GRUNDLAGEN Datenschutzrechtliche Rahmenbedingungen Patienteneinwilligung notwendig Freie Entscheidung des Patienten, Hinweis auf Folgen der Verweigerung Besondere Hervorhebung bei mehreren Einwilligungen Keine Beschränkung der Rechte auf Auskunft, Berichtigung, Sperrung, Löschung Schriftform bzw. wegen besonderer Umstände andere Form Inhalte: Zweck der Erhebung, Verarbeitung oder Nutzung Daten selbst (bzw. Kategorie) benennen Empfänger (bzw. Kategorie) benennen Technische und organisatorische Maßnahmen notwendig Zugangskontrolle Zugriffskontrolle Weitergabekontrolle Eingabekontrolle Auftragskontrolle 4

5 Übersicht verwendeter Profile und Standards IHE OASIS Dokumenten und Bilddaten Management Patientendaten Management XDS.b XDS-I.b XDR PIX PDQ XCA XCA-I XCPD HPD XUA BPPC ATNA CT XACML SAML Sicherheit Cross-Enterprise Document Sharing (XDS.b) Einrichtungsübergreifender Austausch von Dokumenten Zentrale oder dezentrale Speicherung der Dokumente Strukturierung über SubmissionSets und Folder Ergänzung durch XDS Meta Data Update Basis: ebxml 5

6 Cross-Enterprise Document Sharing for Imaging (XDS-I.b) Einrichtungsübergreifender Austausch von Bilddaten Ergänzungen zu XDS.b Basis: ebxml, DICOM Patient Identifier Cross-referencing (PIX) Verlinkung von Patienten-IDs aus verschiedenen Systemen / Einrichtungen Abfrage auf Basis von Patienten-IDs Basis: HL7 Version 2 oder HL7 Version 3 6

7 Patient Demographics Query (PDQ) Abfrage von demografischen Patientendaten Abfrage auf Basis von demografischen Patientendaten Basis: HL7 Version 2 oder HL7 Version 3 Cross Enterprise User Assertion (XUA) Bestätigung der Identität eines authentifizierten Benutzers zur systemübergreifenden Autentifizierung und Autorisierung Basis: SAML 2.0 Identity Assertions 7

8 IHE Basic Patient Privacy Consents (BPPC) Patientenzustimmung auf Basis vordefinierter Policies Privacy Policy Acknowledgement Document mit ID der gewählten Policy und textueller Beschreibung Policies werden von der Document Source bzw. dem Document Consumer durchgesetzt Policies selbst können in einer XDS.b Infrastruktur gespeichert werden Basis: CDA Audit Trail and Node Authentication (ATNA) Syntax und Semantik von Auditnachrichten Zentrale Speicherung von Auditnachrichten aus den Systeme Zertifikatsbasierte Authentifizierung der Systeme 8

9 Consistent Time (CT) Synchronisierung der Zeit zwischen den kommunizierenden Systemen und Computern Basis: Network Time Protocol (NTP) extensible Access Control Markup Language (XACML) XML-basierte Markup Language zur Definition von Access Policy Erlaubt komplexe Berechnungen zur Entscheidung von Zugriffsregelungen 9

10 Anwendungsfälle MAMMA-DIAGNOSTIK, KOLOREKTALES KARZINOM, AKUTVERSORGUNG SCHWERVERLETZTER Datenfluss Mamma-Diagnostik 10

11 Datenfluss Kolorektales Karzinom Datenfluss Akutversorgung Schwerverletzter 11

12 Lösungsarchitektur AKTENMODELLE, LÖSUNGSMODULE Betrachtete Aktenmodelle Kriterium EEPA PEPA EFA Hoheit Professional Patient/Bürger oder Proxy Rahmen Longitudinal, fallübergreifend Longitudinal, fallübergreifend Patientenportal Nein Ja Nein Professional- Portal Architektur: Document Consumer Document Source Optional Ja Nein Primärsysteme oder Prof.-Portal Primärsysteme Prof.-Portal Patienten-Portal Primärsysteme Patienten-Portal Prof.-Portal Professional Zweckbindung, fallbezogen Primärsysteme Primärsysteme 12

13 Standardisierte Lösungsmodule 1. Patientenidentifikation 2. Benutzeridentifikation und -authentifizierung 3. Verwalten von Berechtigungen 4. Prüfung von Berechtigungen 5. Nutzung von Ordnern 6. Akteninhalte Beispiel PEPA im Projekt INFOPAT 13

14 Lösungsarchitektur PEPA Kriterium Patientenidentifikation Benutzerauthentifikation und -authentifizierung Verwaltung von Berechtigungen Prüfung von Berechtigungen Nutzung von Ordnern (Folder) Akteninhalte PEPA Master Patient Index (PIX/PDQ) HPD (zentral) XUA, XUA++ PAP (zentral), mehrere Quellen für Policy-Sets Consent Creator (Patienten-Portal, Prof.- Portal) Feingranulare Regelungen (XACML) PDP (zentral) PEP (zentral, dezentrale) Dokumentenklassen Administrative Fälle / Besuche Registry (zentral) Repository (zentral, dezentral) Briefe, Befunde, Berichte (PDF, CDA) Medikationen (XML) Bilder (DICOM-Objekte) Architektur PEPA ohne Security, Akte bereits angelegt AFFINTY DOMAIN Primary Primary Systems Systems like like Hospital Hospital Information Information Systems Systems Clinical Information Clinical Systems Information Practice Systems Management Systems Practice Etc. Management Systems Etc. Patient Identity Source PIX Consumer EHR Core MPI, Record Module ITI-8 Patient Identity Feed PIX Manager ITI-9 PIX Query Document Registry ITI-8 Patient Identity Feed ITI-18 Registry Stored Query PDQ/PIX Consumer (Imaging) Document Consumer Portals (Imaging) Document Source ITI-41 Provide and Register Document Set-b Document Repository ITI-42 Register Document Set-b ITI-43 Retrieve Document Set Context Based Integration 14

15 Standardisierte Lösungsmodule 1. Patientenidentifikation Regional eindeutige Patientenidentifikation Eindeutige Patientenidentifikation über Einrichtungs- und Systemgrenzen hinweg XDS Affinity Domain Patient Identification Domain (XAD-PID) Lösungsvarianten 1. Master Patient Index 2. Patientenregister 3. Verteilte Erstellung ohne Abfragemöglichkeit 2. Benutzeridentifikation und -authentifizierung 3. Verwalten von Berechtigungen 4. Prüfung von Berechtigungen 5. Nutzung von Ordnern 6. Akteninhalte Patientenidentifikation: Master Patient Index 1. Erstellung der XAD-PID 2. Verknüpfung der lokalen Patientenidentifikatoren mit der XAD-PID zentral 3. Zentrale Speicherung der Verknüpfungen und Abfrage über PIX 15

16 Patientenidentifikation: Patientenregister 1. Erstellung der XAD-PID 2. Verknüpfung der lokalen Patientenidentifikatoren mit der XAD-PID dezentral 3. Abfrage der XAD-PID über PDQ Patientenidentifikation: Verteilte Erstellung ohne Abfragemöglichkeit 1. Erstellung der XAD-PID 2. Verknüpfung der lokalen Patientenidentifikatoren mit der XAD-PID dezentral 3. Keine Abfragemöglichkeit 4. Transport der XAD-PID über Token (z.b. Papier) 16

17 Zusammenfassung Patientenidentifikation Standardisierte Lösungsmodule 1. Patientenidentifikation 2. Benutzeridentifikation und -authentifizierung Identifikation für die Nachvollziehbarkeit der Zugriffe Authentifizierung gegenüber einem vertrauenswürdigen System Föderiertes und zentrales Identitätsmanagement sind möglich Lösungsvarianten 1. Verwendung lokaler Benutzeridentitäten 2. Lokale Eingabe zentraler Benutzeridentitäten 3. Dynamisches Mapping der Benutzeridentitäten 4. Statisches Mapping der Benutzeridentitäten 3. Verwalten von Berechtigungen 4. Prüfung von Berechtigungen 5. Nutzung von Ordnern 6. Akteninhalte 17

18 Benutzeridentifikation: lokale Benutzeridentitäten Benutzeridentifikation: lokale Benutzeridentitäten 18

19 Benutzeridentifikation: Lokale Eingabe zentraler Benutzeridentitäten Benutzeridentifikation: Dynamisches Mapping der Benutzeridentitäten 19

20 Benutzeridentifikation: Dynamisches Mapping der Benutzeridentitäten Benutzeridentifikation: Statisches Mapping der Benutzeridentitäten 20

21 Benutzeridentifikation 1. Cross-Enterprise User Assertion Attribut Extension Inhalte Name des Benutzers (Subject ID) Organisation ID (Subject Organization ID) Organisationsname (Organization) Home Community ID (homecommunity ID) Verwendungszweck (Purpose of Use) Rolle (Subject Role) Patienten ID (Patient Identifier Attribute) Übertragung als SAML Assertion Jedes Attribut kann nur einen Wert annehmen Standardisierte Lösungsmodule 1. Patientenidentifikation 2. Benutzeridentifikation und -authentifizierung 3. Verwalten von Berechtigungen Erfolgt durch Patienteneinwilligungsdokumente Speicherung als Dokument im XDS Document Repository Abruf als lesbares Dokument Austausch über XDS Transaktionen Umsetzung der Patienteneinwilligung in eine XACML Policy und Speicherung im XACML Policy Repository Schnelle Zugriffe durch das Sicherheitssystem Austausch über SAML/XACML Transaktionen 4. Prüfung von Berechtigungen 5. Einstellen von Dokumenten 6. Abrufen von Dokumenten 21

22 Methodik zur Spezifikation von Patienteneinwilligungen Quelle: Fraunhofer Fokus 2012 Standardisierte Lösungsmodule 1. Patientenidentifikation 2. Benutzeridentifikation und -authentifizierung 3. Verwalten von Berechtigungen 4. Prüfung von Berechtigungen Akteure zur Prüfung von Berechtigungen auf Basis von XACML Berechtigungsprüfung pro Transaktion Sinnvolle Gruppierung von Akteuren Beispiele: Suche nach Dokumente (ITI-18) Abrufen von Dokumenten (ITI-43) 5. Nutzung von Ordnern 6. Akteninhalte 22

23 Akteure zur Prüfung von Berechtigungen 1. Request Authorization Decisions Authorization Decision Provider Authorization Requestor 4. Provide Authorization Decisions 2. Request Policies 3. Provide Policies Policy Repository Authorization Requestor entspricht einem XACML PEP (Policy Enforcement Point). Authorization Decision Provider entspricht einem XACML PDP (Policy Decision Point). Policy Repository entspricht einem XACML PAP (Policy Administration Point). Die Transaktionen werden über SOAP und dem SAML 2.0 profile of XACML umgesetzt. Ähnlich wie XUA werden die Akteure des Profils sinnvoll mit den Akteuren der inhaltlichen Transaktionen (z.b. XDS Query) kombiniert. Prüfung von Berechtigungen beim Suchen und Abrufen von Dokumenten Autorisierungsentscheid ung aus dem Cache Authorization Decision Provider 3. Request Policy 4. Provide Policy Policy Repository 2. Authorization Requestor 5. Document Registry 8. Request. Authorization Decision XDS query response Provide Authorization Decision Document Repository Authorization Requestor XDS query 7. XDS retrieval Document Consumer 10. XDS retrieval response 23

24 Standardisierte Lösungsmodule 1. Patientenidentifikation 2. Benutzeridentifikation und -authentifizierung 3. Verwalten von Berechtigungen 4. Prüfung von Berechtigungen 5. Nutzung von Ordnern XDS-Folder werden zur Abbildung von Fallakten verwendet Zweck der Akte (z.b. 3stelliger ICD-10) steht in Folder.codeList Fallakte ist die Summe aller XDSFolder eines Patienten, die mit dem gleichen Zweck Code markiert sind XDSFolder mit Zweck können beliebige zusätzliche Codes verwenden, z.b. um administrative Dokumente zu gruppieren 6. Akteninhalte Beispiel: Patient mit mehreren Fallakten bzw. zweckgebundenen Akten Pat. ID 2016 codelist: (IHE-D-Zweck, S42) (Stationärer-Fall-KH-1, ) codelist: (IHE-D-Zweck, IV-Hüftprothese) codelist: (IHE-D-Zweck, S42) (Ambulanter-Fall-KH2, ) codelist: (IHE-D-Zweck, A38) 24

25 Ausblick NÄCHSTE SCHRITTE Nächste Schritte Neue Version 0.9 in Q1/2013 Einarbeitung der Kommentare Harmonisierung der technischen Basis und Beschreibung der Aktenmodelle Öffentliche Kommentierung 22.April bis 31.Mai 2013 Version 1.0 mit Detailspezifikation nationaler Erweiterungen und Profile Erweiterung der Fokus in weiteren Versionen Domänenübergreifender Datenaustausch Strukturierte Dokumente Detailworkshop zum Cookbook auf der conhit 2013 am Donnerstag: 13:30 Uhr, Halle 1.2, PR-Raum 25

26 Vielen Dank für Ihre Aufmerksamkeit! 26