Personalized-Detailed Clinical Model for Data Interoperability Among Clinical Standards

Abstract

Objective: Data interoperability among health information exchange (HIE) systems is a major concern for healthcare practitioners to enable provisioning of telemedicine-related services. Heterogeneity exists in these systems not only at the data level but also among different heterogeneous healthcare standards with which these are compliant. The relationship between healthcare organization data and different heterogeneous standards is necessary to achieve the goal of data level interoperability. We propose a personalized-detailed clinical model (P-DCM) approach for the generation of customized mappings that creates the necessary linkage between organization-conformed healthcare standards concepts and clinical model concepts to ensure data interoperability among HIE systems. Materials and Methods: We consider electronic health record (EHR) standards, openEHR, and HL7 CDA instances transformation using P-DCM. P-DCM concepts associated with openEHR and HL7 CDA help in transformation of instances among these standards. We investigated two datasets: (1) data of 100 diabetic patients, including 50 each of type 1 and type 2, from a local hospital in Korea and (2) data of a single Alzheimer's disease patient. P-DCMs were created for both scenarios, which provided the basis for deriving instances for HL7 CDA and openEHR standards. Results: For proof of concept, we present case studies of encounter information for type 2 diabetes mellitus patients and monitoring of daily routine activities of an Alzheimer's disease patient. These reflect P-DCM-based customized mappings generation with openEHR and HL7 CDA standards. Customized mappings are generated based on the relationship of P-DCM concepts with CDA and openEHR concepts. Conclusions: The objective of this work is to achieve semantic data interoperability among heterogeneous standards. This would lead to effective utilization of resources and allow timely information exchange among healthcare systems.

Introduction

Telemonitoring has emerged as an active area of research over the past few years, where physicians tend to effectively involve remotely in a patient's care for meeting high standards of healthcare. Personalized medicine envisions bringing healthcare stakeholders under a single platform to individualize prevention, diagnosis, and treatment of a person's disease.¹ The goal of a health information exchange (HIE) system is to facilitate physicians accessing and retrieving clinical data to provide safer, timely, efficient, effective, equitable, and patient-centered care.² “HIE refers to the technological network infrastructure, that has the chief purpose of assuring accurate medical information exchange.”³ HIE systems try to ensure realizing the concept of personalized medicine; however, they face major challenges of interoperability because of difficulty in integrating data from heterogeneous data sources. This objective of personalized medicine using HIE systems can be achieved by using a detailed clinical model (DCM). DCMs provide methodology for structuring medical information by combining expert knowledge, data specification, and terminology and enable various technical applications.⁴ DCM allows its use in multiple standards by making clinical data explicit.⁵ A common DCM gives precise semantics and makes the task of mapping between models manageable.⁶

DCM's effectiveness can be observed from an international collaboration initiative, the Clinical Information Modeling Initiative (CIMI), which is “dedicated to provide a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents.”⁷ The CIMI team has so far agreed to create and use a single logical representation called the CIMI core reference model, comprising one or more models as the basis for interoperability across formalisms.⁸

The envisioned CIMI core reference model considers the use of the already existing HL7 V3 reference information model (RIM) and open electronic health record (EHR) information models. OpenEHR is a healthcare standard based on a two-level modeling approach: a RIM and clinical content representation in archetypes and templates form.⁹ Archetypes and templates are the formal models of domain concepts controlling data structure and content of data.¹⁰ Archetypes are the constraints based models of domain content expressed in a formal language called archetype definition language.¹¹ Another clinical standard that specifies the structure and semantics of “clinical documents” for the purpose of medical information exchange is called HL7 CDA.¹² HL7 CDA is based on RIM to generate clinical documents. RIM is the critical component of the development process of HL7 messages and is the root of all the information models. It consists of backbone classes, their specialization, and structural attributes for further defining the roles of the classes.¹³ The core classes include Act, Entity, Role, Act Relationship, and Participation. These core classes are further divided into subclasses used for the generation of HL7 messages. Both openEHR and HL7 standards are based on reference models that contain similarities and differences between them. This would require consideration of concepts of both the models to be made part of a single generic model, easily adaptable for both standards. The CIMI group's vision of a single model is handled by using ontology mappings in our work.¹⁴ In our previous work, we took initial steps toward the development of an interoperable system by combining the information of HL7 and openEHR standards using ontology mappings and expert verification. We call these mappings “generalized mappings.” Although these mappings achieve accuracy to a certain level, they still lack completeness at instance-level transformations. This is because healthcare organizations conform to concepts of different standards based on their information requirement. This leads to missing mapping information problem in our previous work.¹⁴ Personalized-DCM (P-DCM) encouraged us to extend our previous solution to propose a solution to enhance efficiency of the system and to provide more accurate mapping and minimize the role of human experts. Therefore, the concept of P-DCM is useful in achieving true semantic data interoperability among HIEs.

