Transcript Document

Interoperability in eHealth
Systems
Asuman Dogac, SRDC Ltd.
August 30, 2012
1
It was many and many a year ago…

There were standalone computers…



Then came the networks and the Internet…
Then it became apparent that there would be
huge benefits to be gained if the applications can
talk to one another…
Email is one such application although it is mostly
for human consumption…
August 30, 2012
VLDB 2012
2
What if…

What if Electronic Health Records are widely used and shared?


What if Computerised Physician Order Entry are widely used?


100,000 adverse drug events could be avoided yearly
What if ePrescriptions are widely used?


9 million bed-days could yearly be freed up corresponding to a value
of €3,7 billion
5 million prescription errors could be avoided yearly
What if Chronic Disease Management is used for diabetes
patients?

11,000 diabetic deaths could be avoided every year
Ref: a recent study covering 6 EU countries by realizing
eHealth (epSOS)
To achieve this, you need all the systems working together
seamlessly: interoperability is needed


August 30, 2012
VLDB 2012
3
Outline

Major Interoperability Standards and Profiles in eHealth
 Interoperability Stack





Communication and Transport Layer
Document/Message Layer
Business Process Layer
Profiling
Semantic Interoperability in eHealth

Clinical Terminology Systems
Medical Device Standards
Real Life Uses
 Sharing Electronic Health Records




Monitoring Chronic Diseases


Saglik-Net in Turkey and epSOS in Europe
Patients with Cardiac Implants and Diabetes patients
Secondary use of EHRs in Clinical Research
August 30, 2012
VLDB 2012
4
Two points…

The talk is divided into two main parts:



Description of some of the interoperability standards (which
may not be very thrilling)
Description of some real life uses seems more interesting
It is not “all applied work”; it includes research
August 30, 2012
VLDB 2012
5
Interoperability (Def ’n)
Interoperability with regard to a specific task is said to exist between
two applications when one application can accept data (including data
in the form of a service request) from the other and perform the task
in an appropriate and satisfactory manner (as judged by the user of the
receiving system) without the need for extra operator intervention



Ref: Brown, N. and Reynolds, M. 2000. Strategy for production and
maintenance of standards for interoperability within and between service
departments and other healthcare domains. Short Strategic Study CEN/TC
251/N00-047, CEN/TC 251 Health Informatics, Brussels, Belgium.
This definition implies the following:




The ability to communicate data (connectivity)
The data received by the receiving system is sufficient to perform the task
and
The meaning attached to each data item is the same as that understood by
the creators and users of the sending and receiving systems
The task is performed to the satisfaction of the user of the receiving system
August 30, 2012
VLDB 2012
6
Interoperability and Standards

Interoperability is possible by conforming to
standards

Otherwise an application wishing to communicate
with n different applications must develop that many
different interfaces
August 30, 2012
VLDB 2012
7
The nice thing about standards is that there are so
many to choose from !
August 30, 2012
VLDB 2012
8
Some of the Main Standard Bodies in
eHealth

HL7 (Health Level Seven)




Integrating the Healthcare Enterprise (IHE)




Founded in 1987
A non-profit, ANSI accredited Standards Developing Organization
Provides standards for the exchange, management, and integration of data
that supports clinical patient care and the management, delivery, and
evaluation of healthcare services
Founded in 1998 in the USA by the Radiological Society of North America
(RSNA) and the Healthcare Information and Management Systems Society
(HIMSS)
A not-for-profit initiative
The goal is to stimulate integration of healthcare information resources
CEN/TC 251


The technical committee on Health Informatics of the European Committee
for Standardization
Its mission is to achieve compatibility and interoperability between
independent health systems
August 30, 2012
VLDB 2012
9
Messages vs. Documents in Healthcare IT

Messages





They support an ongoing process in a real-time fashion
They drive activities and may trigger further events
They use the latest version of the data to support an ongoing
process
They are consumed to realize that event
Documents





They have “static” content and have to be persisted
They tend to be used “post occurrence”, i.e. once the actual process
is done
They are "passive“
They capture information and allow that information to be shared,
but do not themselves drive any activity
They are self contained such as an Electronic Health Record (EHR)

August 30, 2012
EHRs are documents also for medico-legal reasons: a medical
professional takes the responsibility for the information contained in it
VLDB 2012
10
HL7 Message Standards


The HL7 standard is developed with the assumption that an
event in the healthcare world, called the trigger event, causes the
exchange of messages between a pair of applications
When an event occurs in an HL7-compliant system:





An HL7 message is prepared by collecting the necessary data from
the underlying application systems and
It is passed to the requestor, usually as an EDI (Electronic Data
Interchange) message
For example, a trigger event, called ADT^A01 (admission/ discharge/
transfer—admission of an inpatient into a facility), occurs when a
patient is admitted to a facility
This event may cause the data about the patient to be collected and
sent to a number of other application systems
Currently, there are two message protocols supported by HL7,
Version 2 and Version 3
August 30, 2012
VLDB 2012
11
HL7 Message Standards


HL7 Version 2 Messaging Standard is the most widely implemented
standard for healthcare information in the world today
However, Version 2 messages have no precisely defined underlying
information model;







The definitions for many data fields are rather vague, and
There are a multitude of optional data fields
Being HL7 Version 2-compliant does not imply direct interoperability
between healthcare systems
This optionality provides great flexibility but necessitates detailed
bilateral agreements among the healthcare systems to achieve
interoperability
To remedy this problem, HL7 developed Version 3 which is based on an
object-oriented data model called Reference Information Model (RIM)
Up to the current Version 2.5, the scope of the HL7 standard was
limited to the exchange of messages between medical information
systems
Starting with Version 3.0, a document markup standard, called the
Clinical Document Architecture (CDA), is proposed
August 30, 2012
VLDB 2012
12
Exchanging HL7 messages…
Interface Engine
Interface Engine
HL7-I12
HL7-I12
Patient Referral
Patient Referral
^
12345
john ^ smith
11011010
Network
12345
smith
(e.g., VAN)
john
Application 1: HIS
Database and back
30, 2012
endAugust
applications
VLDB 2012
Application 2: HIS
Database and back
end applications13
Interoperability Stack
August 30, 2012
14
Interoperability Stack…



Interoperability involves not a single standard but a
collection of standards addressing different layers in the
interoperability stack
There are several alternative standards to be chosen
from for each layer
Some standards specify a range of standards for a layer


E.g., HL7 v3 provides a number of normative specifications for the transport
layer such as ebMS or Web services
Profiling avoids this problem by fixing the combination of
the standards and even further restricting them to provide
interoperability



Integrated Healtcare Enterprises (IHE)
HITSP in USA for NHIN
Ministry of Health, Turkey for NHIS
August 30, 2012
VLDB 2012
15
15
INTEROPERABILITY STACK
Interoperability Stack
Document Layer
Business Process
Layer
Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA,
EHRCom, ...
Non-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical
Imaging)
Terminologies/Coding Systems: LOINC, SNOMED, ...
Business Rules (e.g by using schematrons)
Specifications with Diagrams: e.g. IHE(Actor/Transaction
Diagrams,Sequence Diagrams) , HL7 (Sequence Diagrams)
Choreography/Business Process Standards: WSCDL, ebBP
Communication
Layer
Quality of Service Protocols: WS-Reliability, WS-Security, WS-Addresing
Higher Level Messaging Protocols: SOAP, ebMS, ...
Transport Protocols: HTTP, SMTP, MLLP, ...
16
August 30, 2012
VLDB 2012
16
Health Level 7 (HL7) Message Standards


HL7 v2.x
 At the document layer, it defines the contents of messages with a lot of
optional fields which provides flexibility but reduces interoperability
 It recommends several protocol alternatives for the communication layer
such as “Minimal Lower Layer Protocol (MLLP)” based on TCP/IP
HL7 v3



Defines a generic structure to express the concepts in a domain, called
“Reference Information Model (RIM)”
This generic RIM is then refined to subdomains and later to specific domain
concepts
For example, the HL7 RIM can be specialized into:




It recommends several protocol alternatives for the communication layer




