Download - Decision support system for primary health care in an inter/intranet environment

Computer Methods and Programs in Biomedicine 55 (1998) 31–37

Decision support system for primary health care in aninter/intranet environment

Tom af Klercker a,b,c,*, Mans af Klercker d

a Departments of General Practice and Primary Care, Faculty of Health Sciences, S-581 85, Linkoping, Swedenb Department of Oto–rhino– laryngology, Faculty of Health Sciences, S-581 85, Linkoping, Sweden

c Department of Computer science, Uni6ersity of Linkoping, Linkoping, Swedend Department of Computer science, Uni6ersity of Uppsala, Uppsala, Sweden

Received 28 February 1997; received in revised form 25 August 1997; accepted 28 August 1997

Abstract

The need for easily accessible computerised decision- and documentation-support in primary health care has beenpreviously published. The implementation of such a tool in an intranet environment is described. The use of free-warewhich can be downloaded from the world-wide-web (www) is shown to constitute a very potent and manageablesystem. With the use of innovative scripting, very good log-functions can be added in order to render thoroughstudies of its use possible. In this way, it is possible—under strict research conditions—to study the potential helpand support provided by case-based decision support software in everyday use on a primary care unit. The ease ofuse of this system, as well as its flexibility, shows promise for the future. © 1998 Elsevier Science Ireland Ltd.

Keywords: Case-based; Decision support; Primary health care; HTTP; World-wide-web

1. Introduction

The need for support in decision-making anddocumentation in primary health care (PHC) hasalready been reported [1]. The use of an inductivecomputer program for producing such supportsystems from local case files has also been previ-

ously published [2,3]. Most Swedish PHC centresare computerised, with a variety of commerciallyavailable systems. The implementation of a sup-port system that can be easily and widely ex-tended must be platform-independent. In thefuture, the Swedish health-care system is intendedto rely heavily on information technology (IT)and an easy way to be in the front line is to usecommon IT-solutions. One widely available net-work is the world-wide-web (www) in local (in-tranet) or global (internet) versions. As most of

* Corresponding author. Primarvardens FoU-enhet, Vard-centralen, 59530 Mjolby, Sweden. Tel.: +46 14278093; fax:+46 14278096; e-mail: [email protected]

0169-2607/98/$19.00 © 1998 Elsevier Science Ireland Ltd. All rights reserved.

PII S 0169 -2607 (97 )00052 -7

T. af Klercker, M. af Klercker / Computer Methods and Programs in Biomedicine 55 (1998) 31–3732

the software is free of charge and easy to down-load from the www, such a solution is cheap,relatively simple to structure for various tasks andeasy to use in an everyday working environment,since the same technique is used in routine infor-mation-searches on the intra-/internet.

Our aim was to implement and study the use ofa decision-support system in PHC for the ear noseand throat (ENT) section of a local PHC unit,running a local network. The idea was to use acommonly available, free ‘net-browser’ and aneasy-to-handle server run on an existing computeralready connected to the Internet. The basis forthe system was a decision-tree generated fromcase-notes, using an inductive technique describedelsewhere [3].

2. Background

The implementation of a decision and docu-mentation supporting system from a decision treegenerated by inductive computer software hasbeen previously carried out by the authors on avery small scale. The inductive programXpertRule Professional™ by Attar software, runon a Microsoft DOS based machine, produced apruned and edited decision-tree [3] that was im-plemented on an Apple Macintosh using Hyper-Card™. The program ran well but lacked much ofthe functionality required for clinical and researchpurposes. The Apple Macintosh platform couldnot be used, as nearly all computer programs usedin Swedish PHC are based on IBM compatiblepersonal computers (PC’s). There are a variety ofoperating systems involved and an even greatervariety of commercially available software used.Thus, a system that could be easily implementedon any platform and with all necessary function-ality was required.

3. Design considerations

A decision- and documentation support pro-gram for PHC should be easy to run and veryquick, e.g. short answering-times. It must, forresearch reasons, have a couple of easily accessi-

ble functions behind the interface to facilitatefollow up and studies into user related facts. Thismeans easy access to the different ‘screens’ and alog function that can measure almost everythingrelated to the use of the program. As money is alimiting factor in Swedish PHC, the system shouldbe cheap. It should be possible to run the pro-gram on almost any computer on any net in anyPHC-centre. As the system will hold patient re-lated information, it must be safe and complywith all laws and regulations within the Swedishhealth care system. Patient related and patientspecific information should only be stored tempo-rarily within the local system, while the operatoris actually dealing with the patient. When theoperator exits the patient interview, the researchand processing components of the system shouldonly store depersonalised information. Thus, thesystem log files should contain only informationnecessary for research purposes, without the pos-sibility of tracing back to any individual patient.

