• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
international journal of medical informatics 76 (2007) 190–194
 journal homepage: www.intl.elsevierhealth.com/journals/ijmi
Implementing a new ADT based on the HL7 version 3 RIM
St´ ephane Spahni
a
,
∗
, Christian Lovis
a
, Richard Mercille
b
, Herv´ e Verdel
b
,Michel Cotten
b
, Antoine Geissb¨ uhler
a
a
Medical Informatics Service, Radiology and Medical Informatics Department, University Hospitals of Geneva, 24 rue Micheli-du-Crest,CH-1211 Geneva 14, Switzerland
b
Computing Services, University Hospitals of Geneva, Geneva, Switzerland
a r t i c l e i n f o
 Article history:
Received 29 December 2005Received in revised form20 March 2006Accepted 2 May 2006
Keywords:
Hospital information systems (HIS)ADTHL7Databases migration
a b s t r a c t
The University Hospitals of Geneva (HUG) are the result of the merge of six hospitals intoone single organization. While a true fusion of the management has been effectively done,it was not the case 5 years after for several databases, and in particular the ADT (admission,discharge, transfer). In order to truly realize the fusion, a new ADT service has been builtusingstateofthearttechnologyandstandardsinordertoreplacetheexistingsevenservices.This paper presents the results of the redesign and development of the new ADT service.Thedatamodel,basedonHL7RIM,isdescribedandthetechnologiesselectedarepresented.Finally, a status after 1 year of production is presented.© 2006 Elsevier Ireland Ltd. All rights reserved.
1. Introduction
The administrative system of the HUG was based on two dif-ferent architectures: Diog`ene[1]for the primary care hospitalandPhilos[2]forfiveothersites(psychiatric,geriatricandlongtermcarehospitals).Diog`enewasinplacesincetheseventies,and already went through a migration when the mainframe-basedsystemwasprogressivelyreplacedbyafullydistributedsystem.At the end of the nineties, the six hospitals were mergedto form one single organization—the University Hospitals of Geneva. However, it was not possible to immediately mergethe IT infrastructures—for political as well as technical rea-sons. Each hospital continued therefore to operate its ownADT, with few relations with the others.The deployment of common applications and the need tohave a global view of all information about patients being
∗
Corresponding author
. Tel.: +41 22 372 62 78.E-mail address:Stephane.Spahni@hcuge.ch(S. Spahni).
treated in more than one of the six hospitals[3]introducedthe need for linking the various identities in order to be ableto retrieve all information about one person, wherever he/shewas treated.A master patient index (MPI) was therefore built forstoring links between the various identities of the sameperson in the up to six databases. However, such a solu-tion had its limits and several important points were leftaside:
•
patients still had several active identities, and databasesin each entity stored information associated to the “local”identity;
•
there were often differences between the various identitiesofthesameperson,andchangesmadeononeidentitywerenot reported to the other identities of the same person butin different sites;
1386-5056/$ – see front matter © 2006 Elsevier Ireland Ltd. All rights reserved.doi:10.1016/j.ijmedinf.2006.05.006
 
international journal of medical informatics 76 (2007) 190–194
191
•
the semantic of the trajectory elements was not exactlythe same in all databases, making the job of applicationsdeployed in all institutions harder than necessary.
2. Materials and methods
2.1. Problem to be addressed
The true merge of the databases having failed for severalyears, a completely new ADT has been built in order tofinalize the merge of the institutions in the domain of the administrative patient management and to suppressthe differences in the handling of patients’ identities andtrajectories in the various entities of the HUG. The newapplication, called “SIL” for “Service d’Identification et deLocalisation” fully replaces the existing ones, all existing databeing migrated into the SIL thus merging all trajectories andidentitiesintoonesingledatabasewithasingledatarepresen-tation.
2.2. Constraints
When designing the solution to implement, several con-straints had to be taken into account. The most importantones were:
•
Migration of all existing data into the new system (i.e.almost 30 years of history!).
•
Transparent migration for existing applications: medical aswell as non-medical applications like laboratory systems,managementapplications,etc.Indeed,thenumberofappli-cations accessing the ADT is rather update them on theD-day.
•
The new system should have performances at least at thesame level than the existing ones, without being penalizedby the increased volume of data and the potentially highercomplexity of the model.
•
The new ADT has to be compliant to the JAVA-based archi-tecture being progressively implemented for the new appli-cations.Some additional constraints were also given, in order totake into account the evolution of other elements of theHIS:
•
The administrative management of the patients as wellas the billing system had to be replaced at the sametime the SIL started. Existing data had therefore to bemigrated into two different databases: the SIL for clinic-related data and the DPA (“Dossier Patient Administratif”)for administration-related data. This introduced a strongconstraint in terms of planning, as the two projects had tobe ready at the same time!
•
The migration of the six hospitals towards the new systemfor patient management and billing had to be implementedover several months, enabling a migration site by site inorder to distribute the teaching over time and to limit thenumberofpersonsrequiredforsupportingtheusersduringthe first days of the move.
2.3. Methodology
In order not to loose time reinventing the wheel by designingour own solution for the ADT, we decided to use existingwork done in this area and selected the HL7 ReferenceInformation Model version 1.24 (RIM)[4]. This quite complexinformation model aims in particular at offering a structurefor representing persons, things and organizations as wellas patient encounters, acts, etc. The potential disadvan-tage of this model is that aiming at being as exhaustiveas possible makes it quite complex to grasp: a substan-tial amount of time was therefore required in order tounderstand the reasons behind the choices made in theRIM.In parallel with the study of the RIM ran the task of mak-ing the inventory of the data existing in the various databases(of course not everything is clearly described with its rea-son for being there
. . .
) as well as the list of interfaces madeavailable over the time, sorting out which ones were still inuse and which ones were obsolete. Here, again we were con-fronted with the usual lack of documentation, the existinginterfaces being well described in terms of fields returnedbut the algorithm behind the selection of the entries in thedatabases being often not formalized (e.g. at what time doyou notify planned events like pre-admission or plannedexit?).It was only when both phases were advanced enoughthat it was possible to think at our implementation of theRIM. Indeed the model represents far more than the datamanaged by the ADT: it potentially describes every act con-cerning a patient or performed by an actor as well as themessages exchanged between application modules. Choiceshave therefore been made in order to select the relevantparts of the model and to link the RIM concepts with thelocal concepts—a task necessary for being able to respectthe constraint of transparent migration of existing appli-cations. This resulted in what is called in HL7 a D-MIMor Domain Message Information Model. However, it has tobe noted that our implementation is only using the datamodel of the HL7 standard and not the messaging part itself,although this could be a future extension of our implemen-tation. We therefore did not define our Refined MessageInformationModel—orR-MIM.Severalreasonsmotivatedthisrestriction:
•
Compatibility
: existing applications required compatibleinterfaces, limiting thus the interest of developing alreadyin the initial phase HL7v3 messages.
•
Opportunity
: making a new interface from the beginning isonly useful if there are clients that will use them. How-ever, we already are using HTTP/XML based communica-tion between clinical applications for several years[5], andimplementing true HL7v3 messages would have thereforeonly changed the content of these messages. While sucha change can be highly beneficial during a reorganizationof the way ADT information is accessed and presented tothe users (moving from a backward-compatible view to atrue HL7v3 view), it was postponed for a future phase inorder not to introduce changes at every level at the sametime.
 
