Open laboratory information systems: a casestudy

H. E. SOLBERG & J. G. GLEDITSCH

Department of Clinical Chemistry, Rikshospitalet, Oslo, Norway

Solberg HE, Gleditsch JG. Open laboratory information systems: a case study.Scand J Clin Lab Invest 1999; 59: 33^46.

The EU-AIM project ``OpenLabs'' speci¢ed an open systems architecture for aclinical laboratory information system (LIS) environment and coined the term``open LIS''. Since this conception has not yet been realized into systems and mod-ules commercially available, two university hospitals in Norway had to specify analternative model for openness when they, in a joint project, screened the marketfor a new LIS. To be open, a LIS must be (1) based on main-trend hardware andsystem software running under a standardized operating system, (2) designed fornetwork-based distributed computing, (3) have su¤cient documentation availableto local sta¡, (4) be con¢gurable through parameters, tables and scripts, and (5)have general and con¢gurable access mechanisms both to real-time processes andto the database. The present study describes the selection process and examinesthe compliance of the selected LIS (NetLab) with this model of openness. It isshown that local sta¡ have been able to adapt this LIS to various and changingrequirements in the laboratory.

Key words: Customization; interface; laboratory information system (LIS);NetLab; OpenLabs; openness; work£ow management

Helge Erik Solberg, Department of Clinical Chemistry, Rikshospitalet, N-0027Oslo, Norway. E-mail: h.e.solberg@labmed.uio.no

<

1Abbreviations.öAPI~Application Programming Interface. Speci¢ed set of functions, messages, data, para-meters, etc., that makes inter-operability between IT systems possible. EU-AIM~A research programme of theEuropean Union: ``Advanced Informaticsin Medicine''. EXIM~NetLab's con¢gurable EXport and IMport inter-face. IT~InformationTechnology. LIS~Laboratory Information System. NetLab~The LIS selected and installedin the NLS project. NetLab is the basis for the present case study. NLS~The project ``New Laboratory System''(1993 ^ 1997) at Rikshospitalet (Oslo, Norway) and Haukeland Sykehus (Bergen, Norway) [4]. NPL~NetLab Pro-gram Language. ODBC~Open Data Base Connectivity. A Microsoft API standard for accessing databases.OLIC~On-Line Instrument Connection. Network-based system for connecting analytical instruments on-line toNetLab. OpenLabs~The EU-AIM project A2028 ``OpenLabs''(Applications of Advanced Informatics and Tele-matics for Optimization of Clinical Laboratory Services) [1, 2]. SQL~Structured Query Language. Used for hand-ling relational databases.

Scand J Clin Lab Invest 1999; 59: 33 ^ 46

33

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

1 INTRODUCTION

The aim of the present study is to compare acommercially available laboratory informationsystem (LIS) with an ``open'' LIS as conceivedby the EU-AIM OpenLabs project (A2028)[1, 2].

1.1 The NLS project

In 1994, two university hospitals in NorwayöRikshospitalet (Oslo) and Haukeland sykehus(Bergen)öestablished the joint project ``NewLaboratory System'' (NLS) to select, acquireand introduce a new LIS, which was to ful¢l, asclosely as possible, the OpenLabs' ideal of anopen LIS. The new LIS was taken into routineuse in November 1996 at both hospitals. The pro-ject was completed in 1997 with the ¢nal accep-tance of the new LIS. This paper documents anddiscusses the experiences of the NLS projectagainst the background of OpenLabs.

1.2 The OpenLabs project

One of the four major objectives of the Open-Labs project was ``to specify an open systemsarchitecture for a clinical laboratory informationsystem environment'' [1]. The project coined theconcept ``open clinical Laboratory InformationSystem'' (open LIS), which was de¢ned as anexisting LIS connected to analytical instru-ments, advanced laboratory services (decisionsupport systems, etc.), together with a servicemanager to co-ordinate the work£ow throughthe system. Fig. 1 shows an open LIS consistingof separate modules that communicate andinteract through electronic messages under thecontrol of a work£ow manager. As speci¢ed inOpenLabs, this work£ow manager (called``OpenLIS Service Manager'', OLSM) is respon-sible for controlling the laboratory work fromthe acceptance of laboratory service orders tothe ¢nal delivery of reports [3]. The variousservices are invoked through the OpenLabsapplication programming interface (API),which consists of high-level functions supportingclient/server interaction permitting the use ofadd-on modules and communication with exter-nal IT systems in a vendor and platform indepen-dent manner. Such a documented API is thus thebasis for the required ``openness''.

1.3 Openness in the NLS project

This conception of an open LIS was re£ectedin the NLS project's speci¢cation of require-ments [4], which was used for a preliminary,European-wide request for information and alsofor the ¢nal invitation to tender: ``In addition tothese general requirements for `openness', theRH [Rikshospitalet] may have a future need fora general LIS-API [Application ProgrammingInterface], for example, as outlined in the Open-Labs project [...].''Therefore, it was stated (in Chapter 4 of the

speci¢cation) that the new LIS should