“CDA” for expressing clinical documents,
“Clinical genomics” for expressing clinical and personalized genomics data, and
“Claims and reimbursement” for handling claims and reimbursements
ebXML Message Specification Profile
Web Services Profile
TCP/IP based Minimal Lower Layer Protocol Profile
There are sequence diagrams to describe the choreography of the
interactions
August 30, 2012
VLDB 2012
17
Some Document Standards…

HL7 v3 Clinical Document Architecture (CDA)


openEHR



Has a reference model and uses openEHR archetypes to constrain them
ASTM Continuity of Care Record (CCR)



First, a generic reference model that is specific to the healthcare domain
which contains a few classes (e.g., role, act, entity, participation)
Then healthcare and application-specific concepts such as blood pressure,
lab results are modeled as archetypes, that is, constraint rules that specialize
the generic data structures
ISO/CEN 13606-1


Defines the structure and semantics of medical documents for the purpose
of exchange in Extensible Markup Language (XML)
Defines a core data set for the most relevant administrative, demographic,
and clinical information facts about a patient’s healthcare, covering one or
more healthcare encounters
Contains various sections such as patient demographics, insurance
information, diagnosis and problem list, medications, allergies and care plan
All these standards, except CCR, define quite generic structures
such as folder, section, entry that can be used to represent any
kind of clinical statement
August 30, 2012
VLDB 2012
18
Content Templates..

Document standards are not enough for interoperability because there
can be many different ways of organizing the same clinical information
even when the same EHR content standard is used:


Therefore, the templates/archetypes are necessary to constrain the
structure and format of generic EHR content standards



The same information can be expressed through different components and
these components can be nested differently
For example, IHE defines several content templates such as Discharge
Summary, Medical Summary or PHR Extract
As another example, Continuity of Care Document (CCD) is defined by
constraining HL7 Clinical Document Architecture (CDA) with
requirements set forward in CCR
However, overlapping coding systems as well as the structural
differences in document templates create semantic interoperability
problems :


Different code systems used by different healthcare applications in the same
compositional structure within the same document template;
Different compositional structures within the same document template that
express the same meaning differently
August 30, 2012
VLDB 2012
19
An Example to Interoperability Problems of Content
Templates
August 30, 2012
VLDB 2012
20
Interoperability Stack
INTEROPERABILITY STACK
Integration
Profiles
Document Layer
Business Process
Layer
(e.g. IHE in eHealth
Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA,
or NES UBL in
EHRCom, ...
eBusiness)
Non-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical
Imaging)
Terminologies/Coding Systems: LOINC, SNOMED, ...
or
Business Rules (e.g by using schematrons)
Specifications with Diagrams: e.g. IHE(Actor/Transaction
Diagrams,Sequence Diagrams) , HL7 (Sequence Diagrams)
Choreography/Business Process Standards: WSCDL, ebBP
Communication
Layer
Technical
Specification
s
(National or
Regional Health
Quality of Service Protocols: WS-Reliability, WS-Security, WS-Addresing Networks:
e.g. USA NHIN,
Higher Level Messaging Protocols: SOAP, ebMS, ...
NICTIZ, SaglikNET)
Transport Protocols: HTTP, SMTP, MLLP, ...
21
August 30, 2012
VLDB 2012
21
Semantic Interoperability in
eHealth
August 30, 2012
22
Semantic Interoperability in eHealth

Ability for information shared by systems to be understood
through formally defined domain concepts





In medicine, the clinical information is coded with “controlled
vocabularies” or “terminologies” to express semantics, i.e., the
meaning of the terms used
For example, the observation for a patient can be expressed as a
“heart attack” or a “myocardial infarction”, and these mean the same
thing to medical professionals
But unless the term is associated with a unique code from a code
system, automated processing of the exchanged term is very difficult
because an application, programmed to use “heart attack”, would not
understand “myocardial infarction”
When a term from medical terminology system is used such as
SNOMED CT and the code 22298006 for “Myocardial infarction”, the
automated meaning exchange is possible
Different coding systems used by data exchanging applications
causes semantic interoperability problems
August 30, 2012
VLDB 2012
23
Classification of Terminology Systems

The terminology systems can be classified based on
how they express the semantics of the relationships
between the coded terms:



Some are plain code lists, for example RxNorm
Some are organized into a hierarchy, for example ICD-10
and hence give the parent-child information among the
terms;
Some express the relationships between the coded terms
through ontological constructs, for example SNOMED CT
or semantic networks like Unified Medical Language
System (UMLS)
August 30, 2012
VLDB 2012
24
SNOMED CT (Systematized Nomenclature of
Medicine -- Clinical Terms)

