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.

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Fig. 1. UML diagram of the MLHIM Reference Model – Datatypes package.

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. Fig. 2. UML diagram of the MLHIM Reference Model – Structures package.

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. Fig. 3. UML diagram of the MLHIM Reference Model – Content and Contraint
packages.

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. Fig. 4. UML diagram of the MLHIM Reference Model – Common package.

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. 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. Results (1)
 Data Modeling
 Three CCDs were created:
 Demographic (DemographicEntry)
 Vital Signs (CareEntry)
 Basic Metabolic Panel (CareEntry)

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. 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. Basic Metabolic Panel CCD PCTs
CCD Data Element Data Type
BMP
Sodium
Potassium
Glucose
Urea
Creatinine
DvQuantity
DvQuantity
DvQuantity
DvQuantity
DvQuantity

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Conclusion
 Future Work
 Deploying a enterprise-scale implementation of
MLHIM
 Engaging medical (healthcare) students to become
Domain Modelers

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!