. be based on modern, main-trend and com-mercially obtainable hardware and systemsoftware running under a modern and stan-dardized operating system

. ¢t into the hospital's network-based infra-structure and system for distributed informa-tion handling, and

. have a su¤ciently detailed system documen-tation. It was stressed that the documentationof the system, including its data structures

<

FIG. 1. Global view of data £ow in an open LIS.The arrows depict one or more electronic messages.Some of the ``boxes'' may represent several analogousfunctionalities. Modi¢ed from the OpenLabs data£ow diagram (Fig. 1 in ref. 3).

34 H. E. Solberg & J. G. Gleditsch

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

and its hardware and software interfaces,should enable independent computer expertsto con¢gure the system and to design anddevelop substitute and add-on modules tothe LIS.

The project team realized that it probablywould not be possible in a LIS, commerciallyavailable at the time of invitation to tender, toobtain a full achievement of the OpenLabs viewof an open LIS. However, a close approximationto that ideal was highly desirable. In the openLIS as speci¢ed in the NLS project, many ofthese modulesöbecause of constraints imposedby availability on the marketöhad to be inte-grated within the LIS itself, which would alsobe its own work£ow manager. In such a situa-tion, two issues are important: (1) the systemmust be highly con¢gurable, and (2) it must havea su¤ciently documented data model and speci-¢ed interfaces that permit access to data andlinking with external IT systems. These inter-faces should not only give access to historicaldata, for example, by the use of SQL with arelational database. It is equally, and oftenmore, important to have access through de¢nedinterfaces to real-time data and processes in theLIS. Fig. 2 shows an open LIS as conceived bythe NLS project team.This paper ¢rst brie£y describes how a new

LIS was selected during the NLS project. There-after, the openness of the selected system is stu-died. Real examples are described and discussed.

2 SELECTION OF A NEW LIS

As a basis for the following study of openness ofthe selected LIS, a brief outline of the jointproject ``New Laboratory System'' (NLS) atRikshospitalet and Haukeland sykehus andits methodology is given here (Fig. 3).

2.1 Pre-project and request for information

1) The ¢rst main activity was a very detailed andcomprehensive speci¢cation of requirements,covering both user desiderata and functionaldemands. Table I gives the contents of thespeci¢cation document.

2) This document was used as the basis for aEuropean-wide Request for Information(autumn of 1994). Among the 16 replies

received, ¢ve LIS vendors were selected, thatis, they were ``pre-quali¢ed'' according to theterminology of the European Economic Area(EEA).

2.2 Invitation to tender, evaluation, andselection

This part of the project was run according to avery formal method to ensure, as far as possible,unbiased decisions in the selection process.

3) Following a minor revision of ``Speci¢cationof Requirements'', this document was con-

<

FIG. 2. An open LIS as conceived in the NLS pro-ject [4]. The grey boxes represent users and externalmodules or IT systems.

FIG. 3. The project ``New Laboratory System''(NLS). The ¢gure shows the stages of the joint NLSproject of two Norwegian university hospitals.

Open LIS: a case study 35

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

verted to a large table. Each stated require-mentöeven the minor onesöoccupied aseparate row in the table, identi¢ed by theparagraph number of the speci¢cation docu-ment and key-words summarizing therequirement. Four blank columns wereadded. For each row the vendor could statein the appropriate column whether therequirement was (a) part of the standardLIS, (b) an optional feature of it, (c) possibleto develop within 3 months, or (d) possible todevelop in a year.

4) This table (on a diskette) and the original spe-ci¢cation document were issued with the Invi-tation to Tender, which was sent (June 1995)to the ¢ve pre-quali¢ed vendors. They wereasked to return the diskette with the com-pleted table when submitting their tender. In

this way all vendors were enforced to state theful¢lment of each requirement.

5) All ¢ve vendors returned ¢lled-in tables andsupplementary information with their ten-ders. To make direct comparisons possible,all the replies were edited into a single table,still with one row for each requirement. Atthis stage, two vendors could be droppedbecause it was obvious that their o¡ers wouldnot satisfy the two laboratory departments.The evaluation continued with the threeremaining vendors. The project group visitedthese companies and reference installations ofthe LISes that they o¡ered to clarify all detailsneeded. This information was put into anupdated version of the table which at thisstage contained a very complete basis forcomparison and evaluation.

6) The evaluation comprised the followingstages: (a) The requirements in the compari-son table were divided into logical groups (inmost cases corresponding to the major subdi-visions of the speci¢cation document, seeTable I). (b) These groups were given weightfactors (0.5~low, 1~standard, and 2~highweights). (c) Ful¢lment scores were given toeach vendor (3~best, 1~worst). (d) Finally,an evaluation table, containing weighted ful-¢lment scores and their sums for each vendor,was made (Table II).