SNOMED CT (http://www.ihtsdo.org/snomed-ct/) is a computer
processable collection of medical terminology covering most
areas of clinical information such as









Diseases,
Findings,
Procedures,
Microorganisms, and
Pharmaceuticals
It is the most comprehensive clinical vocabulary
It is developed in native description logics (DL) formalism
It contains approximately 350,000 active concepts, more than
one million terms (incl. synonyms) and about 1.5 million relations
between the concepts
SNOMED CT crossmaps to other terminologies such as ICD-10
and LOINC as well
August 30, 2012
VLDB 2012
25
Terminology Mappings




Terminology mappings are needed for semantic
interoperability in eHealth
Currently, several sources provide terminology system
mappings
UMLS (http://www.nlm.nih.gov/research/umls/) contains
more than 60 families of biomedical vocabularies
together with context and inter-context relationships
among them
BioPortal (http://bioportal.bioontology.org/), contains
ontological representations of more than 290 terminology
systems and their mappings
August 30, 2012
VLDB 2012
26
The Unified Medical Language System (UMLS)

It is a compendium of many controlled vocabularies


Provides a mapping structure among these vocabularies and thus
allows one to translate among the various terminology systems
UMLS Building Blocks

Knowledge Sources


Metathesaurus

Defines concepts and mappings to source vocabularies

It links alternative names and views of the same concept and
identifies useful relationships between different concepts
Semantic Network



A consistent categorization of all concepts represented in the
Metathesaurus and provides a set of useful relationships between these
concepts
For example, Addison’s Disease’s Semantic Type is “Disease or
Syndrome”, and there is a “causes” relationship between “Virus” and
“Disease or Syndrome” Semantic Types
Knowledge Source Server

August 30, 2012
Internet access to knowledge sources by browser or web service API
VLDB 2012
27
Metathesaurus Sources


The Metathesaurus comprises over 1 million biomedical
concepts and 5 million concept names, all of which stem from the
over 100 incorporated controlled vocabularies and classification
systems
Built from electronic versions of many different controlled
vocabularies









Thesauri, e.g., MeSH
Statistical Classifications, e.g., ICD-9, ICD-10, ICPC
Billing Codes, e.g., CPT, CPT Spanish version, HCPCS
Clinical Coding Systems, e.g., SNOMED, Read
Nursing Vocabularies, e.g., NIC, NOC, OMAHA
Alternative/Complementary Medicine: ALTLINK
Drug Sources: Multum, Micromedex, VANDF
Drug Regulatory, e.g., MedDRA
Lists of controlled terms, e.g., COSTAR, HL7 Arden Syntax
August 30, 2012
VLDB 2012
28
An Example: Terms in the UMLS for
“Addison’s disease” Concept CUI C0001403
Term Name
Source
Vocabulary
Addison’s disease
SNOMED CT
Code in the
Source
Vocabulary
363732003
Addison’s Disease
MedlinePlus
T1233
Addison Disease
MeSH
D000224
Bronzed disease
Primary Adrenal
Insufficiency
Primary hypoadrenalism
syndrome, Addison
SNOMED Intl
DB-70620
August 30, 2012
MeSH
MedDRA
VLDB 2012
D000224
10036696
29
A part of UMLS Semantic Network
August 30, 2012
VLDB 2012
30
Interoperability of Terminology Systems

To achieve interoperability among terminology
systems





Not only the mapping information between them
But also the semantic relationships among the terms (or,
concepts) in a terminology system are necessary
Because this helps discovering the implicit equivalences
between two terms from different terminology systems
by using reasoning
However, the automated mappings cannot be fully
reliable
Therefore, continuous involvement of terminology
experts and health care professionals in this process is
necessary
August 30, 2012
VLDB 2012
31
An Example



Assume a patient’s acute heart failure condition is expressed
with SNOMED CT code 56675007 in a clinical document
Receiving application understands only the MedDRA terminology
system
Through reasoning, it is possible to discover that the equivalent
MedDRA code is 10019279 for “heart failure”
SNOMED CT
Heart Failure
84114007
Equivalent
class
MEDRA
Heart Failure
10019279
subclass
SNOMED CT
Acute heart failure
56675007
August 30, 2012
VLDB 2012
32
Semantic Mediation !
August 30, 2012
VLDB 2012
33
An Example to How Some of the
Mentioned eHealth Standards Used
in Practice
Sağlık-Net: The National Health
Information System (NHIS), Turkey
August 30, 2012
34
National Health Information System of
Turkey (NHIS-T)





National Health Information System of Turkey (NHIS-T) is a
nation-wide infrastructure for sharing patients’ electronic health
records (EHRs)
The NHIS-T became operational on January 15, 2009
By Feb. 2012, 98% of the public hospitals and 60% of the private
and university hospitals were connected to NHIS-T with daily
feeds of their patients’ EHRs
Out of 74 million citizens of Turkey, electronic healthcare records
of 60 million citizens have already been created in NHIS-T
As of Feb. 2012, there are 661 million EHRs in the system
 ~ 427 million Observation records
 ~ 110 million Mouth and Teeth examination records
 ~ 21 million In-patient records
August 30, 2012
VLDB 2012
35
Collecting EHRs
NHIS, Turkey
Private Hospitals
Public Hospitals
University
Hospitals
General
Practitioner
(Family
Medicine
Information
System
August 30, 2012
VLDB 2012
36
The National Health Data Dictionary
(NHDD)

The National Health Data Dictionary (NHDD) is developed to
enable the parties to share the same meaning of data

46 Minimum Health Data Sets (MHDS) and 261 data elements
Some data elements








August 30, 2012
Address
Name
Main Diagnosis
Vaccination
Treatment Method
Diastolic Blood Pressure
Healthcare Institution
Marital Status
Some MHDSs






VLDB 2012
Citizen/Foreigner Registration
MHDS
Medical Examination MHDS
Prescription MHDS
Pregnant Monitoring MHDS
Cancer MHDS
Inpatient MHDS
37
August 30, 2012
VLDB 2012
38
An Example Transmission Schema
(“Examination”)
August 30, 2012
VLDB 2012
39
NHIS, Turkey Overview

Content Layer





HL7 CDA is used as the EHR content format
CDA sections correspond to Minimum Health Data Sets (MHDSs)
The MHDSs use the data elements from the National Health Data
Dictionary (NHDD)
Turkish Citizen Numbers are used as patient identifiers
Communication Layer

HL7 Web services Profile with WS-Security over SSL
August 30, 2012
VLDB 2012
40
NHIS “Transmission Schemas”

Healthcare Professional Identifiers: Checked from the
Doctor Data Bank

http://sbu2.saglik.gov.tr/drBilgi/

Patient Identifiers: Citizen numbers are used and
checked from the MERNIS database

Codes used: Checked from the National Health Coding
Reference Server

http://ky.sagliknet.saglik.gov.tr/SKRS2_Listesi

Security and Privacy: Various view mechanisms to hide the
patient demographics information

Business rules: Checked with Schematron rules
August 30, 2012
VLDB 2012
41
Healthcare Professional Registry

Ministry of Health is authorized to provide the work licenses to
the physicians in Turkey

The diploma/specialty information of the medical professionals is
recorded together with their Turkish citizenship numbers in the
Doctor Data Bank (DDB)

As of October 2007, there are 162,446 registered doctors in the
data bank

The Doctor Data Bank is for checking the validity of the
healthcare professional identity in the “Transmission Schema”

Later it will be used authorizing access to the EHRs of the
patients
August 30, 2012
VLDB 2012
42
25 HL7 Web Services for Transporting EHRs











“15–49 Age Female Observation”
“Mouth and Teeth Examination”
“Vaccine Notification”
“Infant Nutrition”
“Infant Observation”
“Infant Psychosocial Observation”
“Communicable Disease Definite
Case Notification”
“Communicable Disease Probable
Case Notification”
“Diabetes”
“Dialysis Notification”
“Dialysis Observation”
August 30, 2012
VLDB 2012














“Birth Notification”
Pregnant Observation”
“Pregnancy Termination”
“Pregnant Psychosocial
Observation”
“Patient Demographics Notification”
“Cancer”
“Puerperal Observation”
“Examination”
“Death Notification”
“Test Result”
“Citizen/Foreigner Registration”
“Stateless Person Registration”
“Newborn Registration” and
“Inpatient”
43
Validation of the Messages by the NHIS
Valid Codes from National Code
Reference Server?
WS SOAP
Valid SOAP message?
Valid use of WS-Security User Name
Token Profile?
Valid Business rules?
(‘Activity Time
HL7-V3
should be less<patient>
than the system
time.)
<id>
</id>
<given>
Valid Patient-Identifier? </given>
<family>
</family>
Valid Physician-Identifier?
</patient>
Valid HL7 CDA Schema?
11011010
Internet
Observation
Service
12345
NHIS
Yılmaz
Ahmet
HIS of Hospital A
August 30, 2012
VLDB 2012
44
Handling Security and Privacy





There are two types of administrators in the system:
 Security Administrator is in charge of granting rights to the
Database Administrators but they themselves have no right to
access the database
Various “View” mechanisms are developed to hide the patient
demographics data from the unauthorized users
The MoH has selected Oracle Identity Management System
Access to NHIS data is audited by logging all the user events
Currently the work is going on for determining the legal ground
about the access rights of various types of users
August 30, 2012
VLDB 2012
45
Decision Support System
Child mortality rate under the age of 12 months in Bilecik?
Number of diarrhea incidents in Istanbul during the last three days?
Number of cancer incidents during last year in all of the
provinces of Turkey?
Decision
Support
System
NHIS
August 30, 2012
VLDB 2012
46
Note..



In Turkey, although the EHRs are collected, they are
shared only with General Practitioners but not with
the physicians in the secondary and tertiary care
This is because there is a need for a consent
mechanism for the patients
The next step is to allow sharing of EHRs not only
with authorized medical practitioners but also with
the patients themselves

Through a Personal Health Record system, called,
eSaglikKaydim
August 30, 2012
VLDB 2012
47
Personal Health Record Systems


The Personal Health Record (PHR) systems have evolved from
Web pages where patients entered their own data manually
Currently, they are classified as:





Provider-tethered PHR system: Data from a medical provider’s
healthcare information system is entered into the PHRs
automatically
Payer-tethered PHR systems provide patients access to claims data
Third party PHR systems such as Microsoft HealthVault that
provides a secure storage for PHR data together with data exchange
interfaces so that third parties can develop applications to upload
patient data, for example, home health devices
Interoperable PHR systems, on the other hand, represent a future
type of PHR in which all entities have access to data
A recent report by Google, HIMSS, Kaiser Permanente and
Microsoft concludes that from the perspective of the healthcare
system, interoperable PHRs provide the greatest value
August 30, 2012
VLDB 2012
48
August 30, 2012
VLDB 2012
49
August 30, 2012
VLDB 2012
50
August 30, 2012
VLDB 2012
51
August 30, 2012
VLDB 2012
52
August 30, 2012
VLDB 2012
53
August 30, 2012
VLDB 2012
54
August 30, 2012
VLDB 2012
55
August 30, 2012
VLDB 2012
56
August 30, 2012
VLDB 2012
57
Factors Affecting the Success of NHIS,
Turkey


The Ministry of Health, being the national authority to decide on
the eHealth standards in Turkey, was able to enforce the
standards that have led to their fast adoption
Building a national common data dictionary consisting of eHealth
data elements and minimum health data sets has helped to





Identify clearly the meaning of data elements;
Giving their explanation in the local language and, more importantly,
Making it possible to share and re-use these components
Finally, the comprehensive testing, especially the conformance
and interoperability testing of vendor-based hospital information
systems contributed to the fast integration of the majority of the
65 HIS vendors in Turkey
Note however that while addressing the national level EHR
interoperability may be relatively easy, it is much more difficult to
do this in an international environment
August 30, 2012
VLDB 2012
58
Related Publications

Although this is applied work, it also involved research:






Asuman Dogac, Mustafa Yuksel, et. al.,”Electronic Health Record Interoperability
as Realized in Turkey’s National Health Information System”, Methods of
Information in Medicine, Vol. 50, No. 2, March 2011, pp. 140–149.
Namli, T., Dogac, A., “Testing Conformance and Interoperability of eHealth
Applications”, Methods of Information in Medicine, Vol. 49, No.3, May 2010,
pp. 281–289.
Namli T., Aluc G., Dogac A., “An Interoperability Test Framework for HL7 based
Systems”, IEEE Transactions on Information Technology in Biomedicine
Vol.13, No.3, May 2009, pp. 389-399.
Namli T., et. al., “Testing the Conformance and Interoperability of NHIS to Turkey’s
HL7 Profile”, 9th International HL7 Interoperability Conference (IHIC) 2008,
Crete, Greece, October, 2008, pp. 63-68.
Kabak Y., Dogac A., et. al., “The Use of HL7 CDA in the National Health
Information System (NHIS) of Turkey, 9th International HL7 Interoperability
Conference (IHIC) 2008, Crete, Greece, October, 2008 pp. 49-55.
Eichelberg M., Aden T., Riesmeier J., Dogac A., Laleci G., “A Survey and Analysis
of Electronic Healthcare Record Standards”, ACM Computing Surveys, Vol. 37,
No:4, December 2005.
August 30, 2012
VLDB 2012
59
Some Other Related Publications







ARTEMIS: An Infrastructure for the Interoperability of Medical Information Systems,
Healthcare IT Management Journal, Volume 1, Issue 2, Summer 2006, pp.26-27.
“Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain”,
Information Systems Journal (Elsevier), Volume 31, Issues 4-5, June-July 2006, pp.321339
Collaborative Business Process Support in IHE XDS through ebXML Business Processes,
In proc. of International Conference on Data Engineering (ICDE2006)
Exploiting ebXML Registry Semantic Constructs for Handling Archetype Metadata in
Healthcare Informatics, International Journal of Metadata, Semantics and Ontologies,
Volume 1, No. 1, 2006.
The Need for Semantic Web Service in the eHealth, W3C workshop on Frameworks for
Semantics in Web Services
Archetype-based Semantic Interoperability of Web Service Messages in the Healthcare
Domain, Int'l Journal on Semantic Web & Information Systems, Vol. 1, No.4, October
2005, pp. 1-22.
Artemis Message Exchange Framework: Semantic Interoperability of Exchanged
Messages in the Healthcare Domain, ACM Sigmod Record, Vol. 34, No. 3, September
2005
August 30, 2012
VLDB 2012
60
Some example Integrating Healthcare
Enterprise (IHE) Profiles
August 30, 2012
61
IHE Retrieve Information for Display (RID)


IHE RID provides provides read-only access to patientcentric clinical information that is located outside the user’s
current application
Standards Used:




Web Services (WSDL for HTTP Get).
General purpose IT Presentation Formats: XHTML, PDF, JPEG, CDA L1
Client may be off-the-shelf browser or display application.
Two services:

Retrieve of Specific Information:




Patient centric: patient ID
Type of Request (see next slide)
Date, Time, nMostRecent
Retrieve a Document



August 30, 2012
Object Unique Instance Identifier (OID)
Type of Request
Content Type Expected
VLDB 2012
62
IHE Retrieve Information for Display
Persistent Document
Types of Requests
•Summary of All Reports
•Summary of Laboratory Reports
•Summary of Radiology Reports
•Summary of Cardiology Reports
•Summary Retrieve
of Surgery
Reports
Specific
Info for Display
Document
for Display
•Summary Retrieve
of Intensive
Care Reports
•Summary of Emergency Reports
•Summary of Discharge Reports
•List of Allergies
IHE-RID WSDL
•List of Medications
<?xml version="1.0" encoding="utf8"?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:s0="http://rsna.org/ihe/IHERetrieveForDisplay"
targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types> <s:schema elementFormDefault="qualified"
targetNamespace="http://rsna.org/ihe/IHERetrieveForDisplay">
<s:simpleType name="summaryRequestType">
<s:restriction base="s:string">
<s:enumeration value="SUMMARY" />
<s:enumeration value="SUMMARY-RADIOLOGY" />
…………
August 30, 2012
VLDB 2012
63
IHE XDS – Cross Enterprise Document
Sharing


XDS is IHE’s first step towards the longitudinal dimension of the EHR (“from
cradle to grave”)
Focus: Support document sharing between EHRs in different care settings
and organizations





Clinical Affinity Domains (like the RHIOs in the States)
One registry (ebXML) to store the metadata of the documents
One or several repositories where documents are actually stored
IHE-XDS is content neutral
Design Premises:
 Organisations that decide to share clinical documents form a group that
is called a “Clinical Affinity Domain”, which has to




August 30, 2012
Establish common a patient ID management scheme (MPI)
Define a common set of meta data and permitted content formats
Define a common set of policies
Share a single metadata registry
VLDB 2012
64
IHE XDS Transaction Diagram
Patient
Ide ntity Source
Patient Ide ntity
Feed
Document
Registry
Query
Documents
Document
Consumer
Register
Document Set
Document
Source
August 30, 2012
Provide&Register
Document S et
Document
Repository
VLDB 2012
Retrieve
Document
65
IHE XDS

Business Process Layer: There are five actors in this profile








Document Source Actor submits an EHR with the “Provide and
Register Document Set” transaction to the Document Repository
Document Repository contains the EHRs and registers the metadata
of the documents to the Document Registry with “Register Document
Set” transaction
Document Registry contains the metadata of the documents
Patient Identity Source aligns the different Patient IDs
Document Consumer queries the registry with “Query Documents”
transaction with metadata to obtain the pointer to the EHR in the
Document Repository
Document Consumer uses the “Retrieve Document” transaction to
obtain the document from the Document Repository using the
pointer
Document Layer: To be decided by each Clinical Affinity Domain
(CDA, pdf,…)
Communication Layer: ebXML Registry specification 3.0 (MTOM
based Web services)
August 30, 2012
VLDB 2012
66
An Example to How IHE
Profiles are Used in Practice
epSOS - European Patients Smart open Services
August 30, 2012
70
Exchanging Patient Summaries and
ePrescriptions in Europe: The epSOS initiative
• Different languages
• Different eHealth processes
• Different grade of development
• Different Legislation
• Different concepts
• No European Nomenclature for
Medicines
August 30, 2012
VLDB 2012
71
The epSOS participating nations
August 30, 2012
VLDB 2012
72
The epSOS Solution


Patient Summary for European Citizens
ePrescription service for European Citizens



The content templates for the three document types





ePrescribing is the electronic prescribing of medicine using software
to transmit the prescription data to the pharmacy where it is being
retrieved
eDispensing is the electronic retrieval of an ePrescription, the
dispensing of the medicine to the patient and the submission of an
electronic report for the medicine dispensed
Patient summary,
ePrescription and
eDispensation
These pivot documents to be exchanged are defind by using and
further restricting IHE PCC templates
Each country defines its own mapping from its national data
structures onto these pivot document schemas
August 30, 2012
VLDB 2012
73
Important Standards Used in epSOS

Content models for Patient Summary, ePrescription and
eDispensation documents




Clinical Terminology Systems


ICD-10, SNOMED CT, LOINC, ATC, …
Interoperability Profiles




HL7 Clinical Document Architecture – CDA v2
HL7/ASTM Continuity of Care Document (CCD) Content templates
Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC)
Content templates
IHE Cross-Community Patient Discovery (XCPD) profile
IHE Cross-Community Access (XCA) profile
IHE Cross-Enterprise Document Reliable Interchange (XDR) profile
Security



IHE Cross-Enterprise User Assertion (XUA) profile
IHE Audit Trail & Node Authentication (ATNA) profile
…
August 30, 2012
VLDB 2012
74
The epSOS Solution

For the coded representation of clinical content within these schemas,
subsets from existing terminology systems are used







epSOS Master Value Sets Catalogue (MVC) is created
The latest version 1.7 of MVC contains 46 value sets
For example,



SNOMED CT,
ICD-10,
LOINC,
ATC, …
The procedures value set contains 102 terms from SNOMED CT and
Illnesses and disorders value set contains 1685 terms from ICD-10
Each epSOS participating nation provides


Mapping of any locally used terminology system to MVC content and also
Translation of the MVC content into its own language, resulting in the epSOS
Master Translation/Transcoding Catalogue (MTC)
August 30, 2012
VLDB 2012
75
The epSOS Solution
PDF as “printable” representation
of the original data
Structured Document based on
HL7 CDA R2 with coded entries
Worldwide recognized HL7 CDA
templates (HL7 CCD; IHE PCC)
August 30, 2012
PDF embedded in an unstructured
HL7 CDA R2 document
VLDB 2012
76
Redundant Coded Data Elements for Safety
Country A
Data
Pivot Document
In Country A
Pivot Document
In Country B
C-A Code
C-A Display name
C-A Code
C-A Display name
epSOS Code
epSOS English
Display name
C-A Code
C-A Display name
epSOS Code
epSOS English
Display name
epSOS C-B lang.
Display name
@
@
Local Terminology Repository
(based on epSOS Reference Terminology [MVC, MTC])
August 30, 2012
VLDB 2012
77
Semantic Transformation
Transcoded & Translated item
Document Consumer NCP
C-A Code
C-A Display Name
C-A
Code System OID
epSOS English
Display Name
epSOS
Code System OID
epSOS Code
C-B Display name
August 30, 2012
<value xsi:type='CD‘
codeSystemName="ICD-10"
displayName="Astım"
codeSystem=“1.3.6.1.4.1.12559.11.10.1.3.1.44.2 "
code="J45" >
<translation
displayName="Asthma” >
<translation
code="493.0“
displayName="ASMA“
codeSystem="2.16.840.1.113883.6.103"
codeSystemName="ICD-9CM" />
</translation>
</value>
VLDB 2012
78
Patient Summary ‘Basic dataset’ (excerpt)
Mainly based on the IHE PCC Section Content modules (derived by the HL7 CCD)
Information/dataset
Contains
Patient Identification
Unique identification for the patient in that country.
Patient Personal
information
Full name.
Date of birth
Gender
Allergies
Allergy description and agent
Preferred HCP/Legal
organization to contact
Name of the HCP/name of the legal organization
Medical Alerts
Other alerts not included in allergies (e.g. intolerance to captopril because of cough)
List of current problems
Problems/diagnosis that fit under these conditions: conditions that may have a chronic or
relapsing course, conditions for which the patient receives repeat medications and conditions
that are persistent and serious contraindications for classes of medication
Medical Devices and
implants
Includes devices as cardiac pacemakers, prosthesis etc that are important to know by the
HCP
Major Surgical Procedures
in the past 6 months
Major Surgical Procedures
Medication Summary
Current medications
Country
Name of Country A
Date of creation of PS
Data on which PS was generated
August 30, 2012
VLDB 2012
79
epSOS Master Value-set Catalogue: > 9000


















Active ingredients: full ATC
Adverse Event Type: SNOMED CT (9 codes)
Allergies without Drugs: SNOMED CT (84 codes)
Blood Group: SNOMED CT (12 codes)
Blood Pressure: LOINC (2 codes)
CodeNoMedication: SNOMED CT (3 codes)
CodeProb: SNOMED CT (7 codes)
Confidenciality: HL7 Confidenciality (7 codes)
Country: ISO 3166-1
Document Title: LOINC (3 codes)
Dose form: EDQM (490 codes)
EntityNamePartQualifier: HL7 (11 codes)
Gender: HL7 administrative gender (3 codes)
HCP: International Standard Classification of Occupations (ISCO) (8 codes)
IHEActCodeVocabulary: IHE (8 codes)
IHERoleCodeVocabulary: IHE (4 codes)
IllnessesandDisorders: ICD10-WHO-en (1685 codes)
…
August 30, 2012
VLDB 2012
80
IHE Cross-Community Access (XCA) profile





XDS provides cross-enterprise access by forming “affinity domains” like the
RHIOs in the USA whereas XCA provides access across such communities
The Cross-Community Access profile allows to query and retrieve patient
relevant medical data held by other communities
There are two new Actors: Initiating Gateway and Responding Gateway
All the communication between communities goes through these Actors
A community is identifiable by a globally unique id called the
homeCommunityId

It is used in XCA to obtain the Web Services’ endpoints that provide access
to data in that community
Initiating
Community
Cross-Gateway
Query
Initiating
Gateway
August 30, 2012
Responding
Community
Cross-Gateway
Retrieve
VLDB 2012
Responding
Gateway
81
IHE Cross-Community Patient Discovery
(XCPD) profile



Locate communities which hold patient relevant health data
Translation of patient identifiers across communities holding the
same patient’s data
A community is identifiable by a globally unique id called the
homeCommunityId
Initiating
Community
Cross-Gateway
Patient Discovery
Initiating
Gateway
August 30, 2012
Responding
Community
Patient Location
Query
VLDB 2012
Responding
Gateway
82
IHE Cross-Enterprise Document Reliable
Interchange (XDR) profile




Permits direct document interchange between healthcare IT systems
without the need of a document sharing infrastructure such as XDS Registry
and Repositories.
Transfer is direct from source to recipient, no repository or registry actors
are involved
XDR is document format agnostic, supporting the same document content
as XDS and XDM
It uses XDS metadata with emphasis on patient identification, document
identification, description, and relationships.
Document
Source
August 30, 2012
Provide and
Register Set
transaction-b
VLDB 2012
Document
Recipient
83
Use of IHE Profiles in epSOS
NCP-B
(country of care)
NCP-A
(country of affiliation)
epSOS Identification Service consumer
XCPD
Initiating Gateway
epSOS Identification Service provider
Demographics Query
epSOS Patient Service consumer
XCA
Initiating Gateway
epSOS Patient Service provider
Cross-Gateway Query
with Returned Documents
epSOS Order Service consumer
epSOS Dispensation Service provider
Provide and Register Document Set
epSOS Consent Service consumer
August 30, 2012
XCA
Responding Gateway
epSOS Order Service provider
epSOS Dispensation Service consumer
XDR
Document Source
XCPD
Responding Gateway
XDR
Document Recipient
epSOS Consent Service provider
VLDB 2012
84
Medical Device Interoperability
August 30, 2012
85
Medical Device- Healthcare Application
Interoperability Standards


Personal medical devices are essential to the
practice of modern health care services
The prominent standards for the integration of
medical device data into electronic health records
(EHR/PHR) include:



IHE Patient Care Device (PCD) integration profiles and
Electronic/Personal Health Record Network Interface
(xHRN-IF) by the Continua Health Alliance
Both of these standards address how to map


The device data obtained through the ISO/IEEE 11073
standard
To the healthcare application interfaces
August 30, 2012
VLDB 2012
86
IHE Device Enterprise Communication
(DEC) Profile


Used for transmitting information from medical devices to the
enterprise applications
For this purpose:




ISO/IEEE 11073 Domain Information Model is mapped to HL7 v2.5
Observation Report and
The ISO/IEEE 11073 Data Types are mapped to HL7 v2.5 Data Types
For semantic interoperability, IHE has developed the Rosetta
Terminology Mapping (RTM) Profile to provide the mapping between
the proprietary device parameters to ISO/IEEE 11073 Nomenclature
A special case of this profile for cardiac implantable devices
 IHE Implantable Device – Cardiac – Observation (IDCO) Profile
 Defines a standard based translation and transfer of device
interrogation information from the interrogation system to the
healthcare application
August 30, 2012
VLDB 2012
87
An Example to How Medical
Device Standards are Used in
Practice
iCardea: An Intelligent Platform for
Personalized Remote Monitoring of
the Cardiac Patients with Electronic
Implant Devices
August 30, 2012
88
eHealth Situation with Cardiac Patients

There has been an exponential growth in the number of cardiac
implantable devices: 800.000 CIED patients in EU with 5.8 million
follow-up visits

CIED electronic and software complexity have widen their function
and application

However, due to their limited processing capabilities restricted by
their size, CIEDs need to be supported with external software running
on “data centers”

Currently, the data center processing is standalone with their own
custom software and proprietary interfaces



Patient and device data is stored in data centres operated by the
vendors
Presented via secure Web-sites to the access of responsible
healthcare professionals
Access to follow-up information often requires clinicians to use
multiple vendor specific systems and interfaces, reducing efficiency
August 30, 2012
VLDB 2012
89
As is situation…
DataCenters currently operated:
•CareLink by Medtronic, USA
•HouseCall Plus by St.Jude Medical, USA
•HomeMonitoring by Biotronik, Germany
•Latitude PMS by Boston Scientific,USA
Data Center
Collected
Data
Data Center
Portal
Physicians access
diagnosis data via a
web-based portals
•GSM network
•Telephone lines
Transmitter /
Interrogator
August 30, 2012
CIED
implanted on
patient
Follow-up visits
(normally
twice a year)
VLDB 2012
Goal:
•To reduce the number of visits,
•To improve the quality of care
90
iCARDEA Architecture
Patient Empowerment System
ORBIS EHR
Interoperability
Interoperability
Programmer and
The Data Center
EHR
Interoperability
System
Collected
Data
Data Center
Portal
August 30, 2012
Careplan
Execution
Monitoring
CIED
implanted on
patient
Personal
Healthcare
Records
Consent
Management
System
Interoperability
IHE CM
Adaptive Care Planner
Interoperability
IHE/IDCO - HL7 ORU
Usually
Manufacturer
Proprietary
Format
Transmitter /
Interrogator
CIED
Information
System
IHE CM
IHE CM & IHE XPHR
Patient
Enables
remote
semiautomatic
context
aware
follow-up
VLDB 2012
Patient
Parameter
Monitoring
Alert /
Reminder
Data
Analysis and
Correlation
Historical Data
91
Clinical Guidelines







Clinical guidelines are developed to assist general practitioners in
making clinical decisions
They usually include plans for treatment and are used in
developing the “Clinical Decision Support” systems
Clinical guidelines aim to reduce inter-practice variations and
improve the quality of care and standardize clinical procedures
A variety of government and professional organizations are
producing and disseminating clinical guidelines
A comprehensive database of evidence-based clinical practice
guidelines and related documents exist, (NGC,
http://www.guideline.gov)
Several computer interpretable models of Clinical Guidelines have
been proposed such as GLIF, ASBRU, ARDEN and EON
Additionally, there are several guideline execution engines
processing these models, such as GLEE, GLARE and DeGel
August 30, 2012
VLDB 2012
92
Guideline
Eligibility Criteria
Decision Step
Algorithm
Branch Step
Action Step
Programming Oriented
Action
GetDataAction
EHR Data
August 30, 2012
Synchronization
Step
Patient State
Step
Medically Oriented
Action
MessageAction
SubGuidelineAction
Sensor Data
VLDB 2012
93
An Example Guideline for Atrial Fibrillation
detection of AF
Type of ICD
Single chamber
Dual chamber
Algorithm of SVT detection
CRTD
Onset
Morphology
EGM: Confirm diagnosis (physician)
AV Ratio
VT
Artefact/noise/dysfunction
Inapproproate discharge Real AF
consider imediate referal to clinic
Physical condition of the patient
stable
unstable
inapropriate discharge
Single/rare episode
heart failure
Persistent AF
Hospital admission
no
CHADS2 Score
Bradycard AF
Normocard AF
Cardioversion
-Medication
-Electrical
- Stroke
- Heart Failure
+1
- Hypertension
+1
- Age >75a
+1
- Diabetes Mellitus
+1
Recent Medical History
Contraindication
No Contraind.
Medication
-Recent Medical History
-Recent Medication
- Diuretics
If tachycard:
-Digitalis
-Amiodaron
If bradycard:
- Reject antiarrhythmic
drugs that cause
bradycardia
Σ>1
Recent Medical History
Contraindication
No Contraind.
Recent Laboratory
Amiodaron?
Sotalol?
Recent Medical History
Recent Medical History
Contraindication
No Contraind.
Recent Medication
Contraindication
No Contraind.
Drug Interaction
Contraindication
No Contraind.
Contraindication
Contraindication
Contraindication
No Contraind.
Drug Interaction
No Contraind.
Start Betablocker
No Contraind.
Recent Laboratory
No Contraind.
Drug Interaction
Contraindication
Recent Medication
No Contraind.
Contraindication
No Contraind.
Start Amiodaron
Contraindication
Contraindication
Ibutilide?
Recent Medication
Recent Laboratory
Σ = 0 or 1
Rhythm Control
yes
Betablocker?
yes=+2
No need for therapeutic
intervention/routine remote follow
up
no
Rate Control
yes
Contraindication
No Contraind.
Recent Laboratory
Contraindication
No Contraind.
Drug Interaction
Contraindication
Recent Medical History
or „persistent AF“
Tachycard AF
1) Deactivation o ICD
programmer
magnet
2) Follow up measurement
3) Device programming
optimize SV detection
Onset
Morphology
AV-Ratio
optimize detection zones
4) Acute Medication
Recent Medication
Sedacoron
Beta Blocker
Drug Interaction
Orale Anticoagulation?
In case of „frequent episodes“
Hospital admission
Frequent episodes
Contraindication
No Contraind.
Recent Medication
Contraindication
No Contraind.
Recent Laboratory
Contraindication
No Contraind.
Drug Interaction
No Contraind.
Contraindication
Start Sotalol
No Contraind.
Start Ibutilide
Increase Betablocker
Increase Amiodaron
Increase Sotalol
Increase Ibutilide
Discontinue Amiodaron
Decrease Sotalol
Decrease Ibutilide
Do not change Amiod.
No Sotalol
No Ibutilide
Discontinue Betablocker
No Contraind.
Do not change β-blocker
Start Oral Anticoagulation
Drug Interaction
No Oral Anticoagulation
No Amiodaron
Amiodaron?
Digitalis?
Ca-Antagonist?
Recent Medical History
Device Programming
-Antibradycard Pacing
-No
Contraindication
Recent Medication
Contraindication
Contraindication
No Contraind.
Recent Medication
No Contraind.
Recent Laboratory
Recommendation of the
careplanerer decision
of the physician
Recent Medical History
No Contraind.
Contraindication
No Contraind.
Recent Medical History
Contraindication
Recent Medication
Contraindication
No Contraind.
Drug Interaction
Contraindication
No Contraind.
No Contraind.
Drug Interaction
Start Digitalis
Source: MEDIS
Contraindication
Increase Digitalis
Discontinue Digitalis
Do not change Digitalis
94
No Contraind.
VLDB 2012
Start Amiodaron
Start Ca-Antagonist
Increase Amiodaron
Increase Ca-Antagonist
Discontinue Amiodaron
Discontinue Ca-Antagon.
Do not change Amiod.
Do not change Ca-Antag.
No Amiodaron
No Digitalis
August 30, 2012
No Contraind.
Drug Interaction
Source: pat. impowerment
Source: ORBIS
No Contraind.
Recent Laboratory
Contraindication
Contraindication
No Contraind.
Recent Laboratory
Contraindication
Contraindication
No Contraind.
In case of „single-rare episode“
No Betablocker
No Ca-Antagonist
Consider Electrical
cardioversion
Consider AF/AVN
Ablation
94
Personalized Adaptive Care Plan