192
international journal of medical informatics 76 (2007) 190–194
2.4. Implementation choices
Implementationchoiceshadtobemadeatdifferentlevels:e.g.software environment and components, information model,data model.
2.4.1. Software environment
The software environment was quite well defined for newdevelopments: JAVA/J2EE for programming environment, Bor-land Enterprise Server as application server and Oracle asDBMS. No object-oriented DBMS is currently supported forproduction applications.
2.4.2. Information model
ThechoiceofthecomponentsoftheRIMthathadtobeimple-mented was driven by the data that had to be migrated intothe SIL. As we implemented ADT functions only, we selectedfour basic classes from the model:
•
Entities, covering the notions of persons (patients as well asclinicians, nurses, etc.) and of entities like wards, medicalservices, care units, rooms, etc.
•
Acts, representing admissions, transfers and discharges of patients.
•
Roles played by entities (e.g. a person can be a patient aswell as a clinician).
•
The relations between roles played by entities and acts areimplemented using two additional classes of the model:participationswhichlinkactstoactors(rolesplayedbyenti-ties during a certain time); act relationships representingthe relations between acts (several types of relationshipsdo exist; their use will be discussed later).
3. Results
The project started in spring 2003 with the study of the HL7version 1.24 model and the inventory of existing services.The implementation itself started mid 2003, while the workon the migration of existing data started in autumn 2003. Atoo optimistic planning expected a production phase by mid2004: various factors explained in the discussion delayed theswitch to the new infrastructure for a few months, the trueproduction having started effectively on the 1st of November2004 for the first two hospitals (about 15% of the activity), andon the 2nd of January 2005 for the next two (all four repre-senting at the end more that 95% of the activity and of theusers). The last two small hospitals migrated beginning of March 2005.It has to be noted that due to the fact that several applica-tions – including the Electronic Patient Record – were alreadybasedona“consolidatedview”ofthepatientsoverallsixhos-pitals, most of the clinical users “moved” to the SIL on the 1stof November. This early migration had a severe impact on themigration strategy: indeed this forced us to synchronize thevarious databases – migrated and not migrated – almost inreal time so that every patient stay was accessible from thesystem were is was created as well as from the SIL. A back-ward link had also to be created for reporting new identitiescreatedintheSILintothe“old”systemsinordertomakethemvisible to some specific applications.
3.1. Information model
Fig. 1presents the data model of the SIL version 1. It is effec-tively a subset of the RIM, presenting the data that is beinghandled by the SIL itself. It corresponds basically to the RIMbackbone, with the main structuring classes. The interfacesare not presented in the diagram: they are either proprietary(SOAPinterfaces)orsimplybasedontheclassesofourD-MIM.One can see in this picture from left to right the identitiesof persons (i.e. every person needed to be known) and enti-ties (e.g. ward units, rooms, divisions, etc.), the roles playedat a certain time by these entities, then participations whichprovide the relations between one act and the various actorsimplied (patient, clinician(s), wards, locations, etc.). We arealready planning to integrate non-living objects our D-MIMin order to take into account non-persons (e.g. organs, sub-stances to be analyzed, etc.). These kind of “objects” aremanipulated by laboratories and are often non-living things.Act relationships are used in particular to represent informa-tion migrated from existing systems:
•
Relations between episodes, like the relation between theepisodes of the mother and her baby (the mother’s episodebeing the one during which she gave birth).
•
In the previous system, all ambulatory visits concerningthe same problem were grouped into one episode or “out-patient treatment”: the act relationships enable us to linkall visits (each being an episode) to one “master” episodethat represents the same concept as the former “outpatienttreatment”. While we can find now papers about modelingsuch situations (e.g.[6]), it has to be noted that at the timewe started our work (mid 2003), there was no “white paper”about this subject.
•
Other uses are already planned, like, e.g. for implementingthe notion of “case”. As such extensions of our implemen-tation are not yet designed, an in-depth review of the latestversion of the model as well as of the literature will have tobe made in time.
3.2. Architecture
The software architecture of the services implemented toaccess the SIL data has been partially driven by the needs
Fig. 1 – Subset of the RIM for the SIL project.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...