Using Knowledge Graph Structures for Semantic Interoperability in Electronic Health Records Data Exchanges

Abstract

Information sharing across medical institutions is restricted to information exchange between specific partners. The lifelong electronic health records (EHR) structure and content require standardization efforts. The existing standards such as openEHR, HL7, and CEN TC251 EN 13606 (Technical committee on Health Informatics of the European Committee for Standardization) aim to achieve data independence along with semantic interoperability. This study aims to discover knowledge representation to achieve semantic health data exchange. OpenEHR and CEN TC251 EN 13606 use archetype-based technology for semantic interoperability. The HL7 Clinical Document Architecture is on its way to adopting this through HL7 templates. Archetypes are the basis for knowledge-based systems as these are means to define clinical knowledge. The paper examines a set of formalisms for the suitability of describing, representing, and reasoning about archetypes. Each of the information exchange technologies such as XML, Web Ontology Language, Object Constraint Language, and Knowledge Interchange Format is evaluated as a part of the knowledge representation experiment. These examine the representation of Archetypes as described by Archetype Definition Language. The evaluation maintains a clear focus on the syntactic and semantic transformations among different EHR standards.

1. Introduction

Health care is a continuously evolving domain. New findings of diseases and clinical treatments are continuously being made. It has raised the need for increased information exchange among various medical institutions. Electronic Health Records (EHRs) contain the medical history and treatments of the patients. In the classical approach, the information and knowledge are stored together. Storage of each clinical concept in a single relation led to a huge data model that was difficult to manage and expensive to maintain. Among the existing interoperability approaches for the EHRs, the dual-model approach [1] seems to be most promising. It consists of an information layer and a knowledge layer. The key feature of this approach is the segregation of knowledge (represented as Archetypes [2]). A conceptual idea is virtually transferred through the medium of an intermediate structure of a knowledge graph. This study analyzes its components.

Knowledge graphs are used to capture knowledge in application situations that need large-scale integration, management, and extraction of value from a variety of data sources. Recent studies examine all currently available knowledge graphs (KGs), including their characteristics, approaches, applications, issues, and challenges [3,4].

This paper focuses on using knowledge representation and information interchange technologies for archetype representation.

1.1. Overview Electronic Health Records

The EHRs domain is very complex. It consists of different types of data (textual to multimedia) with new data requirements emerging over time. For example, there are about 300,000 terms at present (defined in SNOMED-CT), including medical tests and procedures created and modified constantly. EHRs have a complex structure based on archetypes. These may include data from about 100–200 parameters, such as temperature, blood pressure, and body mass index. Each of the individual parameters has its specific contents. Each of the individual parameters (concepts) is represented as archetypes. For example, an archetype contains an item, such as ‘data’ (e.g., captured for a heart rate observation). It offers complete knowledge about a clinical context (i.e., attributes of data), ‘state’ (context for interpretation of data), and ‘protocol’ (information regarding the gathering of data), as shown in Appendix A. Various standard organizations are working for interoperable semantic EHRs. For example, Health Level 7 (HL7), European Committee of standardization Technical committee 251, International standard organization (ISO), and openEHR.

It is desirable to have EHR systems that are functionally interoperable systems and semantically interoperable systems. Interoperability can be defined as an ability to communicate data such that the data are sufficient to perform the tasks at the receiving system, the data items associated have the same meaning for the creator of the sending party and the users of the receiving party, also the task performed must be to the satisfaction of the receiving party. To tackle the EHR interoperability problem, many authorized organizations have defined several standards, such as the Health Level 7 (HL7) Clinical Document Architecture (CDA), Continuity of Care Record (CCR), CEN EN 13606 EHRcom, and openEHR. The main objective of all these EHR standards is to structure the data and markup the content of the medical information to be exchanged.

The three levels of interoperability namely: syntactic (data) interoperability, structural interoperability/semantic interpretability, and semantic interoperability are explained in detail [5]. The main mechanisms for interoperability are reference model, archetypes, and domain knowledge governance.

1.2. Archetypes and Semantic Interoperability

The standards for semantic interoperability (such as HL-7 CDA, openEHR, CEN ISO 13606) endorse the two-level modeling approach for storing EHRs [6]. It consists of two layers that propose to segregate information modeling from content (knowledge) modeling. The reference (information) model layer represents the generic structures of components of the healthcare data. The content model on the other hand is used to represent more domain-specific data, which in general have instability due to variability and high rate of change in the usage (e.g., formal description of physical examination or prescription).

In openEHR and CEN13606, the first level is known as the reference model and the second level consists of archetypes. The reference model (RM) defines the basic fundamental structure and represents the generic structures of components of the healthcare data at the storage level (information modeling). At the second layer, the archetype model (AM) constraints the generic structure to encompass logical semantics and thus, provide a standard definition that aids in semantic interoperability. AM provides deliverables in the form of archetypes and templates. An archetype provides the meta-description of structured clinical records as a computable formalism. In HL7, the two levels are Reference Information Model (RIM) and the HL7 templates. The HL7 Clinical Document Architecture templates are the same as the archetype concept.

