August 30, 20121 Interoperability in eHealth Systems Asuman Dogac, SRDC Ltd

August 30, 2012 1

Interoperability in eHealth Systems

Asuman Dogac, SRDC Ltd.

August 30, 2012 VLDB 2012 2

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 3

What if…

What if Electronic Health Records are widely used and shared? 9 million bed-days could yearly be freed up corresponding to a value

of €3,7 billion What if Computerised Physician Order Entry are widely used?

100,000 adverse drug events could be avoided yearly What if ePrescriptions are widely used?

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 4

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 Saglik-Net in Turkey and epSOS in Europe

Monitoring Chronic Diseases Patients with Cardiac Implants and Diabetes patients

Secondary use of EHRs in Clinical Research

August 30, 2012 VLDB 2012 5

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 6

Interoperability (Def’n)

Interoperability with regard to a specific task is said to exist betweentwo applications when one application can accept data (including datain the form of a service request) from the other and perform the taskin an appropriate and satisfactory manner (as judged by the user of thereceiving 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 7

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 8

The nice thing about standards is that there are so many to choose from !

August 30, 2012 VLDB 2012 9

Some of the Main Standard Bodies in eHealth HL7 (Health Level Seven)

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

Integrating the Healthcare Enterprise (IHE) 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 10

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)

EHRs are documents also for medico-legal reasons: a medical professional takes the responsibility for the information contained in it

August 30, 2012 VLDB 2012 11

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 12

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 13

Exchanging HL7 messages…

john

smith

12345

HL7-I12 Patient Referral

Network

(e.g., VAN)

11011010

HL7-I12 Patient Referral

12345 smithjohn^ ^

Application 1: HIS Database and back end applications

Application 2: HIS Database and back end applications

Interface Engine Interface Engine

August 30, 2012 14

Interoperability Stack

August 30, 2012 VLDB 2012 15

15

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 16

Communication Layer

Transport Protocols: HTTP, SMTP, MLLP, ...

Higher Level Messaging Protocols: SOAP, ebMS, ...

Quality of Service Protocols: WS-Reliability, WS-Security, WS-Addresing

Business Process Layer

Choreography/Business Process Standards: WSCDL, ebBP

Specifications with Diagrams: e.g. IHE(Actor/Transaction Diagrams,Sequence Diagrams) , HL7 (Sequence Diagrams)

Document LayerNon-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical Imaging)

Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA, EHRCom, ...

Terminologies/Coding Systems: LOINC, SNOMED, ...Business Rules (e.g by using schematrons)


16

INTE

ROPE

RABI

LITY

STA

CK

August 30, 2012 VLDB 2012 17

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:

“CDA” for expressing clinical documents, “Clinical genomics” for expressing clinical and personalized genomics data, and “Claims and reimbursement” for handling claims and reimbursements

It recommends several protocol alternatives for the communication layer 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 18

Some Document Standards… HL7 v3 Clinical Document Architecture (CDA)

Defines the structure and semantics of medical documents for the purpose of exchange in Extensible Markup Language (XML)

openEHR 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 Has a reference model and uses openEHR archetypes to constrain them

ASTM Continuity of Care Record (CCR) 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 19

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: The same information can be expressed through different components and

these components can be nested differently Therefore, the templates/archetypes are necessary to constrain the

structure and format of generic EHR content standards 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 20

An Example to Interoperability Problems of Content Templates

August 30, 2012 VLDB 2012 21

Communication Layer

Transport Protocols: HTTP, SMTP, MLLP, ...

Higher Level Messaging Protocols: SOAP, ebMS, ...

Quality of Service Protocols: WS-Reliability, WS-Security, WS-Addresing

Business Process Layer

Choreography/Business Process Standards: WSCDL, ebBP

Specifications with Diagrams: e.g. IHE(Actor/Transaction Diagrams,Sequence Diagrams) , HL7 (Sequence Diagrams)

Document LayerNon-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical Imaging)

Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA, EHRCom, ...

Terminologies/Coding Systems: LOINC, SNOMED, ...Business Rules (e.g by using schematrons)


21

Integration Profiles(e.g. IHE in

eHealth or NES UBL in eBusiness)

or

Technical Specification

s(National or

Regional Health Networks:

e.g. USA NHIN, NICTIZ, Saglik-

NET)

Integration Profiles(e.g. IHE in

eHealth or NES UBL in eBusiness)