Personalized follow-up of CIED patients is coordinated through a
“care plan”




An executable definition of a care plan that consists of computer interpretable
clinical guideline models
Control flow of the care plan is dynamically adapted based on the patient’s
context – PHR, EHR, Diagnosis data, etc.
Provides reminder and personalized guidance services to the medical
professionals
Careplan Engine


Executes machine processable care plan definition
Subscribes to EHR and PHR interoperability Systems for retrieving most recent
relevant clinical parameters related with the care plan



Care Plan Engine is kept up-to date about these clinical parameters
Most recent CIED data is continuously retrieved as a result of pre-programmed
remote follow-ups and alerts
Care Plan Engine executes the care plan for:


Regular pre-programmed follow-ups
Each alert situation to assess the patient’s condition in full context and react as soon as possible in
guidance of clinical guidelines

August 30, 2012
A monitoring interface is presented to the Medical professional
VLDB 2012
95
Cardiac Implementable Electronic Device
Programmer
CIED Vendor
Data Center
CIED Data Receiving
login-in to the CIED vendors’ data centers
PDF/ZIP
Interrogator
CIED Data
Receiving
Valid CIED
Message
CIED Data
Processing
IEEE 11073
HL7v2
Message
CIED Data
Integration
Module
CIED Data
Transforming
CIED Data Processing
CIED data validated, extracted and
encoded using IEEE 11073 Nomenclature
into an HL7v2 ORU message
CIED Data Transforming
HL7v2 message transmitted to Care Plan
Engine through standard Interface
(IHE IDCO Profile)
IHE IDCO Profile
iCardea GUI
Adaptive
Careplan
Execution
Engine
August 30, 2012
VLDB 2012
96
iCARDEA Architecture
Patient Empowerment System
ORBIS EHR
Interoperability
Interoperability
Programmer and
The Data Center
EHR
Interoperability
System
Collected
Data
Data Center
Portal
August 30, 2012
Careplan
Execution
Monitoring
CIED
implanted on
patient
Personal
Healthcare
Records
Consent
Management
System
Interoperability
IHE CM
Adaptive Care Planner
Interoperability
IHE/IDCO - HL7 ORU
Usually
Manufacturer
Proprietary
Format
Transmitter /
Interrogator
CIED
Information
System
IHE CM
IHE CM & IHE XPHR
Patient
Enables
remote
semiautomatic
context
aware
follow-up
VLDB 2012
Patient
Parameter
Monitoring
Alert /
Reminder
Data
Analysis and
Correlation
Historical Data
97
Interoperability Challenges Addressed

