Integration of hospital data using agent technologies – a case study

Cruz-Correia Ra, Vieira-Marques Pa, Costa Pa, Ferreira Aa, Oliveira-Palhares Ea, Araújo Fb, Costa-Pereira Aa

a Department of Biostatistics and Medical Informatics, Faculty of Medicine of University of Porto

b Hospital S. João, Porto

Contact address:

Ricardo Cruz-Correia

Department of Biostatistics and Medical Informatics

Faculty of Medicine of University of Porto

Alameda Prof. Hernâni Monteiro

4200-319 Porto

Portugal

1

Abstract

Data retrieval and its integration is one of the major problems that face large and complex health organizations. This is

especially relevant when patient information is produced in heterogeneous environments. Implementing a Virtual Electronic

Patient Record (VEPR) system may provide an adequate and cost-effective solution for most clinical information needs. In

this paper, we describe and discuss the use of agent technologies for the retrieval and integration of clinical records in a

VEPR, thus making patient information available at any point of care. Between May 2003 and May 2004, a VEPR was

designed and implemented at Hospital S. João, a university hospital with over 1.350 beds. An agent-based platform Multi-

Agent System for Integration of Data (MAID) ensures the communication among various hospital information systems.

Clinical reports are retrieved from clinical department information systems (DIS) and stored into a central repository in a

browser friendly format. Documents are retrieved in HTML and PDF format and are digitally signed at storage. MAID is

now running for the last 10 months, regularly scanning 7 DIS and collecting a mean of 2.000 new reports each day. A

visualization module for the VEPR was made available in October 2004 and the number of users and user sessions has been

growing since. Currently, over 200 doctors are using the system on a daily basis. The total budget of the project was less

than 400.000 euros. Around 30% of the costs were spent in software development and MAID accounted for only 13% of

the total project budget. The use of agent technologies in the implementation of a VEPR enabled the successful integration

of a large amount of heterogeneous data that could then be accessed from any workstation in the hospital intranet. As few

changes were required to be made in the existing DIS, the implementation has been done over a relatively short period of

time and the stress in the organization was low. Optimization of the scheduling algorithm, automatic notification of health

professionals, introspection of clinical reports, retrieval of XML report representations and extension of VEPR to health

centres are priorities for future research and development. We strongly believe that agent technologies can and should be

used to solve complex data integration and communication problems, which are crucial to the quality of patient care.

2

Introduction

The use of information and communication technologies (ICT) has experienced a major growth in the last ten years as they

became accessible to organizations and individuals worldwide. More recently, ICT are also becoming increasingly common

in healthcare settings.

Due to the dissemination of ICT many hospital departments or even individual health professionals have acquired medical

software or created their own computer databases in order to store and manage records containing relevant data from their

patients. In fact, patient records are used to memorize and communicate health data and to help the delivery of care.

Patient records are both a communication and an information system, which enables data sharing among different health

professionals, and between the past and present [1,2].

Unfortunately, many of these information systems were not designed to be interoperable and so the current use and share

of healthcare data may not be very efficient. Furthermore, the multiplication of these unarticulated systems generates

redundant or contradictory data and the lack of standard terminologies or even the lack of single patient identifiers may

hinder an easy integration and, as a consequence, prevent a successful access to all available patient data.

Inefficient use of healthcare information is likely to be a major problem in large and complex health organizations. This is

especially relevant when patient data, which is produced in heterogeneous environments, at various places and by different

health professionals should be available for authorized individuals at any point of care. In this situation, the cost of the

human and technical resources needed for non-automatic data collection, storage or integration is vast. Also, the lack of an

efficient information flow implies a delayed management of clinical report updates, mainly for some laboratory results, and

an increased length of stay or delays in outpatient consultations and surgeries [3, 4].

Therefore, it is not surprising the growing demand to create integrated electronic patient records that would facilitate the

communication process between health professionals [5, 6]. Nevertheless, health institutions or individual health

professionals may not be willing to give up their current stand-alone information systems, as they fear loosing the control

