HonoursProjectReport

Min Max Chosen

1 SoftwareEngineering/SystemAnalysis 0 15 10

2 TheoreticalAnalysis 0 25 0

3 ExperimentDesignandExecution 0 20 15

4 SystemDevelopmentandImplementation 0 15 10

5 Results,FindingsandConclusion 10 20 15

6 AimFormulationandBackgroundWork 10 10

7 QualityofReportWritingandPresentation

10 10

8 AdherencetoProjectProposalandQualityofDeliverables

10 10

9 OverallGeneralProjectEvaluation 0 10 0

TotalMarks 80 80

D e p a r t m e n t o f C o m p u t e r S c i e n c e , U n i v e r s i t y O f C a p e T o w n 2 0 0 9

BySenaLeeAllen

SupervisedbyDr.HanhLeCoSupervisedbyDr.MichelleKuttel

TheE‐HealthPatientRecordManagementSystem

ii

TableofContents

1.Introduction ....................................................................................................... 11.1KeyFeaturesandImpactoftheSystem............................................................................................ 11.2ThesisStructure .......................................................................................................................................... 2

2.Background ........................................................................................................ 32.1Introduction .................................................................................................................................................. 32.2MediumofDisplay ..................................................................................................................................... 32.3HumanComputerInteraction(HCI)................................................................................................... 32.4HeuristicEvaluation.................................................................................................................................. 42.5Web2.0 ........................................................................................................................................................... 42.6RecordConfidentiality.............................................................................................................................. 42.7AssessingaComputerBasedRecordManagementSystem..................................................... 42.8SimilarProjects ........................................................................................................................................... 52.9Conclusion ..................................................................................................................................................... 93.SystemDesign .................................................................................................. 103.1Introduction ............................................................................................................................................... 103.2DesignofthePrototype ........................................................................................................................ 103.3ImplementationOfthePrototype .................................................................................................... 113.4TestingThePrototype ........................................................................................................................... 133.5UserEvaluationofthePrototype ..................................................................................................... 133.6UserRequirementsConclusions ....................................................................................................... 173.7DesignofTheNewSystem .................................................................................................................. 183.7.1ComponentsofaWebApplication................................................................................................ 183.7.2SecurityandAdministrators............................................................................................................ 18

3.8OverallSystemDesign........................................................................................................................... 183.9DatabaseDesign ....................................................................................................................................... 213.10WebsiteDesign ...................................................................................................................................... 223.11SystemRequirements ......................................................................................................................... 233.11.1HardwareRequirements ................................................................................................................ 233.11.2SoftwareRequirements................................................................................................................... 23

3.12DatabaseSecurity ................................................................................................................................. 243.13Conclusion................................................................................................................................................ 24

4.0Implementation.............................................................................................. 254.1Introduction ............................................................................................................................................... 254.2TheImplementationProcess.............................................................................................................. 254.2.1TheUserRegistration/LoginSection .......................................................................................... 264.2.2ThePatientRecordAccessSection ............................................................................................... 284.2.3TheDoctor/NurseSystemSection ................................................................................................ 294.2.4TheECGDisplay .................................................................................................................................... 324.2.5TheAdminSection ............................................................................................................................... 334.2.6OtherWebsiteFunctions ................................................................................................................... 34

4.3Conclusion .................................................................................................................................................. 345.0TestingandEvaluatingOurSystem................................................................. 355.1Introduction ............................................................................................................................................... 355.2SoftwareTesting ...................................................................................................................................... 355.3UserEvaluationOfTheSystem ......................................................................................................... 375.3.1ResultsoftheSurvey ........................................................................................................................... 38

iii

5.3.2FocusGroupSession ............................................................................................................................ 415.4UpdatingOurSystem,theFinalIteration...................................................................................... 415.4.1DesigningtheFinalChanges ........................................................................................................... 415.4.2ImplementationOftheFinalSystem............................................................................................ 425.4.3TestingtheImplementation ............................................................................................................ 43

5.5Conclusion .................................................................................................................................................. 436.Findings............................................................................................................ 446.1OtherFindingsWhenAnalyzingtheCurrentSystem .............................................................. 446.2OtherFindingsDuringSoftwareDevelopment .......................................................................... 44

7.ConclusionsAndFutureWork........................................................................... 467.1SignificanceoftheProject.................................................................................................................... 467.2Achievements ............................................................................................................................................ 467.3FutureWork............................................................................................................................................... 47

8.Appendices....................................................................................................... 488.1AppendixA,PrototypeQuestionnaire............................................................................................ 488.2AppendixB,WorkingSystemSurvey.............................................................................................. 51

9.References ....................................................................................................... 54

iv

ListofTablesandFiguresTable1.SalfordInformationSystemfeatures........................................................................6

Table2.SMARTAlarmcauses .......................................................................................................8

Figure1.Loginscreen.................................................................................................................... 11

Figure2.TheHomePage .............................................................................................................. 12

Figure3.SearchScreen ................................................................................................................. 12

Figure4.AnExampleofaPatientRecord ............................................................................. 13

Figure5.CurrentSystemActivityDiagram.......................................................................... 14

Figure6.CurrentSystemUseCaseDiagram........................................................................ 15

Figure7.ProposedSystemUseCaseDiagram .................................................................... 19

Figure8.DesignClassDiagramoftheProposedSystem................................................ 20

Figure9.EntityRelationDiagramoftheDatabaseourSystemuses ........................ 21

Figure10.Statusselect.................................................................................................................. 22

Figure11.Doctor/Nursesection............................................................................................... 22

Figure12.PatientSection............................................................................................................. 22

Figure13.AdminSection.............................................................................................................. 23

Figure14.SiteMapoftheE‐HealthWebsite........................................................................ 25

Figure15.Loginstatusscreen.................................................................................................... 26

Figure16.Userregistrationscreen.......................................................................................... 27

Figure17.UserRegistrationscreenwitherrormessages ............................................. 27

Figure18.PatientRecordManagementHomePage ........................................................ 29

Figure19.ListAllPatients ........................................................................................................... 30

Figure20.URLhighlightingPatientIDcarriedovertonextpage.............................. 30

Figure21.UpdatingthePatientInformation....................................................................... 30

Figure22.SearchingForApatient ........................................................................................... 31

Figure23.Sidebysidescreenofthesamepatientrecordbutaccessedbyusersofdifferingaccesslevels.Thedoctor’sistheleftscreenwhereasthenurse’sistherightscreen......................................................................................................................................... 32

Figure24.BankConsultationscreen....................................................................................... 32

v

Figure25.Listingtheusersofthesystem............................................................................. 33

Figure26.Editingtheusersstatustoenterintothesystem......................................... 34

Figure27.Doctoranswers ........................................................................................................... 38

Figure28.Nurseanswers............................................................................................................. 39

Figure29.MeanAnswervaluesforthedoctorsandnurses ......................................... 40

Figure30.ConsultationSummaryScreen............................................................................. 42

Figure31.TheECGdisplayScreen........................................................................................... 43

vi

AbstractThisthesisdealswiththecreationofanelectronic,lowcost,healthcaresystemprimarily intended for use in Southern Africa. From our observations andinteractionswithhospitalswithinSouthAfrica,wehavenoticedaneedtoupdatethesystemscurrentlyinplace.Currently,hospitalsdeployapaperbasedrecordmanagement system, relying heavily on files that are easily lost and areinefficient to use, ultimately to the detriment of the patient. Hospitals arebecoming far more overcrowded and the possibility of human errors whenprocessingthesepaper‐basedfilesisveryreal.

Throughour interactionswithrealhealthcareworkers,wehavedevisedawebinterface that allows the creation of patient records, the ability to view ECGreadings and the ability to add and read past doctor consultation notes. Oursystemalsohandlesadministrationtasksbyregulatingwhohasaccesstowhatdata within the system, as well as the creation and deletion of users of thesystem. Emphasis has beenplaced on creating a user‐friendly system, asmosthealthcareworkersarenotfamiliarwithcomputerizedsystems.

Oursystemwaswellreceivedbytheprospectiveusersof thesystemwhenwepresented it to them, and everybody surveyed felt that it would greatlystreamlinetheworkingconditionswithinthehospital.Asaresult,moretimecanbespentconsultingwithpatientsanditiseasiertoquerypastdata.

1

1.IntroductionThe E‐Health project deals with creating a low cost, non‐intrusive medicalsystem, primarily for use in South Africa, in order to help both health careworkers and patients. The reason we devised this project is that it had beenbecome clear on our visits to healthcare facilities that a system needed to beimplemented to update cumbersome paper based systems currently in use inmost hospitals within South Africa. The use of Open Source technology hasallowedustodevelopthissystematverylittlecosttherebybenefitingthepublic.Wedividedtheprojectintothreemanageablesections,theseare:

• The gathering of ECG data (electrocardiogram) through the use ofBluetoothsensorsanddisplayingtheresultsonaPDA.

• Storingthisdatasecurelyinapeer‐to‐peernetwork.

• Creatingawebbasedinterfaceforapatientrecordmanagementsystemthat can create and manage patient records as well as display ECGreadingssentbythepeer‐to‐peernetwork.

This report deals with the last section, i.e. the patient record managementsystem.Thepatientrecordmanagementsystemisakeypartoftheprojectasitistheinterfacethatmajorityoftheuserswillinteractwith.

The nature of this project is primarily anHCI usability project that is focusedtowards the developing world. Thus thorough investigations with theprospective users of the system will occur and they will be heavily involvedthroughouttheproject’slifecycle.

1.1KeyFeaturesandImpactoftheSystemTheKeyfeaturesofthesystemare:

• Alogicallydesigned,user‐friendlyfrontendwebinterface

• Adatabasestoringpatientrecords,doctorconsultationdetailsandaccesslevelsforspecificusersofthesystem

• TheabilitytovisualizeanXMLfilecontainingECGdata

• Administrativecapabilities,i.e.manageusersofthesystem

• Easy creation, updating and searching of the patient records based onHealthcareworkersspecificpreferences.

• Layersofsecuritythatrestrictusersfromaccessingcertaindatabasedontheirstatuswithinthesystem.

• Theabilitytoaddandviewpastdoctorconsultations

• Aselfuserregistrationsystemthatencryptstheuserspassword

Theexpected impactof theprojectwouldbe thecreationofastablesystemtoillustrate todoctorsandnursesofeitherhospitalsorprivatepractices,howan

2

electronichealthcaresystemwouldbenefitthem.Thesystemwilldemonstrate,thatbyupdatingthepaper‐basedsystemsthattheyarecurrentlyusing,theywillimprove the care given to the patients bymaking their working environmentmoreefficient.

1.2ThesisStructureThis thesis is broken down into a number of sections, the next section is thebackgroundchapter,whichidentifiestheprosandconsofcreatinganelectronicpatientrecordmanagementsystem,afewrealworldexamplesofhealthsystemsingeneralaswellassometheorybehindsomeofthemethodologiesused.

The design chapter follows the background chapter, which outlines the stepstakentocreateahighfidelityprototypetobeusedtogatheruserrequirements.The chapter also presents the user’s feedback of the prototype; and this isfollowedbyadesignspecificationforaworkingsystem.

Thedesignspecificationwouldthenbeusedtoimplementaworkingsystem,ofwhichthesystemisexplainedinthenextchapter,theimplementationchapter.

Wegoontotestoursystembothbytestingitsfeatures,andbyconductinguserinvestigations; this is outlined in the testing chapter along with the user’sfeedbacktowardsusingthesystem.

Reportingthefindingswemadethroughouttheproject’slifecycleroundsoffthethesis.Finallywegiveourconclusionsandfutureworksuggestions.

3

2.Background