Interoperability with Cardiovascular Implantable
Electronic Devices

To collect Pacing parameters, EGM, Shocks/Therapies provided, Alerts

IHE Implantable Device Cardiac Observations (IDCO) profile
implementation


ISO/IEEE 11073 (Point of Care Medical Device Communication
Standards) Nomencalature and HL7v2 ORU Messages
Interoperability with Legacy EHR Systems

To collect previous or ongoing healthcare problems, medications, lab
results

IHE XDS, HL7 CDA documents and IHE Care Management Profile
Implementations
August 30, 2012
VLDB 2012
98
Interoperability Challenges Addressed


Interoperability with PHR System

To collect information about daily usage of medications, physical activities,
activities of daily living observations, patient reported symptoms, vital sign
measurements

IHE Care Management Profile Implementation
Interoperability between PHR and EHR


Pre-filling PHR with patient history

IHE Exchange of Personal Health Record (XPHR) Content Modules

IHE Patient Care Coordination (PCC) 09/10 Transactions
Different Coding Systems used by Care Plan Engine, EHR and PHR

UMLS as the terminology server, HL7 Common Terminology Services (CTS)
Implementation
August 30, 2012
VLDB 2012
99
Sample Execution (of Ventricular Tachycardia)
August 30, 2012
VLDB 2012
100
Sample Execution (of Ventricular Tachycardia)
August 30, 2012
VLDB 2012
101
Related Publications

