USE OF XML SCHEMA DEFINITION FOR
THE DEVELOPMENT OF SEMANTICALLY
INTEROPERABLE HEALTHCARE
APPLICATIONS
Third International...
Summary
 Background
 Objective
 Method
 Overview of the MLHIM Specifications
 Description of the MLHIM Reference Mode...
Background (1)
 The deployment of IT products has been proposed
since 1961 in order to solve problems in different
dimens...
Background (2)
 The ~65% failure of healthcare IT projects is
related to the dismissal of the unique complexity
and dynam...
Background (3)
 During his/her lifetime, a person will visit dozens of
healthcare providers, scattered around an
undefine...
Background (4)
 In present, there are many private companies and
governmental agencies whose mission is to develop
health...
Background (5)
 The mainstream solution for solving the problem of
semantic interoperability in healthcare is proposing
c...
Multilevel Modeling (1)
 The original multilevel modeling specifications were
proposed by the openEHR Foundation
 Aspect...
Multilevel Modeling (2)
 The current version of the ISO 13606 Standard
does not allow for data persistence, only messagin...
Given the fact that multilevel modeling provides semantic
interoperability, but there is a need to make it
implementable f...
Method
 Implementation of the Multilevel Healthcare
Information Modeling (MLHIM) Specifications
 Reference Model
 Domai...
The MLHIM Specifications (1)
 MLHIM Reference Model (RM) (1)
 The abstract MLHIM RM consists of classes and
attributes –...
The MLHIM Specifications (2)
 MLHIM Reference Model (RM) (2)
 The MLHIM RM is implemented in XML Schema 1.1
 The MLHIM ...
The MLHIM Specifications (3)
 MLHIM Domain Model (DM) (1)
 The MLHIM DM is expressed as Concept Constraint