2.1IntroductionAdvancementswithin thehealthcare industryarehappeningatarapidpace tocaterforarisingnumberofpeoplewhosufferfromdailyafflictionsandchronicillnesses. Technology has come to the aid in the formof providing storage forpatient records and providing efficient ways to search for and access theserecords. Gone are the days ofmassive filling cabinets and long lines of peopletryingtoobtaintheirpatientrecords.

UnfortunatelySouthernAfricahasbeenlateinembracingthistechnology,foravariety of reasons, these are lack of funding, training and a stereotype thattechnologyisexclusivelytobeusedinthefirstworld.

Currently most South African hospitals are extremely over crowded andunderstaffed. This leads to the patients ultimately suffering from the lack ofattention. Patient’s conditions can rapidly deteriorate while the patient iswaitingtofindhis/herrecord,andthusasystemthatcanstorerelevantpatientdataneedstobecreatedsohealthcareworkerscanactaccordinglyinatimelymanner.

2.2MediumofDisplayTheInternethasbeenusedtodisplaydataover the last threedecadesandtheconcept ofweb applications is not new. Given itswidespread use and ease ofaccess,theInternetisanappropriatemediumforthepurposesthattheE‐Healthproject wishes to accomplish. The purpose being the presentation of datagatheredbysensorsaswellasanyotherrelevantdatathathealthcareworkersmightrequire.Very littledevelopmentof thisnaturehasgone intothemedicalfield and very few systems that keep track of vital signs online exist, thus anopportunity is created to help people in hospitals bettermanage patients andultimatelysavelives.

2.3HumanComputerInteraction(HCI)A lot of research intowhat exactly customers requirewill have to be done inordertoproduceaneffectivesolution.Userspecificationsareanincrediblyvitalpart of web application design and thus should not be taken lightly.Questionnaires and heavy user involvement during the design phases of theprojectwillneedtoensue.

Usability is often overlooked by software engineers [1], and is extremelyimportant. Too often developers make software that is unusable by endcustomerssimplybecausethedevelopersfailedtocatertothecustomersneeds.Henninger et al [1] outline two guidelines that developers should follow foreffectivesoftware, thatbeingstyleguidesandusabilityguides.Styleguidesareused todevelopconsistencyacrossapplications.Usabilityguidelinesare those,which are followed by using techniques such as participatory design and uservalidation.

4

Thenature of this project requires heavy interactionwithmedical staff. TheseHealthcareprofessional’stimeisextremelyvaluableastheyareworkingtosavehumanlives.Thusitisextremelyparamountthatefficientusercentereddesignprinciplesemployed.

2.4HeuristicEvaluationHeuristics are experience‐based techniques that help in problem solving,learning and discovery. Ben Nielsen states [2] that the use of heuristics cangreatlyalleviate costsand improveusabilityof interfaces.He furthermentionsthatdifferent‘evaluators’ofdifferingskillsetsaccessasystem,thesearenovices,ordinaryspecialistsandadvancedspecialists.Thusthreedifferentskillsetsneedto be catered for with the goal of leading everyone to advanced specialists.Nielsen[2]pointsoutsomeofthemostvaluableheuristicsasfollows:

*Simpleandnaturaldialogue

*Speaktheuser’slanguage

*Minimizetheusermemoryload

*Beconsistent

*Providefeedback

*Provideearlymarkedexits

*Provideshortcuts

*Gooderrormessages

*Preventerrors

2.5Web2.0Web2.0isanewdirectiontheInternetistakingwherebyInternetapplicationsare changing to cater foramoreuser‐definedexperience [3].Thatbeingusershavebecometheproducersofcontentandthedesignersofeachother’sviewingexperience. Thus the users take ownership in the system once deployed, andproviding further reason in involving them in development stages andincorporatingtheformermentionedheuristics.Awebapplicationdeployedinamedicalsettingwilltakeonthisform,asdoctorsandnurseswouldbeinchargeofmanagingthecontentwithinthewebsite,andthusultimatelycontrollinghowthewebsitewouldfunction.

2.6RecordConfidentialityPatient records and any data pertaining to a patient are deemed to beconfidential. A system dealing with such data needs to be protected fromintentionalandunintentionalmisuseofthisdata.Thusanyaccessofdataneedstobecontrolledandregulatedifitistocomplywithmedicalstandards.

2.7AssessingaComputerBasedRecordManagementSystemLehnartetal.[4]definesapatientrecordmanagementsystemasasystemthat

5

storesdemographic,andmedicalinformationfromancillaryservicessuchasregistration,lab,radiology,pathology,pharmacy,consultationandtranscription.Theystatethatarecordmanagementsystemisnotsimplyautomatedupdatesofpaperbasedcharts,butratheradynamicsystemusedtohelphealthcareworkersmakebetterinformeddragonesses.AccordingtoGaillouretal.[5]arecordmanagementsystemisonlyeffectiveatachievingthegoalsofincreasingqualityofcareandloweringcostsiftheorganizationre‐designsit’scurrentworkflowandpractices.Henceaveryuser‐friendlysystemneedstobecreatedtomitigatetheriskofuserdissatisfactiontowardsthenewsystem.Fromberg et al. [6] claim the clinical benefits to such a system include:*Easier,morerapidaccesstopatientdatacharts

*Improvedclinicaldecisionmakinganddiseasemanagement

*Moreeducatedpatientsabouttheirownailments

*Anincreaseintimetospendconsultingwithpatients

*An increased perception of patient care and theoretically a better workingenvironment

Allthesebenefitsoveralltranslatetobetterpatientcare.Morebenefitsincludeamoreefficientworkflow,asduplicatetaskswouldnotbeperformedastheneedtoregatherinformationwouldbeeliminatedasalldatapertainingtothepatientisreadilyavailableatalltimes.Timetakentoexecuteadministrationfunctions,such as capturing patient demographics, drop dramatically. According toDassenko and Slowinski, [7] an average of up to 15 minutes was saved perpatienton thepatients firstvisitanda further20minutesoneachsubsequentvisitasaresultofimplementingacomputerbasedpatientrecord.

There are however some challenges when developing a record managementsystem. The main hindrance of which is the initial startup cost. Hardware,software and training make up the bulk of this cost. While there has been areportedhighreturnininvestment[4],theinitialcostsandthefactthatisalargechangefromthecurrentsystemoftenscareawaywouldbeinvestors.

As healthcare is a governmental responsibility, heavy support is required bytheminordertohavewidespreaddeploymentofsuchasystem,andaccordingtoDrazen[8]thisislackingandisanotherreasonwhysomanyhospitalsstillusepaperbased systems today.Data securityhas alsobeen amain issue althoughBergman [9] states that when compared to a paper based system, passwordbasedfileaccesscanactuallyimprovetheinternalsecurity.

2.8SimilarProjectsItisusefultoanalyzesimilarprojectsinthisfieldtoutilizesuccessesandlearnfrommistakesmade.

6

2.8.1TheSalfordDiabetesInformationSystem

TheSalfordDiabetesinformationsystem[10]isasystemdevelopedinBritaintostoreandmonitoraround200000diabeticpatients.Thesystemstoresrelevantpatientdatapertainingtothatindividualpatientandcanbeaccessedbyadoctorenquiringtherecord.Thedatastored isspecificallyaimedfordiabeticpatientsand as a result diabetic patientswere consultedwhen developing the system.ThesystemmakesuseofanumberofsecurityfeaturesinordertokeepthedatastoredwithinthesystemsecureandcanbesummarizedinTable1:

Table1.SalfordInformationSystemfeatures

Themainpointsof thesystem isrestrictingaccess to therecordsbyprovidinglayers of security within the system that is accomplished using userauthentication.Thelayersusedwere‘generalpractitioner’and‘consultant’.Eachgroup had access over certain portions of the data. A database holdinginformationregardingthesestatuseswascreatedandcheckedwheneverauserloggedintothesystem.

ThepatientrecordformsweredesignedinHTMLbytakingactualpaperbasedforms that doctorswoulduse, then converting them into an electronic format.ThesystemmadeuseofaSQLdatabasetostoreinformationcollectedbytheseforms.Accordingtothereport,editingpatientdatacouldtakeweeksbymeansofthe regularpaperbased system, andnow the system takes care of this almostinstantaneously.

Theprojectwasdeemed to be a success and itwas suggested that it could beextended to include all patients, rather that just diabetic patients. Theyconcluded that redundant files and duplicate investigations were virtuallyeliminatedthussavingtimeandmoneytoboththehospitalsandthepatients.

7

2.8.2SMARTCurtisetal.[11]outlinedamedicalsystemknownasScalableMedicalAlertandResponse Technology (SMART). SMART’s purpose is to monitor variousphysiologicalsignalsfrompatientsinthewaitingareasofahospital.Specifically,it measures the SpO2 content within the blood stream (oxygen level in theblood),theECGactivityandthepatientlocationatagiventime.Theprojectranfor over a year (June 2006‐ December 2007) in a hospital located in BostonMassachusetts.Themainaimofthesensorswastomonitorpatientsinthewaitingroom.Awaitcanrangeupto3.2hoursintheEmergencyRoomalone[12].Duringthistime,apatient’sconditioncandeterioraterapidly.Sensorssenddatatoacentralserver,andifanabnormalsituationarises,suitablepersonnelcanbealerted.Withthisarchitecture,thereisaverystrongpossibilitythatthecentralservercanbecomeoverloaded, or worse, fail completely, which could result in loss of life. Thearchitectureinvolvedsensorslocatedinsideawaistpackwornbythepatientwhich connected to a PDA wirelessly. These PDAs would transmit to thecaregiversPDAdatapertainingtothepatient.SMART’sinterfaceisnotweb‐basedhowever;it isalloperatedin‐houseandallunderonecentralserver.Thiscouldbeproblematicunderhighdemand.

Asmentionedearlieralotofmedicalresearchhastooccursoastoknowwhentoflagemergencysituations.SMARThasmanagedtooutlineafewsituationsandthesearegivenbelow:

8

Table2.SMARTAlarmcauses

2.8.3ECGWrapper

Gonçalves et al. [13]propose a system to tackle theproblemsofpatienthomecare. They devise a web interface that is linked to a patient’s data sensors,providingrealtimeECGupdatestothem.Theinterfaceofthesystemcomprisesofan“ECGWrapper‟wherebyanumberoflayersinteracttodeliverdatatotheuser.TheGUIallowsauser(Doctororpatient)toenterpersonaldata,andtoaddanyadditionalrecords.Thisinterfacelinkswithawrappinglayerthatcombineswithdataacquiredbythesensors(DataProcessingLayer)andconvertsitintoareadableformatforthewebinterface(classifiedasthedeliverylayer).

ThedeliverylayerpublishestheECGdataontheInternetfortheusersthroughawebservice.TheuserhastoactivelyspecifyonthewebwhenanECGrecordingsession is to begin. Data about the session as well as the actual session isrecorded.AllthisdataisstoredinanXMLfileandissenttoadatabase.Anyusercantheninvokeagetcommandtoobtainthisdata.AnotablepointisthatthereisatimedelaywhensendingXMLdataaroundthelayers.Thesystemwassaidnotbemeantforlong‐termusage.

9

2.9ConclusionToconcludewecantakewhatiscurrentlyinthemarketandbuilduponitforourE‐Healthsystem.Ofcourseanumberofusabilitysurveyswillhavetobedonefortheintendedmarketasitdiffersfromtheaforementionedsystems,whichweredevelopedinthefirstworld.TheSalfordDiabetessystem[10]presentsuswithagoodfoundationonhowawebbasedrecordmanagementsystemshouldbehaveandwouldbeagoodbasiswhendesigningoursystemexceptwewouldextendittocaterforallpatientsandnotjustthosewithdiabetes.

The visualization of the data will include the pros outlined by the currentsystemsreviewed.Thatbeing,easytouseWebinterfacesthatpresentsdatainalogicalmanner.Thewebinterfacesshouldalsobeabletobeaccessedatanytimeandallrelevantdatadisplayedintheformofonlinerecords,linegraphsandanyothermediumsthatthehealthcareworkersseefit.