This is applied work involving research:







Laleci G. B., Dogac A., “A Semantically Enriched Clinical Guideline Model Enabling
Deployment in Heterogeneous Healthcare Environments”, IEEE Transactions on
Information Technology in Biomedicine Vol. 13, No. 2, pp. 263-273, March, 2009.
Yuksel M., Dogac A., “Interoperability of Medical Device Information and the Clinical
Applications: An HL7 RMIM based on the ISO/IEEE 11073 DIM”, IEEE Transactions on
Information Technology in Biomedicine, Vol. 15, No.4, July 2011, pp. 557 - 566.
Chronaki, C., Sfakianakis, S.G., Petrakis, Y., Yang, M., Radulescu, M., Eichelberg, M.,
Erturkmen, G.L., Hinterbuchner, L., Arbelo, E., & Dogac, A, “Integrating Out-Patient and
Remote Follow-Up of Cardiovascular Implantable Electronic Device Patients”, ICPES 2011 –
World Society of Arrhythmias, PACE (ICPES2011). 34 (11), (1357-8). December 11-14, 2011,
Athens, Greece.
Arbelo, E., Trucco, E., Dogac, A., Luepkes, C., Chronaki, C., Hinterbuchner, L., Ploessnig, M.,
Yang, M., Guillén, A., & Brugada, J., “iCARDEA: Personalized Remote Monitoring of Atrial
Fibrillation in Patients with Electronic Implant Devices”, ICPES 2011 – World Society of
Arrhythmias, PACE (ICPES2011, P193). 34 (11), (1445-6). December 11-14, 2011, Athens,
Greece.
Trucco E; Arbelo E; Laleci GB; Yang M; Kabak Y; Chronaki C; Hinterbuchner L; Guillen A;
Dogac A; Brugada J, “Personalized Remote Monitoring of Atrial Fibrillation in Patients with
Electronic Implant Devices”, ICPES 2011 – World Society of Arrhythmias, PACE (ICPES2011,
P189). 34 (11), (1443-4). December 11-14, 2011, Athens, Greece.
Yang M., Chronaki C.E., Lüpkes C., Thiel A., Plößnig M., Hinterbuchner L., Arbelo E., Laleci
G.B., Kabak Y., Duarte F., Guillén A., Pfeifer B., Pecho W., Dogac A., Eichelberg M., Hein A.,
“Guideline-Driven Telemonitoring and Follow-up of Cardiovascu-lar Implantable Electronic
Devices using ISO/IEEE 11073, HL7 & IHE Profiles”, 33rd Annual International Conference of
the IEEE Engineering in Medicine and Biology Society (EMBC ’11), Boston, USA, August
30th - September 3rd, 2011.
Further Information on iCardea is Available from http://www.srdc.com.tr/icardea/
August 30, 2012
VLDB 2012
102
Empowering European
Diabetes Patients
Support of Patient Empowerment by an
intelligent self-management pathway for
patients – The EMPOWER Project
August 30, 2012
103
104
August 30, 2012
VLDB 2012
104
August 30, 2012
VLDB 2012
105
Interoperability in the Clinical
Research Domain
August 30, 2012
106
Clinical Research

