Transcript Document

Key Issues of Technical
Interoperability Solutions
in eHealth
Asuman Dogac
IST-027065 RIDE Project
Outline of the Talk…
 Introduction
to the technical issues
through a scenario
 Demonstration of EHR interoperability


IHE Profiles
CEN 13606 EHR Content Standard
 A brief
Comparison of the EHR standards
 Current practices in EU Member States
 What lies ahead…
Demo Scenario

One sunny day in Malaga, a person in a
meeting experiences a heart attack
From
the nearest hospital an
ambulance is called
Demo Scenario

On the way to the hospital, the paramedic
obtains the demographic information of
the patient from the patient’s citizen card
and sends it to the hospital by using his
mobile device

This operation is actually calling the Admit
Patient Web service of the hospital
Demo Scenario
 The
patient, Dr. Ilias Iakovidis has been
living in Brussels for a long time
 He has had cardiovascular problems and
had some surgeries and treatment at the
Brussels Hospital
 Therefore, his EHR is in the Brussel
Hospital Information system
Demo Scenario

Luckily, there exists a “Common EU EHR Registry/
Repository” which is used by the hospitals in Spain and
in Belgium to store clinical documents of patients
Common EU EHR
Registry/Repository
Brussels Hospital
Malaga Hospital
Brugge Hospital
Barcelona
Hospital
Demo Scenario


The emergency department of Malaga Hospital assigns a new
patient identifier, PID = 10000146
The doctor searches their own hospital information system for
clinical information about the patient

No information about the patient

Then the doctor queries the
Common EU EHR
Registry/Repository
Demo Scenario



Query: Give me the EHRs of the patient with PID =
10000146
Wrong PID; PID is local to Malaga Hospital and we need
the PID in the Common EU Registry/Repository
Solution?
PID Manager
Name: Ilias Iakovidis
BirthDate:
22/03/1967
Malaga
PID=10000146
10000146
Common Rep = ?
Malaga
Hospital
Before requesting
the EHR, find out
Athe
newPID
patient
in the
is admitted
Common
repository
Ilias Iakovidis
22/03/1967
Brussels
Hospital
10001452
Common
Rep/Reg
Malaga
Hospital
Common EU EHR
Registry/Repository
35000489
Demo Scenario



Now the query is using the correct PID
Registry returns document references
Doctor selects the needed ones and the document is
retrieved from the repository
PID = 35000489
doc1.xml
Give me the
document
references
doc2.xml
...
docn.xml
Malaga
Hospital
Common EU EHR
Registry/Repository
doc2.xml
Demo Scenario



The other issue considered in the demonstration is
authentication and audit trails
The repository needs to be sure that Malaga Hospital and
Brussels Hospital are authorized to communicate with it
Also each hospital must be sure that the actor it communicates
with is the real Repository
Allowed
Nodes
Public
Keys
Lock
with
private
key
Common
Rep/Reg
Mutual
Authentication
Allowed
Nodes
The same
process is
repeated on
the other side
Malaga Hospital
Try to unlock with
public key. If it is
opened
everything is OK
Private Keys
Public
Keys
Malaga
Hospital
Brussels
Hospital
Common EU EHR
Registry/Repository
Demo Scenario




Furthermore, audit trail is essential
It is necessary to allow a security officer in a healthcare institution to
audit activities to detect improper creation, access, modification and
deletion of Protected Health Information (PHI)
In our scenario, we have a common audit repository
Each application creates and sends an audit record to this repository
after specified events
Demo Scenario



Both in the node authentication and audit trail, time is very important
since it is a common variable used in the system
Therefore, all applications should have consistent time (Recording
the correct time in audit records, using correct timestamp
authentications)
In our demonstration, all aplications make their time consistent by
asking the time to a common time server
UTC+1
What time
is it?
What time
is it?
Malaga Hospital
10:13:28
10:12:16
UTC+1
Brusells Hospital
09:13:28
10:13:28
10:14:48
Demo: Technologies Used


NIST IHE XDS Registry Repository (common
registry/repository) was available as public domain
software from National Institute of Standards and
Technology (NIST) from USA
On top of this, we have implemented the following
profiles (will be available as public domain software):
- IHE PIX Manager (for patient ID manager)
- IHE ATNA Profile (for node authentication TLS and
audit trails)
- IHE Consistent Time profile (SNTP)
 We have used:


Care2x HIS (a public domain Hospital Information System)
The document content standard is CEN 13606-2000
The Technical Issues Needed to be
Addressed

Communication Protocols:


Most Commonly used is Internet Protocol (IP)
Although IP seems to be common between health applications,
various application protocols exists in the protocol stack of IP
The communication chanels can be:
Hospital A
Hospital B
HTTP
SMTP
FTP
The Technical Issues Needed to be
Addressed

Message Interoperability:




To be able to exchange information among
heterogeneous healthcare information systems,
messaging interfaces (also called interface engines)
are used
Currently, the Health Level 7 (HL7) Version 2
Messaging Standard is the most widely implemented
message interface standard in the healthcare domain
Another one is HL7 v3 standard and there is no well
defined mapping between them
Proprietary messages are also used in the healthcare
domain
Message Interoperability
Interface Engine
Interface Engine
HL7-I12
HL7-I12
Patient Referral
Patient Referral
^
12345
Ilias^ Iakovidis
11011010
Network
12345
Iakovidis
Ilias
Application 1: HIS
Database and back
end applications
Application 2: HIS
Database and back
end applications
Messaging Standards


Various Messaging Standards exists on current communication
protocols; SOAP, ebXML messaging, EDI
The communicating applications on both sides should support the
same messaging standard


Extracting the message payload
Handling the Headers
SOAP
ebXML Messaging
Communicating through Web
Services
HL7- I12
<patient>
<id>
<name>
HL7I12 Referral
Patient
</id>
<patient>
Web Service
<id> 12345 </id>
<name>
Ilias
</name>
<surname>
</name>
<surname>
Iakovidis
</surname>
11011010
</patient>
</surname>
</patient>
HTTP over TCP/IP
12345
Ilias
Iakovidis
EHR Content Interoperability

There are several standards development
efforts such as;




Health Level 7 (HL7) Clinical Document Architecture
(CDA)
CEN EN 13606 EHRcom
openEHR
These standards aim to structure and markup
the clinical content for the purpose of exchange
GEHR/openEHR Initiative

This approach uses a two-level methodology to model
the EHR structure

In the first level, a generic reference model that is
specific to the healthcare domain is developed and
contains only a few classes (e.g. role, act, entity,
participation)

In the second level, healthcare and application specific
concepts such as blood pressure, lab results etc. are
modeled as archetypes, that is, constraint rules that
specialize the generic data structures that can be
implemented using the reference model

EN 13606-2 will be based on Archetypes
CEN/TC 251 and ENV/EN 13606
EHRcom
 A message-based
standard for the
exchange of electronic healthcare records.
 It consists of five parts:





The Reference Model,
Archetype Interchange Specification,
Reference Archetypes and Term Lists,
Security Features, and
Exchange Models (communication protocol).
HL7 Clinical Document
Architecture (CDA)




CDA is organized into three levels where each level
iteratively adds more structure to clinical documents
Level One focuses on the content of narrative
documents with high-level context such as parties, roles,
dates and time, places and structural organization of
headings
Level Two models the fine-grained observations and
instructions within each heading through a set of RIM Act
classes
Level Three specifies semantics each information entity
by a unique code which enables machine processing
IHE Cross-Enterprise Document
Sharing (XDS)

There is also an industry initiative called Integrating the
Healthcare Enterprise (IHE) which specified the CrossEnterprise Document Sharing (XDS) integration profile
for this purpose

The basic idea of IHE XDS is to store healthcare
documents in an ebXML registry/repository architecture
to facilitate their sharing

IHE XDS handles healthcare documents in a content
neutral way
IHE Cross-Enterprise Sharing of
Medical Summaries (XDS-MS)
 XDS-MS
is a mechanism to automate
sharing of Medical Summaries between
care providers.


Medical Summary Types: episodic care,
collaborative care and permanent care
Specifies content as HL7 CDA and Care
Record Summary (CRS)
IHE Retrieve Information for
Display (RID)

RID provides a simple and rapid read-only
access to patient-centric clinical information that
is located outside the user's current application

Supports access to documents with CDA Level
One, PDF and JPG formats

It is defined as a Web service by providing its
WSDL description with a binding to HTTP GET
Summary of
EHR Standards
EHR
Content
EHRcom
HL7 CDA
IHE RID
IHE XDS
A reference
model and the
data structures
for EHR
content are
defined.
CDA is organized into
Three levels: “Level One“
Focuses on the content of
narrative documents; there
is no semantics at this
level; it is only human
readable. Level Two CDA
models the fine-grained
observations and
instructions within each
heading through a set of
RIM Act classes. A
completely structured
document where the
semantics of each
information entity is
specified by a unique code
will only be possible with
“Level Three".
IHE RID profile
does not specify
content; it
supports access
to existing
persistent
documents in
well-known
presentation
formats such as
CDA Level One,
PDF and JPEG.
IHE XDS profile is content
neutral; it does not
specify how content
should be structured and
encoded. However IHE
continues to specify
further profiles and one
recent profile IHE XDS MS
HL7 specifies medical
summaries based on HL7
CDA standard and CRS
CDA implementation
guides
Summary of
EHR Standards
EHRcom
The Message
EHR
Communication package, which
is under
layer
development as
EN 13606-5, will
define how to
communicate
the EHR extract
to a requesting
process.
HL7 CDA
IHE RID
IHE XDS
HL7 CDA does not
define how EHRs can
be communicated;
the specification
states that CDA
documents can be
transmitted in HL7
messages (in OBX
segment) designed
to transfer clinical
documents.
The network and
transport
protocol is
Internet; the
messaging
protocol is Web
services (http
GET).
In IHE XDS, the network
and transport protocol
is Internet; the
messaging protocol is
ebXML messaging
(SOAP with attachments)
over HTTP or SMTP
(email).
OTHER ISSUES IN EHR
INTEROPERABILITY

