Elsevier

Knowledge-Based Systems

Volume 26, February 2012, Pages 75-85
Knowledge-Based Systems

Archetype sub-ontology: Improving constraint-based clinical knowledge model in electronic health records

https://doi.org/10.1016/j.knosys.2011.07.004Get rights and content

Abstract

The global effort in the standardization of electronic health records has driven the need for a model to allow medical practitioners to interact with the newly standardized medical information system by focusing on the actual medical concepts/processes rather than the underlying data representations. An archetype has been introduced as a model that represents functional health concepts or processes such as admission record, which enables capturing all information relevant to the processes transparently to the users. However, it is necessary to ensure that the archetypes capture accurately all information relevant to the archetype concepts. Therefore, a semantic backbone is required for each of the archetype.

In this paper, we propose the development of an archetype sub-ontology for each archetype to represent the semantic content of the corresponding archetype. The sub-ontology is semi-automatically extracted from a standard health ontology, in this case SNOMED CT. Two steps performed to build an archetype sub-ontology are the annotation process and the extraction process, in which some rules have to be applied to maintain the validity of sub-ontology. The approach is evaluated by utilizing the archetype sub-ontologies produced in the development of a new archetype to ensure that only relevant archetypes can be linked to the archetype being developed, so that the only relevant data are captured using the particular archetype. It is shown that the method produces better results than the current approach in which an archetype sub-ontology is not used. We conclude that the archetype sub-ontology can represent well the semantic content of archetype.

Highlights

► We present an approach to develop an archetype sub-ontology for an archetype. ► An archetype sub-ontology is extracted from health ontology (SNOMED CT). ► There are two main processes in the approach: annotation and extraction. ► The approach is evaluated by applying it in the archetype slot filling process. ► The archetype sub-ontology can represent well the semantic content of an archetype.

Introduction

An ontology constitutes a formal conceptualization for a given domain of interest. Based on the viewpoint of knowledge representation in information systems, an ontology may consist of varying levels of formalization, differing only in expressivity, to capture the essence of a domain – its conceptual entities and the relationships among them.

Ontologies have been widely applied in many areas within the health sector. Some existing terminological standards include SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms), LOINC (Logical Observation Identifiers Names and Codes) and UMLS (Unified Medical Language System) which contains many biomedical ontologies including SNOMED CT and LOINC. These medical ontologies are mainly used for semantic uniformity and consistency of health terms as well as to enable semantic interoperability between different health institutions. For instance, the works in [1], [2] use SNOMED CT to achieve the interoperability between the HL7 (Health Level 7) based health frameworks and other healthcare entities. Health ontologies are also utilized in the efforts of, among others, improving the search query processing in health domain (e.g. in [3], [4]) and providing tools for assisting health practitioners (e.g. in [5], [6], [7]).

In the more specific field of health, i.e. the clinical field, openEHR Foundation1 has proposed a new clinical model referred to as an archetype. This model is adopted by the CEN TC/2512 in its Health informatics – Electronic Health Record Communication (EN 13606) European Standard. An archetype is a model of specific domain knowledge, in this case, clinical knowledge. Each archetype describes a complete clinical knowledge concept such as ‘diagnosis’ or ‘test result’ [8]. Archetype can be viewed as the knowledge level representation which defines a valid information structure [9]. If we are to differentiate an information structure, which is commonly in the form of a database, with the knowledge which is represented by the ontology, the place of archetype is in between those two. Fig. 1 depicts the comparison between ontology (SNOMED CT), archetype, and database in the representation of the term ‘heart rate’. We can see that an archetype describes information in an operational context, which cannot be captured by an ontology due to its general purpose. For example, an ontology can tell us what ‘heart rate’ is, but it cannot explain the structure to capture the ‘heart rate’ measurement information, e.g. that the rhythm of the heart rate and the position of the person whose heart rate is being measured must also be considered. On the other hand, since a database aims at representing the data in the form of information provided to the end users, the term ‘heart rate’ will be meaningless if it is not connected to the term ’patient’. While a database focuses on the specific heart measurement for a specific patient, archetype talks about the way the heart rate of a patient is measured. Furthermore, archetypes are authored by clinicians who do not necessarily have knowledge on databases or ontology. They are designed for health practitioners who can see/interact with them without bothering about the technical structure of data storage or the semantic guidelines of ontology. An example of an archetype user interface is depicted in Fig. 1 on the right side of the archetype column. It is a dummy user interface for the heart_rate archetype presented in the Archetype Editor tool [10].

Since there are different health information framework standards, such as openEHR and CEN/TC 251, which have different archetype specifications, it is important to do semantic binding between archetypes and health ontologies to achieve semantic interoperability of electronic health records (EHR) between health institutions using different health information standards. Moreover, health knowledge tends to change from time to time, which is shown by the existence of two different releases of SNOMED CT each year, each of which contains more than 50,000 changes on average. The changes may affect the archetypes with regard to the terms used in the archetypes. The inspection on which archetypes are affected by the changes need to be conducted. However, manual examination to all archetypes is not practical as the number of archetypes and the number of terms on each archetype grows bigger. The binding between archetypes and health ontologies can facilitate the checking process of the archetypes currency. Therefore, in this paper, we are proposing a binding mechanism by developing a sub-ontology behind each archetype, which is referred to as an archetype sub-ontology. To evaluate how well the archetype sub-ontologies represent the semantic content of archetypes, we utilize them in the enforcement of the archetype slot filling constraint proposed in [11].

The rest of this paper is organized as follows. Section 2 discusses related work and contributions. In Section 3, archetype constraints and a motivating example on the importance of the archetype sub-ontology are presented. The development of archetype sub-ontology, which includes the annotation process and the extraction process, is addressed in Section 4. Section 5 shows the utilization of the archetype sub-ontology in the archetype slot filling constraint. It is followed by the presentation of evaluation in Section 6. Finally, Section 7 concludes our work.