Clinical research is a field of biomedical research addressing the
assessment of new





Pharmaceutical and biological drugs
Diagnostic methods
Medical devices and
Vaccines in humans
In this way, their safety is checked by the regulatory authorities
such as:




Food and Drug Administration (FDA) in the USA and
The European Medicines Agency (EMA) in the European Union
It is driven by clinical trials or post market studies
Clinical trials investigate the role of some factor or agent in the
prevention or treatment of a disease
August 30, 2012
VLDB 2012
107
How the Clinical Trials are Conducted?

The sponsor, usually a biopharmaceutical company, creates the
trial protocol (Study Design) specifying instructions on









The data to be captured
Tests to be ordered,
Inclusion and exclusion criteria for subjects, and
The number and type of visits
This data is sent both to the regulatory body for approval and to
the clinical investigators
Based on the inclusion and exclusion criteria specified in the trial
protocol, eligible patients are selected
A clinical investigator takes the responsibility of conducting the
trial at a particular trial site, and generates, collects and records
data
The collected data to be sent to the sponsor includes the Case
Report Forms (CRFs)
Electronic Case Report Forms are collected through
computerized Electronic Data Capture (EDC) systems
August 30, 2012
VLDB 2012
108
How the Clinical Trials are Conducted?





Sponsors use copies of the data recorded at the clinical site, and
perform various analyses to reach their conclusions
Collected trial data and the results of the analysis are then sent
to the regulators
During the lifetime of the clinical trials, investigators immediately
report any serious Adverse Event (AE) to the sponsor
Regulators need to reconstruct the trial by comparing the data
submitted to the agency by the sponsor with the source data
maintained at the investigational site
After the drug, medical device, diagnostic product or treatment
regimen is authorized to be used in market, the healthcare
institutes can voluntarily report AE incidents to the national
competent authorities
August 30, 2012
VLDB 2012
109
Interoperability Standards for Clinical Research

