An agent-oriented and service-oriented architecture in medicine.

Cristescu, Sorin ; Moldoveanu, Florica

1. INTRODUCTION

An important contribution to the interoperability among medical information systems (Orgun et al.) highlighted the use of mobile agents and HL7-based (hl7.org) ontology. The agents were employed mainly due to their capability of acting autonomously and communicating asynchronously to each other. The HL7-RIM ontology ensured the semantic and lexical connections between the pieces of information carried in the HL7 messages, exchanged by the agents. However, this approach is limited to a particular case, where several medical institutions exchange data kept in local formats. We have to take into account that in the medical domain there are several stakeholders, namely patients, doctors, hospital managers, insurance companies, etc., each with its own goals.

Other research focused on employing semantic web in medicine (Dogac et al., 2005), arguing that web services were designed to wrap and expose existing resources and provide interoperability among diverse applications. This approach covers the case of interoperability of existing applications wrapped as web services, which makes it appropriate in static, legacy environments, but it cannot cover the dynamics of the interactions between the stakeholders of the medical domain, as a multiagent system would do.

The authors of this paper find both approaches valuable, i.e. using multiagent systems as well as semantic web in medical information systems. These aspects will be detailed in the next sections.

2. MOTIVATION

A step forward from the current research would be to extend the semantic interoperability to all the stakeholders, which involves the use of diverse ontologies, not just medical. For example, the personal agent of a patient can make an appointment with the personal agent of the family doctor on behalf of the patient. Or the patient's personal agent can alert the emergency agent (a kind of 112 service), which triggers the ambulance service.

Another step forward would be the use of multiagent systems, instead of isolated, mobile agents. In a multiagent solution, the agents cooperate to achieve a goal. An example would be when taking a clinical decision; the agents involved use game theory to find the Nash equilibrium (Myerson, 1997) to their problem. This way, no agent would be put in disadvantage, and thus the "players" in the game, e.g. the patient, the doctor and the hospital management would take the best possible decision.

A very common scenario is when somebody, for example an elderly person, faints in a park, on a street, or even worse, alone at home. Suppose there is nobody else there who can alert the ambulance service. We argue that wireless Internet can be used in our advantage in such a scenario. Suppose the patient wears a watch which is an embedded device hosting a software agent able to sense the patient's state of health; it autonomously alerts the most appropriate medical service when the patient is in a bad state of health.

Note that patient monitoring systems have been around for a few years now. However, they are very limited in their communication capabilities, in that they usually send signals to a certain hospital, and they are wired uncomfortably to the patient's body and to some local signal processing machine.

The patient's personal agent could send the personal data, the symptoms and the patient's location to an emergency service agent (a kind of 112 phone service), which in turn could inform the closest available ambulance service to rush to the patient. While the patient is transported to the hospital, his/her personal agent could send the patient's medical record together with the current symptoms to the hospital reception agent, which informs the available specialist doctor's agent about the patient's imminent arrival.

The specialist doctor's agent could help him analyze medical images taken with the patient and even learn to discover features and to put diagnostics. An agent could for example learn to detect polyps on the colon, under the doctor's supervision, using a reinforcement learning algorithm (Sutton & Barto, 1998).

Such a scenario is a realistic example of using agents, because, unlike regular software, they manifest the following characteristics, necessary in such a case:

* they are autonomous, so they sense the environment and know what to do without the user's intervention;

* they are mobile, so they can migrate to the destination host and perform a certain operation there; this, together with the previous capability, allow an agent to operate even under sporadic network connectivity and low bandwidth (as it could be the case in a park) and also avoid the need to keep a session with the destination service

* they can learn and improve their behavior; the three capabilities together allow them to learn from other agents, a typical case of multiagent scenarios

As the simple scenario presented above suggests, we envision several types of agents--personal ones, medical agents (per specialty), emergency service agents, hospital reception agents, etc. They don't work in isolation. They communicate, cooperate, negotiate--for example they exchange patient information defined using an HL7-based ontology, they negotiate to fix an appointment between the patient and the doctor, they cooperate to solve a problem using game theory, they learn from each other, etc.

To be easily accessible by humans (e.g. patients, doctors), some of the services offered and used by the agents can be exposed as web services. An example of such a service would be one that puts diagnostics based on patient's symptoms and medical history (extracted from the patient's medical record).

3. ARCHITECTURE PROPOSAL

The authors aim at improving the medical services by enhancing the interoperability and optimizing the flow of information among the stakeholders of the medical domain. As suggested above, the proposed architecture is organized around multiagent systems and semantic web.

From the design point of view, creating a service using software agents or using web services means following the same conceptual steps, as Tab. 1 shows.

