NE

CIa

b

a

A

R

R

A

K

I

M

H

C

D

1

Hcniwlncaav(

t

T

1d

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424

journa l homepage: www. int l .e lsev ierhea l th .com/ journa ls / i jmi

on-invasive lightweight integration engine for buildingHR from autonomous distributed systems

arlos Angulo ∗, Pere Crespoa, Jose A. Maldonadoa, David Monera, Daniel Perezb,rene Abadb, Jesus Mandingorrab, Montserrat Roblesa

BET Group, Technical University of Valencia, SpainConsorcio Hospital General Universitario de Valencia (CHGUV), Valencia, Spain

r t i c l e i n f o

rticle history:

eceived 8 January 2007

eceived in revised form 2 May 2007

ccepted 8 May 2007

eywords:

a b s t r a c t

In this paper we describe Pangea-LE, a message-oriented lightweight data integration engine

that allows homogeneous and concurrent access to clinical information from disperse and

heterogeneous data sources. The engine extracts the information and passes it to the

requesting client applications in a flexible XML format. The XML response message can

be formatted on demand by appropriate Extensible Stylesheet Language (XSL) transforma-

tions in order to meet the needs of client applications. We also present a real deployment in

a hospital where Pangea-LE collects and generates an XML view of all the available patient

nformation management

edical record systems

ospital information system

linical data integration

clinical information. The information is presented to healthcare professionals in an Elec-

tronic Health Record (EHR) viewer Web application with patient search and EHR browsing

capabilities. Implantation in a real setting has been a success due to the non-invasive nature

of Pangea-LE which respects the existing information systems.

Data integration is the problem of combining data residing

ata exchange

. Introduction

ealthcare is a very data-intensive sector, producing andonsuming a great amount of information. In healthcare orga-izations, especially hospitals, the big amount of data gets

ncreasingly obscure due to their decentralized organizationhich has allowed different departments to meet specific or

ocal requirements. This has led to fragmented and heteroge-eous data resources, so called islands of information, whichontain health data about patients, making the access andggregation of data across systems very difficult. This situ-tion has created a large gap between the potential and actualalue of information contents of Electronic Health Record

EHR) systems.

A classic solution to the problem of information distribu-ion is the acquisition or development of large and centralized

∗ Corresponding author at: Grupo BET, Instituto ITACA, Edificio 8G, Univel.: +34 963877007.

E-mail address: cangulo@fis.upv.es (C. Angulo).386-5056/$ – see front matter © 2007 Elsevier Ireland Ltd. All rights resoi:10.1016/j.ijmedinf.2007.05.002

© 2007 Elsevier Ireland Ltd. All rights reserved.

information system, but past investments in existing IT infras-tructure are not leveraged and departments lose their freedomto select the software that matches their requirements best.Furthermore, the best-of-breed approach can be very suit-able for large organizations, letting departments meet theirown business needs more easily and allowing bigger flexibil-ity within decentralized institutions such as hospitals. Thechallenge is to find how these systems can efficient andmeaningfully exchange health information in such a way thathealth professionals can access to the relevant information atthe point of care, while the data can be held in specializeddepartmental systems or small enterprise systems [1].

ersidad Politecnica de Valencia, Valencia 46022, Spain.

at different sources and providing the user with a unified viewof these data [2]. This unified view may be created from a setof existing data repositories in order to facilitate information

erved.

a l i n

S418 i n t e r n a t i o n a l j o u r n a l o f m e d i c

access through a single information access point, or when acertain information need arises it may be constructed by com-bining different but complementing repositories in order tomeet the need. Data integration can be considered as the basisfor other types of integrations such a functional or presenta-tion [3].

There is a huge body of literature regarding data integrationnot only in the area of computer science but also in biomedi-cal informatics [4–7]. There exist different approaches to dataintegration; broadly speaking they can be divided into three:data warehouses, database federations, and peer-to-peer datamanagement systems.

A data warehouse is a central consolidated physical datarepository. Data from local data sources are extracted, trans-formed and loaded in it. The main backward of this approachis that data are not available in the global repository untilextracted from data sources, which may caused seriousupdate difficulties and can create problems in those queriesthat need to be performed on the latest update. Also, it may bedifficult to create a global schema that encompasses the highvariability and complexity of the data sources.