For EHR interoperability, further technical
issues that must also be addressed include:




Mapping the patient identifiers among different
healthcare applications
Authenticating the users across the enterprises
Guaranteeing that all the computers involved
have consistent time
Authenticating Nodes and Obtaining Audit Trail
eHealth Interoperability in USA
Country Messaging
Infrastructure
Patient Identification
USA
Three different identification
infrastructures are considered in the
NHIN:
- Master Patient Identification Repository:
Both the record and identification is
located on the same regional or
national repository
- Patient Record pointers: Patient
identifiers are located in a national or
regional directory and contain
pointers to real records
- Patient Controlled Identification with
Access Cards: Smart Cards and RFID
tags
Possible technical alternatives for
National Health Information
Network (NHIN) :
- Web Services;
- National Central Repository
- Regional Repositories
- Peer-to-peer network of
Regional Registries containing
pointers to real patient records
- Non-Federated Peer-to-Peer
Networks
eHealth Interoperability in Canada
Country Messaging Infrastructure
EHR Interoperability
Patient Identification
Canada
IHE XDS is considered.
Patient identification is
Handled locally in
regions by using Master
Patient Indexes (MPI).
Canada Health Infoway Project
blueprint specifies:
An EHR Solution (EHRS):
Registry/repository
infrastructure to be used for a
region (IHE XDS; ebXML
registry and Web Services with
HL7 v3 messages).
Furthermore a peer-to-peer
network of EHRS is for seen.
For EHR content Hl7 CDA
and ASTM CCRs are
considered.
These identifiers are
linked together by using
demographics between
regions.
eHealth Interoperability in Australia
Country
Messaging
Infrastructure
Australia Service Oriented
Architecture
(Web Services )
EHR Interoperability
Patient Identification
OpenEHR and archetypes
Medicare Card
HealthConnect event summaries:
Medicare smart card
pathology tests, diagnostic test
is considered for
future.
results, hospital discharge
summaries, chronic illness
monitoring, current medications,
allergies, immunization information,
principal diagnoses
eHealth Interoperability in some of
the EU member states
EU Member
State
Messaging
Infrastructure
EHR Interoperability
Patient Identification
Austria
IHE XDS is
recommended by EHI
(Healthcare Initiative
group)
ELGA Initiative (Lifelong
electronic health record),
ONR 112203 for the
discharge letter
Social Security Number
Web Services and
SOAP
KMEHR-bis (messages for
electronic healthcare
record) 20 specific
XML messages are
produced for key
medical transactions.
Unique national personal
identification number is
used.
Belgium
E-Card is used as carrier.
La carte d’identite
electronique (eID) is
planned as a future carrier.
National database linking
demographics to
İdentification number.
eHealth Interoperability in some of
the EU member states
EHR Interoperability
EU Member
State
Messaging
Infrastructure
Denmark
EDI communication BEHR (Basic Structure
for Electronic Health
Records) Structured,
cross-disciplinary,
process and problem
oriented documentation
standard for EHRs.
Netherlands
HL7 version 3
(HL7v3) with Web
Services (SOAP)
HL7 CDA
Patient Identification
Unique national personal
identification number.
Health insurance cards
as carrier.
National database
linking demographics to
identification number.
Citizen Service Number.
eHealth Interoperability in some of
the EU member states
EU Member
State
Messaging
Infrastructure
EHR Interoperability
Patient Identification
United Kingdom HL7v3 XML
Summary Care Record
Messaging Standard located in a central
national database
named as SPINE.
Personal Demographics
Services (PDS) providing
NHS number.
Estonia
National ID Code
ID Cards (Electronic)
National database linking
demographics to ID Code.
eHealth Interoperability in some of
the EU member states
EU Member Messaging Infrastructure
State
EHR Interoperability Patient Identification
France
Dossier médical
Personnel (DMP):
EHRcom
ebXML messaging (IHE XDS
profile is recommended in
the request for proposal)
Unique National Person
Registration number.
Smart cards (SesamVitale)
Central National database
linking demographics to
identification number.
Germany
SOAP, a German protocol
OSCI (Online Services
Computer Interface), ebXML
Messaging Service (ebMS)
Electronic Health Card
eHealth Interoperability in some of
the EU member states
EU Member State
Messaging Infrastructure
Ireland
National Healthlink project
uses HL7 messages
EHR
Interoperability
Patient Identification
PPS person registration
number
Central National database
linking demographics to
identification number.
Slovenia
EDIFACT, HL7
Health Insurance Card
Sweden
In ePrescription Web
Services are used with
EDIFACT Messages
Unique National Person
Identification number.
Central National database
linking demographics to
identification number.
What Lies Ahead…
 The
RIDE
(http://www.srdc.metu.edu.tr/webpage/projects/ride/)
Project is addressing these issues to
propose possible alternatives
 It will prepare a roadmap for the technical
interoperability of eHealth systems…
 Please
stay tuned…
Thank you very much for
your attention
Any Questions?