...
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 particular notions of the concepts they model - for example kumho solus kr21 , the base data types (Integer, Boolean etc) of programming languages.
...
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.
...
- 'ontologies of reality' - ontologies whose subject matter is real things, processes or events, rather than information
- 'ontologies of information' - ontologies whose subject matter is information of any kind - i.e. utterances committed to a medium. Concepts undelying underlying such an ontology are likely to have to do with the process of investigating, recording, reporting or similar ideas.
...
In openEHR we are interested in ontologies of both kinds. Since the EHR is about recorded information, ontologies of the second kind, of information, are relaventrelevant. However, within recorded information of course we expect to find:
...
The openEHR Reference Model includes an information model which defines many classes. The information model, although relatively basic with respect to some of the ontologies in the biomedical space, nevertheless contains ontological commitments of its own - i.e. formal descriptions of certain real-world concepts relating to recorded health information. 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.
| There are 5 types of ENTRYs defined: an ADMIN_ENTRY type and 4 sorts of CARE_ENTRY types: OBSERVATION, EVALUATION, INSTRUCTION, and ACTION. 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 the way it is today has an ontological design which is described in a MedInfo 2007 paper. 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
...
The explanation of the ontology behind the openEHR Entry model is in MedInfo 2007 paper. 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.
| 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. |
| 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.
|
| The Clinical Investigator Record (CIR) ontology: |
...
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.
...