or

Technical Specification

s(National or

Regional Health Networks:

e.g. USA NHIN, NICTIZ, Saglik-

NET)

INTE

ROPE

RABI

LITY

STA

CK

August 30, 2012 22

Semantic Interoperability in eHealth

August 30, 2012 VLDB 2012 23

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 24

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 25

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 26

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 27

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 Internet access to knowledge sources by browser or web service API

August 30, 2012 VLDB 2012 28

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 29

An Example: Terms in the UMLS for “Addison’s disease” Concept CUI C0001403 Term Name Source

Vocabulary

Code in the Source Vocabulary

Addison’s disease SNOMED CT 363732003Addison’s Disease MedlinePlus T1233Addison Disease MeSH D000224Bronzed disease SNOMED Intl DB-70620Primary Adrenal

Insufficiency MeSH D000224

Primary hypoadrenalism syndrome, Addison MedDRA 10036696

August 30, 2012 VLDB 2012 30

A part of UMLS Semantic Network

August 30, 2012 VLDB 2012 31

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 32

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 Acute heart failure56675007

SNOMED CTHeart Failure84114007

MEDRAHeart Failure10019279

subclass

Equivalent class

August 30, 2012 VLDB 2012 33

Semantic Mediation !

SNOMED

CT

August 30, 2012 34

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 VLDB 2012 35

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 36

Collecting EHRs

Private Hospitals

Public Hospitals