Definitions (...
The MLHIM Specifications (4)
 MLHIM Domain Model (DM) (2)
 The implementation of CCDs in XML Schema 1.1
expresses:
 The...
The MLHIM Specifications (5)
 MLHIM Domain Model (DM) (3)
 CCDs are identified by Type 4 Universal Unique
Identifiers (U...
The MLHIM Specifications (6)
 MLHIM Domain Model (DM) (4)
 Each complexType of a CCD is also identified by
UUIDs, which ...
The MLHIM Specifications (7)
 MLHIM Domain Model (DM) (5)
 CCDs can accommodate any number of
terminologies and ontologi...
The MLHIM Specifications (8)
 Additional Features
 The MLHIM specifications validates the semantics of
missing data, sin...
MLHIM Reference Model (1)
 Datatypes Package
 Inspired on the ISO 21090 and openEHR data
types
 Ordered data types: ord...
Fig. 1. UML diagram of the MLHIM Reference Model – Datatypes package.
MLHIM Reference Model (2)
 Structures Package
 ItemType descendants:
 ClusterType: it can contain other ClusterTypes or...
Fig. 2. UML diagram of the MLHIM Reference Model – Structures package.
MLHIM Reference Model (3)
 Content Package
 EntryType descendants:
 CareEntryType: defines structure, protocol and
work...
Fig. 3. UML diagram of the MLHIM Reference Model – Content and Contraint
packages.
MLHIM Reference Model (4)
 Common Package
Parent Type complexType Usage
PartyProxyType
PartySelfType
PartyIdentifiedType
...
Fig. 4. UML diagram of the MLHIM Reference Model – Common package.
Proof of Concept (1)
 Two demo applications were developed based on
the MLHIM Demo EMR
 Demo 1: Demographic and Vital Si...
Proof of Concept (2)
 The oXygen XML editor version 14.2 was used for:
 Create and Validate the MLHIM RM Schema
 Valida...
Results (1)
 Data Modeling
 Three CCDs were created:
 Demographic (DemographicEntry)
 Vital Signs (CareEntry)
 Basic ...
Demographic CCD PCTs
CCD Data Element Data Type
Demograhic
Gender
Zip Code
State
City
Driver License no.
Social Security n...
Vital Signs CCD PCTs
CCD Data Element Data Type
Vital Signs
Systolic Pressure
Diastolic Pressure
BP Device Type
Cuff Locat...
Basic Metabolic Panel CCD PCTs
CCD Data Element Data Type
BMP
Sodium
Potassium
Glucose
Urea
Creatinine
DvQuantity
DvQuanti...
Results (2)
 Data Simulation (1)
 The Demographic CCD was used to generate 130
XML instances of fictitious patients
 66...
Results (3)
 Data Simulation (2)
 n (n = 1, 2, 3, …) simulated instances of the Vital
Signs and Basic Metabolic Panel CC...
Results (4)
 Data Validation
 Data validation followed a backward validation chain,
from the XML instance to the W3C spe...
Discussion (1)
 This paper presented the development of a multilevel
model, XML-based implementation of a proof of
concep...
Discussion (2)
 Relationship to Model-Driven Architecture
 MDA is concerned with the overall architecture of a
specific ...
Discussion (3)
 Relationship to OWL and RDF (1)
 The Semantic Web technologies are the next stage
of the original idea o...
Discussion (4)
 Relationship to OWL and RDF (2)
 MLHIM uses RDF and OWL as it was originally
intended: to link to expand...
Discussion (5)
 Relationship to Other HIT Standards (1)
 MLHIM is the harmonization of HL7 and openEHR
 openEHR impleme...
Discussion (6)
 Relationship to Other HIT Standards (2)
 Regarding HL7v3:
 It is not multilevel modeling, so there is n...
Discussion (7)
 Relationship to Other HIT Standards (3)
 HIE and S&I:
 Healthcare Information Exchange (HIE): it is a ‘...
Discussion (8)
 Limitations of MLHIM
 Resistance to innovation adoption:
 Multilevel modeling
 How MLHIM uses XML tech...
Conclusion
 Future Work
 Deploying a enterprise-scale implementation of
MLHIM
 Engaging medical (healthcare) students t...
lutricav@mlhim.org tim@mlhim.org
https://www.facebook.com/mlhim2
http://gplus.to/MLHIMComm
@mlhim2
https://www.youtube.com...
Upcoming SlideShare
Loading in …5
×

MLHIM FHIES 2013

995 views
911 views

Published on

Prof. Luciana Tricai Cavalini, MD, PhD. presents the Multi-Level Healthcare Information Modelling specifications for Third International Symposium on Foundations of Health Information Engineering and Systems (FHIES) 2013 conference. There is also a video on YouTube http://goo.gl/9QPW5x
It is based on the paper: "Use of XML Schema Definition for the Development of Semantically Interoperable Healthcare Applications" to be published in an upcoming issue of Springer LNCS.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
995
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

MLHIM FHIES 2013

  1. 1. USE OF XML SCHEMA DEFINITION FOR THE DEVELOPMENT OF SEMANTICALLY INTEROPERABLE HEALTHCARE APPLICATIONS Third International Symposium on Foundations of Health Information Engineering and Systems – FHIES 2013 Luciana Tricai Cavalini, MD, PhD Department of Health Information Technology Rio de Janeiro State University, Brazil Timothy Wayne Cook, MSc Founder, MLHIM Laboratory CEO, MedWeb 3.0
  2. 2. Summary  Background  Objective  Method  Overview of the MLHIM Specifications  Description of the MLHIM Reference Model  Demo Application Development  Results  Data Modeling  The Proof of Concept of Semantic Interoperability  Discussion  Relationship to Model-Driven Architectures  Relationship to OWL and RDF  Relationship to Other Standards  Limitations  Conclusions
  3. 3. Background (1)  The deployment of IT products has been proposed since 1961 in order to solve problems in different dimensions of healthcare systems  Such expectations are yet to be met in developed countries, and so far they only increase the costs of healthcare systems in developing countries
  4. 4. Background (2)  The ~65% failure of healthcare IT projects is related to the dismissal of the unique complexity and dynamics of the biomedical ecosystem (lives <- > healthcare systems)  The number of biomedical concepts is large, increasing in number and complexity over time, and consensus among experts is difficult to achieve because of the liberal origins of the medical profession
  5. 5. Background (3)  During his/her lifetime, a person will visit dozens of healthcare providers, scattered around an undefined geographical area; all those visits have a probability > 0 of affecting the future ones  Thus, ideally, data instances generated in each one of those medical encounters should be exchanged in a semantically valid way among all medical applications involved
  6. 6. Background (4)  In present, there are many private companies and governmental agencies whose mission is to develop healthcare information systems, each of them implementing their own data model  Those data models are different from system to system AND they have to be continuously changed over time to catch up with the fast evolution of biomedical science
  7. 7. Background (5)  The mainstream solution for solving the problem of semantic interoperability in healthcare is proposing consensus on ontologies, terminologies or top-down data modeling standards  So far, the only method that has been proven in software to achieve semantic interoperability is multilevel modeling
  8. 8. Multilevel Modeling (1)  The original multilevel modeling specifications were proposed by the openEHR Foundation  Aspects of the openEHR specifications were adopted in the ISO 13606 Standard  Both proposals have low level of adoption in the global healthcare IT community
  9. 9. Multilevel Modeling (2)  The current version of the ISO 13606 Standard does not allow for data persistence, only messaging exchange between systems  Low adoption of openEHR is attributed to:  High complexity of the specifications  Use of a Domain Specific Language for development of clinical data models
  10. 10. Given the fact that multilevel modeling provides semantic interoperability, but there is a need to make it implementable for real healthcare applications; This paper has the objective to: • Present the main features of an XML-based multilevel modeling specification • Describe the proof of concept of semantic interoperability achieved with two demo applications Objectives
  11. 11. Method  Implementation of the Multilevel Healthcare Information Modeling (MLHIM) Specifications  Reference Model  Domain Model  Proof of concept of semantic interoperability  Implementation of two demo apps  Semantic validation of data coming from both
  12. 12. The MLHIM Specifications (1)  MLHIM Reference Model (RM) (1)  The abstract MLHIM RM consists of classes and attributes – necessary and sufficient – to build any healthcare application  This minimalistic approach makes MLHIM the only multilevel model specification that allows the development of mobile applications
  13. 13. The MLHIM Specifications (2)  MLHIM Reference Model (RM) (2)  The MLHIM RM is implemented in XML Schema 1.1  The MLHIM RM abstract classes are defined as complexTypes arranged as ‘xs:extension’  Each complexType has an ‘element’ definition  The ‘elements’ are arranged in substitution groups, in order to replicate the multiple class inheritance capability of the abstract RM
  14. 14. The MLHIM Specifications (3)  MLHIM Domain Model (DM) (1)  The MLHIM DM is expressed as Concept Constraint Definitions (CCD)  An abstract CCD is defined by the combination and restriction of the RM classes and its attributes that are necessary and sufficient to model any biomedical concept
  15. 15. The MLHIM Specifications (4)  MLHIM Domain Model (DM) (2)  The implementation of CCDs in XML Schema 1.1 expresses:  The combination of complexTypes in multiple substitution groups  The definition of restrictions to the complexType elements
  16. 16. The MLHIM Specifications (5)  MLHIM Domain Model (DM) (3)  CCDs are identified by Type 4 Universal Unique Identifiers (UUIDs)  That allows n > 1 CCDs for the same biomedical concept, all of them semantically valid according to the MLHIM RM  Thus, the MLHIM knowledge modeling governance is decentralized and it does not require timely and expensive top-down consensus required for all other HIT standards
  17. 17. The MLHIM Specifications (6)  MLHIM Domain Model (DM) (4)  Each complexType of a CCD is also identified by UUIDs, which allows:  Wide reuse of MLHIM clinical data models – the Pluggable complexTypes (PCTs)  The probability of semantic conflict between two different CCD or PCT implementations of the same concept is zero
  18. 18. The MLHIM Specifications (7)  MLHIM Domain Model (DM) (5)  CCDs can accommodate any number of terminologies and ontologies:  Specific term codes or ontology terms can be linked to its correspondent complexType as computable application information in the ‘annotation’ element  RDF content can also be included, making the MLHIM- based ecosystem fully integrated to the Semantic Web
  19. 19. The MLHIM Specifications (8)  Additional Features  The MLHIM specifications validates the semantics of missing data, since the MLHIM data type complexTypes carry a ‘ev’ element  Very important: MLHIM is only concerned with semantic interoperability of biomedical applications. Implementation issues are outside the scope of the specifications (e.g., persistence model, authentication etc).
  20. 20. MLHIM Reference Model (1)  Datatypes Package  Inspired on the ISO 21090 and openEHR data types  Ordered data types: ordinals (ranks and scores), dates and times and true numbers (quantities, counts and ratios); reference ranges are defined as intervals  Unordered data types: characters, parsable, multimedia and Booleans
  21. 21. Fig. 1. UML diagram of the MLHIM Reference Model – Datatypes package.
  22. 22. MLHIM Reference Model (2)  Structures Package  ItemType descendants:  ClusterType: it can contain other ClusterTypes or any number of ElementTypes  ElementType: the leaf variant if ItemType, to which a datatype is attached
  23. 23. Fig. 2. UML diagram of the MLHIM Reference Model – Structures package.
  24. 24. MLHIM Reference Model (3)  Content Package  EntryType descendants:  CareEntryType: defines structure, protocol and workflow attributes for any clinical information  DemographicEntryType: defines structure for demographic data, separated from other EntryTypes to allow built-in data anominization  AdminEntryType: defines structure for administrative healthcare data
  25. 25. Fig. 3. UML diagram of the MLHIM Reference Model – Content and Contraint packages.
  26. 26. MLHIM Reference Model (4)  Common Package Parent Type complexType Usage PartyProxyType PartySelfType PartyIdentifiedType Representing the subject of the record Proxy data for an identified party other than the subject of the record xs:anyType ParticipationType AttestationType FeederAuditType FeederAuditDetailsType Modeling participation of a Party in an activity Recording an attestation of item(s) of record content by a Party Audit and other meta-data for software applications and systems in the feeder chain Audit details for any system in a feeder system chain ExceptionalValueType See Cavalini and Cook, 2012 See Cavalini and Cook, 2012
  27. 27. Fig. 4. UML diagram of the MLHIM Reference Model – Common package.
  28. 28. Proof of Concept (1)  Two demo applications were developed based on the MLHIM Demo EMR  Demo 1: Demographic and Vital Signs  Demo 2: Demographic and Basic Metabolic Panel  Source data models: NCI Common Data Elements (CDE) repository  Selected CDEs were modeled as CCDs with the CCD-Gen application
  29. 29. Proof of Concept (2)  The oXygen XML editor version 14.2 was used for:  Create and Validate the MLHIM RM Schema  Validate the CCDs generated by the CCD-Gen  Generate and validate simulated data for both applications  Persist the XML instances in its embadded eXist-DB database  oXygen delegates validation of XML Schemas and XML documents according to the W3C XML specifications to the Xerxes and Saxon-EE XML parsers/validators
  30. 30. Results (1)  Data Modeling  Three CCDs were created:  Demographic (DemographicEntry)  Vital Signs (CareEntry)  Basic Metabolic Panel (CareEntry)
  31. 31. Demographic CCD PCTs CCD Data Element Data Type Demograhic Gender Zip Code State City Driver License no. Social Security no. Phone no. Email address First Name Last Name DvString with enumeration DvIdentifier DvCodedString DvCodedString DvIdentifier DvIdentifier DvString DvURI DvString DvString
  32. 32. Vital Signs CCD PCTs CCD Data Element Data Type Vital Signs Systolic Pressure Diastolic Pressure BP Device Type Cuff Location Patient Position Heart Rate Respiration Body Temperature Temperature Location Temperature Device DvQuantity DvQuantity DvString with enumeration DvString with enumeration DvString with enumeration DvCount DvCount DvQuantity DvString with enumeration DvString with enumeration
  33. 33. Basic Metabolic Panel CCD PCTs CCD Data Element Data Type BMP Sodium Potassium Glucose Urea Creatinine DvQuantity DvQuantity DvQuantity DvQuantity DvQuantity
  34. 34. Results (2)  Data Simulation (1)  The Demographic CCD was used to generate 130 XML instances of fictitious patients  66 of them were replicated into both Demo applications  32 of them were persisted only in one of the two Demo applications
  35. 35. Results (3)  Data Simulation (2)  n (n = 1, 2, 3, …) simulated instances of the Vital Signs and Basic Metabolic Panel CCDs were generated for each correspondent Demographic CCD  Example: 1,531 data instances of the Diastolic Blood Pressure were generated
  36. 36. Results (4)  Data Validation  Data validation followed a backward validation chain, from the XML instance to the W3C specifications:  The XML instances were valid according to their correspondent CCDs  The CCDs were valid according to the MLHIM Reference Model Schema  The MLHIM RM Schema was valid according to the XML Schema 1.1 specifications  The XML Schema 1.1 specification is valid according to the W3C XML Language specifications
  37. 37. Discussion (1)  This paper presented the development of a multilevel model, XML-based implementation of a proof of concept of semantic interoperability with the Multilevel Healthcare Information Modeling (MLHIM) specifications  MLHIM allows:  Implementation of any size of biomedical applications  Persistence in No-SQL and SQL databases  Adoption of semantic web technologies by RDF and OWL markup of CCD Schemas (not the instance data!)
  38. 38. Discussion (2)  Relationship to Model-Driven Architecture  MDA is concerned with the overall architecture of a specific software  This is outside the scope of MLHIM, whose only concern is providing an environment for semantic interoperability  Using Eclipse to implement the MLHIM Reference Model created Eclipse dependencies on the XML code that created undesired lock-up to the framework
  39. 39. Discussion (3)  Relationship to OWL and RDF (1)  The Semantic Web technologies are the next stage of the original idea of proposing controlled vocabularies to solve semantic interoperability issues  In present, OWL and RDF lack the expressiveness, syntactic structure and completeness, as well as the relationship to XPath and Xquery, that XML Schema provides
  40. 40. Discussion (4)  Relationship to OWL and RDF (2)  MLHIM uses RDF and OWL as it was originally intended: to link to expanded semantics on the CCD Schema and NOT on the XML data instance  With maturity of OWL and RDF, and the convergence of their current syntaxes to a more robust specification, it might be possible in the future to implement the MLHIM RM in OWL and/or RDF
  41. 41. Discussion (5)  Relationship to Other HIT Standards (1)  MLHIM is the harmonization of HL7 and openEHR  openEHR implementation is challenging:  The archetype formalism has a long learning curve  The archetype governance model is top-down  The openEHR RM has to be implemented in every application, because there are no external validation tools
  42. 42. Discussion (6)  Relationship to Other HIT Standards (2)  Regarding HL7v3:  It is not multilevel modeling, so there is no validity chain back from the data instance to a common RM – the RIM allows expansions  The HL7v3 Common Definition Architecture is been proposed as an implementation of RIM, but the Schemas are top-down and too large for use in mobile applications
  43. 43. Discussion (7)  Relationship to Other HIT Standards (3)  HIE and S&I:  Healthcare Information Exchange (HIE): it is a ‘top of mind’ acronym for semantic interoperability, although it only defines standardized workflows  Standards & Interoperability (S&I) Framework: same as the HL7v3 CDA, it is a top-down clinical data model
  44. 44. Discussion (8)  Limitations of MLHIM  Resistance to innovation adoption:  Multilevel modeling  How MLHIM uses XML technologies  How MLHIM uses Semantic Web technologies  Competing interests  Engaging domain experts
  45. 45. Conclusion  Future Work  Deploying a enterprise-scale implementation of MLHIM  Engaging medical (healthcare) students to become Domain Modelers
  46. 46. lutricav@mlhim.org tim@mlhim.org https://www.facebook.com/mlhim2 http://gplus.to/MLHIMComm @mlhim2 https://www.youtube.com/user/MLHIMdotORG Thank you!

×