A PROTOCOL FOR DYNAMICALLY MAINTAINING AN

INTEGRATED MEDICAL RECORD DATABASE FROM A SET OF

DIFFERENT MEDICAL RECORD DATABASES

Emilio Hern´andez and Mireya Morales

Department of Computing, Sim´on Bol´ıvar University, Caracas, Venezuela

Keywords:

Health information systems, Medical record databases, Interoperability.

Abstract:

Merging distributed medical record databases into an integrated database is an alternative approach for the

implementation of the uniﬁed medical record concept. One of the main advantages of this approach is that

the integrated database could be a backup for medical record databases. Additionally, the integrated database

may be useful for medical research and may help improve the decisions on public policies related to health

care. We propose a protocol for dynamically maintaining an integrated database that is the merge of different

medical record databases, under some limitations related to security and control of the medical record.

1 INTRODUCTION

Hospital Information Systems are usually imple-

mented as client-server or web applications (Morrison

et al., 2010). These applications are suitable as a so-

lution for single administrative domains. A National

Health Service face the problem of fragmentation of

the health-related information among many Hospital

Information Systems. Fragmentation leads to lack of

coordination, information inconsistencies and many

other problems that make it difﬁcult to deﬁne appro-

priate public policies. In addition, information inte-

gration is one of the keys for the improvement of the

consumers health care experience.

Interoperability has been pointed out as a key for

the success of a national or regional Health Informa-

tion Service (Brailer, 2005; Walker et al., 2005). The

efforts have mainly been focused on the deﬁnition of

information exchange standards (HL7, 2010; ANSI,

2010). It is frequently assumed that cooperating data

sources exchange information horizontally, probably

with the help of data discovery services (Zhang and

W. Xu, 2007). There are also some proposals that

additionally consider the semantic level for data asso-

ciation (Lopez and Blobel, 2009; Hovenga, 2008).

We propose a speciﬁc scheme for interoperabil-

ity, based on the integration of databases into a sin-

gle medical record database, with replication of the

information. This approach needs the deﬁnition of a

data exchange protocol that ensures some control on

the replicated information, in order to avoid inconsis-

tencies and provide reasonable security. This inter-

operability scheme resembles a memory hierarchy in

which an upper level integrates the databases of sev-

eral institutions. In the context of a country, for exam-

ple, the number of integrated databases could be much

lower than the number of health centre databases (in

fact, there could be a single integrated database). At

this integration level the horizontal interoperability

between large database systems becomes easier be-

cause there is a lower number of databases and fewer

data formats.

Along with the memory hierarchy scheme, we

propose a protocol for dynamically maintaining a

medical record database that is actually the merge of

different medical record databases, under some limi-

tations related to security and control of the medical

record ”ownership”.

In this paper we describe the proposed interop-

erability scheme and the associated synchronization

protocols. Section 2 presents the components of the

interoperability scheme, section 3 describes the pro-

tocols and section 5 shows the conclusions.

2 HEALTH INFORMATION

SYSTEMS AS MEMORY

HIERARCHIES

At the heart of a Health Information System is the

medical record database. In our model, this database

592

Hernández E. and Morales M..

A PROTOCOL FOR DYNAMICALLY MAINTAINING AN INTEGRATED MEDICAL RECORD DATABASE FROM A SET OF DIFFERENT MEDICAL

RECORD DATABASES.

DOI: 10.5220/0003173705920595

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2011), pages 592-595

ISBN: 978-989-8425-34-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

is deﬁned as the union of the databases located at the

Local DB Level (Local Database Level). These lo-

cal databases can be deployed, for example, at the

computer departments of large hospitals. The local

databases are integrated in a single database at the

Integrated DB Level (Integrated Database Level) by

providing a copy of each medical record, probably ac-

cording to strict security policies. The database of the

Integrated DB Level could be, in turn, a distributed

database with the possibility of offering a single view.

In this sense the whole system resembles a mem-

ory hierarchy. The main difference with a computer

memory hierarchy would be that the control of the

original version is not at the upper level. Local DB

Servers have the ”ownership” of the medical records,

in such a way that they could even decide whether to

prevent some medical records from being uploaded to

the integrated database.

We deﬁne three levels in which synchronization

software must be implemented for moving data up-

wards and backwards in the memory hierarchy. These

levels are:

• Access Level. Basically the access level is com-

posed of the end-user systems that allow medi-

cal staff to interact with the system, as well as

monitoring systems that send patient information

from home or from mobile devices. If the com-

puters at the Access Level can work standalone

during some periods of connectivity failure, data

collected locally must be synchronized later with

the Local DB Level.

• Local DB Level. This level is composed of the

basic data centres where the data are actually

stored. The combination of the Access Level and