On the other hand, database federations leave data at thesources and provide querying access to the set of data sourcesthrough a virtual view (schema). Users pose queries on thevirtual view and a query engine is in charge of decomposingand translating the query into an equivalent set of local sub-queries that are executed against the local data sources andwhose results are then combined. The main disadvantages ofthis approach are that data cleansing becomes difficult sinceit must be done on the fly and performance may be degradedbecause it depends on the query capacity of data sources.Nevertheless, it alleviates the temporal problem of data ware-housing since it always facilitates fresh data. The federationmay maintain a common data model and relies on schemamapping for integration of the data source [7], usually sup-ported by wrappers [8], which are specialized programs thatinterface with the sources and hide their technical details.In order to overcome the difficulties that can arise in deal-ing with the heterogeneity of data sources (relational, XML,object oriented, etc.) some systems use a global conceptu-alization model, called mediated schema, for the data fromall integrated databases [4] which describes the domain enti-ties and their relationship. Data sources are mapped to themediated schema by defining the entities they contain. Themediator/wrapper architecture is one of the most commonlyused to achieve data federation. Wiederhold [8] defines a medi-ator as “a software module that exploits encoded knowledgeabout certain set or subset of data to create information for ahigher layer of applications”. A mediator can be considered asa read-only virtual database which is introduced between thedata sources and the application using them. It is capable ofanswering queries about the underlying data, for this purposeit uses data sources (suitable interfaced by a wrapper), and/orother mediator to answer the queries.

Peer-to-peer management systems (PDMS) [9] are an evo-lutionary step in data integration systems. In a PDMS every

data source (peer) needs to only provide a semantic map-ping to either one or a small set of other data sources. Morecomplex relationships emerge when different semantic paths,used by the system to answer queries, are traversed. They

f o r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424

allow the creation of multiple local, specialized mediatedschemas tailored to specific users and then mappings areused to glue together semantically related peers. Therefore,none of the peers must take the responsibility of both creat-ing a maintaining a mediated schema and mapping it to datasources. Therefore, they offer a truly distributed architectureto exchange data.

One of the difficulties in setting up a data integration sys-tem is the definition of the semantic mappings between thesources and the federated virtual schemas. It requires bothdatabase expertise to express them in a formal language anddomain knowledge to understand the meaning of the schemasbeing mapped [10]. Mappings between two schemas can bespecified either procedurally, i.e. by programs that physicallyimport objects stored in the underlying databases into corre-sponding objects of the global environment or declaratively,i.e. by defining a set of correspondences between entitiesfrom the local and global schemas. Procedural mappings allowdealing with a wide range of data source formats and trans-formations, but they are more difficult to maintain becausethe mapping is encoded in actual programs. On the otherhand, declarative mappings are easier to maintain and canaccommodate query optimization but they are less powerfulin specifying complex data transformation.

In the health domain, there exist several examples ofhealth data integration systems. It is prevalent the utiliza-tion of a set of standard messages, mainly HL7 [11], whichare used to exchange data among information system [12,13].A far smaller number of integration efforts have used the fed-eration approach; some of them are ARCHIMED [14], IBHIS [1],Synapses [15] or Synex [16].

At industrial level data integration is known as Enter-prise Information Integration (EII). The main objective of thisindustry is to provide tools to access and query data held byheterogeneous sources without having to first load all the datainto a central warehouse [10]. A related, and more mature,sector is Enterprise Application Integration (EAI). EAI aimsto enable the communication among computer applicationsin order to support workflows. EAI is based on a diversity oftechnologies such as message brokers and adapters. Currentlymajor Database Management System (DBMS) vendors and ITcompanies offer complex and generally quite expensive dataintegration products for the health care sector, mainly mes-sage brokers for HL7.

In this paper we present an overview of the Pangea-LEdata federation system, emphasizing its flexibility and quickdeployment. Briefly, Pangea-LE is a data integration systemthat provides a virtual, integrated and global XML [17] viewover distributed health data sources. Although a materializedsolution is generally more efficient computationally, we pre-fer virtual approach as it does not involve data replication,which may cause data update and synchronization problems,a significant limitation in an EHR application where up-to-dateinformation is needed.

