How To Create A Germanian Ehr System

Transcription

1 Health Record Architecture(s) in Germany Motivation and Architecture Overview Dr. Jörg Caumanns, Fraunhofer-Institut FOKUS Berlin congres Architectuur in de zorg, Utrecht,

2 Agenda The Philosophy of the German ecr+phr paradigm The Patient in Control: The German PHR platform Regional Care Networks: The ecr platform 2

3 The EHR/PHR Success Story?? Google.health -> leaving the German/European market Microsoft HealthVault -> almost invisible in Germany ICW LifeSensor -> suspended CGM Life (Vita-X) -> re-launch, low market visibility Siemens Assignio -> to be suspended? regional EHR networks -> dependend on public funding, few in real operation NHS in England -> suspended Dutch EHR system -> suspended Czech EHR system -> suspended German telematics infrastructure -> 7+ years late, reduced functionality Many other governmental EHR/PHR activities delayed due to privacy/security issues, increasing costs, and/or low acceptance 3

4 The Balance is the Challenge Privacy Security Usability Flow Integration Functionality Value of Benefit 4

5 The One fits All PHR/EHR Compromise Physicians actively accessing patients data (e.g. query-retrieve-pattern) Who is in control? Who is responsible? Privacy enforcement by Access Control Patient as the bad guy who imposes constraints Access Management vs. Usability Static Configuration (Permissions, Identities, Roles, ) On-Demand Use? Usage specific semantics? 5

6 Different Requirements <=> Different Solutions Immediate access -> database Long term storage -> archive Data processing -> database (OLTP) Data analysis -> data warehouse (OLAP) Async. Communication -> Sync. Communication -> phone, chat Bilateral Data Exchange -> Multilateral Data Sharing -> FTP, etc. Machine Processing -> XML Display to Human -> PDF Publishing Data -> Web Site, Wiki, Cooperation -> Project Place etc. Why do ehealth architects always asume that a single health record architecture could serve all needs? 6

7 Privacy Patient in Control Consent Closed User Group Interaction Spontanous Need Data Integration Active Treatment Usability Functionality 7

8 Privacy Patient in Control Consent Closed User Group Interaction Spontanous Need Data Integration Active Treatment Usability Functionality 8

9 No Compromises - Interaction Patient in Control Spontanous Need Personal Record acc. 291a SGB V Citizen interacting with her physicians Citizen owns data and has full power of control MoH R&D Project as incubator for a future national solution Data Integration Closed User Group Active Treatment Electronic Case Record (ECR/EFA) Members of the care team sharing data related to a single medical case Patient consents to the care team Virtual integration of physicians data within regional healthcare networks Sponsored by 25+ hospitals 9

10 Personal Health Record acc. 291a SGB V Putting the patient into full control 10

11 Asynchronous Interaction Patterns Physician->Citizen: Could you please provide me with your medication plan? Citizen->Physician: Here you are. Citizen->Physician: Could you please provide me with last weeks lab results? Modular Patterns: Physican requests Data from Citizen Phyician provides Data to Citizen Citizen requests Data from Physician Citizen provides Data to Physician Physician->Citizen: I ve updated your nutrition plan. Here it is. Citizen->Physician: Here are last weeks blood glucose values. 11

12 Synchronous Interaction Patterns Physician->Citizen: I would like to register this new medication with your medication plan. Citizen->Physician: Could you please just register this X-Ray with my PHR? Modular Patterns: Physican requests data (together with a patient token); PHR provides data Physican provides data (together with a patient token); PHR accepts data Citizen->Physician: Yes, that test has already been done. The report is available with my PHR. Physician->Citizen: The test shows that you have a cat allergy. Would you like me to set up an allergy passport within your PHR? 12

13 Integration Platform Medication Plan Vaccination Record Interaction Patterns Semantic Interoperability Framework Security Modules (Authorization, ) Communication and Storage Abstraction Layer Adapter Adapter Adapter USB Device Online Database 13

14 Semantic Signifiers The PHR is just a semantics-agnostic platform! Medical use cases are served by applications (e.g. medication plan, allergy passport, patient diary,.) which are implemented on top of this platform. Application semantics are encapsulated as semantic signifiers. Concept map of the application Information models (incl. schemas and schematrons) of the application objects Behavior wrt. create, read, update of application objects E.g. providing a new medication plan makes this the current medication plan. Requests are always on the current medication plan only. Each interaction is bound to a specific semantic signifier! Two special semantic signifiers: Capability list: Which patterns and semantic signifiers does the PHR support? Table of Contents: Which applications are active with the PHR? 14

15 Electronic Case Records (ECR) / elektronische Fallakte (EFA) Architecture Overview 15

16 Essentials ECR is an initiative which is driven and sponsored by German hospitals The objective is to provide a data sharing plattform for regional care networks Hospitals as data providers and service providers Self-Organization (no central services but PKI) Conformant to German Privacy Regulations Adaptable to disease/contract-specific care scenarios Status Specifications have been published in pilot projects in different regions 2 fully operational networks (Munich, Aachen) Product support from industry (Siemens, isoft, ISPro, CrossCheck) Integration with future German Telematikinfrastruktur has been committed 16