Local DB Level basically conforms to a client-

server model with fault tolerance features. Lo-

cal DB Servers may be located within the health

centres, if they have the capacity for administer-

ing a small data centre. The data formats or the

client-server software used by different Local DB

Servers may vary from site to site.

• Integrated DB Level. This level contains, as a

basic unit, a database with the information of sev-

eral Local DB Servers. Local DB Servers must

periodically synchronize their databases with the

Integrated DB Level, using a synchronization pro-

tocol that performs data format transformations if

necessary. Several Integrated DB Servers may in-

teroperate under a secure platform, for instance a

Grid Platform (Foster and Kesselman, 1999), if a

higher degree of integration has to be achieved.

Between the health centres at the Access Level

and the Local DB Level the data will usually ﬂow

through an on-line web application. Between the Lo-

cal DB Level and the Integrated DB Level the data

will ﬂow through synchronization protocols.

We are not deﬁning interoperability protocols be-

tween Local DB Servers. This means that if a patient

must be attended at a health centre far from home,

the assigned Local DB Server must obtain the infor-

mation related to the patient (i.e. the medical record)

from the Integrated DB Level.

The Access Level includes all systems related to

home or mobile monitoring of outpatients. In this

case, the Local DB Level must provide the services

for receiving data from the devices that collect the

monitoring information.

3 THE SYNCHRONIZATION

PROTOCOLS

In this section we describe the protocol for dynami-

cally maintaining the medical record database of the

Integrated DB Level by merging different medical

record databases at the Local DB Level. Such a pro-

tocol needs to be deﬁned and executed under some

limitations related to security and control of the med-

ical record ”ownership”.

In the proposed protocol there are only two al-

lowed operations.

1. Synchronization of a Local DB Server with the

Integrated DB Server.

2. Query of a single medical record to the Integrated

DB from the Local DB Server. This query should

be used only in those cases in which a patient is

attended at a health centre located away from that

in which he/she is registered, for instance, during

an emergency.

3.1 Synchronization Protocol

The database synchronization protocol is inspired by

well known ﬁle synchronization protocols. In our

case, the protocol synchronizes records rather than

ﬁles.

The synchronization protocol, depicted in Fig-

ure 1, works under the following conditions:

• Patients must be identiﬁed according to universal

identity keys. This restriction may prevent the im-

plementation of an Integrated DB Level beyond

the limits of a single country or region.

• The patients must be registered just in one Local

DB Server. Conﬂicts between different versions

of a patient’s medical record could be solved with

the assistance of authorized users.

A PROTOCOL FOR DYNAMICALLY MAINTAINING AN INTEGRATED MEDICAL RECORD DATABASE FROM

A SET OF DIFFERENT MEDICAL RECORD DATABASES

593

Receive keys of local records

records

changed since last sync

Select local records that Check backup records by received

keys and select those that changed

since last sync

Send the keys of all local

Messages

backup copy was preferred

and conflicting records whose

that do not have conflicts

local copy was preferred

and conflicting records whose

Send changed local records

by the authorized user

with received records

from Local DB Server

Receive modified records

Ask authorized user

Send backup records that changed

since last sync

Receive backup records

with backup records

Update local database

about conflicts, if any

LOCAL DB SERVER INTEGRATED DB SERVER

Update integrated database

from Integrated DB Server

that do not have conflicts

Figure 1: Synchronization protocol between a Local DB Server and the Integrated DB Server.

• The medical record is stored in the Local DB

Server. The copy of the medical record at the In-

tegrated DB Server is considered a backup.

• Different Local DB Servers may potentially have

different DB formats.

• The Integrated DB records should be designed

with an inclusive criteria, i.e. ideally they must

contain all of the ﬁelds that could be present in

any of the Local DB records.

A key consideration for the protocol implementa-

tion is that it needs a database subsystem that keeps

track of the record versions. Every time that a medi-

cal record is modiﬁed, an associated version number

ﬁeld must be increased. Fortunately this requirement

can be easily implemented with the help of triggers,

which most Database Management Systems offer. A

separate table indexed by the medical record key may

contain the version number ﬁeld and can be added

to both the Local DB Server and the Integrated DB

Server. A trigger must increases the version number

on every record update.

The synchronization protocol is periodically

launched by the Local DB Server. It starts by send-

ing the keys of the patients locally registered to the

Integrated DB Server. Only these records are going

to be synchronized with the Local DB Server. Once

both parts ﬁnd out which of these medical records

have new versions, they proceed to the information

exchange. If a medical record has new versions in

both sides (probably because the patient was attended

in more than one Health Centre within a short period

of time), an authorized user must decide what infor-

mation should be stored in both the Local DB Server

and the Integrated DB Server.

3.2 Querying the Integrated DB Level