These standards support compatibility among each other. In the openEHR/ CEN 13606 the only means of achieving interoperability with a generic information model is the archetypes. In fact, ADL archetypes can be defined against any Unified Modeling Language (UML) model, and it is also possible to write the archetypes against the HL7 version 3 Reference Information Model and also the HL7 Clinical Document Architecture. Ref. [7] describes how the clinical statements of two different EHR standards derived from the same RIM can be mapped to each other by using archetypes, Refined Message Information Model derivations, and semantic tools.

An archetype is an agreed formal and interoperable specification of a re-usable clinical data set that underpins an EHR. It captures the maximum possible information about a particular and discrete clinical concept [2]. A conceptual definition of data as archetypes can be developed in terms of constraints on structure, types, values, and behaviors of reference model classes based on the dual-model approach. It consists of the knowledge layer as archetypes and a reference model. An example of a simple archetype is WEIGHT, which can be used in multiple places, wherever is required within an EHR. Semantics in archetypes have dual nature. It consists of structural and terminological components:

1.

The structure of archetype provides support for semantics.

2.

EHR component links form a set of interrelated conceptual, clinical entities. Each entity has a set of terminological bindings associated (specified by links to terms of specific medical terminologies).

If data elements are created and modified using archetypes, the archetypes constrain the configuration of data instances to be valid according to the archetype. These are a paradigm for building semantically enabled software systems, providing data validation, clinical modeling (by domain experts), a basis for querying, and form design. An archetype might define or constrain relationships between data values within a data structure. These are expressed as algorithms, formulae, or rules. Its metadata defines its core concept, purpose, use, evidence, authorship, and versioning. An archetype ensures a maximal dataset. It contains all the relevant information regarding a clinical concept. Once the format of an archetype is agreed upon and published, it is held in a ‘library’ and made available for use in any part of a given application by multiple vendor systems, multiple institutions, and multiple geographical regions. Each group or entity using the same archetype will understand and compute data captured by the same archetype in another clinical environment. Thus, an archetype serves the following key purposes:

1.

It allows domain experts (clinicians) to capture data for their information systems;

2.

It provides runtime validation of data input, thus improving data entry quality; and

3.

It provides a basis for intelligent querying of data [8,9]

1.3. Representing Internal Data in Archetypes

Matching clinical data to codes in controlled terminologies is the first step towards achieving data standardization for safe and accurate data interoperability. Archetypes have the feature to separate the internal model data from formal terminologies. Existing terminologies, taxonomies, and ontologies have been written in many languages. For example, MeSH (Medical Subject Heading) [10] and NCI (National Cancer Institute) [11] have their own proprietary formalisms (now commonly expressed also in XML). The ’term binding’ section of the archetype is used to describe the equivalences between archetype local terms and terms found in external terminologies, such as SNOMED-CT (Systematized Nomenclature of Medicine-Clinical Terms) or Unified Medical Language System (UMLS). The internal data are assigned local names, later bound or mapped to external terminology codes. This feature eliminates the need to make changes to the model whenever the terminology changes. For formal description, the Archetype Definition Language (ADL) uses three other syntaxes, cADL (constraint form of ADL), dADL (data definition form of ADL), and a version of first-order predicate logic (FOPL), to describe constraints on data, which are instances of some information model (e.g., expressed in UML) [12]. Thus, ADL can be used to write archetypes for any domain where formal object model(s) exist, which describe data instances.

1.4. EHRs: Data Modeling

The openEHR architecture [1] includes a design principle called ‘Ontological separation’, which regulates the EHR modeling; see Figure 1. The model consists of two main categories entitled ‘ontologies of information and ’ontologies of reality’. The ‘ontologies of information’ contain the information models of the EHR content, whereas the ‘ontologies of reality’ describe real phenomena with descriptions and classifications.

The ‘ontologies of information’ are divided into:

1.

‘Domain content models’ (knowledge models) containing formal definitions of the clinical content. These are developed using archetypes, which are designed such that, these can change when new clinical needs arise.

2.

‘Information representation models’ are implemented in the electronic health care systems software. These are used as a foundation for the domain content models and are designed to be stable regarding model changes. In openEHR, this component is named the reference model (RM).

In simpler terms, if RM is equivalent to the set of letter/digits, then each and every archetype would be a grammar constraining which strings could be expressed for that archetype. Thus, in formal terms,

RM = {Set of classes C1, C2, C3 ...Cn}.

Archetype = {Set of rules for valid combination of classes of RM}.

The ‘ontologies of reality’ contains examples:

1.

Classifications: ICDx(International Classification of Diseases) and ICPC(International Classification for Primary Care).

2.

Process descriptions: Clinical guidelines.

3.

Descriptive terminologies: SNOMED-CT, LONIC.

