Establishing a Personal Electronic Health Record in the Rhine-Neckar - PowerPoint PPT Presentation

Establishing a Personal Electronic Health Record in the Rhine-Neckar Region Sarajevo 31th of August 2009 Oliver HEINZE 1 , Antje BRANDNER 1 , Björn BERGH 1 1 Department of Information Technology and Medical Engineering University Hospital Heidelberg, Germany

Overview 1. ! Objectives 2. ! Overall concept 3. ! Architecture of PEHR 4. ! Lessons learned 5. ! Outlook

Objectives - What shall be achieved?  ! Support integrated care with strong focus on the patient  ! Improve quality of diagnosis + treatment  ! Avoiding multiple examinations  ! Reduce costs / Optimize cost-benefit-ratio  ! Infrastructure which enables a seamless communication  ! Web-based integrated view  PEHR!

Types of records

EMR, EHR and PHR Record type Characteristics Main Advantages Main Disadv. EMR All clinical data of a patient Not accessible for other doctors or to document, monitor and Electronic the patient manage care delivery in Medical Record one institution Case-based accessible within the care delivery organisation (CDO) Subsets of each CDO‘s EMR Viewing in other No patient EHR presently assumed to include CDOs possilbe involvement for Electronic summaries (CCR, etc.) viewing and Easier data import Health Record access Longitudinal access across from professional management multiple institutions systems (high quality and completeness) PHR Contains patient input (home Fully controled by No automated care devices, diet, sports). the empowered data import from Personal Health Acess for multiple player is patient other systems Record managed by the patient

PEHR Vision Patient

PEHR Scope  ! Rhine-Neckar Region about 2,4 Mio. inhabitants 1 Phase: EHR 2 Phase: EHR more practices and hospitals 3 Phase: PEHR

Partner  ! InterComponentWare AG Walldorf • ! Product: Professional Exchange Server (PXS) • ! MPI and Record Module (EHR) • ! Lifesensor (PHR)  ! CHILI GmbH • ! WADO+ Gateway + DICOM Webserver  ! Rhine-Neckar Health Centers (GRN gGmbH): 4 Hospitals (1000 beds)  ! Specialist practices (2 oncology)  ! University Hospital Heidelberg (2000 beds) • ! Maximum medical care • ! 60.000 inpatients/a • ! 250.000 outpatients/a

How? Technical concept

Network structure Other Hospitals PEHR DMZ SSL over VPN tunnel PXS Wado+ DB Wado+ and Apache Webserver University SSL + Client Certificates Hospital HD Medical Practices HIS/CIS RIS/PACS DMZ: Demiliterized Zone WADO: Web access to DICOM Objects SSL: Secure Socket Layer VPN: Virtual Private Network H(C)IS: Hospital or Clinic Information System

Patient allocation and document sharing MPI: Meier HIS 1= 1234 HIS 2= 4711 Hospital 1 (P)EHR Hospital 2 Patient data Patient data MPI diagnoses, diagnoses, documents document HIS 1 HIS 2 EPR Web viewing viewing EPR: Meier OP-Report HIS 1 Discharge Letter HIS 2 …

Patient allocation, document sharing and integration of PACS Hospital 1 (P)EHR Hospital 2 Patient data Patient data MPI diagnoses, diagnoses, documents document HIS 1 HIS 2 EPR Web viewing viewing viewing image-ref. Web Web Web image-ref. PACS 1 WADO PACS 2 images image-request

Privacy Consent

Decentralized Consent Management University Hospital Heidelberg O Yes O No O Yes Viewing, Senden O No Hospital Viewing, Senden Schwetzingen Viewing, Senden Medical Practice (P)EHR O Yes O No • ! Consent is paper-based • ! Each CDO has to implement their own storage solution • ! Administrative stuff has to fill in the consent flag in the local HIS/CIS

Centralized Consent Management referring to IHE BPPC PEHR HL7 ADT HIS/CIS Consent Creator in context EMR Policy 1: 0 MPI Policy 2: 0 Digital Archive Policy 3: 0 … XACML via HL7 MDM Authorization Manager Record Print for Signature Module Scan IHE: Integrating the Healthcare Enterprise BPPC: Basic Patient Privacy Consent XACML: OASIS eXtensible Access Control Markup Language

Experieces

Lessons learned Privacy consent Interfaces Decentralized: Development required Document export: Development CIS to store and send consent flag; viewing required due to lack of support of HL7 and sending modules have to check MDM interfaces; this flag; Centralized: no development Viewing: Development for https-based nessessary; a consent creator has to context integration required; GUI for be connected (  Interface!) consent flag management PACS Decentralzied: Communication server Highly complex message interaction has to filter HL7 Messages in order to between several system modules; check if forwarding to WADO Much logic inside the WADO module component is allowed or not required; solution is dependent on local Centralized: WADO component has to conditions and not as generic as initially ask the authorization manager if QR is intended (IHE based) due to the allowed (  Interface required) proprietary interfaces of our vendor Decentralized: No adaption to PEHR Only little adaption of pre-processing PEHR systems required required at communication server (ESB) Centralized: authorization manager and processing of XACML policies required

Outlook  ! And in future? • ! Usable cross-linkage to medical practices: Webinterface vs. direct pimary system integration • ! How to deal with data from the „before consent“ period? • ! New services inside the PEHR e.g. drug safety • ! Keep focusing on IHE profile usage

Thank you! University Hospital Heidelberg Center of Information Technology and Medical Engineering (ZIM) Tiergartenstr. 15 | 69121 Heidelberg | Germany Oliver Heinze (M. Sc. in Medical Informatics) Mail oliver.heinze@med.uni-heidelberg.de Fon +49 6221 56 37571 Antje Brandner (M. Sc. in Medical Informatics) Mail antje.brandner@med.uni-heidelberg.de Fon +49 6221 56 37800 Prof. Dr. med. Björn Bergh (Director ZIM) Mail bjoern.bergh@med.uni-heidelberg.de Fon +49 6221 56 2000