In Pangea-LE, the virtual global view is easily customizablefor different user groups whose needs may change over time.

In an evolving environment as healthcare, the local databasesmay change often. The databases are designed and main-tained to meet local needs and changes are almost madeindependently of the integrated global view. Applications con-

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424 S419

a-LE

nlsd

2

PdItTooawEe

ihpisgost

itP

•

Fig. 1 – Pange

ected to Pangea-LE do not required to be updated after anyocal data source change. These features make the Pangea-LEystem a valuable solution to achieve fast, easy and secureata sharing and integration.

. Materials and methods

angea-LE acts like a mediator [8] between existing healthata repositories and health professionals of an organization.

t allows the definition and management of a global, struc-ured XML view of all the clinical records stored for a patient.his view is presented to health professionals by meansf an EHR Web application. Information views are createdn demand and are role dependant so that enterprise-wideccess roles can be defined for different professional profilesith specific access rights levels corresponding to different

HR views (clinicians, nurse, management, administrative,tc.).

We must stress that the purpose of this concrete use cases only to display EHR views. Information is presented in auman readable way and the clinician must provide his/herarticular interpretation. Nevertheless, it is worthwhile notic-

ng that it is also possible to keep the original meaning ofhared EHR extracts for machine interpretation purposes,uided by some EHR standards. This use case has been testednly for experimental purposes according to the Europeantandard CEN EN13606 [18,19] for the communication of elec-ronic health records.

Pangea-LE can be classified as a generic middleware thatntegrates clinical information. It is important to notice thathere are only a few basic requirements to be met before

angea-LE could be deployed into a healthcare organization:

Unique patient identification throughout all the organiza-tion local information subsystems. In the event of there

architecture.

being none, the organization must provide a method inorder to solve patient identification conflicts.

• Organization-wide user authentication and role assign-ment. This task is commonly executed by means of adirectory service such a Lightweight Directory Access Pro-tocol (LDAP) [20].

Pangea-LE offers read-only views only. Users access thesystem from standard desktop PCs with a Web browser. Secu-rity is implemented by the application server SSL channel viahttps protocol.

Pangea-LE architecture has four basic components (seeFig. 1).

2.1. Wrappers

In the context of data integration a wrapper [21] is a programwhich understands the particular data organization of a datasource. Its main purpose is to encapsulate data sources andoffer a common interface for the extraction of data to theintegration engine. In Pangea-LE heterogeneous data sourceaccess is achieved by using JAVA Database Connectivity (JDBC)drivers and through a set of configuration files, each of themdescribing a data source. The selection of JDBC is due to thepredominance of relational databases in the health care sec-tor. At the time of writing this paper there were 221 differentJDBC drivers available [22] covering the vast majority of rela-tional DBMS. For non-relational data sources and repositorieswithout a data manager such as file systems, ftp, messagingsystems or even web services, corresponding JDBC wrappershave to be built in order to access them in a homogeneous way.

For this purpose, we see data sources as a set of entities andattributes, as they are specialized in some concrete data orga-nization, such as tables and columns in the case of relationaldata sources.

S420 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424

ent

Fig. 2 – EED

2.2. EHR extract definitions (EED)

EHR extract definitions which are used to specify the sharedglobal view. Pangea-LE uses XML as canonical format for pub-lishing and exchanging data, therefore the global view is avirtual XML view and legacy data should be transformed fromthe flat relational format to the hierarchical structure of XML.This is a typical data exchange problem (also known as dataconversion, data translation or data transformation). Dataexchange is the problem of taking data structure under asource schema and creating an instance of a target schemathat reflect the source data as accurately as possible [23]. Dataexchange requires at schema level an explicit representationof how the source and target schemas are related to eachother; these explicit representations are called mappings. InPangea-LE, mappings are defined in an EED.