General Practitioner(Family Medicine InformationSystem

University Hospitals

NHIS, Turkey

August 30, 2012 VLDB 2012 37

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

Address Name Main Diagnosis Vaccination Treatment Method Diastolic Blood Pressure Healthcare Institution Marital Status

Citizen/Foreigner Registration MHDS

Medical Examination MHDS Prescription MHDS Pregnant Monitoring MHDS Cancer MHDS Inpatient MHDS

Some data elements Some MHDSs

August 30, 2012 VLDB 2012 38

August 30, 2012 VLDB 2012 39

An Example Transmission Schema (“Examination”)

August 30, 2012 VLDB 2012 40

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 41

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 42

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 43

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”

“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”

August 30, 2012 VLDB 2012 44

Validation of the Messages by the NHIS

Internet

11011010

HIS of Hospital A

HL7-V3 <patient> <id> </id> <given> </given> <family> </family></patient>

WS SOAP Valid SOAP message?

Valid use of WS-Security User Name Token Profile?

Valid HL7 CDA Schema?

12345

Yılmaz

Ahmet

Observation Service

NHIS

Valid Codes from National Code Reference Server?

Valid Business rules? (‘Activity Time should be less than the system time.)Valid Patient-Identifier?Valid Physician-Identifier?

August 30, 2012 VLDB 2012 45

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 46

Decision Support System

NHIS

Decision SupportSystem

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?

August 30, 2012 VLDB 2012 47

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 48

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 4949

August 30, 2012 VLDB 2012 5050

August 30, 2012 VLDB 2012 5151

August 30, 2012 VLDB 2012 5252

August 30, 2012 VLDB 2012 5353

August 30, 2012 VLDB 2012 5454

August 30, 2012 VLDB 2012 5555

August 30, 2012 VLDB 2012 5656

August 30, 2012 VLDB 2012 5757

August 30, 2012 VLDB 2012 58

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 59

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 60

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.321-339

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 61

Some example Integrating Healthcare Enterprise (IHE) Profiles

August 30, 2012 VLDB 2012 62

IHE Retrieve Information for Display (RID) IHE RID provides provides read-only access to patient-

centric 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 Object Unique Instance Identifier (OID) Type of Request Content Type Expected

August 30, 2012 VLDB 2012 63

IHE Retrieve Information for Display

Retrieve Specific Info for Display

Types of Requests•Summary of All Reports•Summary of Laboratory Reports•Summary of Radiology Reports•Summary of Cardiology Reports•Summary of Surgery Reports•Summary of Intensive Care Reports•Summary of Emergency Reports•Summary of Discharge Reports•List of Allergies•List of Medications

Retrieve Document for Display

Persistent Document

IHE-RID WSDL<?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 64

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

August 30, 2012 VLDB 2012 65

Document Consumer

Retrieve Document

Query Documents

Patient Identity Source

Patient Identity Feed

Document Source

Document Registry

Document Repository

Provide&Register Document Set

Register Document Set

IHE XDS Transaction Diagram

August 30, 2012 VLDB 2012 66

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 70

An Example to How IHE Profiles are Used in Practice

epSOS - European Patients - Smart open Services

August 30, 2012 VLDB 2012 71

• Different languages

• Different eHealth processes

• Different grade of development

• Different Legislation

• Different concepts

• No European Nomenclature for Medicines

Exchanging Patient Summaries and ePrescriptions in Europe: The epSOS initiative

August 30, 2012 VLDB 2012 72

The epSOS participating nations

August 30, 2012 VLDB 2012 73

The epSOS Solution Patient Summary for European Citizens ePrescription service for European Citizens

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

The content templates for the three document types 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 74

Important Standards Used in epSOS Content models for Patient Summary, ePrescription and

eDispensation documents 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

Clinical Terminology Systems ICD-10, SNOMED CT, LOINC, ATC, …

Interoperability Profiles 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 75

The epSOS Solution For the coded representation of clinical content within these schemas,

subsets from existing terminology systems are used SNOMED CT, ICD-10, LOINC, ATC, …

epSOS Master Value Sets Catalogue (MVC) is created The latest version 1.7 of MVC contains 46 value sets For example,

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 76

Structured Document based on HL7 CDA R2 with coded entries

PDF as “printable” representation of the original data

Worldwide recognized HL7 CDA templates (HL7 CCD; IHE PCC)Worldwide recognized HL7 CDA templates (HL7 CCD; IHE PCC)

The epSOS Solution

PDF embedded in an unstructured HL7 CDA R2 documentPDF embedded in an unstructured HL7 CDA R2 document

August 30, 2012 VLDB 2012 77

Redundant Coded Data Elements for Safety

C-A CodeC-A Display name

Country AData


epSOS CodeepSOS EnglishDisplay name

Pivot Document In Country B


Pivot Document In Country A

epSOS CodeepSOS EnglishDisplay name

@

epSOS C-B lang.Display name@

Local Terminology Repository(based on epSOS Reference Terminology [MVC, MTC])

August 30, 2012 VLDB 2012 78

C-A CodeC-A Display Name

epSOS Code

epSOS EnglishDisplay Name

epSOS Code System OID

C-A Code System OID

C-B Display name

<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" >

<translationdisplayName="Asthma” >

<translationcode="493.0“

displayName="ASMA“codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD-9CM" />

</translation></value>

Transcoded & Translated itemDocument Consumer NCP

Transcoded & Translated itemDocument Consumer NCP

Semantic Transformation

August 30, 2012 VLDB 2012 79

Patient Summary ‘Basic dataset’ (excerpt)

Information/dataset Contains

Patient Identification Unique identification for the patient in that country.

Patient Personal information

Full name. Date of birthGender

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

Mainly based on the IHE PCC Section Content modules (derived by the HL7 CCD)

August 30, 2012 VLDB 2012 80

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 81

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

Responding Community

Initiating Gateway

Responding Gateway

Cross-GatewayQuery

Cross-GatewayRetrieve

August 30, 2012 VLDB 2012 82

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

Responding Community

Initiating Gateway

Responding Gateway

Cross-GatewayPatient Discovery

Patient Location Query

August 30, 2012 VLDB 2012 83

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

Document Recipient

Provide and Register Set transaction-b

August 30, 2012 VLDB 2012 84

NCP-B(country of care)

NCP-A(country of affiliation)

Demographics Query

Cross-Gateway Query with Returned Documents

Provide and Register Document Set

epSOS Identification Service consumer

XCPD Initiating Gateway

epSOS Identification Service provider

XCPD Responding Gateway

epSOS Patient Service consumer

epSOS Order Service consumer

XCA Initiating Gateway

epSOS Patient Service provider

epSOS Order Service provider

XCA Responding Gateway

epSOS Dispensation Service consumer

epSOS Consent Service consumer

epSOS Dispensation Service provider

epSOS Consent Service provider

XDR Document Source

XDR Document Recipient

Use of IHE Profiles in epSOS

August 30, 2012 85

Medical Device Interoperability

August 30, 2012 VLDB 2012 86

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 87

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 88

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 VLDB 2012 8989

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 909090

As is situation…

CIED implanted on patient

Collected Data

Data Center Portal

Data Center

Transmitter / Interrogator

DataCenters currently operated:•CareLink by Medtronic, USA•HouseCall Plus by St.Jude Medical, USA•HomeMonitoring by Biotronik, Germany•Latitude PMS by Boston Scientific,USA

Follow-up visits(normally twice a year)

Physicians access diagnosis data via a web-based portals

Goal: •To reduce the number of visits, •To improve the quality of care

•GSM network•Telephone lines

August 30, 2012 VLDB 2012 919191

iCARDEA Architecture


Enables remote semi-

automatic context aware

follow-up

CollectedData Adaptive Care Planner

Data Center Portal

Programmer and The Data Center


Careplan Execution Monitoring

Usually Manufacturer Proprietary

Format

CIE

D

Info

rma

tion

Sys

tem

EHR Interoperability

System

Personal Healthcare

Records

Consent Management

System

Patient Empowerment SystemPatient

Patient Parameter Monitoring

Data Analysis and Correlation

Alert / Reminder

ORBIS EHR

Historical Data

August 30, 2012 VLDB 2012 92

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 93

Patient StateStep

Guideline

Eligibility Criteria Algorithm

Decision Step Action StepBranch StepSynchronization

Step

GetDataAction

Medically OrientedAction

Programming Oriented Action

SubGuidelineActionMessageAction

EHR Data Sensor Data

August 30, 2012 VLDB 2012 9494

Physical condition of the patient

Inca

seof

„fr

equen

t epi

sodes“

or„p

ersi

sten

tAF

“

Contraindication

Recent Medication

Start Oral Anticoagulation

detection of AF

Type of ICD

Single chamber Dual chamber CRTD

Algorithm of SVT detection

Onset Morphology AV Ratio

EGM: Confirm diagnosis (physician)

VT Artefact/noise/dysfunction Inapproproate discharge Real AF

consider imediate referal to clinic

unstablestable

inapropriate discharge heart failure

1) Deactivation o ICDprogrammermagnet

