related with it in the other terminologies. This search
scenario requires the definition of a terminology
network, where the different terminologies are
connected by means of related terms. For example,
“Acne disorder” in SNOMED CT corresponds to
“Acne” in ICD-9. Currently, in order to support
users in defining the mappings of a term against the
corresponding terms of the remaining terminologies
of the network, we first search its name in those
terminologies. Then, we use SNOMED CT as a
terminology gateway in case no such term name is
detected, i.e. we automatically fetch its synonyms
from SNOMED CT and then search the synonyms
instead. If still no solution is found, the terminology
server tokenizes the term name, discarding stop-
words and starts a new search with these tokens and
their synonyms. Future work includes using
ontology matching
20
techniques that exploit the
semantics of the terminologies in OWL.
2.3 Inference Model
This section broadly reports on an approach to
convert ADL definitions to OWL and then attach
rules to the semantic version of the archetypes.
Let us consider the following situation. A health
care information system that receives some
OBSERVATION (e.g. “blood pressure”) entry (no
matter where from but fulfilling an archetype
specification) is able to syntactically understand
such information and therefore may deliver it to a
professional, who proceeds with the
OBSERVATION assessment. This is clearly a great
advance for the interoperability of medical systems
but it would be even more interesting if the
observation archetype could tell not only how to
manipulate observation’s values but also how to
assess and evaluate them. Every task that depends on
data analysis and conclusion arrival usually requires
the presence of an expert with enough knowledge to
make a good decision. However if we separate tacit
from explicit knowledge then we could add the latter
in the archetyped concept so the expert only needed
to deal with the former one.
Unfortunately, the ADL language does not
provide support for rules and inference which are
important pieces of clinical knowledge. Besides,
while one of the greatest advantages of two-level
modelling (Beale, 2002) is the carrying out of
archetype definition as a decentralized process, it
allows for contradictory viewpoints to coexist or
even false information to be provided. In addition, a
higher level of normalization of clinical knowledge
could be achieved, encouraging for automated
20
www.ontologymatching.org
means to reuse knowledge expressed in the form of
rules, which follows the same philosophy of sharing
archetypes.
SWRL
21
is a W3C recommendation developed to
improve OWL limitations, in terms of inference, by
means of rules. In combination, they add
considerable expressive power to the Semantic Web.
Furthermore, by merging SWRL rules with OWL
ontologies, we will be able to partially automate
decision making process.
Concretely, the complete knowledge workflow,
from archetypes to inference, can be summarised as
follows: 1) Translating ADL to OWL, 2) Mapping
clinical data to OWL instances, 3) Adding SWRL
rules to the ontology, 4) Executing inference.
When translation is finished, the obtained
ontology file should be filled with instances of
concrete clinical data. Depending on the nature of
the data source, an adequate access approach should
be chosen to correctly map each field to individuals’
properties. From our perspective, preferred source
will be the one where supplied XML files are
compatible to the Reference Model syntax. In this
case, instance mapping is a straightforward process.
As a particular implementation, here we adopt an
inference process based on the Jess-Java bridge
provided with the Protégé ontology editor
(Golbreich and Imai, 2004). The Protégé SWRL
Editor is an extension to Protégé-OWL that permits
interactive editing of SWRL rules. It generates OWL
files that include attached SWRL expressions.
The resulting OWL file, enriched with inferred
knowledge, has many possible destinations. For
example it can be directly delivered to the end user
through a compatible interface or stored in a
repository. In the clinical domain, these results
provide means for automatically improving decision
making and monitoring tasks.
3 INTEGRATION
The following example, focused on preventing
pressure ulcers in hospitalized patients illustrates an
integrated, practical use of the three-dimensional
(Information, Concept, and Inference) architecture
described in this paper. Pressure ulcers are a severe
problem for bedridden patients caused by many
different reasons like friction or humidity, which,
not treated in time can become live-threatening. The
goal of the hypothetical system described in this
example is to automatically produce an alarm if a
risk of ulcer is detected for any patient.
21
www.w3.org/Submission/SWRL
TOWARDS INTEROPERABILITY IN e-HEALTH SYSTEMS - A Three-Dimensional Approach based on Standards and
Semantics
209