over the data or loosing some system functions customized to their needs [7].

The idea of a virtual electronic patient record (VEPR) supported on pre-existing information systems could help the

integration process and facilitate the communication among these systems without jeopardizing the existing data or

interfering in future software developments of these systems [8].

Multi-agent systems are known for addressing issues related to distributed information sources. Complex problems are

resolved by managing and integrating heterogeneous entities responsible for solving simpler and smaller problems. These

entities, named agents, have communication skills, autonomous behaviour and a pro-active social nature [9]. Combined,

these characteristics provide the necessary construct to address complex problems and to map the actual process flow [10].

Therefore, agent technologies could provide an adequate solution for the implementation of a successful VEPR.

In this paper we describe and discuss the use of multi-agent technologies in the retrieval and integration of patient data

aiming the creation of a VEPR in a large hospital.

3

System Development

Initial Scenario

With approximately 1.350 beds, Hospital S. João (HSJ) is the reference hospital for the North of Portugal and the second

largest in the country. This university hospital employs around 800 staff doctors and another 400 as trainees, from over 50

medical specialities.

Similarly to all other Portuguese public hospitals, at HSJ patient’s information resources are based on SONHO a system

developed by the governmental agency IGIF (Instituto de Gestão Informática e Financeira da Saúde) that manages data

related to hospital stays, consultations and emergency visits. Although this system has the capacity to manage some general

clinical data (in a module called SAM – Sistema de Apoio ao Médico) it has reduced flexibility regarding the use of these

data by health professionals and lacks specificity regarding the needs of different medical specialities. This may explain why

SONHO is still mostly used for administrative (egg. consultations scheduling) and financial (egg. Diagnosis Related

Groups) purposes rather than for the care of patients.

Not surprisingly, over the past ten years, nearly two thirds of its 24 major clinical departments have implemented or

acquired at least one information system to record specific data focused on the daily management of their patients and on

their own medical research interests. Unfortunately, these departmental information systems (DIS) use a number of

different data structures, database management systems, ontologies, communication protocols, file formats for reporting

clinical results and user authentication systems. In addition, many of these systems are connect to medical devices (egg.

monitoring, imaging or lab instruments), which increase the overall complexity. The scenario includes unrelated applications

managing relevant pieces of clinical information and duplicated data scattered over several databases. Therefore, the vast

majority of patient’s data could only be shared using paper records, conducing to an inefficient flow of information

translated into high administrative costs both in time and staff.

Building a Virtual Electronic Patient Record System

In May 2003, the HSJ Directory Board asked the Department of Biostatistics and Medical Informatics to create a VEPR

system aiming at delivering the maximum information possible to health professionals through the integration of DIS with

SONHO and DRG systems. Nine DIS were initially chosen (table 1). These systems contained many different types of

data and had been implemented using various technologies. The development of communication interfaces was simpler for

the six applications that had Web interfaces because they already used standard communication protocols such as HTTP.

General Architecture

The architecture of this VEPR allows the collection, integration and availability of clinical reports providing an up-to-date

overview of a patient medical history at all points of care. Two major modules were designed (figure 1): the Multi-Agent

system for Integration of Data (MAID) module, which provides for automatic document retrieval and the visualization (VIZ)

module, which shows patient data upon user request.

4

As illustrated in figure 1, MAID collects clinical reports from various hospital departments (e.g. DIS A and DIS B), stores

them on a central repository (CRep) consisting of a database holding references to these clinical reports and a file system where

reports are stored. After searching the database, VEPR users can access the integrated data of a particular patient through a

web-based interface. When selecting a specific report, its contents are downloaded from the central repository file system to

the browser.

The VEPR system server runs on a Pentium 4 (1.8GHz), with 768Mb RAM and a Linux RedHat Fedora Core 1.0 operating

system. The central repository file system, which contains the clinical reports files, is located on a HP StorageWorks SAN,

which is mounted in the VEPR server using the NFS protocol. The database, which contains the patient’s identification

and references to the clinical records, is stored on two HP Server RP5740 RISC computer cluster running an Oracle

