ontology[10] are suggested. Finally, we have developed one ontology for describing
information about the state of the patient, which contains 121 classes divided into 28
categories to represent states such as the level of exertion (low, medium, high intensity)
or the position of the patient (standing, sitting,...).
On the other hand, composite observations are composed of two or more observa-
tions, either simple or composite. They are intended to represent observations of phe-
nomena such as the Blood Pressure, which is composed of the systolic and diastolic
blood pressures. Below, we present some OWL2
4
axioms that represent the general
terms for representing medical observations
5
:
c:Observation ≡ c:Simple Obs ⊔ c:Comp Obs
c:Simple Obs ≡ =0 c:comp
c:Simple Obs ⊑ =1 c:value ⊓ ≤ 1 c:unit ⊓ ≤ 1 c:protocol.c:Protocol ⊓
∀c:state.c:State ⊓ =1 c:site.c:AnatomicalSite
c:Comp Obs ≡ ≥ 2 c:comp.c:Observation
Specific observations are described as specializations of these general terms.
Other main components of the proposal are Application ontologies, which repre-
sent the observations as they are understood in one particular health information sys-
tem. When such a system wants to join the framework, the following steps must be
followed: first its Application ontology has to be defined on top of its underlying data
repository. One module named Internal2OntoModule has been developed for that task.
In some cases the module will receive as input a database schema and after apply-
ing a set of rules founded on schema features (tables, keys, inclusion, exclusion and
functional dependencies, null values and semantic integrity constraints), it constructs
the corresponding ontology components (classes, properties, relations and restrictions).
More details about the nature of the rules are described in a previous paper of our re-
search group[12]. In other cases, the input will be an archetype description (e.g. of a
EHR standard) written in Archetype Description Language[13] which is transformed to
OWL. Moreover,this module is responsible for creating the Σ links (Fig.1) that regulate
the information flow between the underlying repositories and the Application ontology,
following the guidelines in [14]. Then, the particular system must import the above de-
scribed Canonical ontology and create the integration mapping that relates the terms of
its Application ontology with the terms in the Canonical ontology. A MappingModule
has been developed for this purpose.
Once a particular system A has joined the framework it is prepared to send infor-
mation about observations stored in its underlying repository to another system B in
the framework. Thanks to the Σ links between the underlying repository and the Ap-
plication ontology of system A, the information to be sent is converted into instances
(individuals) of the classes of that Application ontology. Then, all the implicit knowl-
edge (regarding the individuals) that can be inferred from the Applications layer is
made explicit with the help of a reasoner. At this point, the integration mapping that
4
For the sake of conciseness we use the Description Logic (DL)[11] representation of axioms.
5
Throughout the paper, the namespace ’c’ will be used for referring to terms in the Canonical
ontology, and namespaces ’a’ and ’b’ will be used for referring to the ontologies of some
specific systems A and B
47