P-DCM behaves as a centralized entity, easily used by healthcare standards according to their structure and format. The association of P-DCM concepts with different standard concepts creates mapping relationship and results in customized mapping generation. Mapping relationships based on P-DCM are used when the service is unable to transform particular concepts of source instance into target instance. We are using P-DCMs to achieve true semantic data interoperability among HIEs compliant with heterogeneous standards. For the proof of concept, we developed P-DCMs for diabetes and Alzheimer's disease patient data, which are presented in Results. The diabetes P-DCM is based on data of 100 patients from the hospital management information system (HMIS) of a local hospital in Korea, whereas the Alzheimer's disease P-DCM is based on Alzheimer's patient data gathered from a home healthcare monitoring system (HHMS). Our work¹⁵ describes Alzheimer's patient data transformation into heterogeneous standards. Instances of openEHR (called extracts) and CDA are derived from the P-DCM. This mapping information is stored in the mapping file.

The proposed approach provides data interoperability between HIEs that are compliant with clinical standards. Data interoperability is based on mappings that require a higher level of accuracy. Initially, we focused on accuracy using ontology matching techniques to generate generalized mappings by using clinical standards information. The level of accuracy was not appropriate for information to be exchanged seamlessly among HIEs; therefore we propose the P-DCM approach as our second step. Our P-DCM approach achieves a high level of accuracy by considering organizational information in the mapping process in the form of customized mappings. This leads to resolving heterogeneities among clinical standards and ensures seamless communication between HIEs.

Semantic Interoperability Artifacts

Semantic interoperability is one of the vital challenges faced by the healthcare community. The concept of semantic stack, elaborated in an Internet publication on clinical information models,¹⁶ deals with the semantic interoperability artifacts. The stack deals with data, information, and clinical pathways necessary for documentation of the patient record.¹⁶ The stack defines different models that include the Model of Knowledge (ontologies), the Model of Meaning (vocabularies), the Model of Use (DCM or archetypes), the Model of Syntaxes (archetype object model), and the Model of Documentation, Archiving, and Exchange. Although the semantic stack covers most of the artifacts necessary for semantic interoperability, it still lacks a model that can ensure complete, accurate, and true semantic interoperability that considers an organization's clinical model and its representation. Conformance claim plays an important role in semantic interoperability, where healthcare organizations represent clinical concepts by using specific set of concepts of different healthcare standard formats based on their requirements. For example, HL7 provides artifact “interactions” that are used for communicating HL7 messages between medical systems. Each domain (laboratory, patient administration, and others) in the HL7 specifications provides a specific set of interactions for exchange of messages. Laboratory domain interactions include Order, Promise, and Result interactions, with each having a further set of interactions. Organizations can conform based on their requirements to these interactions, such as conforming only to the set of Order and Result interactions. Therefore, a model is necessary that focuses on organization conformance claims to complete the semantic stack. We call this model the “Model of Purpose,” and it deals with the concept of P-DCM. To increase the effectiveness of using all the models, the personalization concept is necessary. The Model of Purpose is related with all the other models in Figure 1.

Fig. 1.

Modified semantic stack¹⁶ with personalized-detailed clinical model (DCM).

In summary, healthcare standards are striving hard and provide the basis for interoperability; however, achieving interoperability at the data level is still a bottleneck for integration of healthcare systems compliant with heterogeneous healthcare standards. Each standard defines clinical concepts that are not understandable outside the scope of that standard.¹⁷ Ontology matching is one of the methods to integrate these heterogeneous standards but lacks application because of organizations' conformance to artifacts based on their requirements.

