Journal:Using knowledge graph structures for semantic interoperability in electronic health records data exchanges

From LIMSWiki
Jump to navigationJump to search
Full article title Using knowledge graph structures for semantic interoperability in electronic health records data exchanges
Journal Information
Author(s) Sachdeva, Shelly; Bhalla, Subhash
Author affiliation(s) National Institute of Technology Delhi, University of Aizu
Primary contact Email: shellysachdeva at nitdelhi dot ac dot in
Year published 2022
Volume and issue 13(2)
Article # 52
DOI 10.3390/info13020052
ISSN 2078-2489
Distribution license Creative Commons Attribution 4.0 International
Download (PDF)


Information sharing across medical institutions is restricted to information exchange between specific partners. The lifelong electronic health record (EHR) structure and content require standardization efforts. Existing standards such as openEHR, Health Level 7 (HL7), and ISO/EN 13606 aim to achieve data independence along with semantic interoperability. This study aims to discover knowledge representation to achieve semantic health data exchange. openEHR and ISO/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 (OWL), Object Constraint Language (OCL), and Knowledge Interchange Format (KIF)—is evaluated as a part of the knowledge representation experiment. These examine the representation of archetypes as described by Archetype Definition Language (ADL). The evaluation maintains a clear focus on the syntactic and semantic transformations among different EHR standards.

Keywords: archetypes, electronic health records, dual-model approach, knowledge representation, EHR, XML, ADL, OWL, KIF


Healthcare 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 at those medical institutions. In the classical approach, information and knowledge are stored together. However, 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 EHRs, the dual-model approach[1] seems to be most promising. It consists of an information layer and a knowledge layer. The key benefit 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 that knowledge graph's components.

Knowledge graphs are used to capture knowledge in application-based situations that require 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.

Overview of EHRs

The domain of the modern EHR is complex. It consists of different types of data (from textual to multimedia), with new data requirements emerging over time. For example, there are about 300,000 medical terms at present (as defined by SNOMED CT), and medical tests and procedures are constantly created and modified. EHRs have a complex structure based on archetypes. These may include data based on hundreds of parameters, such as temperature, blood pressure, and body mass index (BMI). Each of the individual parameters (or concepts) has its own specific content and is represented as an archetype. For example, one archetype could contain an item such as "data," which can, for example, be represented as a documented heart rate observation. This archetype ideally offers complete knowledge about a clinical context (i.e., attributes of data), the data's "state" (i.e., context for interpretation of data), and its "protocol" (i.e., information regarding the gathering of data) (see Appendix A). Various standards development organizations are working to improve the interoperability of semantic EHRs through these archetypes and more.

It is desirable to have EHR systems that are functionally 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 associated data items have the same meaning for the creator of the sending party and the users of the receiving party, and the tasks performed using the data must be to the satisfaction of the receiving party. To tackle the EHR interoperability problem, many authorized organizations have defined several standards. Examples include Health Level 7 (HL7) and its Clinical Document Architecture (CDA), ASTM International's Continuity of Care Record (CCR), European Committee for Standardization (CEN) Technical Committee 251 and International Organization for Standardization (ISO)'s ISO/EN 13606, and the openEHR Foundation's openEHR. The main objective of all these EHR standards is to structure the data and mark up the content of the medical information to be more readily exchanged.

For this work, three levels of interoperability stand out, namely syntactic (data) interoperability, structural interoperability/semantic interpretability, and semantic interoperability.[5] The main mechanisms for interoperability are reference models, archetypes, and domain knowledge governance.

Archetypes and semantic interoperability