The program must be only suggestive, ratherthan dictative, as the responsibility rests with theuser and not with the system. It is important thatthis is made clear when using the system, leavingno doubt as to who is responsible for the patient.As treatment is often guided by local traditions,the system should not give suggestions regardingtreatment unless the local users assume responsi-bility for this. Therefore, local adjustments mustbe easily carried out on the program. It must bepossible to perform test runs with systems that areeasily discernible from a real patient-related run.

Local traditions and changes in the disease-panorama should be mirrored in the decisionsupport system as soon as the change is stable andaccepted by the users. This means that the pro-gram should include every new case tried in con-junction with the system and that the rules changeas the underlying database changes.

As connection to the internet leads to a risk ofinfecting the computer with viruses, an effectiveanti-virus environment is an absolute necessity.Some operating systems used in PHC are veryweak with regard to virus defence. To permit theuse of the standard protection system for theintranet, it was necessary for the www-program torun in its own operating system. Therefore, in the

T. af Klercker, M. af Klercker / Computer Methods and Programs in Biomedicine 55 (1998) 31–37 33

test PHC-centre both IBM OS/2 and MicrosoftWindows were run.

4. System description

4.1. O6er6iew

The decision support system prototype is builtusing a client/server solution. The protocol used isHyperText Transport Protocol (HTTP) which isthe protocol used by the www [4]. This choice wasmade for the following reasons.

4.1.1. Platform compatibilityRecent years have seen tremendous growth of

the www. This has encouraged software develop-ment by clients and servers using the HTTP pro-tocol. Today, there are servers and browsers (aHTTP client is most often called a browser) onevery major computer platform. This enables thesystem to be used in basically any computer envi-ronment. It further enables the server and clientto run on different platforms, which is of greatadvantage.

Most computer networks already use Ether-net™ technology, making it very easy to create aTCP/IP network (the networking standard of theinternet) on a network already in place, greatlyreducing installation costs. All the major operat-ing systems (OSs), Windows 95, Windows NT,OS/2, MacOS and UNIX, also come with TCP/IPinstalled.

4.1.2. Ease of installationIf a TCP/IP-ready network is already installed

at the testing site, installation of the client/serversystem is easy. A ready-configured server is con-nected to the network and www-browsers areinstalled on each work-station. This is all that isneeded to get the system up and running.

4.1.3. PriceMany applications of both www-servers and

browsers are available free of charge on the inter-net, of which many are in widespread use—theApache server used in this prototype is said to berunning at over 200 000 www sites. A smooth

working system of bug reporting and user testinghas squashed existing bugs in the software in thepast. Consequently, the server software is alreadyrobust. The browsers are also of good quality—Netscape Navigator™ is actually commerciallyavailable software, but is distributed free ofcharge to non-commercial users.

In larger installations one might opt for usingcommercially available software, in order tobenefit from technical support. In this prototypehowever, software provided free of charge hasbeen to our complete satisfaction.

4.2. Software

4.2.1. The ser6erOur choice of a HTTP-server was the Apache

www-server. It has a large number of uses andstems from one of the original www-servers on theinternet (the NCSA www-server). It is availableon UNIX-systems and on Windows NT. It has allthe usual features of a modern HTTP-server, suchas: ability to handle HyperText Mark-up Lan-guage-forms (HTML-forms), multi-level securityetc. Its world-wide use ensured us of its reliability.The choice of a HTTP-server was not critical inthis prototype; any server with the ability to han-dle common gateway interface (CGI) [5] externalscripts would have sufficed and this includes virtu-ally any server on any computer system.

4.2.2. CGI scriptingThe ability to handle CGI scripts was, as men-

tioned above, critical. CGI scripts provide amethod of extending a HTTP-server’s ability torespond to client requests. Common uses of CGIare gateways to databases and HTML-form han-dling. Since most of the user interface in thedecision support system consists of HTML-forms,CGI was an obvious choice. CGI scripts wereimplemented to manage most functions of thesystem: navigating the decision tree, session log-ging and patient data input.

The programming language (PL) used for theCGI-scripts was practical extension and reportlanguage (PERL) [6]. Its powerful text handlingand pattern recognition features make it an idealPL for CGI. The majority of all CGI scripts