2) Follow up measurement3) Device programming

optimize SV detectionOnsetMorphologyAV-Ratio

optimize detection zones4) Acute Medication

Recent MedicationSedacoronBeta BlockerDrug Interaction

Hospital admission Hospital admission

Single/rare episode Frequent episodes Persistent AF

Rate Control Rhythm Control

CHADS2 Score

- Stroke yes=+2

- Heart Failure +1

- Hypertension +1

- Age >75a +1

- Diabetes Mellitus +1

Σ > 1Σ = 0 or 1

Recent Medical History

Contraindication

Recent Laboratory

Drug Interaction

Contraindication

Orale Anticoagulation?

Contraindication No Contraind.

No Oral Anticoagulation

No Contraind.

No Contraind.

Betablocker?

Digitalis?


Recent Laboratory

Drug Interaction

No Contraind.

No Contraind.

Contraindication

Contraindication

Contraindication No Contraind.

Start Betablocker

No Betablocker


Recent Laboratory

Drug Interaction

No Contraind.

No Contraind.

No Contraind.

Start Digitalis

Contraindication

Contraindication

Contraindication

Increase Betablocker

Discontinue Betablocker

Do not change β-blocker

No Digitalis

Increase Digitalis

Discontinue Digitalis

Do not change Digitalis

No Contraind.Contraindication

Recent Medication

No Contraind.

Amiodaron?

Contraindication


Recent Laboratory

Drug Interaction

No Contraind.

No Contraind.

No Contraind.

Start Amiodaron

Contraindication

Contraindication

Contraindication

No Amiodaron

Increase Amiodaron

Discontinue Amiodaron

Do not change Amiod.

Recent Medication

No Contraind.

Contraindication


Recent Laboratory

Drug Interaction

No Contraind.

No Contraind.

No Contraind.

Start Ca-Antagonist

Contraindication

Contraindication

Contraindication

No Ca-Antagonist

Increase Ca-Antagonist

Discontinue Ca-Antagon.

Do not change Ca-Antag.

Recent Medication

No Contraind.

Ca-Antagonist?

Sotalol?


Recent Laboratory

Drug Interaction

Start Sotalol

No Sotalol

Increase Sotalol

Decrease Sotalol

Recent Medication

Contraindication

No Contraind.

No Contraind.

No Contraind.

Contraindication

Contraindication

Contraindication

No Contraind.

Ibutilide?


Recent Laboratory

Drug Interaction

Start Ibutilide

No Ibutilide

Increase Ibutilide

Decrease Ibutilide

Recent Medication