In Figure 1, the EHR extracts are based on commonly shared archetypes. These are proposed as a means to exchange information between different health care providers [1]. The semantics of the domain content models (e.g., archetypes) are provided by terminology binding. The meaning of nodes in archetypes is given by textual descriptions and references to external terminology systems. These are in the form of term definition and term binding. Representation of archetypes in various possibilities such as XML (Extensive Markup Language), ADL (Archetype Definition Language), and OWL (Web Ontology Language) has been described in the paper. Subsequently, a comparison is drawn amongst these information exchange technologies, and the advantages and disadvantages of each have been analyzed. The main aim of the study is to find the best representation of an archetype. The paper examines a set of formalisms for the suitability of describing, representing, and reasoning about archetypes.

2. Formalisms in Transformation of Archetypes among Different Standards: Background

The prevalent standards such as HL7 Clinical Document Architecture (CDA), openEHR, and CEN TC251 EN 13606 use archetype-based technology for semantically interoperable exchange. ADL archetypes can be written against any UML model, and it would be possible to write archetypes directly against the HL7v3 RIM (Reference Information Model) [13], and also the CDA specification [14] (using a UML expression derived from its XML schema). These standards define the structure and the markup of the clinical content to make EHR exchange interoperable. They all rely on dual-model technology for semantic interoperability. They have different classes in the reference model having abstract semantics. Although the names of the classes are not shared between these standards, their semantics are similar. The RM for all the standards is stable. If alignments are performed between archetypes of different standards, aligning algorithms based on similarity measures will fail, as class names (of RM) are disparate. Dictionary-based approaches will not be of much help, as all names are quite abstract [15]. The various ongoing exchange efforts based on archetypes use different formalisms to represent archetypes. The mapping among different standards makes use of model management and uses OWL transformations and XML representation of archetypes.

For interoperability among EHR standards based on ontologies, the possible approaches are (i) by building common ontology and (ii) by reusing existing ontologies and combining them.

The first approach requires the transformation of ADL archetypes into OWL [16,17]. The ontological information and archetype models have been compared to find similarities and differences among the CEN and openEHR representations. The software tool available based on this approach is Poseacle convertor [18]. This approach involves the use of XML and OWL representations. The latter is obtained by reusing existing ontologies and combining them through ontology mapping. The ARTEMIS [19] project was implemented based on this. The various formalisms such as XML, ADL, and OWL have been used [19].

It has been found that archetypes must be agreed upon before communication. However, it does not seem feasible to expect all professionals of various disciplines to agree on exactly all details of the archetypes associated with the data they would like to exchange. If this approach becomes widely accepted, it is certain that the number of available archetypes will become very large. Although archetypes are annotated with terms from standardized ontologies (terminologies, taxonomies, etc.), there will still be differences at the archetype level and at the terminology level. Due to competing standards, local variations at the archetype level will stem from the specialization of archetypes for specific purposes and research projects. Further, several widely used terminologies could be used to annotate archetypes (e.g., SNOMED-CT, MeSH, NCI). Local ontologies are also used to annotate archetypes; therefore, a sound and general process for matching archetypes are essential. A unified framework based on a fuzzy ontology was proposed to show how to exploit semantic web technologies to support EHR semantic interoperability [20]. Costa et al. introduced ontologies and rules as a means of establishing interoperability amongst heterogeneous health systems (openEHR and HL7) [21]. OmniPHR interoperable model is proposed for assessing the structure of semantic interoperability and database integration from various health standards [22]. OmniPHR uses artificial intelligence, Natural Language Processing, and a standard ontology to achieve interoperability. Knowledge graphs are represented using a variety of methodologies, but machine learning methods are frequently employed to create a low-dimensional representation that can support a wide range of applications [23].

Thus, there is a requirement to identify the role of the suitability of various formalisms for achieving full semantic interoperability through archetypes, which has been addressed in the current research.

3. Knowledge Representation

Ontologies (31 percent), semantic web-related formalisms (26 percent), decision tables and rules (19 percent), logic (14 percent), and probabilistic models (10 percent) are the most general knowledge representation approaches. Knowledge is primarily represented in medical informatics through computer interpretable clinical recommendations (43%), medical domain ontologies (26%), and electronic health care records (22%) [24]. Embedding codes can convey the meaning of the concepts that are represented by an archetype from a commonly recognized terminology at appropriate points in the archetype. Archetypes are the unit of communication between interoperating applications, as they define the minimum context that must be considered for safe communication [15]. Expressivity is a key parameter in choosing or creating a knowledge representation. It is easier and more compact to express a fact or element of knowledge within the semantics and grammar of a more expressive knowledge representation. However, more expressive languages will likely require more complex logic and algorithms to construct equivalent inferences. A highly expressive knowledge representation is also less likely to be complete and consistent. Less expressive KRs may be both complete and consistent [25]. This section describes the knowledge technologies for the representation of archetypes.

3.1. ADL and XML

The ADL approach uses existing UML semantics and existing terminologies and adds convenient syntax for expressing the required constraints. Expressing the semantics of archetypes using XML-based exchange formats leads to the conflation of abstract and concrete representational semantics [12]. ADL syntax is straightforward and powerful. It has allowed mappings to other formalisms to be more correctly defined and understood. Previously, archetypes have been expressed as XML instance documents conforming to W3C XML schemas [26], for example, in the Good Electronic Health Record (GEHR) [27] and openEHR projects. Subsequently, expressing archetype constraints using numerous schema languages for XML (such as XML schema, RELAX NG, and Schematron) has been examined. Because of the issues reported, these languages were abandoned for archetype validation [28,29]. For example, in XML schema, classes in RM were mapped to complex types, and archetypes were mapped to class restrictions. The strict rules (unique particle attribution, complex enumerations, placing regular expression constraint) in using the restriction feature in XML schema did not permit the implementation of archetype constraints.