An EED describes the structure of the XML instances ofthe clinical concepts to be shared in an integration project.It also contains the mapping to data sources, i.e. how theEED entities are related to data source entities. They combinethe extraction part of SQL (FROM and WHERE clauses) withattributes (from data sources) to path mappings (from targetschemas). Mappings are specified as a set of rules that asso-ciate an expression that may involve several columns froma data source to a leaf element of the target document. It ispossible to define complex nested structures by using nested

(correlated) SQL queries.

It is also possible to use more than one data source in anEED, the only restriction being that every FROM clause mustreference tables from a single data source, i.e. every nested

ity sample.

query must use tables from a single database. An EED entity isspecified in an XML file (see Fig. 2) where some fixed descriptorelements define their behavior:

• Elements that specify a valid wrapper configuration foraccessing the necessary information to populate the EEDinstances.

• Elements specifying data to be extracted from the datasource (FROM and WHERE clauses).

• Input parameters accepted by query processor to executefilters on data sources.

• Valid calls (input parameter combinations which areallowed in order to build an EHR extract from an EED).

• Elements specifying data pre-processing which allowssource atomic data to be combined or transformed beforeXML generation.

• Elements that describe the labeling and nesting format thatconstitutes the resulting XML document.

Each EED is a coherent information unit definition wherethe mapping between data source elements and globalschema is established. Each EED can define as many mappingelements as needed to create the coherent and complete pieceof information. Every data source involved in an integrationproject is a potential supporter for a set of clinical concepts,i.e. it may contain the data required to populate their instance,

and therefore several EEDs can be defined for one single datarepository. Each EED can only be shared as a whole. In otherwords, the minimum unit of information that can be sharedthrough Pangea-LE is generated by an EED entity.

i n f o

Wspptflra

2

Egrt(cast

2

Oitvgago

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l

EED entities can be instantiated by a Pangea-LE exposedeb Service (WS) [24]. This WS accepts XML petition mes-

ages pointing to the desirable EED together with the requiredarameters (e.g. patient identification number). When theetition arrives to Pangea-LE and it is checked as a valid call,he Query Processing Module (see Fig. 1) generates on they the SQL statements that are required to build the XMLesponse. The extracted data is then structured and labeledccording to the rules defined in the EED.

.3. XSLT transformations

ach EED can specify one or more Extensible Stylesheet Lan-uage (XSL) transformation files to be applied to the XMLesponse message. This method allows Pangea-LE to adapthe output to different application message formats or devicesPDAs, Tablet PCs, etc.). Moreover, the same clinical entityan be formatted in different styles according to specific userccess roles. Transformations can be applied on the serveride or alternatively in the client application if it is allowedo perform this task.

.4. EHR browsing trees

ne of the most remarkable Pangea-LE features is the abil-ty to organize the retrieved clinical information in a flexibleree structure. Once information has been extracted, differentiews can be configured: chronologically, data origin (emer-

encies, outpatient consultation, radiology . . .), etc. EHR treesre also defined in XML documents (see Fig. 3). They bothuide the extraction process of the clinical data associated tone patient and specify how to structure, organize, aggregate

Fig. 3 – EHR tree definition sample and res

r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424 S421

and summarize data. At run time, each EHR tree constitutes ahealth record view for a particular role and it is mainly built byusing EED entities. When a user wishes to access to the clinicaldata of a patient, the module that interprets EHR trees firstlyretrieves only the minimum information needed to shape asummarized view of the patient’s healthcare record. Subse-quently, users can interact with each particular tree node toget a more detailed view of the particular clinical conceptdescribed by the corresponding EED entity. All these possi-ble interactions are defined and controlled by EHR trees. Eachstructural component of the EHR tree data model correspondsto nodes in the visual tree control used in the EHR viewer appli-cation. Tree nodes are user interactive, therefore EHR viewscan be built interactively and on demand. A text and an iconcan be assigned to nodes; furthermore they can be visibleor invisible. Currently, three different types of nodes can bedefined in an EHR tree: container, fixed and summary.

• Container nodes are the main EHR tree components sincethey define how to obtain the data to populate the EHR view.They are associated with an EED entity. In runtime, they willhave a child for every EED instance generated.

• Fixed nodes are nodes that are not attached to an EED entitybut they can have children nodes of any type. Their purposeis to customize the EHR tree structure.

