This page is halfway through being transferred from http://www.openehr.org/FAQs/t_ontology_FAQ.htm
The main purpose of this page is start a wider discussion about openEHR and ontology, involving ontology experts. The goal of such a discussion would be to find improvements to openEHR so as to ensure that it really is a model of health information suitable for computerised inferencing and other processing - e.g. decision support, medication interaction analysis and guideline processing. The aim is thus a practical one.
During the history of openEHR its authors learned much about ontology, and made what we believe is a reasonable analysis underlying parts of the openEHR architecture. Now it is time to get people with a lot more experience in this area to have a look at what we have done, and to show us how to improve.
The structure of this page is as follows:
Ontologies are formalised ways of describing aspects of the real world. They are used for two main purposes: a) so that multiple people and computers can agree on the same facts and b) so that computerised inferencing can be performed, usually based on classifying individual facts (patient A has chronically raised blood pressure) in categories (hypertensive person) so as to access facts of the category (increased risk of stroke) relevant to the individual. Many other kinds of reasoning can be done.
There is much work going on in ontologies around the world, including in biomedical ontologies. Most of the work is designed with computer-based reasoning on facts e.g. recorded in patient data in mind. One of the challenges of ontological models is that to work, the data on which inferencing is to be done using the ontology must themselves have a meaning consistent with the ontology. In practical terms this means that the information model(s) of the data must be consistent with the ontologies, in other words, if the data record a 'allergy' for a patient, this has the same meaning as 'allergy' does in the ontology. However, this is often not the case due to poorly defined terms; 'allergy' might have been used to mean 'an allergic reaction' or 'a diagnosed allergy.
Ontologies also exist in software, although most software developers have no idea of this, due to the failure so far of mainstream ICT education to take account of semantics within technical models (i.e. 'class', 'object' or E-R models in the programming sense). Nevertheless, everytime any 'modeller' or programmer creates code, a UML model or an information schema, they are creating some kind of ontology, usually of informational concepts. Software models should be understood as ontologies, because they make commitments to certain flavours of the concepts they model - including the base data types (Integer, Boolean etc) of programming languages.
A basic categorisation of ontologies used in the ontology world is upper and domain or specific ontologies. An upper ontology is domain-independent, and extremely general; they are applicable over many domains.
If you have never seen an ontology before, you may find John Sowa's top-level categories interesting - this is a well-known example of an upper ontology. Needless to say, this is regarded as by no means the best or most relevant in the biomedical sphere, but it is a useful reference point.
Although at some level all ontologies are 'descriptions of an aspect of reality', for the purposes of this page, we will distinguish between two broad categories of ontology:
We draw this distinction because as soon as something s recorded, there is a question of what the recorded form looks like:
In openEHR we are interested in ontologies of both kinds. Since the EHR is about recorded information, ontologies of information are relavent. However, within recorded information of course we expect to find:
Ontologies of the first kind are therefore just as important. In our opinion, it is not yet clear how they inter-relate....
top
At the moment we are not trying to provide a comprehensive summary of the work done in the area of health information ontologies, but it is worth mentioning some of the work of ontological significance that has occurred over the years:
If we are to take an ontological analysis of openEHR seriously, we need to establish success criteria. These might include:
Relevant biomedical ontology resources to be investigated with respect to the openEHR appears to include the following.
Within the openEHR environment there are 3 entities that can be considered in an ontological way: the reference model, the archetypes, and terminology (both the internal openEHR vocabularies and well-known external terminologies such as ICDx, ICPC, LOINC and SNOMED CT).
The openEHR Reference Model defines many classes, but the part of the model of most ontological interest is the 'Entry' part, which is formally specified in the openEHR EHR Information Model; it can also be seen online as detailed UML. A summarised UML form of the Entry types in openEHR is illustrated below.
Entry types The 6th type is called GENERIC_ENTRY, and is designed for mapping into and out of legacy and integration structures such as CEN EN13606, HL7 CDA, message and relational databases. The UML model of this type is here; it is documented in the openEHR Integration IM. All of these types are extremely generic and archetypes are used to define the specific business/domain content models under each of these types - see archetype mindmap for examples.
The openEHR Entry model has an ontological design which is described in a forthcoming MedInfo 2007 paper (in-press copies are available on request). We can summarise the approach with the following three diagrams. The first is a model of process (shown in two ways); the second shows a cycle of information creation due to the process, and the last shows the information ontology developed in openEHR for recorded clinical information.
The explanation of the ontology behind the openEHR Entry model is in a forthcoming paper by Beale and Heard ref. The following 3 diagrams show in a summarised way the ontological underpinning of the openEHR Entry model the way it is today. The first is a model of process, the second a model of information creation due to this process, and the third an ontology of information.
openEHR process model We model health care delivery as two kinds of process: a clinical process, corresponding to the interaction between a 'clinical investigator system' and a 'patient system', situated within a business process, which is owned by an 'administrative context'. The clinical process constitutes a sub-process of the business process, i.e. it is the main mechanism for the business process to achieve its goal, which is to satisfy a demand for care on the part of the patient. The administrative context corresponds to the health system as a whole, rather than a single enterprise, since from the patient care point of view, the mobilisation of care delivery is carried out by a network of provider organisations. The model can be illustrated in two equivalent ways, as shown in Figure 3. more....
openEHR Entry process
The terms 'observation', 'evaluation' etc defined above are not themselves the same as information types, since they refer to a variety of phenomena within the process: information from observations, the activity of evaluation, acts of intervention, and goal statements. To be more precise, we are mainly interested in information created by the investigator system, since this notional agent encompasses any person or device who/which performs any healthcare related task, including the patient herself. The investigator system is therefore the creator of all clinical information in the health record, including patient-entered data. A small amount of administrative information may also end up in the EHR, generally created by non-clinical actors in the organisational context.
We can redraw the investigator system in order to more clearly show the types of information created during the care process, as shown in Figure 4. Five types of information are identified, as follows:
openEHR Entry ontology The Clinical Investigator Record (CIR) ontology:
An ontology of types of recorded health information. This ontology is probabaly the main starting point for analysing the ontological qualities of openEHR.
Of the biomedical ontologies mentioned above, the OBI and the OCI appear to be closest in purpose. No proper study of these has yet been made with respect to openEHR.
In the openEHR approach, most description of the contents of recorded health information is left to archetypes (openEHR FAQ). An archetype can be thought of as a model of some clinical content (e.g. what is recorded in a urinalysis, or an ante-natal visit), expressed in a constraint formalism known as ADL (which has some similarities to OWL). Over 200 archetypes have been defined during NHS projects, Australian GP projects, and openEHR activities (openEHR archetypes page). To go straight to the point, an ontological way of looking at the archetypes that exist is the mindmap view. The structure of each archetype can be viewed by clicking on a node in this view. Another way to view archetypes is with the ADL workbench tool, and with various archetype editors. Example archetypes: Microbial lab observations; Adverse reaction; Examination of named body part.
There are at least two ontological questions with respect to archetypes:
The most important thing we can say with respect to archetypes and ontology is probably this: archetypes are not descriptions of real things like biochemical or anatomical phenomena in the textbook sense (e.g. lik a description of how the heart functions in a physiology book); instead they are recordings of something of interest (observation, evaluation etc) during the clinical process, according to the health professional and following typical clinical approaches. In practical terms then, archetypes are practical in their intent, and only capture what health professionals think they need to record.
Of the work mentioned above, the BFO / SNAP / SPAN ontologies may be a good starting point.
To be continued