Wehaveseentheprosandconsofimplementingapatientrecordmanagementsystem.Implementingsuchasystemwouldmostprobablyimprovepatientcareandprovidebetterjobsatisfactionforalltherelevantstakeholdersinvolved,andalthoughpaperbased systems still get the jobdone, there is reasonenough toimplementanupdatedsystem,withSouthAfricanrequirementsinmind.

10

3.SystemDesign

3.1IntroductionThischapteroutlines theprocesswe took ingathering information inorder todesign the best possible E‐Health system. We will look at the designmethodologiesusedaswellastheUMLmodelsofthefinaldesignofthesystem.

Thefirststepintheiterationwastodesignahighfidelityprototypeconsistingofnon‐interactive displays detailing how the potential system might look andbehave.

When designing final the system, one has to take into consideration the userswants and needs. We as computer scientists have little idea of what medicalpractitionersactuallyneed,andhenceourassumptionscouldbe incorrect.Theonly way to gauge these assumptions is to interview these healthcareprofessionalsonhowitwouldbebesttoimproveourprototypeintosomethingofusetothem.

As theprojects focus isausabilitypriorityproject, thedesignmethodologyweused is an iterative development process. The sequence of events for eachiterationisasfollows:

1.Gatheruserspecifications

2.DesignIterationofthesystem

3.Implementiterationofthesystem

4.Testiterationtochecksuitability

5.Evaluationbyusers

6.RepeatfromSteponeuntilaviablesystememerges.

Thismethodologyisalsoknownasstepwiserefinementandisveryeffectiveinausabilityproject,asusersareheavily involvedwith thecreationof thesystem,andareconsultedmultipletimesinthedesignprocess.

As outlined in the background chapter, User Centered Design principles weredeemed the most effective way of creating effective software for our users: ‐HealthCareprofessionals(doctorsandnurses).

3.2DesignofthePrototypeThefirstIterationofoursystembeganbydesigningandimplementingahighfidelityprototype.

For the design of the prototype system,we selected components from similarsystems(e.g.TheSalfordDiabetesInformationSystem[10]).Weplannedtohaveawebinterfacethatdisplayeddatatakenfromavarietyofsensorsandprovidethe ability to the users to search through this data using a number of searchcriteria.

11

We also had some informal interview sessions with two doctors outside ofworking conditions to gather their thoughts on how the system should beimplemented. In the interviewwe explained the project proposal. There inputwasthattheythoughttheprojectwasveryinteresting,buttheyworriedthattheprojectwouldnothaveanyrealindustryuseifdisplayingsensordataweretheonly focus of the project. We took what they said into consideration andproceededtodesigntheprototypewebsite.

3.3ImplementationOfthePrototypeAmedicalsystemwillstorelargequantitiesofdata(Images,patientrecordsetc.)andthusneedstoplayahugepartinconsideringasolution.TherearecurrentlyanumberofdatabasesystemsavailableonthemarkettodaysuchasMicrosoftSQLServer,OracleSQLandMySQLdatabasesystems.Itwasplannedatthestartoftheprojecttouseapeer‐to‐peerdatabasesystemtostoreECGdataforscalabilityreasons.

The prototype website implementation was accomplished using HTML,(Hypertextmarkuplanguage)theforemostlanguageusedforwebpages[14].Itallows users to create structured documents by specifying semantics for textsuchasheadings,paragraphs,listsaswellascreationofexternallinks.Itallowsimagesandobjectstobeembeddedandcanbeusedtocreateinteractiveforms.

The prototype website itself used images of data rather than actual data andlackedtheabilitytoactuallyprocessdata.Thereasonbehindthisdecisionwasforrapiddeploymentoftheprototypecoupledwithouruncertaintyofwhetheror not ourprototypewouldbe favorable towards thehealthcareworkers. ThescreenshotsoftheprototypesystemcanbefoundinFigures1‐4.Theprototypeitselfoutlinedthecapabilityofthewebsitetodisplaythesensorinformation.

Figure1.Loginscreen

12

Figure2.TheHomePage

Figure3.SearchScreen

13

Figure4.AnExampleofaPatientRecord

Thescreenshotsshowtheloginpage,Figure1,wherewewouldexplainthateachuserhadthereownlogindetailsthathadtobeenteredinordertoaccessthewebsite.Figure2,displaysthehomepagewhichservesasabaseofoperationsforthewebsite.Figure3,showsthesearchingfunctionalityenvisionedtobeimplementedinthefinalsystem,thatbeingsearchingbynameandsensordata.Finally,Figure4displayshowwethinkapatientrecordwouldlookinthefinalsystem.

3.4TestingThePrototypeInordertotesttheprototypebeforepresentingittotheusers,weranthrougheach of the pages andmade sure linkswere correctlymapping to the desiredpage.Thenextstepwastotestthisprototypeonpotentialusersandgathertheirthoughtsandopinions.

3.5UserEvaluationofthePrototypeWeinterviewedfivehealthcareprofessionalstogatherasmuchinformationaspossibletocreateaneffectivesystem.Givenourlackofmedicalexperience,theinformationwereceivedwasvaluable,anddifficulttoobtainanyotherway.

When it came down to actually speaking to the prospected users, a lot ofproblemsarose. Itwas fairlydifficult toschedulea timetoseethedoctorsandnurses,whoareverybusy.Eventuallythefiveindividualswewereseekingwereinterviewed,comprisingofthreedoctorsandtwonurses,allfromtheRedCrossMemorialHospital,CapeTown.

The prototype website was taken to the healthcare workers and demoed tothem,thiscoupledwithaquestionnaire(AppendixA),formedthematerialthatwastobeusedtoconducttheinterview.

14

3.5.1GeneralObservations

Unfortunatelynophotographswereallowedtobetakeninsidethehospital.Thefirst thing that was noticed when entering the hospital was a lot of peoplewaiting at the reception area. One individual standing in themultiple queueswasquestionedonwhatshewaswaitingfor,andshepromptlyrespondedthatshewaswaitingforherpatientrecordtobefoundandshehadbeenwaitingforat least ten minutes after which she expressed her discontent. The hospital’srecordsystemwasfullypaper‐based,withtheexceptionofthefinancesystem.

The general course of events from when a typical patient enters the hospitaluntilwhenhe/sheleavesissummarizedinFigure5:

Figure5.CurrentSystemActivityDiagram

Analysisofthisdiagramshowsaheavyrelianceonphysicaldeliveryofthefiles.Ateachof thesepoints, the riskarises that filesaremisplacedor lost ‘underastack of other files’ as one doctor put it. This is particularly the case when itcomes to theexternaldoctors, i.e. sometimes tests suchasx‐raysoccurbutdonotgetrecorded.

The roles and responsibilities of the actors in the current system aresummarizedinFigure6.

15

Figure6.CurrentSystemUseCaseDiagram

Fromthisdiagram,onecanseehoweachroleinteractswiththesystem.Specialattentionmustbepaidtothefactthatapatientcannoteverreallyseetheirfile,andthatthesystemisentirelypaper‐based.

3.5.2Interviews

Thefirstintervieweewasapediatricdoctorwhohadalsospentsometimeintheintensive care unit. Shewas very interested in the system and offered a lot ofsuggestionstoaddonceeverythinghadbeenexplained.Shenotedthatmostofthehistoryof sensorbased informationwasnotveryuseful todoctorsas theywouldprefertotaketheirownpresentdata.Theexceptionswerebloodpressurelevelsandbloodglucoselevelsindiabeticpatients.Shealsostressedtheneedtoupgradethehospitalsrecordsystem,asitwasverycumbersome.Shestatedthathospitalswouldbethemainusersofsuchasystem,asopposedtooldagehomesorpatient’shomes,andsaidthatitcouldeasilybeextendedtoaprivatepracticeaswell.Shethoughtthatbothnursesanddoctorswouldmakeuseofthesystem,but nurses slightly more. When asked if she foresaw any problems with thesystem, she noted power outages and system failure as they main points ofconcern. She thought that only doctors and nurses should be able to view thepatient data, given its confidentiality, and that password protection should besufficient.OtherFieldssherecommendedwereHospitalIDnumberandDateofbirth.Shealsonotedthatshecouldnotthinkofapracticalsituationwhereonewould need to query patients based on vital signs, unless it was for researchpurposes.Thusthesearchfunctioncouldbesimplifiedtosearcheitherbyname,surname and hospital ID (A number each patient is assigned to avoid namecollisions). She said if we were to pursue the system to be used for researchpurposes then to condense the searchcriteria into comboboxesotherwise the

16

interface would get too cluttered. She then suggested that by changing thedirectionof theproject to focus onpatient recordmanagement, amoreusefulsystemtothehealthcareworkerswouldemerge.

Thesecondintervieweewasanotherdoctorwhodealsmainlywithrespiratoryinfections. The doctor was a little intimidated by the demonstration of theprototype. She thought the only important sensor to usewas the temperaturesensor, and that all the other sensorswere very specialty specific, i.e. ECG forcardiologists. She said that such a system could fit in any clinical setting. Shethought that mainly doctors would use the system. She couldn’t think of anyproblemswiththesystembutsaiditwouldbeasteeplearningcurveforher,asshedidnotliketousecomputersverymuch.Shesaidthatweshouldaddsomefunctionalitytorecordnotesfromapatientconsultationtothepatientrecords.

The third interviewee was a nurse who had grown accustomed to the paperbasedsystembutthoughtthe ideaofmodernizingtoreducewaitingtimesandease searching for records was a brilliant idea. She said that she would beinterestedinseeingmainlybloodpressuredataandanyabnormaldatafoundintestprescribedbydoctors.Shealsosaidthatthesystemcouldbeimplementedinanyhealthcarecentre.She thought thatbothdoctorsandnurseswouldusethe system equally. Her concerns for the system were the effort required intrainingthestafftousethesystemandthecontingencyplansforsystemfailure.Shealsosaidthatthesystemshouldfindtherecordsinatimelymannerandifitdid this it would be ‘brilliant for administration’. In terms of access to theinformation, she thought that thenurseswouldaccess certain informationandmoreinformationwouldbeaccessibletothedoctors(Consultationnotes).Thusatwo‐tieredsecuritysystemwouldneedtobeputintoplaceforaccesscontrol.Shesaidthatthesystemneededtoincludeinformationaboutdiagnosisdonebythedoctoraswellas ifanyexternaltestsweredone(e.g.x‐raysultrasoundetcwith dates included). Her final thought was that the patient should also beinformedofwhatisgoingonandsomeformofinformationdivulgedtothem,herexamplewasonhowtousecertainmedication.

Thefourthintervieweewasanallergyspecialistwhohadmanythoughtsonthetopic.Shehadheardofelectronicallyupdatingpatientrecordsandthemeanstousethemonline,andwaswaitingforsuchasystemtocometoSouthAfrica.Shethoughtthatsensorinformationwasnotparticularlyusefulandthatbackgroundhistoryofthepatientswasmoreimportant.Thiswastoincludepreviousseriousillness diagnosis and any ‘red flags’: that being allergies, drug cross‐reactionsensitivity,diabetesandHIVdiagnosisetc. Shegaveanexampleofanoldmanthathad18visitswithdifferentdoctorswithinthehospitalandasaresulthadahugefile thatwas incrediblyhardtouse,andthuswassentona fewduplicatetestsandx‐raysfornoreason.Thusasystemthatoutlinedimportantdiagnosisonacomputerscreenwouldmitigatesuchasituation.Shethoughtthebestplaceto install thesystemwouldbe inadayhospitalorgeneralpractice.Shestatedthat nurses and doctorswould use the system equally. Hermain concernwasconfidentiality, and that a two‐tiered system needed to be put into place thatallowedaccessbasedontheindividualloggingintothesystemandthusdisplayonlyrelevantinformation.Intermsofsearchingfunctionality,shesaidtoremovesearchingforspecificvitalsigns.Patientnamesearchingshouldstillbepresent