working on the www today are written in PERL.Another factor was, once again, platform compat-ibility; the CGI scripts could very easily have beenwritten in some other PL, such as C+ + , orVisual Basic, but porting (strictly speaking, trans-lating) them from one platform to another wouldhave been much more difficult. PERL on theother hand, has been ported to a number ofdifferent platforms and uses an identical code onevery platform. A PERL script (that does not useany special features of one computer OS) can beused on any operating system, which is not thecase with many other PL’s. This enables the deci-sion support system to be ported, with minimumeffort, to a large number of different platforms.

4.2.3. File format and generationThe HTTP-server responds to client requests

mostly by sending the client a file. In the case ofthe present system, these files are mainly text filesin the HTML format. HTML is basically a PLconsisting of text with different formatting op-tions such as line breaks, lists, tables and images.These are represented using tags in the text. Whenthe www-browser (on the client side) receives textin HTML format, it will format the text accordingto the tags, with results resembling what onewould see from a normal word processor. Origi-nally it was intended that this would be usedmainly for publishing scientific text electronically,but extensions to HTML have made it possible tocreate more interactive elements on a page such asfill-in forms, buttons and menus. All these areused by our decision support system to create theuser input components of the system. They are allparts of the standard graphical user interface(GUI) of today, enabling a user familiar with astandard window system (Windows, Macintoshetc.) to recognise and use the screens with aminimum of explanation.

The tree structure is represented usingfilenames. Each file has a unique name, represent-ing its position in the tree, so for example ‘node334’ would be reached by selecting choice three inthe first and second questions and choice four inthe third. This enables a more dynamic approachto moving in the tree. Moving one level up in thetree (i.e. returning to the last question) is simply

achieved by removing the last digit (or any othercharacter), e.g. from ‘node 334’ to ‘node 33’. Byremoving more than one digit, it is possible tojump further back up the tree. When movingthrough the tree, one has only to number thedifferent responses and tack the chosen numberonto the current filename to arrive at the nextnode. In this system, this task is performed by twodifferent CGI scripts called ‘up’ and ‘down’. Thistechnique also makes changes in the structure ofthe tree quite simple. Individual files can bechanged at any time without affecting anything,as long as a branch of the tree is not ‘cut off’(deleted).

Each of the nodes and leaves in the decisionsupport tree is represented by a file. The nodesand leaves each represent a different screen lay-out. Within the group however, the difference indesign and content is very small. For example, theonly difference between each of the diagnoses isthe diagnosis itself and the percentage of cases itrepresents. This opens the field for simple,scripted regeneration of the files, rather than pro-ducing them all by hand.

For this we used a template for each of thedifferent types of files (node and leaf). Each of thetemplates comprise basically the complete HTMLcode for each of the files, but with differinginformation (specific diagnosis, frequency etc.) re-placed by special tags (cdiagnosisc ,c frequencyc ). In another file, the informationspecific for each file is stored. It can look some-thing like this:

[…]133node:Vertigodiagnosis:12frequency:

14452node:Otitis mediadiagnosis:4frequency:

[…]

The generating script then combines these twodifferent files to generate the files used by theserver (the above example would result in two


files, ‘node 133.html’ and ‘node 14452.html’, re-spectively). The two actually represent the totalamount of information stored—not only infor-mation but also sequencing. The same files arealso used to generate the path history on eachpage.

Nodes and leaves are pre-generated: they usu-ally do not change during use of the system.However, the system is designed to be very easyto modify. It will not actually store any leavesor nodes, these will be generated on demand.This is useful in a decision support systemwhich may change often; changes in the under-lying case-file database, will be reflected immedi-ately in the decision tree.

4.3. Other

4.3.1. StateEach time a user runs the system, some data

concerning the state of the individual user isrecorded, e.g. the user input concerning the pa-tient, user name, timing information etc. Forthis we use two different mechanisms, one onthe server side and another on the client side.As each session begins, it is assigned a 12 digitID. This is stored on the client side, usingNetscape persistent ‘cookies’. A cookie is a littlepiece of information that the server can ask theclient to store and to return each time the clientrequests something from the server. In this way,the server can always identify which user (orsession) is making the request and consequentlyset certain dynamic variables correctly (such asshowing the answer the user picked last time acertain node vas ‘visited’).

In the server, a temporary log is kept of eachsession. When a session is correctly terminated,scripts computes the temporary log and writesan entry into the main log.

4.3.2. AdministrationCertain administrative routines are also avail-

able using the www-browser. Adding new usersand handling and reading log files for example,can be done from any computer that can accessthe server. The correct address has to be knownin order to access these particular pages. As the

decision-support program runs on a computeractually placed in the computer science depart-ment of The University of Linkoping it can beaccessed from anywhere on the internet.

