A Mediation Framework for Achieving Interoperability in Pervasive Grid-Based Homecare Systems V. Koufi, F. Malamateniou and G. Vassilacopoulos Department of Digital Systems, University of Piraeus 80, Karaoli & Dimitriou St. 185 34 Piraeus GREECE +30 210 414 2171, +30 210 414 2769, +30 210 414 2370
{vassok, flora, gvass}@unipi.gr ABSTRACT Healthcare is an increasingly collaborative enterprise involving many individuals and organizations that coordinate their efforts toward promoting quality and efficient delivery of healthcare. In cases where healthcare delivery is intended to be provided at patients’ homes, the delivery process can be facilitated through the use of pervasive homecare systems. In such systems, interoperability is highly demanded in all the levels including the service and data levels. This paper presents a mediator-based approach for achieving interoperability in pervasive processbased healthcare systems built on a Grid infrastructure. The system’s architecture is based on a Grid infrastructure upon which healthcare processes are automated using the Business Process Execution Language (BPEL). Client applications are portal-based, operate on mobile devices and can use radio frequency identification (RFID) technology for wireless capture of identification data. The proposed mediation framework enables decoupling of the healthcare processes and the underlying Grid middleware infrastructures. In particular, it resolves issues raised by both the diversity of the middleware infrastructures and the diversity of data formats and semantics used in the databases exposed by Grid middleware services. The framework is built on a software platform that exploits agent and workflow technology, thus providing robustness, high flexibility and fault tolerance in an environment as dynamic and heterogeneous as healthcare.
Categories and Subject Descriptors H.3.4 [Information Storage and Retrieval]: Systems and Software – Distributed Systems, information networks. H.3.5 [Information Storage and Retrieval]: Online Information Services – Data sharing, Web-based services. J.3 [Life and Medical Sciences]: Medical information systems.
General Terms Design, Reliability, Security.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PETRA’09, June 9–13, 2009, Corfu, Greece. Copyright 2009 ACM ISBN 978-1-60558-409-6...$5.00
Keywords Grid portal application; Business Process Execution Language; software agents; workflow systems; interoperability.
1. INTRODUCTION In recent years, the demand for homecare services has increased substantially due to rising healthcare costs resulting at lower availability of beds in healthcare institutions and in turn to a movement towards earlier patient discharge [1]. Homecare is considered to be a key point for the provision of support to medically fragile children and elderly, individuals with chronic diseases, disabilities or terminal illnesses, enabling them to live independently at their homes [1][2]. Homecare services may be requested by the patient himself (or the patient's family), the general practitioner or some other specialist and usually require instant availability of patient information which is scattered around disparate and geographically dispersed systems hosted by the healthcare providers where the patient has received medical care in the past. Hence, the development of safe and easy to use methods and techniques supporting quality and efficient delivery of such services requires the use of interoperable healthcare information systems (HIS). The movement towards such a HIS requires an architecture that implements interoperability among existing information systems in all levels including service and data levels. Thus, collaboration among healthcare services is realized and patient information can be readily accessed by authorized users at the point of care. This paper presents a mediator framework to address service and data interoperability issues in the context of a service-oriented architecture (SOA) of a healthcare information system implemented in a Grid environment. In the prototype system architecture, healthcare processes are modeled using the Business Process Execution Language (BPEL) and are expressed as web services to enable integrated access to disparate healthcare information. These web services are highlevel services that are created using Grid database services as the basic primitives. Grid database services offer capabilities such as data federation and distributed query processing and are generated by using Open Grid Services Architecture - Data Access and Integration (OGSA-DAI) [15], a middleware product which is part of the Globus Toolkit [19]. They are built as an extension to Web services and deliver added-value, high level data management functionality. For example, unlike traditional Web service solutions, OGSA-DAI supports dynamic creation of services which may combine and transform data from multiple distributed data resources (e.g. via a Distributed Query Processing
service) in order to present an integrated or even derived view of the data [24]. In the remainder of this paper, we refer to web services that are defined, deployed and executed using these service-oriented Grid computing infrastructures as Grid services [16]. The healthcare processes modeled can be executed through wireless and mobile devices (e.g. personal digital assistants PDAs and mobile phones) by means of a customized Grid portal application that complies with the restrictions imposed by the relevant client (e.g. limited display size). Moreover, radio frequency identification (RFID) technology is used for user identification and for accessing healthcare processes in a pervasive manner. The proposed mediator framework resolves issues raised by both the diversity of the middleware infrastructures and the diversity of data formats and semantics used in the databases exposed by Grid middleware services. Furthermore, it complies with the most stringent requirements of high performance, reliability, robustness, scalability, high flexibility and fault tolerance. To this end, it utilizes both workflow and agent technologies. In particular, it uses a set of cooperating agents for the management of interactions between the client applications and the server-side implementations. Moreover, java-based workflows are used for modeling both the logics of interactions and the internal behavior of each participating system. These workflows may involve several tasks such as data retrieval and transformation, computations and other low level auxiliary operations needed during execution of a process handling a client request.
2. AGENT AND WORKFLOW TECHNOLOGY FOR SUPPORTING INTEROPERABILITY IN HEALTHCARE INFORMATION SYSTEMS Homecare applications require availability and accuracy of patient information which is scattered around disparate and geographically dispersed healthcare information systems. The incorporation of Grid technology in the healthcare domain led to the advent of Health Data Grids which serve as the integration infrastructure for shared and coordinated use of diverse data resources in virtual healthcare organizations comprised of geographically distributed and organizationally disparate healthcare providers [25][26]. Moreover, service-orientation of the Grid enables the realization of interoperable healthcare information systems according to the Service-Oriented Architecture (SOA) philosophy. Although HIS interoperability can be achieved by means of these systems, new challenges arise due to the diversity of the middleware products used by different healthcare organizations. Moreover, diversity in the data formats and semantics used in the various local databases exposed by Grid middleware is an issue that needs to be addressed as the requestor of patient data needs to be aware of the terms used in each healthcare institution in order to form a query that will retrieve those data. On these grounds, effective management of interactions in such a heterogeneous and distributed environment is a fairly complex task. The conjunction of agent and workflow technologies provides the ability to execute such complex tasks and helps managing the complexity of the distribution in terms of both administration and fault tolerance. Hence, it can make a major contribution towards resolving interoperability issues in pervasive Grid-based healthcare information systems. When
building such systems, data privacy and security are issues of paramount importance and need to be addressed. Thus, appropriate safeguards of a technical nature should be used to secure personal information against unauthorized access, collection, use, disclosure or disposal. Workflows and Agents Development Environment (WADE), which is the main evolution of Java Agent Development Environment (JADE) [13], is a software platform suitable for the development of mission critical applications by exploiting agent and workflow technologies [14]. In particular, it facilitates the development of interoperable multi-agent systems where agent tasks can be defined according to the workflow metaphor. In WADE each workflow is expressed as a Java class with a well defined structure, thus combining the advantages of workflow technology with the power and flexibility of an actual programming language like Java. Unlike the majority of existing workflow systems that provide a powerful centralized engine, in WADE each agent can embed a “micro workflow engine” and a complex process can be carried out by a set of cooperating agents each one executing a piece of the process [14]. This improves significantly performance which is a matter of prominent importance in the healthcare field. On these grounds, WADE may be considered as a suitable software platform for the development of the mediator that will handle effectively all the interactions among disparate healthcare information systems.
3. RELATED WORK During the last few years, research efforts regarding the realization of interoperability among the existing HISs have been on the rise [3][4][5][6][7][8][9][10][11][12]. Technologies used for this purpose range from low-level techniques such as RPC/RMI to provider-independent techniques based on XML/web services. These techniques have solved to a great extend the problem of interoperability of heterogeneous distributed systems but still lack the efficiency when it comes to performance issues.
4. MOTIVATING SCENARIO The basic motivation for this research stems from our involvement in a recent project concerned with defining and automating cross-organizational healthcare processes spanning a health district in order to implement a district-wide, processoriented healthcare information system providing high quality of medical care when and where needed. The interoperability requirements and the stringent needs for a secure, reliable and high performance system that provides real-time access to sensitive patient information motivated this work and provided some of the background supportive information for developing the prototype system architecture presented in this paper. Typically, a health district consists of one district general hospital (DGH) and a number of peripheral hospitals and health centers. As remote consultations need accessing patient’s medical information which is scattered around disparate and geographically dispersed healthcare information systems within the district, there is a need to ensure that a high performance interoperable environment is created and that authorized access to healthcare services and data is provided. Suppose a healthcare process which is concerned with the provision of remote consultation to a patient in need, at home. For
Figure 1. Remote consultation process model using IBM WebSphere Workflow example, let’s consider the scenario of a general practitioner who works on a diabetes management program with a patient according to which the patient is asked to monitor blood glucose, blood pressure and weight. The blood glucose, blood pressure and weight readings are submitted to the general practitioner who, in turn, accesses patient’s health record in order to view glucose trends and medical information from multiple healthcare providers within the district. Having a consolidated view of his condition and treatments he can adjust the insulin therapy, accordingly. He, finally, sends a reminder to the patient regarding the next date of readings’ submission. Figure 1 shows a high-level view of the healthcare sub-process concerned with remote consultation using the IBM WebSphere Workflow build-time tool [27].
5. SYSTEM ARCHITECTURE Figure 2 illustrates a high-level view of the architecture of a pervasive Grid-based healthcare system in which a mediator is used for resolving interoperability issues. The architecture is described by a three-tier model, comprising the client at the viewer’s site (patient’s home), the server site of the DGH and the Grid (i.e. Health Data Grid) which comprises of the remote data resources used by existing healthcare information systems. These resources are heterogeneous and reside in geographically distributed and organizationally disparate healthcare providers within the health district. Figure 3 illustrates a high level architecture of the proposed mediator, which lies between the client and the existing health district information systems. In essence, the mediator is a multiagent system that handles client interactions with the underlying system. The agents are held in containers running on different servers which are distributed across healthcare organizations of a health district. In this way, a distributed runtime environment is formed where agents handle interactions. Agents’ tasks involved in this procedure are defined according to the workflow metaphor.
The set of the aforementioned containers is called a platform. There is one main container which is deployed in a server at the DGH site and a number of peripheral containers deployed in servers residing at the healthcare organizations of the health district. The main container is the first one to start and all other containers register to it at bootstrap time. In each server, containers are activated by a BootDaemon process. The main container holds three special WADE-specific agents, namely the Agent Management System (AMS), the Directory Facilitator (DF) and the Configuration Agent (CFA). For clarity reasons, these agents are not illustrated in Figure 3. The AMS represents the authority in the platform, namely it is the only agent that can activate platform management actions such as creating/killing other agents, killing containers and shutting down the platform [13]. The DF implements the yellow pages service by means of which the other agents advertise their services and find other agents offering services they need [13]. The CFA is responsible for interacting with the boot daemons and controlling the application lifecycle. Apart from the WADE-specific agents, one application-specific agent is also held at the main container, namely the Gateway Agent (GA), which handles the communication between the client portal and the multi-agent system implementing the mediator. Each peripheral container holds a WADE-specific agent, namely the Controller Agent (CA), and two application-specific agents, namely the Service Handling Agent (SHA) and the Data Handling Agent (DHA), which are the core components of the mediator. The CA, which is not illustrated in Figure 3 for clarity reasons, is responsible for supervising activities in the local container and for all the fault tolerance mechanisms provided by WADE. SHA handles the invocation of the Grid services deployed in the web server of the healthcare institution, while DHA handles data retrieval from the underlying data resource(s). In essence, SHA and DHA undertake the responsibility of virtualizing the local systems by providing a standard interface to the underlying
District General Hospital
Viewer’s Site
Grid
Passive RFID Reader
Grid Service
Existing Information System
...
Mediator
Global Security Server
Grid Service
Data Grid Grid Service Local Authorization Server BPEL Process
Figure 2. System Architecture database(s) and services. In particular, each SHA keeps an image of the Grid services while DHA keeps an image of the database(s) schema of the local healthcare information system. Services and data are mapped to the standard ones populated to the client applications for requesting access to them. A more detailed description of the tasks performed by both SHA and DHA will be provided in the following two sections. The logics of interactions that need to be carried out by both SHA and DHA in order to ensure transparent access to the underlying healthcare services that manipulate patient data are described as workflows. Thus, both SHA and DHA are designed to include a light workflow engine that will execute these workflows. Each time a modification occurs in the underlying system (i.e. database(s) and/or applications) a new or modified workflow reflecting the modification can be deployed at runtime thus
making the agents immediately able to access it.
5.1 Data Interoperability One major problem regarding information retrieval from several distributed databases is the diversity of data formats and semantics used by each database. Hence, a need arises for ensuring data interoperability, namely for enabling automatic interpretation of the retrieved information in a meaningful and accurate manner. Thus, it is ensured that the produced results are as defined by the system from which they were originally retrieved. To achieve data interoperability, all sites must use common terminology for the data they manipulate. To this end, they must defer to a common information reference model which will contain a number of virtual data elements and their mappings to the actual ones. In the proposed architecture, this reference model is defined by means of an XML file where a virtual name Grid
Main & DGH Application Containers
DB
Data Handling Agent
Existing HIS
Service Handling Agent
Grid Services
Gateway Agent
Portal
Grid Services
District General Hospital
Hospital Application Container
Mediator Web/Application Server
Web/Application Server Hospital Hospital Hospital
Figure 3. Mediator Architecture
is assigned to each data element and mappings are defined between the data types of the actual data elements and the data types of the virtual data elements (where applicable). An excerpt of this file is illustrated in Figure 4. The XML file resides at a server hosted at each healthcare setting.
patient pat pat_id/ int pat_name varchar(20) varchar(15) ...
Figure 4. Excerpt of XML file storing the mapping of virtual data elements to actual ones.
5.2 Service Interoperability While Grid computing can resolve HIS interoperability issues to a great extent, it introduces new interoperability challenges due to the diversity among the Grid middleware used for exposing each HIS’s functionality and underlying medical data. A solution to this problem is the virtualization of Grid services in order to hide technical details of each middleware platform from users and applications and to support application-level interoperability among different Grid resources. The proposed mediator realizes this virtualization by providing a uniform interface to each one of the remote Grid services. When a request for a service invocation is issued, the SHA captures it and performs a number of activities in order to determine the way this service should be invoked by taking under consideration the version of the middleware used for its generation. These activities are defined according to the workflow metaphor as illustrated in Figure 5. This workflow is java-based and constructed using Workflow Lifecycle Management Environment (WOLF), a development environment for WADE-based applications [25].
transformations in the SQL query to be executed. This is done in accordance with the XML file mentioned in the previous section. Finally, the service is invoked.
GET_GRID_MIDDL_ VERSION
INVOKE_GRID_ DATABASE_SERVICE GET_DEVICE_TYPE
TRANSFORM_DATA
INTERPRET_AND_ DESPLAY_RESULTS
Figure 5. Workflow of actions taken by the SHA. iii. Acquisition of requesting party’s device type - if the version of the Grid middleware is not the latest, namely OGSA-DAI 3.1, after retrieving the data from the remote database and before delivering it to the requesting client, the type of the device used by the user is queried in order for the relevant data transformations to be performed according to the capabilities of the device (e.g. display size). iv. Data transformation – for previous versions of Grid middleware (i.e. versions other than OGSA-DAI 3.1), the data retrieved by means of the Grid service need to be transformed by the DHA at the remote host prior to being delivered to the requesting client. To this end, the appropriate stylesheet is selected according to the requestor’s device type and data are transformed accordingly.
According to this workflow, each time a request is issued for a task execution, the following activities are being executed: i. Acquisition of Grid middleware version - upon request for a remote Grid service invocation, the relevant SHA, which resides at the healthcare setting, where the Grid service is deployed, queries the server hosting the service in order to acquire the version of Grid middleware used for its generation. ii. Grid service invocation - given the Grid middleware version, the SHA determines the format the request should have and makes all the relevant transformations to the initial request. If the execution of the service involves data retrieval, the DHA is contacted in order to determine and perform all the required
Figure 6. OGSA-DAI workflow for data transformation In case OGSA-DAI 3.1 is being used, the data transformation is performed within the Grid middleware framework by means of an OGDA-DAI workflow. In OGSA-DAI, a workflow
consists of a number of units called activities. An activity is an individual unit of work in the workflow and performs a well-defined data-related task such as running an SQL query, performing a data transformation or delivering data [15]. Figure 6 illustrates the OGSA-DAI workflow that needs to be executed for the transformation of data prior to their delivery to the requesting client. v. Display data – retrieved data are interpreted in accordance to the information reference model and are displayed on the client’s display after being consolidated.
5.3 Security Issues In the prototype system architecture, access control issues are handled by a special kind of application-specific agent, the Access Control Agent (ACA). In particular, each peripheral container holds an ACA which during, user interaction with the system, decides whether access of a given subject (patient, healthcare professional, other specialist) to given object (healthcare service or data) should be permitted or denied by taking into account the current context. The contextual information influencing authorization decisions is determined by a pre-defined set of attributes that may relate to the user (e.g. user roles, user/patient relationship), to the environment (e.g. client location and time of attempted access) and to the data resource provider (e.g. the healthcare organization’s security policy). For example, the permissions of a physician accessing the system via a portable device are adapted depending on his/her identity, location and time of access as well as the security policy of each healthcare organization where a portion of the requested information is stored. The logics of interactions that need to be carried out by the agent in order to ensure authorized access to the target objects are also described as workflows. A thorough description of the authorization mechanism incorporated in the proposed architecture is out of the scope of this paper.
6. IMPLEMENTATION ISSUES The architecture presented in this paper has been implemented in a laboratory environment using WADE 2.0. The latter is built on top of JADE [13] and uses Java Runtime Environment 1.5.0 for executing the workflows that define agent tasks. The software tools used are Apache/Tomcat as Web/Application Server and Globus Toolkit (GT4) for the provision of Grid middleware services. OGSA-DAI and its extension, OGSA-DQP, are used for the generation of the Grid database services using the geographically dispersed data resources. In our implementation, a PostGres SQL relational database and a MySQL database are used as data resources. The port types and descriptions of the Grid database services are described by generated WSDL, which also indicates the way these can be accessed. The BPEL engine used for the execution of BPEL healthcare processes is ActiveBPEL [20], an open source BPEL Engine [16]. The portal providing access to this engine is based upon GridSphere portal framework [22]. The GridSphere Portal is a Java Servlets/JSP based framework that builds upon the Java CoG Kit [18], Globus Toolkit [19] and MyProxy [17] to support such features as single sign-on, job submission and data movement. The GridSphere portal framework is based upon the Java Portlet model [23]. The portlet concept is a Java standard (JSR-168) [21].
7. CONCLUDING REMARKS AND FUTURE WORK Homecare provides a practical alternative to the delivery of healthcare services to medically fragile children and elderly, individuals with chronic diseases, disabilities or terminal illness, enabling them to live independently at their homes. Remote consultations constitute an important part of those services and when used appropriately can be of value to all parties involved. However, in order for those consultations to be effective, physicians need to have a consolidated view of patient’s medical information which is scattered around disparate and geographically dispersed systems hosted by the healthcare institutions where patient has received medical care. Thus, much effort has to be put to achieving interoperability among existing healthcare information systems. When building interoperable healthcare information systems it is of paramount important to ensure that data and service interoperability issues are addressed efficiently. At the same time, the most stringent requirements of high performance, reliability, security, robustness, scalability, high flexibility and fault tolerance should be met. To this end, a mediation framework has been proposed, based on agent and workflow technology that lies between client applications and existing healthcare information systems that resolves data and service interoperability issues and complies with all of the above requirements.
8. REFERENCES [1] Lang, A., Edwards, N., and Fleiszer, A. 2007. Safety in home care: a broadened perspective of patient safety. Int. J. Qual Health Care, 2008, 20(2), 130-5. [2] Maglavera, S., Prentza, A., Maglaveras, N., Lekka, I., Sakka, E., and Leondaridis, L., Continuous Home Care Monitoring Services through INTERLIFE. In Proceedings of the IEEE Engineering in Medicine and Biology Society, (New York City, New York, USA, August 29-30, 2006). IEMBS’06. [3] Berler, D. K. A., and Pavlopoulos, S., Design of an Interoperability Framework in a Regional Healthcare System, In Proceedings of the IEEE Engineering in Medicine and Biology Society (September 1-5, 2004). IEMBS '04, pp 3093–3096. [4]
Grimson, J., Grimson, W., and Hasselbring, W, The SI Challenge in Healthcare, Communications of the ACM, 2000, 43(6), 48–55.
[5] Hsieh, E.A., Hsieh, S.L., Weng, Y.C., and Yang, T.H., Feipei Lai Cheng, P.H. et al. Middleware Based Inpatient Healthcare Information System, In Proceedings of Bioinformatics and Bioengineering (Boston, Massachusetts, USA, October 14–17, 2007). BIBE 2007, pp 1230–1234. [6] Jin, D., and Cordy, J.R. Integrating Reverse Engineering Tools using a Service-Sharing Methodology, In Proceedings of the 14th IEEE International Conference on Program Comprehension (Athens, Greece, June 14-16, 2006). ICPC’06, pp. 94–99. [7] Jin, D., and Winter, A. Working Session on Interoperable Reengineering Services, In Proceedings of the International Workshop on Program Comprehension (St. Louis, MO, USA, May 15-16, 2005). IWPC 2005, 291–293.
[8] Ko, L.-F., Lin, J.-C., Chen, C.-H., Chang, J.-S., Lai, F., and Hsu, K.-P. HL7 Middleware Framework for Healthcare Information System, In Proceedings of the e-Health Networking, Applications and Services (New Delhi,India, August 17-19, 2006). HEALTHCOM 2006, pp. 152–156. [9] Souder, T., and Mancoridis, S. A Tool for Securely Integrating Legacy Systems into a Distributed Environment, In Proceedings of the 6th Working Conference on Reverse Engineering (Atlanta, USA, October, 1999). WCRE, pp. 47– 55. [10] Yang, T. H., Cheng, P.H., Yang, C.H., Lai, F., Chen, C.L., Lee, H.H., et al. A Scalable Multi-Tier Architecture for the National Taiwan University Hospital Information System Based on HL7 Standard, In Proceedings of the 19th IEEE International Symposium on Computer-Based Medical Systems (Salt Lake City, Utah, USA, June 21-23, 2006). CBMS’06, 99–104. [11] Wang, W., Wang, M., and Zhu, S. Healthcare Information System Integration: A Service Oriented Approach, In Proceedings of the Services Systems and Services Management (2005). ICSSSM '05, pp. 1475–1480. [12] Zou, Y., and Kontogiannis, K. Towards a Web-Centric Legacy System Migration Framework, Software Maintenance, 2005. In Proceedings of the 3rd International Workshop on Net-Centric Computing (NCC): Migrating to the Web, International Conference on Software Engineering, (Toronto, Canada, May 12-19, 2001). ICSE’01. [13] Java Agent Development Framework, http://jade.tilab.com/ [14] Caire, G. Gotta, D., and Banzi, M. WADE: A Software Platform to Develop Mission Critical Applications Exploiting Agents and Workflows, In Proceedings of the 7th International Conference on Autonomous Agents and Multiagent Systems - Industry and Applications Track (Estoril, Portugal, May 12-16 ,2008). AAMAS’08, pp. 2936. [15] The OGSA-DAI project, http://www.ogsa-dai.ac.uk/
[16] Emmerich, W., Butchart, B., Chen, L., Wassermann, B., and S. L. Price. 2006. Grid Service Orchestration using the Business Process Execution Language (BPEL). J. Grid Comp 2006. 3, 283-304. [17] MyProxy Credential Management Service, http://grid.ncsa.uiuc.edu/myproxy/ [18] Java CoG Kit, http://www-unix.globus.org/cog/ [19] The Globus Toolkit, http://www.globus.org/ [20] Active Endpoints, ActiveBPEL Open Source Engine Project, http://www.activebpel.org/ [21] JSR-168 Portlet Specification, http://www.jcp.org/aboutJava/communityprocess/final/jsr168 [22] Gridsphere Portal Framework, http://www.gridsphere.org/gridsphere/gridsphere [23] Grabowski, P., Lewandowski, B., and Russell, M. Access from J2ME-enabled Mobile Devices to Grid Services, White Paper. [24] Antonioletti, M. , Hong, N. C., Hume, A., Jackson, M., Krause, A. and Nowell, J. 2003. Experiences Designing and Implementing Grid Database Services in the OGSA-DAI Project, Designing and Building Grid Services Workshop (October 2003). GGF9. [25] Pereira, A.L., Muppavarapu, V. and Chung, S. M. RoleBased Access Control for Grid database services using the community authorization service. IEEE T. Depend. Secure, 2006, 3(2), 156-166. [26] Malamateniou, F. and Vassilacopoulos, G. Developing a virtual patient record using XML and web-based workflow technologies. Int. J. Med. Inform., 2003, 70(2-3), 131-139. [27] IBM Corporation. IBM Websphere Workflow – Getting Started with Buildtime V. 3.6, 2005. [28] Caire, G., Porta, M., Quarantotto, M., and Sacchi, G.: Wolf an Eclipse Plug-In for WADE. In Proceedings of 6th International Workshop on Agent-Based Computing for Enterprise (Rome, Italy, June 23-25, 2008). ACEC 2008.
