How To Create A Germanian Ehr System

Health Record Architecture(s) in Germany

Motivation and Architecture Overview

Dr. Jörg Caumanns, Fraunhofer-Institut FOKUS Berlin

Agenda

The „Philosophy“ of the German eCR+PHR paradigm

The Patient in Control: The German PHR platform

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

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,

The Balance is the Challenge

Privacy

Security

Usability

Flow Integration

Functionality

Value of Benefit

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

– Patient as the „bad guy“ who

imposes constraints

– Access Management vs. Usability

Static Configuration (Permissions, Identities, Roles, …)

– On-Demand Use?

Immediate access -> database Data processing -> database (OLTP) Async. Communication -> eMail Bilateral Data Exchange -> eMail

Long term storage -> archive

Data analysis -> data warehouse (OLAP) Sync. Communication -> phone, chat Multilateral Data Sharing -> FTP, etc.

Different Requirements <=> Different Solutions

Bilateral Data Exchange -> eMail Machine Processing -> XML Publishing Data -> Web Site, Wiki, …

Multilateral Data Sharing -> FTP, etc. Display to Human -> PDF

Cooperation -> Project Place etc.

Why do eHealth architects always asume that a single

health record architecture could serve all needs?

Privacy

Patient in Control

Closed User Group

Consent

Functionality

Spontanous Need

Active Treatment

Usability

Interaction

Data Integration

Privacy

Patient in Control

Closed User Group

Consent

Functionality

Spontanous Need

Active Treatment

Usability

Interaction

Data Integration

No Compromises

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

Patient in Control

Spontanous Need Interaction

Closed User Group

Active Treatment Data Integration

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

Personal Health Record acc.

§

291a SGB V

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?

– Physician->Citizen: I’ve updated your nutrition plan. Here it is.

– Citizen->Physician: Here are last weeks blood glucose values.

Modular Patterns:

• Physican requests Data from Citizen

• Phyician provides Data to Citizen

• Citizen requests Data from Physician

• Citizen provides Data to Physician

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?

– 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?

Modular Patterns:

• Physican requests data (together with

a patient token); PHR provides data

• Physican provides data (together with

Integration Platform

Vaccination Record …

Medication Plan

Semantic Interoperability Framework Interaction

Online Database …

USB Device

Security Modules (Authorization, …)

Communication and Storage Abstraction Layer

Adapter Adapter Adapter

Interaction Patterns

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

– 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:

Electronic Case Records (ECR) / elektronische Fallakte (EFA)

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

– Adaptable to disease/contract-specific care scenarios

Status

– Specifications have been published in 2008

– 10+ pilot projects in different regions

– 2 fully operational networks (Munich, Aachen)

– Product support from industry (Siemens, iSoft, ISPro, CrossCheck)

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

ECR as a Federated System

A u th_e n_t Auth entis ierun g Au_the ntis ieru ng e n tis ie ru n g A u to ri s ie ru n g

ECR Security Architecture (Overview)

Identity Provider ECR Admission Token Service ECR Record Registry Authenticate Users / Assign Attributes Create Admission Codes Discover Patient’s Records Enforce Access Policies ECR Document Registry ECR Access Token Service Assign Access Policies ECR Document Registry ECR Policy Token Service Obtain Access Policies Id e n ti R e ID lic y PatientID RecordID Identity Assertion Admission Assertion Access Assertion ECR Document Repository IDM Policy Assertion tit y / A ttr ib u te s Admission Lists R ec ord Id en tifie_r Acc ess Pol icy ID Policy Registry A c c e s s P o li

Admission Code RecordID PolicyID PolicyID Access Policy UserID Attribute

RecordID Metadata SecretHash

ECR Assertion Chaining

Identity Provider

Admission Token Service

produces produces co n su m e s su m e s identit y assertion admission assertion access assertion efe re n ce re fe re n ce patient Access Token Service

Policy Service produces produces co n s co n su m e s su m e s access assertion

policy assert ion _refe

re n ce re consent w ho? w hat?

ECR Building Blocks

Hospital acting as ECR Provider

ECR Consumer

„ECR in a Box“ Deployment: Full

encapsulation of ECR Security

Create Record

Close Record

Merge Records

Split Records

Update Metadata

Align Purpose

Register Consent

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

Record Management: Logical Operations

Register Consent

Deprecate Consent

Register Episode/Visit

De-Register Episode

Update Episode Metadata

….

Register Document

De-Register Document

Update Document Metadata

– incl. diagnosis-specific Metadata

…

Dedicated service interface per management operation?

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

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

ECR R-MIM

Header

Patient

Initiator

eCR Provider

eCR Object

Contract Docs.

Roles

Care Providers

Body

Contract Docs. Purpose HCP Visits Diagnosis

eCR-V

eCR-specific sections (optional) CAVE Docs.

ECR Visit (Folder) R-MIM

eCR-V

Header

Patient

Care Giver

eCR Object

Diagnosis

Inpatient Visit

eCR-V

Body

Admission Diagnosis Medical Documents Diagnosis eCR-specific sections (optional) Contract Docs.

Nesting of Standards

IHE PCC PHR Update

ECR R-MIM (Subset of CDA R-MIM)

P

ro

vi

d

e

r

In

te

rf

a

ce

C

D

A

P

ro

ce

sso

r

E

C

R

S

e

rvi

ce

s

OMG/HL7 RLUS

SOAP

HTTPS

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:SecurityContext>...</RLUStypes:SecurityContext> <RLUStypes:InitializeContext> <!—visit identifier --> <cda:encompassingEncounter>

<cda:code code="INP„ codeSystem="1.2.276.0.76.3.1.81.81.5.4" /> <cda:id root="..." extension="..."/>

<cda:effectiveTime NullFlavor="UNK" /> </cda:encompassingEncounter>

</RLUStypes:InitializeContext>

ECR Box (Plug & Play Deployment)

Crosscheck Networks

Frans Halslaan nr 9

5143 GJ Waalwijk

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 1st _{challenge is on extensibility and adaptability}

– Disease specific care networks, Quality management, reporting procedures, …

– 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 2nd _{challenge is on EHR/PHR administration and operation}

– The deeper the EHR is integrated with hospital IT the more management