System Semi-Autonomous

(1)

(2)

St.John 's

A Semi-Autonomous On-Line Chemotherapy Prescription System

by

©Syed Naqvi

A thesissub mittedto the SchoolofGraduateStudies in partialfulfilmentof the requirements for thedegree of

Masterof Science

Departmentof ComputerScience Memoria lUniversityof Newfound land

October 24, 2007

Newfoundland

(3)

(4)

Abstract

To advance thecauses of reducing medical errors and improving the quality of patient care,healthcare is currently going through a periodof vast reforms. CPOE (Computerized Physician Order Entry) is one such reform. An important example of CPOE is drug prescription,both of individual drugs and complex regimens,e.q., chemotherapy. By reducing medication errors,CPOE can both increase the quality of patient care and decrease cost. Several types of problems may arise during the design and implementation of CPOE systems. The most obvious of these problems are due to insufficient attention being paid to the nature of existing manual clinical workftows.

Muchmore damaging are subtleproblems related to insufficient attention being paid to the nature of the clinical workplace-in particular,the frequent lack of resources, e.g.,system administratorsand programmers, for ongoing system maintenance and evolution after the system is deployed.

In this thesis, we will describe the development of an on-line chemotherapy pre-

scription system in which many aspects of system maintenance and evolution can be performed by the system'susers. The user-guided operational model underlying this system overcomes many of the problems arising from limited system maintenance and evolution resources in the target workplace. This thesis will also include several discussions of various lessons learned during the development of this system that are applicable to the development of medical informatics systems in general.

(5)

List of Tables

2.1 Types of System Operational Models

4.1 Single User Design Table.

4.2 Multi User Design Table

32

67 103

(11)

List of Figures

3.1 Workflow Diagram: Manual Chemotherapy Prescription Process . 43 3.2 Workflow Diagram: Computerized Chemotherapy Prescription Process 47 3.3 Screenshots: Meditech - (a) Patient Profile (b) Finding Patient. 49 3.4 Farrell Version 1 - Sample Prescription Page.. . 52

3.5 Farrell Version 2 - Sample Prescription 53