The Model of Knowledge uses ontology for resolving heterogeneities but is limited to handling generalized mappings. For example, HL7 RIM ontology (www.w3.org/wiki/images/2/2e/HCLS$$ClinicalObservationsInteroperability$$HL7CDA2OWL.html$notes.html), openEHR ontology (http://trajano.us.es/∼isabel/EHR/), and systematized nomenclature of medicine clinical terms (SNOMED CT) ontology (http://krono.act.uji.es/people/Ernesto/umlsassessment/SNOMED-ontology.zip/view) are some of the healthcare standard ontologies that can be mapped to one another, resulting in generation of generalized mappings. Generalized mappings include mappings between standard ontologies based on their reference models. HL7 RIM ontology and openEHR ontology matching results in generation of generalized mappings (the Entity concept of HL7 RIM ontology mapped with the Actor concept of openEHR ontology).

The Model of Purpose is related to the Model of Knowledge as it is based on P-DCM to generate customized mappings for increased mappings accuracy level with generalized mappings. Generalized mappings are based on the generic approach of matching multiple standard ontologies using ontology matching techniques, whereas customized mappings are based on the specific approach of matching a particular information model reflecting that organization's requirements by relating them with concepts of multiple standards. Therefore, distinction between generalized and customized mappings is the addition of the P-DCM concept in customized mappings for a higher level of accuracy. For example, mapping of the Observation concept of the openEHR standard with the Observation concept of the HL7 standard is generalized mapping, whereas the Complication (P-DCM concept) concept used to identify the problem of a particular patient in the healthcare organization can be mapped with the observation concept of HL7 and the Section concept of the openEHR standard. Therefore, communication between two HIEs compliant with openEHR and the HL7 standard would be accurate if customized mappings are used to interpret the Complication concept in these standards rather than generalized mappings.

The Model of Meaning provides standard-based clinical terminologies information; few of the standard vocabularies include SNOMED CT (www.ihtsdo.org/snomed-ct/), Mesh (www.nlm.nih.gov/mesh/), and ICD-10 (http://apps.who.int/classifications/icd10/browse/2010/en).

The Model of Use provides the initial platform for formulating the clinical information to the Model of Purpose. It provides a generic structure to clinical concepts in the form of DCMs. The Blood Pressure DCM and the Cholesterol DCM are two examples of the Model of Use.

The Model of Syntaxes is based on specific standard-based structure/format for representing clinical concepts. The openEHR standard archetype is one of the examples of representing clinical concepts.

The specification of how the clinical information should be modeled in standard format is represented by the Model of Documentation. Examples include HL7 CDA and CEN 13606 standards specification.

The Model of Purpose is also related to the Model of Syntaxes and the Model of Documentation for conformance purpose. Conformance to healthcare standard artifacts by organizations plays a key role in data interoperability. For example, the HL7 Laboratory domain provides a set of interactions divided into three categories: Order, Promise, and Result. Consider an organization conforming to Order and Result interactions and not Promise interactions, requiring these interactions binding with clinical concepts in some model. The Model of Purpose relates clinical concepts with each interaction in Order and Result interactions for communication. Each time the interaction takes place, the associated messages containing specific data and concepts would be communicated. The Test Order message is conformed to one of the Order interactions modeled in the Model of Purpose, ensuring that the Test Order message is always communicated by Order interaction. On the other hand, in the current scenario the organization is not conformed to Promise interactions as per its requirements; therefore these interactions will not take place. In this way, the Model of Purpose relates with other models to ensure data interoperability.

Existing Systems Literature Review

Many systems exist for achieving data-level interoperability among heterogeneous healthcare standards. Dogac et al.¹⁸ proposed a Web services-based Artemis architecture that is based on ontologies for handling semantic mediation among health information systems. The main focus of this work is to enable communication among health information systems that are compliant with HL7 V2 and V3 standards. Sahay et al.¹⁹ also worked on integration of HL7 V2 and V3 standards by developing ontologies and their alignments; their PPEPR methodology is used for building ontologies and is deployed under semantically enabled healthcare integration framework. Layers are defined as input and output layers containing global and message ontologies for conversion among incompatible message instances of heterogeneous standards.

Maldonado et al.²⁰ developed a tool called LinkEHR-Ed that is used for building, processing, and validating archetypes based on multiple reference models. The LinkEHR-Ed tool supports HL7 CDA, openEHR, and CEN 13606 standards reference models and builds archetypes based on their reference models. Kilic and Dogac²¹ proposed mapping algorithms that were used for generating mapping definitions. These mapping definitions were used for transformations among HL7 clinical statements instances and EHRcom instances, The work of Martinez Costa et al.²² focused on dual-model architecture standards transformation. CEN 13606 and openEHR standards archetypes and extracts transformation are discussed and validated using the Poseacle Converter.²³ The transformations were performed at archetype and data levels. Our previous work²⁴ focused on semantic process interoperability with the help of interaction ontology in HL7 V3. Interaction ontology is responsible for handling the heterogeneities between processes of different healthcare organizations compliant with the HL7 V3 standard. This work is only related to semantic process interoperability using standard HL7 V3, and semantic data interoperability is not discussed.

Galarraga et al.²⁵ presented a review about the role of the ISO/IEEE 11073 family of standards for interoperability in telemonitoring. The focus of the study was on resolving barriers like heterogeneity of devices and systems and difficulty of its integration with HMIS. They mostly focused on device-level interoperability using ISO/IEEE 11073 standards, leaving aside data-level interoperability. Lee and Gatton²⁶ described a technique based on a home healthcare monitoring system data exchange scheme between the HL7 standard and the IEEE 1451 standard. The IEEE 1451 standard defines a suite of interfaces that communicates among heterogeneous networks, whereas the HL7 standard is used for medical information exchange among medical organizations. The CIMI⁷ is an initiative started by healthcare standards stakeholders. This group is dedicated to providing a common format for detailed specifications to represent health information content so that semantically interoperable information can be exchanged. The basic purpose is to define DCMs in a generic format that can easily be converted to any standardized format.

Semantic interoperability at the data level is mainly targeted by the systems discussed. Most of these systems are based on ontologies for generating semantic mappings. Ontology mappings have limitations resulting in manual mappings and expert verifications. The main concerns with these systems are accuracy of the mappings, evolution of the mapping files or bridge or common ontology, and definition of clinical information independent of any specific clinical standard. In this study, we propose a system that could achieve transformations among HL7 CDA and openEHR standards by achieving a high level of accuracy.

The mentioned concerns are addressed at two levels: reference model-level mappings (addressed by Khan et al.¹⁴) and clinical information defined in the form of DCMs. A DCM allows clinical information transformation into different standards. This also adds to the accuracy of mappings and results in true data interoperability.

Materials and Methods

Proposed System Working Model

In our previous work, the Accuracy Mapping Engine¹⁴ generated the mapping file that was verified by experts to ensure accuracy of mapping between openEHR and HL7 CDA. Although it resolved the heterogeneity issue at the reference model level, instance-level mapping still faced missing mappings for different concepts. The DCM encouraged us to combine our previous solution with the proposed one to enhance efficiency of the system and provide more accurate mappings and minimize the role of human experts. Also, accuracy is further improved by introducing the concept of P-DCM. This certainly adds to automation of the system in instance transformation phase at the run time described by the Accuracy Mapping Engine. This section explains the working model of the system, as shown in Figure 2.

Fig. 2.

Working model. DCM, detailed clinical model; EHR, electronic health record; P-DCM, personalized-detailed clinical model.

Building The P-DCM

Building the P-DCM requires understanding clinical concepts (such as diabetes) and also how a clinical concept is formulated for data capturing by HIEs (such as the Subjective, Objective, Assessment, Plan [SOAP] method of documentation). Because of these constraints, organizations can conform to particular concepts of different standards for creation of an EHR document. This adds the personalization aspect and thus requires customized mappings as a solution. P-DCM development follows three steps: identifying the clinical concept, identifying the structure of clinical concepts recording by HIE, and, lastly, building the P-DCM based on the clinical concept and the way its information is structured. First, each clinical concept is made up of some constructs; therefore identification of the clinical concept is necessary, such as diabetes, Alzheimer's disease, or cancer. This analysis would result in identification of all the related observations, history, medication, and recommendations in the domain of a particular clinical concept. Second, clinical concept information documentation is identified that provides the baseline for modeling P-DCM. SOAP, Data, Assessment and Plan, Functional Outcomes Reporting, and narrative notes are a few of the examples for structuring the notes about medical records of a patient. Lastly, modeling P-DCM based on the information obtained from the first two steps is performed. This is performed by modeling the clinical concept information into classes, attributes, and data types. Modeling P-DCM allows easy association of its concepts with the clinical standards concept, thus resulting in generation of customized mappings.

In order to analyze the development of P-DCM, we gathered data from about 100 diabetic patients from a local hospital in Korea, including 50 patients each having type 1 and type 2 diabetes. Also, we gathered information about Alzheimer's disease patients by monitoring their daily life activities using sensory devices. We developed the P-DCM for type 2 diabetic patients, shown in Table 1, and for an Alzheimer's disease patient, shown in Table 2.

Table 1.

Hospital Management Information System-Based Personalized-Detailed Clinical Model and Clinical Information

HMIS-BASED P-DCM	CLINICAL INFORMATION
Package DiabetesMellitus_Type2_V1	Package ClinicalInformation
imports ClinicalInformation	imports Datatypes
imports Datatypes	class Observation
	Title: SET
class Subjective	Value: Any
Complaint: Observations	Text: ED
Allergies: Observations	Device: SC CWE
Medications: Medication	CodingSystem: CD
…	ObservationValue: PQ
class Objective	…
ClinicalObservations: Observation
…	class Medication
class Assessment	Title: SET
Complications: Observation	DoseQuantity: IVA<PQ>
…	Notes: ED
class Plan	…
Exercise: Observation	EndPackage
Medication: Observation
…
EndPackage

HMIS, hospital management information system; P-DCM, personalized-detailed clinical model; PQ, physical quantity.

Table 2.

Home Healthcare Monitoring System-Based Personalized-Detailed Clinical Model

HHMS-BASED ALZHEIMER'S DISEASE PATIENT P-DCM
Package Alzheimer_Patient_Activities_Monitoring_V1
imports Datatypes
class Activities
Activity: String
Type: String
SensorID: Integer
DetectedBy: String
ActivityName:
String Time: DateTime
EndPackage

HHMS, home healthcare monitoring system; P-DCM, personalized-detailed clinical model.

Conformance Manager

The Conformance Manager handles the association of P-DCM concepts with openEHR and HL7 CDA concepts. The conformance is based on the HIE requirement to represent P-DCM concepts with specific concepts of both standards. With each and every entity, attribute, data type, or unit of openEHR and the HL7 CDA template, a concept of P-DCM is associated. As an example, P-DCM's concept Relationship conforms to the Party Relationship and Relationship Link concepts of openEHR and the HL7 CDA template, respectively.

DCM Rule Manager and Customized Mappings

The DCM Rule Manager generates rules in the form of Customized Mappings in addition to Generalized Mappings and is used by the Accuracy Mapping Engine for instance-level transformation. Customized Mappings are the mappings based on P-DCM concepts and their relationship with openEHR and CDA concepts, whereas Generalized Mappings are generated by matching ontologies of both the standards. Equation 1 shows the transitive relationship, with each concept of P-DCM conformed to particular concepts of CDA and openEHR. Therefore concepts of CDA and openEHR bridged by the P-DCM concept are similar in relationship. For example, x is the Relationship concept of P-DCM, y is the Party Relationship concept of the openEHR demographics model, and z is the Relationship Link concept of the HL7 CDA RIM. The Party Relationship and Relationship Link concepts are derived from the Relationship concept; therefore both standard concepts are similar and can be mapped in instance transformation. To derive concepts from P-DCM means to associate P-DCM concepts with different standard concepts for its representation in clinical document generation for exchange of information. This information is further stored in the mapping file: \documentclass{aastex}\usepackage{amsbsy}\usepackage{amsfonts}\usepackage{amssymb}\usepackage{bm}\usepackage{mathrsfs}\usepackage{pifont}\usepackage{stmaryrd}\usepackage{textcomp}\usepackage{portland, xspace}\usepackage{amsmath, amsxtra}\pagestyle{empty}\DeclareMathSizes{10}{9}{7}{6}\begin{document} \begin{align*} \begin{split}& :Def - transitive Of \ @ swrl ( ( ? x \ transformTo \ ? { \rm y}) \\ & ( ? { \rm x} \ transformTo \ ? { \rm z} ) \rightarrow \\& ( ? { \rm y} \ transformTo \ ? { \rm z} ) ) for All \ unique \ { \rm x} \end{split} \tag{1} \end{align*} \end{document}

P-DCM-Based Customized Mappings Generation Algorithm

Algorithm 1 describes the P-DCM concepts C_i associated with concepts S_sC_p and T_wC_k of two different standards. Standard 1 and 2 concepts are derived from P-DCM concepts using the transformation functions C.Match(S_sC_p) and C.Match(T_wC_k). This association of concepts results in generating customized mappings CustomizedMappings[j]. CustomizedMappings[j] mappings are based on relation of P-DCM concepts with both standard concepts ∃ {x|x ∈S_sC_p [i], x ∈C_i }≡}y|y ∈T_w C_k [i], y ∈C_i }. Finally, CustomizedMappings are stored, and these are used for transformation among standards format:

Results

A DCM represents knowledge about the clinical concepts, and when they are designed based on the interpretation of an organization, it becomes P-DCM. The information of P-DCM requires representation in standard formats for sharing, paving the way for standards like HL7 and openEHR. The bonding of P-DCM with these standards defines the level of data interoperability. This section explains how the approach of P-DCM can be associated with healthcare standards to generate customized mappings for data interoperability. To demonstrate the approach, we present two case studies of HMIS (related to diabetes)- and HHMS (related to Alzheimer's disease)-based P-DCM. Initially, P-DCM is defined such that it models the clinical concept in a format that satisfies the information and structure an organization intends for representation. The next step is association of P-DCM concepts with standard concepts, hence generating customized mappings. We showed these customized mappings and how these can help in generating different standard formats. A simple example is a healthcare organization using these mappings to share or exchange the same information with two different healthcare organizations, having one compliant with HL7 and other with the openEHR standard. To further illustrate, we discuss two case studies in the following subsections.

Case Study A: Hmis-Based P-DCM

For proof of concept, we created instances from the P-DCM and clinical information as described in Table 1. The P-DCM is based on the SOAP pattern, adopted by local hospitals' staff in Korea to record diabetes patients' data at different encounters. Therefore, we modeled the P-DCM to represent information about the clinical concept (in this case diabetes) using the SOAP pattern used by the organization. The first column in Table 1 shows P-DCM having classes and the information of each class. Subjective is a class that represents clinical information concepts like Complaint, Allergies, and Medication. Each clinical information concept is represented by a clinical modeling concept such as representation of the clinical information concept Complaint with the clinical modeling concept Observation. Each clinical modeling concept contains attributes that have data types, represented in the second column of Table 1 as clinical information. The clinical modeling concept Observation has attributes like Title, Value, Text, and others with their data types such as SET, Any, Physical Quantity (PQ) as shown in Table 1. SOAP is a method of documenting patient-related data in sections. The instances in HL7 CDA and openEHR standard are thus derived from P-DCM. Figures 3 and 4 show portions of instances of CDA and openEHR standards, respectively, recording the blood pressure of the diabetic patient. Figure 3 represents the P-DCM concepts in HL7 CDA format; therefore mappings between P-DCM concepts and HL7 CDA concepts are generated. These mappings are stored as customized mappings as shown in Table 3. The first column of Table 3 shows P-DCM concepts with their values depicted in the second column; the fourth and fifth columns of Table 3 show HL7 CDA concepts that represent the P-DCM concepts, depicting the classes and their attributes used for representing P-DCM concepts. In the same way, Figure 4 represents the same P-DCM information in the openEHR standard that was earlier represented in the HL7 CDA format. The summary of the association of some of the P-DCM concepts with openEHR concepts is characterized in the third column of Table 3. These mappings help in achieving data interoperability among different HMISs compliant with various healthcare standards. In this case study, the HMIS can exchange information with other HMISs that are compliant with the openEHR and HL7 CDA standards, hence achieving data interoperability. We explain below the case study in more detail to provide insight into the working model of the proposed system.

Fig. 3.

CDA instance of a type 2 diabetes mellitus patient. PQ, physical quantity; SNOMED-CT, systematized nomenclature of medicine clinical terms.

Fig. 4.

Open electronic health record instance (extract) of a type 2 diabetes mellitus patient. SNOMED-CT, systematized nomenclature of medicine clinical terms.

Table 3.

Content Mapping of Clinical Information to HL7 CDA and Open Electronic Health Record

P-DCM CONCEPT	VALUE	OPEN EHR CLASS (ATTRIBUTE)	HL7 RIM CORE CLASS	HL7 CLASS (ATTRIBUTE)	TERMINOLOGY (VOCABULARY NAME)/VALUE
Assessment	Chronic disease assessment	Composition	Act	Organizer	Chronic disease follow-up assessment (SNOMED CT)
Complication	Non–insulin dependent diabetes mellitus	Section	Act	Observation	Non–insulin dependent diabetes mellitus (SNOMED CT)
Objective	(objective)	Section	ActRelationship	Entry	Objective observation (SNOMED CT)
Clinical Observation	Blood pressure	Observation	Act	Observation	On examination—blood pressure reading (finding) (SNOMED CT)

EHR, electronic health record; P-DCM, personalized-detailed clinical model; RIM, reference information model; SNOMED CT, systematized nomenclature of medicine clinical terms.

Sample ambulatory encounter data of a non–insulin-dependent diabetes mellitus patient with neurological complications are converted to both standard formats based on P-DCM. SNOMED CT terminologies are used as vocabularies for coding the data. The Section class in both standards is used for categorizing related information. The SOAP pattern creates sections based on information like the Objective section, used for categorizing observations. Therefore, the P-DCM concept Objective and its attributes are categorized in sections in both the openEHR and CDA standards. On the other hand, attributes of the Objective concept of P-DCM are categorized under the Observation class. Clinical information is represented by ClinicalInformation package, whereas the contents of the clinical information are represented in P-DCM. ISO 20190 standard data types are used for modeling P-DCM and ClinicalInformation models. Interesting mapping information is obtained at the attributes level, as shown in Figures 3 and 4.

The CodingSystem attribute of the Observation class in P-DCM is transformed with code attribute in CDA and defining code attribute in openEHR. Therefore, in CDA, the code attribute of the Observation class is mapped to the defining code tag of the openEHR extract. For blood pressure observation, both use SNOMED CT vocabulary; information about it is stored in the codeSystemName attribute of CDA, mapped to the terminology_id attribute of openEHR. Some of the mappings of CDA and openEHR concepts with P-DCM concepts are shown in Table 3. In the same way, blood pressure is measured in “mm Hg,” represented in P-DCM by the ObservationValue, recorded by data type PQ in CDA and data type DV_Quantity in openEHR, resulting in the DCM Rule Engine to generate the rule discussed in Eq. 1 above. The unit “mm Hg” from P-DCM annotates PQ and DV_Quantity by applying the DCM Rule Engine transitiveOf rule and creates mapping between these data types. These mappings are then made part of the mapping file created in our previous work, resulting in interoperability service performing transformations. The resulting mapping instance (Eq. 2) is derived and stored in the mapping file. The mapping instance hasSourceEntity refers to the HL7 CDA concept, and hasTargetEntity refers to the openEHR concept: \documentclass{aastex}\usepackage{amsbsy}\usepackage{amsfonts}\usepackage{amssymb}\usepackage{bm}\usepackage{mathrsfs}\usepackage{pifont}\usepackage{stmaryrd}\usepackage{textcomp}\usepackage{portland, xspace}\usepackage{amsmath, amsxtra}\pagestyle{empty}\DeclareMathSizes{10}{9}{7}{6}\begin{document} \begin{align*} \begin{split}& map : Mapping \_ \ Instance \_ \ 3321 a \\ & map:Mapping ; \\ & map:hasSourceEntity \ map : PQ; \\ & map:hasT arg etEntity \ map : DV \_ Quantity; \\ & map: pdcmConcept \ map:Observation Value; \\& map : hasSimilarityType \ ^{ \prime \prime} = ^{ \prime \prime}; \\ & map: hasSimilarityValue 1.0; \end{split} \tag{2} \end{align*} \end{document}

Case Study B: Hhms-Based P-DCM

We performed experiments on monitoring daily life activities of an Alzheimer's disease patient as a P-DCM case study in HHMS. The baseline of this work is the Human Activity Recognition Engine (HARE),²⁷ designed and developed by our lab for monitoring the activities of Alzheimer's disease patients. HARE focuses on monitoring human activities (with an Alzheimer's disease patient as the case study) using heterogeneous sensor technology. We extended this work in Khan et al.¹⁵ by introducing healthcare standards-based sensory data exchange among HMIS and HHMS. The P-DCM developed for this case study is shown in Table 2. We considered the home environment, which consists of a set of activities to be recognized; therefore P-DCM consists of the Activities class that has attributes like Activity, Type, SensorID, DetectedBy, ActivityName, and Time information. As discussed in our previous work,¹⁵ HHMS physicians of two different HMISs compliant with openEHR and HL7 CDA have subscribed to the HHMS. Therefore, mappings of P-DCM concepts are generated with openEHR and HL7 CDA concepts for exchange of information with these HMIS.

The information about the patient is collected using sensor application. Each activity consists of its type, which shows whether the patient is moving, sleeping, eating, or walking. These activities are identified by a particular sensor or camera (the example shows motion sensors, wearable sensors, and a two-dimensional camera). The sensors and cameras are provided with unique IDs. Date and time of the activity performed are also maintained in the repository. A threshold of 1 h is set for the data to be accumulated and stored in the HARE repository. This information is then transformed into CDA document and openEHR extract for communication with corresponding HMIS. Figure 5 shows the activities recognized in the home environment using sensors in CDA document format. This document is developed for exchange of information with the HMIS compliant with HL7 CDA. Mappings of the P-DCM concept with HL7 CDA concepts are shown in Table 4, with P-DCM concepts and its values in columns 1 and 2 and HL7 CDA concepts (classes and attributes) in columns 4 and 5.

Fig. 5.

Sample CDA of an Alzheimer's disease patient's activity. SNOMED CT, systematized nomenclature of medicine clinical terms.

Table 4.

Content Mapping of Activities to HL7 CDA and Open Electronic Health Record

P-DCM CONCEPT	VALUE	OPEN EHR CLASS (ATTRIBUTE)	HL7 RIM CORE CLASS	HL7 CLASS (ATTRIBUTE)	TERMINOLOGY (VOCABULARY NAME)/VALUE
Activities	(All activities)	Composition	Act	Organizer	Alzheimer's Disease Society member (SNOMED CT)
Activity	(Single activity)	Item Tree	Act	Component
Type	Motion	Observation	Act	Observation	Patient Works Away (SNOMED CT)
DetectedBy	Motion sensor	Element	Participation	Performer
			Role	AssignedEntity	Sensor Device (SNOMED CT)
			Entity	Device	Motion Sensor
ActivityName	Leaving bedroom	Contact	Participation	Participant
			Role	ParticipationRole	Home Health (HL7]
			Entity	PlayingEntity	Bedroom (SNOMED CT)
SensorID	1		Entity	AssignedEntity (ID)	1
Time	2011:05:16:01:00:00	Item (time)	Act	Observation (effective time)	20110516010000

EHR, electronic health record; P-DCM, personalized-detailed clinical model; RIM, reference information model; SNOMED CT, systematized nomenclature of medicine clinical terms.

The activities information recognized by the HHMS also must be exchanged with the HMIS compliant with the openEHR standard. Figure 6 shows the representation of P-DCM information in openEHR format. Mappings of P-DCM concepts with openEHR concepts are shown in Table 4, with openEHR concepts shown in the third column. The P-DCM concept has also created a link between HL7 CDA concepts and openEHR concepts, thus achieving data interoperability. A further detail about the mappings is provided in the next section.

Fig. 6.

Sample open electronic health record extract of an Alzheimer's disease patient's activity. SNOMED-CT, systematized nomenclature of medicine clinical terms.

Mapping Alzheimer's disease patient activities to HL7 CDA and openEHR

The activities of Alzheimer's disease patients are stored in the HARE repository. These activities are monitored in a home environment with the help of sensors and cameras and are part of the HHMS. We generated a HL7 CDA document and an openEHR extract from the activities information. HL7 CDA is generated from the standard CDA refined message information model that contains logically related classes for the CDA document generation, and the coded values are derived from standard vocabularies like SNOMED CT and HL7.

A sample CDA document generated is shown in Figure 5. Similarly, Figure 6 shows a sample openEHR extract from the activities. Table 4 summarizes the mappings of the patient's activities information with HL7 CDA and openEHR. It shows the tags and values of activities mapping to HL7 CDA and openEHR classes and attributes. The patient leaving his bedroom is categorized as Motion in the XML file, which is mapped with the Observation class of both the standards. Similarly, the motion sensor is mapped to the Device class in HL7 CDA but the Element class in openEHR.

Conclusions

Frequent exchange and storage of patient information among healthcare systems compliant with heterogeneous standards require true data-level interoperability. The proposed system is based on novel methodology by introducing the P-DCM concept for integration and interoperability among healthcare systems. OpenEHR and HL7 CDA instances are derived from the P-DCM to generate customized mappings. The P-DCM role in customized mappings among healthcare standards ensures consistent transformation of clinical information into a standard format. The proposed system achieves a high level of accuracy in mappings and instance transformation. The DCM would behave as a reference model for a particular disease, and our work is in progress to create such a DCM.

Footnotes

Acknowledgments

This research was supported by the Ministry of Knowledge Economy, Korea, under the Information Technology Research Center support program supervised by the National IT Industry Promotion Agency [grant NIPA-2012-(H0301-12-2001)].

Disclosure Statement

No competing financial interests exist.

References

Offit

. Personalized medicine: New genomics, old lessons. Hum Genet, 2011; 130:3–14.

Health information exchange. http://en.wikipedia.org/wiki/Health_information_exchange. 2012 March 10.

Health information exchange definition—Defined by experts. www.medical-record-coding.com/2011/12/health-information-exchange-definition/. 2012 September 14.

Detailed clinical model. www.detailedclinicalmodels.nl/dcm-en. 2012 September 14.

Goossen

. Using detailed clinical models to bridge the gap between clinicians and HIT. Stud Health Technol Inform, 2008; 141:3–10.

Parker

et al. Detailed clinical models for sharable, executable guidelines. Medinfo, 2004; 11:145–148.

CIMI [Clinical Information Modeling Initiative]. Clinical information modeling initiative goes with archetypes & UML profile. www.openehr.org/news_events/industry_news/20111214. 2012 March 2.

CIMI details. http://wiki.hl7.org/images/9/99/CIMI-Seeking-Clarity-20120108.pdf. 2012 March 16.

Architecture overview. www.openehr.org/releases/1.0.1/. 2012 October 5.

10.

Beale

, Heard

. The openEHR archetype model. The template object model (TOM) March 13, 2007. www.openehr.org/releases/1.0.1/architecture/am/tom.pdf. 2011 March 2.

11.

Beale

, Heard

. The openEHR archetype model. Archetype definition language. ADL 2. March 3, 2007. www.openehr.org/releases/1.0.2/architecture/am/adl2.pdf. 2011 March 2.

12.

HL7 implementation guide for CDA release 2: NHSN healthcare associated infection (HAI) reports, release 2 (U.S. realm). Draft standard for trial use. February 2009. www.cdc.gov/nhsn/PDFs/CDA/CDAR2L3_IG_HAIRPT_R2_D2_2009FEB.pdf. 2012 October 20.

13.

Beeler

. HL7 reference information model. 2004. www.interopsante.org/offres/file_inline_src/412/412_P_15660_92.pdf. 2012 October 1.

14.

Khan

et al. Achieving interoperability among healthcare standards: Building semantic mappings at models level. Proceedings of the 6th International Conference on Ubiquitous Information Management and Communication, New York: ACM, 2012; 101.

15.

Khan

, Hussain

, Afzal

, Amin

, Lee

. Healthcare standards based sensory data exchange for home healthcare monitoring system. Conf Proc IEEE Eng Med Biol Soc, 2012; 1274–1277.

16.

Freriks

. Semantic interoperability artefact modelling standard: Clinical information models. Electronic Record Services BV. July 29, 2012. www.en13606.org/wiki/images/1/1c/ERS_SIAMS_%28most_recent_version%29.pdf. 2012 November 25.

17.

Bosca

, Maldonado

, Moner

, Robles

. Detailed clinical models to facilitate interstandard interoperability of data types. 23rd International Conference of the European Federation for Medical Informatics, Oslo, Norway. European Federation for Medical Informatics, 2011.

18.

Dogac

et al. Artemis: Deploying semantically enriched Web services in the healthcare domain. Inf Systems, 2006; 31:321–339.

19.

Sahay

et al. A methodological approach for ontologising and aligning health level seven (HL7) applications. Availability, Reliability and Security for Business, Enterprise and Health Information Systems. Berlin: Springer, 2011; 102–117.

20.

Maldonado

et al. LinkEHR-Ed: A multi-reference model archetype editor based on formal semantics. Int J Med Inform, 2009; 78:559–570.

21.

Kilic

, Dogac

. Achieving clinical statement interoperability using R-MIM and archetype-based semantic transformations. IEEE Trans Inf Technol Biomed, 2009; 13:467–477.

22.

Martínez Costa

, Menárguez-Tortosa

, Fernández-Breis

. Clinical data interoperability based on archetype transformation. J Biomed Inform, 2011; 44:869–880.

23.

Poseacle Converter. http://miuras.inf.um.es:9080/PoseacleConverter. 2012 March 2.

24.

Khan

, Hussain

, Latif

, Afzal

, Ahmad

, Lee

. Process interoperability in healthcare systems with dynamic semantic web services. Computing, 2013; 1–26. http://link.springer.com/article/10.1007/s00607-012-0239-3/fulltext.html. 2013 February 25.

25.

Galarraga

, Serrano

, Martinez

, de Toledo

, Reynolds

. Telemonitoring systems interoperability challenge: An updated review of the applicability of ISO/IEEE 11073 standards for interoperability in telemonitoring. Engineering in Medicine and Biology Society, 2007 EMBS 2007. 29th Annual International Conference of the IEEE. Piscataway, NJ: IEEE, 2007; 6161–6165.

26.

Lee

, Gatton

. Wireless health data exchange for home healthcare monitoring systems. Sensors, 2010; 10:3243–3260.

27.

Khattak

, Truc

PTH

, Hung

, Dang

V-H

, Guan

, Pervez

, Han

, Lee

Y-K

. Towards smart homes using low level sensory data. Sensors, 2011; 11:11581–11604.