17

aswellasIDsearches.Shesuggestedthatanextensiontothesystemwouldbetolink it to the financialsystemaswellas thepharmaceuticaldispensingsystem.Forfinanceitcouldhavecertainbillingconditionsoutlineontheform(e.g.ifthepatienthasmedicalaidornot)Thepharmaceuticaldispensingsystemcouldbeputintoplacesoastoalertdoctorsifbadreactionswilloccurifcertaindrugsareprescribed that do not go well together. The doctor concluded that if anelectronicpatient systemwere toexist itwouldsavecostand time.Shestatedthatcurrentlytheyhavetorelyonfilesbeingdeliveredthroughoutthehospitalthat take a day on average to obtain, or through tedious phone calls inemergency situations. She further stated that investigations would not berepeated and thatwe should also add a section fordoctornotes (Consultationnotes).

The final interviewee, a nurse, had very similar viewsonwhat theprospectedsystemshouldbe.She,too,thoughtitshouldbeimplementedinahospital.Shealso thought that most sensor data was not too useful and should rather besubstitutedwith patient history ofwhat tests and the results they underwent(e.g.patientwentforachestx‐rayfortuberculosisandwasfoundtobenormaletc.).Shethoughttherewouldbeequalusageamongstthestaffandcouldnotseeany problems with the system. She thought a password system should besufficientforkeepingfilessecure.

Itwasinterestingtonotethatallthreedoctorshadheardofanelectronicpatientrecordingsystembefore,whereasboththenurseshadnot.Thisisprobablyduetothefactthatthedoctorsaremoreinternationallyexposedtotechnology.

3.6UserRequirementsConclusionsThus,fromtheuser’sspecificationswecanseethatthereisaneedtoupdatethecumbersomepaper‐based filing system into an electronic system.The focus ofthe system would be to display patient diagnosis data and external test dataratherthanjustvisualizationsofsensordata.Securityshouldplayahugepartofthe system and the users themselves suggested an access control list type ofsecuritysystemallowinglevelsofdatatobeaccesseddependinguponthelevelofclearanceanindividualhad.Thegeneralconsensuswasthatanelectronicwebbased system, would save time and money for both patients and staff. If aneffective system were to exist, the hospital would run much more efficiently,thereby improving the livelihood of patients and allow the health careprofessionalsameanstodotheirjobsmoreeffectively,thusitisjustifiedtocarryonwithanother,morerefinediteration.

18

3.7DesignofTheNewSystemThesecondIterationinthelifecycleofoursystembeganbytakingthespecificationsobtainedbytheuserswhileevaluatingthehighfidelityprototypeandoutliningthenewsystem,whichisawebbasedpatientrecordmanagementsystem.

3.7.1ComponentsofaWebApplicationMost Web applications utilize a three‐tiered architecture: the main interfacelayer which users interact with, the business logic layer which handles userqueriesandactions,andthedatalayerwhichisresponsibleforstoringthedatatobeusedintheformofadatabase

PHP is a widely used, general‐purpose scripting language that was originallydesigned forwebdevelopment, toproducedynamicwebpages.ThusPHPwaschosen rather thanHTML for the final systemdesign, as it is amorepowerfullanguage to process forms and link to databases, thus allowing morefunctionality. Security implementations would also be more robust in a PHPpage,thusstrengtheningthereasonforthechange.

3.7.2SecurityandAdministratorsAspreviouslymentioned,securityisveryimportantwithinthesystem.Various‘layers’ofsecurityneed tobecreatedaccording to theuseraccessing thedata.Thus an access list needs to be created. Currently the system has minimalsecurity features and files are kept in a filing cabinet. A web interface willimprovesecurityfromwithinthesystem,asitwillrestrictaccessofthesefilestoonly the relevant people via a password protection scheme. There is neverperfect security however, as it is always possible to break ones password, butwithproperinstructionsonpasswordcreation,itcouldprovetobeverydifficulttodoso.

Anadministratorroletomonitorthesystemwillbecreated.Thisadministratorwill be responsible for managing access control lists as well as generalfunctionalityofthesystem.

3.8OverallSystemDesignFromtheabovefactswecandevisethewaytheparticipantsinthenewsystemshouldbeinFigure7:

19

Figure7.ProposedSystemUseCaseDiagram

Themajorchangesfromtheprototypeare:

• The fact that a newactor is introduced to the system: an administratorwhosepurposeistomanagethesite,aswellassetupthesecuritylayerswithin the system. If one individual needs to accessmore data about apatientthantheyhaveaccessto,theywouldcontacttheadministratortogetclearance.

• Apatientcanviewcertainbitsofhis/herfileaswell.• Everything is now electronically based, thus hopefully easier to access

andbackup• More emphasis on creating a patient record management system, as

opposedtosensormonitoring• Modifythesearchingtobebynameratherthanbysensordata

Thesechangeswere justifiedbyanalyzing theuser feedbackgiven tous in theprecedingiteration.

20

Thesystemitselfwillbeasfollows:

Figure8.DesignClassDiagramoftheProposedSystem

The design class diagram in Figure 8 outlines the overall structure of theproposedsystem.Thesystemwillrelyondifferentclassesofpeople.Asseenintheusecasediagram, thesedifferentpeoplewillhavedifferentabilitieswithinthesystem.Animportantnoteisthateachoftheseclasseswillbeallowedaccessto certain files i.e. a patient has access to only their own file, nurseswill haveaccess to all files but not consultation notes and doctors will have access toeverything.Administratorswillhaveaccesstotheadministrationsectionofthesystemwheretheyhavetheabilitytochangeaccessrightsandmanagetheusersof the system. Each individual would have to be given a unique identifyingnumberaswell.

A session is a single instance of theweb site, andhencemultiple sessions canexist.ThewebsiteusesalocalserverthathoststhewebsiteovertheInternet.

Toconclude,asummaryoftheproposedsystemistoupdatethecurrentpaperbasedsystemwithinahospitalintoanelectronic,dynamicsystemthatcatersfortheneedsofthehealthcareprofessionalsfoundduringtheanalysisstage.Theseneedsinclude:

• Variouslayersofsecurityimplementedbydividingthewebsiteintoclearareas that can only be accessed by certain roles, e.g. doctors can haveaccesstoallpatientdataandconsultationnotes,whereasnursescanonlyaccessthepatientdata.

• Abilitytocreate,read,updateanddeletefileseasily• Abilitytosearchthroughfilesquickly• Abilitytoaddconsultationnotestoapatientsfile

21

• Abilitytostorerelevantdataaccordingtothepatient,e.g.bloodpressureataspecificvisit

• HavetheAdministratormanagetheusersofthesystemeasily• Havetheusersselfregisterinordertousethesystem

3.9DatabaseDesignThe database containing all the user and patient data forms the heart of oursystem and thus special attentionmust bemade in designing the tables to beusedbyoursystem.Thesystemwouldrequiretheuseofthreeseparatetables,with foreignkeys to link the tables together.A tablewouldbecreated tostoretheuserdata, i.e.thedatarequiredforanyusertologintoandusethesystem.The second table to create would be a patient table storing all the necessarydetailsapatientinahospitalsettingmighthave.Thefinaltablewouldbetostoretheconsultationdatathatapatientwouldhavewithadoctor.Thetablestructurecan be summarized in the following entity relation diagrams; PK indicates theprimarykeyforthetablesandFKaretheforeignkeystolinkthetablestogether:

Figure9.EntityRelationDiagramoftheDatabaseourSystemuses

22

3.10WebsiteDesignThewebsitewasdesignedtohavethefollowingstructure:

Figure10.Statusselect

Figure 10 shows the idea that a prospective user of the system will choosehis/herstatusinordertoentertherelevantsectionofthewebsite,eachsectionisplannedtohavealoginscreentofilteroutunwantedguests.

Figure11.Doctor/Nursesection

Figure 11 shows the capabilities and sequence of events a healthcare workergoesthroughwithinthesystemwhereeachbubblerepresentsanewwebpagewithinthesite.

Figure12.PatientSection

23

Fig 12 shows the capabilities a patient can use in the system, i.e. only viewhis/herownrecord.

Figure13.AdminSection

The Admin section allows the admin to edit the users of the system, thuscontrolling access to the system, aswell as deleting any users that should noteveryusethesystem.

3.11SystemRequirements

3.11.1HardwareRequirementsAs the system is an electronic recordmanagement system, therewill be somebasichardwarerequirements:

*Acomputerserver: ‐Usedtostoreall theE‐HealthWebsite files includingtheMYSQLdatabasewherepatient consultation anduserdatawill be stored.ThisserverwillthushosttheE‐Healthwebsiteforthehealthcareworkerstoaccess.

*A Reliable ADSL router or other form of Internet connectivity: ‐ This will beused inconjunctionwith theserverso that theE‐Healthsystemisonlineatalltimes

3.11.2SoftwareRequirementsThe software required in order to operate the E‐Health record Managementsystemisasfollows:

*TheActualE‐HealthPHPpages loadedonto the server: ‐This includesall thenecessaryinterfacesthatinteractwiththeHealthcareworkersandpatients,aswell as the back end administration system that deals with the user accesscontrols

24

*Database software: ‐ The database software used is MYSQL server. MYSQLserverisafreeopensourcepackagethatistrustedandwidelyimplementedbymanywebdevelopers. In order to use theMYSQLdatabase easier, a graphicaluserinterfacecalledPHPmyadminwasusedtointeractwithMYSQLtocreatethenecessary tables to be used as outlined in the design chapter. MYSQL can befoundatwww.mysql.comandphpmyadminatwww.phpmyadmin.net

*WebserverSoftware:‐InordertohosttheWebsiteserversidesoftwareneedstobeinstalled.ThewebserverdirectsallincomingtraffictotheappropriatefilebyusingtheserversIPaddress.WedecidedtouseApachewebserver,alsoopensource and widely used. Apache is available at http://www.apache.org, onceinstalled, theapachewebserverneededtobeconfiguredtohandlePHPpages.Adding a PHP package to the web server did this. This was found athttp://www.php.net.

3.12DatabaseSecurityEnteringinausernameandapasswordaccessestheMYSQLdatabaselocatedontheserver.ItisenvisionedthattheadministratoronlywouldhaveaccesstotheMYSQL database and it is his/her responsibility to assign an appropriatepasswordtoaccessitandchangeitonamonthlybasistopreventanybodyfrommaliciouslyenteringthesystem.

3.13ConclusionThenextstepinthesoftwaredevelopmentlifecycleistotakeallthedesignspecificationsoutlinedbytheusersandimplementtheminaworkingsystem.Wefeelconfidentthatwehavedesignedasystemthatwouldmeettheusersrequirementsandimplementationcanproceed.

25

4.0Implementation

4.1IntroductionThischapterbuildsupontheprecedingchaptersdesignspecifications,andoutlinesthestepsweundertooktocreateaworkingsystemaswellasillustratethewebsite’sfunctionsandfeatures.

4.2TheImplementationProcessIn order to begin the whole process all the necessary software needed to beinstalled onto our testing server. Once MYSQL and Apache was installed andconfigured, the tablesoutlined in thedesign chapterwere created to store thedataenteredinbythewebsite.

The next step was to create all the necessary PHP pages to be used as thewebsite.

The website development was divided into four sections, namely the patientaccess record section, the Doctor/nurse system section, the userregistration/loginsectionandtheadminsection.

Figure14summarizestheentirewebsiteintheformofasitemap.

Figure14.SiteMapoftheE­HealthWebsite

26

4.2.1TheUserRegistration/LoginSectionThissectionofthewebsitedealswithcreatingusersthatwillusethesystem(i.e.thedoctors,nursesandpatients)thuswebpagesinthissectioninteractwiththeuserstablecreatedintheMYSQLdatabase.Thesectionalsodealswithverifyingtheusersofthesystemsothatthereisalayerofsecurityinplace.

