Latest revision as of 17:42, 27 August 2013

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

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 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

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.

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

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.

WORKFLOW

The Activator agent, after receiving a new task from the Operative Centre human operator, assigns it to one of the ambulances available. As a first step the Activator asks the MOA for its availability sending a request message (Step 1) negotiating the new task. If the operative unit represented by the MOA is not processing another task, the MOA accepts the request replying with an Accept message (Step 2) and the Activator sends the necessary information (such as location, expected pathology and seriousness) for the new task (Step 3). If the MOA is not ready to receive a new task, it responds with a Refuse message. In this case steps 1 and 2 are repeated with another MOA.

Once at the place, the MOA begins collecting health information from different DSAs (Step 4) representing medical devices such as ECG or Oximenter present at the operative unit through. Other health information is collected from the CSA (Step 5) representing hand-handle devices, such as smart-phone or PDA used by medical staff. All data collected from the MOA are stored into a database together with the patient personal information such as name, surname and age. The data collected from the different medical devices are sent to the CSA from the MOA so the medical staff can visualize these data using the hand-handle device (Step 6). With a pre-configured frequency, the MOA elaborates the data collected and decides which is the most relevant pathology effecting the patient and the seriousness of it. If there are more pathologies affecting the patient, the most relevant one will be taken into account. An example of the order of priority the is the following: Cardiology, Respiratory, Spinal trauma, Head and Facial trauma, etc.

After the MOA has detected the pathology, it retrieves from the database all the hospitals that treat that pathology and sends the SOA representing the nearest hospital the request to host the patient (Step 7). The SOA, considering the available resources, can accept the request sending to the MOA an Accept message or can refuse it (Step 8). If the SOA refuses the request, the MOA asks the SOA representing the next nearest hospital. If no SAO that represents the hospital in the territory respond, the MOA will chosen anyway one of the hospitals. The policy of selection can be the closest one or randomly one of the hospitals. During time, the health conditions of the patient may change getting worse or with the emerging of a more relevant pathology. This means that the MOA can take another decision about the hospital where to send the patient and the steps 7 and 8 are repeated again in order to negotiate the hospital where the patient can be brought. Anyway, reached a pathology with high relevance, the MOA will not change the pathology to a less relevant one even if health parameters turn to be in range, because of medical considerations.

JADE-Leap4Android

JADE has released an add-on for the Android OS in order to integrate the mobile devices to the platform. This gives to the user the possibility to extend their system to the mobile devices. Due to the low computation capacity of mobile devices, JADE uses a split model for the agents being executing on the device platform. An agent is represented by the "front-end container", running on the mobile device, and by an "back-end container", running on the server (by server we mean any device with larger computation such as personal computer and server). The core functionality of the agent resides on the back-end container and the front-end one interfaces with the user interface built over the Android OS to exchange data. The data exchanged and different computation location the is transparent to the user.

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).

Publications

• 2011
  • Elton Domnori, Giacomo Cabri, Letizia Leonardi, "Multi-Agent approach for Disaster Management", SEDM 2011, Barcelona (ES);
  • Elton Domnori, Giacomo Cabri, Letizia Leonardi, "A multi-agent approach for territorial emergency management", WAO 2011, Rende (IT);
  • 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 demo video click here.

Download Ubimedic source code File:Ubimedic.zip

Download Ubimedic2 source code File:Ubimedic2.zip