From Agentgroup
Revision as of 16:29, 29 May 2011 by Elton Domnori (Talk | contribs) (Demo)

Jump to: navigation, search

Ubimedic

Involved people

Giacomo Cabri

Francesco De Mola

Letizia Leonardi

Overview

The UbiMedic architecture is an agent-based context-aware middleware, a complete framework tailored to support management and communications in medical and territorial emergencies. UbiMedic has been thought to achieve an easy integration in the entire system of brand new entities, be they people or medical devices, providing an integrated information platform, upon which more intelligent services for health care can be successively deployed. UbiMedic aims at building a distributed context-aware platform with mobile agents implementing helpful services for user applications. The middleware is an agent-based framework and is designed taking into consideration the importance of portability even on small devices (e.g. PDAs or other limited user’s terminals).

A layered view of the architecture

Layered view Ubimedic.jpg

The UbiMedic specific layers of the middleware stack offer both low and high level services to grant dynamism and context-awareness features to the system.

Ubimedic Services.jpg

UbiMedic is implemented on top of JADE agent platform and exploits the facilities provided by the platform. The latter is composed of several Peripheral Containers, representing different nodes with their own JVM, and a centralized Main Container, providing the basic facilities for the platform management.

UbiMedic agents

Ubimedic agents.jpg

The framework proposes a three-level decomposed approach, related to three corresponding agents. The main idea of each application accessing a medical device (e.g. an electrocardiograph or a pulse oximeter sensor) is the definition of the following three kinds of agents: a User Interface Agent (UIA) in charge of managing user interactions, by means of a more or less complex GUI providing all the suitable tools to end-user monitoring of the detected patient data; a Physical Resource Interface Agent (PRIA), which has to collect and make available the patient's vital signs measured by medical devices to requesters all over the platform; a Proxy Agent (PA), an intermediate entity which includes the proper logic to process and filter the data collected by PRIA according to the specific medical device typology and to the particular goals of the application.

UbiMedic-RED

UbiMedic-RED (Role Enabled Devices) is a prototypical application exploiting the concept of agent role to carry out an easy and seamless integration of heterogeneous medical devices, resulting in a sort of plug-and-play device installation. The proposal, based on the UbiMedic architecture, consists in encapsulating specific medical device handling within software agents. This is reached through an interaction model based on the role concept. Among other advantages, roles can be exploited to achieve separation of concerns between the business logic (embodied in the agent) and the interaction logic (embodied in the role). An appropriate infrastructure is in charge of providing role capabilities to the agent; in UbiMedic-RED we adopt the RoleSystem infrastructure associated with the Jade agent platform.

The following picture shows the sequence of steps designed in UbiMedic-RED according to the role-based approach.

Ubimedic Red Interactions.jpg

A new medical device joining the platform must be equipped with a vendor-specific role, the implementation of which is provided by the device’s manufacturer, enclosing the know-how required to interact with the specific medical device (step 1). First of all, the new device must connect to the platform through a registration request, addressed to a centralized UbiMedic service (2). The system creates a generic PRIA in a centralized node with a code repository (3); then, the new PRIA moves back to the node of the requesting device (4), where it assumes the role of the specific device manufacturer, resulting in a complete personalized PRIA (5). The assumed role enables the device to interact with the other agents in the platform, though using its own procedures and proprietary protocols. In fact, the PRIA can acquire data from the medical device via its proprietary protocol managed by the embodied role (6), and, at the same time, can deliver the collected data to the target UIAs or PAs, interacting via standard ACL (7).


Ubimedic2

Involved people

Elton Domnori

Giacomo Cabri

Letizia Leonardi

Overview

Ubimedic2 is multi-agent framework able to support the management of territorial emergences. It extends the idea of the former Ubimedic including introducing the idea of the operative units such as ambulances and hospitals which are involved in the coordination of the rescue operations. We propose a distributed approach where all the operative units using the agent technology, collaborates with each-other and arrange the coordination of the rescue operations. Agents support the medical staff in the decision making process, collect and store digital data patient, collaborate for a better use of the resources still keeping the ability to succeed in their task in absence of communication.

Architecture layer

Ubimedic2 arch layer.png

Agent structure

Service agents (SA) are the agents that represent devices.The device can be a medical one or a simple notebook or PDA that human operators use to insert data or read data taken from the medical devices such as oximenter, ECG and defibrillator. These kind of device has limited functionality and there is no decision making. We divide this agent typology in two categories
Device Service Agent (DSA) is the agent that represents the medical device in use by the operators. The device uses an agent to interface with the rest of the world offering a determined service or information. This is the most simple agent in our architecture. It simply responds to a request by returning the requested data. Devices usually operate in a limited area depending on the environment they are placed in, like the vehicle or the hospital division.
Client Service Agent (CSA) is the agent that represents the client interface device of an operator. The device is used as input/output device where an operator inserts the necessary information and examine the patient file. This device can be notebooks, PDAs, smart-phone, etc.
Operative Agents (OA) are the agents that represent the operative unit like ambulance, medical car, hospital, etc. This kind of agent makes use of devices communicating with their respective service agent and collaborating with the other operative agents taking the most appropriate decision. Again, we split the operative agents typology into two categories
Mobile Operative Agent (MOA) is the agent that represents a mobile unit like: ambulance, medical car, helicopter, etc. This agent communicates with service agents (representing devices mounted on the vehicle) in order to receive the necessary information and other mobile and fixed agents in order to organise the operation.
Fixed Operative Agent (FOA) is the agent that represents a fix unit like hospital or temporary treatment camp, etc. This agent communicates only with mobile operative agent when they receive a request to accommodate a patient with a determined pathology.
The Activator is a agents in charge of activating the other agents when units are ready to be used and of deactivating them when the units aro no more available. It receives the request from the human operator when a new operation is needed, asks for the activation of the standby units when necessary, etc.


PIM

The Controller Process (CP) is not an agent but a process. One CP is created when a new operation needs to be performed. It is a PIM process that will navigate over all the mobile agents that are involved in the operation in order to control the overall operation. It is like the operative centre and is necessary to hold some knowledge that is not under the mobile units competence. For example, when other ambulances are necessary, the controller activates the request for other ambulances and wait till other medical units are ready to be used (in our context, when other agents are activated and are in the ready status).

Ubimedic2 pim.png


Publications

  • 2011
    • Elton Domnori, Giacomo Cabri, Letizia Leonardi, "Designing and implementing intelligent agents for e-health", EIDWT 2011;
    • Elton Domnori, Giacomo Cabri, Letizia Leonardi, "Ubimedic2: An Agent-Based Approach in Territorial Emergence Management", PCTH 2011;
    • Elton Domnori, Giacomo Cabri, Letizia Leonardi, "Managing Territorial Emergences with Ubimedic2", PCTH 2011 - demo session;
    • Elton Domnori, Giacomo Cabri, Letizia Leonardi "Coordination Issues in an Agent-Based Approach for Territorial Emergence Management", WAINA: p184-189 (2011);

Demo

For the demo video click here.