With ADL parsing tools, it is possible to convert ADL to any number of forms, including various XML formats. XML instances can be generated from the object form of an archetype in memory. XML archetypes are equivalent to serialized instances of the parse tree, i.e., particular ADL archetypes serialized from objects into XML instances. Archetypes connect information structures to formal terminologies. They are path-addressable similar to XML data, using path expressions directly convertible to Xpath expressions. An XML schema corresponding to the ADL object model has been published at openEHR.org [30]. The XML schema corresponding to RM is published at [21].

The XML has a role in the exchange requirement. The EHR_Extract, used for exchange, is expressed using XML [1]. A recent study examines whether W3C XML schema provides a practicable solution for the semantic validation of standard-based EHR documents [28]. The EHR_Extract needs to be validated against the RM and the associated archetypes.

Example of XML/ADL use in openEHR: To accept a report from pathology laboratory for inclusion in the EHR repository of a patient (in the ADL form), an XML form is generated using the archetype. This form is shared with the laboratory for on-site validation of data input. Thus, XML is used as an input and transport medium.

The comparison between ADL and XML is shown below and Appendix B.

1.

Both are machine processable.

2.

ADL is human readable, whereas XML is sometimes unreadable (e.g., XML schema instance, OWL-RDF ontologies).

3.

ADL adheres to object-oriented semantics, particularly for container types, whereas XML schema languages do not follow object-oriented semantics.

4.

For ontological reference, ADL has domain entities/archetypes, and XML has global terms/concepts.

5.

ADL uses attributes, and XML uses attributes and sub-elements to represent object properties.

6.

ADL uses nearly half of space (storage) for tags, XML may have data redundancy in contents.

7.

In terms of efficiency, ADL is a domain-specific language (sufficiently rich to capture and model medical domain) in comparison to XML, which is good for web document modeling with limited ability to represent database contents.

3.2. ADL and OWL

Web Ontology Language (OWL) [31] is a language for the semantic web, which allows:

1.

Offering expressiveness and the possibility of reasoning over the information it describes.

2.

Allows making annotations on classes or properties, and semantic similarity functions are available.

3.

OWL is related to terminologies. For example, SNOMED-CT is currently in the process of adapting its representation to semantic web environments [32]. Having a representation of both the clinical and terminological information in the same formalism would facilitate better clinical knowledge management and would enrich archetypes by adding more information to them.

4.

OWL modeling brings all information concerning a particular term together (e.g., code, definition, bindings, and translations).

5.

There exists several tools to process it.

OWL has an abstract syntax, an extension of XML-based syntax known as the resource description framework (RDF). OWL is general-purpose description logic (DL) and is primarily used to describe “classes” of things in such a way as to support subsumptive inferencing within the ontology, and by extension, on data that are instances of ontology classes. The OWL includes intersection, union, complement of existential quantification, universal quantification, min cardinality, max cardinality, equivalence, and specialization. Thus, it has a decidability and computability nature, offering expressiveness and the possibility of reasoning over the information it describes. OWL version 2 has a property of qualified cardinality restrictions (which makes it possible to capture the occurrences restrictions from ADL), property chain inclusions, and OWL/XML syntax.

ADL provides a rich set of constraints on primitive types, including dates and times; however, ADL has significant drawbacks for achieving the goal of semantic interoperability, such as its syntactic orientation. Consequently, the formalization of the exchange and transformation processes is more than using semantic-oriented models such as ontological ones. In addition to this, syntactic approaches also make important archetype-related tasks, such as comparing and classifying archetypes, difficult. Archetypes in ADL can be represented in OWL. It requires [12]:

1.

Express the relevant reference models in OWL.

2.

Express the relevant terminologies in OWL.

3.

Be able to represent concepts (i.e., constraints) independently of natural language.

4.

Convert the cADL part of an archetype to OWL.

Using OWL-expressed archetypes to validate data (which would require massive amounts of data to be converted to OWL statements) is unlikely to be anywhere near as efficient as doing it with archetypes expressed in ADL or one of its concrete expressions [12]. The UML-like representation is not suitable for performing formal reasoning at the conceptual level; however, OWL offers a great deal of inferencing power of the far wider scope in comparison to specific reasoning.

The object-oriented semantics apply in the UML specification of RM and the corresponding XML schema mapped from it. This needs to be mapped for conversion to OWL. Practically, this is possible, as illustrated in a recent study [16]. The XML-schema class is mapped to OWL class with the same name. The restricted data type definitions in XML schema are mapped to OWL data type. The attributes in XML-schema mapped to OWL property. The instances/objects in XML are equivalent to individuals in OWL.