database management system.

MAID is built on JADE (Java Agent Development Framework) [11] as a multi-agent FIPA compliant development

platform, for agents’ management and deployment.

Multi-Agent System for Integration of Data

The design of MAID inherits some of the characteristics of the multi-agent systems paradigm namely their independence,

autonomy, scalability and reliability [10]. MAID main entities were designed to cooperate and undertake the necessary

actions in order to build a virtual electronic patient record making existing information available within a reasonable time

frame.

The automatic document retrieval process is achieved by two independent actions (figure 1) performed by a set of agents:

firstly, the retrieval of report references consists on the questioning of each DIS for new clinical reports and the eventual retrieval

of their references (list agents); secondly, the retrieval of report files consists on the actual retrieval of the correspondent clinical

reports files from the DIS to the central repository (balancer and file agents). A particular case of this last action correspond

to the immediate retrieval of a clinical report that is not yet available centrally but has meanwhile been requested by a user

(express agent).

The described actions are mapped into behaviours that define agent’s individuality. These behaviours describe the

necessary steps that an agent must undertake in order to accomplish its purpose. All agents act on an asynchronous and

autonomous way.

The rules that define the environment of these actions take into account the hourly distribution of reports produced by a

particular department according to each weekday (figure 2). This representation can provide the necessary information for

more precise decision making on optimizing report availability. Currently MAID agents’ reasoning is performed

independently. Each agent takes only into account the statistics of its assigned DIS.

A set of plug-ins is available for network communication (e.g. HTTP, HTTPS, simple sockets), database communication

(e.g. Oracle, DBM), logging and digital signing.

5

Report reference retrieval action

List Agents

An individual list agents was assigned to each of the nine DIS. These agents regularly survey the assigned DIS looking for

new clinical reports. For each of these reports a reference is obtained and stored on the CRep database. The list of

references is retrieved exchanging XML messages with each DIS using network plug-ins.

Each list agent XML request is identified by an element composed by two attributes, a unique identification and a time

interval. The first is used for message management and control while the second attribute is used for selecting clinical

reports generated during a specific period of time. Depending on the nature of the problem, unsuccessful requests are

stored for a later request (e.g. network unavailability) or audit action (e.g. database unavailability).

On the other hand, each DIS XML reply is composed by a management element (including the request unique

identification) and a list element containing references to reports produced during the requested time interval. Each report

reference element includes, among other attributes, patient identification, author, type and location (URL) of the report.

List agents store these attributes on CRep database. List agents also update CRep database using patients’ administrative

data from SONHO.

The time interval of the last successful reply is stored for each DIS and used when MAID is restarted (e.g. after a system

crash). List agents assume recovery behaviour, using the stored time interval to retrieve the list of reports references

produced during inactivity of MAID.

Report file retrieval action

Balancer Agents

To each of the nine DIS an individual balancer agents was assigned. These agents regularly survey the CRep database

looking for new clinical reports references.

When new references are available, a FIPA-Contract-Net negotiation protocol [12] is initiated with a number of

subordinated file agents to optimize work distribution. The negotiation currency is the current workload of each of the

subordinated file agent. On protocol completion, the status of each report retrieval is returned to the balancer. If an error is

reported a log entry is registered. Finally, the CRep database is updated by deleting the references of retrieved reports.

File Agents

As described above each file agent is assigned to a specific balancer. File agents are designed to accept a list of report

references after a negotiation protocol with the balancer. The list is processed sequentially as reports files are requested to

the DIS.

For each single patient there is a directory on the CRep File System. The directory path is determined by splitting the last

two pairs of digits of an internal patient identification number and concatenating the entire number in the end (eg. internal

patient number 123456789 is stored at /67/89/123456789/). This operation guarantees an uniform distribution on the

directory tree.

6

After determining the patient’s directory, file agents retrieve the corresponding report using available network plug-ins. The

report is then digitally signed and stored.

Version control of the reports is performed using as fingerprint the SHA1 digest [13] of the location attribute (URL). A

