-To achieve high quality and efficiency standards, interoperability between different information systems in healthcare is strongly required. Distribution, high modularity, robustness are features of agent oriented architectures, making MultiAgent Systems (MAS) ideal for Health Information Systems (HIS), as the healthcare domain is characterized by system and data heterogeneity. This paper presents an agent oriented architecture to address this kind of issues, capable to access geographically distributed data to allow health professionals to retrieve/update any patient's record efficiently and reliably. The proposed architecture is composed by three layers, to allow local data storage keeping clinical information available by authorized facilities and physicians. Furthermore MAS technology integrates with legacy systems, wrapping them with agents.
The healthcare domain is facing a growing number of
challenges: the incidence of medical errors is rising; many medical
facilities are understaffed, and serve increasingly large areas;
healthcare costs are rising more and more; healthcare facilities
are under pressure to provide better services with less resources
[
Federated architecture. Healthcare facilities and services are distributed and federated by nature, and clinical data should be maintained in the facility where they are produced, ensuring that information will be updated when necessary.
Security and privacy. Due to the importance and the strictly personal nature of clinical data, information should be processed by mean of secure architectures, addressing privacy laws.
ture should be modular, to avoid a quick obsolescence, and scalable, to support the growing number of medical records; a HIS should be designed to achieve a safety critical degree of reliability.
should integrate with existing systems in order to preserve past investments and to make its adoption practicable for local facilities.
Use of open standards. It is, in fact, a mandatory requirement for those systems, as HIS, addressing interoperability issues.
Multi-Agent System (MAS) paradigm, being characterized
by decentralization and parallel execution of activities based
on autonomous entities [
In this paper we propose an agent oriented architecture
capable to access geographically distributed data to allow
health professionals to retrieve/update any patient’s record
efficiently and reliably. Such architecture meets the
interoperability requirements among different health facilities and, at the
same time, integrates with existing legacy systems (including
local databases), being a new software layer on top of existing
ones: this allows to protect the investments made by facilities
and institutions as required by ministerial directives [
Distribution. A key concept of agent technology is flexibility: the complex issues of interoperability and integration with existing systems is broken down to minor tasks assigned to individual agents: cooperation is the solution to the original question. Retrieving data is possible from any point in the territory just through communication of distributed agents, and expensive infrastructures - as happens with cloud solutions - are not required.
High modularity. Thanks to standardization activities made by the MAS community - FIPA IEEE -, simply adding new agents in the architecture (registering their services and sharing the same ontology) is enough in order to extend the capabilities of the system. Robustness. An agent oriented infrastructure provides many recovery techniques to better achieve fault tolerance goals.
wrapper agents, each one designed for a particular instance of legacy information systems, the architecture represents a higher fully interoperable software layer. Communication at this level is readily able to use well established standard ontologies for messaging (HL7), definition of clinical documents (HL7 CDA), scheduled workflows (IHE) and health care terminologies (such as LOINC and SNOMED CT).
The rest of this paper is organized as follow: section II describes related works, about HIS and adopted technologies to implement them; section III details the multi-agent system architecture; section IV illustrates an implementation related to an emergency-response scenario; section V points out some qualitative evaluations about the proposed architecture; finally, section VI draws the conclusions from the described work.
II.
RELATED WORKS
In recent years, two different technologies have been the
subject of much of the research relating to HIS: cloud
computing and multi-agent systems. A mobile system that enables
electronic healthcare data storage, update and retrieval using
Cloud Computing is proposed in [
Also researches about HIS impact have been carried out. In
[
The agent oriented architecture is expressed by three levels of abstraction, named local platform, district platform and client platform (Fig.1-2): each one is characterized by its specific agents and resources as described in the next subsections. The discriminating factor between the first two layers is of administrative nature: there is a local platform for each health facility in the territory (e.g. a hospital); facilities refers to administrative districts, which constitute the second layer of the architecture; finally, the client level is represented by any software agent which needs to login to the infrastructure to retrieve documents or insert/update a patient’s health record.
There is a local platform (Fig. 3) for each health facility. It has the role to interface with any information system, currently present in the structure, committed to the management of clinical documents (create, edit, search, access) and the scheduling of different departments in the facility. Every local platform needs to know the address of its referring district platform in order to have access to the entire agent infrastructure.
LocalDBWrapper.: The task of such agents is to interface with the databases of a certain local healthcare institution. The advantages in the use of wrapping agents are the following: All the legacy systems would not be modified or replaced, but in fact encapsulated within such agents. In this way, any external agent, which needs to access to data contained by a local database, will be able to obtain them simply by communicating with the referring LocalDBWrapper agent, thus avoiding direct interaction with legacy systems.
It makes possible to abstract the actual data representation within the different information systems available in the various facilities. With this solution, we don’t need to address issues like information conflicts (such as homonymy and synonymy) or data schema inconsistencies by burdensome techniques of renaming, restructuring or even system redesign; it is sufficient to design a wrapping agent for each different legacy system able to translate the internal data representation in the ontology shared by all the agents in the infrastructure.
Hence, using agents to wrap local databases allows to keep data in the local facilities where the medical records are generated, differently from outsourced cloud solutions that store data in remote servers and have to deal with privacy concerns [22]. Furthermore agents have proven useful when directly acting as Web Services, providing agent-based services [23]. An agent that needs data from the LocalDBWrapper is able to obtain the service with a message exchange in the FIPA Agent Communication Language. In order to add a local platform to the entire agent oriented architecture, the LocalDBWrapper agents must register to DF Intra-District agent of their referring district platform: this makes it available from distributed and remote agents, which need to retrieve data contained by the local structure.
DocumentHandler.: This kind of agents are able to access the content of a specific clinical document produced within the facility, such as clinical reports, laboratory tests, prescriptions, etc. In general, a DocumentHandler is contacted by a client agent to get health records managed by it: the DocumentHandler agent locates the requested document through its unique identifier, obtains it from the clinical repository and translates the information in an outgoing message towards the requesting client agent. Hence, the latter will be able to get the contents of clinical data requested.
Service Agents.: This set consists of agents for the management of different departments of the healthcare structure (e.g. radiology, cardiology, analysis laboratory, etc.). This paper does not provide further information on this field, but it is possible to find details about an agent oriented implementation of the Radiology Scheduled Workflow provided by Integrated the Healthcare Enterprise (IHE) consortium in [24].
The main task of a district platform (Fig. 4) is to encapsulate all the local platforms that administratively belong to it. Basically, the district platforms represent the logic layer which composes the final architecture and allows to achieve the interoperability goal of our distributed system: every district platforms, therefore, must know each other their address.
DistrictDBWrapper.: These agents have similar functions with local wrappers: they manage data within district databases. The gateway agent contacts wrappers in order to store or retrieve any reference to a patient’s clinical records, which have been produced by every local platform in the territory or by general practitioners.
DocumentHandler.: DocumentHandler agents manage those kind of documents which are of administrative competence of a district, such as Electronic Health Record (EHR) and Patient Summary [25]. They may refer to health records which are distributed in different local platforms: the Gateway agent has the role to look for and gather this information.
Gateway.: The Gateway agent catches the client requests and makes queries to local and district wrappers to retrieve data about any distributed health record of a citizen (Fig. 5). It returns the addresses of DocumentHandler agents which the client must contact to get the required documents. To accomplish this task, the gateway performs two basic activities: When it retrieves the distributed data required to fulfil a client request, it must integrate them into a data structure, so that the client can handle a single dataset. When a clinical record is produced within a district for a patient belonging to another district, the former gateway must inform the latter one to make its referring DistrictDBWrapper agent register such event in its own district database.
Init.: During the starting phase of the district platform, the Init agent registers the same platform Gateway to all the active DF Inter-district agents of the remote district platforms in the territory.
DF Inter-district.: As we just said, it is the Directory Facilitator in which all the remote Gateways are registered. This allows a single Gateway to communicate with any other distributed gateway in the entire infrastructure.
DF Intra-district.: This Directory Facilitator contains all the LocalDBWrapper agents registrations of the local platforms belonging to the same district.
LoginServer.: Its task is to establish a secure connection with the client that wants to access to the infrastructure to retrieve data in a specified district.
This logic platform contains client applications, which may be any agent oriented software that is able, after a login phase, to access data through the connection with a district gateway agent. Examples of client applications could be: software to access EHR, both by medical staff and citizens, mobile applications to retrieve the Patient Summary for emergency situations, software to update health records by general practitioners, etc.
IV.
SCENARIO
To show the capabilities of this architecture we assumed a scenario where an emergency doctor urgently needs to consult a patient’s health records, in particular his patient summary. According to the EU definition, a patient summary is a clinical document that is digitally stored in repositories with cumulative indexing systems and secure access by authorised people. It is an HL7 CDA compliant document, contained in the patient’s EHR, whose purpose is to summarize a patient’s clinical history and his current situation.
In short, the main Patient Summary’s use cases can be
summed up in [
Emergency situations in which the patient may not give an exhaustive description about his clinical history (problems, allergies, current medicines, etc.). Reliability of the information flows between family doctor and health facilities.
Patients affected by chronic diseases managed by several specialists or elderly in home care regime.
JADE Framework [23] to develop local and district agents in some desktop computers.
An android smartphone application (Fig. 6) to simulate the client agent, developed with JADE LEAP add-on. Ministerial directives to compose a Patient Summary for our experiment, an XML parser and an agent ontology based on HL7 concepts.
The operating mode is very simple (Fig. 7). First of all, the mobile client application log in to the district platform entering its username and password: a secure connection is established with the platform using TSL protocol to ensure secure access to patients’ personal and sensitive data. Then, the client asks for a citizen’s Patient Summary and its relative health records by typing his tax code: the Gateway agent will query the different distributed entities to find the location of required data and inform the client where it can retrieve health records. Finally, the client application gather this data asking directly to DocumentHandler agents of the platforms which hold the patient’s records.
Since the proposed MAS has to be understood as an infrastructure to address the interoperability issue in HIS domain and we implemented a simple proof-of-concept for a specific use case scenario, a quantitative evaluation is impossible at this stage of the work. Nevertheless a qualitative evaluation about the benefits produced by the adoption of MAS can be outlined.
The standardization of agent communication permits to integrate legacy system and new services wrapping them with agents, achieving interoperability and modularity. The JADE framework, adopted for our emergency scenario, adheres to FIPA standards allowing agents to register their services in a Directory Facilitator (DF) agent. Hence, other agents can query the DF to obtain the services they need. Also reliability and robustness can be achieved with MAS approach: keeping the focus on JADE, the framework offers the Main Container Replication Service (MCRS) and the DF persistence; in this way the container responsible for agent management is not a single point of failure and offered services are always traceable.
Some domain experts1 have concerns about the actual applicability of our Multi-Agent approach in present HIS for which Service Oriented Architectures (SOA) are widely adopted. In our opinion an integration between MAS and SOA is both possible and desirable. Furthermore W3C specifications about Web Services confirm that software agents are the running programs that drive Web services both to implement them and to access them [27].
1as Klaus-Peter Adlassnig, during the final panel of the 1st International Workshop on Artificial Intelligence and NetMedicine (NETMED’12)
In health information systems, the importance of addressing interoperability issues among existing systems is widely recognized. A crucial aspect is to allow health professionals to get any information they need about a patient in a pervasive and reliable way, even if these data are distributed in technically and geographically different health information systems.
To meet these requirements, in this paper we proposed an architecture based on MAS technology that takes advantage of the adoption of established standards for the management of clinical documents. Our goal was to show how MAS features can contribute in HIS in terms of interoperability, reliability, modularity and robustness; and how health professionals and thus citizens - could benefit from this efficient distributed system. The adoption of a Multi-Agent architecture responds to requirements prescribed by international boards and local governments; differently from cloud computing solutions that propose to centralize data in the cloud, MAS are more suitable to respect the distributed and federated nature of healthcare services. The proposed architecture ensures that clinical data are stored in the same place where they are produced, and seems better fit what prescribed by privacy laws. Furthermore legacy systems can be integrated simply wrapping them with agents that have to share the same ontology used by existing agents.
As future work the inclusion of proactive agents within the architecture will be investigated, mapping out possible improvements deriving from the adoption of goal-oriented behaviours with respect to the interoperability issue.