Reference [33] provides mapping archetypes to OWL. For automatically transforming archetype definitions from ADL to OWL, the archetype ontologies use the ehr2ont framework [34]. The LinkEHR [35] is also a recent project for obtaining the OWL representation of archetypes.

3.3. ADL and Other Formalisms

A comparative analysis of ADL with other formalisms such as the Object Constraint Language (OCL) and Knowledge Interchange Format (KIF) is shown in Section 4.3. The OCL allows constraining all class instances to conform to the specific configuration of instances. In contrast, ADL provides the ability to create numerous archetypes, each describing in detail a concrete configuration of instances of a class. ADL archetypes include invariants (which are expressed in a syntax similar to OCL).

The Resource Description Framework (RDF) is a data model for objects (“resources”) and relations between them provide a simple semantics for this data model [36]. OWL takes the essential fact-stating ability of RDF and the class- and property-structuring capabilities of RDF schema and extends them in essential ways. OWL classes can be specified as logical combinations (intersections, unions, or complements) of other classes, or as enumerations of specified objects, going beyond the capabilities of the RDF schema. OWL can declare classes and organize these classes in a subsumption (“subclass”) hierarchy, as an RDF schema. The significant extension over RDF schema is the ability in OWL to provide restrictions on how properties behave (that are local to a class). A recent study concentrates on the semantic interoperability of diverse EHRs and their standards, proposing the transformation of heterogeneous EHR datasets into XML syntactic models and their translation into a common ontological representation for semantic knowledge acquisition [37].

4. Evaluation in Practice

We ran into many problems concerning alternative representations of the archetype and the inability to express some of the constraints in different knowledge representation languages. We detail these problems as a cautionary tale to others planning to use pre-existing archetypes for semantic interoperability, as a list of issues to consider when describing concepts formally in any language, and as a collection of criteria for evaluating alternative representations.

The three best-suited knowledge formalisms ADL, XML, and OWL for archetype representation have been evaluated for the features mentioned in the paper through the experimental setup KnowledgeRep. The ADL formalism has been compared with XML and OWL to find the suitable role of these formalisms in a working semantic interoperable system.

4.1. KnowledgeRep: Simulation

Various knowledge formalisms used in different EHR standards for obtaining semantic interoperability have been examined in current research with the OpenEHR standard. The underlying Java Reference Implementation [19] of OpenEHR has been used. It has been named as KnowledgeRep. It is an evaluation setup for examining various archetype representations for EHR concepts. Figure 2, shows an application GUI (graphical user interface), the knowledge representations, and the communication classes. The application GUI represents various system interactions between the users and the EHR system. It is responsible for multiple calls to the utility and server-side classes to perform the formatting and transformations of the data and extract relevant data. It comprises the following modules: the form presented to the user, the template mechanism required to create the template corresponding to the EHR system, the data binding module, and the result viewer, which represents the report desired by the user. GWT facilitates all these modules. It introduces the necessary flexibility into the model-driven approach of standard-based EHR system development.

The knowledge representation (archetypes) in ADL, XML, and OWL formalisms and the communication classes are shown in the second part of the diagram. It contains components that are responsible for communication. It also contains logic that connects the GUI with the underlying java reference implementation of OpenEHR. The entire set of knowledge is parsed from ADL/XML/OWL files using the classes of RM and mapped to the GUI (form). The knowledge representation and communication part of the setup comprises the ArchetypeWrapper and DatabaseWrapper classes, which act as the communication nodes. The ArchetypeDAO maps the database and the basic RM data types. The clinical software database is shown (the details are beyond the scope of current research).

4.2. Methodology

Here we describe the analysis procedure applied for each formalism, ADL, XML, and OWL. The archetypes used for the analysis have been downloaded from CKM [38], Appendix C. Each knowledge representation has been analyzed from the perspective of how strong it is to support the client side and the server side of the EHR system. In other words, we have tried to explore knowledge representation from a user’s perspective and the machine’s perspective.

4.2.1. Representation in ADL

The analysis of the ADL was performed as given. A user selects a form to make a data entry, the corresponding .adl file is picked up from the archetype repository, parsed to extract all the node paths of the mandatory fields, and then a form is generated. When the user enters the value of any of the fields in the archetype, they are bonded with the exact path in the .adl file. We see that the ADL formalism is a powerful knowledge representation that can act as a GUI generator. At the same time, when the data are to be persisted, a user inputs to the corresponding archetype are mapped to the RM data types by intermediate classes and stored in the database. Along with the data type and the data value, the path of the node in the adl file and the name of the adl file are also persisted—this aids in the retrieval of the data from the database. Whenever the data are to be represented as a report, the data value is picked, mapped to the node whose path corresponds to it in the database, and then represented in the form corresponding to the archetype. Thus, ADL formalism plays a major role in data persistence in this case. From the above analysis, we can conclude that ADL, on the one hand, provides the object-oriented semantics and, on the other hand, is machine processable; thus, it plays a significant role in both the client side and backend of an EHR system; therefore, it is a powerful knowledge formalism.