• Summary nodes can collect EED instances from any num-ber of container nodes and show them in the tree as childnodes. Summary nodes are very useful when different data

sources are needed to be integrated as a single one, allow-ing a virtual union of sources. For instance, different types ofdischarge reports, held by different data sources, can coexistin the same organization. We can define an invisible con-

ult tree for EHR Number = 0 instance.

a l i n f o r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424

Table 1 – Distribution of requests per data source

Data source %

Laboratory 30.00Pathological anatomy 11.30Ambulatory consults 11.30Emergencies 10.60Admission 9.40Clinical reports 9.40Magnetic resonance reports 9.00

S422 i n t e r n a t i o n a l j o u r n a l o f m e d i c

tainer node for each type of discharge report and collecttheir instances by using a summary node. Thus, the EHR treeview will have a single node that contains all the dischargereports.

EHR tree definitions guide the EHR viewer appearance.Therefore, they may be used to define customized EHR viewsfor different user groups or roles. Fig. 3 shows a simple exam-ple. The main structural item in an EHR tree definition is theHCE node element. HCE node specifies the node appearancein the resulting tree by defining its text content, type, iconand visibility. Content element defines the data to be showed.Two elements are nested inside of it. The LIST NODES speci-fies the EED name (in the example surgicalprocedures list) andthe parameters that must be used to obtain the list of “user-friendly” instance identifiers, in the example the list of surgicalprocedure dates. List nodes are automatically executed whena user accesses to the EHR of a patient. This allows us to givethe user a complete summary of the EHR. On the other hand,the DETAIL NODE element stipulates the EED (in the examplesurgicalprocedures detail) and the parameters that must beused to obtain a single full instance. Note that the parameterreport number is bound to the report number value which waspreviously extracted by the instantiation of the surgicalproce-dures list EED.

3. Results

Pangea-LE has been deployed in the Consorcio Hospital Gen-eral Universitario de Valencia (CHGUV). CHGUV is a mediumsized hospital serving a population of 350,000 inhabitants with592 beds, 21 operating rooms and 470 physicians. The deploy-ment process started at the end of 2004, since then the systemhas evolved from a prototype to a full operational systemwhich currently serves the whole hospital.

In order to close the design-reality gap [25] a multidisci-plinary work team has been created to make the integrationproject a success. The team is composed of representativespecialists form clinical, management, documentation andcomputing departments. The team is in charge of the coor-dination of resources, planning and priorities selection. Thedeployment process itself has been progressive and stronglycoordinated. Integration has been guided by the documen-tation and computing departments. The former is in chargeof designing EHR trees and validation of data sources whilethe latter supplies the data source access parameters andschemata in order to build EED entities. Once a data sourceis selected to be integrated one or more EED must be createdto extract data from that source. When the EED is ready, theappropriate transformations are implemented and tested tooffer a suitable data presentation for human readable report.Finally, the relevant EHR trees are updated to include the newEED.

The most important departmental systems were the firstto be integrated (admission, emergencies, outpatient con-

sultations agendas, pathological anatomy and a wide rangeof discharge reports). Currently, the vast majority of patienthealth data is available electronically through Pangea-LE,including: alerts, emergencies, inpatient episodes, outpatient

Endoscopy 2.10Other sources 6.80

consultations, laboratory results, biopsy and cytology testresults, magnetic resonance reports, mammographies, endo-scopies and most of the discharge reports from specialty units.At present, more than twenty local systems have been inte-grated and 36 EED have been defined. Table 1 shows thedistribution of requests per data source.

Easy access, completeness and immediate informationretrieval have made EHR viewer application rapidly extendorganization-wide, which is, in fact, the major evidence of theproject’s success. In order to gain precise knowledge of theactual use of Pangea-LE we have analysed the system log toget statistical data about the use of the EHR viewer. At thetime of performing the analysis, late 2006 (2 year after deploy-ment), the number of potential medical users is 970, 470 ofthem being medical practitioner and 500 nursing staff. Thenumber of regular users is 750 (approximately 75% of poten-tial users) and nearly 300 of them use the EHR viewer daily.The system serves on average approximately 13,000 EHR permonth and more than 80% of the activity is concentrated inthe range from 9:00 a.m. to 5:00 p.m. A detailed analysis of dis-tribution of EHR petitions per data source and day of the weekshows an anomaly on Sundays because the emergency activityis much higher than on the other days. All this clearly reflectsthat Pangea-LE is mainly used for everyday care delivery anddemonstrates that the EHR viewer has become an importanttool in the doctor’s office.