7) At this stage the price o¡ers were opened. Tothe project group's surprise and great satisfac-tion it was discovered that the total priceswere inversely related to the weighted ful¢l-ment scores. ``LIS x'' (~NetLab, see below)was both the system with the highest scoreand the least expensive one.

8) The contract was made with Bull AS (Oslo,Norway) in February 1996. Then followed acustomization, installation and testing perioduntil NetLab was put into service at both hos-pitals in November the same year. The systemwas eventually approved formally in June1997.

2.3 Openness in vendors' replies

Because most vendors did not comment sys-tematically on the speci¢ed requirements, it isdi¤cult to evaluate and compare the opennessof the LISes described in the 16 answers toRequest for Information (see step 2 above).

<

TABLE I. Contents of the document ``Speci¢cationof Requirements'' [4] of the NLS project.

1 Introduction2 The Hospitals and the Laboratories3 System Scope and Objectives4 General Requirements

4.1 ``Open'' System Architecture4.2 Distributed Data Processing4.2.1 Networks4.2.2 A Network-Based LIS4.2.3 Interfaces to Other Systems

4.3 Data Model4.4 Work Stations4.5 User Interface4.6 Support for Certi¢cation of Laboratory

5 Functional Requirements5.1 Order Entry5.2 Entry, Calculation, Control and Veri¢cation

of Results5.3 Linking of Laboratory Instruments and

Equipment5.4 Reporting of Results5.5 Comments5.6 Quality Control5.7 Statistics

6 System Requirements6.1 Response Time6.2 Storage6.3 Capacity and Con¢guration

7 Other Requirements7.1 Security7.2 Running, Operation, and Maintenance7.3 Documentation and Training

The speci®cation document is available uponrequest to the authors.

36 H. E. Solberg & J. G. Gleditsch

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

However, because of the mandatory responsein the tenders to each requirement (see steps 4and 5 above), the project could take opennessinto account when selecting the best LIS amongthe three systems that competed in the last phaseof selection. Table III summarizes the opennessof these systems. The project group's rankingwith regard to openness was LIS x(NetLab)wLIS zwLIS y.

2.4 The NetLab system

NetLab is a LIS produced by Saric Interna-tional (NetLab Center, Lucerne, Switzerland), acompany subsidiary of Bull International. Thesystem runs on a UNIX server (the NLS installa-tion: Bull ESCALA, IBM AIX). Data are storedin a set of dynamic ¢les supporting real-timeprocessing, with continuous updating of a rela-tional database (UNIFY 2000) for long-timestorage and information handling. The worksta-tions are PCs, running underWindows 3.x or 95/98/NT, which emulate terminals in a network(Ethernet, TCP/IP). All NetLab installationsrun the same program nucleus. The LIS is custo-mized by various mechanisms, such as tables of

static data, parameters, scripts, con¢gurableinterfaces, etc. Many of these tools are topics ofthe present study.

Analytical instruments are on-line throughOLIC, a network-based instrument subsystemwith Windows 95 clients and a gateway toNetLab on a Novell server.

3 OPENNESS OF THESELECTED LIS

The following three aspects of openness are stu-died: (1) Customization and con¢guration of theLIS, (2) interfaces to processes and data inthe LIS, and (3) addition of decision supportto the LIS.

3.1 Customization and con¢guration

3.1.1 Parameters and static tables. Since thecore program of NetLab is the same for alllaboratories, the system must be highly con¢g-urable. This is achieved by basing the system onan extensive set of tables and con¢guration¢les. Absolutely all parameters and con¢g-

<

TABLE II. Evaluation table. The compared LISes are held anonymous (codes `x', `y' and `z').

Score

Group of requirements (see Table I) Weight LIS x LIS y LIS z