new version of a particular report makes the older version unavailable for users, though securely preserved for auditing

purposes.

Express Agent

The express agent was designed to act in response to report unavailability on CRep file system. This happens when a report

reference already present on the CRep database is requested by a VIZ user but hasn’t already been fetched by the report file

retrieval action.

Therefore, this agent has a reactive nature to VIZ events. The evaluation of its activity may be an indicator of the system

ability to anticipate user requests.

Visualization Module

The integration of clinical information in the VEPR achieved by MAID is presented to users through a VIZ website

available in the Hospital intranet. After authentication, healthcare professionals can access to patient data using several

search methods. The search can be performed either by patient name or by in-patient, consultation and emergency

numbers. As a particular patient can be identified on each DIS by one or more of these identification numbers, this type of

search is able to find all data independently where it is produced.

After patient search a list of all reports collected in the past 24 hours is presented (figure 3), helping users that are just

looking for a recently requested report. The remaining clinical information can be accessed through a left-side menu,

allowing medical doctors to choose from two views: source (DIS) or chronological oriented. Due to the version control

rules only the last version is available to the uses. In addition, a chronological bar is displayed following the clinical reports

list, giving a perspective of past patient hospital events (figure 3).

After selecting a particular report the following steps are taken: determination of the patient’s directory path according to

the internal patient number; retrieval of the report from the CRep file system; and, finally, the digital signature checking. As

previously referred, if the requested report is not yet stored in the CRep file system the express agent is triggered. Figure 4

shows an example of a requested clinical report.

Security Issues

VEPR presents many security challenges namely the need to provide protection to patient’s sensitive information. The

implementation of security mechanisms was thought from the beginning of the project’s development and implementation,

allowing for its better integration and acceptability [14,15]. This subject was tackled according to the three main security

characteristics: integrity, availability and confidentiality.

7

One of the main security issues is the trust put into the information withheld by the stored patient reports. Digital

signatures are security mechanisms that provide the integrity of a report by enabling the detection of unauthorized

modifications. If the digital signature does not match with report contents then this report is marked as not valid [16].

Availability focuses on means to provide for the continuous access to information by authorized users. Equipment and

power redundancy, backups and system monitoring were all put in place to guarantee availability of the system at all times.

The number of reports daily retrieved from each DIS is compared to what is expected and the number of sessions of

different users is monitored. Any deviation from expected values triggers an alert message to the system administrator.

Confidentiality relates mainly to the access to sensitive information by authorized individuals. It is obtained by controlling

access to information and by protecting it while in transit along network communications. Access control policies were

defined by the hospital administration after a proposal from a specifically assigned committee defining roles and levels of

access to VIZ. These policies were implemented using Role-Based Access Control (RBAC), an access control model used

for large organizations.

In order to provide for an efficient way for user identification and authentication, development of access control tools was

based on ENV 12251 European pre-standard [17]. As the network wiring and equipment is spread all over the hospital it is

necessary to protect the network infrastructure from eavesdropping. This was accomplished using TLS authentication

protocol [18], which provides encryption of all information whilst in transit.

Ethical Approval and Norms

This VEPR respects the determinations of the hospital ethical committee (Comissão de Ética do Hospital de S. João) and

follows the requisites from the Portuguese national committee on the protection of personal data (Comissão Nacional de

Protecção de Dados Pessoais). In addiction, is in acceptance with the norms from the King’s Fund quality accreditation

process.

Implementation Costs

Table 2 summarizes the implementation costs. Five technicians worked in this project for one year. During this period they

designed the architecture of the VEPR system, chose the implementation tools, developed the software, defined the

communication protocols with each DIS and installed and tested the system. This software development corresponded to

approximately 30% of the total costs, which amounted to near 400.000 euros. The cost of MAID was around 50.000 euros

corresponding to only 13% of the total project expenses. Another 62% was spent in new hardware and the remaining 8%

with external software companies that had to create interfaces for their DIS.

Results and Current Status

