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

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

Post on 16-Sep-2016




0 download


<ul><li><p>Computer Methods and Programs in Biomedicine 55 (1998) 3137</p><p>Decision support system for primary health care in aninter:intranet environment</p><p>Tom af Klercker a,b,c,*, Mans af Klercker d</p><p>a Departments of General Practice and Primary Care, Faculty of Health Sciences, S-581 85, Linkoping, Swedenb Department of Otorhino laryngology, Faculty of Health Sciences, S-581 85, Linkoping, Sweden</p><p>c Department of Computer science, Uni6ersity of Linkoping, Linkoping, Swedend Department of Computer science, Uni6ersity of Uppsala, Uppsala, Sweden</p><p>Received 28 February 1997; received in revised form 25 August 1997; accepted 28 August 1997</p><p>Abstract</p><p>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 possibleunder strict research conditionsto 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.</p><p>Keywords: Case-based; Decision support; Primary health care; HTTP; World-wide-web</p><p>1. Introduction</p><p>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-</p><p>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</p><p>* Corresponding author. Primarvardens FoU-enhet, Vard-centralen, 59530 Mjolby, Sweden. Tel.: 46 14278093; fax:46 14278096; e-mail:</p><p>0169-2607:98:$19.00 1998 Elsevier Science Ireland Ltd. All rights reserved.</p><p>PII S 0169 -2607 (97 )00052 -7</p></li><li><p>T. af Klercker, M. af Klercker : Computer Methods and Programs in Biomedicine 55 (1998) 313732</p><p>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.</p><p>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].</p><p>2. Background</p><p>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 (PCs). 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.</p><p>3. Design considerations</p><p>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-</p><p>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.</p><p>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.</p><p>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.</p><p>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</p></li><li><p>T. af Klercker, M. af Klercker : Computer Methods and Programs in Biomedicine 55 (1998) 3137 33</p><p>test PHC-centre both IBM OS:2 and MicrosoftWindows were run.</p><p>4. System description</p><p>4.1. O6er6iew</p><p>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.</p><p>4.1.1. Platform compatibilityRecent years have seen tremendous growth of</p><p>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.</p><p>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.</p><p>4.1.2. Ease of installationIf a TCP:IP-ready network is already installed</p><p>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.</p><p>4.1.3. PriceMany applications of both www-servers and</p><p>browsers are available free of charge on the inter-net, of which many are in widespread usetheApache server used in this prototype is said to berunning at over 200 000 www sites. A smooth</p><p>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 qualityNetscape Navigator is actually commerciallyavailable software, but is distributed free ofcharge to non-commercial users.</p><p>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.</p><p>4.2. Software</p><p>4.2.1. The ser6erOur choice of a HTTP-server was the Apache</p><p>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.</p><p>4.2.2. CGI scriptingThe ability to handle CGI scripts was, as men-</p><p>tioned above, critical. CGI scripts provide amethod of extending a HTTP-servers 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.</p><p>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</p></li><li><p>T. af Klercker, M. af Klercker : Computer Methods and Programs in Biomedicine 55 (1998) 313734</p><p>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 PLs. This enables the deci-sion support system to be ported, with minimumeffort, to a large number of different platforms.</p><p>4.2.3. File format and generationThe HTTP-server responds to client requests</p><p>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.</p><p>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</p><p>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).</p><p>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.</p><p>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:</p><p>[]133node:Vertigodiagnosis:12frequency:</p><p>14452node:Otitis mediadiagnosis:4frequency:</p><p>[]</p><p>The generating script then combines these twodifferent files to generate the files used by theserver (the above example would result in two</p></li><li><p>T. af Klercker, M. af Klercker : Computer Methods and Programs in Biomedicine 55 (1998) 3137 35</p><p>files, node 133.html and node 14452.html, re-spectively). The two actually represent the totalamount of information storednot only infor-mation but also sequencing. The same files arealso used to generate the path history on eachpage.</p><p>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 deman...</p></li></ul>


View more >