(→Overview) |
(→UbiMedic services) |
||
| Line 16: | Line 16: | ||
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. | 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 | + | ===UbiMedic agents=== |
| + | [[Image:Ubimedic_agent.jpg|center]] | ||
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. | 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. | ||
| Line 22: | Line 23: | ||
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. | 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). | 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). | ||
| − | + | ||
===Interactions among the UbiMedic-RED components=== | ===Interactions among the UbiMedic-RED components=== | ||
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). | 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). | ||
Revision as of 10:54, 2 February 2010
Contents
Ubimedic
Involved people
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.
The three agent typologies of a medical device application service 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).
Interactions among the UbiMedic-RED components
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).