A simple login screen,Figure15,was createdprompting theuser to chose theareaofthewebsitehe/shewishestovisit.

Figure15.Loginstatusscreen

Oncetheuserchosetheappropriatelink,he/sheisredirectedtotheappropriateloginscreen.

Patientsarepromptedtoentertheirlogindetailsi.e.usernameandpassword,inorder to access their own individual record. If they do not possess logininformation,theyhavetoregistertheirnameinthesystem.Aregistrationpagewascreated,Figure16, such that thepatiententersall therequired fields.Thepatient is stored in thesystemand their status is set to ‘patient’meaning theyonly have access to their individual record and not the actual patientmanagementsystem

27

Figure16.Userregistrationscreen

TheregistrationpagemakesuseofanumberofPHPfunctions.FirstlyitusestheINSERT SQL command to insert into the users table. Secondly it checks theexistenceofduplicateusernamesandpromptstheuserifoneisfound,thisissocollisions cannot exists and data integrity is always intact. The third functionencrypts the users entered password and stores it in the database as anencrypted string. The encryption algorithm used is a one‐way AES encryptionalgorithm.Thisprovidesahighlevelofsecurity,aseventheadministratorwouldnotknowwhattheuserpasswordis.Thedownsidetothisisthatifauserforgetshis/her password itwill be impossible to retrieve. To counter this it is hopedthattheuserwill fill inthecontactdetailssectionof theregistrationformso ifthisproblemarises,theadministratorcanissueatemporarypassworduntiltheusercanchangeitagainmanually.Inordertopreventunnecessaryspammingoftheusersdatabase,manyinputvalidationchecksareused.Thefirstofwhichisthatauseralwayshastoenterafirstname,surname,dateofbirth,passwordandusername,asthesearevitalfields.Theuseralsohastoenterthepasswordtwicesoastopreventtypographicalerrorsofthepasswordasthefieldismaskedandtheuserhasknowwayofseeingifhisorherpasswordisspeltashe/shewished.The format of the date is also checked. If any mistakes do occur the user isnotified of what the error was and is asked to rectify it. The username andpasswordlengtharealsocheckedtomakesurethatasecurecombinationexistsand a username and password less than 6 characters is disallowed. Figure 17showssomesampleerrormessagesgeneratedwhensomefieldswereleftblank.

Figure17.UserRegistrationscreenwitherrormessages

The exact same process outlined above is used for the health care workerregistration.Theexceptionbeingisthatthestatusoftheuserintheusertablein

28

thedatabaseissetto‘unknown’andtheuserwillnothaveaccesstoanypartofthe system. This is to prevent any random individual from accessing theconfidential information present in the system. The administrator then has tophysicallyverifythehealthcareworkerbycontactinghim/herandcheckingthatitwasactuallythecorrectindividualtryingtoregisterintothesystem.Oncetheuser is verified, he/she has access to the system with that username andpassword.

The admin login screen is a simple login area that checks the administrator’spassword and verifies that he/she is actually the administrator. Theadministrator is assumed to be a trusted individual hired by the hospital tocontrolwhohasaccesstothesystem.He/shecannotactuallyaccessthesystemitselfbutcontrolswhocan.

4.2.2ThePatientRecordAccessSectionOnceapatienthasloggedintothesystemsuccessfully,he/shehasonlyaccesstohis/herrecordfullyandnotthesystemitself.Thewaythisoccursisthroughtheuseofasharedkeywithinthedatabase.Thepatiententershis/herusername;this username is checkedwith the username of the patient file in the Patientsdatabase.Thedatapertainingtothatpatientisthendisplayed.Inordertogettheconsultation data, another shared key, the patientid, is used. A record setcontaining each consultation that the patient has undergone is displayed. Anavigationbartopagethroughtheconsultationsisalsoprovidedaswellasthenavigation status (i.e. total number of consultation’s andwhich consultation isdisplayed). Almost all data displayed is dynamic and is received from thedatabase, e.g. all the fields are filledwith the relevant data and the patient isgreetedbyname.

TheSQLqueriesusedtoextractdatafromthedatabaseareasfollows:

Forthepatientinformation

SELECT patientid, name, surname, chronic_conditions, medication, allergies,username

FROMPatient

WHEREusername=colname

Andfortheconsultationinformation

SELECT*

FROMConsultation

WHEREpatientid=colname

ORDERBY`date`DESC

Wherecolnameisthepatientidnumberoftheloggedinuser

29

Thereisalsoalogoutfunctionthatclearsthecolnamesothatanotherusercouldlogintothesystem.

4.2.3TheDoctor/NurseSystemSectionOnce the doctor/ nurse logs into the system, he/ she is taken to the systemhomepage.Asessionvariableiscreatedstoringtheusersstatus(i.e. ‘doctor’or‘nurse’) Session variables are variable PHP uses to keep track of data acrossmultiplepages, thiswaywe can restrict access to certainpagesby imposing acriteriauponthemthatthesessionvariablehastomatch.

The homepage, Figure 18, basically sums up what each tab in the systemnavigationbardoes.There are three tabs that theuserwouldbe interested inthat direct the users to different parts of the site. The first of which we willdescribe is the 'createpatient' tab.Theaddpatient tabworks inaverysimilarwaytothecreateuserfunctionintheloginscreen,thedifferencebeingthedataentered,andthetablethedataisinsertedto.ThedataisinsertedintothePatientdatabase, and it toomakesuse of the input validation checksused in theuserregistrationsection.Thehomepage isalsowhereauserwouldgo toviewECGdataofapatientprovidedbytheothersectionsoftheE‐Healthproject.

Figure18.PatientRecordManagementHomePage

Thenextsectionisthelistpatientssection,Figure19,thislistsallthepatientsinthe system in groups of 10. This functionality was primarily envisioned to beused to edit patient data, e.g. add a chronic illness or a change a name etc. Anavigation bar alongwith status similar to that in the patient access record isalso implemented.Eachpatientnamehasa link to theeditpatientdatascreenwherethesechangesoccur.Aredirectpageoccursbytakingthepatientidofthename that is clicked and attaching it to the URL string, as seen in Figure 20,wherethenextpagereads itandoutputs thenecessarydatapertainingto thatpatient id in the form of an edit patient screen, Figure 21. An update SQLcommandisexecutedwhenthedetailsareedited.

30

Figure19.ListAllPatients

Figure20.URLhighlightingPatientIDcarriedovertonextpage

Figure21.UpdatingthePatientInformation

Thenextsectionofthesystemisthesearchforrecordsfunction. Ahealthcareworkerwillenter the lastnameof the individualathand,anda listofpatientswillcomeup.Thecorrectpatientischosen(identifiedbythefirstnamesurnameanddateofbirth)andthecorrectdetailedpatientrecordisloaded.

31

Figure22.SearchingForApatient

Itisthroughthisfunctionthatanewconsultationiscreated.Inthecurrentpaperbasedsystem,apatientcomesinforaconsultationandthedoctorhasaccesstohis/herfile.Thedoctorthenmightdecidetogothroughthisfilebeforestartingthenewconsultation.Weachievedasimilaroutcomewithoursystemthatbeingalltheconsultationsaredisplayedonebyoneinchronologicalorder,andthereisa link to start a new consultation just underneath the past consultation data.Patientallergies,medicationandchronic illnessesaredisplayedatall times,asthiswasafeaturerequestedbythehealthcareworkersduringthedesignstages.

Thepatientrecord file isexactly thesamefileasaccessedbythepatientswiththeexceptionofthelinkforcreatinganewconsultationavailable.Thereisalsoanaccessconstraintbasedonthesessionvariablewithinthepage.Nursesonlyhave access to patient data namely chronic illnesses,medication and allergies,whereasdoctorshave access to the full record.Nurses also cannot createnewconsultations. This is achieved by using PHP code to set up an access regionwhere restricted data would go. Figure 23 outlines this by showing the exactsamepatient record, only one is accessedby adoctor,whereas theotherby anurse.

32

Figure23.Sidebysidescreenof thesamepatientrecordbutaccessedbyusersofdifferingaccesslevels.Thedoctor’sistheleftscreenwhereasthenurse’sistherightscreen.

A doctor can create a new consultation to be entered into the database byclicking on the designated link; he/she is then envisioned to fill in the blankconsultation form throughout the actual consultation. The data is then savedwiththeassociatedpatientid.

Figure24.BankConsultationscreen

4.2.4TheECGDisplayAlthough thehealthcareworkersdidnotplaceECGdatadisplayatapremium,westilldecidedtoimplementitandprovideitasanovelfeaturetooursystem.SensorsthatsendthedatatoaPDAgathertheECGdata.ThePDAthensendsthisdatatoapeer‐to‐peerdatabase.Thispeer‐to‐peerdatabasethensendsanXML

33

file to the server on demand containing the desired ECG data to be displayed.Othermembersintheproject implementedtheECGdatacapturingstoringandsending.Thejobofthewebinterfacewastodisplaythedatasentinthexmlfile.ThiswasdonebyreadingintheXMLfilethenpassingthedatatoGooglechartsAPI in the form of a string. The Google Charts API returns a graph with therelevant data plotted onto a curve. The Google charts API is a free InternetservicemadebyGoogleforwebdeveloperstodisplaydatagraphically.Thewebdeveloper specifies the chart type, size, colors and data to be displayed. Theresultofasuccessfulrequestresultsinagraphbeingdisplayedasanimage.

Our interface takes each node in the xml file, and then displays the dataaccordingly.OnehastobeconnectedtotheInternetinorderforthegraphtobegenerated.

4.2.5TheAdminSectionAfter an administrator has logged on he/she is presentedwith a list of all theusersofthesystem.He/shethencaneditthedetailsorremovethementirelyinthecaseofa fraudulentuser.Theeditdetails screen iswhereanUPDATESQLcommand is executed according to the userid. This is also where he/shevalidates unknown users in order to gain access to the system. Delete userexecutesaDELETESQLcommandaccordingtotheuserid.

Figure25.Listingtheusersofthesystem

34

Figure26.Editingtheusersstatustoenterintothesystem

4.2.6OtherWebsiteFunctionsThroughout thewebsite other functionality has been implemented in order tomakethewebsiteasuserfriendlyaspossible:

*Errorscreenswhen loginhas failed that linkback to thepreviouspage forallthreeloginareasofthewebsite.

*Anavigationbarwithinthesystemthatstaysconstantthroughoutthesession.

*A more aesthetically appealing and logical organization of the site whencomparedtotheprototype.

*Theabilitytologoutatanytime.

4.3ConclusionTheimplementationofoursystemwentbyaccordingtotheplanslaidoutbyourdesign chapter, and we feel positive that we have addressed the usersrequirements in order to create a useful system. The next step in thedevelopmentlifecycleistotestoursysteminavarietyofwaystoensureastableenvironment is present, as well as to confirm all the user requirement’s havebeenmet.

35

5.0TestingandEvaluatingOurSystem

5.1IntroductionThischapterdealswiththestepswetookintestingoursystemtomakesureitwasfreeofbugsandtoensurethesystemdidwhatitwassupposedtodo.Afterwhichitoutlinestheusertestscarriedoutandthesubsequentresults,thenfinallythechapterendswithhowweimplementedthechangessuggestedbytheuserstocreatethefinalsystem.

5.2SoftwareTestingBeforereturningtothehospital,extensivetestingwasaccomplishedinordertomakesurea fully functioningsystemwaspresentedtothehealthcareworkers.Weranaseriesofwhiteboxandblackboxtests.Whiteandblackboxtestsaresoftwareengineeringterms,wherewhiteboxtestingteststheinternalstructureof the code, and black box tests the external structure (e.g. the user interfaceinteractions).