Contraindication

No Contraind.

No Contraind.

No Contraind.

Contraindication

Contraindication

Contraindication

No Contraind.

Consider Electrical cardioversion

Consider AF/AVN Ablation

Inca

seof

„si

ngl

e-rare

epis

ode“

yes

noNo need for therapeutic

intervention/routine remote follow up

yes

no

Amiodaron?

Contraindication


Recent Laboratory

Drug Interaction

Start Amiodaron

Contraindication

Contraindication

Contraindication

No Amiodaron

Increase Amiodaron

Discontinue Amiodaron

Do not change Amiod.

Recent Medication

No Contraind.

No Contraind.

No Contraind.

No Contraind.

Source: ORBIS

Source: MEDIS

Tachycard AF

Bradycard AF

Normocard AF

Cardioversion-Medication-Electrical

Medication-Recent Medical History

-Recent Medication- Diuretics

If tachycard:-Digitalis

-Amiodaron

If bradycard:- Reject antiarrhythmic

drugs that cause bradycardia

Drug Interaction

Device Programming-Antibradycard Pacing

-No

Source: pat. impowerment

Recommendation of the careplanerer decision

of the physician

An Example Guideline for Atrial Fibrillation

August 30, 2012 VLDB 2012 9595

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 A monitoring interface is presented to the Medical professional

95

August 30, 2012 VLDB 2012 96

Cardiac Implementable Electronic Device

96

CIED Data Receivinglogin-in to the CIED vendors’ data centers

CIED Data ProcessingCIED data validated, extracted and encoded using IEEE 11073 Nomenclature into an HL7v2 ORU message

CIED Data TransformingHL7v2 message transmitted to Care Plan Engine through standard Interface(IHE IDCO Profile)

Interrogator

Programmer

Adaptive Careplan Execution

Engine

iCardea GUIiCardea GUI

CIED VendorData Center

CIED Data Receiving

CIED Data Receiving

CIED Data ProcessingCIED Data Processing

CIED Data Transforming

CIED Data Transforming

Valid CIED Message

Valid CIED Message

IEEE 11073HL7v2

Message

IEEE 11073HL7v2

Message

IHE IDCO ProfileIHE IDCO Profile

CIED Data Integration

Module

CIED Data Integration

Module

PDF/ZIPPDF/ZIP

August 30, 2012 VLDB 2012 979797

iCARDEA Architecture


Enables remote semi-

automatic context aware

follow-up

CollectedData Adaptive Care Planner

Data Center Portal

Programmer and The Data Center


Careplan Execution Monitoring

Usually Manufacturer Proprietary

Format

CIE

D

Info

rma

tion

Sys

tem

EHR Interoperability

System

Personal Healthcare

Records

Consent Management

System

Patient Empowerment SystemPatient

Patient Parameter Monitoring

Data Analysis and Correlation

Alert / Reminder

ORBIS EHR

Historical Data

August 30, 2012 VLDB 2012 9898

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 99

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 100

Sample Execution (of Ventricular Tachycardia)

August 30, 2012 VLDB 2012 101

Sample Execution (of Ventricular Tachycardia)

August 30, 2012 VLDB 2012 102

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 103

Empowering European Diabetes Patients

Support of Patient Empowerment by an intelligent self-management pathway for patients – The EMPOWER Project

August 30, 2012 VLDB 2012 104

104

August 30, 2012 VLDB 2012 105

August 30, 2012 106

Interoperability in the Clinical Research Domain

August 30, 2012 VLDB 2012 107

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 108

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 109

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 110

Interoperability Standards for Clinical Research The parties involved in a regulated clinical research study are

The sponsor, The clinical investigator and The regulatory body, each with their own software applications,

Clinical Data Interchange Standards Consortium (CDISC, http://www.cdisc.org) develops standards covering almost all the steps within a regulated clinical research study including 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 111

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 112

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 113

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 114

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 115

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 116

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 117

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 118

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

August 30, 2012 VLDB 2012 119

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: It serves more than 290 biomedical ontologies including ontological

representations of major terminology systems like SNOMED CT, LOINC, ICD10, MedDRA, WHO-ART and RxNORM

More importantly, it also serves mapping information between the coded terms of these terminology systems as an ontology

We have implemented an export functionality 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 120

Thank you...Questions?

Slides are available from: www.srdc.com.tr/~asuman/eHealthInteroperability.ppt