MAID is running since May 2004 and currently scans daily from 7 of the 9 above-mentioned DIS. Although already

integrated, the 2 remaining DIS are not yet producing clinical reports due to administrative reasons. At the present,

documents are collected in HTML and PDF format.

8

During the past 10 months, nearly 500.000 clinical reports from 62.000 patients have been collected and occupy 3.4 GB on

the file system. Currently, nearly 2.000 new documents from 800 patients are retrieved and stored each day.

The distribution of reports and updates from the three main hospital laboratories is shown in table 3. DIS such as Clinical

Pathology frequently generates partial reports, which originates a vast number of updates.

VIZ was made available for testing in October 2004 but only started to be known and routinely used since December 2004.

The number of sessions grew from 315 in December to 780 in January and to 2.126 in February. The number of different

doctors using the VEPR grew in the same period from 21 to 44 and to 209, respectively. Currently, the mean duration of

each session is 9 minutes and, on average, two clinical reports are requested per session.

Lessons and Future Research

The use of multi-agent technologies allowed the successful integration of a large amount of heterogeneous clinical data.

This patient information can now be accessed from any workstation in the hospital intranet thus making the implementation

of a VEPR a useful reality. Also the system provides a user friendly and uniform view of clinical reports instead of the

previous multiple interfaces from the various DIS, which were likely to confuse the user.

Independence between DIS and central systems were guaranteed, enabling eventual upgrades of DIS to be made without

need for major changes in the VEPR. No changes were required to local DIS hardware and full accessibility to previous

collected patient data was maintained at all times.

As minor changes were required to the existing DIS, the implementation and deployment were done over a relatively short

period of time and the stress in the organization was very low. During all phases of the project no DIS has ever been

stopped. There was also no disruption in the clinical information as old records were kept. All these contributed to the

relatively low financial costs.

The process of integration of heterogeneous clinical information systems has shown the existence of several organizational

or technical problems and, indirectly, contributed to its solution. While some reports cannot be associated with identified

hospital patients (e.g. outpatients that are not administratively considered as HSJ patients), some patients had multiple rather

than unique identification numbers, making difficult their correct identification. A similar problem was found with staff

identification numbers, which were reused after staff members left the hospital. Furthermore, hospital servers had major

differences in their internal clock times, amounting to 25 minutes in some extreme cases. Therefore, use of the Network

Time Protocol on every server involved in the VEPR project was mandatory. Also, some of the companies responsible for

DIS lacked the skills to implement the necessary web-services for integration. Finally, the lack of a stable leadership in the

hospital translated into three different directory boards during the period of this project lead to some changes in priorities

and delays in the dissemination of the VEPR.

One of the major consequences of the implementation of MAID may be the reduction or even the elimination of

administrative tasks related to the delivery and storage of clinical reports [4]. Figure 5 illustrates the actual process of

disseminating the information within the hospital. Multi-agents technologies offered a natural and transparent way of

mapping this information flow and corresponding human actions (e.g. locate, pull, copy, transport and store clinical reports)

during the daily hospital routine. As shown in the figure, MAID covers an area of the hospital information flow that was

9

assured by at least one staff members of each laboratory plus another administrative on each of the main hospital clinical

departments or hospital archives. This corresponds to around 30 members of hospital staff who can potentially be used in

other tasks.

Nevertheless, the clinical and economical consequences of the utilization of this VEPR need to be externally and formally

assessed in the near future. A significant increase of health professional satisfaction may be expected. In contrast,

significant reductions may be expected in the time of access to reports, number of administrative staff, number of duplicates

emitted by DIS, number of delayed consultations or surgeries due to lack of timely patient data, number of misplaced or

misassigned clinical reports or number of unjustified accesses to clinical records.

Currently, MAID agents’ reasoning is performed independently as each agent takes only into account the statistics of its

assigned DIS. The use in the near future of artificial intelligence technologies such as Bayesian Networks coupled with

MAID may optimize the retrieval-scheduling algorithm by considering the VEPR workload together with the frequency

