Both information models and ontologies promise advantages in promoting interoperability. Recent research has shown the benefits of rigorous modelling in assuring largescale consistency. In previous work we have demonstrated the feasibility of remodelling the OpenEHR information ontology using realist ontologies, such as IAO. We here present an OWL version of the care-entry model, showing that many terms contained in clinical archetypes refer to reality rather than to information. Even though not covering the domain of the information model (which deals with record structure, data types, etc.) we have shown that the harmonization of the OpenEHR standard with realist ontologies is feasible. While useful to resolve ambiguities contained in archetype metadata definition, the proposed merged ontology also revealed several modelling inconsistencies on published archetypes. We have also demonstrated that ambiguity in relations and ontological commitment can be improved by rigorous ontological definitions.
The lack of interoperability is recognized in medical
informatics communities as one of the main obstacles for the
full use of healthcare information systems. This issue has
led to the creation of standards development organizations
with the purpose to build consensus by proposing
commonly agreed message types, terms and architectural patterns.
Within the realm of standards, models underlying initiatives
like Health Level Seven International (HL7) and Open
Electronic Health Records (OpenEHR) try to ensure
interoperability by defining basic templates to represent information in
health records. Those templates consist of a set of common
information and clinical variables that faithfully represent
health record information. The OpenEHR standard, e.g.,
defines
(1) a generic information model, the reference model with
domain-invariant classes to be instantiated by
(2) specific clinical models, which support semantic
interoperability, which are called archetypes, containing
specific clinical information
Ontologies, based on the study of reality, are an alternative solution to interoperability issues. With communication standards they share the goal of unifying meaning across different communities, maintaining common (machineprocessable) interpretations. The difference is that ontologybased models are based on formal logic and are, to different degrees, influenced by philosophical methodologies.
The practical and pragmatic orientation of the
OpenEHR standard1, which has been described as grounded
in an ontology of healthcare information
In previous work
This paper is structured as follows: in a brief introduction we describe the OpenEHR two-level modelling approach for clinical data representation; we then compare it with the methodology of ontological realism. Finally, we propose an ontological representation of the entry types, and show practical results obtained and discuss findings. 2
Required for the development of any information system, modelling is one of the most important aspects of software engineering. However, despite the number of best practices and research developed to this subject, there is not yet an undisputed best way of representing a domain. In a complex domain such as healthcare, it is not surprising that many approaches have been used throughout the years.
The modelling and ontological foundations of
OpenEHR are a consequence of several previous efforts to
improve the structure and communication capabilities of
Electronic Health Records. Probably due to such origins, an
important principle of the OpenEHR architecture is the
separation between an ontology of reality and an ontology
of information
The ontology of reality represents clinical and (patho-) physiological processes, body parts, chemicals, procedures, etc. As OpenEHR makes no distinction between terminologies, medical classifications and realist ontologies, this category encompasses the International Classifications of Diseases (ICD), Logical Observation Identifiers Names and Codes (LOINC), as well as most parts of SNOMED CT.
The information model is a rather complex and detailed
architecture of a generic EHR. It encompasses both
definition of records and documents (e.g. classes such as Folder,
Composition, Section and Entry), and of the basic functions
of software systems such as Data structure, Data type,
Access, Version, etc.). The care entry model “define the
semantics of all the „hard‟ information in the record”
Following a quite different principle, realist ontologies
are based on the philosophical study of reality. The term
“realism” in Philosophy is widely used and controversial
Our goal in this paper is not to analyse the whole
standard but only the care entry structure, due to its similarity and
overlap with ontologically described entities. For this
purposes, the realist approach brings two main advantages. The
first is the clear separation between information entities and
real entities, which are related by the relation isAbout – e.g.
the drawing of a horse is about a real horse, or a shadow on
a radiological image is about some anatomical structure.
That prevents inadvertent incorrect inferences of common
language statements, such as “patient blood pressure is an
observation, and all observations are created by healthcare
professionals, therefore the patient blood pressure is created
by healthcare professional”. The second advantage concerns
the possibility of re-use of several previously developed
ontologies adopting the principles of the OBO Foundry
To demonstrate the compatibility between the OpenEHR model and clinically oriented realist ontologies, we have created an OpenEHR information ontology according to the OGMS guidelines. To properly place each class, we took into consideration the natural language description and basic rationale used to develop the entry types. In such rationale, the history classes (“observation” and “action”) represent statements about the past events of the individual subject of record. This includes the description of currently observed characteristics, based on the fact that their appearance necessarily precedes the observation. The “evaluation” classes represent current assessment by the attending health professional, including “diagnosis” and “prognosis”, as well as the representation of the imagined future, like “goals” and “scenarios”. “Instructions” represent future events that should take place as prescribed by the health professional.
The proposed merged ontology can be seen in figures 2 and 3. While the rationale is quite different, the IAO proved capable of faithfully representing the meaning of each information type. Observation is a Data item resulting from the medical encounter, being a description of an entity, usually, the patient. By classifying the other classes according to their intended outcome, we merged the Proposal classes under Objective specification and Instruction classes under Plan specification. Finally, Action was represented as a special type of report, since it necessarily describes a process that has the patient as participant.
Fig. 2. The OpenEHR Care Information branch
We analysed the most commonly used example of an
observation archetype, viz. the Blood Pressure Archetype,
due to its stability and simplicity. Some examples are shown
in Table 1. It was modelled as information about blood
pressure, which is understood as the quality of a portion of
blood that exerts pressure toward an artery. For didactical
purposes, the ontological aspects of blood pressure were
simplified
However, several epistemic entities were not
successfully modelled, as they are not properly representable in
realist ontologies. As an example, consider the metadata
“confounding factors”, defined as “Comment on and record
other incidental factors that may be contributing to the blood
pressure measurement. (…), level of anxiety or 'white coat
syndrome'; pain or fever; changes in atmospheric pressure
etc.” Events such as pain and changes in atmospheric
pressure have little or nothing in common that could map them
to one category in an ontology. E.g. a confounding factor
can be a process, a disposition, or a quality. Whether such
“non-ontological” classes – characterized as “defined
classes” by
Finally, some attributes that are specific to medical
practice, such as “Diastolic endpoint”, have unclear
representation in real ontologies. Defined in the Blood Pressure
Archetype as a metadata allowing the user to “record which
Korotkoff sound2 is used for determining diastolic pressure
using auscultative method”, this attribute depends on
training and individual interpretation to be defined, and lack
ontological status
2 Sounds heard during measurement of blood pressure.
Class name openEHR-EHROBSERVATION.blood_pressure.v1 The local measurement of arterial blood pressure which is a surrogate for arterial pressure in the systemic circulation. Most commonly, use of the term 'blood pressure' refers to measurement of brachial artery pressure in the upper arm. is_aboutsome arterial_blood_pressure is_output_of some blood_pressure_measurement_process has_part some blood_pressure_measurement_datum 'physical examination finding' Systolic_blood_pressure_data Represents the Systolic attribute, defined as Peak systemic arterial blood pressure - measured in systolic or contraction phase of the heart cycle. is_output_of some Systolic_blood_pressure_measuring_process blood_pressure_measurement_datum human_position_configuration Represents the Position attribute, defined as The position of the subject at the time of measurement. is_quality_of some human_being configuration (subClass of quality) blood_pressure_measurement_process Represents the actual process of measurement that will result in the blood pressure observation. It is not directly referred in the OpenEHR archetype. Extended and modified from the Vital Sign Ontology. has_participant some (human_being and (has_quality some human_position_configuration) and (has_quality some sleep_status) and (has_role some patient_role) and (has_part some artery_wall)) ‘planned process’
Overall, the ontological interpretation of the blood pressure archetype revealed definitions that could only be understood by a domain specialist. It also made clear that the archetype is information about the patient, the examination procedures, the examination artefacts used in the procedure (real entities) and the health professional‟s interpretation of the process (information entities). As such, it requires additional modelling of reality, e.g. roles and parts, in order to express the real entities represented in the information artefacts. 3.2
We examined the Medication Action Archetype, which
represents one of the most commonly described healthcare
interventions. Its precise reconstruction was not
straightforward, as it included states that contradict the existence of a
process, e.g.Cancelled or Postponed states. In other words, a
cancelled process is not a kind of process, since the process
never actually took place. Therefore, a different treatment is
required, as only plans about medication administration
processes can be cancelled or postponed, not the processes
themselves
Furthermore, because this archetype includes medication-specific information, it is not clear what kind of relation between the action and the medication holds. Since this template has information such as Name of medication as well as Reason for ceasing the medication, an explicit definition of those relations in the archetype is required before further modelling. 3.3
For this analysis, we used two archetypes. The first is a publicly published evaluation archetype, the Clinical Synopsis Archetype. While extremely simple, this class proved conformant to its information status, being defined as “narrative summary or overview about a patient, specifically from the perspective of a healthcare provider, and with or without associated interpretations.” This definition suggests that a class such as OGMS Clinical Picture perfectly describes its meaning, though not as an overarching concept to diagnosis or objective specifications.
The second one is an archetype that demonstrates the classification as Objective specification, the Goal Archetype. It conformed to modelling, requiring specification of the objective intended, along with the time where it is expected and the standard that will evaluate its success. Overall, this class appears to be adequately represented. 3.4
For this analysis of this archetype category we evaluated the medication order, being one of the most common instructions. It is defined as “an order or instruction created by a clinician which specifies which medication to take, when, for how long etc.” It is directly related to the medication action archetype by an item called Medication activity (See section 3.2). This was suitable for ontological representation since it can be shown that both actions and instructions are about processes. While the actions are kinds of processes, the instructions are plans that specify a process type which may be or not instantiated in the future. Not only the ontological representation faithfully describes the entities about medication, but also makes clearer the distinction between a suspended plan (the medication will not be administered to the patient) and a suspended administration (the administration process started but was stopped before completion).
Though not addressing those aspects of the information model that deal with record structure, data types, etc. we have presented examples which demonstrate that the harmonization of the OpenEHR standard by representing archetypes as realist ontologies is feasible. While useful to detect and fix ambiguities in archetype metadata definitions, the merged ontology also revealed several modelling inconsistencies on published archetypes. We have also shown that ambiguity in relations and ontological commitment can be improved by providing rigorous ontological definitions. Future work should focus on standard ways of ontologically representing epistemic and interpretative clinical information, together with their linkage to reality entities. Also, the precise logical formulation of value constraints, data types and cardinality requires further studies, to guarantee universal interpretability of these kinds of representation.
This work is supported by the Hemominas Foundation (Belo Horizonte, Brazil). AQA was being financed by Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (Brazil) – Programa de Doutorado no País com Estágio no Exterior, process number 2380-11-0, during the writing of this paper.