We tested the systemduring the implementationphase of the iteration, asweaddedfunctionalitytothesite,andwassatisfied.Butweneededtorunthroughall the functions again to see ifwehad overlooked anything and to see howauserwouldinteractwiththesiteinitsentirety.

Wefirsttestedallthelinkswithinthesitetoseeifeachonemapscorrectlytothedesiredpage.Wedidthisbystartingattheloginscreenandsystematicallygoingthroughthewebsiteonesiteatatime,oncehappywemovedontothenexttestcase.

We then tested theuser registrationsystem.Firstweenteredall thedetails inthe fields as onewould in the realworld and see if it actually added it to thedatabase, which it did.We then added the exact same user details within theformtoseehowtheformwillhandletheduplicate,sureenoughitthrewanerrorandinformedusthataduplicateusernamewasbeingusedandthedetailswerenotsavedtotheuserstableinthedatabase.Wealsoproceededtotesttheothererror functionalitieswe had codedwithin the form, all ofwhich performed toexpectations.Itwasalsonotedthatwhenauserregistersherehis/herstatusissettopatientautomatically, thiswasverifiedtobetrueandthenextsectionofthe site was tested. We also checked the password string saved in the userdatabase. The expected outcomewas a string of indiscernible data,whichwasnoticed.Thiswasusedasanencryptiontechniqueforthepassword.Thesystemuses this string of data to log into the system this was checked and only theencryptedstringwouldwork for logging in ( i.e. if thepasswordwasmanuallychangedtosomethingitwouldnotwork,onlyifitwasenteredandencryptedbytheuser).

Thenextformwetestedwasthedoctor/nurseregistrationform.Itwastestedinexactly the samewayas thepatient registration form, althoughwe checked tosee if the status of the doctor/nursewe had entered inwas set to ‘unknown’,whichitdid.

36

Thenextstepwastotesttheadminsectionofthewebsite.Theloginusernamewassetto‘admin’,andthepasswordwas‘ehealth’,wefirsttriedtouseawrongnameandpasswordtologin,butwasmetwiththeappropriatebadloginscreen,wethenusedanameandpasswordthatwasalreadyinthesystem(adoctorwehad previously entered in) but also was met with a bad login screen, this isbecause the status of the person logging in has to be set to ‘admin’. After thecorrect combinationwasentered thenext screenemerged.We then tested theabilitytoedituserdetails,weeditedoneoftheusersarbitrarilyandcheckedtheactualdatabasetoseeifithaddoneso.Wealsochangedtherandomusersstatusandagainthiswasreflectedintheusertableinthedatabase.Thelaststepwastodeleteauser,onceclickedalltracesoftheuserwereindeedremovedfromthesystem.

Wemovedontothedoctor/nursesectionofthewebsite.Firstwetriedtologinunderapatientusernameandpasswordandabadloginscreenoccurred,whichwas the expected outcome.We also used the admin username and password,whichwasalsosenttothebadloginscreen.Adoctorsusernameandpasswordwerethenused,thusweweretakentotheE‐HealthsystemHomepagewhereaWelcomeDoctormessagewasdisplayed.We thenchose the ‘Listpatients’Taband checked that the patients listed coincided with the patients table in thedatabase,which it did.We also created a newpatient and checked to see if itaddedtothedatabase,againtheexpectedoutcomewasnoticed.Wecheckedtheedit patient details of the website and the relevant fields of the form werepopulated by data taken from the database. Changing some of the patientinformation tested the update SQL statement and the database was updatedcorrectly.

Thesearchtabwasthenused.Firstweenteredrandomdataintothesearchfieldandtheexpectedoutcomeof0searchresultswasseen.Thenweenteredinthepatientnameweknewwasinthesystemandtheexpectedoutcomeof‘found1of1’alongwiththeappropriatelinkwasseen.Wealsoenteredinapatientnamethat we knew had duplicates present (i.e. sharing of the surname amongstpatients)andtheexpectedoutcomeofdisplayingbothpatientswasseen.Theyare easily distinguishable by their patient ID and their date of births beingdisplayedwiththesearchresultssoahealthcareworkercanchoosethecorrectpatient.

Wethenproceededtoclickoneofthenameswehadsearchedfortochecktoseeif the correct patient record was displayed. A header displaying the name ofperson thatwasclickedwasdisplayedalongwith theappropriatepatientdatafound inthepatient table.There isalsoaconsultationnotessectionwithinthepatientrecordandthiswascheckedtosee if itcoincidedwiththeconsultationtable in thedatabase,and in thiscase thepatient recordwasexpected tohavetwo consultation files,whichwas correctlydisplayed and scrolled tousing thearrowkeysonthewebsite.

Wethenclickedthe logout functiononthewebsiteandweweretakenbacktothemainloginscreen.Totestthesecurityweclickedthe‘back’buttoninthewebbrowser,butabadloginscreenwasshown,aswecodedthesystemtonotallowthis.Weenteredanurseusernameandpasswordandthehomepagegreetedus

37

with awelcomenurse header.We tested theWebsite functionality exactly thesameway as the doctor login described above and the expected results wereseen. We noted to see if our layer security system worked (Disallowing thenursesaccesstotheconsultationnotesofapatient)andsureenoughtherewasnowayofthenurseseeingthesefiles.Weloggedoutthenurseandproceededtothepatientsection.

The patient login was tested in the same manner as the other facets of thewebsite. Correct test outcomes were noticed and only the patient recordpertaining to the respective login informationwasdisplayed.The ‘patient’ hadno way of accessing any other patient files except if he/she knew the logindetailsoftheotherpatientswhichisanunlikelyscenario.

We stress tested the system by adding a relatively large number of patientrecordstothedatabase(500patientrecords).Thesystemwasabletodisplayalloftherecordswhenpromptedandwewereabletosearchthroughtheserecordseffectively.Theoreticallythesystemwouldbeabletoprocessasmanyrecordsasthe database can store and larger database size testingwould be reserved forfuturework.

Thusafterourtestingwedeemedthesystemtobestableenoughtobetakentotheactualprospectiveusersofthesystem.

5.3UserEvaluationOfTheSystemInordertotestthatthesystemisbuiltaccordingtotheusersstandards,andseeif therewasanythingtobeaddedtothesystem,anothervisit totheRedCrossmemorialhospitalwasneeded.Wemanagedtoseeexactlythesamedoctorsandnursesthatwereinterviewedinthefirstprototypeiterationplusanextranurse.Wealsoheldasmallfocusgroupsessionwiththreepatientstogathertheirideasonthepatientsideofthesystem.

Inordertogaugetheusersreactionsasurveywasformulated.ThesurveywassetinanSUSformat,whichisasurveystylethathasbeendeemedveryefficient[15],asitisbotheasytofilloutandatthesametimeathoroughevaluatorofthesystem.Thesurvey[AppendixB]consistedoftenquestions,thefirstninewereratings questions where the user was asked to rate a specific aspect of thesystemonascalefromonetoseven,sevenbeingthebestoutcomeandonetheworst.Thetenthquestionwasusedasanopenendedquestiontogatherexistingthoughtsonhowtoimprovethesystem.

Theway the interviewwas conductedwas to have the users run through thesystemfunctionalitieswhilewewerepresent.Weansweredanyquestionstheyhadaboutcertainfunctions,thoughtherewerenotmanyasthesystemprovedto be very intuitive. The users were then presented with the user evaluationsurvey.

Thesurveytouchedonanumberofpertinentissuesthatwereaddressedbythesystem.Theseissuesincluded:

*Howthesecurityoftherecordswerehandled.

38

*Howusefultherecordmanagementsystemactuallyis.

*Gaugingthelearningcurverequiredinordertostartusingthesystem.

*Overallefficiencyandeaseofuseofthesystem

*Theoverallaestheticappealofthesystem.

5.3.1ResultsoftheSurveyTheresponsetothesystemwasgenerallyverypositive,butafewconcernswereraisedthatneedtobeaddressedinthefinaliterationofthesystem.

TheUsers as awhole felt very satisfied after using the system, they found thesystemveryeasytouseandnavigateacross.Theygenerallyfeltthattherecordmanagementsystemwouldimproveefficiencygreatly.Onenursecommentedonhow she did not think such a system could exist in South Africa and ifimplementedforrealmightprovideahugebenefit.

The security aspect was also deemed to be handled very well, although onedoctorveryrightlypointedoutthattherearealwayswaystobreakthesystembutshe laterconcluded thatwhatoursystemhandledsecurityadequatelyandtherewashardlymuchelsewecouldaddtoimproveonitthatshecouldthinkof.

Thesystemwaspraisedasveryeasytolearnanduseandonenursesaidthatitwasabreathoffreshairwhencomparedtootherhighlyconfusingsystemsshehadworkedwithinthepast.

The visual appeal of the site was also very positive and the site map wasreportedtobedesignedwellandlinkswereplacedinalogicalmanner.

The results of the survey [Appendix B] can be summarized in the followinggraphs,onebeingthelowestscoreandsevenbeingthehighest:

Figure27.Doctoranswers

39

Figure28.Nurseanswers

Asonecanseefromtheabovegraphs,resultswereextremelyfavorabletowardsthesystem.Questiononeofthesurveydealtwiththeoverallsatisfactionofthewebsitesystemthattheytested.Theaverageanswerforalltheparticipantswas6outof7,indicatingthatuserswereveryhappywiththesystem.

Thesecondquestiondealtwithhoweasyitwastonavigatethroughthesiteandhowlogicallythesitewaslaidout.Thisscoredveryhighlywithallthehealthcareworkers surveyedwhich is very encouraging as it confirmswehave created averyuser‐friendlysystem,

Question three queries how useful a patient recordmanagement system is tothem;thequestionwasputintoseeiftheusersstillfeltthatthesystemwouldbeusefulastheydidatthestartofftheproject.Theresultingaverageof6.5outof7confirmsthisstatement

The fourth question dealswith rating the security features of the system. Theconsensuswasthatitwasimplementedmorethanadequately,scoringa6outof7.

Userswere asked to rate the aesthetic appeal of thewebsite for question five.Theaverageanswerwas6.2andwewerecommendedbymanyoftheusersthatthesitewasveryappealingandprofessional.

Surprisingly though are some results from question 6 which deals with howmuchtrainingwouldberequiredtousethesystem.Allthenursesfounditveryeasytouse‘rightoutofthebox’whereastwoofthedoctorsthoughttheymightneedsomeonetogothroughthesystemforthembeforehand.

Question sevenwas asked to gauge the usefulness and the extent of the errorchecking and backtracking options if the user made a mistake. The resultinganswergaveanaverageof6.3and theusers thought thisaspectof thesystemwasdealtwithwellenough.

40

The eighth question had the lowest answer value. It deals with theadministrationsectionofthewebsiteandthecreationofanadministrator.Oneof thenurse’s felt that itwasnotnecessaryand that they coulddo that adminworkandsitemanagement.Shewashoweveraloneinthisopinion,astheotherhealth care workers surveyed felt that it was a good idea to add anadministrativerole.

Finally,questionninedealswiththeeaseofcreatingpatientrecordsanddoctorconsultations. This too was commented on being easy to do with an averageratingof6.5.

TheaveragesforbothgroupsislistedbelowinFigure29:

Figure29.MeanAnswervaluesforthedoctorsandnurses

Therewere,however,anumberofconcernsgivenbytheusersthatneedtobeattendedtointhefinaliteration.Mostofwhicharesmallcosmeticchangestothewebsiteand/ordatabase,theseare:

*Addition of a next of kin name and contact in the patient record (mainly forchildpatientsbutalsoextendstoadults)

*Addition of hospital name to the consultation as patients may not visit onehospitalexclusively.

*Additionofadiagnosissummarypage.Thiswaydoctorsandnursescanseeanypatterninapatient’sreasontovisit,ratherthanpagingthroughalltherecordsapatientmighthave.