However, the parsing of the ADL archetype returns objects according to the archetype object model. The archetype object model (AOM) is the definitive formal representation of archetype semantics. It is independent of syntax. The primary goal of the AOM specification is to tell developers how to build archetype tools and EHR components that utilize archetypes. It can be used to generate the output side of parsers that process archetypes in a linguistic format, such as the openEHR Archetype Definition Language (ADL). The semantics defined in the AOM is used to express the object structures of archetypes. These objects are equivalent to a syntax tree. The archetype object model can be thought of as a model of an in-memory archetype or template, or as a standard syntax tree for any serialized format—not only ADL. An archetype’s canonical abstract syntactic form is ADL, although it may also be parsed from and serialized to XML, JSON, or any other format. Calls to an appropriate AOM construction API from an archetype or template editing tool can also produce the in-memory archetype representation. This model is common to all dual-model-based standards; it will have no information about the particular reference model for which the archetype was built. Thus, the obtained objects cannot be used to perform any semantic activity such as comparison, selection, or classification.

4.2.2. Representation in XML

For experimental analysis, an XML representation is automatically generated by the archetype editor is being used. This XML format conforms to the archetype constraint classes defined in the OpenEHR RM, can be directly imported into the OpenEHR RM to initialize the relevant archetypes. Thus, the XML format is again generated via the archetype editor from a corresponding ADL counterpart. Each piece of data can subsequently be referenced using its XML path. For example, the patient’s first name (Paul) could be referenced as “/record/name/firstname”. The drawback of this formalism can be tracked in its inefficiency to represent the archetype constraints completely. It is a suitable formalism for transforming and exchanging data from one form to another.

4.2.3. Representation in OWL

The semantic web enables greater access not only to content but also to services on the Web [39]. Users and software agents should discover, invoke, compose, and monitor Web resources offering particular services and having specific properties. They should be able to do so with a high degree of automation if desired. Powerful tools should be enabled by service descriptions across the Web service lifecycle. OWL-S (formerly DAML-S) [39] is an ontology of services that makes these functionalities possible.

Since the experiment used the OpenEHR Java Reference Implementation of RM, it has been found that in order to use OWL formalism, the RM (i.e., information model) should be transformed into OWL statements (OWL is found to be at a more abstract level as compared to ADL, XML, and XML schema). It has been analyzed that there exists a method for binding terminology to the EHR system with OWL as a bridging technology, given that the terminology is expressible in OWL.

Recent research [40] describes the ADL-to-OWL translation approach, describes the techniques to map archetypes to formal ontologies and demonstrates how rules can be applied to the resulting representation. It translates definitions expressed in the openEHR ADL to a formal representation expressed using the OWL. The formal representations are then integrated with rules expressed with the Semantic Web Rule Language (SWRL) [41] expressions, providing an approach to apply the SWRL rules to concrete instances of clinical data. Sharing the knowledge expressed in rules is consistent with the philosophy of open sharing, encouraged by archetypes. The approach also allows the reuse of formal knowledge, expressed through ontologies, and extends reuse to propositions of declarative knowledge, such as those encoded in clinical guidelines.

4.3. Findings

To the best of the author’s knowledge, KnowledgeRep has investigated the suitability of various formalisms in the context of archetypes, using the specific semantics of their underlying reference models and hierarchical structure (tree) of archetype definitions. It examines whether currently available archetype languages provide direct support for mapping to formal ontologies and then exploiting reasoning on clinical knowledge, which are critical ingredients of full semantic interoperability.

Through KnowledgeRep, various comparisons presented in

Table 1. Comparative analysis of various knowledge representations (in context to archetype).

Features	ADL	XML	OWL	OCL	KIF
Domain Modeling	Archetype Description Language(ADL).	Web document model.	Web-enabled ontologies for building the Semantic Web.	Constraints on object models (not on data) can describe archetypes.	Formal semantics (sharable among software entities).
Reference Model (RM) with object-oriented semantics	ADL syntax adheres to object-oriented reference models (expressed in UML for constraints).	XML and XML schema languages do not follow object-oriented semantics.	Requires explicit expression of a reference model in OWL to represent archetype constraints.	All statements are FOPL statements. It is impossible to express an archetype in a structural way.	Existing information model and terminologies have to be converted to KIF statements to describe archetypes.
Constraint Representation	ADL enables constraints to be expressed in a structural and nested way for archetypes.	Strict rules in XML schema cannot express archetype constraints.	Inconvenient in OWL.	OCL constraint types include function pre- and post-conditions, and class variants.
Path Traceability	ADL has a path syntax based on XPath (open EHR path) to deal with heavily nested structures.	Inbuilt Xpath mechanism.	No inbuilt path mechanism.	The OCL syntax for paths (that traverse associations) is similar to XPath.	No inbuilt path mechanism.
Inbuilt Ontology Section	ADL provides independence from natural language and terminology issues by having a separate ontology per archetype. It contains ’bindings’ and language-specific translations.	No built in syntax.	No built in syntax. It requires the semantics to be represented from first principles.	No built in syntax.	No built in syntax.

have been obtained. The conclusions of various results are also shown in

Table 2. Suitability of ADL, XML, and OWL.

