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!