applications, and different organisations without
needing to pass through many layers of conversion.
In this case the XML file itself is the message
payload. The schema method is like a map or plan,
where the information elements in the message are
stored in a rigid format, and have a relationship to
each other by virtue of their position in the schema.
The receiving party is aware of the schema structure
and can access the information slots to retrieve the
required information. In this case the schema data
file itself is the message payload. The Object method
is where information is transmitted as a software
object. The receiving party can interface with the
object to retrieve the desired information. In this
case the Object itself is the message payload. FIPA
standard allows any Java object to be sent as part of
a message payload. This object can be an XML,
Schema or other type object which can be handled
by the Java object class.
The primary difficulty in exchanging messages
is to ensure the message being sent is understood
and has the same meaning both by the sender and
receiver. One simple natural language expression,
such as “The woman is on the bus” can be used to
illustrate the complexities associated with
communications between different systems. This
statement can be interpreted in several ways e.g.,
“the woman is travelling in the bus”, or “the woman
is painted onto the side of the bus”, or “the woman is
travelling on top of the bus”. This ambiguity is in
addition to the assumption that the observer (the
listener) receiving the message knows what the
“bus” object is (and this interpretation is the same as
the sender) and “on” is a relationship description
used when discussing the object “bus”. The
confusion associated with this bus example stems
from an overlapping of ontologies. Language and
ontologies are two interconnected components
which are used to formalise the meaning of data, and
preserve that meaning when sending and receiving
messages (
FIPA_a, 2002) (Noy et al., 2001). An
ontology is a data model which represents language
of a domain and is used to reason about these
described objects and relationships between objects.
Most people possess the capability to handle more
than one ontology, such as a domestic and a work-
related ontology. Therefore, different ontologies can
co-exist in the one entity, but care must be made to
ensure the message exchanges are filtered to match
the ontology of the other party. Difficulties in
communicating and sharing medical information
between institutes, individuals or groups has
generated a multitude of ontology and language
implementations for example Galen (Rector et al.,
2005) (Stuckenschmidt et al., 2004), Tambis (Baker
et al., 1999), UMLS (Unified Medical Language
System) (NLM, 2006), ONIONS (Gangemi et al.,
1999), HL7 RIM (Beeler, 2001), GENE (Egana,
2005). These ontologies and language
implementations specify various medical domains
through an abstract conceptualised model of the real
world environment. This demonstrates that no
unique “one-stop-shop” ontology for the medical
domain exists. The FIPA message structure
recognises that in the real world different ontologies
are present, and instead of forcing a single ontology,
it allows many exist in the same environment and
includes a framework to define, describe and
manage them.
The FIPA ontology is composed of two parts, a
vocabulary which describes the terminology of
concepts used by agents in their realm of
communication (e.g. dietitian or renal), and the
classification of the relationships between these
concepts, semantics and structures (FIPA_a, 2002).
Exchanging messages using a specific ontology
provides a richer contextual environment in which to
share information between separate software
entities.
In summary, a payload holds (or contains) the
actual context rich medical information to be
exchanged between two or more systems. The
message is formed using specific ontologies to
ensure the message is understood and has the same
meaning between the sender and receiver. Both the
medical CEN and agent FIPA standards allow
similar types of message payloads to be transmitted.
But for communications to work effectively it is
vital that the message gets to the correct destination.
2.2 Message Envelope
To deliver a message payload to a specific
destination it is necessary to wrap or encapsulate the
payload using a message envelope. A message
envelope consists of a number of key parameters
which allows the message sender, receiver and
content to be clearly identified during message
transmission. Agents not only use messages for
communicating information in a context rich form,
but also for social and collaborative interaction so
they transmit more envelope parameters, and
messages in general. It is therefore imperative to
compare the parameters used by medical and agent
message standards to ensure the agent system can
support them. This will identify what parameters (if
any) would have to be added to the agent
COMMUNICATION OF MEDICAL INFORMATION USING AGENTS
83