The architecture consists of communicating agents (the agent-oriented part), so it is highly distributed in nature and also scalable, since the agents communicate over the Internet. There will be several services (the service-oriented part) that agents need to access:

* an ontology service: its purpose is to translate a message using a certain ontology into another one (but in the same domain, e.g. medical) and it is used by various agents which don't necessarily use the same ontology to communicate

* an emergency service (could be implemented as an agent)

* an EPR (Electronic Patient Record) service, keeping and providing the medical history of patients

* various medical services which wrap legacy medical applications

The first three services presented above are truly global, offering information to any agent on behalf of any user anywhere in the world. For this reason, since scalability is an issue, they are federated services, implemented per region and delegating to the appropriate regional service when necessary. For example, when the patient is taken to the hospital in Venice, Italy, the patient's medical record is asked from the local EPR service. Supposing the patient is resident in Arizona, the Venice EPR service would contact the one in Arizona to get the desired information. Since the patient's medical history might be described using SNOMED terminology (ihtsdo.org) and the medical agent in the Venice hospital might only understand the LOINC terminology (ihtsdo.org), a translation would be necessary, which is provided by the ontology service. This one in turn is federated, so after the central service receives the translation request, it delegates it to the proper service which understands both SNOMED and LOINC and performs the translation.

The EPR, ontology and the other services could be described by a yellow pages type of service, which functions as a broker for the interested agents.

This loose, distributed architecture has as its backbone the usage of standards:

* FIPA-ACL for inter-agent communication (fipa.org)

* SOAP for communication with web services (w3.org)

* HL7-based ontologies and other ontologies, wrapped in FIPA-ACL messages (for inter-agent communication) and in SOAP messages (for communication with web services)

Without these standards and the ontology server to translate between ontologies, the communication among the entities in the system would be impossible or at its best proprietary, thus limited to groups of entities, making the system difficult to reuse and extend with new entities.

4. FUTURE WORK

It is important to notice that the non-functional aspects play a very important role in the architecture of the proposed platform. Specifically, the performance, scalability and security are capabilities vital for the success of the project, as for example nobody would be interested in a system that exposes the patient's medical record to the public at large. Thus, the authors shall focus next on the implementation of the nonfunctional aspects.

Tab. 1 enumerates the steps to take in building the architecture. Issues such as publishing of semantic services and semantic discovery of services need further research.

The authors shall also focus on the representation and storage of agents' knowledge, which are important issues for the system scalability and for the agents' learning capabilities. For example, the intention is that agents communicate in order to apply game theory concepts, to come up with the best possible decision on behalf of the agent's owner.

5. CONCLUSIONS

This paper identifies scenarios in the medical domain where an architecture combining multiagent systems with semantic web allows us to move from the legacy medical applications to new, dynamic interactions, aimed at improving the medical services. Such an approach needs to take into account the functional and the non-functional requirements, as well as the agreed upon standards, in order to have a real integration architecture.

6. REFERENCES

Dogac, A.; Laleci, G.; Kirbas, S.; Kabak, Y. & Sinir, S (2005). Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain, Information Systems Journal, 2005, Volume 31, Issues 4-5, June-July 2006, pp 321-339

Myerson, R.B. (1997). Game Theory: Analysis of Conflict, Harvard University Press, ISBN 0-674-34116-3, Cambridge, Massachusetts

Orgun, B.; Vu, J. (2005). HL7 ontology and mobile agents for interoperability in heterogeneous medical information systems. Computers in Biology and Medicine 36, 2006, pp 817-836

Sutton, R.; Barto, A. (1998). Reinforcement Learning: An Introduction, MIT Press, SUTRH 0-262-19398-1, Cambridge, Massachusetts

*** (2007-2009) www.h17.org, The Health Level Seven Standard, Accessed on: 2008-02-01

***(2009) http://www.ihtsdo.org/snomed-ct, IHTSDO: International Health Terminology Standards Development Organisation, Accessed on: 2009-06-01

***(2009) http://www.fipa.org, Foundation for Intelligent Physical Agents, Accessed on: 2009-06-01

***(2009) http://www.w3.org/TR/soap, SOAP Specifications, Accessed on: 2009-03-01

Tab. 1. The steps to follow and the techniques to be used when
building the services

Steps Agent-Oriented Service-Oriented
 Architecture Architecture

Integrate the Wrap ontology in Link ontology to
ontologies in FIPA-ACL message WSDL-S
messages

Publish the FIPA-ACL Directory UDDI + WSDL-S
services Facilitator + Radiant

Semantic service FIPA-ACL Directory WSDL-S + Lumina
discovery Facilitator

Communication Consume FIPA-ACL Consume SOAP
 message message