patterns in report production and retrieval and the access time patterns over a period of a day, week or year. Automatic

notification of new clinical reports availability to health professions is also though to be included in MAID’s features.

Introspection of clinical reports is planned and MAID will also be used to retrieve XML report representations provided by

DIS. These two future developments will enable the storage of structured patient data on clinical databases, which besides

visualisation could then be used for other purposes such as knowledge discovery. The existence of these databases should

provide the basis for clinical, epidemiological and management studies thus contributing for more informed medical

decisions [19].

Finally, we hope to expand this system in order to include clinical information produced in regional health centres and,

conversely, to provide hospital data to primary care health professionals thus achieving a full integrated VEPR.

It is therefore our deep understanding that agent technologies can and should be used to solve complex data integration and

communication problems, which are crucial to the quality of patient care.

Acknowledgements

We thank the former HSJ clinical director Dr Cunha Ribeiro for initial incentive and the former hospital director Prof.

Isabel Ramos for enduring support. We are also in debt to the staff of DOI (Departamento de Organização Informática,

HSJ) for its continuing and timely collaboration and to all health professionals who so enthusiastically embraced this project.

The Programa Operacional - Saúde XXI funded by the European Union, financially supported this project.

10

References

1. Dick RS, Steen EB. The Computer-based Patient Record: An Essential Technology for Health Care. NationalAcademy Press, 1997.

2. Nygren E, Wyatt JC, Wright P. Helping clinicians to find data and avoid delays. Lancet, 352: 1462–6, Oct 1998.

3. Berg M. Implementing information systems in health care organizations: myths and challenges. Int J Med Inf, 64(2-3):143–156, 2001.

4. Schmitt KF, Wofford DA. Financial analysis projects clear returns from electronic medical records. Healthc FinancManage, 56(1): 52–7, Jan 2002.

5. Lenz R, Kuhn KA. Intranet meets hospital information systems: the solution to the integration problem? Methods InfMed, 40(2): 99–105, 2001.

6. Halamka JD, Osterland C, Safran C. Careweb, a web-based medical record for an integrated health care delivery system.Int J Med Inform, 54(1): 1–8, Apr 1999.

7. Wyatt JC. Hospital information management: the need for clinical leadership. BMJ, 311: 175–8, Jul 1995.

8. Malamateniou F, Vassilacopoulos G. An implementation of a virtual patient record using web services. Stud HealthTechnol Inform, 95, 2003.

9. Weiss G. Multi-agent Syatems – A modern approach to distributed Artificial Intelligence. MIT Press, Cambridge,Massachusetts, 1999.

10. Moreno A, Nealon J. Agent-based applications in health care. In Applications of Software Agent Technology in theHealth Care Domain, Whitestein Series in Software Agent Technologies, 3–18. 2003.

11. Bellifemine F, Poggi A, Rimassa G. Jade a fipa-compliant agent framework. In PAAM 99, 97–108, 1999.

12. FIPA. Agent management specification. Technical report, Foundation for Intelligent Physical Agents, 2000.

13. US Secure Hash Algorithm 1 (SHA1). RFC 3174. Network working group of Cisco Systems. Available at ftp://ftp-rfc-editor.org/in-notes/rfc2246.txt, 1999.

14. Ferreira A, Cruz-Correia R, Costa-Pereira A. The creation of a secure web-based epr. In Proceedings of Mednet 2003 -Technology and health care: official journal of the European Society for Engineering and Medicine, 11: 390–9, 2003.

15. Ferreira A, Cruz-Correia R, Costa-Pereira A. Securing a web-based epr: An approach to secure a centralized epr withina hospital. In Proceedings of the 6th International Conference on Enterprise Information Systems 2004, 3: 54–9, 2004.

16. Ferreira A, Cruz-Correia R, Luis FA, Oliveira-Palhares E, Marques P, Costa P, Costa-Pereira A. Integrity for electronicpatient record reports. In Proceedings of the 17th IEEE Symposium on Computer-Based Medical Systems 2004, 4–9,2004.