If a patient is attended in the health centre where

he/she is registered, the medical record is available lo-

cally and there is no need to query the Integrated DB

Server. This query is needed if the patient is attended

in a health centre whose Local DB Server is differ-

ent from that in which he/she is registered. This may

happen, for instance, in an emergency far from home.

The query from a Local DB Server to the Integrated

DB must meet the data acces policies deﬁned for the

Health Information System. The medical record is

downloaded and a temporal medical record is cre-

ated in the Local DB while the patient is attended.

This record may be modiﬁed in the Local DB. Dur-

ing the next synchronization of this Local DB Server,

HEALTHINF 2011 - International Conference on Health Informatics

594

the modiﬁed temporal record is uploaded to the In-

tegrated DB Server and deleted from the Local DB.

Later on, the new version of the medical record will

be downloaded from the Integrated DB to the Local

DB where the patient is registered, keeping a copy at

the Integrated DB Level.

4 IMPLEMENTATION

The synchronization protocol must be implemented

for each Hospital Information Systems, because they

may have different Database Management Systems,

of different database deﬁnitions. An analysis at the

semantic level must be carried out in order to deﬁne

table and ﬁeld mappings between the Local DB and

the Integrated DB. The implementation of the syn-

chronization protocol must include the version track-

ing subsystem described in section 3.1. The synchro-

nizer itself follows a client-server model in which

both parts must authenticate each other, for instance

by means of digital certiﬁcates.

In practice, the execution of a the synchronization

protocol with several Local DB Servers could unveils

the presence of many medical records for the same pa-

tient, loaded from different health centres. Once the

patients are assigned their Local DB Servers, multiple

medical records associated to them should progres-

sively be removed. However, in principle, the risk of

having duplicate medical records for the same patient

is independent of the interoperability approach.

4.1 Prototype

As a proof of concept, a prototype of a Hospital Infor-

mation System and a Synchronization Tool have been

developed. The Medical Record and Interconsultation

subsystems are tightly coupled. The interconsultation

subsystem does not work at real-time. It is a store-

and-forward telemedicine subsystem that allows aux-

iliary physicians in remote health centres to make in-

terconsultations with other physicians or medical spe-

cialists, usually located in large hospitals. A database

synchronizer is provided, developed with an ad hoc

data exchange protocol. However, other database syn-

chronizers could be developed following a standars

data exchange protocol such as HL7 (HL7, 2010).

5 CONCLUSIONS

In this article we describe an interoperability scheme

for Health Information Systems, based on the inte-

gration of databases into a single database. The data

is actually replicated in the integrated database. This

approach needs the deﬁnition of data exchange proto-

cols that ensure the control on the replicated informa-

tion, in order to avoid inconsistencies and provide rea-

sonable security. This interoperability scheme resem-

bles a memory hierarchy in which an upper level inte-

grates the databases of several local database servers.

An integrated database centre located at the top

level of the memory hierarchy will serve as backup

level for local data centres. Additionally, this upper

level will provide the services needed for policy mak-

ing at the health authority level, and will be used for

building data sets for scientiﬁc research.

REFERENCES

ANSI (2010). The ANSI ASC X12. http://www.x12.org/,

accessed on July 2010.

Brailer, D. J. (2005). Interoperability: The key to the future

health care system. Health Affairs, 10(1377).

Foster, I. and Kesselman, C. (1999). The Grid: Blueprint

for a New Computing Infrastructure, chapter Compu-

tational Grids, pages 15–51. Morgan Kaufmann Pub-

lishers, Inc.

HL7 (2010). Health Level Seven. http://www.hl7.org/, ac-

cessed on July 2010.

Hovenga, E. (2008). Importance of achieving semantic in-

teroperability for national health information systems.

Texto & Contexto Enfermagem, 17(1):158–167.

Lopez, D. M. and Blobel, B. G. (2009). A development

framework for semantically interoperable health in-

formation systems. International Journal of Medical

Informatics, 78(2):83–103.

Morrison, C., Iosif, A., and Danka, M. (2010). Report

on existing open-source electronic medical records.

Technical Report UCAM-CL-TR-768, University of

Cambridge, Computer Laboratory.

Walker, J., Pan, E., Johnston, D., Adler-Milstein, J., Bates,

D. W., and Middleton, B. (2005). The value of

health care information exchange and interoperability.

Health Affairs, 10(1377).

Zhang, J. and W. Xu, D. E. (2007). System interoperabil-

ity study for healthcare information system with web

services. Journal of Computer Science, 3(7):515–522.

A PROTOCOL FOR DYNAMICALLY MAINTAINING AN INTEGRATED MEDICAL RECORD DATABASE FROM

A SET OF DIFFERENT MEDICAL RECORD DATABASES

595