The parties involved in a regulated clinical research study are




Clinical Data Interchange Standards Consortium (CDISC,
http://www.cdisc.org) develops standards covering almost all the steps
within a regulated clinical research study including







The sponsor,
The clinical investigator and
The regulatory body, each with their own software applications,
Study Design (CDISC SDM),
Study Data Collection (CDISC ODM and CDASH),
Study Data Analysis (CDISC ADAM) and
Submission to the regulatory bodies (CDISC SDTM)
There are Individual Case Safety Report (ICSR) Standards for the
exchange of adverse event reports during and after clinical research
studies
These set of standards proved to be very useful and are being widely
used in managing clinical research studies
However, the vast majority of clinical research study protocols also
need data from the clinical care domain
August 30, 2012
VLDB 2012
110
Clinical Trials vs Post Market Safety Studies

Clinical trials are not adequate to ensure comprehensive drug
safety

Limited size and scope

Do not include patients with comorbid conditions and those being
treated with concomitant medications

Designed to pick-up common problems not rare adverse events
Cannot detect long-term adverse events


Post market safety studies address this problem, but

Based on voluntarily sent spontaneous case safety reports

Medical professionals do not always see reporting a priority &
detecting adverse events may not always be straightforward
It is estimated that medical practitioners report only about 5%
of harmful drug side effects
Approximately 5% of all hospital admissions in Europe are due to
an adverse drug reaction (ADR), and ADRs are the fifth most
common cause of hospital deaths


August 30, 2012
VLDB 2012
111
The Interoperability Problems of Clinical Care
and Clinical Research

To improve the effectiveness of clinical research processes, the
information from the clinical care must be re-used:




Most of the data needed by clinical research is already available in the
clinical care records (EHRs)
However clinical research and the clinical care domains use different
standards and hence are not interoperable:

Clinical research uses CDISC standards

Clinical care is dominated by HL7 standards

The terminology systems used are also different
For example, currently the clinicians copy the results of therapeutic
procedures and examinations from an EHR system in the Case Report
Form (CRF) manually
As another example, the investigators have to manually select the
eligible patients from the underlying EHR systems, by examining the
inclusion/exclusion criteria listed in trial design documents
August 30, 2012
VLDB 2012
112
IHE Standards for the Interoperability of
Clinical Care and Clinical Research Domains




An Initiative for the interoperability of clinical care and clinical
research domains - two profiles from IHE:
 IHE Drug Safety Content Profile (DSC)
 IHE Clinical Research Document Profile (CRD)
These profiles reuse the available standards in clinical care and
research domains to facilitate their interoperability
However, the interoperability is achieved through hard-coded
mappings between clinical research and care standards
 For example, in CRD, a direct XSLT mapping between IHE PCC
templates and the CDASH annotated ODM structure is provided
Also the XSLT mappings are only valid for the given fixed formats
defined in PCC/CCD and ODM models; once these formats are
modified due to emerging requirements, new mappings will be
needed
August 30, 2012
VLDB 2012
113
The SALUS Approach

An effort in this direction: The SALUS Project
 Enable post-market analysis for different subpopulations selected
from multiple, distributed EHRs as target cohorts
 Automated ADE detection tools screening EHRs in a hospital to
facilitate ADE detection
 Enable ADE reporting by automatically extracting the available
information from the EHRs into the individual case safety reports,
to avoid double data entry
 Enable real time screening of multiple, distributed,
heterogeneous EHRs for early detection of adverse event signals

SALUS (Scalable, Standard based Interoperability Framework for Sustainable
Proactive Post Market Safety Studies)


Supported by the European Commission under the FP7 Program
For further information: http://www.srdc.com.tr/projects/salus/
August 30, 2012
VLDB 2012
114
The SALUS Approach


The SALUS framework is based on the “semantic mediation” of clinical care
and clinical research domains
 A process of matching schemas and mapping attributes and values
using semantics
In achieving this, the mediator needs
 A shared conceptual reference model to serve as the common ground




To correlate the concepts from different sources to reconcile their differences
and
To establish some well-defined relationships among them
Building a coherent conceptual reference model to be used in “semantic
mediation”, on the other hand, requires a ‘‘semantic harmonization’’ process
Semantic Harmonization involves
 Investigating semantically connected domain analysis models
 Deriving common semantics and
 Expressing this semantics through explicit and formal knowledge
representations techniques
August 30, 2012
VLDB 2012
115
The SALUS Approach

Fortunately, this shared conceptual model exists for the
clinical care and research domains through the efforts by the
BRIDG Project



The BRIDG model unifies various aspects of all the concepts in
the clinical care and research domains and
Creates a shared generic representation for each concept
In the SALUS framework, the RDF representation of the
BRIDG model is used as the core ontology to have the
common shared semantics in a formal, machine processable
form
August 30, 2012
VLDB 2012
116
Biomedical Research Integrated Domain Group
(BRIDG)






BRIDG initiative aims to enable the re-use of information from the
clinical care domain in clinical research
It has developed a domain analysis model (DAM) which
harmonizes
 CDISC data standards with
 The HL7 Reference Information Model (RIM)
This facilitates data exchange between the EHR systems and the
sponsor clinical research systems
Currently the BRIDG model semantics is available only to human
experts because it is not in a machine processable form
Mappings between
 The standards harmonized by the BRIDG initiative and
 The BRIDG DAM
are provided through spreadsheets
August 30, 2012
VLDB 2012
117
The SALUS Approach


The BRIDG DAM semantics has already been mapped to more
than one implementation model (such as CDISC SDTM and HL7
Study Design RMIM) using spreadsheets
To be able to use these mapping information automatically, we
have converted them into machine processable format as
follows:
 The mappings of the terms in a dataset standard (such as
CDASH) to BRIDG Model is rather straight forward and we used
SPARQL queries for this purpose
 For standards that have a compositional nature enabling
multidimensional representation of clinical data, such as HL7 RIM
based models, a more complex mapping mechanism is needed


August 30, 2012
For this, we utilized ontology mapping mechanisms
For example, when the value of an attribute in a source class needs
to be processed to obtain the value of the attribute in the target class
VLDB 2012
118
The SALUS Approach


Another challenge is the different terminology systems used by
clinical care and clinical research institutes
BioPortal (http://bioportal.bioontology.org) initiative is an important effort
in this direction:



More importantly, it also serves mapping information between the
coded terms of these terminology systems as an ontology
We have implemented an export functionality



It serves more than 290 biomedical ontologies including ontological
representations of major terminology systems like SNOMED CT, LOINC,
ICD10, MedDRA, WHO-ART and RxNORM
To add these ontologies together with their mappings to our Semantic
Framework, and
To utilize them to address end-to-end semantic interoperability of clinical
care and research systems
Ref: Gokce B. Laleci, Mustafa Yuksel, Asuman Dogac, “Providing Semantic
Interoperability between Clinical Care and Clinical Research Domains”, currently
under revision, IEEE Transactions on Information Technology in Biomedicine
August 30, 2012
VLDB 2012
119
Thank you...Questions?
Slides are available from:
www.srdc.com.tr/~asuman/eHealthInteroperability.ppt
August 30, 2012
VLDB 2012
120