Various Formalisms	Suitability
ADL	Representation of archetypes
XML	Information interchange
OWL	Semantic activities and transformation among archetypes

and

Table 3. Summary of transformation of ADL with other formalisms.

	XML	OCL	OWL	KIF
Trans-	Yes	No	Yes	Yes
formation of ADL archetypes	(GEHR Project) [27]		(Poseacle convertor, ARTEMIS project, Archetype Ontologiser, LinkEHR project) [50]	[51]

.

From Table 1 we infer that ADL best represents archetypes definitions. The XML schema languages were not able to specify the archetype constraints; therefore, the XML-encoded EHR data and archetype definitions will be read into the EHR system, which will validate the EHR data against the archetype constraints programmatically. XML has a role in the exchange requirement over the web. OWL would not be a suitable representation for storing the EHR data itself. It is designed on a mathematical base specifically for reasoning. Thus, it is suitable for semantic activities such as classification, comparing, reasoning, and transformation.

Table 3 presents a consolidated view of the possibility of transformation of ADL archetypes. Thus, the XML archetypes are serialized instances of the parse tree obtained from ADL parser. Expressing archetypes using OWL/KIF requires the existing information model and relevant terminologies to be converted to OWL/KIF statements. Valuing data using OWL expressed archetypes requires massive amounts of data to be converted to OWL statements; however, OWL plays a significant role in ontology mapping, which permits the exchange of information among health care information systems conforming to different standards. The transformation to OCL is impossible, but the ADL syntax includes assertion language based on OCL.

Although, OWL is not suitable for representing conditional expressions used in representing constraints and rules. Some researchers have proposed ways to represent such richer expressions, e.g., by adopting rule languages (e.g., RuleML) into RDF and OWL representations [39]. RuleML is a family of languages whose modular system of XML schemas permits high-precision Web rule interchange [42]. Recent work [40,43] makes a case for the potential of combining the translated OpenEHR Archetype Definitions with a rule-based approach using Semantic Web Rule Language (SWRL) [41] rules. Hajjamy et al. developed a semi-automatic integration approach for integrating data from traditional information systems to a better ontologies-based system. Different data sources via UML, RDB, and XML are converted into local ontologies (OWL2) in the mentioned approach. Based on semantic, structural, and syntactic similarity measurement, all the local ontologies output then merge into a global ontology [44].

5. Discussions

The ADL has various advantages and a few disadvantages compared to the other languages, as shown in Table 1. A recent study [16] states that difference between OpenEHR RM/ADL and XML/XML schema as:

1.

The OpenEHR RM has a “domain bias” and is, therefore, more extensive and expressive than XML, a minimal generic model to describe hierarchical textual structures. This means that more has to be expressed in an XML schema in order to obtain a document class that is semantically equivalent to an archetype.

2.

The OpenEHR RM and archetype object models are modeled in UML. There is a direct correspondence between an ADL instance and the archetype object model (AOM). These models have an object-oriented bias, which is beneficial when seen as representations for software systems. They may be further equipped with logical artifacts, such as pre-and post-conditions, loop, and class invariants, and finally, operational implementation artifacts.

Therefore, the XML/XML schema models can be considered more abstract than the OpenEHR RM/AOM/ADL models, in the sense that the latter is more “implementation-oriented”.

To standardize the knowledge representation in the clinical domain, a significant contribution comes from languages such as the Resource Description Framework schema or OWL [45]. OWL is even more abstract (omitting as much as possible about internal structures and reducing the description to a set of statements about what is true in the description). This minimalism enables formal reasoner engines to operate on the models, assisting us in discovering irregularities and inconsistencies [16].

To publish pre-existing ontologies (e.g., Unified Medical Language System (UMLS)) on the Semantic Web, there exist several problems concerning alternative interpretations of the semantic network (SN) notation and the inability to express some of the interpretations in OWL. In the study [46], the authors run into several difficulties in this undertaking. Some obstacles were due to ambiguities in the SN notation’s semantics or the notation’s under-specification (e.g., what can be inferred from the absence of edges?). Other problems were the inability to express the SN as OWL axioms that would provide the desired inferences, and the difficulty of making choices between multiple possible representations. The authors encountered obstacles representing the semantics of “links” in the SN, especially in the context of requirements such as $\delta$/$\rho$ inheritance, inheritance blocking, and polymorphism. Thus, OWL language cannot be used to represent some notions in UMLS. $\delta$/$\rho$ inheritance is domain and range inheritance. The “is-a” link in SN gives rise to inheritance. Whenever there is a conflict between the placement of types in the SN and the links to be inherited, the SN provides a mechanism to explicitly “block” inheritance. The relationships whose arguments, i.e., domain and range values can be instances of multiple classes are called polymorphic relationships. These requirements led the authors of [46] to investigate the possible interpretations and encodings of a “link” in the SN.

