Mainz, Juli O. Heinze, M. Birkle, B. Schreiweis, N. Yüksekogul, B. Bergh

Transkript

1 Grundlagen der elektronischen Einwilligungsverwaltung in der Architektur der ISIS-Akte in der MRN für multizentrischen Versorgungs- und Forschungsszenarien Mainz, Juli 2013 O. Heinze, M. Birkle, B. Schreiweis, N. Yüksekogul, B. Bergh Sektion Medizinische Informationssysteme Zentrum für Informations- und Medizintechnik

2 Hintergrund

3 ZIM-Projekte mit Bezug zum Einwilligungsmanagement Versorgungsbezug 2006/2007 Intersektorales Informationssystem (ISIS) Forschungsbezug Heidelberg Research Platform (HEIREP) 2010 GANI_MED Seit 2012 (Antrag seit 2008) INFOPAT Teilprojekt Persönliche elektronische Patientenakte PEPA (P2) INFOPAT Teilprojekt Forschungs- und Wissensplattform (P8)

4 Versorgungsszenario: Die ISIS-Akte in der MRN EPA Hausarzt EPA EPA Krankenhaus Universitätsklinikum eepa, PEPA, EPA Facharzt EPA Apotheke EPA Legende Patient EPA: Elektronische Patientenakte eepa: Einrichtungsübergreifende EPA (engl. EHR) PEPA: Persönliche eepa

5 Forschungsszenario INFOPAT-Forschungsplattform Patient EPA Hausarzt / Facharzt Einwilligung, Zugriff EPA PEPA Pseudonymisierte Daten Uniklinikum / Krankenhaus EPA Apotheke

6 Zielsetzung / Forschungsfrage In allen Szenarien (Versorgung und Forschung) geht es um Datenaustausch Daten dürfen nur aus den Primärsystemen übermittelt werden, wenn der Patient zuvor aufgeklärt wurde und in die elektronische Übermittlung eingewilligt hat (Informed Consent). Zentrale Datenschutzanforderung für das Einwilligungsmanagement! Wie kann eine standardisierte, generische und modulare Lösung für einrichtungsübergreifende, elektronische Patientenakten und Forschungsplattformen aussehen?

7 Grundlagen

8 Der IHE-Gedanke (Connectivity, Interoperabilität) IHE-Profile IHE-Profile IHE-Profile (z.b. PDQ) IHE-Profile IHE-Profile IHE-Profile Transaction ITI-21 Patient Demogr. Query: HL7 v2.5 QBP^Q22 Actor 1 Patient Demographics Consumer Actor 2 Patient Demographics Supplier

9 IHE Profil BPPC Basic Patient Privacy Consent very basic profile to manage patient privacy in XDS environments three problems of BPPC have been identified: usage of OIDs in the field confidentiality code return of all privacy policies to the decentralized policy decision points no workflow described how to manage consent documents

10 extensible Access Control Markup OASIS Standard Language (XACML) Syntax zur Definition von Policy-Sets, Policies, Rules Autorisierungsanfragen und antworten (Rudimentär, besser mit SAML: Security Assertion Markup Language)

11 Wichtige Rollendefinitionen in XACML Policy Administration Point (PAP) Verwaltung der Policies (z.b. in einem Repository) Policy Decision Point (PDP) Evaluation von Anfragen Prüfen gegen Policies Entscheidet über die Autorisierung Policy Enforcement Point (PEP) Setzt Entscheidung des PDP durch

12 Forschungsmethodik Literaturanalyse zur Identifikation existierender Ansätze Design and Creation* für die Entwicklung der Konzepte, Modelle, Architekturen Awareness (Problem erkennen) Suggestion (Lösungsvorschläge) Development (Umsetzung) Evaluation (Abgleich Ergebnis mit Erwartungen) Conclusion (Konsolidierung der Ergebnisse des Design-Prozesses) Evolutionäres Konzept und Umsetzung über mehrere Stufen 1. ISIS-Akte als eepa, standardisiert 2. ISIS-Akte als PEPA, basierend auf IHE-Profilen * Briony J. Oates (2006): Researching Information and Computing, London: Sage.

13 ERGEBNISSE

14 1. Generation ISIS-Akte (eepa)