17. Env 12251: Health informatics - secure user identification management and security of authentication by passwords.Technical report, CEN/TC 251.

18. Tls - transport layer security. RFC 2246. Technical report, Internet Engineering Task Force - IETF, Available at:ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt, 1999.

19. Powsner SM, Wyatt JC, Wright P. Opportunities for and challenges of computerisation. Lancet, 352: 1617–22, Nov1998.

11

Table 1 –Type of data and technologies and existence of web interface in the nine initial departmental information systems(DIS) integrated by MAID.

DIS Type of data (examples of clinical reports) Implementationtechnology

Web interface

Anatomo-pathology Exam reports MicrosoftAccess

No

Cardiology ECGs and discharge letters ASP Yes

Clinical Pathology Biochemical results, haematological cell counts andmicrobiologic reports

PHP Yes

Gastrenterology Upper and lower endoscopy reports Delphi NoGynaecology Endoscopy reports Java YesImmunoalergology Pulmonary function tests Delphi NoImmunohemotherapy Coagulation studies, molecular biology reports and

immuno-hematologic results ASP Yes

Intensive Care Discharge letters Java YesPneumology Bronchoscopy reports and discharge letters Java Yes

12

Table 2: Implementation costs of the VEPR system.

Item Description Costs (Euros)

Hardware 240.000DB Cluster 2 x HP Server RP5740 RISC Server Pentium 4 1.8GHz, 768Mb RAM 40Gb Disk Storage HP StorageWorks SAN Backup CSW MSL5000 Dual Magazine All

Software Development 120.000Technicians 1 system administrator, 1 security manager, 1 database

administrator and 2 senior programmers for 12 months

Ancillary software upgrading 30.000WEB services development

Total budget 390.000

13

Table 3 – Monthly mean number of new clinical reports or updates collected by MAID from the three main hospitallaboratories in terms of number of reports generated

Monthly mean number

Department Reports Updates1 Total

Clinical Pathology 14.008 29.843 43.851Immunohemotherapy 5.587 203 5.790Anatomo-pathology 2.297 0 2.2971 These updates correspond mostly to complementary data (e.g. new lab results from the same report) or, in rare occasions,

to corrections of previous reports.

14

VEPR

VIZ

Users

HTTPS/XML

HTTP/XML

HTTPS

DIS A

DIS B

MAID

WebServer

CRep

FileSystem

Database

Explicit Report Request

ListFile

BalancerFile

ListFile

BalancerFile

Express

DIS A

DIS B

Figure 1: General architecture of the Virtual Electronic Patient Record (VEPR) system showing the Multi-Agent system forIntegration of Data (MAID) and the Visualization (VIZ) modules and the Central Repository (CRep). A moredetailed explanation is presented in the text (system development section).

15

0

50

100

150

200

250

300

350

400

450

500

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Hours

Nu

mb

er o

f R

epo

rts

Sunday

Monday

Figure 2 - Mean hourly distribution of reports produced by Clinical Pathology according to two-week days.

16

Figure 3: Visualization module interface showing a 24 hours summary of retrieved reports and a chronological bar with all

past patient events in the VEPR.

17

Figure 4: Visualization module interface showing an example of a requested clinical report.

18

Scenario A

Scenario B

Lab ResultsReport

Delivering Doctor

Doctor

Archiving Report in Medical Record

Medical Record Delivering

Periodically checking for reports availability

AskingAdministrative

RespondingAdministrative

Doctor

Doctor

ReportDelivering

Archiving Report in Medical Record

Medical Record Delivering

Lab Results

Area covered by MAID

Figure 5: The hospital information flow. In scenario A (delivery of reports by producer), a laboratory technician or an

administrative auxiliary when perceiving that the lab results are ready triggers its delivery using another auxiliary to

a third auxiliary who finally distributes this information to the relevant doctor. In scenario B (delivery of reports by

requester), a doctor or an administrative auxiliary on his behalf periodically checks the lab technician or auxiliary

for the readiness of the lab results and when they are finally ready scenario A is triggered.

19