Two evaluations have been carried out over the last 2 years.For this purpose a questionnaire was designed and sent to aselected representative user group (100 health professionalsfrom diverse hospital units) to assess their opinion, confirmthe former results and detect any weakness or deficiency. Thefirst one, which was handed out 3 months after installation,was especially focused on information priorities in order todetermine which data sources should be integrated first. Thesecond one was completed 2 years after initial deployment.The main topics and results of the second evaluation were:

• Information availability: Questions to detect information thatis needed by clinicians but not available in the EHR viewerapplication. 53% of users feel that not all informationneeded is available. This mainly refers to information heldby external systems (91%). On the other hand, 88.2% of usersfind the information that they are searching for easily.

• User satisfaction: Questions about system performance andfaults, if detected. System speed was evaluated on a (0–9)scale (the higher the better), the mean being 6.48.

i n f o

•

4

Wbotdoai

bhdlemibgtPa

cstctdttiamapiaci

btsTitctiio

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l

Added value: Questions about benefits for patients due to theuse of the EHR viewer were also presented on the (0–9) scale.Patient benefit received a score of 8.26 while the advan-tages compared to paper-based records achieved a scoreof 7.05.

. Discussion

e introduced Pangea-LE, a light data integration engineased on free software components. The system is in the linef the virtual approach and read-only view systems, i.e. sys-ems that support read-only views of data held by multipleatabases [26]. Our solution is based on the definition of a setf data aggregates, each of them defining a clinical concept,nd mapping them with the heterogeneous structures foundn the autonomous information systems.

There are tools that address the data transformationetween different data schemas. Although these tools canelp us to define mappings, for example between a relationalata source and a target XML Schema, they usually show a

ack of flexibility. Thus, we can use them to design a particularxtraction and transformation algorithm (an XSLT transfor-ation, an XQuery or some particular source code) to embed

t in our own software but it is not a generic code which cane used for data integration and querying. If the source or tar-et schema changes, we would be forced to regenerate theransformation algorithm and modify our application by hand.angea-LE resolves these cases by means of the edition of theffected EED (a single XML document).

Pangea-LE allows a non-invasive integration mechanism,ompletely respectful of the already existing autonomous sub-ystems of a health organization with a very specific purpose:o define secure, global and unified views, organized by flexibleriteria, over all EHR dispersed among the manifold subsys-ems of a healthcare organization. Nevertheless, due to itsesign, it is capable of evolving towards more advanced func-ionalities such as clinical research support and as a helpingool in extract, transform and load (ETL) processes requiredn clinical or economical research. Pangea-LE may ease thelways laborious load stage of data warehouses and dataarts. The strongest feature of the system is its high flexibility

nd scalability: flexibility to specify multiple formats for theresentation, to structure health data according to normal-

zed formats to communicate EHR (HL7-CDA or EN13606), etc.nd to organize the clinical history view according to differentriteria; scalability to deploy the engine for inter-institutionalnteroperation.

Experience in a real setting has been shown. Pangea-LE haseen in routine use for the last 2 years in the CHGUV, becominghe most important computer system for the medical profes-ional who has to access patients’ electronic health records.he deployment has demonstrated its flexibility and scalabil-

ty. The system has allowed fast EHR integration throughouthe whole organization. A key factor for the project’s suc-ess has been the creation of a multidisciplinary working

eam involving medical, administrative and IT professionalsn charge of coordinating the system deployment. The partic-pation of clinical professionals has allowed rapid detectionf requirements and failures, which has brought about the

r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424 S423

possibility of adapting the system to meet the needs of theorganization.