*Allowthenursesprivilegetoseediagnosisandsymptomsofaconsultationaswell, in the formof thesummarymentioned in thepreviouspoint,butstillnottheactualconsultationnotes(currentlythenurseonlyhasaccesstothepatientmedicationallergiesandpersonaldetails).These fieldsweredeemed tobenotconfidentialtothenurses.

41

*Removetheprivilegeofpatientstoseeconsultationnotes.Thiswasjustifiedbyanumberofreasons.Firstlya lotofmedical jargon isusedthatwouldconfusethepatientandcouldleadtothepatienttryingtoselfmedicatethemselvesinawrongmanner.Secondlytoavoidoffendingpatients,e.g.adoctormightsaythata patient is overly obese as a cause of something. Finally to not cause anyunnecessary worry to the patient, as doctors would often times write manydifferent diagnosis’s for a symptom and patients would hone in on the worstpossiblediagnosis, e.g. cancer couldbe a reason for somethingbut is the leastprobableandpatientswouldseecancerandgetworriedunnecessarily.

*Additionofanychronicillnessinformationtoarecorde.g.ifadoctorknewthatapatientisdiabeticthenhe/shewouldbemoreeducatedonhowtoact.

Once these changeshavebeenmade, itwasagreedby theparticipants that aneffective patient record management system would result that can be usedwithinalmostanyhospitalorprivatepracticesetting.

5.3.2FocusGroupSessionAfocusgroupsessionconsistingofthreepatientsfoundinthewaitingroomwasalsocarriedout.Thepurposewastogatherapatient’spointofviewwithrespecttothesystem.Thesessionstartedoutwithademoofthesystem,followedbyasmall discussionon their views.Twoof thepatients said they thought it tobeextremelyusefulandtheothersaidthatshewouldnotuseit,butsawthevalueofsuchasystem.Thereasonthatindividualgavewasthatshedidnothavereadyaccesstoacomputerandfeltthatherdoctorvisitswerenotfrequentenoughforhertoconstantlycheckuponherstatus.Theothertwoindividualsstatedthatitwouldbe veryuseful as a reminderonwhathappened to them in thepast, aswell as seeing what medication they were supposed to be taking. All threeindividualscommentedontheeaseofuseofthesystem,andhowtheythoughtthatnothingmoreneededtobeaddedtosuchasystem.

5.4UpdatingOurSystem,theFinalIterationWewould then proceed to add theminor changes previously specified by theusers.Asthesystemwasdeemedsatisfactory,majoroverhaulingofthesystemwasnotrequired,thuswestartedthethirdandfinaliterationofoursystem.

5.4.1DesigningtheFinalChangesThe main addition specified in the second evaluation was a consultationsummarypageaccessiblebythenursesanddoctors.Afurtherrequirementwastoalterthetablesusedinthedatabasetoincludethenewfieldsrequestedbythehealthcareworkers.

In addition, after consultation with other members of the project group, adecisionwasmadetoimprovetheECGdisplaysectionofthewebsite.WewouldaddthefunctionalitytoautomaticallychecktoseeifthereareanyupdatestotheXMLfilesentbytheotherpartsoftheoverallhonoursproject.Thereasonbeingwasthatwefeltthiswouldbemoreusefultothehealthcareworkersasmoreuptodatedatawouldbeavailabletothem.Theinterfaceusedwasalsodecidedtoneedafacelifttomakeitmoreprofessionalandstreamlined.

42

5.4.2ImplementationOftheFinalSystemThefirststepwastoeditthedatabasetoincludetherequesteddata.Anext‐of‐kinfieldwasaddedtothepatienttable,achronicillnessfieldtothepatienttableand the hospital name to the consultation table. All forms pertaining to thepatienttableandtheconsultationtablewereupdatedtoincludethenewfields.

We removed the privilege of patients being able to view their doctor’sconsultationnotesbyremovingthefieldinthepatientrecordaccesspage.

We also designed a new page displaying the diagnosis summary section of apatientrecordandmadeitaccessibletobothdoctorsandnurses.Thiswasdoneusing a SELECT * SQl command and choosing the right data to populate arepeatingtable.Figure30showstheconsultationsummaryscreen.

Figure30.ConsultationSummaryScreen

ThefinalstepwastoimprovetheECGDisplaypage.Thepreviousiterationhadall thedataextractedfromtheXMLfilesentbytheothersectionoftheprojectdisplayedon thepage.This led toaveryconfusing interface thatneeded toberefined. We accomplished this by having an interactive summary table that auserclickedtodisplaytheECGgraph.Thewebpagealsonowhastheabilitytorecheck theXML file to see if anew filehasbeensent, thusupdating thepagewithouttheusernotneedingtorefreshthepage.Theupdatetimerwassettobe1minute.This timewasdecided tobe thecompromise,asashort refreshrateexerts a huge strain on theweb serverwhereas a largewait timewould haveproved pointless. The system also checks to see if there are duplicate nodeswithinthexmlfileanddoesnotdisplaythem.Figure31showstheupdatedECGdisplayscreen.

43

Figure31.TheECGdisplayScreen

5.4.3TestingtheImplementationThe main areas to test were to ensure that forms that were edited actuallyupdatedthenewfieldstothedatabase.Thiswasproventobetrue.

To test the Summary page, we added and removed consultations to theconsultation table in thedatabase andnoted if itwasdisplayedonto the tabletested the consultation diagnosis summary page. The expected outcome wasseen on all occurrences.We also ensured that both doctors and nurses couldaccessthispage.

5.5ConclusionAstheuserswereextremelyhappywiththesystemandthechangesrequestedwere relatively small,we deemed it not necessary to go back for further usertesting.

Fromthepositiveuserevaluationofthesystem,ithasbecomeclearthataviablesystemhasemerged.Wefeelthatwehaveachievedaverypracticalsystemandthatthefinalimplementationwouldbereadyforuserstoworkwith.

44

6.FindingsWe encountered a number of interesting findings while developing the Websystem. These findings would greatly help any development of a productionsystemtobeusedintheindustry.

Themaindiscoverywenoticedwhendevelopingthesystemoccurredduringtheinitialuserrequirementssectionof theprojectwhereour focuswasdisplayingdifferentdatavaluesfromavarietyofsensors.Remotesensordatawasfoundtobenotasvaluableasexpected,whereaswefoundoutthatthereisagreatneedfor a web based record system, thus this finding greatly influenced oursubsequent work. That being the main emphasis of the project shifting fromvisualizing sensor data, to creating a web based patient record managementsystem, which was thought of being incredibly useful in the currentenvironment.We initially had no idea of a need of such a system, and it wasthrough consultation with the health care workers that we were able todetermineitsvaluetotheindustry.

6.1OtherFindingsWhenAnalyzingtheCurrentSystemWe found our project to encompass a broad range of research areas: sensormonitoring, network topology, network security, human computer interaction(HCI)targetedatthedevelopingworldandwebdevelopmenttonameafew.TheHCIaspectofourprojecthasemergedtobeincrediblyimportant,asthroughourextensive usability studies,we have found a huge need to upgrade the recordmanagementsystemscurrentlywithinSouthAfricanhospitals.ThefirstworldsviewonHCI cannot totally be considered in this country as people’s views oncomputersvarygreatlyfromthewesternworld.Thusthisviewplayedapartinus creating a user‐friendly system that can easily be ported to other hospitalswithinthecountry,andpossiblythecontinent.

An interestingpoint tomention is that the interviewees’people’smindsetwasthatacomputerizedsystemcouldnotbeimplementedinSouthAfrica.Theyfeltthattechnologysuchasthiswasexclusivelyforuseinfirstworldcountries,andwhenexplainedtothemthatthissystemwasbeingdesignedfortheminmind,theywereextremelyoptimisticastheythoughthowthesystemwouldimprovetheworkingconditionswithinthehospital.

It isalsointerestingtonotethecontinueduseofpaper‐basedsystemsinmanyhospitals.Whenaskediftheythoughtofupdatingtheirsystem,intervieweesfeltitwouldbefartooexpensivetodoso,butwhenwetoldthemthatoursystemwasdevelopedusingexclusivelyopensourcetechnologyandthatthemaincostswerehardwarerelated,againtheywereshockedandextremelyoptimistic thatanelectronicupdatetotheirsystemcouldoccur.

6.2OtherFindingsDuringSoftwareDevelopmentThe effectiveness of the Open Source aspect of our project was also aninterestingfinding.Weachieveddesirableresultswithouropensourceserversand database systems without having to purchase commercial software, thussuggestingthattheseOpenSourcesoftwarepackagesrivalcommercialpackagesinquality,reliabilityandcapability.

45

During this project we developed a list of requirements for an effective web‐based system for patient records. The users placed ease of use and logicalorganization of data highest on their list of requirements for a web‐basedsystem.Someofthehealthcareworkersinterviewedhadverybadexperienceswithsystemstheyhadusedbeforehand,findingthem,extremelycomplicatedtouseandthusveryfrustrating.Securityofdatawasalsoincrediblyimportantforobvious reasons of confidentiality. Somewhat surprisingly, aestheticswas alsoplaced as a huge factor in user satisfaction, thus a sleek, professional lookingwebsiteneededtobedeveloped.

Development of an actual production systemwill face a number of challenges.Whenweaskedusershowsuchasystemcouldactuallybeimplementedwithinahospital setting, they responded that a proposal would have to go through anumberofcommitteesandsuperintendantsforapprovalandwouldtakequitealongtime.Howevertheystatedthatsuchasystemcouldbeimplementedmuchfasteratasmallerscalewithinprivatepractices,asthereisalotmorefreedomtomaneuver.Thesystemwasdeemedappropriatebytheuserstobeusedinahospitalsettingaswellasaprivatepractice.Thisisanobviousrouteforfutureprojects.

46

7.ConclusionsAndFutureWorkTheoriginalgoaloftheprojectwastocreateasystemthatwouldbenefithealthcareworkers and patients by providing a low cost system that theywould behappytouse.Webelievewehavedonethisandthatoursystemcouldbeusedinanyhealthcaresetting.Themainaimsofthesystemweretohavetheabilitytocreate,viewandstorepatientrecords.Patientrecordsconsistedofanumberofdemographicfieldsandconsultationnotes,whichwouldbestoredinadatabase.ThesystemalsodisplaysECGdatasentbyothersectionsofthesystemaswellasprovideadministrativecapabilitiestosetaccesscontrol listsoftheusersofthesystem.

The main challenges when developing the system was working around thehealthcareworkers schedule. Theywere often times understandably busy andwehadtowaitlongperiodsoftimebeforewecouldseethem.Itisalsodifficultto gauge whether we have met every single user requirement as often timesusersmighthavedifferingviewsonhowdatashouldbepresentedandwewereforcedtocompromiseoncertainaspectsofthesystem(Anexampleofthisinoursystemwasexactlyhowmuchinformationanurseshouldbeabletoaccess,soaftermuchconsultationwithdifferingindividualsasolutionwasfound).

7.1SignificanceoftheProjectThe system developed illustrates how a web‐based healthcare system wouldgreatlyimprovetheworkingconditionsofahospitalbycreatingabetterpatientcaring environment. The fact that we used Open Source tools cut down thesoftwarecoststremendouslyandisimportant,aslargefundinggrantswouldbedifficulttocomebyinSouthernAfrica.

7.2AchievementsHealth care workers were consulted in the design, implementation andevaluation stages of each iteration of the system. Thus the resulting system isonethattheywouldbehappytouse.Thesystemachievesthegoalsofbeingabletocreateandmanagepatientrecords,displayECGdatafromtheothersectionsoftheproject,providedataaccesslayers,selfregistertousethesystem,addandview doctors consultations and have administrators manage the users of thesystem.Wealsobelievewehavecreatedanaestheticallypleasingwebsitethatiseasytolearnhowtouseandcanbedeployedinathirdworldsetting.