Codes representing the meanings of nodes and constraints on text or terms, bindings to terminologies such as SNOMED or LOINC, are stated in the ontology section of an archetype. The report [15] describes a novel approach to address semantic interoperability in the healthcare domain, taking into account ontology mapping. Archetypes are used to scope the context of the matching process that will allow two independent healthcare providers to interoperate. It structures the matching algorithms at two different levels, terminology and archetype, leveraging the most mature research on ontology matching. The approach identifies relationships between ontological terms that have been embedded in pairs of archetypes as a means of matching these terms. The matched terms can then, in turn, be used to identify similarities between archetypes. The context of the archetype will limit the matching space to allow for more accurate mapping results and, due to the nature of archetypes, ultimately to a very high level of automation. The Simple Knowledge Organization System (SKOS) [47] is a standard data model for sharing and linking knowledge organization systems via the Semantic Web. The possibility of exploring SKOS shortly to bridge the gaps among records that have been created by different representation languages or represented on different semantics of terms may be done. Costa et al. introduced a method of achieving interoperability heterogeneous health systems through ontologies and rules. That approach used OWL features to map out the balance between openEHR records mixed with HL7 [48]. Recent research proposes a semantic ontological framework that might unify several EHR data formats. It takes different data formats as input (ADL, SQL, XML, CDA-HL7) and converts them into an OWL ontology [49].

6. Conclusions

Semantic interoperability is essential to facilitate the computerized support for alerts, workflow management, and evidence-based healthcare across heterogeneous EHR systems. The archetypes have been presented as a key to knowledge representation and information exchange; however, currently available archetype languages do not provide direct support for mapping to formal ontologies and then exploiting reasoning on clinical knowledge, which are critical ingredients of full semantic interoperability. The study presented various technologies for representing archetypes from XML to ADL to OWL through the simulation named as KnowledgeRep. The comparative analysis among the formalisms such as OWL, OCL, and KIF are presented (Table 1).

The semantic interoperable exchange among different standards requires these formalisms as is illustrated by recent research projects (Table 3) in the study.

The KnowledgeRep study has explored the following objectives:

1.

Given an EHR system expressed in OWL (${\mathrm{ES}}_{\mathrm{OWL}}$) and a terminology system expressed in OWL (${\mathrm{TS}}_{\mathrm{OWL}}$), there exists a method for binding terminology to EHR expressed in OWL (${{T}}_{\mathrm{OWL}}$). The EHR system here includes the RM and archetype. This enables both the RM and archetypes to be expressed in OWL representation. That is,

∃ ${{T}}_{\mathrm{OWL}}$ (${\mathrm{ES}}_{\mathrm{OWL}}$, ${\mathrm{TS}}_{\mathrm{OWL}})$.

2.

It has been found that given an EHR system expressed in UML+ADL (${\mathrm{ES}}_{\mathrm{UML}+\mathrm{ADL}}$) and a terminology system (${\mathrm{TS}}_{\mathrm{F}}$) expressed in formalism F, there exists a method for binding terminology to EHR through the ‘term binding’ (TB) section of archetype (${{T}}_{\mathrm{TB}}$). The EHR system here includes the RM (expressed in UML) and archetypes (expressed in ADL representation). The archetypes contain a ‘term binding’ section (Section 1.3). That is,

∃ ${{T}}_{\mathrm{TB}}$ (${\mathrm{ES}}_{\mathrm{UML}+\mathrm{ADL}}$, ${\mathrm{TS}}_{\mathrm{F}})$.

3.

It has also been found that given an EHR system expressed in XML (${\mathrm{ES}}_{\mathrm{XML}}$) and a terminology system expressed in XML (${\mathrm{TS}}_{\mathrm{XML}}$), there exists a method for binding terminology to EHR. The EHR system here includes the RM (expressed in XML schema) and Archetypes (represented in XML). That is,

∃ ${{T}}_{\mathrm{XML}}$(${\mathrm{ES}}_{\mathrm{XML}}$, ${\mathrm{TS}}_{\mathrm{XML}})$.

For coping with the semantics, two things are required.

1.

Establishment of the terminology binding (achieved through archetypes).

2.

Establishment of the mapping between different standardized EHR systems, i.e., data elements of one EHR system transformed to the data elements of another EHR system and vice versa (through various knowledge formalisms, see Table 1).

Thus, the paper concludes that ADL is suitable for domain modeling and constraint representation. XML schema do not provide the support for defining archetypes constraints [29]; however, XML is the global standard for exchange requirements and is also used for bringing the data from a non-archetype-based EHR system into an archetype-based EHR repository (through XSLT transformations). The OWL representation is the best fit for semantic activities, without which the semantic exchange among the three prevalent standards is impossible. The structural components of a knowledge graph have been considered for forming virtual intermediate support for the information exchanges. The current research can contribute to helping the EHR system vendors and developers to choose the appropriate technology for the required purpose, keeping in mind the semantic interoperability.

The study is limited to establishing a comparison between distinct approaches (XML, OWL, OCL, and KIF) to interoperate within the domain-specific application such as healthcare; however, it does not discuss intelligent, semi auto-constructed knowledge graph framework in the e-health context—a subject that can be further explored. Moreover, the research may be extended for various knowledge graph problems [3] such as data insufficiency, explainability, incomplete and incorrect knowledge, inconsistencies, and integration of knowledge.