3 System Scope and Objectives 1 3 1 24.1a `Open'' System Architecture (technology platform) 1 3 1 24.1b ``Open'' System Architecture (functional openness) 1 3 1 24.2 Distributed Data Processing 1 2 2 24.3 Data Model 2 3 1 24.4 Workstations 0.5 1 2 34.5 User Interface 0.5 3 2 14.6 Support for Certi¢cation 0.5 1.5 3 1.55.1 Order Entry 2 3 1 25.2 Entry, Calculation, Control and Veri¢cation of Results 2 3 2 15.3 Linking of laboratory Instruments and Equipment 2 2 3 15.4 Reporting of Results 2 3 1 25.5 Comments 1 3 2 15.6 Quality Control 1 1 2 35.7 Statistics 0.5 2 2 26.1 Response Time 1 2 2 26.2 Storage 1 2 1 36.3 Capacity and Con¢guration 1 2 2 27.1 Security 1 1.5 1.5 37.2a Running, Operation, and Maintenance (running) 0.5 1.5 1.5 37.2b Running, Operation, and Maintenance (administration) 0.5 3 2 17.3 Documentation and Training 1 2.5 1 2.5

Weighted sum of scores 59.0 38.8 46.3

Open LIS: a case study 37

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

uration data for the NetLab system are openfor inspection and modi¢cation by site man-agers. The system also coexists very closely withthe standard UNIX environment, relying onthe principle ``UNIX to do what UNIX is bestat''. Most of the administration and mainte-nance programs are UNIX shell-scripts,-which may be inspected and modi¢ed.

We can broadly classify the parametrizationand con¢guration of NetLab within three maingroups.

1) Con¢guration and behaviour of:

. program modules

. dialogue de¢nitions (see 3.1.2)

<

TABLE III. Openness in the three competing LISes. Summary of information given with the tenders.

System

Category of openness LIS x LIS y LIS z

PlatformHardware Standard Standard ProprietaryOperating system Standard Standard ProprietarySystem programs Standard Proprietary database,

otherwise standardSQJdatabase,otherwise proprietary

DocumentationSystem Yes, detailed No Yes, detailedData model Yes, detailed Only partially Yes, detailedInterfaces Yes, detailed No Only SQL

APIs Several, documented,con¢gurable ``ports''

No ``open'' APIs Only for on-lineinstruments

Additional decision supportInternal Flexible and powerful

programminglanguage permits userdevelopment ofcomputing anddecision algorithms

Computed resultspossible; only vendordevelopment ofdecision rules (userdevelopment possiblein the future)

Only vendordevelopment

External User may interfaceadd-on modulesthrough ODBC andcon¢gurable real-timeports

Only vendor mayinterface externalmodules

Only through SQL

Flexible reporting Yes, general report tool Partially Partially

StatisticsInternal Yes, routine statistics Yes, routine statistics Yes, routine statisticsExternal Yes, through SQL

export and ODBCtext ¢les (SQL in the future) Yes, through SQL

export

Customization Yes, extremely£exible and powerfulthrough tables,parameters, scripts anduser-programmedprocedures

Parametrization Partialparametrization; someprogramming byvendor often needed

DocumentationSystem Yes, very

comprehensive; alsopossible to read witha web browser

No, only sometechnical guides. Datamodel only availablewith specialagreement

Yes

Maintenance Yes Yes PartialUse Yes Yes Yes

38 H. E. Solberg & J. G. Gleditsch

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

. hardware objects (terminals, printers, ports,etc.)

. users (signatures, defaults, access-levels, etc.)

2) Work organization:

. Test parameters (names, codes, units, refer-ence and warning limits, etc.)

. Workstations, worklists, instruments, etc.

Comment: We stress that the data model ofNetLab suits our laboratory very well. The orga-nization of the laboratory into sections andworkstations, with their work lists and instru-ments, is nicely mirrored as corresponding enti-ties with proper relationships in the data model.Also the grouping of tests in the laboratory'srepertoire and their relations with work lists areadequate.

3) Other de¢nitions:

. Comments, messages, texts, information

. De¢nition lists (sample types, result valuelists, £ags, and many more)

. Users can also create their own de¢nitionsand lists

As may be expected, local sta¡ have used thissystem extensively for customization. Experi-ence with the tools delivered with NetLab forthis kind of system administration is good.Fairly advanced modi¢cations of the system'sbehaviour are possible. One example: To laystricter rules on requester de¢nition we createda new de¢nition table with the codes for the cor-rect requester groups. The appropriate ¢eld inthe corresponding screen dialogue for entry ofrequester data was then linked to this table.

3.1.2 Screen dialogues. The user interface inNetLab is based on user con¢gurable screendialogues. The system components of a NetLabdialogue are

. a program from the NetLab library of dia-logue programs

. a dialogue ``mask'', containing ¢xed text,separating lines, etc., which may be designedwith a special-purpose editor

. a table with a list of data ¢elds and their attri-butes (parameters), and

. a dialogue compiler that generates a screendialogue from the program, mask and list of¢elds speci¢ed by the user.

Any number of specialized dialogues may inthis way be made and con¢gured to the user'sparticular requirements. This activity may bedone at any time and repeated when needed.Usually, new dialogues are developed on thebasis of existing ones. NetLab has functions forcopying dialogues for further editing and con¢g-uration.

This feature has been employed at Rikshospi-talet to generate and modify several screen dialo-gues to ful¢l local requirements. A typicalexample is the creation (by NetLab sta¡) andmodi¢cation (by the local system administrator)of a dialogue (MVAL) to be used by laboratoryphysicians responsible for medical validation ofpatient results:

1) A general-purpose selection and display dia-logue (RQFG) was copied and given the acro-nym ``MVAL''.

2) The dialogue mask was edited in the specialeditor for this particular purpose. Lines, texts,etc. were drawn into the mask to de¢ne ascreen suitable for the doctor performingmedical validation.

3) The list of ¢elds for this dialogue was de¢ned.It speci¢ed all needed data ¢elds and theirattributes. The attributes of a ¢eld de¢ne itsposition, behaviour, functionality, defaultvalue, function keys, etc.

4) In the case of the MVAL dialogue the selec-tion criteria were set in such a way that thedialogue would select and sequentially dis-play all requests containing results withextreme and panic values, delta-check warn-ings, and all results failing to be automaticallymedically validated by the speci¢ed internalrules.

5) The dialogue was then generated by the use ofthe NetLab dialogue compiler, made avail-able to users having the required access privi-leges, and included in user menus whereneeded. The dialogue could immediately betested and used.

The resulting MVAL dialogue is shown inFig. 4. Observe that results outside reference(`r'), extreme (`e'), and panic (`p') intervals aremarked. Also delta-check warnings (`D') and£ags for technical (`T') and medical (`M') valida-tion are shown. The doctor in charge of medicalvalidation may perform the required actions inthis dialogue by navigating the cursor and usingfunction keys.

<

Open LIS: a case study 39

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

3.1.3 Printed reports. All printed reports inNetLab are con¢gured from a few basic reportprograms. The elements that combine togetherto create a speci¢c printed report in NetLab aretypically the following:

. a program from the NetLab library of reportprograms

. a set of parameters dictating the functionalityof the report (data content, sorting, schedul-ing, etc.)

. a simple screen dialogue for the user to setcriteria for data selection, choose a printerand start the report

. one or more high-level report script to presentand format the data using a report generator

. a printer if the report is to be a hard-copy.(Reports can also be written to ¢les or ``ports''and used for export or data-capture functionsif desired; see 3.2.4)

In principle, any report generator may beused. At Rikshospitalet we have used the inher-ent UNIFY report generator and found this ade-quate for our needs. Rikshospitalet's reportscripts are mostly written to produce PCL-5 for-mat print ¢les and standard PCL-5 compatibleprinters of all sizes are used for printing. Labelprinting with bar codes is also handled as report-ing in the system, and is freely con¢gurable toproduce the desired layouts on labels.

Any number of specialized reports may bede¢ned and con¢gured to meet users' speci¢cneeds. Setting parameters and editing scripts todevelop and test reports can be done at any time.Rikshospitalet has made its own modi¢cationsto nearly all of the initially delivered reports. Inaddition, several new reports have been devel-oped. Some of them are listed below (the localreport names are stated with capital letters):

. RUTAöA critical subset of tests immedi-ately sent to local, dedicated printers in someintensive care units when the results arevalidated in the laboratory.

. RELIöspecial list used by analytical sectionsin the laboratory to discover and ¢nd samplesthat may be overdue.

. ALISöA preliminary report for a ward thatpresents all the patients and a subset of testsfor these patients in a spreadsheet layout.

. GLULöA report used when collecting andanalysing glucose from patients being moni-tored all day and night.

. ROCOöA special report used when report-ing corrected results to a requester.

It is also possible to invoke other utilities fromreport generator scripts. As NetLab does notsupport directly high-quality graphs on printedreports, Rikshospitalet has installed and usedthe GNUPLOT program, a command-line plot-

<

FIG. 4. Screen dialogue for medical validation (MVAL).

40 H. E. Solberg & J. G. Gleditsch

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

ting utility [5]. Fig. 5 shows an example of a plotdirectly produced from the NetLab databasethrough the report generator and GNUPLOT.(When this was written, the graphical reportingfrom NetLab was only at the pilot stage.)

3.2 Interfaces. In the OpenLabs project [1 ^3], openness was based on a set of high-levelfunctions supporting client-server interactionöthe OpenLabs APIöassisted by a service man-ager to co-ordinate the work£ow through thesystem (Fig. 1). The interaction with externalmodules and other IT systems has been solveddi¡erently in NetLab, which does not have astandardized and global API and which reliesupon internal work£ow management. In fact,NetLab has several interfaces, both to historicaland static data in the relational database and toreal-time, dynamic processes. In this sense,NetLab implements the open solution shown inFig. 2.

3.2.1 Con¢gurable ``ports'' to real-time pro-cesses. The NetLab includes a program module(EXIM) specialized for real-time import andexport of data. EXIM can be set up in anynumber of instances and each program is indivi-dually con¢gured to meet a speci¢c demand.The interface for one such EXIM port may be aremote network program, a serial communica-tion line or a ¢le based interface. An EXIMport will typically consist of the following:

. An EXIM program module

. a set of parameters de¢ning the system con¢g-uration of the program (name, starting condi-tions, scheduling, low level communicationcharacteristics, etc.)

. a data de¢nition of the ¢elds handled in theexport or import

. a criteria de¢nition describing the criteria forimporting/exporting data (requester groupsor codes, speci¢c £ag settings, etc.)

. a high level protocol description (de¢ning

<

FIG. 5. Printed graphical presentation of patient results. The graph shows results of micro-CRP and creatininein serum (ordinate) versus sample collection time (abscissa).

Open LIS: a case study 41

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

dataframes, checksum algorithms, ACK/NAK conventions, etc.)

. any number of shell scripts or other programsto perform desired pre- or post-handling ofdata.

At present Rikshospitalet has seven suchEXIM ports de¢ned:

1) An import of historical data from the latelaboratory system used before start-up ofNetLab. The EXIM port was set up todirectly read data ¢les of ``old'' data andupdate the database, thereby creating a one-year historical ``data-background'' for exist-ing patients.

2) An export of all new requests entered inNetLab used to interface the old instrumentnetwork server to NetLab.

3) An import of results from the old instrumentnetwork server. When NetLab was taken intouse the new instrument network (OLIC) wasnot taken into use until a little later. The exist-ing instrument network server was modi¢edto communicate with NetLab instead of theold LIS, and the switch-over was transparentas seen from the instrument workstations.

4) Real-time export of results for EDI purposes.5) Daily export of billing data.6) An import of all new or modi¢ed patient

information from the hospital's patientadministrative system.

7) Real-time export of results from internalrequesters to build a central hospital resultdatabase with data and information frommany service providers, including labora-tories. The database will support a hospital-wide result query client program and even-tually also a request client.

The ¢rst six of these EXIM ports were deliv-ered with the system, but several have later beenadjusted by local sta¡. The EXIMs used as inter-face to patient data (no. 6 above) have beenextensively modi¢ed at Rikshospitalet. Theexport of results to the central information data-base (no. 7 in the list) was set up by Rikshospita-let's own sta¡ independently of the vendor.This easily con¢gurable export and import

mechanism of real-time data is one of NetLab'sstrongest features in relation to openness. It per-mits local sta¡ to develop and modify veryadvanced interfaces between the LIS and other

IT systems, permitting a high degree of systeminteraction.

3.2.2 SQL interface to relational database.NetLab is built around a standard relationaldatabase (UNIFY 2000) with some 70 indivi-dual tables containing

. static information (more or less) needed byNetLab to perform its tasks, for example,laboratory test repertory, standard com-ments, tables of requesters, and con¢gurationdata

. production data, for example, on patients,requests, samples and results. The productiondata are continuously updated, with a verybrief delay, from the dynamic ¢le system usedfor real-time processing.

This database system supports standard SQLin both interactive and embedded modes. Inter-active SQL permits the user to enter SQL state-ments at a workstation and immediately triggerthe speci¢ed database actions. In the embeddedmode, SQL statements are included in programs.Then the speci¢ed database actions are donewhen the program is executed. Both SQL modeshave been used by Rikshospitalet's own sta¡ toaccess the NetLab database.Comment: The SQL interface is not a special

feature of NetLab. Data of any LIS with arelational database will probably have an SQLinterpreter.

3.2.2.1 Interactive SQL. When a completedocumentation of the data model is available,as is the case with NetLab, an experienced usermay take full advantage of the power of interac-tive SQL to retrieve and manipulate data. Thisfeature has been used extensively with NetLabat Rikshospitalet. Here are some typical exam-ples:

. Batch import of data into the database fromexternal sources.

. Batch export of data for processing by otherprogram systems. This has been particularlyuseful for heavy statistical analysis. At Rik-shospitalet very extensive workload studies,analyses of result distributions, etc., havebeen performed in this way, using a commer-cial statistical program package (SAS Version6.10, SAS Institute Inc., Cary, NC 27512,U.S.A.).

<

42 H. E. Solberg & J. G. Gleditsch

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

. Analysis of data directly, using interactiveSQL statements, is of great value when tryingto trace errors, and it was used extensivelyduring the acceptance testing of the new LIS(see section 2.2, stage 8).

. Manipulation of data, using interactive SQL,is an extremely dangerous operation with pro-duction dataönot to be recommended forinexperienced users! However, in a few casesat Rikshospitalet it has been necessary to usethis method for correcting errors or solve pro-blems that are di¤cult to handle otherwise.

3.2.2.2 Embedded SQL. SQL statements maybe embedded in various scripts (program state-ments that are interpreted at run-time). Thismethod is used, for example, in CGI scripts(Common Gateway Interface), permitting webapplications to be used with data in the NetLabdatabase. The local system administrator mayalso develop UNIX shell scripts, small pro-grams that do useful database tasks throughembedded SQL. Here are two examples of shellscripts developed locally at Rikshospitalet:

1) To facilitate the administration of users ofNetLab a simple shell script was developed.It prompts the administrator for informationand then performs, by embedded SQL state-ments, the required updating of tables in theNetLab database.

2) To prepare printed reports of important testparameters, a shell script with embeddedSQL triggers an extraction of the requiredinformation from the NetLab database andformats this information for printing usingUNIFY's report generator.

Comment: It is also possible to embed SQLstatements in the source code of the C-language,the language in which NetLab has been devel-oped. However, for performance reasons,NetLab employs direct calls to the UNIFY data-base through an API.

3.2.3 High-level interfaces to relational data-base. As most systems based on a relationaldatabase management system, NetLab permitsaccess to data through high-level interfaces likeMicrosoft's ODBC (an API), provided that theappropriate driver programs have been installedon the NetLab server and workstations (cli-ents). This feature makes it possible to use

commercial and user-friendly software, likestatistical program packages (for example,SAS) and Microsoft Access and Excel, to solvead-hoc problems or to develop production rou-tines. Rikshospitalet has exploited this facility.Two examples:

. An Access application for checking and vali-dating billing data before these are trans-ferred to the hospital's economy system hasbeen developed and used routinely.

. Access has frequently been used for ad-hocanalysis of NetLab data when problems orerrors have occurred.

3.2.4 Use of the report generator as interface. Asmentioned in section 3.1.3, output formatted bythe report generator may also be written to ¢les.This kind of export is thus an alternative tothose obtained by the EXIM mechanism, SQL,and high-level interfaces to the relational data-base (see sections 3.2.1 ^ 3). Like ordinary print-outs, report output to ¢les may be produced ondemand or automatically scheduled. This facil-ity has been tested and used at Rikshospitalet inpilot versions of data export to other IT sys-tems. However, in these cases export throughEXIM (3.2.1) was eventually preferred.

3.3 Decision support

The OpenLabs project [1, 2] stressed the needto add various kinds of decision support systems(DSS) to the open LIS and developed severalprototypes for such modules. Many of the boxesin Fig. 1 represent advanced, ``intelligent'' ser-vices, based on numerical criteria, expert systemtechnology, neural networks, etc.

3.3.1 External decision support modules. InNetLab,, such add-on modules may be inter-faced as described above, either to the dynamicprocesses through the EXIM ports (see 3.2.1) orto the relational database (3.2.2 and 3.2.3). Atpresent, no external decision support moduleshave been interfaced to the NetLab installed atRikshospitalet. We have thus no experiencewith this facility.

However, Rikshospitalet participates in EU'sINCO-Copernicus project ``Information SystemSupport for Quality Assurance and Accredita-tion of Clinical Laboratories'' (called``QLABz''). Any future testing and validation

<

Open LIS: a case study 43

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

at Rikshospitalet of QLABz software will useEXIM mechanisms.

3.3.2 NPL programs. In addition, NetLab hasa special-purpose programming language calledNetLab Program Language (NPL). This simplelanguage has a C-like syntax and includes func-tions and procedures with arguments, recur-sion, if-then-else switches, full £oating pointarithmetic, and many functions to manipulaterequest or result records:

. Modi¢cation of the handling of requests: add-ing tests, deleting tests, adding comments, etc.

. Modi¢cation of the handling of test results:checking, setting/unsetting of result valuesand various £ags, issuing warnings, addingcalculated tests and computing their values,executing rule-based decisions (including useof previous values), adding comments, etc.

NPL is thus a very powerful tool in the handsof an experienced person. Since adequate docu-mentation is available, the development of NPLprograms, in most cases, does not require com-pany assistance. They may be tested immediatelyand put into service ``on the £y''.At Rikshospitalet, this £exible and powerful

feature of NetLab has been used for problemsthat otherwise would have been impossible tosolve without the addition of external modulesor modi¢cation of NetLab by the producer. Sofar, a total of 12 NPL programs have been devel-oped locally for problems in the following areas:

. Automatic ordering of supplementary lab-oratory tests when certain conditions areful¢lled.

. Automatic generation of comments torequests or test results.

. Checking of test results to aid in the medicalvalidation.

. Rounding-o¡ of results depending on the levelof the result.

. Deleting redundant tests. Two examples: (1)When serum electrophoresis is ordered, totalprotein in serum is requested automatically asan additional test while total protein inplasma is deleted if it has been ordered. (2)A result entry for a test done with a statmethod deletes the same test ordered withroutine priority.

Table IV gives a simple example of oneof these NPL programs. To aid the valida-tion of haematology results, the procedureCheckHBandHCT calculates the ratio of hae-moglobin and haematocrit values and executestwo simple decision rules based on this ratio.This example illustrates some important featuresof NPL programs.

. Retrieval of a result value:revl()

. Calculation, in this case, of a ratio of resultvalues:Ratio~revl("HB_B") /revl("HCT_B")

. Requesting a new test:add_test()

. Assigning values to record elements. In thisexample, a result value is de¢ned and result£ags are removed:set_revl()unset_refg()

<

TABLE IV. Example of NLP procedure. Calculation of the ratio of B-Haemoglobin and B-Haematocrit as anaid in patient results validation. If the ratio is outside the interval 0.300 ^ 0.375 automatic medical validation ofB-Haemoglobin and B-Haematocrit is inhibited. If the ratio is outside 0.290 ^ 0.380 also the technical validationof these two tests is unset.

proc CheckHBandHCT() {if (revl("HB_B") w 0 && revl("HCT_B") w 0) {Ratio~revl("HB_B") / revl("HCT_B")if (Ratio w 0,375 || Ratio v 0,300) {add_test("HB/HCT_ ")set_revl("HB/HCT_ ",Ratio)unset_refg("HB_B","MVAL")unset_refg("HCT_B","MVAL")if (Ratio w 0,380 || Ratio v 0,290) {unset_refg("HB_B","TVAL")unset_refg("HCT_B","TVAL") }}}}

44 H. E. Solberg & J. G. Gleditsch

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.

. Execution of decision rules, which here arestatements of the if-then type:if

4 DISCUSSION

This case study shows that NetLab is not animplementation of the genuine OpenLabs modelfor an open LIS (Fig. 1). NetLab does not have ageneral, standardized OpenLabs API permittinga set of modules to communicate and interactunder work£ow control by a central service man-ager. However, NetLab is a very powerful reali-zation of the alternative model for openness asconceived by the NLS project group (Fig. 2).This LIS has a high degree of con¢gurability,and several e¤cient and easy-to-use interfacesboth to the dynamic, real-time processes and tothe relational database. The twomain di¡erencesfrom the OpenLabs model are:

. NetLab relies on internal work£ow manage-ment.

. There is no single, standardized API inNetLab, but a set of di¡erent interfaces tothe system.

The practical problem with the OpenLabsmodel, at the present stage of development, isthat it is not commercially available. The Open-Labs project has described an ideal LIS environ-ment. To attain this goal, international e¡ortsare needed. It is necessary to obtain interna-tional consensus of a standardized API and ofthe functionality of work£ow managers so thatcompanies may develop LISes and add-on mod-ules for advanced services that may easily beinterconnected.In this perspective, and as a temporary solu-

tion, NetLab has an obvious advantage: Thisopen LIS is commercially available, and itsopenness may be used directly by competentlocal sta¡. When reviewing the OpenLabs speci-¢cation of user requirements [6] and functional-ity [3], it is our conviction and experience thatmost of the open LIS features may be realizedthrough the tools o¡ered by NetLab.

The persons running the NLS projects wereastonished at the very closed nature of mostLISes evaluated. There may be several reasonsfor this:

. Openness is a relatively new concept, andmany of the commercially available LISesare old systems with only a modern ¢nish.

. Openness makes it possible for local or third-party development of LIS-related applica-tions. Many LIS companies seem to fear thissituation, as customization and the develop-ment of extra features represent a signi¢cantpart of their income.

We believe that openness will be a dominantfeature of future IT systems. Therefore, a LISthat already o¡ers a certain degree of opennesswill compete strongly in the market.

REFERENCES

1 O'Moore R, Groth T, Grimson W, Boran G. TheOpenLabs project. Comput Methods ProgramsBiomed 1996; 50: 85 ^ 6.

2 O'Moore R, Groth T, GrimsonW, Boran G, editors.Advanced informatics and telematics for optimiza-tion of clinical laboratory services. A selection ofpapers describing various activities of the EU-AIMOpenLabs project. Comput Methods ProgramsBiomed 1996; 50: 85 ^ 206.

3 Grimson W, Brender J, Grimson J, Groth T,Hermanson B, Yearworth M, Wade V. Specifyingan open clinical laboratory information system.Comput Methods Programs Biomed 1996; 50: 95 ^109.

4 (NLS Project Group.). Speci¢cation of Require-ments: Laboratory Information System for Rikshos-pitalet and Haukeland Sykehus. Non-publishedreport, Rikshospitalet (Oslo) and Haukeland Syke-hus (Bergen),Version 2.0 (23.06.95). (Available uponrequest to the authors of the present paper.)

5 GNUPLOT. See the Internet: www.cs.dart-mouth.edu/gnuplot___info.html

6 Brender J, McNair P. User requirements on thefuture laboratory information systems. ComputMethods Programs Biomed 1996; 50: 87 ^ 93.

Received: 20 November 1998Accepted: 3 December 1998

<

Open LIS: a case study 45

Scan

d J

Clin

Lab

Inv

est D

ownl

oade

d fr

om in

form

ahea

lthca

re.c

om b

y U

nive

rsity

of

Wat

erlo

o on

10/

30/1

4Fo

r pe

rson

al u

se o

nly.