Themethodologyweusedwasaniterativedevelopmentapproach,whichwefeltwas themost effectivemethodology to usewhendeveloping our system.Witheachsuccessiveiteration,wewereabletodeterminespecificuserrequirementsaswellasironoutanybugsandunnecessarysectionstothesystemthatmighthave occurred during development. We believe that through our iterativeapproach,wehavecreatedaviablesystemthatcanbeusedintheSouthAfricanHealth care industries today. The user involvementwas crucial in formulatingthesystemandimplementingasystemthattheythemselveswouldwanttouseandbenefitfrom.

47

7.3FutureWorkWhile theprospectiveusersof the systemdeemed theproject a success, therearestillanumberoffunctionsthatcouldbeaddedtothesystemtoimproveitiftherewasmoredevelopmenttime.Thefirstofwhichistointegratethesystemtolinkupwiththedifferentmedicalaidcompaniespresentwithinthecountry,thisway claims canbe linked electronically andwoulddecrease time taken toreimburse members. Another addition would be to link the system to apharmaceuticalprescriptionsystemthatpharmacieshaveaccessto, thiswouldreducepaperbasedprescriptionsaswellaserrors indispensingdrugs.Finallywehave created a very broad system that can be used in anymedical setting.Thereare,however,manyspecializedfieldsofmedicinethatmightwishtohavemoredatafieldswithinapatientrecord,thusanextensiontothesystemwouldbetocreateveryspecializedsubsystemsrelatedtoeachspecialistsrequirements(e.g.agastroenterologistmightrequirecompletelydifferentdata thanaplasticsurgeon).

Further testing in a clinic environment could also occur; this would probablyrevealnewrequirementsthatwouldneedtobetakencareof.Alargernumberofpatientrecordswouldalsoneedtobeaddedtothedatabasetoseeifthesystemcanhandlelargeloadsasinrealitytherecouldbethousandsoffilestobestoredandpossiblyevenmore.

Future work also includes the deployment of the actual system within thehospitaland/orclinicsetting.Wewoulddothisbyfirsttransferringthecurrentdatatheyhaveinpaperformintoourdatabases.Inordertodothisweneededtoget ethical clearance assuring the hospital that the data would be keptconfidential, which we obtained during the implementation phases of theproject.ConsultingtheuniversityethicscommitteeaswellasthesuperintendentoftheRedCrossmemorialhospitalaccomplishedthis.Thenextstepwouldbetophysicallyentertherecords.Followingthiswouldbeobtainingallthenecessaryhardware to be installedwithin the hospital then training the staff to use thesystem. Of course funding would need to be acquired to accomplish this andwould take place by formulating a business case document to present topotentialinvestorsofthesystem.

ThehealthcareadministrationproceduresinSouthernAfricaareverybackwardwhen compared to firstworld countries, andwebelieve thatby implementingthis system, we could help improve hospitals and clinics throughout thesubcontinentandpossiblybeyond.

48

8.Appendices

8.1AppendixA,PrototypeQuestionnaireE­HealthQuestionnaire.

SenaAllen,GregoryChandran,RobertKoletka

WearefourthyearstudentsattheUCTDepartmentofComputerScience.WearerunninganovelE‐healthprojecttogathervitalsignsfrompatientsinahospitalenvironment.Weuseavarietyofsmallsensors(measuringheartrate,bloodglucose,temperatureetc.)Which,whenplacedonanindividual,transmitvitalsignstoadatabase.ThisdatabasecanthenbeaccessedbyahealthcareprofessionalovertheInternetatanygiventime.

Inorderforustodevelopaneffectivesystem,weneedtodeterminewhatisrequiredforaneffectivesystem:thedata,whichwouldbeimportantandusefulformedicalpractitioners.Yourparticipationwouldbeextremelyvaluabletous.

Haveyouheardofasystemlikethisbefore?

Yes No

Pleasetickallthesensortypesyouthinkwillbemostusefulinsuchasystem.

a) ECGsensors

b) Bloodglucoselevelsensors

c) Temperaturesensors

d) Other_______________________________________________

Wheredoyouthinkthebestplacetoimplementsuchasystemwouldbe?

a) Inahospital

b) Inanoldagehome

c) Inpatientshomes

d) Other_____________________________________________

49

Whodoyouthinkwillusethissystemmore?

a) Doctors

b) Nurses

c) Equalusage

Canyouforeseeanyproblemswiththissystem?Ifyes,pleasespecify.

Yes No

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Whatsortofstandardswouldberequiredforpatientconfidentialityi.e.whoshouldbeabletoaccessinformation?

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

50

Havingseentheprototypewebsite,whatadditionalfunctionswouldyouadd,orpresentfunctionstakeaway?

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Pleasecommentonanythingelseyouthinkmightbeuseful.Thankyouforyourtime.

___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

51

8.2AppendixB,WorkingSystemSurveyThankyouforyourtime.

Forthefollowingquestions,pleasecirclethenumber,whichbestrepresents,yourexperiencewiththeweb‐basedpatientrecordmanagementsystem.

1.Pleaserateyouroverallfeelingofthewebsitefrom1to7,where7representsextremesatisfactionand1completedissatisfaction.

Consideringthewebsiteasawhole,Iam:

1 2 3 4 5 6 7

Dissatisfied VerySatisfied

2.Pleaseindicateeaseofsitenavigation:wastherealogicalflowbetweenthemenus?Areitemslocatedwhereyouwouldexpectthemtobe?

Ifoundthewebsite:

1 2 3 4 5 6 7

VeryDifficulttoNavigate

VeryEasytoNavigate

3.Pleaseratetheusefulnessoftheonlinematerial,i.e.keepingpatientrecordsonacomputerizedsystemasopposedtoapaperbasedsystem.

Havinganelectronicwebbasedpatientmanagementsystemis:

1 2 3 4 5 6 7

Nouseatall

Incrediblyuseful

52

4.Oursystemusesanencryptedpasswordservicewithaccesstofilescontrolledbytherankoftheuser:patientscanaccessonlytheirfile,whiledoctorsandnurseshavespecificrestrictions.Pleaseratethesesecurityfeatures:

Ifeltthatthesecurityfeatureswithinthewebsitewere:

1 2 3 4 5 6 7

Verybadlyimplemented

Dealtwithverywell

5.Pleaseratethegenerallookandfeelofthewebsite.

Ifoundthelookofwebsitetobe:

1 2 3 4 5 6 7

Unprofessionalandboring

Veryvisuallyappealing

6.Pleaseratethedifficultyoflearningtousethewebsite.

InorderformetousethewebsiteeffectivelyIwouldneed:

1 2 3 4 5 6 7

Intensivetraining Hardlyanytraining

7.Pleasecommentontheeaseofcorrectingyourselfifanerrorwasmade.

Ifoundtheerrormessagesandbacktrackingoptionswere:

1 2 3 4 5 6 7

Difficultandcumbersome

Clearandeasytocorrectoneself

53

8.Pleasecommentontheroleofanadministratortooverseemanagementofthesite.

TheAdministratorsroleis:

1 2 3 4 5 6 7

Pointless Necessary

9.Pleasecommentontheeaseoffindingandaddingpatientrecords.

Findingoraddingapatientrecordwas:

1 2 3 4 5 6 7

Difficultandcumbersome

Clearandeasytodo

10.Pleasecommentonanythingthatyouwouldliketoaddthatwasnotaddressed.

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

54

9.References

[1]Henninger,S.,Lu,C.,andFaith,C.1997.Usingorganizationallearningtechniquestodevelopcontext‐specificusabilityguidelines.InProceedingsofthe2ndConferenceonDesigninginteractiveSystems:Processes,Practices,Methods,andTechniques(Amsterdam,TheNetherlands,August18‐20,1997).S.Coles,Ed.DIS'97.ACM,NewYork,NY,129‐136.DOI=http://doi.acm.org/10.1145/263552.263594

[2]Nielsen,J.andMolich,R.1990.Heuristicevaluationofuserinterfaces.InProceedingsoftheSIGCHIConferenceonHumanFactorsinComputingSystems:EmpoweringPeople(Seattle,Washington,UnitedStates,April01‐05,1990).J.C.ChewandJ.Whiteside,Eds.CHI'90.ACM,NewYork,NY,249‐256.DOI=http://doi.acm.org/10.1145/97243.97281

[3]Dix,A.andCowen,L.2007.HCI2.0?:usabilitymeetsweb2.0.InProceedingsofthe21stBritishHCIGroupAnnualConferenceonHCI2008:PeopleandComputersXxi:Hci..ButNotAsWeKnowIt‐Volume2(UniversityofLancaster,UnitedKingdom,September03‐07,2007).BritishComputerSocietyConferenceonHuman‐ComputerInteraction.BritishComputerSociety,Swinton,UK,185‐186.

[4]Lenhart,J.G.,Honess,K.,Covington,D.,andJohnson,K.E.“AnAnalysisofTrends,Perceptions,andUsePatternsofElectronicMedicalRecordsAmongFamilyPracticeResidencyPrograms.”FamilyMedicine,February2000,32:109‐114.

[5]Gaillour,F.“RethinkingtheCPR:IsPerfecttheEnemyoftheGood?”HealthcareManagementTechnology[serialonline],May1999,20:22‐25.32

[6]Fromberg,R.,andAmatayakul,M.“CPRIandtheFutureofComputer‐basedPatientRecords.”HealthcareFinancialManagement,July1995,49:48

[7]Dassenko,D.,andSlowinski,T.“UsingtheCPRtoBenefitaBusinessOffice.”HealthcareFinancialManagement,July1995,49:68‐70,72‐73

[8]Drazen,E.“PointCounter‐point:Computer‐basedPatientRecord.InterviewbyC.Marietti.”HealthcareInformatics,May1998,15:84‐86,88‐90,94‐96.

[9]Bergman,R.“WhereThere’saWill...Computer‐basedPatientRecordsRequireCommitment,Time–andMoney.”HospitalsandHealthNetworks,May5,1994,68:36,38,40,42.

[10]DWChadwick,PJCrook,AJYoung,DMMcDowell,TLDornan,JPNew(September2000);Usingtheinternettoaccessconfidentialpatientrecords:acasestudyBMJ321:612–4

[11]Curtis,D.,Shih,E.,Waterman,J.,Guttag,J.,Bailey,J.,Stair,T.,Greenes,R.A.,andOhno‐Machado,L.(2008).Physiologicalsignalmonitoringinthewaitingareasofanemergencyroom.InProceedingsoftheICST3rdinternationalConferenceonBodyAreaNetworks(Tempe,Arizona,March13‐17,2008).ICST

55

(InstituteforComputerSciencesSocial‐InformaticsandTelecommunicationsEngineering),ICST,Brussels,Belgium,1‐8.

[12]McCraig,L.F.,Burt,C.W.(2003)Nationalhospitalambulatorymedicalcaresurvey:emergencydepartmentsummary.Advdata.2005May26;(358):1.USDeptofHHS.CentersforDiseaseControlandPrevention

[13]Gonçalves,B.,Filho,J.G.,Andreão,R.V.,andGuizzardi,G.(2008).ECGdataprovisioningfortelehomecaremonitoring.InProceedingsofthe2008ACMSymposiumonAppliedComputing(Fortaleza,Ceara,Brazil,March16‐20,2008).SAC'08.ACM,NewYork,NY,1374‐1379

[14]Musciano,Chuck,(1997),HTML:thedefinitiveguide,Publisher:SEBASTOPOL:O'REILLY&ASSOCIATES,

[15]Brooke,J.(1996).SUS:A“quickanddirty”usabilityscale.InP.W.Jordan,B.Thomas,B.A.Weerdmeester&I.L.McClelland,Eds.UsabilityEvaluationinIndustry,pp.189‐194.London:Taylor&Francis.