Umgang mit multiplen IHE Affinity Domains bei der Einbindung des mündigen Bürgers und Patienten in Prozesse des Gesundheitswesens

Transkript

1 Umgang mit multiplen IHE Affinity Domains bei der Einbindung des mündigen Bürgers und Patienten in Prozesse des Gesundheitswesens Dr. Oliver Heinze Dortmund Abteilung für Medizinische Informationssysteme

2 Hintergrund Krankenhausinformationssystem Universitätsklinikum Heidelberg Patienten = Kooperation, IHE Interoperabilität: (Integrating the Austausch und Healthcare Die Fähigkeit Enterprise) zur Wiederverwendung Zusammenarbeit von von Daten Initiative von Anwendern und verschiedenen und Informationen eakten Herstellern zur Verbesserung Systemen oder der Interoperabilität Organisationen im Gesundheitswesen Bilder & Dokumente zum Patienten Weitere Kliniken... Arztpraxissysteme & Portal Hausärzte / Fachärzte

3 Hinzu kommen weitere Netze und Verbünde: -Versorgung: Krankenhausketten, Fachnetze (z.b. Traumanetz),.. - Forschung: BMBF-Initiative MI,..

4 Problem Es entstehen multiple IHE Affinity Domains Jeweils eigene Zugänge und Identitäten für Nutzer (Patienten und Gesundheitsdiensteanbieter) Verschiedene Portale / Apps als Zugang (Usability?) Inhalte nicht an einem Ort / in einer View ADs sind technisch Versorgungsprozesse richten sich nicht nach AD- Grenzen Patienten denken nicht in ADs

5 Usecases aus Bürger- / Patientensicht Zugriff auf Dokumente Zugriffe Steuern Einwilligungen erteilen Eigene Dokumente übermitteln: Aufnahmedokumente Einwilligungen PRO für Versorgung (Monitoring-Daten) und Forschung (Fragebogen, Follow-ups, etc.)

6 Was müssen wir lösen? Aus Nutzersicht zentral für multiple ADs: Identitätsmanagement, einen zentralen Account verknüpfen mit XAD-PIDs (Authentifizierung,..) Einwilligungsverwaltung und Zugriffssteuerung (Autorisierung) Dokumentenaustausch (Metadaten, technische Endpunkte, Inhalte,..) Datenschutz und Datensicherheit (Zertifikate, etc.)

7 IHE Affinity Domain (AD) An XDS Affinity Domain is an administrative structure made of a well-defined set of Document Source Actors, set of Document Repositories, set of Document Consumers organized around a single Document Registry that have agreed to share clinical documents.

8 Beispiel-AD PEPA MRN Patient Primary systems IHE compliant Software PEPA Persönliche einrichtungsübergreifende Gesundheits- und Patientenakte Patient Portal Integration platform IHE IHE-based Interface PEHR Core Professional Portal IHE Universitätsklinikum Heidelberg Professional IHE Adapter Non-IHE compliant Software Master Patient Index Document Registry Document Repository Healthcare Provider Directory Imaging Repository Policy Enforcement Point Log Repository Policy Decision Point Policy Repository

9 Welche Möglichkeiten bietet IHE? Cross-Profile XCA: Cross-Enterprise User Assertion XCPD: Cross-Community Patient Discovery XCA: Cross-Community Access XCF: Cross-Community Fetch XCDR: Cross-Community Document Reliable Interchange Nachteile Identitätsmanagement ggf. schwierig und ggf. Security- Probleme Einstellen XCDR bisher nicht weit verbreitet

10 Vernetzung von Regionen (IHE Affinity Domains) AD-Roaming PEPA Alle Akten in den unterschiedlichen IHE-ADs nutzen den selben Interoperability Stack IHE ITI (Profile XCPD, XCA,..) Gateways IHE-D Value-Sets (Metadaten) Gateways Gateways efa Patienten können über Portale/Apps der jeweiligen AD Informationen abrufen eepa Nachteil: Usability, Inhalte ggf. nicht in einer View

11 Lösungsvorschlag: Teil multipler ADs sein PATIENTENSEITE VOR DIE KLAMMER ZIEHEN

12

13 Architektur: Ein Frontend, Datenaustausch mit multiplen ADs Frontend (Apps + Web) IHE + FHIR PHIL SDK Personal Health Interop. Interfaces (PHIL) IHE Affinity Domains Frontend (Apps + Web)3rd Backend (Services, Logic + Storage) + Aphinity (IHE connectivity services incl. AD-Repository) IHE XDS & Co. Gesundheits-Betriebssystem für Bürger und Patienten (digitalen Gesundheitsdrehscheibe) Mobile Nutzung (ios, Android) Wichtige Basisservices nach EU-Regularien Sichere, digitale Identität + Login Akte (Storage) Services: Medikationsplan, epro Konnektivität Hoch adaptierbar an persönliche Lebenssituation durch 3. App-Integration (IHE und FHIR) Integriert bestehende ehealth-infrastrukturen (IHE) Zertifizierung nach MPG

14 IHE-AD-Konnektivität Modul Aphinity Kommunikation 1:n zwischen Gesundheitsanwendung und mehreren Affinity Domains AD-Repository (Könnte IHE-Profil werden) Endpunkte Verwaltung (OIDs, URLs,.., für Schnittstellen verwendeter IHE- Akteursimplementierungen PIX/PDQ (MPI), HPD XDS-Registry, Repository ATNA (Logging)... Zertifikatsverwaltung (Public Keys) Ggf. XDS-Metadaten-Mapping (Harmonisierung) Policy-Prüfung (BPPC, APPC) Identitätsmanagement: PIX-Profil: PIX-Feed, PIX-Query + weitere Maßnahmen

15 Zugriff auf bestehende Daten n ADs (n>=1) à eine konsolidierte Sicht XDS 1. n-fach ITI-18: Registry Stored Query 2. ITI-43: Retrieve Document Set MHD 1. n-fach: ITI-67: Find Document References 2. ITI-68: Retrieve Document

16 Einstellen von Daten Für n ADs (n>=0) 1. Als FHIR-Ressource in Patienten-AD 2. Sonst: XDS ITI-41: Provide&Register Document Set-b 3. Oder MHD: ITI-65: Provide Document Bundle

17 Vergabe von Zugriffsberechtigungen Für n ADs (n>=1) 1. ITI-41: Provide&Register Document Set-b 1. Falls Dokument in Home-AD des Providers unbekannt das Dokument 2. Regel(n) in APPC- Dokument

18 Diskussion Vorteile des Ansatzes: Patienten haben alles an einem Ort (in einer View) unter ihrer Kontrolle Patienten können den Service wählen, der ihnen am besten zusagt POC am UKHD dieses Jahr, ab nächstes Jahr weitere Bei der nötigen Architektur ist noch nicht alles in IHE-Profilen spezifiziert/profiliert: AD-Repository,.. Wünschenswert auf nationaler Ebene Einheitliches Patientenverzeichnis (MPI) Einheitliches Provider Directory (HPD) Einheitliches AD-Repository (ggf. als neues IHE-Profil)

19 Vielen Dank! Haben Sie