The standards for semantic interoperability (such as CDA, openEHR, and ISO/EN 13606) endorse the two-level modeling approach for storing EHR content.[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 their usage (e.g., a formal description of a physical examination or prescription).

In openEHR and ISO/EN 13606, the first level is known as the reference model (RM) and the second level consists of archetypes. The RM defines the basic fundamental structure and represents the generic structures of components of the healthcare data at the storage level (i.e., information modeling). At the second layer, the archetype model (AM) constrains 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's CDA, the two levels are the Reference Information Model (RIM) and the HL7 templates, which function essentially the same as the archetype concept.

These standards support compatibility among each other. In the case of openEHR and ISO/EN 13606, the only means of achieving interoperability with a generic information model is through their 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 RIM and the CDA in general. Kilic and Dogac[7] note this in their work, describing 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.

As mentioned prior, an archetype is an agreed upon 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 RM classes based on the dual-model approach. It consists of the knowledge layer as archetypes and an RM. An example of a simple archetype is "Weight," which can be used in multiple places as required within an EHR.

Semantics in archetypes have a dual nature. They consist of both structural and terminological components. The structure of an archetype provides support for semantics, while EHR component links form a set of interrelated conceptual, clinical entities. Each entity has a set of terminological bindings associated with it (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, formula, or rules. An archetype's metadata defines its core concept, purpose, use, evidence, authorship, and versioning. An archetype also 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[8][9]:

  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.
  3. It provides a basis for intelligent querying of data.

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 advantage of being able to separate the internal model data from formal terminologies. Existing terminologies, taxonomies, and ontologies have been written in many languages. For example, Medical Subject Headings (MESH)[10] and the National Cancer Institute (NCI)[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 or Unified Medical Language System (UMLS). The internal data are assigned local names and 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 descriptions, 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.

EHRs and data modeling

The openEHR architecture[1] includes a design principle called "ontological separation," which regulates the EHR modeling (Figure 1). The model consists of two main categories: "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.

Fig1 Sachdeva Information22 13-2.png

Fig. 1 Illustration of openEHR’s ontological structure

The ontologies of information are divided into several models:

  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 healthcare system's 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 the RM.

In simpler terms, if RM is equivalent to the set of letters/digits, then each and every archetype would be a set of grammar constraining which strings could be expressed for that archetype. 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 can be broken down as:

  1. Classifications: ICDx (International Classification of Diseases) and ICPC (International Classification of Primary Care)
  2. Process descriptions: Clinical guidelines
  3. Descriptive terminologies: SNOMED CT or LOINC

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 ADL, XML (Extensible Markup 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 this 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.

Formalisms in transformation of archetypes among different standards: Background

Prevalent standards such as CDA, openEHR, and ISO/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 RIM[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 RM, 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) building common ontology and (ii) reusing existing ontologies and combining them. The first approach requires the transformation of ADL archetypes into OWL.[16][17] The ontological information and AMs 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, with the latter being obtained by reusing existing ontologies and combining them through ontology mapping. The ARTEMIS project was implemented based on this, using the various formalisms such as XML, ADL, and OWL.[19]

Broadly speaking, 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.

In 2019, Adel et al.[20] proposed a unified framework based on a fuzzy ontology to show how to exploit semantic web technologies to support EHR semantic interoperability. Prior to that, Martinez-Costa et al.[21] introduced ontologies and rules as a means of establishing interoperability amongst heterogeneous health systems (openEHR and HL7). Recently, Roehrs et al.[22] proposed an application model called OmniPHR, a model for assessing the structure of semantic interoperability and database integration from various health standards. 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]

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

Knowledge representation

In a 2019 review of more than 100 papers on knowledge representation in health care, Riaño et al.[24] found that ontologies (31%), semantic web-related formalisms (26%), decision tables and rules (19%), logic (14%), and probabilistic models (10%) represented the most common knowledge representation approaches. They also found that medical informatics knowledge was primarily represented as computer interpretable clinical recommendations (43%), medical domain ontologies (26%), and EHRs (22%).[24] In most of these cases, 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.


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. Similar to XML data, they are path-addressable using path expressions directly convertible to Xpath expressions. An XML schema corresponding to the ADL object model has been published at[30] The XML schema corresponding to RM is published in the work of Martinez-Costa et al.[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 the 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.

An example of XML/ADL use can be found in openEHR. To accept a report from the 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.

A comparison between ADL and XML is stated below, and in Appendix B:

  1. Both are machine processable.
  2. ADL is human readable, whereas XML is sometimes unreadable (e.g., XML schema instances, 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 its required space (storage) for tags, and XML may have data redundancy in contents.
  7. In terms of efficiency, ADL is a domain-specific language (sufficiently rich to capture and model the medical domain) in comparison to XML, which is good for web document modeling, though with limited ability to represent database contents.


OWL[31] is a language for the semantic web, which:

  • offers expressiveness and the possibility of reasoning over the information it describes;
  • allows making annotations on classes or properties and makes semantic similarity functions available;
  • is related to terminologies (e.g., SNOMED CT is currently in the process of adapting its representation to semantic web environments[32], recognizing that 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);
  • brings all information concerning a particular term together through modeling (e.g., code, definition, bindings, and translations); and
  • is supported by several tools which can 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. OWL includes intersection, union, complement of existential quantification, universal quantification, min cardinality, max cardinality, equivalence, and specialization. Thus, it demonstrates decidability and computability, 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. However, it requires[12]:

  • the expression of the relevant RMs in OWL;
  • the expression of the relevant terminologies in OWL;
  • the representation of concepts (i.e., constraints) independently of natural language; and
  • the conversion of 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 an OWL class with the same name. The restricted data type definitions in XML schema are mapped to an OWL data type. The attributes in XML-schema are mapped to an OWL property. The instances/objects in XML are equivalent to individuals in OWL.

Kilic et al.[33] provide mapping archetypes to OWL. For automatically transforming archetype definitions from ADL to OWL, the archetype ontologies use the ehr2ont framework.[34] LinkEHR[35] is a more recent project for obtaining the OWL representation of archetypes.

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 later in the next section. 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).

RDF is a data model for objects (“resources”), and relations between them provide 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]

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.

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, referred to 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 (Google Web Toolkit) facilitates all these modules. It introduces the necessary flexibility into the model-driven approach of standard-based EHR system development.

Fig2 Sachdeva Information22 13-2.png

Fig. 2 KnowledgeRep: Evaluation setup for various archetype representations for EHR concepts

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. ArchetypeDAO maps the database and the basic RM data types. The clinical software database is shown (the details are beyond the scope of the current research).


Here we describe the analysis procedure applied for each formalism, ADL, XML, and OWL. The archetypes used for the analysis have been downloaded from Clinical Knowledge Manager (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.

Representation in ADL

The analysis of 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, it is 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, making it a powerful knowledge formalism.

However, parsing of the ADL archetype returns objects according to the archetype object model (AOM). 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 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 AOM 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 RM for which the archetype was built. Thus, the obtained objects cannot be used to perform any semantic activity such as comparison, selection, or classification.

Representation in XML

For experimental analysis, an XML representation automatically generated by the archetype editor is being used. This XML format conforms to the archetype constraint classes defined in the openEHR RM, and it can be directly imported into the oenEHR 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, however, a suitable formalism for transforming and exchanging data from one form to another.

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). As such, 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 OWL. The formal representations are then integrated with rules expressed with 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.


To the best of the authors' knowledge, KnowledgeRep has investigated the suitability of various formalisms in the context of archetypes, using the specific semantics of their underlying RMs 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, have been obtained. The conclusions of various results are also shown in Table 2 and Table 3.

Table 1. Comparative analysis of various knowledge representations (in context to archetype)
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 RMs (expressed in UML for constraints) XML and XML schema languages do not follow object-oriented semantics Requires explicit expression of an RM 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 (openEHR 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, containing "bindings" and language-specific translations No built-in syntax No built-in syntax and requires the semantics to be represented from first principles No built-in syntax No built-in syntax
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
Table 3. Summary of transformation of ADL with other formalisms
Transformation of ADL archetypes Yes (GEHR Project)[27] No Yes (Poseacle Convertor, ARTEMIS project, Archetype Ontologiser, LinkEHR project)[35] Yes [42]

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 healthcare information systems conforming to different standards. The transformation to OCL is impossible, but the ADL syntax includes assertion language based on OCL.

However, OWL is not suitable for representing conditional expressions used in representing constraints and rules. Some researchers have proposed ways to represent such richer expressions, for example, 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.[43] Recent work[40][44] makes a case for the potential of combining the translated openEHR Archetype Definitions with a rule-based approach using SWRL[41] rules. El Hajjamy et al.[45] 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.[45]


ADL has various advantages and a few disadvantages compared to the other languages, as shown in Table 1. A recent study[16] states the 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 AOMs are modeled in UML. There is a direct correspondence between an ADL instance and the 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.

As such, 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 knowledge representation in the clinical domain, a significant contribution comes from languages such as the RDF schema or OWL.[46] 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., UMLS) on the semantic web, there exist several problems concerning alternative interpretations of the semantic network notation and the inability to express some of the interpretations in OWL. Kashyap and Bordiga[47] 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 among multiple possible representations. The authors encountered obstacles representing the semantics of “links” in the SN, especially in the context of requirements such as δ/ρ inheritance, inheritance blocking, and polymorphism. Thus, OWL language cannot be used to represent some notions in UMLS. δ/ρ 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 Kashyap and Bordiga[47] 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)[48] 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. da Costa et al.[49] 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. Recent research proposes a semantic ontological framework that might unify several EHR data formats. It takes different data formats as input (ADL, SQL, XML, and CDA) and converts them into an OWL ontology.[49]


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. This study presented various technologies for representing archetypes such as XML, ADL, and OWL through the simulation tool KnowledgeRep. The comparative analysis among formalisms such as OWL, OCL, and KIF were 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 (ESOWL) and a terminology system expressed in OWL (TSOWL), there exists a method for binding terminology to EHR expressed in OWL (TOWL). The EHR system here includes the RM and archetype. This enables both the RM and archetypes to be expressed in OWL representation. That is, ∃ TOWL (ESOWL, TSOWL).
2. It has been found that given an EHR system expressed in UML+ADL (ESUML+ADL) and a terminology system (TSF) expressed in formalism F, there exists a method for binding terminology to EHR through the "term binding" (TB) section of archetype (TTB). The EHR system here includes the RM (expressed in UML) and archetypes (expressed in ADL representation). The archetypes contain a "term binding" section. That is, ∃ TTB (ESUML+ADL, TSF).
3. It has also been found that given an EHR system expressed in XML (ESXML) and a terminology system expressed in XML (TSXML), 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, ∃ TXML (ESXML, TSXML).

However, for coping with the semantics, two things are required. First, terminology binding must established through archetypes. Second, mappings between different standardized EHR systems must be established. In other words, data elements of one EHR system need to be 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). 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. Current research can contribute to helping EHR system vendors and developers to choose the appropriate technology for the required purpose, keeping in mind semantic interoperability.

Note that this study is limited to establishing a comparison between distinct approaches (XML, OWL, OCL, and KIF) to interoperate within domain-specific applications such as healthcare. Tt does not discuss intelligent, semi-auto-constructed knowledge graph framework in the e-health context, a subject requiring further examination. Moreover, the research shows potential for being extended for various knowledge graph problems[3] such as data insufficiency, explainability, incomplete and incorrect knowledge, inconsistencies, and integration of knowledge.

Abbreviations, acronyms, and initialisms

ADL: Archetype Definition Language

AM: archetype model

AOM: archetype object model

CCR: Continuity of Care Record

CDA: Clinical Document Architecture

CEN: European Committee for Standardization

CKM: Clinical Knowledge Manager

DL: description logic

EHR: electronic health record

GEHR: Good Electronic Health Record

GWT: Google Web Toolkit

HL7: Health Level 7

ISO: International Organization for Standardization

KG: knowledge graph

KIF: Knowledge Interchange Format

MeSH: Medical Subject Heading

NCI: National Cancer Institute

OCL: Object Constraint Language

OWL: Web Ontology Language

RDF: Resource Description Framework

RIM: Reference Information Model

RM: reference model

SKOS: Simple Knowledge Organization System

SWRL: Semantic Web Rule Language

UML: Unified Modeling Language

UMLS: Unified Medical Language System

XML: Extensible Markup Language


Appendix A. Parameter Heart_rate as an archetype

The structure of an archetype is given in Figure A1.

FigA1 Sachdeva Information22 13-2.png

Fig. A1 Parameter Heart_rate as an archetype.

Appendix B. Comparison of ADL and XML

The comparison of ADL and XML is given in Table A1.

Table A1. Comparison of ADL and XML
Properties ADL XML
Machine-processable Yes Yes
Human-readable Yes Sometimes unreadable (e.g., XML schema instance, OWL-RDF ontologies)
Leaf data types More comprehensive set, including interval of numerics and date/time types String data; with XML String data; schema option- more comprehensive set
Structure Universal schema for temporal database (EHRs) (history database) Semi-structured data (rooted acyclic graph with unique path from root to leaf)
Adhering to object-oriented semantics Yes, particularly for container types XML schema languages do not follow object-oriented semantics
Ontological reference Domain entities/archetypes Global terms/concepts
Representation of object properties Uses attributes Uses attributes and sub-elements
Space (for storage) Uses nearly half of space for tags May have data redundancy in contents
Efficiency Is a domain specific language (sufficiently rich to capture and model medical domain) Good for web document modeling with limited ability to represent database contents
Example (Archetype) ADL representation of Heart_rate (Appendix D) XML representation of Heart_rate (Appendix D)

Appendix C. List of archetypes

  1. openEHR-EHR-ITEM_TREE.medication.v1
  2. openEHR-EHR-OBSERVATION.heart_rate.v1
  3. openEHR-EHR-OBSERVATION.blood_pressure.v1
  5. openEHR-EHR-OBSERVATION.body_weight.v1

Appendix D. XML and ADL representation of Heart_rate

The XML and ADL representation of the Heart_rate archetype is given in Table A2.

Table A2. XML and ADL representation of Heart_rate
XML representation ADL representation
<?xml version="1.0" encoding="UTF-8"?>

<archetype xmlns="" xmlns:xsi="" xmlns:xsd=""> .
<term_definitions language="ar-sy">
<items code="at0000">

<items id="text">*Pulse/Heart beat(en)</items>
<items id="description">*The rate and associated attributes for a pulse or heart beat. (en)</items>

<items code="at1037">

<items id="text">*Body site(en)</items>
<items id="description">*Body site where the pulse or heart beat were observed.(en)</items>

<items code="at1005">

<items id="text">*Presence(en)</items>
<items id="description">*Presence of a pulse or heart beat.(en)</items>
<items id="comment">*It can be implied that the pulse or heart beat is present if Rate >0 /min. (en)</items>

<items code="at1013">

<items id="text">*Device(en)</items>
<items id="description">*Details about the device used to measure the pulse rate or heart rate.(en)</items>

<items code="at0013">

<items id="text">*Position(en)</items>
<items id="description">*The body position of the subject during the observation.(en)</items>


archetype (adl_version=1.4; uid=566c355d-9e8f-473d-a80d-90fcd8d61414)


term_definitions = <
["ar-sy"] = <
items = <["at0000"] = <
text = <"*Pulse/Heart beat(en)">
description = <"*The rate and associated attributes for a pulse or heart beat. (en)">
["at1037"] = <
text = <"*Body site(en)">
description = <"*Body site where the pulse or heart beat were observed.(en)">
["at1005"] = <
text = <"*Presence(en)">
description = <"*Presence of a pulse or heart beat.(en)">
comment = <"*It can be implied that the pulse or heart beat is present if Rate >0 /min. (en)">
["at1013"] = <
text = <"*Device(en)">
description = <"*Details about the device used to measure the pulse rate or heart rate.(en)">
["at0013"] = <
text = <"*Position(en)">
description = <"*The body position of the subject during the observation.(en)">

>      >




Author contributions

S.S. and S.B. conceived, formulated, and verified the formalisms for archetypes. S.S. and S.B. analyzed the results, proofread the manuscript, and corrected the manuscript. All authors have read and agreed to the published version of the manuscript.


This research received no external funding.

Conflict of interest

The authors declare no conflict of interest.


  1. 1.0 1.1 1.2 1.3 openEHR Foundation (15 December 2015). "openEHR Architecture Overview". BASE Release-1.0.3. openEHR Foundation. Retrieved 19 January 2022. 
  2. 2.0 2.1 Beale, T. (2002). "Archetypes: Constraint-based Domain Models for Future-proof Information Systems". OOPSLA 2002: Eleventh OOPSLA Workshop on Behavioral Semantics: 16–32. 
  3. 3.0 3.1 Tiwari, Sanju; Al-Aswadi, Fatima N.; Gaurav, Devottam (1 July 2021). "Recent trends in knowledge graphs: theory and practice" (in en). Soft Computing 25 (13): 8337–8355. doi:10.1007/s00500-021-05756-8. ISSN 1432-7643. 
  4. Hogan, Aidan; Blomqvist, Eva; Cochez, Michael; D’amato, Claudia; Melo, Gerard De; Gutierrez, Claudio; Kirrane, Sabrina; Gayo, José Emilio Labra et al. (31 May 2022). "Knowledge Graphs" (in en). ACM Computing Surveys 54 (4): 1–37. doi:10.1145/3447772. ISSN 0360-0300. 
  5. Sachdeva, Shelly; Bhalla, Subhash (2010), Kikuchi, Shinji; Sachdeva, Shelly; Bhalla, Subhash, eds., "Semantic Interoperability in Healthcare Information for EHR Databases", Databases in Networked Information Systems (Berlin, Heidelberg: Springer Berlin Heidelberg) 5999: 157–173, doi:10.1007/978-3-642-12038-1_11, ISBN 978-3-642-12037-4, 
  6. Bird, L.; Goodchild, A.; Tun, Z. (2003). "Experiences with a two-level modelling approach to electronic health records" (PDF). Journal of Research and Practice in Information Technology 35 (2): 121–38. 
  7. Kilic, O.; Dogac, A. (1 July 2009). "Achieving Clinical Statement Interoperability Using R-MIM and Archetype-Based Semantic Transformations". IEEE Transactions on Information Technology in Biomedicine 13 (4): 467–477. doi:10.1109/TITB.2008.904647. ISSN 1089-7771. 
  8. Frankel, H.; Beale, T. (10 March 2012). "Ocean Informatics EHR Service Interface". openEHR Wiki. openEHR Foundation. Retrieved 09 January 2022. 
  9. Sachdeva, S.; Bhalla, S. (2009). "Tutorial: Implementing High-Level Query Language Interfaces for Archetype-Based Electronic Health Records Database". Proceedings of the 15th International Conference on Management of Data. 
  10. National Library of Medicine. "MeSH". National Institutes of Health. Retrieved 05 November 2021. 
  11. National Cancer Institute (20 September 2021). "Metadata Services for Cancer Data". National Institutes of Health. Retrieved 09 November 2021. 
  12. 12.0 12.1 12.2 12.3 Beale, T.; Heard, S. (12 December 2008). "openEHR Release 1.0.2: The openEHR Archetype Model - Achetype Definition Language ADL 1.4" (PDF). openEHR Foundation. Retrieved 09 January 2022. 
  13. Beeler, G.; Duteau, J.-H.; Grieve, G. et al. (September 2014). "HL7 Reference Information Model". Health Level 7. Retrieved 06 September 2021. 
  14. Dolin, R.H.; Alschuler, L.; Boyer, S. et al. (2 April 2018). "Clinical Document Architecture, Release 2". Health Level 7. Retrieved 06 September 2021. 
  15. 15.0 15.1 15.2 Bisbal, J.; Berry, D. (2009). "Archetype Alignment - A Two-level Driven Semantic Matching Approach to Interoperability in the Clinical Domain". Proceedings of the Second International Conference on Health Informatics, HEALTHINF 2009: 216–21. doi:10.5220/0001541502160221. 
  16. 16.0 16.1 16.2 16.3 Hedayat, R. (2010). "Semantic Web Technologies in the Quest for Compatible Distributed Health Records". Uppsala Universitet. 
  17. Maldonado, José Alberto; Costa, Catalina Martínez; Moner, David; Menárguez-Tortosa, Marcos; Boscá, Diego; Miñarro Giménez, José Antonio; Fernández-Breis, Jesualdo Tomás; Robles, Montserrat (1 August 2012). "Using the ResearchEHR platform to facilitate the practical application of the EHR standards" (in en). Journal of Biomedical Informatics 45 (4): 746–762. doi:10.1016/j.jbi.2011.11.004. 
  18. Breis, J.T.F.; Tortosa, M.M.; Martinez-Costa, C.. "POSEACLE Converter". Universidad de Murcia. Archived from the original on 26 June 2012. 
  19. 19.0 19.1 Chen, Rong; Klein, Gunnar (2007). "The openEHR Java reference implementation project". Studies in Health Technology and Informatics 129 (Pt 1): 58–62. ISSN 0926-9630. PMID 17911678. 
  20. Adel, Ebtsam; El-sappagh, Shaker; Elmogy, Mohammed; Barakat, Sherif; Kwak, Kyung-Sup (2019). "A Fuzzy Ontological Infrastructure for Semantic Interoperability in Distributed Electronic Health Record" (in en). Intelligent Automation and Soft Computing: –1–-1. doi:10.31209/2019.100000151. ISSN 1079-8587. 
  21. 21.0 21.1 Martinez-Costa, Catalina; Menarguez-Tortosa, Marcos; Alberto, Jose; Tomas, Jesualdo (1 January 2010), Wu, Gang, ed., "Semantic Web Technologies for Managing EHR-related Clinical Knowledge" (in en), Semantic Web (InTech), doi:10.5772/7298, ISBN 978-953-7619-54-1, Retrieved 2022-06-12 
  22. Roehrs, Alex; da Costa, Cristiano Andre; da Rosa Righi, Rodrigo; Rigo, Sandro Jose; Wichman, Matheus Henrique (1 March 2019). "Toward a Model for Personal Health Record Interoperability". IEEE Journal of Biomedical and Health Informatics 23 (2): 867–873. doi:10.1109/JBHI.2018.2836138. ISSN 2168-2194. 
  23. Nicholson, David N.; Greene, Casey S. (2020). "Constructing knowledge graphs and their biomedical applications" (in en). Computational and Structural Biotechnology Journal 18: 1414–1428. doi:10.1016/j.csbj.2020.05.017. PMC PMC7327409. PMID 32637040. 
  24. 24.0 24.1 Riaño, David; Peleg, Mor; ten Teije, Annette (1 September 2019). "Ten years of knowledge representation for health care (2009–2018): Topics, trends, and challenges" (in en). Artificial Intelligence in Medicine 100: 101713. doi:10.1016/j.artmed.2019.101713. 
  25. Blobel, Bernd (2013). "Knowledge representation and management enabling intelligent interoperability - principles and standards". Studies in Health Technology and Informatics 186: 3–21. ISSN 0926-9630. PMID 23542959. 
  26. Ocean Informatics (15 February 2006). "openEHR XML-schemas - Release 1.0.2". openEHR Foundation. Retrieved 08 December 2021. 
  27. 27.0 27.1 St. Bartholomew's Hospital Medical College (23 June 1994). "The Good European Health Record". CORDIS. European Commission. Retrieved 09 January 2022. 
  28. 28.0 28.1 Rinner, C.; Janzek-Hawlat, S.; Sibinovic, S.; Duftschmid, G. (2010). "Semantic Validation of Standard-based Electronic Health Record Documents with W3C XML Schema" (in en). Methods of Information in Medicine 49 (03): 271–280. doi:10.3414/ME09-02-0027. ISSN 0026-1270. 
  29. 29.0 29.1 Tun, Z.; Bird, L.J.; Goodchild, A. (2002). "Validating Electronic Health Records Using Archetypes and XML" (PDF). 
  30. "openEHR". openEHR Foundation. Retrieved 15 November 2021. 
  31. McGuinness, D.L.; van Harmelen, F. (10 February 2004). "OWL Web Ontology Language Overview". W3C. Retrieved 09 January 2022. 
  32. Sundvall, Erik; Qamar, Rahil; Nyström, Mikael; Forss, Mattias; Petersson, Håkan; Karlsson, Daniel; Åhlfeldt, Hans; Rector, Alan (1 October 2008). "Integration of tools for binding archetypes to SNOMED CT" (in en). BMC Medical Informatics and Decision Making 8 (S1): S7. doi:10.1186/1472-6947-8-S1-S7. ISSN 1472-6947. PMC PMC2582794. PMID 19007444. 
  33. Kilic, O.; Bicer, Veli; Dogac, A. (June 2005). "Mapping Archetypes to OWL" (PDF). Software Research and Development Center. Retrieved 10 November 2021. 
  34. devinci84 (6 August 2008). "ehr2ont -". Google Code. Retrieved 10 November 2021. 
  35. 35.0 35.1 "LinkEHR Interoperability Platform". VeraTech for Health. 2019. Retrieved 10 November 2021. 
  36. Vatant, B. (15 March 2014). "RDF". W3C. Retrieved 09 January 2022. 
  37. Kiourtis, Athanasios; Mavrogiorgou, Argyro; Kyriazis, Dimosthenis (1 October 2017). "Gaining the Semantic Knowledge of Healthcare Data through Syntactic Models Transformations". 2017 International Symposium on Computer Science and Intelligent Controls (ISCSIC) (Budapest: IEEE): 102–107. doi:10.1109/ISCSIC.2017.13. ISBN 978-1-5386-2941-3. 
  38. openEHR Foundation. "Clinical Knowledge Manager". openEHR Foundation. Retrieved 09 November 2021. 
  39. 39.0 39.1 39.2 Martin, D.; Burstein, M.; Hobbs, J. et al. (22 November 2004). "OWL-S: Semantic Markup for Web Services". W3C. Retrieved 06 November 2021. 
  40. 40.0 40.1 Lezcano, Leonardo; Sicilia, Miguel-Angel; Rodríguez-Solano, Carlos (1 April 2011). "Integrating reasoning and clinical archetypes using OWL ontologies and SWRL rules" (in en). Journal of Biomedical Informatics 44 (2): 343–353. doi:10.1016/j.jbi.2010.11.005. 
  41. 41.0 41.1 Horrocks, I.; Patel-Schneider, P.F.; Boley, H. et al. (21 May 2004). "SWRL: A Semantic Web Rule Language Combining OWL and RuleML". W3C. Retrieved 06 November 2021. 
  42. Knowledge Systems, AI Laboratory. "Knowledge Interchange Format (KIF)". Stanford University. Retrieved 06 September 2021. 
  43. Boley, Harold; Paschke, Adrian; Shafiq, Omair (2010), Dean, Mike; Hall, John; Rotolo, Antonino et al.., eds., "RuleML 1.0: The Overarching Specification of Web Rules", Semantic Web Rules (Berlin, Heidelberg: Springer Berlin Heidelberg) 6403: 162–178, doi:10.1007/978-3-642-16289-3_15, ISBN 978-3-642-16288-6, Retrieved 2022-06-12 
  44. Lezcano, Leonardo; Sicilia, Miguel-Angel; Serrano-Balazote, Pablo (2008), Lytras, Miltiadis D.; Carroll, John M.; Damiani, Ernesto et al.., eds., "Combining OpenEHR Archetype Definitions with SWRL Rules – A Translation Approach" (in en), Emerging Technologies and Information Systems for the Knowledge Society (Berlin, Heidelberg: Springer Berlin Heidelberg) 5288: 79–87, doi:10.1007/978-3-540-87781-3_9, ISBN 978-3-540-87780-6, Retrieved 2022-06-12 
  45. 45.0 45.1 El Hajjamy, Oussama; Alaoui, Larbi; Bahaj, Mohamed (2018), Tabii, Youness; Lazaar, Mohamed; Al Achhab, Mohammed et al.., eds., "Integration of Heterogeneous Classical Data Sources in an Ontological Database" (in en), Big Data, Cloud and Applications (Cham: Springer International Publishing) 872: 417–432, doi:10.1007/978-3-319-96292-4_33, ISBN 978-3-319-96291-7, Retrieved 2022-06-12 
  46. Gatta, Roberto; Vallati, Mauro; Cappelli, Carlo; De Bari, Berardino; Salvetti, Massimo; Finardi, Silvio; Muiesan, Maria Lorenza; Valentini, Vincenzo et al. (2016). "Bridging the Gap between Knowledge Representation and Electronic Health Records:". Proceedings of the 9th International Joint Conference on Biomedical Engineering Systems and Technologies (Rome, Italy: SCITEPRESS - Science and and Technology Publications): 159–165. doi:10.5220/0005648801590165. ISBN 978-989-758-170-0. 
  47. 47.0 47.1 Kashyap, Vipul; Borgida, Alex (2003), Fensel, Dieter; Sycara, Katia; Mylopoulos, John, eds., "Representing the UMLS® Semantic Network Using OWL", The Semantic Web - ISWC 2003 (Berlin, Heidelberg: Springer Berlin Heidelberg) 2870: 1–16, doi:10.1007/978-3-540-39718-2_1, ISBN 978-3-540-20362-9, 
  48. Miles, A.; Bechhofer, S. (20 August 2008). "SKOS Simple Knowledge Organization System RDF Schema". WC3. Retrieved 06 November 2021. 
  49. 49.0 49.1 da Costa, C.A.; Wichman, M.H.; Righi, R.R. et al. (2019). "Ontology-based Model for Interoperability between openEHR and HL7 Health Applications". In Arabnia, H.R.; Deligiannidis, L.; Tinetti, F.G. et al. (in English). HIMS'19 proceedings of the 2019 International Conference on Health Informatics and Medical Systems. ISBN 978-1-68392-570-5. OCLC 1151199195. 


This presentation is faithful to the original, with only a few minor changes to presentation, grammar, and punctuation. In some cases important information was missing from the references, and that information was added. The original references are in alphabetical order; this version places them in or order of appearance, by design. The original gives the same citation for both 35 and 50; for this version, only one instance is used.