Pangea-LE is not only helping in the delivery of healthcarebut also in administrative tasks such as diagnosis codificationusing ICD-9. The admission department performs this task byprocessing discharge reports and any other relevant informa-tion. The EHR viewer has emerged as a key application becauseit eases the codification process by allowing codifiers to haveimmediate access to all the relevant information. Moreover,the demand on the hospital’s archive of paper-based healthrecords has been reduced significantly.

Interesting results were deduced from the questionnaire:in spite of the great amount of information available alarge number of health professionals expressed the needto access information from data sources external to thehospital (mainly speciality outpatient centres). Users havefound it easy to use the EHR viewer, which has fosteredits rapid deployment throughout the hospital. Also, patientbenefits were explicitly expressed, such as timesaving orthe decrease of redundant diagnostic procedures. The mostsignificant use of the EHR viewer occurs during patientencounters when doctors and nursing staff can have quick andcomplete access to information about past encounters andexaminations.

The facility of use and a very intuitive graphic interfacehas made the EHR viewer a key application in the Hospital.The integration project has produced a very positive symbiosisbetween all participating parts. Even so, we have found somelimitations in Pangea-LE:

• There is no terminology service available to map informa-tion to a shared knowledge source.

• Asynchronous data retrieval service is not supported. Thiswould be a useful feature for clinicians who could be alerted,for instance, when a test result becomes available.

• System configuration files (EED, EHR Tree definitions, log-gers, etc.) must be defined manually.

Prospects:

• Pangea-LE infrastructure can be a useful tool in the extract,transform and load process of data warehousing.

• A visual management module is being developed in orderto ease EED and EHR tree definition.

• A specific audit log viewer is also being developed so thata trace can be performed for a specific user or a specificpatient.

5. Conclusions

In this paper we have presented Pangea-LE, a data inte-gration system. Pangea-LE allows a non-invasive integrationmechanism, completely respectful of the already existingautonomous subsystems of a health organization with a veryspecific purpose: to define secure, global and unified views,

organized by flexible criteria, over all EHRs dispersed amongthe manifold subsystems of a healthcare institution. Never-theless, due to its design, it is able to evolve towards theadvanced functions described in Section 4 of this paper. But

a l i n

r

S424 i n t e r n a t i o n a l j o u r n a l o f m e d i c

without a doubt the strongest feature of the system is its highflexibility and scalability: flexibility to specify multiple formatsfor the presentation of information, to structure the healthdata according to normalized formats to communicate EHRs(HL7 or EN13606), etc. and to organize the clinical history viewaccording to different criteria; scalability to deploy the enginefor inter-institutional interoperation.

Pangea-LE is highly flexible, fully scalable, with almost nopreliminary requirements, and allows fast EHR deploymentthroughout an organization. Our experience in CHGUV hasshown that the full specification of an integration project canbe performed in just a few weeks. In fact, the main part of itwas completed in a matter of a few days.

Acknowledgements

This work was partially funded by the Spanish Ministry ofScience and Technology (MEC-TSI2004-06475-102-01) and theSpanish Ministry of Health (PI052245).

e f e r e n c e s

[1] M. Rigby, D. Budgen, M. Turner, I. Kotsiopoulos, P. Brereton, J.Keane, K. Bennett, M. Russell, P. Layzell, F. Zhu, Adata-gathering broker as a future orientated approach tosupporting EPR users, Int. J. Med. Inf. 76 (2/3) (2007)137–144.

[2] M. Lenzerini, Data integration: a theoretical perspective, in:Proceedings of the 21st ACM SIGACT-SIGMOND-SIGARTSymposium on Principles of Database Systems, 2002, pp.233–246.

[3] R. Lenz, M. Beyer, K.A. Kuhn, Semantic integration inhealthcare networks, Int. J. Med. Inf. 76 (2/3) (2007) 201–207.

[4] R. Alonso-Calvo, V. Maojo, H. Billhardt, F. Martın-Sanchez, M.Garcıa-Remsal, D. Perez-Rey, An agent- and ontology-basedsystem for integrating public gene, protein, and diseasedatabases, J. Biomed. Inf. 40 (1) (2006) 17–29.

[5] K.A. Karasavvas, R. Baldock, A. Burger, Bioinformaticsintegration and agent technology, J. Biomed. Inf. 36 (3) (2004)205–219.