Section snippets

Related work and contributions

The specific part of an ontology that is required by a specific application is often referred to as a sub-ontology or an ontology view. A sub-ontology of a base ontology is a certain sub-set of that base ontology that is a valid ontology in its own right [12]. A sub-ontology is obtained through a systematic extraction process from the base ontology. Some frameworks to extract ontology have been proposed in [13], [14], [15], [16], [17], as well as in our initial work in [18]. A comprehensive

Archetype constraints and a motivating example

Since archetypes control data quality through their rules [27], their usage enables information and assistance systems to validate data at the time of data entry. This can, in turn, be used as a basis of alerting the user to the error(s), and/or prescribing corrective measures. For this purpose, archetype is expressed using constraints [9] which can be used to validate the captured data. One of the built-in constraints is the containment of an archetype inside another archetype, which is called

Development of the archetype sub-ontology

In our initial work, MOVE [18] is proposed as a framework for sub-ontology extraction. However, since MOVE is a generic approach for the extraction and it does not consider the specific characteristics of SNOMED CT nor does it capture the notion of archetypes, we cannot reuse the framework as it is. Rather, we use it as the basic structure in this work. For the development of archetype sub-ontology, we use a modified framework called Archetype-MOVE.

Fig. 3 describes how Archetype-MOVE works.

Archetype slot filling constraint enforcement utilizing the archetype sub-ontologies

The archetype sub-ontology is utilized in the application of the archetype slot filling constraint. The constraint is to enforce the semantic relevance between the slot and the filler archetype as well as to avoid semantic irrelevance between them. By applying the constraint, the list of relevant archetypes is presented, from which the archetype author can choose to fill in the slot.

Fig. 6 shows the utilization of archetype sub-ontologies in producing the list of relevant archetypes to a

Evaluation

We have applied the approach to slot filling processes of openEHR archetypes. At this stage, we only choose slots requiring the archetypes of the Evaluation class. This choice was merely based on the convenient number of archetypes in this class, since the method itself can be applied to all classes of archetypes. For the application of the approach, we took the archetypes bundled along with version 1.0.1248 of the Archetype Editor installer file.

Conclusion

In this paper, we have presented an approach to develop an archetype sub-ontology, which is extracted from SNOMED CT ontology, for a specific archetype. It represents the semantic content of the archetype. There are two main processes in the development of archetype sub-ontologies: the annotation process and the extraction process. In the annotation process, one or more SNOMED CT concepts are selected to annotate an archetype term. These concepts are used as the input of the extraction process

Acknowledgment

This work is partially supported by the Ministry of National Education of the Republic of Indonesia through the scholarship granted to the first author. Mehul Bhatt acknowledges the funding and support by the Alexandar von Humboldt Foundation (Germany) and the Germany Research Foundation (DFG). We also would like to express our gratitude to any anonymous reviewers of our manuscript for their valuable suggestions to improve this paper.

References (28)

  • Archetype editor. <http://www.wiki.oceaninformatics.com/confluence/display/TTL/Archetype+Editor> accessed...
  • A.K. Sari et al.

    Utilization of ontology in health for archetypes constraint enforcement

  • C. Wouters, A formalization and application of ontology extraction, Ph.D. Thesis,...
  • B.J. Peterson, W.A. Andersen, J. Engel, Knowledge bus: Generating application-focused databases from large ontologies,...
  • Cited by (16)

    • Max-margin weight learning for medical knowledge network

      2018, Computer Methods and Programs in Biomedicine
      Citation Excerpt :

      An electronic medical record (EMR) [27] refers to the systematized collection of patient health information in digital format, including free-form text, symbols, charts, and data. As crucial carriers of recorded medical activity, EMRs contain significant medical knowledge [28–30]. Therefore, we employ EMRs as the knowledge foundation and information source of an intelligent medical diagnosis system.

    • Learning and inference in knowledge-based probabilistic model for medical diagnosis

      2017, Knowledge-Based Systems
      Citation Excerpt :

      Electronic medical records (EMRs) [27] are a systematized collection of patient health information in a digital format. As the crucial carrier of recorded medical activity, EMRs contain significant medical knowledge [28,29]. Therefore, for this study, we adopted Chinese Electronic Medical Records (CEMRs) in free-form text as the primary source of medical knowledge.

    • A distributed clinical decision support system architecture

      2014, Journal of King Saud University - Computer and Information Sciences
      Citation Excerpt :

      Constructing KBs of the CDSS is a crucial task that determines the success of the CDSS in general (Kim et al., 2008; Koutkias et al., 2012). The goal is to collect the medical knowledge from the relevant sources (domain experts, EHR databases, and clinical practice guidelines), systematize it and represent it in a formal human-understandable and a computer-interpretable manner (Sari et al., 2012). In this framework, to populate the standard XML KBs, we use three services, which are KEM, DME and PEM.

    • An approach for sub-ontology evolution in a distributed health care enterprise

      2013, Information Systems
      Citation Excerpt :

      This can be achieved by limiting the successor concept level of and the non-IS-A relationship level connected to the selected concepts. These rules have also been established in [6]. The rules are classified based on the different groups of the semantic change operations discussed in Section 5.2.

    • SNOMED CT module-driven clinical archetype management

      2013, Journal of Biomedical Informatics
      Citation Excerpt :

      A rebuilding process is applied to guarantee that the minimal segment is a valid ontology in its own right. According to [39] we consider that a valid SNOMED CT segment is a not null subset of the SNOMED CT ontology and it does not contain isolated concepts (i.e. concepts that are not related to any other concept). The following two steps are executed for each concept of the segment:

    View all citing articles on Scopus
    View full text