View
225
Download
0
Category
Tags:
Preview:
Citation preview
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)
Interoperability Stack
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)
Interoperability Stack
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
C-A CodeC-A Display name
epSOS CodeepSOS EnglishDisplay name
Pivot Document In Country B
C-A CodeC-A Display name
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
CIED implanted on patient
Enables remote semi-
automatic context aware
follow-up
CollectedData Adaptive Care Planner
Data Center Portal
Programmer and The Data Center
Transmitter / Interrogator
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 Medical History
Recent Laboratory
Drug Interaction
No Contraind.
No Contraind.
Contraindication
Contraindication
Contraindication No Contraind.
Start Betablocker
No Betablocker
Recent Medical History
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 Medical History
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 Medical History
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 Medical History
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 Medical History
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 Medical History
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
CIED implanted on patient
Enables remote semi-
automatic context aware
follow-up
CollectedData Adaptive Care Planner
Data Center Portal
Programmer and The Data Center
Transmitter / Interrogator
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
Recommended