15 Architektur ISIS-Akte 1. Generation AFFINTY DOMAIN (MRN) Primary Primärsysteme like Hospital Hospital Information Information Clinical Clinical Information Information Practice Practice Management Management Etc. Etc. Adapter HL7 ADT Adapter HL7 MDM eepa-kern MPI Aktenmodul Adapter DICOM Bildintegration Adapter GUI Context Based Integration

16 ISIS-Akte 1. Generation AFFINTY DOMAIN (MRN) Primary Primärsysteme like Hospital Hospital Information Information Clinical Clinical Information Information Practice Practice Management Management Etc. Etc. Consent Creator PAP PDP Adapter HL7 ADT Adapter HL7 MDM PDP PEP PEP eepa-kern MPI Aktenmodul Adapter DICOM PDP PEP Bildintegration Adapter GUI PEP Context Based Integration

17 Umsetzung des Consent Creators in ish.med

18

19 Nachteile Einwilligung in jeder Organisation erneut nötig Nicht für alle Primärsysteme implementierbar (vor allem PVS) Kein elektronisches Einwilligungsdokument Inhalte der Einwilligung nicht feingranular steuerbar (z.b. auch für Forschungsplattform)

20 2. und 3. Generation ISIS-Akte (eepa und PEPA)

21 PEPA: IHE-Akteure und Transaktionen ohne Security (Auswahl) AFFINTY DOMAIN (z.b. MRN) Primary Primärsysteme like Hospital Hospital Information Information Clinical Clinical Information Information Practice Practice Management Management Etc. Etc. Patient Identity Source PIX Consumer ITI-8 Patient Identity Feed ITI-9 PIX Query PEPA-Kern MPI, Record Module PIX Manager Document Registry ITI-8 Patient Identity Feed ITI-18 Registry Stored Query Portale PDQ/PIX Consumer Document Consumer 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

22 PEPA Akteure und Transaktionen ohne Security (Auswahl) AFFINTY DOMAIN (z.b. MRN) Primary Primärsysteme like Hospital Hospital Information Information Clinical Clinical Information Information Practice Practice Management Management Etc. Etc. Patient Identity Source PIX Consumer PEP ITI-8 Patient Identity Feed PEP ITI-9 PIX Query PEPA-Kern MPI, Record Module PEP PIX Manager Document Registry ITI-8 Patient Identity Feed ITI-18 Registry Stored Query Portale PDQ/PIX Consumer Document Consumer Consent Creator Document Source ITI-41 Provide and Register Document Set-b PEP Document Repository ITI-42 Register Document Set-b ITI-43 Retrieve Document Set PDP PAP Consent Manageme nt Service Context Based Integration

23 Consent Management Service (CMS)

24 Consent Creator Service (CCS)

25 Neue Akteure im IHE-D Cookbook PEP: Authorization Requestor PDP: Authorization Decision Provider PAP: Policy Repository Advanced Consent Creator: Erstellt Einwilligungsdokumente auf Basis von XACML

26 Diskussion Modularität und Konzept der IHE-Akteure ermöglicht eine flexible Verteilung der benötigten Funktionen innerhalb einer spezifischen Architektur (Generalisierbares, allgemeingültiges Konzept, spezielle, regionale, Verbund-bezogene Lösung/Implementierung Hoher Widerverwendungsgrad der Komponenten COMS soll Referenzimplementierung für die neuen IHE-D Akteure werden: Aufbau einer nationalen und evtl. internat. Community angestrebt!

27 Ausblick Anpassung COMS an IHE-D Cookbook Akteure Integration des COMS-Consent-Creators in INFOPAT (P2/P8) Umsetzung als App-Client Konzept/Machbarkeit für die variante Forschungs- Szenario als Private Cloud mit virtuellen Netzen

28 Literatur 1. Heinze, O., B. Birkle, L. Köster, B. Bergh (2011). Architecture of a consent management suite and integration into IHE-based Regional Health Information Networks. BMC medical informatics and decision making: 11: p Idris, T., R. Brandner, B. Bergh and O. Heinze (2012). "Eine Standardisierte Sicherheitsarchitektur für den einrichtungsübergreifenden Datenaustausch." e-health 2013: IHE-Deutschland (2013). Cookbook zur sicheren, aktenbasierten Bild- und Befundkommunikation (

29 Vielen Dank! Fragen? Kontakt: Universitätsklinikum Heidelberg Zentrum für Informations- und Medizintechnik Oliver Heinze Speyerer Str.4 D Heidelberg