4.3.3. HardwareThe test PHC-centre already has 17 PC’s with

Intel 486 processors installed. Random accessmemory (RAM) was 8 Mb up to a maximum of16 Mb. The operating system is IBM OS 2,since the client/server computerised informationsystem, BMS from IBM, runs in that environ-ment. It runs on an intranet connected to awide area network (WAN) inside a fire-wall runby the local government. The net is an Ethernetand the protocol TCP/IP. A local computer actsas a server for the PHC-centre intranet.

5. Status report

The decision-support program has not beenaccessible on the Intranet of the PHC-centre un-til very recently so there is no record of itspractical use in its intended surroundings. Shortruns with different PHC staff in a mock-upmodel have shown the system to perform well,without serious faults. No real everyday use ex-perience is available thus far. Once the system isin everyday use, the log-function of the programwill quickly generate knowledge about the pro-gram and its users. The appearance of the start-ing pages is seen in Figs. 1 and 2. They are inSwedish, as is the actual working system whichwill to be used and studied. They appear as theydo on the screen using the Netscape Naviga-tor™ www browser.

The option to include the recorded cases inthe decision-support database, thus changing therules, has not been implemented, partly becauseof the relatively short time of intended use andpartly because prolonged use is outside of thescope of our study. This will however, be a keyfeature in the future, as it will enable the pro-gram to change automatically with increasingmedical knowledge and changing disease-panorama.


Fig. 1. This is the starting screen where the users identify themselves and relevant social patient data to be used during the run canbe entered. Translation is within the boxes.

6. Lessons learned

To implement a computer program for decisionsupport in Swedish PHC is a laborious job. Ev-erybody working in PHC has, partly because ofshortage of funding, a busy schedule. This meansthat if any extra work is taken on, howeverbeneficial on a research level, it must mean gainsat the local level. If substantial gains in the every-day working situation cannot be achieved, there isno interest whatsoever. There must be somethingto show to those involved and the product mustbe ‘marketed’ thoroughly. The program must besimple to run, as well as easy to access and leave,otherwise it will be difficult to convince anybodyto use it.

Although there are a huge number of differentideas and solutions to every conceivable program-ming problem to be found on the www, the veryspecial demands that research puts on the pro-gram, necessitates special and innovative pro-gramming.

Running a computer with two different operat-ing systems simultaneously makes the computer‘memory-hungry’. As no interference with the

speed of the ordinary programs used, especiallyno lengthening of answering-times, is acceptable,more RAM had to be installed. A minimum of 16extra megabytes of RAM for each PC was neces-sary.

The problems encountered and solved, are inline with modern PC development and evolvingstandards. We found that a swift and flexible,clinical decision support system for ambulatoryENT care in PHC is both motivated and useful[1–3]. Therefore, the forthcoming testing andevaluation of the system in a working PHC-centreis highly warranted.

7. Future plans

The decision support system will soon be imple-mented and its use documented and studied indetail. The underlying database derived from pa-tient records in a nearby PHC centre should beupdated with the patients from the test centre. Ifthere is a structured computerised patient record-keeping system, this could be carried out auto-matically by the computer. Thus, the decision tree


Fig. 2. First questioning screen. On the following, similiar screens, relevant facts from previous screen(s) are printed to facilitateprogress. Translation is within the boxes.

253–267.[2] T. af Klercker, E. Trell, P.G. Lundquist, Essential data-set

for ambulatory ear, nose and throat care in general prac-tice: an aid for quality assessment, Qual. Health Care 6(1997) 35–39.

[3] T. af Klercker, Effects of pruning of a decision-tree for ear,nose and throat realm in primary health care based on casenotes, J. Med. Systems 20 (4) (1996) 215–226.

[4] S. Spainhour, V. Quercia, Web Master in a Nutshell: ADesktop Quick Reference (O’Reilly, New York, USA,1996).

[5] S. Gundavaram, CGI Programming on the World WideWeb (O’Reilly, New York, USA, 1996).

[6] L. Wall, T. Christiansen, R.L. Schwartz, ProgrammingPerl, 2nd edn., (O’Reilly, New York, USA, 1996).

could adapt itself automatically to the way theactual centre handles its patients, bringing an evenbetter functionality to the decision support pro-gram. If we achieve a positive result from thetesting of this system, the same principles could beapplied in other medical specialities.

References

[1] T. af Klercker, E. Trell, P.G. Lundquist, Towards anessential data set for ambulatory otorhinolaryngologicalcare in general practice, J. Med. Informatics 19 (1994)

Download - Decision support system for primary health care in an inter/intranet environment

Top Related