[6] W. Sujansky, Heterogeneous database integration inbiomedicine, J. Biomed. Inf. 34 (4) (2001) 285–298.

[7] B.B. Louie, P. Mork, F. Martin-Sanchez, A. Halevy, P.Aarczy-Hornoch, Data integration and genomic medicine, J.Biomed. Inf. 40 (1) (2007) 5–16.

[8] G. Wiederhold, Mediators in the architecture of future

information systems, Computer 25 (3) (1992) 38–49.

[9] S. Gribble, A. Halevy, Z. Ives, M. Rodrig, D. Suciu, What candatabases do for peer-to-peer? in: Proceedings of the FourthInternational Workshop on the Web and Databases WebDB,2001, pp. 31–36.

f o r m a t i c s 7 6 S ( 2 0 0 7 ) S417–S424

[10] A. Halevy, A. Rajaraman, J. Ordille, Data integration: theteenage years, in: Proceedings of the 32nd InternationalConference on Very Large Data Bases, 2006, pp. 6–16.

[11] Health Level Seven (HL7), http://www.hl7.org (last visitedDecember 2006).

[12] K.U. Heitmann, R. Schwiger, J. Dudeck, Discharge andreferral data exchange using global standards-the SCIPHOXproject in Germany Int. J. Med. Inf. 70 (2/3) (2003) 195–203.

[13] Y. Sooyoung, K. Boyoung, P. Heekyong, C. Jinwook, C.Jonghoon, Design and implementation of HL7 basedreal-time clinical data integration system, in: Proceedings ofthe International Conference on Mathematics andEngineering Techniques in Medicine and Biological SciencesMETMBS ’03, 2003, pp. 222–230.

[14] G. Thurler, F. Borst, C. Breant, D. Campi, J. Jenc, B.Lehner-Godinho, P. Maricot, J.R. Scherrer, ARCHIMED: Anetwork of integrated information systems, Methods Inf.Med. 39 (1) (2000) 36–43.

[15] W. Grimson, D. Berry, J. Grimson, G. Stephens, E. Felton, P.Given, R. O’Moore, Federated healthcare record server-theSynapses paradigm, Int. J. Med. Inf. 52 (1–3) (1998) 3–27.

[16] Y. Xu, D. Sauquet, P. Degoulet, M.C. Jaulent,Component-based mediation services for the integration ofmedical applications, Artif. Intell. Med. 27 (3) (2003) 283–304.

[17] World Wide Web Consortium, XML, http://www.w3.org/XML(last visited December 2006).

[18] J.A. Maldonado, M. Robles, P. Crespo, Integration ofdistributed healthcare records: publishing legacy data asXML documents compliant with CEN/TC251 ENV13606, in:Proceedings of the 16th IEEE Symposium on ComputerBased Medical Systems, IEEE Computer Society Press, 2003,pp. 213–218.

[19] European Committee for Standardization, Healthinformatics—electronic health record communication. Part1: Reference model, Draft European Standard for CENEnquiry prEN13606-1, 2006.

[20] LDAP RFC, http://www.ietf.org/rfc/rfc2251.txt (last visitedDecember 2006).

[21] M.T. Roth, P.M. Schwarz, Don’t scrap it, wrap it! A wrapperarchitecture for legacy data sources, in: Proceedings of 23rdInternational Conference on Very Large Database Systems,1997, pp. 266–275.

[22] JDBC Data Access API,http://developers.sun.com/product/jdbc/drivers (last visitedDecember 2006).

[23] R. Fagin, P.G. Kolaitis, R.J. Miller, L. Popa, Data exchange:semantics and query answering, in: Proceedings of theNinth International Conference on Database Theory, 2003,pp. 207–224.

[24] World Wide Web Consortium, Web Services:http://www.w3.org/2002/ws (last visited December 2006).

[25] R. Heeks, Health information systems: Failure, success andimprovisation, Int. J. Med. Inf. 75 (2006) 125–137.

[26] R. Hull, Managing semantic heterogeneity in Databases: atheoretical perspective, in: Proceedings of the ACM PODS,1997, pp. 51–61.