Elektronische Fallakten und IHE

Transkript

1 Elektronische Fallakten und IHE Elektronische Fallakten: Umsetzung und Etablierung IHE Infotag 2007 Dr. Jörg Caumanns // Fraunhofer ISST Frankfurt,

2 Patientenbezogene vs. Fallbezogene Akten Lebenszyklus durch Patienten bestimmt Verantwortung nur beim Patienten Kopien in patientengeführten Akten und vom Patienten eingestellte (Original-)Daten ( 291a, etc.) Übergabe ( Kopie/ef.) Lebenszyklus durch einen Fall bestimmt Inhaltliche Verantwortung beim Arzt Einwilligung durch Patienten Übergabe ( Kopie/ef.) Übernahme (Kopie) Übergabe (Kopie/ef.) Übernahme ( Kopie) Kopien / eferenzen in fallbezogenen Akten ( 137f, 140, etc.) Lebenszyklus durch Archivierungsvorschriften bestimmt Verantwortung beim Arzt KIS PVS DMS Primärdaten in den Primärsystemen der Leistungserbringer 2

3 »3-inge-Modell«für elektronische Akten Einweiser-Portale Einrichtungsübergreifende Kooperation Authentisierung Vernetzung von Providern (P2P / Föderationen)»Anwendungen«Diagnosespezifische Akten und Gesundheitsdienste Patienten-Portale IV Unterstützung.»Middleware«(normiert) Identity Management Zugangsmanagement Extern nutzbares CUD-API für strukturierte Patientendaten Portal-Integration Interne Systeme des Krankenhauses zur Verwaltung von Patienten- und Mitarbeiterdaten 3

4 ec und IHE XDS (1/2) Authentication Identity Management (off-the-shelf) White Pages for physicians and organizational units request access to the application Pseudonymization Anonymization Cryptografic mechanism Physician IHE Patient Identity Feed request access to a patient s medical records ecord Discovery (Meta-)Directory P2P Discovery Facade (SOAP) or Web-Portal IHE XDS epository Queries and Filters request access to medical data ecord and Data Management IHE XDS egistry Existing solutions/products ec-specific services Provider-specific implementation Data Sources (KIS, PVS, IS, LIS, ) Frontend-API (SOAP, SAML, XACML, WS Trust) Backend-API (SOAP, IHE, LDAP, ) 4

5 ec und IHE XDS (2/2) ec Case egistry ec Client XDS Client (Consumer) ec API Wrapper XDS API Wrapper Packaging (Core Product + Adaptors) Meta data egistry register epository MDOs Core Product Identity Feed provide and register register case Patient Mgmt Data Provosioning Application(s) 5

6 Actors and Transactions Electronic Case ecord ec TokenService get pseudonyms ec Locator discover cases query admission code ec Case egistry query registry register partition IHE XDS admisson code feed query registry Consumer egistry register document set Source provide & register document set epository retrieve document 6

7 efa IHE Migration (1/2) efa nutzt IHE ATNA für Audit Trails Ein Audit epository pro efa-provider Protokollierung gemäß einer Adaption der IHE und DICOM Profile für FC 3881 IHE XUA entspricht im Kern der Spezifikation des efa Identity Provider Unterstützung von SAML 2.0 für efa geplant Gemeinsame Profile für WS Trust and SAML sind sinnvoll Vorschlag: Einheitliches»Passive equestor Profile«IHE Cross Community Information Exchange sollte das zweistufige Föderationsmodell der efa- Architektur als Umsetzungsoption berücksichtigen: efa Federation Service vs. IHE Community Bridge efa P2P und Trust Brokerage vs. homogener»circle of Trust«eFA P2P discovery vs. IHE Data Existence Locator IHE Patient Agreement Profile (PCC) muss mit den kommenden Spezifikationen zu Einwilligungen im Kontext der deutschen Gesundheitskarte abgeglichen werden. 7

8 efa IHE Migration (2/2) Ko-Existenz von zentralisierten Strukturen in einer P2P-Infrastruktur (und umgekehrt) macht Sinn und ist eine Synergie-Option für IHE und efa Assertion-Fluss der efa kann als Vorlage für IHE»EH discovery and authorization profile«dienen Die rein virtuelle Integration von Datenquellen sollte von IHE XDS besser unterstützt werden: Zumindest in Deutschland gibt es keinen Business Case für zentrale Patientenregister und Patientendaten-Speicher Die rechtlichen ahmenbedingungen und Datenschutzanforderungen lassen sich über eine Datenhaltung bei Gesundheitsdienstleistern einfacher umsetzen Gemeinsame Herausforderungen Passive equestor Profile (efa lässt aktuell WS FL, Liberty und SAML Artefakte zu) Umsetzung von Abfragen auf HL7 CDA kodierte Dokumente Vorgaben zu Protection Profiles Angemessene Nutzung von Anonymisierung und Pseudonymisierung Umgang mit qualifiziert signierten Dokumenten 8