3.6 Farrell Version 2 - Sample Prescription (Cont'd) 54 3.7 Farrell Version 3 - Sample Prescription Input Page . . . .. 56 3.8 Farrell Version 3 - Sample Prescription Output Page 57

4.1 Workflow Diagram: Login/Logout. 4.2 Screenshot: Login .

4.3 Workflow Diagram: Patient Search by MCP Number 4.4 Screenshot: Patient Search Page . ...

69 70 72 73 4.5 Workflow Diagram: Patient Search by Demographic Information. 74

4.6 Workflow Diagram: Prescribe Regimen. ... 76

4.7 Screenshot: Sample Prescription Input Page 77

4.8 Screenshot: Sample Prescription Output Page 78

4.9 Workflow Diagram: Add Patient to Database 81

(12)

4.10 Screenshot: Add Patient to Database. .. . . .... 4.11 Workflow Diagram:Create New Regimen.

4.12 Screenshot:Create Regimen - Regimen Name 4.13Screenshot: Create Regimen - Chemo Drugs Details . 4.14 Screenshot: Create Regimen - Antiemetic Drugs Details.

4.15 Workflow Diagram: Alter Regimen 4.16 Screenshot:Alter Regimen - Regimen Name 4.17Screenshot: Alter Regimen - Cherno Drugs Details.

4.18 Workflow Diagram: Manage Regimens 4.19Screenshot: Manage Regimens.

4.20Workflow Diagram: Add New Chemotherapy Drug 4.21Screenshot: Add New Chemotherapy Drug ..

4.22 Workflow Diagram: Password Retrieval.

4.23 Screenshot: Password Retrieval . 4.24 Workflow Diagram: View Patient History.

4.25 Screenshot: View Patient History .

4.26 Workflow Diagram: Import Regimen 4.27Screenshot: Import Regimen.

4.28 Workflow Diagram: Add Proposal.

4.29 Screenshot: Add Proposal - Change Emetogenicity Potential 4.30 Workflow Diagram: Vote Proposal.

4.31 Workflow Diagram:View Proposals . 4.32 Screenshot: View Proposals 4.33 Database Entity-Relationship Diagram

82 85 86 87 88 91 92 93 95 95 97 98 100 101 105 106 108 109 113 114 117 118 119 121

(13)

5.1 Spiral Development Model . 129

(14)

Chapter 1 Introduction

1.1 M ot ivat ion

Almost all activitiesinvolvedin theprocess of improving apati en t' sheal th are initi- atedviaawrit ten orde r by aphysician .This orde r isusu ally aprescrip ti on,which includesinstru cti onsfor administe ring medicati on,or different tests for diagnosti c purposes.This initialstep orent ry point for theprocess of patient care iscruc ial, as theent irecare processisdepend ent on it .In par ti cul ar,aminormist akein prescribing,e.g.,mist akesin dosage or frequ ency of medicat ion,cancausesevere problems, orinthe worst case thiscould resultinthe death ofthe pati ent. Hence,physicians arerequir edto beverycar efulwhilewriting such prescriptions.

In 1999,arepor tby the Insti tu t e of Medicine,"To ErrIsHuma n"[36],cite d much evide ncetoindicat e that intheUnite d St ates alone, prevent abl emedi cati on errorsare involvedin44,000to98,000death sper annum(a grea te r deathtollthandeathsdue to suchfear edthreats asbreast cance r, motor-v ehiclewrecks,and AIDScombined)

(15)

andcost $17to $29 billionper year. Thisrep ort andothers haverenewed efforts toapply information technologyto clinicalworkflowinorde r todecreas emedi cation errors . Studieshaveprovedthattheintroducti on ofa compute r in clinicalworkflow cansignificant ly redu cemedi cati on erro rs[61,43]. The successf ul intr odu cti on ofa comp utersyste m,e.g.,CP OE(Compute rized PhysicianOrderEnt ry), cancause not onlya decrease in medicati on errors,butalsoenhance workthro ugh many aspects, e.g.,redu ced cost,standa rdizat ionofcareand improved efficiencyofcare delivery [37, 59].CPOE syst ems are remarkablyhelpfulin redu cingprescriptionrelat ed errors, wher eprescriptionwritin ginvolves complexcalculat ionsof dosage.Thismoti vat es the developm en t of prescrip ti on systemsthatcanbehelpful in makin g the prescription processmore accurateand improving the quali ty of pati en t care.

Such compute rizat ion isdesirabl e;however , thereare knownproblemsthat occur duringthedevelopm ent of these systems,suchasinattenti onto the clinical workflow.

Theseproblems can be severeenough that theresultingsyst ems are oftenreject edby physicians.Ifthe promises ofcomputer izat iongivenabovearetoberealized , these probl emsmustbe dealtwit hdur ingsystemdevelopment.

1.2 Objectives

Given the prescriptionproblemdescrib edin moti vati on , aswell asknown probl ems wit h implem entin g compute rizedsolut ionstomedicalinform ati csingenera l,this thesis has two mainobjectives:

1.To developa restricte dCP OEsystem for thechemot he ra py prescrip ti onprocess.

(16)

2. To present a number of lessons learned during the developmentof such a system that are also relevant to medical informatics in general.

In the process of developing the required system,we have discovered what we think is a gap in current software engineering theory and practice. This gap is related to the assumptions that are made in software engineering practices and the actual operation of the system both in terms of maintenance and evolution after deployment. Given this gap, we also have a third objective of this thesis,to describe this gap and propose a solution.

The reader should note that though software engineering techniques are used extensively in the design and implementation of this system (and the description of this design and implementation),this thesis is not intended as a software engineering thesis. Rather, it is intended as a contribution to medical informatics, as both a demonstration of how a particular kind of system can be developedand the general lessons that should be learned from this development process.

1.3 Contributions

The major contributions to this thesis are as follows:

•A detailed workflow analysis of the chemotherapy prescription process: This workflow analysis was gathered by repeated weekly conversation with Dr. Far- rell, under the Spiral software process development model (see Section 2.3.2.4).

These conversations allowed us to gather workflow not only because Dr. Farrell was a chemotherapy prescriber himself, but also because he was the developer of

(17)

many of several previous chemotherapy prescription systems (see Section 3.3);

hence, these conversations access the experience of not only Dr. Farrell, but all users with which Dr. Farrell himself interacted in developing his previous systems.Similarly the workflow was also validated through these conversations with Dr. Farrell (and hence also indirectly validated with the other system users that Dr. Farrell talked to while developing his previous systems).

•A set of software development guidelines for medical informatics:These guidelines are encoded as various lessons learnedduring this project and are listed at the end of Chapters 4, 5, and 6. We are aware that many of these lessons are common sense in the software engineering community; however, it is still of interest to list such guidelines here because these have particular importance in medical informatics.

•Addressing problems of post-development system operation in medical infonnat- ics:This involved developing what we believe to be an original classification of post-development system operational models (see Section 2.3.3), and explain- ing why certain medical informatics systems such as~hemotherapyprescription operate under a model that is not currently addressed in an adequate fashion by software development practice. We also propose a solution to this problem in the form of a democratic model of system operation (see Section 4.2.1).

(18)

1.4 Organization of Thesis

In Chapters2 and 3, we describe the general problems with medicalinformatics software and look in detailat the prescription process, particularly as it relatesto chemotherapy.

• In Chapter 2,we willdescribe different types of medicalsoftware/tools(Sec- tion 2.1), problemsthat arisewhiledeveloping them, andpossiblesolut ionsto thoseproblems(Section 2.2). We willsee how software techniquesarehelpful in developingmedicalsoftware (Section 2.3).We will discuss how the operation of software afterits developmentis important to considerwhile developing any software. We willdiscuss in detail the different softwareoperationalmodels defined in terms of software evolutionand maintenance(Section2.3.3) .We will discuss whichsoftware process modeland system operationa lmodel is appro- priatefor the development of medical systems (Section 2.3.5).

•In Chapter3, we willdiscussin detailboth CPOE (Section3.1)and chemotherapy prescription(Section 3.2) as a restricted form of CPOE system. We willalso examine different problemsfor the development of sucha system thatare introduced due to thelimit ed resources availab lefor themaintenanceandevolution of a medicalsystem during its operation.Finally,we will look at theprevious work that has been done toimplement chemotherapy prescriptionsystems (Section 3.3).

In Chapters 4, 5, and 6, we will look at the design, development,andimplement at ion of a chemotherapy prescription system. Note that at the end of eachof thesechapters,

(19)

asthis thesis is on medicalinform ati cs,we willgive in-depth discussions ofthespec ific lessons we draw for developingmedical informat ics softwarein general.

•Incha pter4, we willdiscussthe design of a chemotherapyprescript ionsystem.

We will descri be theobjectivesofthesystem (Section4.1),andit's twokey features(Section4.2),relate dtouserint erface designandanewlyprop osedmodel ofsystemoperation,whichwe callthedemocraticmodelof systemoperat ion.

We identifysystemobjects andclasses (Section4.3) ,andbreakthe design of thesystem into single-use r(Section4.4) and multi -user(Sect ion4.5)features.

Fina lly,we will describe thedatabase schemafor thesystem(Sect ion4.6).

•InCha pter 5,we will look at differenttechno logychoices,i.e.,developm en t fram ework ,IDE,dat ab ase andwebserver,thatweremad e forthedevelopme nt of ourchemot hera pyprescr ipt ionsystem.We willseehow thechoiceoftech- nologiesfordevelopment ofsoftware is affectedinthecase ofmedica lsoftware.

•InCha pter6, we willdiscussthe different systemimplem ent ati onmodelsde- scribingdifferentways to get softwareacceptedina targetworkpl ace.vVe will discuss the differentfactors that affecttheacceptanc~of medica lsoftwa re/tools byhealth care.

Fina lly,inChapter7, we willprovide conclus ionsandalist ofdirect ions for fut ure research.

(20)

Chapter 2 Background

In thischapte r,wewill review different background topics for thisthesis. These includ e genera l descrip tions of the typesofmedicalsoftwa re(Sect ion 2.1),different problemsinvolvedinthe developm en t of medi cal softwareandtheirsolut ions(Sect ion 2.2),andadescription of softwa reengineeringtechniques(Sect ion 2.3).Thelatt er includes not onlystanda rdtechniquessuchas thesoftware processmodel (Sect ion 2.3.1),but also includes thesoftwareoperat iona l model (Sect ion 2.3.3),whichis of parti cul ar concernto thesystem develop edinthisthesis.

2.1 Medical Software

Modernhealth car e orga nizat ionsare designed andstruct ure d to enhancetheeffi- ciencyof health car e.Theintrodu ction of inform ationtechn ologyinto health car e can greatlyenha ncethe process of quality patientcare.Alongwith the basic effectsof int rodu cin g compute rsto any workflow,i.e.,costredu cti on and increased timeeffi- ciency,compute rizedworkflowcan redu cemanyflaws attachedtomanu alheal th care

(21)

workflow,which areexplained laterinthis secti on with referencetodifferent typesof medi cal syste ms.

However ,heal th car e orga nizat ions have given lit tle attentio ntotheintrodu cti on ofcom pute rs to clinicalworkflow [14,45].Ifwe explorethecausesofsuch inatt ention totheclinicalworkflowfurth er ,wewill discovermanyimport an t and interestin gfact s about health car eorganiz ati ons.Theclinical environment isdifferentfrom any oth er workenvironment, becauseof theuniqueness andcomplexity which arisefrom the typesof services,complexity of services,and motives behind theservices it provides.

Thesefactors arefurtherela bora te d later in this section.

Thereare many typesof medical systems, which are design edfor useby different user communit ies. These communit ies include single doctor s,smallgroups of doctors , and lar gegroupsof doct ors.To exam ine past efforts for the det ails of successes and failur esinanat te mpttoimplem entdifferent typesofelect ronic medi calsyst ems,we havedivid edsyst emsinto three levelsdep endin g onsystem function alit y and typ eof user community. Whenwediscuss eachtypeof syst em ,wewill describ ewhat that syste m does,thepoten ti al advantages it has , and wheth er or notit hasbeen a success in thepast in the USAand Can ad a.

2.1.1 Data StorageSy stems

These syste ms includeElectronicHealthRecords (EHR) and ElectronicMedical Record s(EMR).Accordin gtotheHIMSS ElectronicHealthRecord Committee,EHR isdefined as asecur e,real time, point- of-car e,pati ent- centri cinformationresour cefor clinicians [30]. An EMR is concept ua lly differentfrom an EHR, as an EMR is theac-

(22)

tua lcompute rizedclinical recordin different hospita lsand physician'soffices, whereas an EHR isdesignedto sha re dat a among different EMRs [27].EHRsare relian t on EMRs beingin place and EMRscan never reachtheirfullpotent ial with outEHRs.

In bothkinds ofsystems, pati entdat afrom differentsourcesis stored indat ab asesto makeitavailable toclinicians.Thisdat a can bescann edimages of pap erdocum ent s, diagnostic images,orothertypeof medi caldat a relatedtopati ents.EHRs and EMRs aredesigned formanyuses,fromindividu al clinicswhich have single-user EtvIRs to hospit allevelEMRs,whichmayhavedozens orhundreds of users .Hence ,EMRs and EHRscover abroad spect ru mof user comm unit ies.

A reportbyHIMSS on EMRsand EHRsestablishestheirabilitytoimprovepati ent care in thefollowingways[30]:

1.Help ing to reduce medical errors.

2. Makin g accesstopati entdat afast er.

3. Providin g remoteaccess todat a.

4.Allowingthesharin gof dat a amo ng differentclinician s.

Despite thepotentialofEMRs andEHRsto makecont ributionsto the improvemen t of health care qua lity,significant initi ativ es and stra tegies toimplem ent them inthe pasthave causedonlyarelati vely sma ll number of sites inNort h America touse them.In1991,the Inst itu te of Medicine(10M)[50]proposedtohave compre hensive implem ent ation of EHR intheUS over aperiodof 10years. However , afte r 12years, no moretha n 17-25 percentof themedi cal user comm unityemploys EHR[32]. Like theUS,Canadais alsofarbehindin introd ucingcompute rs inthe health car e.In

(23)

Canada,major steps to introducenation-wideEHR weretakenthrough amulti- million dollar investm entbyInfoway,fundedbythefederal govern me nt. Infoway [15]

isanot for profit organiz ationwhich aims to put an interoper abl eEHR intoplace across 50 percentof Canad a (by population )bythe endoftheyear 2009. However, areportby Infoway statesthatabout 91 percentof physiciansarestill using pap er recordsand/orprescribin gusing paper[14].

2.1.2 Analytical and Decision Support Systems

Analyticaland decisionsupport tools are designedto helpdoctors in making critical decisionson patienthealth.Analyticaltools areusedto accesslargetransactional datas etsby various datamining techniqu es.Theresults ext ract ed using thesetools can thenbevisualizedusingdifferentknowledgerepr esent ationmethods. Thesetools can beused broadlyto find theusefulpatternsin healthdatawhich can helpin improvingpatientcare,e.g.,ana lyt ical tools to findadverse drug events. Analytic al toolsmayalso beusedfor visualdataanalysis or imageprocessing [53]. A clinical decisionsupport systemis anysystem that helpsin makingdiagnosticdecisionsfor pati entcare[67].Bothanalyt ica l and decisionsupport syst emsaretypically focused systems ,aimedat singleusersor smallgroups of users .

Work on clinicaldecisionsupport systems originated in the 1970s,whensystems suchas the de Dombals Leedsabdominalpain system[23] and the MYCINsyst em [80] for selectingantibiotics,weredevelop ed .In 1999,Perr eaultand Metzgeroutlined thekeybenefitsof clinicaldecisionsupport syst ems[56]:

1.Supporting clinicaldiagnosis and treatm en tplanprocesses.

(24)

2. Promoting the use of best practicesin patientcare .

3. Helping with cost reductionby reducing medicationerrors, and helpingto avoid duplicate and unnecessary tests.

Unfortunately,decisionsupportsystems are underusedin a manner similarto that seen with data storage systems. For example,a reportby the Joint Clinica lDecision SupportWorkgroupconcludedthat clinicaldecision systems are stillused onlyby minor ity of physician in theirpractice[77].

2.1.3 Computerized Physician Order EntrySystems (CPOE)

Order entry systems,such as Computerized Physician Order Ent ry(CPOE) areone level above EHR/EMR.Such systems are designedon top of physicianworkflowand are used to assistphysiciansin accomplishingpatient-re late dtaskssuchas ordering tests and prescribing medications.The purpose of such systems is mainlyto prevent medication errors that are related primarily to prescription writ ing. Suchsystems may have additionalfeatures such as decision support,patient safety features such as real-timepatient identification, and billing.CPOEis primari lydesignedforuse by singledoctors,though a CPOE system may serve a groupof doctors.

Successful order entry systems are guaranteed to improve healthcare in the following ways [9, 20,38, 60]:

1.Reducing theprescription errors that areinherentin writingprescriptions which involvecomplex calculations,such as chemotherapyprescriptions.

2.Giving direct access to patient data and history.

(25)

3. Removinginterpr et ationof illegiblehand-wri t ten orde rs fromtheworkl oadfor nursesand pharmacists .

4.Providing quickerturnovertimefor medi cati ons.

5. Making data morereadily available for otheruses such as research. Thoughthe conceptof order ent ry systems is veryold,and resear chhas provenits effect iveness inimproving clinical processes [9, 20, 38,60], it remainsunderused in healthcare.Indeed,in theUS and Canada, theuse of CPOE is evenlower thanthe use of EHR/EMRdescrib ed earlier in the section.In theUS,out of 17-25 percent of usersof EHR,onlyabout 9.6 percentuse some kind ofelect ronic ordering system , whichmay include elect ronic prescribingorelect ronic labtestordering[21].Similarl y, in Canada,lessthan 5 percentof physiciansuse elect ronic ordering systems[14]. As order ent ry systems ,and specificallyComputeriz edPhysicianOrder Entrysyst ems , arethesubject of thisthesis,they are discussedin moredet ailin Section3.1.

2.2 Developing Medical Systems: Problems and Solutions

In the previous sections ,wehavelooked into differentmedicalsystems shownto be helpfulin improvingtheprocessof patient careand notedthat despitethebenefits of suchsystems, their usageislow.Ifsuch systemsare guarantee d to improvethe qualit y of healthcar e,butare notwidelyused ,then there mustbefactor sinvolvedto preventtheiradoption. In this section, wewillexplorethe problemsunderlyingsuch minimaluseof medi cal systemsandtha t must , therefore , betakeninto considerati on

(26)

when designing medical systems.We have divided these problems into two categories:

system development problems (Section 2.2.1) ,which affect the development of a medical system, and system operation problems (Section 2.2.2),which arise during the use of a system after development.

2.2.1 SystemDevelopment

In this section we will identify and briefly explain the different problemsthat arise whilechang ingfrom a manualmedicalsystem to an electronicmedicalsystem.We will also discuss how these problems have affected the introduction of medicalsystems in health car e and how (ifat all)they have beenaddressed.

2.2.1.1 Importing LegacyKnowledge

In order to makelegacy data readily availableto physiciansin new electronicsystems older patient data must be added to electronicpatient records. Thisaddit ionof data can be expensiveand difficult,as it may include scanningallpaper records into an electronic form. This transfer of data from paper to a scanned digital format needs carefulattentionto ensure thatall necessary detailsare transfer redsuccessfully.

Unfortunately, research has shown that many physicians find patient data hard to understand ina scanned digitalform, whichcausesthemto revertbacktomanu al systems [39J.Importing patient data is also difficult as it involvesthe assimilation of medicalknowledgefrom differentsources into the new system.Thesesystems are often further complicated due to the use of specific medicalterminology,as systems which use non-standardmedical terms are likely to be rejected by the users.

(27)

Scanning old pati en t recordsandaddingthemtonew systemsshould be considered onlyas an int erm edi at e steptowards developin g afully elect ron ic medi calrecord [39].

Thisstepnot only elimina testhe problem ofslow processing and rigidstru ctur e inscanned documen ts ,but also makesthe elect ronic dat amorereadil y available for sharin g, administ ra tive,and resear chpurposes.However ,inorde r to preventthe possibilitiesoferrors involvedin themanual addit ion of dat ato adatabase,necessary validitychecksarerequir edtoensure the corre ct ness of thedat a.Moreover ,to deal with theproblem of usageof medi calterminology,it is important to work in close collaborat ion with the act ua l usersof thesystem ,i.e.,physicians ,who will beobliged to work with themedic alterminol ogies employed by the syste m.

2.2.1.2 Interoperability

Int erop erabili tyisan import an tissueif we aretomergedat afromdifferentsour ces tomakeit available for sha ringamongthe users ofthosesources . Moststa nd-alone medi calsyst ems are developed and tar get edforaparti cul ardepar tm entorhospit al and lackanyshared convent ionsof datawithothersources. This restri ct slarge amounts of medi caldata toonlyone medic alsyst em at atimeand rendersthat dat a uselessto other syst emsthat could benefitby sharin git [24,42].

In orderto makedat a availa ble forsharing from different sour ces it is necessaryto standardiz emedicaldat a.There are manystandards , such as HealthLevel 7 (HL7) [31], that can beintroduced as guidelines toena ble the excha ngeand interop erability ofelect ronic heal threcord s. HL7 introdu ces a setof"ru lesofconversa t ion" that enab le differen t systemsto communicate pati en t-cen tri cdat a.In Can ad a,Infoway, whichhasinvestedmillions ofdollars provid edby the Can adi an govern ment, has

(28)

establishedaset ofguiding principl esforinform at ion standards. Infowayis also lever agin gHL7 messaging, which is standardthro ughoutNorthAmerica[24].

2.2.1.3 Legal Issues

There are man ylegalissuesinvolvedin useof EHRandelectro nic prescribin gsystems, which make the developm en tprocessmore complex.Privacylawsmakeitdifficul t to sha re data among theusersofelect ronic healthdata, i.e.,theperson aldat a of apati entor thehistoryof hismedi calrecordis not allowed to beopenforgenera l accesslikeresear chwork orad minist ra tive usewithout theconsent of thepati ent . For example,under the Food and DrugRegul ati onsinCanadaapharm acyisallowed tofillonlythose prescrip ti ons thatareorde red byphysicianinawritt en or verb al form. Food and Drugregul ati on states: "C.01.041(1.1)Subject toC.01.043and C.01.046,noperson shall sella substancecontaining a Schedule F drug unless(a) thesaleis madepursuant to a verbal or written prescription receivedby theseller;"

[41]. Moreover , therearemany hurdlesrelated to thecreat ionofand main tenan ce of medi calrecord s which make the developm en t and main tenan ceprocessmore complex . To overcometheprivacyprobl em ,weneed todealwith the privacy of pati ent s and medi calprofessionals verycarefully.Within the health car einformation syste m, there is anemerging needto ensure thesecurit y and integrit y of healthcaredata while maint ainin gpati entprivacy.A relati onaldat ab aseisa goodsolut ion to problemsre- lated toprivacy andsecur ity issu es,wheredata can be stored in tabl es and limit ed access can be gra nte dto eachpersonaccord ingtohis/ herprivileges.Moreover , to enha nce privacy,field protectioncanbe appliedto tablestorestri ct access toindi- vidua lcolum ns. Tomake data availab le forresear ch,we canuse varioustechniques,

(29)

suchasdata anonymisatio n,to preserveprivacy [75].

Inaddit ionto suchtechnicalsolut ions,we canalso deal withlegal issues by developing legislati on thattakesintoaccountthe specific concerns ofhealth informatio n.

For exa mple,apossible solut ionto the legal issues involved in electro nic prescri bing hasbeenproposedby theNationa l Associati on ofPhar macyRegul atoryAuth ori ti es (NAP RA),which has developedgenera l recomm end at ionsfor thcsafeandeffective tran sfer of prescriptionsbetweenprescrib ers and pharm acist s.Theyidentifyfiveprin- ciples that should bemetfor safe transferofelect ronic prescriptions ,whicharealso supporte d bytheHealth Canadas Therap eu t icProdu ct sProgramm e (T P P)[51]:

1.Theprocessmustmain t ainpati ent confident iality.

2. Theprocess mustbe ableto verifytheauthent icityof the prescrip tion ,i.e.,that the prescri berisiniti atin g theprescrip ti on .

3. The system must be capab leof validat ingtheaccuracy ofthe prescrip ti on , and the processmustinclud e a mecha nismto prevent forgeries.

4.Pati ent choice must be protected;that is the pati entmustdet ermin e the prac- tit ionertoreceive the prescription aut hority.

Legalissueswithin many otherareasof healthinform ati cs could beresolvedby similarl y struc t ure d legislati on. Inanycase, such issues are not cur rent ly handledby softwareengineering meth ods and probabl y will notbehandl edin futur e;hence, theywill notbe add ressed inthisthesis.

(30)

2.2.1.4 Social and Organizational Issues

Modernhealth car e orga nizat ionsareconfronte dwit h new clinicale-hea lt htechnolo- gies as neverbefore.Earl y evide ncesuggests that theadopt ionof newmedical soft- war e/toolsdep endsin largeparton their accepta nce bybothhospit albureau cracies and bydoctors.This acceptance must take into accountvarioussocialandorga niza- tiona l issuesrelated to the behavior of doct ors andburea ucrats within the hospi t al environment. Theseissues and behaviors arediscussed extensively in[49].Thefol- lowing conde nsessome ofthe main pointsin thatdiscussion , and dividestheseissues into twocatego ries: bureau crati c and physician .

Hospit albureau cracies showthe followingbehavior towards the adoption of new software/ too l:

1.The ap proval pr o ce ss : Itisverydifficul tfor amedicaltool tobe approved byhospi t albureau crats. Thisisprimaril ydue to caut ionabout adopti on of newtoolsbecause aminor erro r inthose tools could harmpati en tshealth and evencause deaths.Moreover ,thebureaucracy also hastoconsiderthe complex secur ityand privacyissuesassociat edwith the adopt ion of newsoftwar e.

2. Limit edIT resou r ce s: Manydevelopm entproblemsarisebecauseof limited hospi t alIT resour ces.Forexa m ple, thedevelopm entofsome databas e-enabl ed tools mayrequir edat ab ase administ rat ion,but ahospit al 'sIT departmentmay nothave any dat ab aseadministr ationpersonn eltospar e.

3.Preferencefor existing tools: Ashospit albureau cracies trustonlyexist ing tools,theyask fornew tools/so ftware based on,andthussimilar to,those tools.

17

(31)

This similarity fallsintwocategories:

• Look and feel: Hospi t albureau cracies insistthatnew tools use thesame interface as exist ingtoolsor,inthecase ofapap er-b ased system,they requir enewtoolsto have thesame input and displ ayform at asthat syste m.

• Underlying technologies: Bureau crats are more comforta ble usingnew tools which are based ontechnologies thatthey are alrea dy famili arwith.

Doct ors showthe followingbehavior towardstheadopt ionof new tools/software :

1.Need for familiar look: Eveniftheyagree tousenewtools,doctor sneed these toolsto have same interface and look as toolswit h whichtheyare alrea dy famili ar ,i.e.,theinterface of the oldsyste m.

2.Difficulty in extracting workflow descriptions: Dueto thebusysched- ulesof doct ors,itis somet imesvery hardto getusefuldescriptionsof clinical workflowfromthem.Thismayresul tinthe developm entofasyst emwithin- sufficient informati on aboutthetarget workplace and users ,leadin g toafailur e ofadopt ion.

3.Cannot be compelled to change: Doct orshave aresp onsibili tytopati ent carewhichtheyalways main tain aspriorit y.Hence,no onecancompel them to adoptanew technology which they donotfeel serves thatpriori ty.

Thislastbehaviorispar ti cul arl yimport an t,becauseithighlights a cruc ial difference bet weentherelati onship of doctors andtheadminist ra t ion in hospi t al and there- lati onshipbetween emp loyeesandtheadminist rat ion incompa nies. Ina compa ny,

(32)

the workers are employees of the company and can be compelled by the administration to make any change related to work. However, the relationship between doctors and hospital is not so much that of employees but rather that of private contractor;

therefore it is much more difficult to compell doctors to make any changes requested by the administration.This difference in relationship has implications for software adoption. In an ordinary company workers can be told by the administration or IT department to adopt a new technology,while the successful development of medical tools/softwarerequires that doctors and administrators both see the benefits and hence agree to adopting a new technology.

The problems that occur during the development and acceptance of medical systems due to social and organizational issues that are specific to the medical field have been given very little attention in the past [40,59]. This inattention was a cause for the failure of many medical informatics systems, where either physicians refused to accept new systems or stopped using medical systems to protest against them, e.q.,the Cedars-Sinai hospital uninstalled a multimillion dollar system as physicians stopped using it [40]. There is not really an effective solution available in software literature to overcome these problems,but it is recommended that designers involve physicians in the development process as much as possible. This is related to the issue of physician champions in medical software development, which will be discussed in more detail in later sections of this thesis.

(33)

2.2.2 System Operation

We have discussed many development problems and their solutions in theprevious section. Let us now consider the problemsthat are associated with system operation.

System operation is concerned with the issues relatedto short,mid, and long term system evolut ionand maintenance,i.e. ,what a system does afteritisdeveloped . Here,issues relatedto maintenanceare how system changes that arise from theday todayusage of thesystem,e.g.,addinga new users to system, are handl ed . System evolut ionisrelated to theneed for cha nge inthebasic designof a systemthatarises after using thatsystemfor along period oftime. For example, inthecase of a chemot hera pyprescr iptio nsystem,if thebasicmethod of prescribingchemot herapy drugs is cha nged,it willcause a need for a corresponding changein thedesign of the system. Theseissues are especially important for systems whicharedevelopedfor a longer period, making it more likely for these issues to corne forth.

Thoughsystem operation issues occasionally come upin softwaredevelopment, they arenot satisfactorilyaddressed in software engineeringliteratur e at present.

Thisis particularlyunfortunateforus, as many medicalinformatics systems arelong lived and face these problems. Thiswillbe discussed in more detail inSection2.3.3.

2.3 Software Development

From Section2.1and Section2.2, we see that medicalsoftwarepresentssome in- terestingdevelopmental problems . Here we willanalyzetheseproblemsinterms of two components of the software development process, the software process modeland the system operational model, and we will see how appropriate software engineering

(34)

techniques can help us to solve many of the problems arising during the development of medical informatics systems. In this section, we will briefly describe what each model is (Section 2.3.1 and 2.3.3), and the types of each model (Sections 2.3.2 and 2.3.4). The discussion of types of system operational models (Section 2.3.4) is particularly detailed, as this is not, to our knowledge,adequately addressed in the software literature. Finally, in Section 2.3.5,we discuss which software process and system operational models are most relevant to medical informatics.

2.3.1 What is a Software Process Model?

A software process model may be defined as a simplified description of a software process which is presented from a particular perspective[69]. In other words, we can say that a process model is a plan of action for a large and complex software development,which includes a clear statement of what is required and the different tools,steps and series of steps, required to successfully implement a software product [10, pp. 21-22].

In the early days of computers, software development was still evolving.Because projects were small, the programmers' own defined ways-ofdevelopment were sufficient to produce successful software. The most common way to develop software was to write code and then test it, and came to be called the build and fix model.

With the passage of time, software projects became more complicated and difficult to develop with traditional programming techniques due to lack of knowledge about the software implementation.To overcome this problem new development models, also called software development paradigms, were introduced to cover the whole software

(35)

developm en tlife cycle. Thesemod elsinclude a compre hensiveguida nce toward s the developm ent ofsoft ware .

A model, alsocalled thelife cycleofaproj ectdevelopm ent , consist s of differ ent phases ,which can ran gefrom three (fora simple model,includingDesign ,Develop- ment , and Maint en ance)to morethantwent yphases.However ,mostof themodels include the phases of Requir ement ,Design ,Implem ent ation ,Testin g,Deploym ent , and Main t en an ce.Differentprocessmodelsincludedifferentiter ati ons andorders of thesephases,whichmake themsuita ble forpar ti cul ar circumsta nces. Hence,the selection of anappropria te modeldepend s on thenatur e of theprojectand itscon- st ra ints.

2.3.2 Types of Software Process Models

Today,wehavemanysoftwareprocessmodels , allof whichare act ua lly variationsof four traditional soft ware models.

2.3.2.1 Waterfall Model

Thewat erfallmodelwasintroducedbyRoycein 1970and isalsocalled thelinear sequential model [63].In thismod el the followingphases arecomplete d in order.

1.Requir em entSpecificati on

2.Design

3. Implemen t ati on

4.Testin g

(36)

5. Deployment

6. Maintenance

In the Waterfall model one should only move to the next phase on the completion

of previous phase. There is no jumping back and forth, and there is no overlap between the phases.In spite of the fact that the system being developed is always well documented from the very beginning of the process, one of the main disadvantages of the Waterfall model is that not every part of the product is available until late in the development process. Thus, if mistakes or deficiencies exist in the documentation or earlier phases, they may not be discovered until the deployment of the software.

Hence, correction must often be done in the maintenance phase. Because of its sequential nature, the Waterfall model is not applicable when the requirements are not clear and well understood at the start of the project. Moreover, in the Waterfall model the actual participation of the end user is negligible, and only the final version of the product can be delivered to users, which makes it unavailable for comments by the client in earlier stages.

2.3.2.2 Incremental Model

The Incremental model was introduced in 1975 by Basili [8].The Incremental model is a series of waterfall cycles, where the requirements are known at the beginning and are divided into groups, and the initial group of requirements is fulfilled at the end of a series of several waterfall builds. Hence, this model can get evaluation from the client by showing a working part of software after each cycle, which can allow both alterations during development and the addition of new requirements during

(37)

the implementation of the system. In the Incremental modela usable product is available after the first release,and each iteration results in additional functionalities for the product.However,in this model,users are required to learn the new system developed in each cycle. Thus,the Incremental model is beneficial for projects where feedback is necessary from customers at early stages of project development.

2.3.2.3 Prototyping Model

This model, also called the Evolutionary model,was introduced by Floyd [26] and simply refines the prototype system in each iteration. Working software is built in the first iteration and then refined in later subsequent iterations. The specification, development, and testing phases are carried out concurrently. Rapid feedback is made possible by adding customer evaluation in each cycle. The final system will accurately fulfill the user needs; however the project is often started without full knowledge of requirements and thus needs greater coordination with the user.

2.3.2.4 Spiral Model

The Spiral model was defined by Boehm in 1988 [12]' and!s recommended for high- risk projects where the requirements must be refined and the user's needs must be met. The Spiral development model involves incremental builds which identify areas of risk and decide how to overcome and eliminate chances of risk via the validation and verification of the project in each iteration or build of the product.As such, it is obvious that the Spiral model combines features of the Waterfall,Incremental, and Prototyping models,and hence provides a great deal of user involvement and risk management.Ifwe compare the Spiral model in more detail with other models,

(38)

itsdistin cti vefeatur eis that itdeals wit htherisksanduncert ain ti esinvolvedin softwaredevelopment . The Spira l model explicit lyrecognizes thefollowingrisksand uncer t ain ti es [10]:

1.Duringlongdevelopmen ts, the users are neglectedin theprocess ofgathering their requir ement s.

2.Theusersrequ irements aremisu nd erstood.

3.Theusers cha ngerequirements.

4.The targethard ware configurationcha nges.

Thedisadvan t age of using theSpira l modelis its complexityandgreate rcost.How- ever, giventhe high riskassociated wit h medical software,this is the preferr edmodel for med ical systemdevelopme nt(see Section2.3.5formorediscussion ).

2.3.3 What is a System Operational Model?

Asystemoperat iona l modelis a descript ionof theshorttomidt ermmaint enan ce andevolut ionrequire mentsfora givensystem.Here,system mainte na nce is support that is availab le for theoperation of a system,whichcouldeither be support from thedeveloperof thesystemor sup portby the system administ rato r, whois availab le onsite or cont ractedto performdifferentactivit ies necessary for suchsystemtokeep them up andrunning . Systemevolut ionishow system requir em ents evolve inthe short tolong termduringa system'soperation.Bothmaintenanceandevolut ionare changes to thesystemthatrequireresources;hence,system operat iona lmodel is the

(39)

descrip ti onthatinclud esnot onlythe natur e ofmaintenan ce andevolut ion but also takeintoaccount theresourc esthatare availabl etomakethose changes.

Howare syste m maintenance andsyste mevolut iontypically handl edinsoft ware enginee ring? Theusu al approac h is to assumethat therewillalways be sufficient resour cesfor unlimit ed evolut ionand main tenan ce,i.e.,oneormore system adminis- trat ors andoneor moreprogramm ers willalways be theretobring aboutthecha nges requir ed tohandle evolut ionand main t enan ce. Unde r the assumpt ionof unlimited cha nge resourc es,thereisno need to explicit ly describ e syste mevolutionand maint e- nance.Inst ead ,todealwith any futur e change insyste ms, proper softwareengineer ing practi ces are adoptedwhen the initi al system isdeveloped,e.g.,st ruc t ure d program- mingisused andall necessarydocum ent ati onisdone,suchthat itiseasytomake any cha nges whicharenecessaryinthe futur e. Unfort una te ly,aswewill seein thenext section ,theassumptionof unlimited change resour cesis not truefor cert ainsyst em operational environment s.

2.3.4 TypesofSystemOperational Model

Thoughthereisno explicit menti on ofsystemoperat iona l modelsin the software enginee ring literature, thereappea r tobethree types . Unlike syste m processmodels, whichdep endmore on the complexit yof the syste m, syst emoperationalmodelsde- pend onthe user communityand to alesserdegree on the applica t ion bein gdeveloped.

These threetypesareasfollows:

1.Large Organizational Model: Thisincludes orga nizat ionsthat have ef- fecti velyunlimitedresour ces availa ble for syste m maint enan ceandevolut ion.

(40)

These orga nizat ionscan use their resour ces for systemadminist rat ion,andcan handl e anycha nges which they may want in theirsystem due tolong term syste mevolut ion.

2.Personal Model: Thisincludes standa lonesystems developedfor personaluse.

Usersusing suchsystems possess very limit ed resourcesforthe main t enance and evolut ionoftheirsystems.

3.Small Organizational Model: Thisinclud es sma ll organi zati onsor focused groups in lar ge orga nizat ions,suchas a cance rclinic inalargehealth car e organizat ion. These orga nizat ions havelimitedresour ces availa ble,andcannot usually affordsystem maint enan ce andevolut ion.

Thisistoour knowledge anorigina l classificati on ofsyste m operationmodels.We believe that thisclassificati onisusefulnot only forshowing howexist ing syst ems operate, but also for showingtypesofsyste ms not adequa te lyadd ressed incur rent software developm en tpracti ce.This orde ringof modelsmaylooksome wha tstra nge, butthis isthe historical order in which these models eme rged . To fullyunderst and the differencesbetween thesethree models,itisuseful to100k atthishistori cal orde r in moredet ail.

Thishist orical orde rcan benicelyvisu alizedintermsofa3x2 tabl e (seeTabl e 2.1),whose dimensions aretypesof availablesupportandsizeof user communit ies.

The typesofsupportare:

1.No Support: A workpl acewhereno systemadminist rat or is availableand no orvery lit tl e supportis available from the developer ofthesyste m.

(41)

2.Partial Support: A workplacewhere support isavailable but isavailable eit her part-time onsiteor full-tim e off-site,e.g.,supportavailable viaphone fromthe develop er ofthesyste m.

3.Full Support: A workpl acewhere support is availa ble both,full-tim e onsite, i.e.,syste m administr ator s and programm ershiredby orga nizat ion,and/or full- timeoff-site.

Thetyp esof usercommunitiesare:

1.Single-user systems: Single-user syste ms werefirst introducedin the1970s.

These systemsare developedfora standa lonecompute randare less complex and less expensive thenmulti-u ser syste ms.

2.Multi-user Systems: Multi-u ser systems werefirst introducedinthe 1950s, whenit was common for bigorganizations to usesuch systems . Multi-user systems are more complexandexpe nsive than single-user syst ems .Dueto their complexityand differentfuncti onaliti es suchsyste ms requir efull support and dedi cat edtechnical supportonsite.

Notethattwopossibl e combina tionsofsupportand user communit ies areveryrar e:

Multi-user syste ms withno support ,and single-user syste ms with full support. Hence, theyare notaddressedbelow.

Letusnowlook at the historical orde r in whichthemodels emerged . When com pute rs werefirst introdu cedthey carne only inamulti-user environment. Initi al compute rsystems in 1950swere targete dtohundreds orthousandsof users, and those multi-u ser syste mswere, bydefiniti on,complexsyste ms . Organiz ati ons that

(42)

were usin g suchmult i-usersystems had theirown IT divisions,orhad theresources to contract differentcompanies for thefullsystem support. Thesesystems were developed under the LargeOrgani zati onal Model. In the late 1970sandearly 1980s standalonesystemswere int rodu cedfor the use ofsingleusers. These systemswere simple, buthadno support from the developers. Usersusingthesesystemswere expecte dtobe sma rtenoughtobe abletofix any problems that might arisewhile usin g them. Therefore,these systems were effectively under the PersonalModel.

At this point wehavepure versions of thefirsttwomodels. However ,the era ofthe mid 1980's sawthe introducti on of par t ial support,whichdid not affect big businesses,but didcha ngethe PersonalModel bymovin gitfromtheupperleft corne r down thecolumn. Inthis model,users who pay severa lthousa nd dollarsfor a system receivehelp fromdesignatedstaffbelongingto the vend or compan ies who createdthesesystems. Because of the lar genumber ofusers ent itle dto suchservices, provid ing supportto themwasnot an issuefor big vendercompa nies, due to the economicfactors involved .Hence, single-usersystems were the first typeofsystems for whichpartialsup portwasprovided.As more andmore peoplegotint o the market oneofthe waysfor systemdeveloperstoret ainmarket share becam e the provision of user support . Thisnowmean t that bythe addit ionof par ti al support,single-user systemscould becom emore complex,andinturncouldbe ada pte d to theneeds of sma llorga nizat ions. Thisled to theemergence ofthethirdope ra t ional model, the SmallOrgani zati onalModel.

Now thatwehave seenhow thesethree models emerge d,letus examine how each modeldealswit hthe issues of software maintenanceand software evolution:

(43)

1.Large Organizational Model: In thecase of the Large Organizational Model, as such organizations haveeffect ively unlimited resources, they can afford to allocate these resourcesas necessary for both system maintenance and evolution.

2.Personal Model: In the case of the Personal Model,for maintenance,either the person or the developer company is responsible for system maintenance and evolution. For future system evolution under this model,software companies are always trying to establish the needs of their users. As the number of personal- system users is large, big software companies can invest a lot of money to make a good general package for them.Hence,personal computer evolution is handled very well. In the case of system maintenance,as companies sell these systems to many users, they have the resources to maintain them and to provide support, suchas 24/7help lines or technical support available over the web to correct problems.As systems under the personal model are relatively simple compared to multi-user systems,partial support is sufficient for their maintenance and evolution.

3.Small Organizational Model: In the case of the St;lall Organizational Model, organizations lack the resources to handle the maintenance and evolution.More- over,these organizations do not have the numbers to encourage the emergence of vendor companies that will provide them with even partial support.

As we can see from the above,there is a gap in how to deal with a system operating under the Small Organizational Model. One way to deal with maintenance for these organizations is that we can minimize the need for full time system administrator support by building systems in such a way that the system users can handle adminis-

(44)

tration themselves.To handle evolution, in case of organizations whose activities are small and very circumscribed,with sufficient design during the development of the system; we can also put the evolution of such systems in the hands of their users.

To handle system operation in the Small Organizational Model,we have introduced a democraticmodel of system operation (see Section 4.2.1).Thoughthis model is describedin detailin Section 4.2.1, the followingpoints shouldbe noted here;first, wehave builtthismodelso that system changesthatare requiredbased onday to day activit iesare inthe user 'shan ds. Second, alt houghthesystemad minist rato r cannotbe fullyremoved from the loop, minor day to day cha ngescanbe madeby the users using thisdemocratic approach, so that even partial supportis sufficient.

2.3.5 Which System Process and Operational Models are Appropriate for Medical Informatics?

By looking at the complexityof medical systems and taking into considerationthe risk involved in the process of developing a medical tool, the Spiral model (see Section 2.3.2.4)seems to be the most appropriate one. As this modelneeds strong user involvement in the process of development,there is a need to findcomputer literate physicians whocan act as physicianchampionsand can helpthro ughouttheprocess of developinga successfulmedicaltool.

The system operational model depends on the type of medicalsystem beingde- veloped. For EMRs/EHRs,and generaldrug orders CrOE willfallunder thelarge organizational model. Decision support systems, if they are done frequently enough, will fall under the personal model. Infrequently used decision support systems and

(45)

targete dCP OEsystemswillfall under theSmallOrganizationalModel. Hence med- icalinformat icstoolsfall int o allthreecategoriesof system operationa l model.In Cha pter3, we willsee thatchemot hera pyprescript ionsystems fall under theSma ll

Organi zat ional Modelandwe willshow in detail howlimi t ed resourcescan cause probl em sfor theoperationofsuchsystems.

Tabl e 2.1: Typ es of System Operationa lModels Single-User Multi-User Environment Environment

Personal

V

No Support

X

(1970's )

Personal

V

Organizat iona l

Partial Support [Sma ll]

7

(1980's+ ) (1990's+ )

Organi zati onal

V

Full Support

X

[Large]

.(1950's+ )

(46)

Chapter 3 Chemotherapy Prescription

In this chapter we will look at a particular type of order entry system associated with chemotherapy prescription. Such a system is an example of a CPOE system (see Section 2.1). CPOE systems can be of a generalized nature, covering all types of medical prescription writing,or can be targeted systems,where a system is designed to computerize a specific type of medical treatment such as chemotherapy.Targeted CPOE systems inherit all the problems of the generalized CPOE, but also introduce some new problems due to their targeted nature. Hence,in this chapter we will discuss CPOE in general (Section 3.1),and we will look afan example of a targeted CPOE, a chemotherapy prescription (Section 3.2). Finally,we will review previous efforts to develop chemotherapy prescription systems and we will sketch the form of an idealized system that builds on this work (Section 3.3).

(47)

3.1 CPOE

In Section 2.2,welooked at the problemsassociated with medicalsoftware in general.

In thissection,we will look at these problems in the contextof theparticularsystem of interestto us in this thesis,namely CPOE.In thissection,we more closelyexam- ine the definition of CPOE (Section 3.1.1),and we review thebenefits and problems associatedwith CPOE implementation(Section 3.1.2),as well as the problems(Sec- tion 3.1.3).Finally, we will summarize the factors associated with successf ulCPOE implementation(Section 3.1.4).

3.1.1 What is CPOE?

CPOE (Computerized Physician Order Entry)is the generic nam e fora comp uter applicationwhichwas introduced as an effort to eliminatethechanceof errors,such as errors in ordering medication by a physician (see Section 3.1.2) . To eliminate thechanceoferrors, instead of writingorders on a prescriptionpad, the prescriber enters anorder directlyinto the computer. The funct iona lit iesof CPOE systems vary in different CPOE tools. Kaushal and Bates describe the basicfunct iona lities of CPOE toolsas follows: ". .Basic CPOE ensur'esstandardized,legible, complete ordersby only accepting typed orders in a standard andcom plete[ormat,.. Basic clinical decision support may include suggestions or default valuesfor drug doses, routes,and frequencies..."[35].Advanced CPOE systems may include,butare not limited to,decisionsupport,drug dose recommendation,drugint eract ion notification, and billing[13].

(48)

3.1.2 Benefits of CPOE

Studies have shown that CPOE systems are effective in reducing the medication errors that frequently occur in the paper based system currently in use by the majority of medical service providers [9,20, 38, 60]. Note that even a basic CPOE system can be very helpful in reducing calculation errors in prescriptions which involve complex calculations (such as protocols for cancer chemotherapy orHIV therapy). These and other benefits are described in more detail below.

3.1.2.1 Reduction of Medical Errors

Every year, thousands of patients world-wide die as a result of medication errors [36].Mistakes such as errors in dosage, improper routes of administration, and wrong dosage schedules, among others, are typically responsible for such events. Such mistakes have at least two causes: The first cause is Doctors' poor handwriting,which sometimes leaves pharmacists squinting to read drug names or dosages, and causes them to provide improper medication or dosages by misunderstanding the prescription. The second cause of medication errors arises when prescription writing involves complex calculations.Given the actions of some drugs, especially the cell toxic drugs involved in chemotherapy,any mistake in calculation of dosage has potential to cause patient'sinjury or even death.This problem is compounded when prescriptions involve multiple drugs; for example, in a chemotherapy prescription, a selection of drugs is given and the dosage of each drug involves calculations (see Section 3.2.1 for details).Even if neither of the above problems is present,the prescription is written perfectly, and everything is calculated correctly, adverse drug events (in which several

(49)

drugs combine to have unexpected side effects) can cause another category of errors where wrong combinations of drugs can cause harm to the patient.'.

CPOE systems are regarded as the solution to medication errors which arise from prescription writing. CPOE solves the problems of poor handwriting, as allprescrip- tions are computer generated and all calculationsare done by computer,eliminating the chanceof calculationerrors. Moreover, CPOE can check the possibilityof any known adversedrugeventsautomatically.Theresultsof CPOE canbeimpressive;

published studies have shownthatCPOEcanprevent81percentoferro rsrela tedto prescript ionwrit ing[9,20,38, 60].

3.1.2.2 Time and Cost

Most studies on CPOE benefits are related to CPOE's ability to reduce medication errors, as this is the primary purpose of CPOE systems. However , CPOE systems also have the abilityto reduce overall hospital costs.Evans et al [25], have shownthat CPOE systems help to reduce the cost of medication and thelengt h of hospitalstays by reducing the number of orders for antibiotics when anti-infective-management programs were used. Moreover,the abilityof CPOE to reduce adverse drug events also causes a decreasein the costs associatedwit hsuch events, whichare,according to a report by the Insti tu t e of Medicine,about2 billiondollarsa year[36].

IThere is anothertype of error related to deficiencyof medication knowledge,whichmay occur because of less experienced physicians entering into the field, or when physicians occasionallyfind themselves outside their normal area of expertise[IIJ.Though this could potentially be mitigated by computerization,i.e.,an appropriately designed expert system,thisis beyond the scope of this thesis and will not be considered further herein.

(50)

3.1.2.3 Research Purposes

Electro nic dat ais alwaysattractive for researchpurposes. CP OE dat ais stored elect ronically in itemi zedformin dat ab ases,i.e.,notinscanned docum entform;

hence,it provides elect ronic dat awhichismorereadil y availa ble for resear ch ,whichin turncan improve the qualit y of health car e.For exa mple, inthecaseofchemot hera py treat me nt, wheredifferent comb inat ionsofdrugsare used to treatcance r,medical dat a can helpresearchers tofindthebest combinat ionsofdrugsfor thetreat mentof par ti culartyp es ofcancer.

3.1.2.4 Administrative Purposes

Acompute rized medical system likeCPOEcan beuseful foradminist rat ive purposes, suchas evalua t ionof clinical staffperforma nce.For instance,usefulinform ati on can beretri eved about how often aparti cul ardrugisprescribedby thephysician and how much aparti culardrug costs per year . Inthis way, ad minist rat orscan maximizethe effectivenessoftheir resour ce allocat ion.

3.1.3 Proble m s wit h CPOE

CPOE hasbeenunderdiscussionfor over35 years,which haslead to an underst andin g of manyproblem swith CPOEsystems.In 1970,Collen [19] introduced theconce ptof CPOE bylistingthegenera lobjec t ivesof MedicalInformationManag ementSyst ems , andstatedthat,"Physiciansshouldentermedicalorders directly into the computer".

Following this,therewerevariouseffortsto implementCP OEsystems.Sit tig and Stead [68], in 1993,summa rizedthe previous wor k donerelated to CP OE.Accordin g

(51)

to their pap ermost of theefforts mad e inthe1970s and 1980smet wit hfailure. Techn ology const ra intsat thattime,costs, and lack of computerliter acy wit hinthe medicalprofession were amongthe major causesof these systems' failures.

Oddly,recentimplement ati ons ofCP O Eatdifferent sites donot showsignificant improvem ents,desp it e advance me nts intechno logyand sufficientcompute r lit eracy inthe medicalprofession.As aresul t ,many oftheseefforts havefailed .For example, Cedars-Sin aiHospi t alin LosAngelesimplem ent ed amultimilli on-doll arCPOE in lat e 2002and threemonths afte r implem ent ati on ,thetoolwasuninstall ed asphysicians complainedaboutthe poordesign ofthesystem [40].Iftechn ologyhasimproved,the cost oftechnology hasdecreased , soft ware design and implemen t ationmeth odologies haveimproved , andcomp uter lit eracyinthe med ical profession hasimproved , then ot her reasonsmust beresponsible forthe failur e ofthesesystems .

Themainreasonfor these failuresseemstobe alack of resp ectby systemdevel- opers for theclinical work flow,inpart icu lar,whereinsufficientattent ions hasbeen paid to thedetailsofgoingfrom manu al to computer izedworkflow[40,59]. This was acknowledged byMichaelL.Langb erg,M.D. , ChiefMedica l Officer at Ceda rs-Sina i MedicalCent er ,who statedthat,"Oneof themost important lesson slearn ed todate is that the complexityof hum an change managem entmaybe easily underestimat ed"

[40].Wewill discuss this in much greate r det ailwhenwelookat the specificsof chemot hera py prescrip ti onin Sect ion3.3.Inthe next section,wewill discuss the fact ors that makefor a success fulCP OEsystem.

(52)

3.1.4 Factors in SuccessfulCPOE Im p le m e ntations

As seen in previous subsect ion, many CP OEsystemshave failed becau sephysicians stopped usin g them,andoneofthe main causesseemsto beinat t enti on to clinical workflowby syste m developers. Physician sneed a systemthat is gua ra ntee d to help them providequalit y care to their pati ent s and,obviously, they cannot make compromises in pati ent care .Ifa tool is design edin keepin gwithest ablished physician and health car eworkflows (whicharealready knowntoworkwell) ,thentherearefewer chances for thattool tofail.Thus,to makeCPOEaccepta ble forphysicianstoadopt, it must haveat leastthefollowingproperties[6,78]:

•Itshould be accura teandreliable soas topositiv ely affcct patientcare.

•Whileimplem entin g CP OEsyste ms, legacy syste mscur rent ly in usebythe health care providers should betakenintoconside rat ion.

•Physiciansshouldbe given fullaut hority tomake any decisionsaboutpa- tienthealth. Imposing somet hingagainstaphysician 'sfinaldecisionshould beavoided.

•Itshould befast enough thatit improvesthespeedof workflow or atleastit shouldnot be slowerthanthe exist ing system .

•Itshouldbe easy to use andshould requir eminimaltrainingforeffecti ve use.

A striking featureof medicalwork is thatit is fast paced .Physicianshavelittle time tospa re to learnnewtechnologi es.Hence,thenewCPOE system should be sim pleenough thatit takes littl etimeforphysicians tolearnit.

(53)

•Int erfaceissu es shouldbe taken int o considerationwhiledesigningsuchsystems andthe int erface shouldbe consiste ntthro ugho utthe system.

• Itshould have standa rdizat ion withresp ect tomedicalprocedur es andtermi- nologyandaworkflow thatcan be effectively implement edin health car e.

•Duringsyst emimplement ati on ,physicians should receive any helptheyneedto cha nge theirworkflow st ra teg iesand habit s.

•Afterthe syste m hasbeenimplem ent ed , online help should beavailable.

These are theminimalrequir emen tsfora success ful CrOE implement ation .Itis st rongly recomm end ed that, tofulfilland tounderst and theabovecha rac te rist ics, physicians should be anactive par t ofthe implem ent ati on.Thusthereis aneed to search for compute r liter atephysicians,referred to as "physicia ncha mpions"through- outthe liter atur e [59, 65], ifthe process of implem ent ati onistobesuccessful.

When compa redto "ordi nary"software,the developm ent of medi calsoftwar e/ tools ismuchmore complexand risky, asif it isdoneincorr ectl y,peoplecan die and it will have excessivecosts(seeSection 3.1.2). Car eful conside ra t ion should be givento make sure thatthe appropria tesoft ware processmodelis selecte d to dealwiththis complexity. Moreover ,we also needtochoose the appropria te systemoper ation al model.This is necessarybecau seCrOE, asnoted earlier,comes in several sizes.The genera l CrOE fallsunderLar geOrgani zation alModel. However ,as wewillseein next section,chemot hera py prescrip ti on seemstofallunder the SmallOrgani zati onal Mod el.Itmean s thatchemot hera py prescrip ti onhasfewer availa ble resour ces, and itsimplicati ons will be discussedand dealt wit hinthe rem aind er ofthisthesis.

(54)

3.2 Chemotherapy Prescription

Inthissection,wewill now exa m ine aspe cific typ e ofCP OE in det ail,i.e.,chemot herapy prescrip ti on.Wewillstruct ureth issystem in parallelwith that for CP OE,by firstgiving a descriptionofche mo t hera py(Sect ion 3.2.1). Recallthatoneof the mainproblem swithCPOE isnotpayin g attent ionto the workflow of healthcar e system.Ther efor e,we givean over viewofchemot hera py prescriptionworkflow(Sec t ion 3.2.2),and wewillseehow thismanua lworkflowcan beimprovedbyrepl acin git withcom pute rizedworkflow(Sect ion3.2.3) .We will lookatthebenefitsofthecom- puteriz edworkflow(Sect ion 3.2.4), andconside rat ionsconcern ing thedevelopmentof compu te rized workflow (Sect ion3.2.5) .

3.2.1 What isChemother ap y?

Chemother ap yrefersto theuseof drugsto treat anillness (chemother apy=chemic al- therap y )[31 .Wher e cance r is conce rne d,chemo t hera py isused to eit he r destro y cance r cellscom pletely or,whenthis is not possible ,tocont rol thegrowth of these cells[21. Mostcance rchemot hera pe ut ic drugshavebeen chose n becau setheyactaspoisons thatatt ack dividing cells.The typica lsideeffectsofcell-to xic drugsresultfrom their effects onothe r rapidlydividing cellssuchashairfollicles and bonemarrow,which produ cesnewred and whiteblood cells.Shor t- term effectsofche mo t he ra py include hairloss ,bonemarrow suppress ion,ane m ia, and susceptibilityto infection.

Ther eis alar genumber of differ entdrugs that are used totreat cance r. Each typ e ofcance r isonly sensit ive topar ti cul ardrugs,and there arc manydifferent typesof drugs.In most cases, a combinat ion of drugs,alsocalledadrugre gimen,