17 ECR Logical Model Scenario: Someone is ill and subject to co-operative treatment The kinds of relevant data and the scope of the treatment can be defined purpose specific data collection co-operating physicians and organizations need access to all data which is relevant for the patient s treatment patient gives consent to this (NO fine grained permissions needed!) An ECR medical case corresponds to a co-operative treatment Each medical case is made up from folders and administrative cases (which are folders, too) An ECR administrative case corresponds to an inpatient visit that is part of the treatment -> automated linkage of visits and ECR folders Medical data is registered within folders Document metadata for freely configurable views 17

18 Autorisierung Authentisierung ECR as a Federated System 18 Authentisierung Authentisierung

19 ECR Security Architecture (Overview) Authenticate Users / Assign Attributes Create Admission Codes Discover Patient s Records Assign Access Policies Obtain Access Policies Enforce Access Policies PatientID RecordID ECR Document Registry Identity Provider ECR Admission Token Service ECR Record Registry ECR Access Token Service ECR Policy Token Service ECR Document Registry Identi tity / Attributes Record Identifier Access Policy ID licy Access Poli ECR Document Repository Identity Assertion Admission Assertion Access Assertion Policy Assertion IDM Admission Lists Policy Registry UserID Attribute SecretHash Admission Code RecordID PolicyID PolicyID Access Policy RecordID Metadata 19

20 ECR Assertion Chaining identit y assertion Identity Provider produces consumes cons sumes consumes Admission Token Service Access Token Service Policy Service admission assertion produces access assertion produces policy assert ion produces reference eference reference w ho? w hat? patient consent consumes Business Services 20

21 ECR Building Blocks ECR Consumer Hospital acting as ECR Provider ECR in a Box Deployment: Full encapsulationofecr Security and XDS-based Record Interface 21

22 ECR in a Box: Services and Operations 22

23 Record Management: Logical Operations Create Record Close Record Merge Records Split Records Update Metadata Align Purpose Register Consent Deprecate Consent Register Episode/Visit De-Register Episode Update Episode Metadata. Update Patient Demographics Update Patient ID Add Care Team Member Remove Care Team Member Update Care Team Member ID Update Care Team Member Role Register Document De-Register Document Update Document Metadata incl. diagnosis-specific Metadata Dedicated service interface per management operation? How to manage diagnosis specific extension? As metadata? 23

24 ECR R-MIM The full ECR Information Modell can be implemented as an CDA compliant R-MIM New ECR instances can be set up by sending a respective CDA to the ECR Box E.g. using a standard doctor s letter Dear ECR Box. The current status (content) of an ECR instance can be exported as a set of interlinked CDA documents A ECR instance can be managed by adding/deleting/updating sections and entries within the respective CDA document E.g. updating the purpose is done by updating the respective entry within the CDA s diagnosis section Diagnosis specific extensions can be implemented and managed by simply adding further sections/entries (ECR R-MIM compliant, diagnosis specific R-MIM) 24

25 ECR R-MIM Patient ecr Object Initiator Header Roles Care Providers ecr Provider Contract Docs. Purpose Diagnosis Body HCP Visits CAVE Docs. ecr-v ecr-specific sections (optional) 25

26 ECR Visit (Folder) R-MIM Patient Care Giver ecr-v Header ecr Object Inpatient Visit Admission Diagnosis Diagnosis ecr-v Body Contract Docs. Medical Documents ecr-specific sections (optional) 26

27 Nesting of Standards ECR R-MIM (Subset of CDA R-MIM) IHE PCC PHR Update HTTPS SOAP OMG/HL7 RLUS Provider Interface CDA Processor ECR Services ECR Box 27

28 Example: Registration of a Document with an ECR <ecr:initializerlusecrboxrequest> <!-- ecr Document --> <cda:clinicaldocument>... </cda:clinicaldocument> <RLUStypes:RLUSInitializeRequestSrcStruct> <RLUStypes:RLUSsemantic-signifierName> ecr-document </RLUStypes:RLUSsemantic-signifierName> <RLUStypes:SecurityContext>...</RLUStypes:SecurityContext> <RLUStypes:InitializeContext> <! visit identifier --> <cda:encompassingencounter> <cda:code code="inp codesystem=" " /> <cda:id root="..." extension="..."/> <cda:effectivetime NullFlavor="UNK" /> </cda:encompassingencounter> </RLUStypes:InitializeContext> <RLUStypes:CBRContext>...</RLUStypes:CBRContext> </RLUStypes:RLUSInitializeRequestSrcStruct> </ecr:initializerlusecrboxrequest> 28

29 ECR Box (Plug & Play Deployment) Crosscheck Networks Frans Halslaan nr GJ Waalwijk [email protected] 29

30 Conclusion EHR/PHR is just a platform Multiple, simple and easy-to-use platforms vs. making compromises on usability, functionality and privacy Access control means must be integrated with the logical architecture The 1 st challenge is on extensibility and adaptability Disease specific care networks, Quality management, reporting procedures, Semantics-aware domain/application models as basis for access operations (e.g. query for current medication) Application-specific adaptation of CRUD behavior The 2 nd challenge is on EHR/PHR administration and operation The deeper the EHR is integrated with hospital IT the more management functionality will be needed Management operations must abstract from technology and implementation 30