Udvikling af et elektronisk. væskeskema. til opgørelse og visualisering af væskebalancen hos intensivpatienter

Transkript

1 Udvikling af et elektronisk væskeskema til opgørelse og visualisering af væskebalancen hos intensivpatienter Bachelorprojekt 13gr671 Sundhedsteknologi Aalborg Universitet 30. maj 2013

2

3 Department of Health Science and Technology Fredrik Bajers Vej 7D Aalborg Titel: Udvikling af et elektronisk væskeskema til opgørelse og visualisering af væskebalancen hos intensivpatienter Tema: Design af sundhedsteknologiske systemer Projektperiode: P6, forårssemesteret 2013 Projektgruppe: 13gr671 Deltagere: Kasper Aarup Houlberg Mette Evald Mette Vandborg Lauridsen Mia Horsbøl Hansen Peter Lyngø Sørensen Vejleder: Ulrike Pielmeier Oplagstal: 7 Sidetal: 187 Bilagsantal: 3 + CD Afsluttet d Synopsis: Intensivpatienter er ofte prædisponeret for en ubalanceret væskebalance, grundet øget risiko for udvikling af sygdomme som sepsis eller akut nyresvigt, som ofte fører til over- eller dehydrering af patienten. Det er derfor vigtigt at opretholde en neutral væskebalance ved intensivpatienter. Dette gøres ved at føre et detaljeret væskeskema over patientens væskeindgifter og -udgifter i løbet af et akutdøgn. Papirbaserede væskeskemaer er forbundet med flere problemstillinger såsom fejlindtastninger, dobbeltindtastninger, upræcise data, manglende overblik og fleksibilitet. Udviklingen af et elektronisk væskeskema er fundet som et muligt alternativ, hvor udarbejdelsen af dette sker ved anvendelse af principper indenfor objekt-orienteret analyse, design, programmering samt UML. En test af det endelige program (FluidApp) viste, at dette kunne oprette patienter, tilknytte specifikke dataparametre til en patient ved at tilføje/slette parametre, oprette nye parametre i et registreringsoversigt, indtaste væskeindgifter og -udgifter samt automatisk opgøre væskebalancen. Ligeledes kunne en graf og en oversigtstabel over en patients væskebalance samt en hensigtserklæring visualiseres. På baggrund af de foretagende tests viste det sig, at de implementerede dele i FluidApp kunne løse de fundne problemstillinger, det er dog stadig ønskværdigt at foretage en overtagelsestest for at identificere muligheder for optimering og udvikling. Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

4

5 Forord Projektet er blevet udarbejdet af gruppe 671 på 6. semester civilingeniøruddannelsen i Sundhedsteknologi ved Aalborg Universitet i perioden d. 4. februar til 30. maj Projektets overordnede tema er Design af sundhedsteknologiske systemer og projektrapportens titel er Udvikling af et elektronisk væskeskema til opgørelse og visualisering af væskebalancen hos intensivpatienter. Projektets målgruppe er vejledere, medstuderende og andre med interesse indenfor Sundhedsteknologi, men det kan være en fordel at læseren har kendskab til Unified Modelling Language (UML), objektorienteret programmering og naturvidenskabelige fag. Der rettes tak til sygeplejersker på intensiv afdeling R, Bernt Pedersen og Morten Salomonsen, samt sygeplejerske Naja Weber Hansen på intensiv afdeling TIA, Aalborg Universitetshospital, for deltagelse i ekspertinterviews. Læsevejledning Kildehenvisninger i rapporten vil blive opført efter Harvardmetoden med [Efternavn, År] i teksten. Kildehenvisninger fører til en samlet litteraturliste bagerst i projektet, hvor bøger angives med forfatter, år, titel, udgave og forlag, mens internetsider er angivet med forfatter, titel, URL og dato tilgået. Hvis forfatter ved internetkilder ikke er angivet, er organisationen bag denne internetkilde valideret. Foretagne interviews er refereret med [Efternavn på informant, År] i projektet. I litteraturlisten er interviews angivet med informantens navn, type af interview, dato for transskription, samt interviewets interviewere. Tabeller og figurer er nummereret i henhold til det pågældende kapitel, dvs. første figur i kapitel 6 har nummer 6.1, næste nummer 6.2 osv. Referencer til appendiks angives med et bogstav, f.eks. appendiks A. Denne metode benyttes også ved bilag. Der kan forekomme forkortelser af udvalgte begreber og termer i projektet, hvilket anbringes i parentes ved første benævnelse. Efter første benævnelse for det pågældende begreb eller term, anvendes forkortelsen i projektet. Vedlagt rapporten er en CD, hvorpå projektgruppens udviklede elektroniske væskeskema forefindes. v

6 Kasper Aarup Houlberg Mette Evald Mette Vandborg Lauridsen Mia Horsbøl Hansen Peter Lyngø Sørensen vi

7 Resumé Intensive care unit (ICU) patients have a predisposition for developing an unbalanced fluid balance because of higher risks of developing diseases like acute renal failure and sepsis. These diseases tend to cause dehydration or overhydration depending on the disease type. It is essential for ICU patients to keep a neutral fluid balance. Today the fluid balance of ICU patients is monitored by maintaining a paper-based fluid balance chart to record fluid inputs and outputs during the day. Based on expert interviews with ICU nurses at Aalborg University Hospital and literature research, it is evident that the paper-based fluid balance charts are associated with problems like incorrect entries, double entries, imprecise data, lack of overview and flexibility. These issues have urged the development of an IT-system to replace the paper-based fluid balance charts. The project group has developed FluidApp, an electronic fluid balance chart, in which it is possible to register observed fluid input and output values of patients. To every registered value a comment may be added to mimic the freedom of writing patient related messages on the paper-bases charts. FluidApp calculates a patient s fluid balance automatically based on the patient s perspiration, metabolic water and fluid input and output values. The system displays the calculated fluid balance in a graph and an overview table. The graph and table allows the user to get a view of the fluid balance over time periods of hours or several days. FluidApp implements furthermore a function, that enables an user to create new parameters in FluidApps registration overview. During parameter creation the user has to choose whether a parameter is a fluid input, output or another type of parameter. The user can link relevant parameters to a specific patient by adding the newly created parameter to the patient s registration overview. Every day in the ICU a doctor makes a statement of intent for a patient s fluid input and output values. This statement of intent tells other ICU staff what the expected fluid inputs and outputs are for the specific patient. The doctor can record the statement of intent in FluidApp and compare this to the entry values for the fluid inputs and outputs. The development of FluidApp has involved object-oriented analysis, design and programming using Unified Modeling Language (UML) and Java. FluidApp has been tested according to use cases developed on the basis of expert interviews. Test results show that FluidApp satisfies the functionality requirements set for the system. Further testing of the system however needs to be done by FluidApps intended users before the system fully can replace paper-based fluid balance charts. vii

8

9 Indholdsfortegnelse Resumé vii Kapitel 1 Indledning Initierende problemformulering: I Problemanalyse 3 Kapitel 2 Opgørelse af væskebalance for intensivpatienter Menneskekroppens væskebalance Væskebehandling af intensivpatienter Væskeskemaet og dets parametre Arbejdsgange forbundet med væskeskemaerne Kapitel 3 Problemstillinger ved papirbaserede væskeskemaer Opbygningen af væskeskemaer Risiko for upræcise væskeskemaer Formidling af information fra væskeskemaer Intern formidling Formidling mellem sygehusafdelinger Opsamling Kapitel 4 Opsummering Problemformulering II Metode 19 Kapitel 5 Metode Unified Modeling Language (UML) Waterfall-modellen Ekspertinterviews IIIProblemløsning 25 Kapitel 6 Optimeringsmuligheder for elektroniske væskeskemaer Automatiske beregninger ix

10 6.2 Kontinuerlig beregning af væskebalancen Mindske antal indtastninger Overblik over væskebalancen gennem flere døgn Opsamling Kapitel 7 Systemkrav Antagelser ved udvikling af et elektronisk væskeskema Systembeskrivelse Systemkrav Funktionelle krav Non-funktionelle krav Use cases UC: Håndter ingen forbindelse til database UC: Identificer patient UC: Opret patient UC: Rediger patientoplysninger UC: Registrer data UC: Rediger fejlindtastninger UC: Tilføj kommentar UC: Tilføj/fjern parametre til/fra registreringsoversigt UC: Opret ny parameter UC: Se hensigtserklæring UC: Se væskebalance UC: Se grafisk oversigt UC: Vælg parameter/parametre UC: Vælg default parameter/parametre UC: Vælg alternativ tidsperiode UC: Ændr default tidsperiodeindstilling UC: Se tidligere data UC: Rediger tidligere data UC: Lav udskrift Kapitel 8 Objektorienteret analyse - OOA Introduktion til objekter og klasser Identifikation af FluidApps analyseklasser Dynamisk systembeskrivelse Kapitel 9 Objektorienteret design - OOD System usability Grafisk design af FluidApp Overordnet design af FluidApps brugergrænseflader Mock-ups af FluidApps brugergrænseflader Screenflow Databasedesign Anvendelse af objektorienterede programmeringsprincipper MVC-mønster Singleton-mønster Indkapsling af data Polymorfi ved anvendelse af interfaces x

11 9.5 Designklasser for FluidApp Syntaks for FluidApps klassediagrammer Klassediagram for FluidApps brugerfladestruktur Klassediagram over FluidApps overordnede «controller»-designklasser Klassediagram for FluidApps «model»-designklasser Præsentation af de individuelle designklasser Sekvensdiagrammer Sekvensdiagram for tilføj/fjern parametre Sekvensdiagram for UC: Se væskebalance Kapitel 10 Implementering Implementeringsværktøj Afvigelser i det implementerede softwaredesign Implementering af FluidApps database SQL-syntaks for kommunikation med FluidApps database Grafisk implementering Kapitel 11 Test Tests af FluidApps UC s UC: Identificer patient UC: Opret patient UC: Rediger patientoplysninger UC: Registrer data - test af registrer patientdata UC: Registrer data - test af registrer hensigtserklæring UC: Se væskebalance & Se hensigtserklæring UC: Se grafisk oversigt UC: Se tidligere data UC: Håndter ingen forbindelse til database Overblik over testresultater IV Syntese 145 Kapitel 12 Diskussion FluidApps løsning på fundne problemstillinger Fleksibilitet i det elektroniske væskeskema Overblik over en patients tilstandsudvikling Eliminering af upræcise data ved eliminering af definitionsproblemer omkring dokumentationsarbejdet Eliminering af dobbeltindtastninger Bedre formidling mellem afdelinger Diskussion af testudførelse og testresultater Fremadrettet arbejde Manglende systemfunktionaliteter Udvidelse af FluidApp Minimering af arbejdsbelastning Systemaccept Videreudvikling til transportable enheder Kapitel 13 Konklusion 153 xi

12 Litteratur 155 Appendiks A Meningskondensering og -kategorisering af ekspertinterviews Appendiks B Slides - kurset Objektorienteret programmering Appendiks C Screenflow Bilag A Anvendte væskeskemaer xii

13 Kapitel 1 Indledning I 2011 var der intensivindlæggelser fordelt på 49 danske intensivafdelinger. Hospitalsforløb, der indebærer indlæggelse på en intensivafdeling, er omkostningsfulde, da disse beslaglægger omkring 3,5 mia. kr. per år, svarende til 6 % af de samlede hospitalsomkostninger i Danmark. Omkostningerne skyldes, at intensivafdelinger skal udføre et mere intensivt observations-, diagnostisk-, behandlings- og plejearbejde af et i høj grad differentieret patientspektrum end på andre sengeafdelinger. Størstedelen af ressourceforbruget går dermed til omkostningselementer såsom personaleudgifter, udgifter til kliniske støttefunktioner og udgifter til lægemidler [Andersen et al., 2007], [Dansk Intensiv Database, 2012]. Sværhedsgraden af intensivpatienters sygdomstilstand kan være varierende, men ofte er tilstanden dog af en sådan sværhedsgrad, at patientbehandlingen ikke kan gennemføres på en almindelig sengeafdeling. Patienter på de danske intensivafdelinger indbefatter både medicinske, akutte kirurgiske og i varierende grad komplicerede kirurgiske patienter [Andersen et al., 2007]. Intensivafdelinger kan således være udsat for at håndtere et bredt spektrum af grundsygdomme med differentierede grader af kompleksitet, hvilket sætter forskellige krav til den intensive terapi [Dansk Intensiv Database, 2012]. I udenlandske studier er det påvist, at flere end 30 % af de indlagte intensivpatienter ikke modtager en optimal behandling og pleje. Dette kan forestilles at medvirke til, at intensivpatienterne har en øget morbiditet. I 2011 var dødeligheden under indlæggelse på en intensivafdeling i gennemsnit 12,7 %, mens 4,4 % af de udskrevne intensivpatienter døde indenfor 48 timer efter udskrivelse fra intensivafdelingen. Med denne mortalitetsrate er der væsentligt potentiale for forbedringer af behandlingen af de kritisk syge patienter på intensivafdelingerne [Dansk Intensiv Database, 2012]. For flere intensivpatienter er opretholdelsen af en neutral væskebalance et væsentligt led i den almene patientbehandling [Scales og Pilsworth, 2008], [Hansen, 2013], [Pedersen, 2013]. Vedligeholdelse af en neutral væskebalance kan være vital, da en signifikant øget dødelighed er blevet forbundet med patienter, hvis væskebalance har været ubalanceret [Leach, 2010]. Skal den intensive patient sikres mod, at denne ikke får et over- eller underskud af væske i kroppen, er det nødvendigt at have et overblik over patientens væskebalance. For at opnå dette overblik er det vigtigt, at patientens indtagelse og afgivelse af væske følges nøje og føres ind i patienttilknyttede væskeskemaer. Utilstrækkelig regulering af væskebalancen og utilstrækkelig forvaltning af væskeskemaer kan være medvirkende 1

14 til, at akut syge patienter får et helbredsmæssigt dårligt udfald. Det er derfor vitalt, at væskeskemaer anvendes korrekt og opdateres jævnligt, så patientens væskebalance kan monitoreres [Scales og Pilsworth, 2008]. På nuværende tidspunkt anvendes papirbaserede væskeskemaer på flere af de danske sygehuse til monitorering af intensivpatienters væskebalance [Hansen, 2013], [Pedersen, 2013], [Salomonsen, 2013]. Ud fra Regionernes pejlemærker for Sundheds-it, er visionerne for de danske regioner, at en klinisk it-arbejdsplads skabes, som giver sundhedspersonale adgang til væsentlige parakliniske informationer [Regionernes Sundheds-it, 2012]. Dette udtrykkes yderligere i visionerne for det nye Aalborg Universitetshospital, samt handleplanen anno 2013 for Aalborg Universitetshospital. Ifølge disse er målsætningen at arbejdsbesparende teknologiløsninger implementeres for yderligere at optimere den moderne sygehusdrift og sikre en høj datasikkerhed [Region Nordjylland, 2010], [Region Nordjylland, 2013]. Visionen er, at satse på teknologiske løsninger i den daglige drift såvel som i forbindelse med forskning og udvikling. Dette, så det er muligt at styrke visitation, diagnosticering og behandling af patienter [Region Nordjylland, 2010]. Hvis visionerne for de danske sygehuse ift. den kliniske it-arbejdsplads skal følges, må en videreudvikling af de nuværende arbejdsredskaber, såsom de papirbaserede væskeskemaer, gå i retning af en elektronisk model. Denne visionsopfyldelse ses allerede på enkelte sygehuse som Århus Universitetshospital, hvor elektroniske væskeskemaer anvendes [Anæstesiologisk Intensivafdeling I - Skejby, 2013]. De nuværende anvendte papirbaserede væskeskemaer er forældede ift. de kliniske it-visioner, som er opstillet for de danske sygehuse. Det kan således være relevant at udvikle et elektronisk væskeskema, der potentielt kan være arbejdsbesparende og allervæsentligst forbedrer behandlingen af patienter på intensivafdelinger. For at understøtte udviklingen af et elektronisk væskeskema, er det fundet relevant at foretage en undersøgelse af opbygningen og anvendelsen af de nuværende papirbaserede væskeskemaer, samt problemstillinger forbundet med disse. Problemstillinger identificeres gennem en analyse af de arbejdsmæssige procedurer forbundet med anvendelsen af væskeskemaer, og gennem ekspertinterviews med relevante informanter. Herudfra kan følgende initierende problemformulering opstilles Initierende problemformulering: Hvorledes anvendes de nuværende papirbaserede væskeskemaer til opgørelse af væskebalancen hos intensivpatienter, og hvilke problemstillinger opstår ved anvendelse af disse? 2

15 Del I Problemanalyse 3

16

17 Kapitel 2 Opgørelse af væskebalance for intensivpatienter Målet for det følgende afsnit er at identificere eventuelle problemstillinger forbundet med anvendelse af papirbaserede væskeskemaer til opgørelse af væskebalance for intensivpatienter. Dette opnås igennem en analyse af denne patientgruppes krav til et væskeskema, samt en analyse af indhold, opbygning og arbejdsgange ved anvendelsen af de nuværende papirbaserede væskeskemaer. 2.1 Menneskekroppens væskebalance Vand er den grundlæggende bestanddel i menneskekroppen og udgør omkring 60 % af kropsvægten for et voksent menneske [Sawka et al., 2005], [Jéquier og Constant, 2009]. Det totale vandindhold i kroppen er fordelt ud på den intracellulære og ekstracellulære væske, der udgør henholdsvis omkring to-tredjedele og en-tredjedel af det totale vandindhold i kroppen [Jéquier og Constant, 2009]. En menneskekrop på 70 kg indeholder omkring 42 L vand, hvor omkring 28 L befinder sig intracellulært, og omkring 14 L ekstracellulært, hvoraf de 10,8 L er i interstitielvæsken og 3,2 L findes i blodplasmaet [Sawka et al., 2005], [Jéquier og Constant, 2009]. Kroppen udskifter dagligt 5-10 % af vandet i kroppen [Sawka et al., 2005]. Kroppens væskebalance gennemgår dermed konstante ændringer i forhold til væskeindgift og -udgift [Armstrong et al., 2013]. Denne balance mellem væskeudgift og -indgift vedligeholdes af et sammenspil mellem nyrerne og det neuroendokrinesystem, baseret på ændringer i volumen og i sammensætningen af det totale væskeindhold i kroppen. Herigennem opnås der i normaltilstand en neutral væskebalance, hvor den daglige væskeindgift er lig med den daglige væskeudgift [Eidemak et al., 2011], [Sawka et al., 2005]. Hovedbestanddelen af den daglige væskeudgift er diurese, som udgør mellem 1-2 L. Derudover tabes væske gennem afføring og perspiratio [Sawka et al., 2005]. Perspiratiobetegnelsen dækker over "perspiratio insensibilis", det umærkelige væsketab, dette inkluderer et væsketab igennem huden uafhængigt af svedproduktion og et væsketab igennem luftvejene [Karlsen et al., 2009]. Den daglige væskeudgift erstattes primært gennem indtagelse af drikkevarer og mad, og derudover dannes der ligeledes væske (forbrændingsvand) ved forbrænding af næringsstoffer. I tabel 2.1 er vist gennemsnitlige værdier for væskebalancen hos stillesiddende voksne mennesker. Her tydeliggøres, at den totale væskeindgift 5

18 er lig den totale væskeudgift for en person i neutral væskebalance. Indgift Gennemsnitlig Udgift Gennemsnitlig væskeindgift (ml/døgn) væskeudgift (ml/døgn) Drikkevarer 1575 Diurese 1600 Mad 675 Perspiratio 750 Forbrændingsvand 300 Afføring 200 Total 2550 Total 2550 Tabel 2.1: Væskebalance for stillesiddende voksne mennesker i et tempereret klima, opstillet på baggrund af data fra [Jéquier og Constant, 2009]. 2.2 Væskebehandling af intensivpatienter Intensivpatienter kan defineres som patienter, der har behov for intensiv observation og behandling grundet livstruende eller potentielt livstruende tilstande [Hansen et al., 2001]. Den livstruende fysiologiske tilstand medvirker, at intensivpatienter i de fleste tilfælde ikke selv er i stand til at regulere deres væskebalance, hvorved en ubalanceret væskebalance opstår [Scales og Pilsworth, 2008]. Intensivpatienter er desuden ofte prædisponeret for en ubalanceret væskebalance grundet de sygdomme, som intensivpatienter kan have [Scales og Pilsworth, 2008]. I USA er de fem primære indlæggelsesdiagnoser for intensivpatienter; respiratorisk insufficiens/svigt, postoperativ observation og behandling, iskæmisk hjertesygdom, sepsis og hjertesvigt [Society of Critical Care Medicine, 2012]. Derudover udvikler op imod 25 % af indlagte intensivpatienter akut nyreinsufficiens (AKI) [Glassford og Bellomo, 2011]. De forskellige intensivpatientgrupper har vidt forskellige krav til administreringen af væskebalancen. F.eks. modtager patienter med sepsis typisk en relativt stor indgift af intravenøs væske tidligt i behandlingsforløbet for bl.a. at modvirke hypotension, hvilket er årsagen til, at sepsispatienter har en signifikant mere positiv væskebalance end den gennemsnitlige intensivpatient [Vincent et al., 2006], [Boyd et al., 2011]. Modsat sepsis patienter anbefales en konservativ væskeadministrering til intensivpatienter med AKI. Dette, da disse har svært ved at udskille væske og derfor har en øget risiko for at udvikle ødemer, hvoraf f.eks. lungeødemer kan være livstruende [Glassford og Bellomo, 2011], [Scales og Pilsworth, 2008], [Walker et al., 2012]. [Wiedemann et al., 2006]. Fælles for disse to yderpunkter af væskebehandling er, at estimering af en nøjagtig væskebalance er vital. Dette kommer bl.a. til udtryk hos patienter med sepsis, hvor en for lille væskeindgift resulterer i utilstrækkelig perfusion af vitale organer, mens en mere positiv væskebalance end den gennemsnitlige for sepsispatienter forøger mortalitetsraten [Boyd et al., 2011], [Vincent et al., 2006]. Væskebehandling af intensivpatienter er en kontinuerlig process med ændringer baseret på patientens aktuelle tilstand samt væskebalance. Dermed er korrekt administrering af væskebehandling direkte afhængig af en nøjagtig estimering af den aktuelle væskebalance. Det er derfor nødvendigt at føre et detaljeret væskeskema for alle intensivpatienter for, at denne estimering bliver så præcis som muligt [Scales og Pilsworth, 2008]. 6

19 2.3 Væskeskemaet og dets parametre Til estimering af en patients væskebalancen anvendes væskeskemaer, hvor formålet med disse er at opgøre patientens væskeindgifter og -udgifter. På den baggrund kan patientens væskebalance estimeres ved følgende [Eidemak et al., 2011]: V æskebalance = samlet væskeindgif t samlet væskeudgif t (2.1) På intensivafdelinger anvendes et større observationsskema, hvori det primære væskeskema er implementeret. Dette væskeskema indeholder akkumulerede væskeværdier opsamlet fra supplerende væskeskemaet. Opsætningen af væskeskemaer og supplerende væskeskemaer kan være forskellige imellem intensivafdelinger, men det udvalg af parametre der observeres og registreres i disse er meget lig hinanden. Et eksempel på et væskeskema og supplerende væskeskemaer ses i bilag A. Disse akkumulerede væskeindgifter og -udgifter anvendes til at udregne den akkumulerede væskebalance ud fra formel 2.1 [Hansen, 2013], [Pedersen, 2013]. De supplerende væskeskemaer indeholder de individuelle væskeindgifter og -udgifter, som registreres i disse skemaer i løbet af et akutdøgn. Akutdøgn-betegnelsen vil fremadrettet blive benyttet i denne rapport til at betegne et døgn, startende kl og afsluttet 24 timer senere, hvor en patient er indlagt på en intensivafdeling. Det primære væskeskema påføres ved akutdøgnets start lægens ordinerede væskebehandling. Hvis patienten bliver ustabil i løbet af akutdøgnet, kan der blive behov for at tilføre eller udtrække ekstra væske, hvilket derefter påføres væskeskemaet [Pedersen, 2013]. I tabel 2.2 er vist en oversigt over væskeindgift-parametre samt hvor ofte og hvorledes disse registreres. Indgift Hvor ofte registreres Hvorledes registreres parameter parameter Per sonde På timebasis Aflæses Skyl På timebasis Aflæses Infusioner På timebasis Aflæses Medicin + vand i sonde Ved tildeling Måles Per os (væske) Ved tildeling Måles Per os (mad) Ved tildeling Estimeres Transducer Hver 8. time Aflæses/Standard Forbrændingsvand Hver 8. time Standard Tabel 2.2: Oversigt over registreringen af væskeindgifter I tabel 2.2 angives forbrændingsvand som repræsenteret ved en standardværdi. Denne sættes, uanset patientens størrelse, til 300 ml pr. døgn [Salomonsen, 2013]. For både væskeindgifter og -udgifter findes de individuelle registreringer af disse i supplerende skemaer, hvoraf de akkumulerede værdier tilføjes væskeskemaet hver 8. time. I tabel 2.3 er opstillet en oversigt over forskellige typer af væskeudgifter, samt hvor ofte og hvorledes disse registreres. 7

20 Udgift Hvor ofte registreres Hvorledes registreres parameter parameter Diurese Hver time Aflæses Dræn Hver time Aflæses Dialyse Hver time Aflæses Perspiratio Hver 8. time Estimeres Væske i afføring Hver 8. time Estimeres/Aflæses Aspirat Ved opkast Estimeres Tabel 2.3: Oversigt over registreringen af væskeudgifter Værdien for perspiratio er et estimat baseret på patientens vægt, hvor det antages, at perspiratio udgør et væsketab på 7-10 ml per kg per døgn [Perren et al., 2011], [Eidemak et al., 2011], [Salomonsen, 2013], [Hansen, 2013]. For febrile patienter samt patienter, der sveder mere end gennemsnittet, skal der tages hensyn til yderligere væsketab grundet øget svedproduktion [Perren et al., 2011], [Pedersen, 2013]. På Aalborg Universitetshopsitals intensivafdelinger baseres dette væsketab på et skøn af sygeplejersken [Pedersen, 2013]. Ydermere registreres patientens vægt i væskeskemaet. Denne parameter kan anvendes som kontrolparameter til at validere den opgjorte væskebalance, da f.eks. en positiv væskebalance vil resultere i en tilsvarende forøgelse af patientens vægt. Måling af patienters vægt er simplificeret ved, at der i alle intensivsenge er integreret vægt [Hansen, 2013]. 8

21 2.4 Arbejdsgange forbundet med væskeskemaerne I det følgende identificeres, hvor i arbejdsgangen eventuelle problemstillinger kan opstå for personalet grundet de papirbaserede væskeskemaer. Sygeplejerske Læge kl Vejer patient ved stuegang Noterer vægt i væskeskema Udarbejder en hensigtserklæring [Ved tildeling] Hver time Noterer indgift/udgift på væskeskema Kl , 22.00, 6.00 [Ellers] [Kan overholde ordination] Opgør væskebalance Nyt døgn kl Væskeskema for akutdøgn afsluttes Figur 2.1: Aktivitetsdiagram for arbejdsgangen med det primære væskeskema og supplerende væskeskemaer. Aktivitetsdiagrammet er udarbejdet på baggrund af ekspertinterviews [Hansen, 2013], [Pedersen, 2013], [Salomonsen, 2013]. På figur 2.1 er vist et aktivitetsdiagram for arbejdsgangen ved udførelse af en patients væskeskemaer. En patients væskeskema og supplerende væskeskemaer påbegyndes ved et akutdøgns start, hvor patienten indledende vejes, hvilket registreres i væskeskemaet. Ved stuegang undersøger en læge patienten og laver en hensigtserklæring, hvor væske ordineres baseret på patienttilstanden og den aktuelle væskebalance. Denne hensigtserklæring gælder for et akutdøgn, og de vagthavende skal sørge for at overholde denne. Hver gang en sygeplejerske giver en patient en væskeindgift, registreres antal ml i tilhørende supplerende væskeskema. På samme måde noteres observerede væskeudgifter. 9

22 Bestemte parametre registreres på timebasis af sygeplejersken, som nævnt i afsnit 2.3. Sygeplejerskerne tjekker i løbet af dagen, om patienten kan overholde hensigtserklæringen. Hvis dette ikke er tilfældet, kontaktes lægen, og en ny hensigtserklæring udarbejdes, som de vagthavende følger resten af det pågældende akutdøgn. Væskebalancen opgøres tre gange på et akutdøgn, kl , og Dette opnås ved, at sygeplejersken akkumulerer samtlige væskeindgifter og -udgifter siden seneste opgørelse. Endelig bliver den opgjorte væskebalance for akutdøgnet sammenholdt med patientens totale akkumulerede væskebalance siden indlæggelse. Dette gøres for at danne et overblik over patientens væskebalanceudvikling [Hansen, 2013]. Når væskeskemaer føres på en patient, er det vigtigt, at disse bliver udfyldt for hele akutdøgnet. Derfor føres væskeskemaet ligegyldigt hvilken afdeling patienten befinder sig på. Følgende forklares proceduren ved overførsel af en patients væskeskema fra anæstesiologisk afdeling til en intensivafdeling, og fra en intensivafdeling til den afdeling, hvor patienten var indlagt inden intensivafdelingen (stamafdelingen). Denne process illustreres med henblik på at lokalisere svage punkter i arbejdsgangen. 10

23 Personale Postomdeling Notering af væskebalance på et narkoseskema Narkoseskemaet postomdeles Modtager narkoseskema på intensivafdeling Ved overførsel af patient til stamafdeling Data for væskebalancen overføres fra narkoseskemaet til intensivskemaet Kopi af væskeskema Kopien gives til stamafdelingen [Ja] [Nej] Væskeskema sendes med patienten Stamafdeling sender væskeskema med postomdeling Modtager væskeskema på intensivafdeling Figur 2.2: Aktivitetsdiagram for arbejdsgangen ved overførsel af væskeskemaer fra anæstesiologisk afdeling til intensivafdelingen. Aktivitetsdiagrammet er udarbejdet på baggrund af et ekspertinterview [Pedersen, 2013]. Hvis en patient efter en operation overføres til en intensivafdeling, skal væskedata fra det narkoseskema, der blev benyttet under operationen, overføres til intensivafdelingens væskeskema, se figur 2.2. Hvis patienten overføres tilbage til stamafdelingen, skal patientens væskeskema for pågældende akutdøgn medbringes, så skemaet kan blive ført for resten af akutdøgnet. Dette foregår enten ved, at der laves en kopi af væskeskemaet eller, at det oprindelige væskeskema fra intensivafdelingen sendes med patienten til stamafdelingen, hvor det føres for resten af akutdøgnet og efterfølgende sendes tilbage til intensivafdelingen med postomdeling [Pedersen, 2013]. Denne omdeling af det papirbaserede væskeskema er sårbar, da væskeskemaet kan risikere at forsvinde under transporten. Derudover kan det være besværligt at koordinere denne process afdelingerne imellem. 11

24

25 Kapitel 3 Problemstillinger ved papirbaserede væskeskemaer Følgende afsnit har til formål at identificere eventuelle problemstillinger ved anvendelse af de nuværende papirbaserede væskeskemaer på intensivafdelinger. Problemstillinger i forbindelse med disse skemaer er blevet identificeret ud fra litteraturen, men er ligeledes baseret på interviewede informanters udsagn. Disse udsagn er uddybet yderligere i appendiks A. 3.1 Opbygningen af væskeskemaer På nuværende tidspunkt udfyldes nye væskeskemaer hvert døgn patienten er indlagt, hvorved patienten kan ende ud i at have et større antal papirbaserede væskeskemaer i sin patientjournal. Hvert enkelt af de primære væskeskemaer giver et overblik over patientens væskebalance for det pågældende akutdøgn, og viser en total væskebalance siden indlæggelsesdagen. Et overblik over alle de individuelle akkumulerede væskebalancer pr. akutdøgn kan dog kun opnås, hvis alle de foregående dokumenterede væskeskemaer findes frem fra patientjournalen [Hansen, 2013]. Dette kan forestilles at være tidskrævende samt være et uoverskueligt arbejde. Uoverskueligt i den forstand, at væskeskemaerne indeholdende patientens væskebalance er udfyldt med mange informationer og ikke kun de nødvendige oversigtsinformationer, som kunne være ønsket ved vurdering af patientens aktuelle "væske-tilstand. Intensivafdelinger rummer mange forskellige patientertyper, der kan have forskellige behov for behandling og monitorering. Disse behov skal ligeledes indpasses i de arbejdsredskaber, som anvendes til patientbehandlingen. Med en standardiseret væskeskemaform kan det i nogle patienttilfælde være svært at akkommodere denne rummelighed, hvorfor alternative metoder til anvendelse af de forskellige væskeskemaer må findes. Det kan være nødvendigt at udvide skemaerne, eksempelvis hvis en patient har haft behov for særdeles mange blodtransfusioner. I en sådan situation kan der opstå pladsmangel til dokumentation i væskeskemaet, hvorfor et ekstra skema må påklistres på det oprindelige [Hansen, 2013]. Det kan ske, at antallet af tekstkolonner til registrering af væskeparametre ikke er tilstrækkeligt, hvorfor væskeskemaet må vendes på en anden led, eller en ekstra kolonne indtegnes i skemaet. Det papirbaserede væskeskema er i denne form ikke særligt fleksibelt, hvilket kan være problematisk ift. et arbejdsmiljø, der kræver fleksibilitet [Hansen, 2013], [Pedersen, 2013]. 13

26 3.2 Risiko for upræcise væskeskemaer Væskeskemaer er et vigtigt arbejdsværktøj i den kliniske hverdag til at give et overblik over patientens væsketilstandsudvikling, og dermed også vigtige ift. at antyde en mulig væsketerapi, som patienten skal modtage fremadrettet [Callum, 1999], [Tang og Lee, 2010], [Hansen, 2013]. Da den medicinske beslutning omkring ordination af en bestemt væsketerapi bl.a. beror på en vurdering af disse væskeskemaer, er det vigtigt, at skemaerne er præcise for at give det aktuelle sygdomsbillede af patienten. Dette, for at undgå kliniske fejl og sikre, at patientens fremadrettede væsketerapi bliver så optimal som muligt [Hansen, 2013], [Pedersen, 2013], [Salomonsen, 2013]. Det er således problematisk, når de anvendte væskeskemaer forekommer upræcise pga. manglende opdatering af væskedata i væskeskemaerne, fejlnoteringer eller fejludregninger af de indførte data. Dette er jf. litteraturen og de udførte interviews almindelige fejl. En undersøgelse vedrørende dokumentering i væskeskemaer af ca postoperative patienter udtaler: " % af patienterne i stikprøven havde enten dårlig dokumentation af deres væskebalance eller havde uopdaget/ubehandlet væskebalance." [Callum, 1999] I et studie af [Leach, 2010] nævnes utilstrækkelig dokumentation som en vigtig medvirkende årsag til dårlig væskebehandling. Dette understøttes af, at der i USA er blevet dokumenteret forkert væskeadministration til postoperative patienter i % af tilfældende, hvilket fører til omkring 9000 dødsfald årligt i USA [Leach, 2010], [Leach et al., 2013]. Et upræcist væskeskema betyder, at en medicinsk beslutning omkring væsketerapi ikke udelukkende beror på disse skemaer, men kræver en yderligere sammenligning med andre parametre såsom f.eks. patientens vægtudvikling [Hansen, 2013], [Pedersen, 2013], [Schneider et al., 2012], [Tang og Lee, 2010]. Væskeskemaer kan være et vigtigt værktøj i behandlingen af intensivpatienter. Det kræver dog, at dokumentation af væskeindgifter og -udgifter foretages udførligt og korrekt således, at væskeskemaet giver et korrekt billede af patientens væskebalance, og at misfortolkninger undgås [Tang og Lee, 2010], [Scales og Pilsworth, 2008] og [Callum, 1999]. 3.3 Formidling af information fra væskeskemaer Der kan forekomme problemstillinger ved dels formidlingen af information i væskeskemaerne internt på intensivafdelinger, og dels mellem andre sygehusafdelinger Intern formidling For at udregne væskebalancen, er det nødvendigt at overføre de akkumulerede væskeværdier fra de forskellige anvendte supplerende væskeskemaer over i det primære væskeskema, jf. afsnit 2.4. Ved denne overførsel af data indskrives akkumulerede dataværdier altså dobbelt; på det pågældende supplerende væskeskema og på det primære væskeskema [Hansen, 2013], [Pedersen, 2013]. Dobbeltnoteringen repræsenterer en redundant arbejdsopgave, som ikke er til gavn for patienten. Det kunne ligeledes tænkes at flere fejl såsom talfordrejninger kunne opstå ved denne dobbeltnotering. 14

27 Da væskeskemaet skifter hænder i løbet af en døgnvagt, bl.a. pga. vagtskifte, er det vigtigt, at patientinformationer i skemaerne er dokumenteret på en sådan måde, at det nye ansvarlige personale forstår disse. Dette, for at sikre kontinuitet i patientbehandlingen [Callum, 1999]. Er der ikke fastsat en bestemt standard for dokumentering og fortolkning af væskedataene i væskeskemaerne, er der risiko for, at skemaerne føres forskelligt af sundhedspersonalet. Denne forskellighed i skemadokumentation kan blive genstand for forvirring, og evt. medvirke til upræcise væskeskemaer jf. appendiks A. Denne problematik understøttes af [Tang og Lee, 2010] hvor 25 kirurgi-studerende beregnede patienters væskebalance ud fra 13 væskeskemaer. For otte af disse væskeskemaer var der en signifikant forskel mellem den korrekte værdi og den af de studerendes beregnede værdi. Studiet tilskriver bl.a. dette til manglen på universelle dokumenterings- og fortolkningsmetoder, hvilket resulterer i uklare og/eller unøjagtige væskeskemaer [Tang og Lee, 2010] Formidling mellem sygehusafdelinger Intensivafdelingers personale skal, som nævnt i afsnit 2.4, selv overføre væskedata fra et narkoseskema noteret ved en operation til intensivafdelingens væskeskema. Det kan forekomme, at der ses mangelfuld notation af væskedata i narkoseskemaet, hvilket medfører yderligere skønsmæssigt arbejde for aktørerne på intensivafdelingen samt mulige fejl i væskedokumentationen [Pedersen, 2013]. Arbejdsgangen peger på, desuden hentydet i figur 2.2, at der ved overlevering af patienter fra én afdeling til en anden kræves dobbeltnotering af væskeinformation. I [Berger et al., 2012] påpeges i forlængelse heraf, at der optræder risici i forbindelse med overførsel af patienter til anden afdeling. Dette kan bl.a. skyldes, at vigtig information om patienten ikke bliver videreformidlet. I afsnit 2.4 nævnes ligeledes, hvordan væskeskemaer overføres til patientmodtagende afdeling via postomdeling. Ved denne overførsel af et papirbaseret væskeskema kan det forestilles, at væskeskemaet kan gå tabt i transporten, hvilket ville problematisere informationsformidlingen imellem afdelingerne. 3.4 Opsamling Der er i dette kapitel blevet identificeret følgende problemstillinger ved anvendelse af papirbaserede væskeskemaer: Manglende fleksibilitet i væskeskemaets opbygning. Manglende overblik over patientens tilstandsudvikling over flere døgn. Risiko for upræcise data; enten pga. fejlindtastninger, fejludregninger eller manglende datanotation Arbejde med dobbeltindtastning Manglende formidling af data mellem afdelinger. Disse problemstillinger understøtter udarbejdelsen af en alternativ løsning til de papirbaserede væskeskemaer, der evt. kan løse nogle af disse problemstillinger. 15

28

29 Kapitel 4 Opsummering På baggrund af problemanalysen kan det udledes, at korrekt estimering og administrering af intensivpatienters væskebalance er essentiel, da der ved over- og underhydrering er en signifikant forøget dødelighed, jf. afsnit 2.2. Det er derfor vigtigt at føre et detaljeret væskeskema for at sikre korrekt væskebehandling, og dermed opnå en neutral væskebalance. På de nuværende papirbaserede væskeskemaer noteres en patients væskeindgifter og -udgifter, hvorudfra patientens væskebalance kan opgøres, se afsnit 2.3. For at kortlægge arbejdsgange forbundet med de papirbaserede væskeskemaer, er en række ekspertinterviews blevet udført med informanter, som til dagligt arbejder med disse. Arbejdsgange blev kortlagt med henblik på identificering af væskeskemaets essentielle funktionaliteter og eventuelle problemstillinger forbundet med anvendelsen af de papirbaserede væskeskemaer. Dobbeltnotering og problematikker med potentielt mistet data ved postomdeling af væskeskemaer var umiddelbare problemstillinger identificeret ved analyse af sundhedspersonalets arbejdsgange med væskeskemaer, jf. afsnit 3.3 og 2.4. Ekspertinterviews blev primært udført, for at identificere eventuelle problemstillinger ved anvendelse af de nuværende papirbaserede væskeskemaer. Dette med henblik på at understøtte udviklingen af et eventuelt elektronisk baseret væskeskema samt identificere områder, hvor et elektronisk væskeskema vil kunne forbedre arbejdsgangen. En række problemstillinger med de nuværende væskeskemaer er blevet introduceret ud fra interviewenes kvalitative data, og enkelte problemstillinger underbygges ligeledes af videnskabelige artikler. På nuværende tidspunkt er det besværligt at opnå et samlet overblik over udviklingen i patientens væskebalance for hele indlæggelsesperioden, da det primære væskeskema kun afdækker ét akutdøgn. For at opnå et samlet overblik skal patientens væskeskemaer for alle akutdøgn findes frem fra patientjournalen og sammenholdes. Dette kunne forestilles at være tidskrævende og uoverskueligt. I deres nuværende form lever papirbaserede væskeskemaer ikke op til den fleksibilitet som det intensive arbejdsmiljø påkræver. Ekspertinterviewene og litteraturen har påpeget, at væskeskemaer forekommer upræcise pga. manglende opdatering af data i væskeskemaerne, og pga. fejlnoteringer eller fejludregninger af de indførte data. Det upræcise væskeskema medfører, at de medicinske beslutninger omkring væskeordination må sammenholdes med andre parametre for korrekt væskebehandling, se afsnit

30 For at forsøge at løse de fundne problemstillinger med papirbaserede væskeskemaer, kan informationsteknologiske alternativer overvejes. Dette, da en elektronisk applikation umiddelbart kan løse flere af de fundne problemstillinger. F.eks. kan en elektronisk applikation designes til at implementere automatiske udregninger af patientens væskebalance, fremfor at sundhedspersonalet skal udregne disse i hånden som på nuværende tidspunkt. I litteraturen er det ligeledes blevet påvist, at anvendelsen af sundheds-it har adskillige fordele i sundhedsvæsenet [Chaudhry et al., 2006], [Amarasingham et al., 2009]. Ved at benytte sundheds-it har det vist sig, at effekten og kvaliteten af behandlingen forbedres. Ligeledes opnås en forøgelse i monitorering og færre medicinrelaterede fejl [Chaudhry et al., 2006]. Denne automatisering af informationssystemer er forbundet med færre komplikationer samt lavere mortalitet og omkostninger [Amarasingham et al., 2009] Problemformulering På baggrund af problemstillingerne med de papirbaserede væskeskemaer og fordelene ved sundheds-it, har projektgruppen fundet det interessant at udvikle en elektronisk applikation af de papirbaserede væskeskemaer. Dette med henblik på at erstatte de nuværende papirbaserede væskeskemaer, og dermed opfylde visionerne for den kliniske it-arbejdsplads. En elektronisk applikation af væskeskemaerne udvikles ligeledes med henblik på at løse flere af de fundne problemstillinger således, at arbejdsbelastningen af sundhedspersonalet minimeres og væskebehandlingen af intensivpatienter optimeres. Følgende problemformulering er således udformet: Hvordan kan et elektronisk væskeskema udvikles, som både løser de fundne problemstillinger forbundet med de papirbaserede væskeskemaer og potentielt optimerer væskebehandlingen af intensivpatienter? 18

31 Del II Metode 19

32

33 Kapitel 5 Metode I dette kapitel præsenteres de grundlæggende værktøjer som benyttes til softwareudviklingen af det elektroniske væskeskema. I selve modelleringsprocessen af softwaresystemet anvendes Unified Modeling Language som modelleringsværktøj. Softwareudviklingsprocessen defineret ved Waterfall-modellen anvendes til beskrivelse af det overordnede procesforløb. Udover disse værktøjer til softwareudvikling er ekspertinterview foretaget i projektarbejdet, hvorfor disses metode beskrives. 5.1 Unified Modeling Language (UML) UML er et grafisk modelleringssprog, som kan anvendes til at dokumentere og designe især objektorienterede softwaresystemer [Fowler, 2004]. UML har tilknyttet etablerede grafiske notationer i form af diagrammer, til at vise forskellige aspekter af et softwaresystems opbygning og funktionaliteter. Disse opdeles overordnet i struktur- og opførsels-diagrammer. Diagrammerne opstilles af [Fowler, 2004] og nogle af disse er: Use-case diagrammer: Viser aktørers anvendelse og interaktion med systemet. Aktivitetsdiagrammer: Viser hvordan processer forløber. Klassediagrammer: Viser opbygningen af og sammenhængen imellem specifikke klasser, udtrykt ved deres egenskaber og opførsel. Sekvensdiagrammer: Viser interaktionen imellem objekter sekventielt. UML beskriver ikke processen til at udvikle software, men frigiver en række værktøjer, som kan hjælpe med at fortælle hvordan et produkt bør fungere [Eriksson et al., 2004]. 5.2 Waterfall-modellen Waterfall-modellen er en model for en softwareudviklingsproces, hvor processen opdeles i faser. Disse faser indbefatter typisk krav, analyse, design, kode/implementering og test [Eriksson et al., 2004], [Fowler, 2004]. Faserne er generelle for softwareudviklingsprocesser, og beskrives af [Eriksson et al., 2004] sammen med deres forbindelse med UML: Krav: Indeholder en beskrivelse af systemets ønskede funktionaliteter, igennem en beskrivelse af funktionelle og non-funktionelle krav for systemet, som er udarbejdet ud 21

34 fra foregående problemanalyse. Use-case diagrammer anvendes til at modellere aktørernes ønskede anvendelse og interaktion med systemet. Analyse: Har til formål at opstille de primære abstraktioner, i form af objekter og klasser, til opfyldelse af de opstillede krav. Disse findes på baggrund af problemdomænet. Disse abstraktioners relationer til hinanden, samt struktur vises ved klassediagrammer. Design: De fundne klasser fra analysen bruges her og specificeres nærmere. De specifikke brugergrænseflader, samt kommunikation imellem klasser bliver designet her. Implementering: De fundne klasser fra design-fasen implementeres i kode, ved brug af objektorienteret programmeringssprog. Test: Det implementerede system kan testes med forskellige tests, bl.a.: System test: Her testes hele systemet for dets ønskede funktionaliteter. Dette kan gøres på baggrund af use case- eller aktivitetsdiagrammer. Accept test: Lignende system test, blot her foretages test af den tiltænkte bruger. I Waterfall-modellen udgøres hver fase af en bestemt aktivitet, som udføres helt til ende. Aktiviteterne bliver således ikke grundregel udført igen, når fasen først er gennemført. Selvom modellen lægger op til, at faserne gennemføres fuldstændigt før næste fasebegyndelse, tillader modellen dog stadig, at der vendes tilbage til en tidligere fase, hvis noget i denne bør revideres på baggrund af arbejdet med senere faser, da dette oftest er uundgåeligt [Fowler, 2004]. Nedenstående figur 5.1 viser en illustration af Waterfallmodellen. Figur 5.1: Figuren viser waterfall-modellens opdeling af softwareudviklingsprocessen i faser. Waterfall-modellen har den svaghed, at denne ikke grundlæggende tager højde for de mange ændringer, der kan forekomme i faserne på baggrund af arbejdet med senere faser som f.eks. test og implementering [Fowler, 2004], [Eriksson et al., 2004]. Projektgruppen har dog valgt at anvende Waterfall-modellen, da denne giver mulighed for at planlægge tidsrummet for de enkelte faser fra starten af arbejdsprocessen. Dette blev vurderet nødvendigt af projektgruppen, da denne sideløbende med projektarbejdet har skullet lære objekt-orienteret analyse, design og programmering, hvorfor udviklingsperioden ligeledes har været en læringsproces. Disse forhold talte for at anvende Waterfall-modellen og dennes progressive orientering. 22

35 Da formålet med dette projekt er at udvikle en elektronisk applikation til administration af væskebalancen, vil den modelleringsmæssige proces for denne softwareudvikling starte med en opsætning af krav til systemet, efterfulgt af analyse, design, implementering af softwaresystemet og endeligt test af systemet. Denne proces vil fremgå af kapitlerne i problemløsningen. 5.3 Ekspertinterviews Det kan være relevant at foretage ekspertinterviews, da visse forskningsområder ikke er tilstrækkeligt dokumenteret i litteraturen, hvorved yderligere information om det undersøgte område må findes ved eksperter. Handler problemet om, hvordan informanten opfatter sin egen verden, er det nærliggende at spørge informanten selv for at få et indblik i denne verden [Kvale, 2006], [Riis, 2005]. I forestående projekt er ekspertinterviews blevet udført med tre sygeplejersker fra henholdsvis intensiv afdeling R og TIA på Aalborg Universitetshospital. I nedenstående tabel 5.1 ses en oversigt over de interviewede informanter samt citationsnotationen for de udførte interviews, som anvendes i projektet. Informant Afdeling Interviewdato Citation Bernt Pedersen R 6/3-13 [Pedersen, 2013] Morten Salomonsen R 6/3-13 [Salomonsen, 2013] Naja Weber Hansen TIA 7/3-13 [Hansen, 2013] Tabel 5.1: Oversigt over interviewede informanter. Formålet med de udførte ekspertinterviews var at klarlægge opbygningen samt anvendelsen af de nuværende papirbaserede væskeskemaer. Dette for at undersøge, hvad en elektronisk applikation af væskeskemaet skal indeholde, hvilke funktionaliteter dette skal have samt at identificere eventuelle problemstillinger med de anvendte papirbaserede væskeskemaer ud fra de praktiske arbejdsprocedurer med disse. Desuden skulle interviewene demonstrere, hvilke optimeringer, som en kunde ville kunne ønske af en elektronisk applikation af væskeskemaet. En interviewguide blev udarbejdet til ekspertinterviewene. Denne kan ses på vedlagte CD. Semistrukturerede interviews var ønsket, da denne strukturform faciliteter et samtalebaseret interview mellem informant og interviewer. Dette, da interviewformen ikke er fastlåst i rækkefølgen af sine spørgsmål, men lægger op til en åben fortælling fra informantens side. Denne eksplorative tilgang skulle projektgruppen dog være varsom med, da der er risiko for, at informantens fortælling løber af sporet ift. de ønskede mål med interviewet. Det var således vigtigt, at intervieweren undervejs markerede, hvilke spørgsmål var blevet besvaret, og hvilke manglede at blive fulgt op på. Spørgsmål i interviewguiden blev udarbejdet ift. de opstillede mål for de udførte ekspertinterviews. En række nøglespørgsmål blev identificeret og placeret under en række temaer. Nøglespørgsmål blev understøttet af følgespørgsmål eller stikord, og projektgruppen stillede desuden kontrolspørgsmål undervejs i interviewene for at sikre en korrekt forståelse af informanternes udsagn. For at opnå en eksplorativ struktur, blev spørgsmålene ligeledes udformet således, at disse lagde op til en åben fortælling fra informantens side [Kvale, 2006]. 23

36 Alle informanter fra ekspertinterviewene blev adspurgt, om det kunne tillades at registrere deres udsagn således, at disse udsagn kunne anvendes i projektet. Projektgruppen anvendte en diktafon som registreringsmetode, og diktafonmaterialet for hvert interview blev transskriberet på en formaliseret skriftlig form. Dette vil sige, informanternes og interviewernes udsagn ikke blev nedskrevet ordret med gentagelser, talepauser m.m. Kun den formelle holdning til interviewspørgsmålene blev transskriberet. Denne transskriptionsmetode blev anvendt for at effektivisere analyseforløbet af de enkelte interviews. Tre analysemetoder er blevet anvendt for at uddrage relevant information ift. de opsatte mål for ekspertinterviewene. Opbygningen og anvendelsen af nuværende papirbaserede væskeskemaer forekom uklar, hvorfor en åben fortælling fra informanten omkring disse emner var ønskværdig. For at håndtere disse fortællinger, er narrativ strukturering af det transskriberede materiale blevet udført. Dette, for at kunne opstille en model for arbejdsproceduren med de papirbaserede væskeskemaer, hvorudfra problemstillinger med de anvendte skemaer evt. kunne udledes. Disse modeller for arbejdsprocedurer er afspejlet i afsnit 2.4. Meningskondensering blev anvendt for at analysere eventuelle problemstillinger forbundet med anvendelsen af papirbaserede væskeskemaer. Ved anvendelse af denne analysemetode blev informanternes udsagn i transskriptionerne mere præcist formuleret. Et eksempel på meningskondensering kan ses i appendiks A. De kondenserede udsagn blev placeret i relevante kategorier ved anvendelse af meningskategorisering. Dette blev udført for at danne et overblik over de kondenserede udsagn, samt for at antyde en generaliserbarhed inden for bestemte kategorier. Meningskondensering og meningskategorisering af ekspertinterviewene er yderligere uddybet i appendiks A. 24

37 Del III Problemløsning 25

38

39 Kapitel 6 Optimeringsmuligheder for elektroniske væskeskemaer For at designe et optimalt system til opgørelse af væskebalance hos intensivpatienter, ønskes i dette afsnit at fremlægge de områder forbundet med papirbaserede væskeskemaer, der ifølge skemaernes brugere kunne findes værdi i at optimere. Derudover ønskes at underbygge disse optimeringsområder med kilder i litteraturen. I udviklingen af et væskebalancesystem tages hermed hensyn til de brugere, der skal anvende væskeskemaet samtidigt med, at de bagvedliggende principper er funderet i litteraturen. 6.1 Automatiske beregninger Ifølge en informant fra de udførte ekspertinterviews vil det være fordelagtigt, hvis et system fremfor sundhedspersonalet foretog beregningerne forbundet med opgørelsen af væskebalancen i løbet af akutdøgnet. Dette, fordi der altid er en vis risiko for, at sundhedspersonalet regner eller skriver forkert i beregningerne foretaget med lommeregner, se afsnit 3.2 [Pedersen, 2013]. Udover fejlminimering, vil en sådan funktion ligeledes mindske sundhedspersonalets arbejdsopgaver og dermed frigøre mere tid til behandling og observation af patienten [Salomonsen, 2013]. 6.2 Kontinuerlig beregning af væskebalancen Informanter har udtrykt, at det vil være anvendeligt at have en kontinuerlig opgørelse af væskebalancen. Selvom sundhedspersonalet på nuværende tidspunkt opgør en patients væskebalance tre gange i akutdøgnet, kan det forestilles, at behandlingen af visse patienter kan drage fordel af, at en opdateret væskebalance er kendt [Hansen, 2013]. En informant mener, at det kan være en fordel i sygeplejerskernes arbejde, hvis disse har mulighed for at se patientens opgjorte væskebalance indenfor et bestemt tidsrum [Salomonsen, 2013]. Dermed er et muligt krav til det elektroniske væskeskema, at en patients væskebalance opgøres kontinuerligt med mulighed for at få vist denne over en relevant tidsperiode. 6.3 Mindske antal indtastninger En stor optimering ift. intensivsygeplejerskernes arbejdsbyrde kan ifølge en informant være, at dataindsamlingen af væskeindgifter fra f.eks. infusionspumper blev foretaget automatisk [Hansen, 2013]. Hvis f.eks. infusionspumperne selv dokumenterede væskeindgifter 27

40 til et elektronisk væskeskema, ville sygeplejerskerne være fri for at aflæse og nedskrive data. En sådan teknologi hører dog udenfor udviklingen af et elektronisk væskeskema, og er af for stort omfang til, at dette vil udvikles i nærværende projekt. Da aflæsning og indtastning af væskedata ikke kan undgås ud fra præmisserne på Aalborg Universitetshospital på nuværende tidspunkt, er det i stedet vigtigt, at antallet af nødvendige indtastninger i væskeskemaet minimeres. Automatiske beregninger som nævnt i afsnit 6.1 kan i høj grad bidrage til dette. Dette ved at eliminere både indtastninger på lommeregner samt indførelse af akkumulerede værdier til det primære væskeskema. Desuden er der visse parametre såsom perspiratio og forbrændingsvand der ikke måles, men i stedet estimeres. Dette enten på baggrund af anden data, eksempelvis patientens vægt, eller ved antagelse af en fast perspiratio-værdi [Hansen, 2013], [Salomonsen, 2013], [Pedersen, 2013]. Sådanne dataværdier bør ikke være nødvendige at indtaste for brugere af et digitalt væskeskema, da disse værdier vil kunne beregnes automatisk af systemet på baggrund af eksempelvis patientens registrerede vægt. Derudover ville et elektronisk væskeskema, der kunne tilgås af flere afdelinger eliminere den dobbeltnotation der blev nævnt i afsnit vedrørende overførsel af væskeskemaer afdelinger i mellem. 6.4 Overblik over væskebalancen gennem flere døgn En måde hvorpå et elektronisk væskeskema kan optimere de papirbaserede væskeskemaer er ved, at systemet giver et overblik over en patients væskebalance over flere akutdøgn [Pedersen, 2013]. Svingninger i en patients væskebalance bliver holdt øje med på intensivafdelingerne på Aalborg Universitetshospital, men på nuværende tidspunkt gennemgås de tidligere dages væskeskemaer for at opnå dette overblik over udviklingen i patientens væskebalance. En mulig optimering af det papirbaserede væskeskema kan ligge i en grafisk visualisering af patientens væskebalance over de indlagte akutdøgn [Hansen, 2013]. En informant fandt ikke, at grafer nødvendigvis vil give meget til deres arbejdsgang, da behandlerne hovedsageligt er interesseret i talværdierne frem for en grafisk oversigt over udviklingen i væskebalancen [Salomonsen, 2013]. I litteraturen beskrives dog, hvorledes visualisering kan anvendes til at gøre store datamængder overskuelige. Da der i stadig højere grad er store mængder af data tilgængelig for behandlere, kan det være svært at anvende dette optimalt, hvis digitale systemer ikke gør interaktion med og præsentation af denne data effektiv [Chittaro, 2001]. Med fokus på informationsvisualisering i medicinske informationssystemer kan en overskuelig præsentation af store mængder data opnås [Chittaro, 2001]. Dette kan gøre et systems brugere i stand til at håndtere mere data, og derigennem få et bedre indblik i patientens sygdomstilstand [Chittaro, 2001]. Det er muligt, at der udover den opgjorte væskebalance på døgnbasis ligeledes kan være interesse i at have et overblik over udviklingen af enkelte parametre. Dermed kan det, udover den kontinuerlige opgørelse af væskebalancen, være relevant at give mulighed for visualisering af flere parametre opstillet i de papirbaserede væskeskemaer. Dette kunne f.eks. indebære en visualisering af udviklingen i diurese, dræn, vægt eller blodtryk. 28

41 6.5 Opsamling Ovenstående afsnit har specificeret flere områder, hvor de papirbaserede væskeskemaer kan optimeres, ud fra informanters udsagn fra udførte ekspertinterviews. De overordnede optimeringsområder er fundet til at være: Opgøre en patients væskebalance kontinuerligt. Automatisere beregninger og dermed mindske antal dataindtastninger. Visualisering af udviklingen i patientens væsketilstand. 29

42

43 Kapitel 7 Systemkrav For at udvikle et softwaresystem, er det vigtigt at fastsætte en række krav i form af funktionelle og non-funktionelle krav til systemet. Disse krav skal beskrive henholdsvis funktionaliteten og de tekniske løsningsvalg for det givne system, og udvikles i nært sammenspil med systemets brugere. En analyse af krav til et system involverer netop at finde ud af, hvad brugerne af softwaresystemer gerne vil have, at et system gør [Fowler, 2004]. På baggrund af foregående problemanalyse har det været muligt at identificere en række funktionelle krav til projektgruppens elektroniske væskeskemasystem. Udover problemanalysen tager de funktionelle krav desuden udgangspunkt i en række antagelser beskrevet i følgende afsnit. Dernæst følger en beskrivelse af systemets overordnede problemområde efterfulgt af en identificering af systemets funktionelle og non-funktionelle krav. 7.1 Antagelser ved udvikling af et elektronisk væskeskema På intensivafdelingerne på Aalborg Universitetshospital er der på nuværende tidspunkt ikke computerterminaler ved den enkelte patient [Pedersen, 2013], [Hansen, 2013]. Dette betyder, at sygeplejerskerne både vil skulle nedskrive væskedata på papir, hvorefter disse nedskrevne data vil skulle indføres i en terminal, hvis elektroniske væskeskemaer indføres på Aalborg Universitetshospitals intensivafdelinger. Denne form for dobbeltindtastning er ikke ønskværdig. Derfor er det nødvendigt at foretage nogle antagelser i forbindelse med udviklingen af et elektronisk væskeskema. Dette indebærer en antagelse om, at der på intensivafdelingen er mulighed for enten at foretage opsamlingen af data på et elektronisk medie f.eks. en tablet eller pc, eller at indsamlingen af data foretages og overføres til væskeskemaet automatisk. Dette virker som realistiske antagelser for fremtiden grundet fremtidsvisionerne for klinisk IT på de danske sygehuse, jf. kapitel 1. Derudover antages, at et elektronisk system ikke kræver et separat log-in af systemets brugere. Ifølge en informant er der i forvejen mange forskellige systemer, hvor det er nødvendigt at logge ind, hvorfor flere log-ins blot vil besværliggøre arbejdsgangen yderligere [Hansen, 2013]. 7.2 Systembeskrivelse I kapitel 3 blev en række problemstillinger ved anvendelsen af papirbaserede væskeskemaer identificeret. Derudover blev der i kapitel 6 redegjort for optimeringsmuligheder indenfor 31

44 anvendelsen af disse skemaer. Målet med udviklingen af et elektronisk væskeskemasystem er derfor at forbedre de nuværende papirbaserede væskeskemaer, både ved at løse de identificerede problemstillinger og samtidigt ved at implementere de fundne optimeringsmuligheder. Forventningen er, at dette vil resultere i en optimering af væskebehandling af intensivpatienter samt vil optimere sundhedspersonalets arbejdsgang. Systemets hovedformål er kontinuerlig opgørelse af en intensivpatients væskebalance. Brugeren af systemet vælger indledningsvis den patient, som det ønskes at opgøre en væskebalance for. Til baggrund for opgørelsen af en patients væskebalance ligger brugernes registreringer af en patients væskeindgifter og -udgifter i systemet. Systemet skal designes således, at der som udgangspunkt kan tilføjes de parametre, som blev opstillet i tabel 2.2 og tabel 2.3 samt patientens vægt, til en registreringsoversigt. Brugeren skal dog have mulighed for selv at vælge, hvilke parametre som tilføjes til registreringsoversigten og evt. tilføje nye relevante parametre. Herved modificeres systemet ift. den enkelte patients væskebehandling og skaber en form for fleksibilitet. Desuden skal estimering og registrering af en patients forbrændingsvand og perspiratio foregå automatisk, hvorved brugeren ikke er involveret i disse beregninger, og fejlberegninger dermed kan undgås. Systemet skal håndtere de registrerede væskeindgifter og -udgifter, samt beregne den aktuelle væskebalance. Dermed reduceres sundhedspersonalets arbejdsopgave ift. registrering og fortolkning af data. Den aktuelle væskebalance skal kunne vises over et tidsrum valgt af systemets brugere således, at det er muligt for brugeren at få et overblik over en patients væskebalance for hele indlæggelsesperioden eller for de sidste aktuelle indlæggelsestimer. Desuden skal brugeren kunne se patientens væskebalance for et givet tidspunkt i akutdøgnet. Visualisering af data skal foregå både i tabeller og grafer, hvor graferne skal give et indblik i udviklingen af en patients væskebalance mens en tabel viser de præcise talværdier. Grafer kan f.eks. anvendes af systemets brugere til hurtigt at identificere, om en patient gennem indlæggelsesperioden har haft store svingninger i væskebalancen eller om denne generelt har været stabil. Hensigten med systemet er, at dette skal kunne anvendes på tværs af forskellige afdelinger og af brugere med forskellige faglige forudsætninger. Derfor skal det være muligt for den enkelte bruger at modificere de tabelmæssige eller grafiske indstillinger i systemet, da det kunne forestilles, at læger eller sygeplejersker ønsker forskellige output for disse. Dermed skal det være muligt for en given bruger eller afdeling at tilpasse systemet til dennes behov. 7.3 Systemkrav Overordnet ønskes, at et elektronisk system svarende til de papirbaserede væskeskemaer udvikles til at give et overblik over den intensive patients tilstand ift. dennes væskebalance. Overblikket over en patients væskeindgifter og -udgifter har inspireret til, at systemet benævnes FluidApp. Følgende beskrives de funktionelle og non-funktionelle krav for FluidApp. Funktionelle krav beskriver systemets opførsel(behaviour), og denne opførsel er uafhængig af den valgte implementeringsform. Non-funktionelle krav kan beskrives i form af størrelse, ydeevne og sikkerhed, og er dermed afhængige af den valgte implementeringsform. 32

45 7.3.1 Funktionelle krav FluidApp skal kræve, at patienten identificeres. FluidApp skal anvende et identifikationsnummer til at adskille de enkelte patienter. Dette identifikationsnummer kan være i form af en barcode, CPR-nr. eller lignende. FluidApp skal give brugeren mulighed for at oprette en patient i systemets database. Brugere af FluidApp skal have muligheden for at oprette en patient i systemets database, dog skal FluidApp tjekke, om patienten ikke allerede er oprettet i databasen før en ny patientprofil kan oprettes. FluidApp skal give brugeren mulighed for at redigere tidligere gemte patientoplysninger undtagen patientens identifikationsnummer. Der kan forekomme situationer, hvor sundhedspersonalet ikke har alle oplysninger omkring en patient. I disse situationer kan en patientprofil være oprettet i FluidApps database uden patientspecifikke informationer såsom navn, fødselsdato m.m. Det kan være ønskværdigt, at systemet giver brugeren mulighed for at redigere en gemt patientprofil, hvis flere patientinformationer opnås på et senere tidspunkt end på oprettelsesdagen. FluidApp skal give brugeren mulighed for at registrere observerede dataværdier for relevante parametre og redigere i disse dataværdier, hvis nødvendigt. En bruger skal kunne registrere værdier for væskeindgift/udgift, kropsvægt og eventuelt andre brugervurderede relevante parametre. Brugeren skal ligeledes kunne redigere de registrerede dataværdier således, at registreret data bliver så præcis som muligt. FluidApp skal give brugeren mulighed for at oprette og redigere en hensigtserklæring for en patients parametre. En bruger skal have mulighed for at oprette en hensigtserklæring for en patients parametre. Dette, så sundhedspersonalet kan give patienten de rette mængder af f.eks. medicin, væske m.m. for det igangværende akutdøgn. Desuden skal en bruger kunne redigere de registrerede værdier for en hensigtserklæring således, at en ny ordination kan ordineres hvis patientens tilstand ændre sig i løbet af akutdøgnet. FluidApp skal tids-, bruger- og patientstemple de registrerede parameterværdier. Data for forskellige parametre skal tidsstemples således, at brugeren har et tidsmæssigt overblik over patientens tilstandsudvikling. Brugeren skal have mulighed for selv at specificere en tidsstempling for observerede dataværdier, da det kan ske, at parameterværdier ikke indtastes netop som disse bliver aktuelle. Systemet skal dog ligeledes kunne tidsstemple de registrerede værdier, hvis brugeren ikke indskriver en specifik tidsstempling. Udover en tidsstempling af de observerede dataværdier, bør der ligeledes foretages en tidsstempling af hvornår brugeren har gemt data i systemet, for at højne dokumentationsværdien. Systemet skal ligeledes kunne foretage identifikation af systemets brugere således, at det er muligt at brugerstemple de registrerede data. Dette for at holde styr på, hvilken bruger har foretaget de enkelte målinger og registreret disse. Identifikation af brugeren kan f.eks. ske ved indhentning af log-in data fra et EPJ-systemet som f.eks. Clinical Suite. De observerede dataværdier skal desuden patientstemples således, at tilknytningen af data til en specifik patient er tydelig. 33

46 FluidApp skal tillade, at brugeren tilknytter en kommentar til observeret parameterdata. For at undgå fejlmedicinering er det vigtigt at kunne videregive oplysninger om patientrelaterede dataværdier således, at registreret data kan anskues kritisk. Der er således brug for et kommentarfelt knyttet til hvert dataværdifelt. På denne måde kan FluidApps brugere videregive oplysninger om dataværdier gennem kommentarfeltet og dermed efterligne friheden med papirbaserede væskeskemaer, hvor kommentarer nemt kan nedfældes. FluidApp skal give brugeren mulighed for at tilføje en ny parameter til FluidApps registreringsoversigt, og oprette nye parametre. Da intensivpatienter dækker over en væsentlig differentieret patientgruppe, kan det være relevant, at en bruger kan modificere FluidApp til at kunne håndtere flere forskellige patientgrupper. Dette, ved at give brugeren mulighed for at oprette yderligere nye parametre samt modificere en registreringsoversigt til kun at indeholde de relevante parametre for en specifik patient. FluidApp skal give brugeren mulighed for at fjerne en parameter. Det kan forestilles, at f.eks. enkelte væskeindgifter kun gives i en vis periode. Hermed kan det være relevant at fjerne nogle oprettede parametre fra patientens registreringsoversigt. Dette af overskuelighedsmæssige årsager og for at opdaterer oversigten ift. en patients aktuelle væskebehandling. FluidApp skal give et overblik over en patients aktuelle sygdomstilstand ift. ophobning af væske ud fra relevante væskeparametre. Relevante væskerelaterede parametre skal demonstreres, for at give sundhedspersonalet et hurtigt overblik over patientens tilstand. Dette kan gøres med en dataoversigtstabel. Essentielle parametre til opgørelse af patientens væskebalance er motiveret i afsnit 2.3. FluidApp skal give et overblik over en registreret hensigtserklæring for den pågældende patient. Dette, for at give sundhedspersonalet et overblik over lægens ordinations anvisninger for væskeindgifter og -udgifter i løbet af et akut døgn. Hensigtserklæringen skal demonstreres i en oversigtstabel, således at sundhedspersonalet kan sammenligne registrerede parameterværdier med hensigten for tilsvarende parametre. FluidApp skal håndtere akkumulering af kontinuerte væskeparametre såvel som ikke-kontinuerte væskeparametre. Visse væskeparametre registreres ikke kun i væskeskemaet som en enkelt dataværdi, men med en infusionsrate samt infusionsmængde. Systemet skal kunne håndtere disse kontinuerte væskeparametre. De ikke-kontinuerte væskeparametre, såsom diurese, forventes registreret løbende, når disse opstår. 34

47 FluidApp skal foretage automatiske udregninger af enkelte parametre. Gennem problemanalysen er det fundet fordelagtigt, hvis FluidApp fremfor sundhedspersonalet foretager automatiske beregninger af f.eks. den akkumulerede væskebalance, perspiratio og forbrændingsvand således, at sundhedspersonalet undgår fejludregninger. FluidApp skal således implementere formler til udregning af en patients væskebalance, perspiratio og forbrændingsvand således, at FluidApp kan foretage disse udregninger automatisk. FluidApp skal opgøre en patients væskebalance kontinuerligt. Det er blevet udtrykt i kapitel 6, at sundhedspersonalet ser fordele i at have en kontinuerlig opgørelse af væskebalancen til rådighed. Dette, da det ikke altid er nok med en akkumuleret væskebalance tre gange i akutdøgnet. FluidApp skal således kunne opgøre patientens væskebalance kontinuerligt ud fra registreret væskedata. FluidApp skal demonstrere patientforløbet ved grafisk afbildning af parameterværdier. FluidApp skal give brugeren et overblik over patientens tilstandsudvikling ved grafisk at demonstrere patientforløbet ift. bestemte parametre over en tidsperiode. Dette gøres for at understøtte sundhedspersonalets videre arbejde med patienten. En grafisk afbildning sammen med en oversigtstabel over relevante parametre giver sundhedspersonalet mulighed for at vurdere data i flere abstraktionslag. FluidApp skal give en bruger mulighed for at vælge en tidsperiode for dataoversigtstabellen eller den grafiske afbildning af enkelte parametre. FluidApp vil supplere med en default tidsperiode, hvormed data fremvises, i oversigtstabellen af væskeparameterdata og den grafiske afbildning af forskellige parametre. En bruger skal have mulighed for at ændre denne tidsperiode. Dette, for at brugeren har mulighed for at få et bredere tidsmæssigt overblik over de enkelte parametre. FluidApp skal kunne anvendes af flere typer brugere med forskellige faglige baggrunde. For at kunne anvende FluidApp optimalt til patientbehandling, må dette udvikles til at kunne anvendes af flere faggrupper. Dette, da flere faggrupper med forskellige faglige baggrunde følger den akutte patients forløb, og dermed skal have muligheden for at kunne udøve en optimal behandling af patienten. FluidApp skal give en bruger mulighed for at ændre defaultindstillingerne for den grafiske afbildning eller dataoversigtstabellen. Skal FluidApp anvendes af flere forskellige typer brugere med forskellige faglige baggrunde, skal det være muligt at modificere applikationens funktioner således, at disse er tilpasset den enkelte brugers behov. Dette kan bl.a. opfyldes ved at give brugeren mulighed for at ændre på systembestemte defaultindstillinger for visualiserende grafer og dataoversigtstabellen. FluidApp skal give en bruger mulighed for at sammensætte flere parametre i én grafisk afbildning. Ved at inkorporere denne funktionalitet, giver det sundhedspersonalet mulighed for at se sammenhænge mellem flere udvalgte parametre. 35

48 FluidApp skal kunne tilgå tidligere data for en patient. Tidligere målinger af f.eks. kropsvægt og væskeindgifter/udgifter skal kunne illustreres af systemet. Vægtdata, væskedata m.m. skal således tidsstemples jf. tidligere krav for, at en bruger kan finde tidligere registreret data frem for en bestemt tidsperiode. FluidApp skal kunne foretage et udskrift af tidligere registreret parameterværdier samt grafer, for at kunne dokumentere patienttilstanden. Et udskrift skal kunne foretages af de indskrevne dataværdier samt grafer således, at patientbehandlingen dokumenteres til patientens papirjournal. FluidApp skal håndtere brugerfejl og fejlindtastninger. Metoder til minimering af brugerfejl og fejlindtastninger anvendes således, at der forekommer en optimeret interaktion med FluidApp. Metoder kan f.eks. være at scanne brugerindtastninger for ulæselige data Non-funktionelle krav FluidApp skal kunne oprette forbindelse til en server database. For at kunne opgøre patientens væskebalance over flere døgn, er det nødvendigt at gemme observerede dataværdier for væskeparametre. Det er således nødvendigt at kommunikere med en database, for at udtrække data til anvendelse i FluidApp. En server database anvendes, da FluidApp skal kunne tilgås fra flere computer enheder. FluidApp skal demonstrere en brugerflade, hvis dimensioner kan modificeres. Programmet skal kunne køres på forskellige computerenheder, som kan have forskellige skærmformater. Derfor skal brugerfladens dimensioner kunne ændres uden at dette påvirker brugerfladens indhold. FluidApp skal informere systemets brugere om systemets tilstand. FluidApp skal give en bruger feedback omkring systemtilstanden således, at brugeren kan følge, hvor denne befinder sig i systemprocessen. F.eks. ved fejl i kommunikationen med databasen kan det være anvendeligt at meddele dette til brugeren, så brugeren ikke forventer at data f.eks. blev gemt i databasen. FluidApp skal være platformsuafhængigt. Ved anvendelse af programmeringssproget JAVA, kan dette opnås. FluidApp skal være nemt at genanvende i andre softwaresystemer. FluidApp skal designes ift. en række designmønstre således, at systemet nemt kan genbruges i andre softwaresammenhænge. 36

49 7.4 Use cases For at illustrere FluidApps funktionelle krav anvendes use cases. En use case (UC) beskriver, hvorledes et system anvendes af systemets brugere, og modellerer dermed interaktionen mellem brugeren af systemet og systemet selv. En UC beskrives ved en række scenarier, der alle er forbundet ved, at brugeren har et bestemt mål, som skal opnås ved anvendelse af systemet. Disse scenarier er en række sekventielle handlinger foretaget af systemets bruger, der leder til det fælles mål. En UC er således brugerinitieret, hvor systemets brugere ofte benævnes systemets aktører. En enkelt aktør kan udføre mange UC s, mens en enkelt UC kan blive udført af mange forskellige aktører [Fowler, 2004]. UC s kan opsamles i et UC-diagram for at give et overblik over, hvorledes de forskellige aktører interagerer med systemet gennem de opstillede UC s [Fowler, 2004]. To aktører, henholdsvis sygeplejersker og læger, er blevet identificeret som primæraktører til FluidApp, og kan samles under fællesbetegnelsen "Sundhedspersonale". Der anvendes en database i forbindelse med de enkelte UC s, men da databasen ikke initierer nogen af de opstillede UC s, vil denne ikke medregnes som aktør. I det følgende illustreres FluidApps identificerede UC s i figur

50 Figur 7.1: Figuren illustrerer systemets aktører, UC s og database. 38

51 I UC-diagrammet illustreret i figur 7.1 ses, at der forekommer toogtyve UC s, hvor enkelte af disse kan generaliseres ved de "tomme pile". Nogle UC s er opstillet som extensions af andre UC s, og er dermed yderligere handlingsmuligheder for den enkelte aktør. De enkelte UC s kan beskrives på en formaliseret form for at uddybe de enkelte UC s sekventielle handlingsforløb [Fowler, 2004]. Denne formaliserede form indeholder specifikationer som aktør, forudsætninger for UC, main succes scenario (MSS), følgetilstand og extensions. MSS beskriver det succesfulde forløb af sekventielle handlinger for at nå aktørens mål i den enkelte UC. Extensions beskriver variationer til MSS, som kan opstå gennem aktørens handlingssekvens [Fowler, 2004], [Arlow og Neustadt, 2005]. Følgende opstilles den formaliserede beskrivelse af de enkelte UC s illustreret i figur 7.1. Hver UC-beskrivelse efterfølges af et aktivitetsdiagram, der er med til at give et overblik over de aktiviteter, som forløber ved udførelse af UC ne. Aktivitetsdiagrammer kan demonstrere både sekventielle- og parallelle aktiviteter, og angiver ligeledes, hvilke meddelelser, som bliver modtaget eller sendt i den udførte handling [Eriksson et al., 2004]. Aktivitetsdiagrammerne inddeles i swimlanes for at illustrere, om det er systemet eller selve aktøren der udfører de enkelte handlinger. 39

52 7.4.1 UC: Håndter ingen forbindelse til database Hvis der ikke kan oprettes forbindelse til databasen, skal FluidApps brugere have mulighed for at prøve at oprette forbindelse igen eller komme ud af programmets valgte funktionalitet, der forårsagede et kald til systemets database. Dette illustreres i følgende UC: Håndter ingen forbindelse til database. Dennes formaliserede beskrivelse ses i tabel 7.1 og aktivitetsdiagram på figur 7.2. UC t indgår som en extension til mange af de øvrige UC s, men illustreres ikke på UCdiagrammet i figur 7.1 pga. dennes store interaktionsomfang. I aktivitetsdiagrammerne henviser den pågældende UC tilbage til en tidligere tilstand, når brugeren vælger at prøve igen. Denne tidligere tilstand er illustreret med en rød boksmarkering i aktivitetsdiagrammerne for UC s, der har UC: Håndter ingen forbindelse til database som extension. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Håndter ingen forbindelse til database Sundhedspersonale FluidApp kører. 1. Systemet giver en fejlmeddelelse omkring ingen forbindelse til database. 2. Systemet giver aktøren mulighed for at prøve at oprette forbindelse til databasen igen eller gå til en menu. 3. Aktøren vælger at prøve igen eller gå til en menu. Aktøren har håndteret fejlen omkring ingen forbindelse til databasen. Tabel 7.1: Formaliseret beskrivelse af UC: Håndter ingen forbindelse til database. Aktør System Håndter ingen forbindelse til database Giver besked om ingen forbindelse til database Giver aktøren mulighed for at prøve igen eller gå til en menu. [Ønsker ikke at forsøge igen] Gå til menu [Prøver at oprette forbindelse] Gå til den rødtmarkerede aktivitet Figur 7.2: Aktivitetsdiagram for håndteringen af ingen forbindelse til databasen. 40

53 7.4.2 UC: Identificer patient Før FluidApps væskerelaterede funktionaliteter kan anvendes, skal patienten identificeres ved indtastning af patientoplysninger. Er patienten allerede oprettet i FluidApps database, vil brugeren blot skulle registrere patientens barcode, CPR-nr eller anden form for identifikationsnummer. Er patienten endnu ikke oprettet, vil brugeren manuelt skulle registrere patientoplysninger som navn, køn og fødselsdato, hvilket forløber i UC: Opret patient. Brugeren kan herefter progrediere til systemets andre funktionaliteter. Tabel 7.2 og figur 7.3 viser dette UC. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Identificer patient Sundhedspersonale FluidApp kører 1. Aktøren indtaster patientens identifikationsnummer (ID) i form af enten en specifik stregkode, CPR-nr. eller andet identifikationsnummer. 2. Aktøren beder systemet om at finde patienten i FluidApps database. 3. Systemet validerer ID et ift. indtastningsfejl. 4. Systemet kan validere ID. 5. Systemet identificerer ID i databasen. 6. ID et er identificeret. 7. Systemet demonstrerer registreret patientdata (fornavn, efternavn, køn og fødselsdato) for brugeren. Patienten er identificeret og aktøren kan herefter fortsætte i programfunktionerne. 3.a: Systemet kan ikke validere ID et pga. ulæselige indtastninger; indtasninger med bogstaver, bindestreg m.m. 1. Systemet informerer aktøren herom, og beder aktøren om at prøve at indtaste patientens ID igen. 5.a: Systemet kan ikke validere ID et pga., at patienten med det indskrevne ID ikke er oprettet i databasen. 1. Aktøren modtager en notifikation omkring, at patienten ikke er oprettet i systemet. 2. Aktøren kan oprette patienten i databasen eller prøve at indtaste ID et igen. 5.b: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til databasen. Tabel 7.2: Formaliseret beskrivelse af UC: Identificer patient. 41

54 [Nej] Aktør Indtaster patientens identifikationsnummer Vælger at finde patienten i database [Ja] Opret patient System Validerer identifikationsnummer [ID ikke valideret] [ID valideret] Giver besked om fejlindtastning Find patient i database [Patient ikke oprettet i database] [Ingen forbindelse til database] Giver besked om, at patienten ikke er oprettet Håndter ingen forbindelse til database Giver besked om patienten skal oprettes eller ej Figur 7.3: Aktivitetsdiagram for UC: Identificer patient. [Patient fundet] Indskriver automatisk registreret patientdata 42

55 7.4.3 UC: Opret patient I visse tilfælde er en patient endnu ikke oprettet i FluidApps database, hvorfor følgende UC må forløbe for at kunne identificere patienten. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Opret patient Sundhedspersonale FluidApp kører, og patienten er ikke oprettet i systemets database. Aktøren har evt. modtaget en fejlmeddelelse om, at patienten ikke er oprettet i systemet, gennem UC: Identificer patient eller UC: Rediger patientoplysninger. 1. Aktøren opretter en patient ved at godkende patientens ID og evt. registrere fornavn, efternavn, køn og fødselsdato. 2. Aktøren vælger at gemme oplysningerne. 3. Systemet validerer patientoplysningerne for ulæselige karakter. 4. Patientoplysningerne valideret. 5. Systemet gemmer patientoplysningerne i databasen. Patienten er oprettet i systemet og aktøren føres herefter til FluidApps øvrige programfunktioner. 3.a : Oplysninger indeholder ulovlige karakterer eller er opsat på et ukorrekt format. 1. Aktøren har mulighed for at redigere fejlindtastninger. 5.a : Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.3: Formaliseret beskrivelse af UC: Opret patient. Aktør System Opret patient [Ønsker at indtaste patientoplysninger] Godkender identifikationsnummer [Indeholder ulæselige karakter] Validere patientoplysninger [Ellers] Registrerer patientoplysninger [Ønsker blank patient] Rediger fejlindtastninger Gemmer oplysninger i database [Ellers] [Succes] Vælger at gemme data Håndter ingen forbindelse til database Figur 7.4: Aktivitetsdiagram for oprettelse af en ny patient i FluidApps database. 43

56 7.4.4 UC: Rediger patientoplysninger Er ukorrekte eller mangelfulde patientprofiler blevet oprettet i FluidApps database, er det muligt for brugeren gennem UC: Rediger patientoplysninger at rette denne type patientprofiler. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Rediger patientoplysninger Sundhedspersonale FluidApp kører. 1. Aktør indtaster patientens ID. 2. Aktøren vælger at redigere patientoplysninger. 3. Systemet validerer ID et for ulæselige karakterer. 4. ID er valideret. 5. Systemet identificerer, om patienten er oprettet i systemets database ud fra det indtastede ID. 6. ID er identificeret. 7. Systemet indhenter tidligere registrerede patientoplysninger, og visualiserer disse for aktøren. 8. Aktøren redigerer patientoplysningerne. 9. Aktøren vælger at gemme de redigerede patientoplysninger. 10. Systemet validerer de nyindtastede oplysninger for ulæselige karakterer eller formater. 11. Oplysninger er valideret. 12. Systemet opdaterer patientprofilen i systemets database. Patientens personlige oplysninger er opdaterede. 3.a: Systemet kan ikke validere ID et pga. ulæselige indtastninger; indtasninger med bogstaver, bindestreg m.m. 1. Systemet informerer aktøren herom, og beder aktøren om at prøve at indtaste ID et igen. 5.a: Patienten med det indskrevne ID ikke er oprettet i databasen. 1. Aktøren modtager en notifikation omkring, at patienten ikke er oprettet i systemet. 2. Aktøren kan oprette patienten i databasen eller prøve at indtaste patientens ID igen. 10.a : Nyindtastede oplysninger indeholder ulovlige karakterer eller er opsat på et ukorrekt format. 1. Aktøren har mulighed for at redigere fejlindtastninger. 5.b og 12.a : Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.4: Formaliseret beskrivelse af UC: Rediger patientoplysninger. 44

57 Aktør System Indtaster patient ID Vælger at redigere patientinformation Validerer identifikationsnummer [ID ikke valideret] [ID valideret] Giver besked om fejlindtastning 1. Finder patient i database [Nej] [Patient ikke oprettet i database] Giver besked om, at patienten ikke er oprettet [Patient fundet ] [Ingen forbindelse til database] Håndter ingen forbindelse til database [Ja] Giver besked om patienten skal oprettes eller ej Indskriver automatisk registreret patientdata Opret patient Redigerer patientinformationer Gemmer nye oplysninger Validerer indtastede oplysninger [Fejl i oplysninger] [Ellers] Rediger fejlindtastninger 2. Prøver at opdatere patientoplysninger i databasen [Ingen forbindelse til database] [Systemet kan opdatere oplysningerne] 2. Håndter ingen forbindelse til database Figur 7.5: Aktivitetsdiagram for redigering af patientoplysninger UC: Registrer data FluidApp giver brugeren mulighed for at registrere data for forskellige parametre. Denne registreringsproces sker både i forbindelse med registrering af en hensigtserklæring for en række parametre eller i forbindelse med registrering af observerede dataværdier. Den eneste forskel mellem disse to scenarier er, at extension 1.a i følgende UC ikke kan forløbe ved en registrering af en hensigtserklæring, hvorfor denne ignoreres i pågældende situation. Dette, da de hensigtsmæssige dataværdier ikke er tilknyttet et observationstidspunkt som observerede dataværdier. 45

58 Use case Aktør Forudsætninger MSS Følgetilstand Extensions Registrer data Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. 1. Aktøren registrerer en dataværdi/dataværdier evt. for væskeindgiftsparametre og/eller væskeudgiftsparametere og/eller for andre parametre såsom kropsvægt i en registreringsoversigt. 2. I scenariet med registrering af observerede dataværdier, sætter aktøren et observationstidspunkt for den/de registrerede data. 3. Aktøren gemmer den/de registrerede data, og eventuelle tilføjede kommentarer. 4. Systemet validerer den/de registrerede data ift. læselighed. 5. Data kunne valideres. 6. Systemet tids-, bruger- og patientstempler den/de registrerede måling(er) for den/de enkelte parameter/parametre. 7. Systemet gemmer den/de registrerede data i databasen. Aktøren har registreret observeret parameterdata eller en hensigtserklæring. Registreret data kan anvendes af systemets andre funktioner, f.eks. til opgørelse af patientens væskebalance eller til fremvisning af en hensigtserklæring så andet sundhedspersonale kan se målet for det pågældende døgns væskebehandling. 1.a: Aktøren har brug for at knytte en kommentar til den/de pågældende dataværdi(er) 1. Aktøren har mulighed for at tilføje en kommentar til den/de registrerede måling(er). 1.b: Aktøren har brug for at registrere data om en ikke-tilføjet parameter eller parametre i en registreringsoversigt. 1. Aktøren vælger at tilføje/fjerne parametre fra registreringsoversigten. 1.c: Aktøren har brug for at fjerne en parameter/parametre fra en registreringsoversigt. Aktøren vælger at tilføje/fjerne parametre fra registreringsoversigten. 1.d: Aktøren har brug for at registrere data om en ikke-oprettet væskeparameter. 1. Aktøren har mulighed for at oprette en ny parameter, hvortil væskedata kan registreres efter denne er tilføjet til en registreringsoversigt. 2.a Aktøren sætter ikke et observationstidspunkt for den/de registrerede observationsdata. 1. Systemets aktuelle tidsstempel sættes som observationstidspunkt. 4.a: En registreret datamåling er ulæselig, dvs. indeholder andre karakterer end tal. 1. Systemet informerer aktøren herom. 1. Aktøren har mulighed for at redigere fejlindtastningen. 7.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.5: Formaliseret beskrivelse af UC: Registrer data. 46

59 Aktør System [Ellers] [Ønsker at tilføje/fjerne parameter/parametre] [Ønsker ny parameter] Opret ny parameter Indtaster data for parameter/parametre [Ønsker at registrere data] [Ønsker at tilføje parameter] Tilføj/fjern parametre til/fra registreringsoversigt [Ellers] Validerer data [Ønsker specifik tidsstempling] Sætter specifikt registreringstidspunkt [Fejl i data] Rediger fejlindtastning [Ellers] Data tids-, brugerog patientstemples [Ellers] Data gemmes [Ønsker at tilføje kommentar] [Kan ikke oprette forbindelse til database] [Ellers] Tilføj kommentar Vælger at gemme data Håndter ingen forbindelse til database Figur 7.6: Aktivitetsdiagram for registrering af parameterdata. Forekommer registreringen i hensigtserklærings-mæssigt øjemed, vil den grønt-markerede handling ikke kunne forløbe, hvorved der hoppes direkte ned til valget om tilføjelse af en kommentar. 47

60 7.4.6 UC: Rediger fejlindtastninger For at sikre mod fejl i registreret data, skal FluidApp validere værdier/oplysninger indtastet af en aktør. Opdages en fejlindtastning, vil aktøren få mulighed for at rette denne således, at data registreres korrekt. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Rediger fejlindtastninger Sundhedspersonale FluidApp kører og patienten er oprettet samt selekteret. En bruger har indtastet og forsøgt at gemme en ikke gyldig indtastning. 1. Systemet giver en advarsel om fejlindtastninger, og markerer disse med en asterisk (*). 2. Aktøren redigerer fejlindtastningerne eller sletter disse. Registreret data skulle gerne være korrekt, da aktøren har haft mulighed for at redigere disse. Tabel 7.6: Formaliseret beskrivelse af UC: Rediger fejlindtastninger. Aktør System Rediger fejlindtastning Giver advarsel og markerer fejl med (*) Data/oplysninger med fejl «iterative» [Fejlindtastning ønsket slettet] Indtastning slettes [Anden værdi/oplysning ønskes indskrevet] Anden værdi/oplysning indtastes istedet Ny indtastet data/oplysninger Figur 7.7: Aktivitetsdiagram for redigering af fejlindtastninger. 48

61 7.4.7 UC: Tilføj kommentar I følgende UC: Tilføj kommentar vises de sekventielle handlinger påkrævet for at tilføje en kommentar til en specifik observeret dataværdi. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Tilføj kommentar Sundhedspersonale FluidApp kører, og patienten er oprettet i systemets database samt selekteret. 1. Aktøren vælger et kommentarfelt tilknyttet et datafelt for en parameter. 2. Aktøren skriver en kommentar i kommentarfeltet. 3. Kommentaren knyttes til den dertilhørende dataværdi. Aktøren har givet en meddelelse videre til andet sundhedspersonale om den registrerede dataværdi således, at værdierne kan anskues kritisk. Tabel 7.7: Formaliseret beskrivelse af UC: Tilføj kommentar. Aktør System Tilføj kommentar Vælger kommentarfelt ud for ønsket parameter Kommentar indtastes Kommentaren knyttes til den dertilhørende dataparameter Figur 7.8: Aktivitetsdiagram for tilføjelse af en kommentar. 49

62 7.4.8 UC: Tilføj/fjern parametre til/fra registreringsoversigt En registreringsoversigt i FluidApp kan opbygges specifikt ift. den enkelte patients væskebehandling, da systemets brugere kan tilføje/fjerne parametre til/fra denne oversigt. Dette demonstreres i følgende UC: Tilføj/fjern parametre til/fra registreringsoversigt. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Tilføj/fjern parametre til/fra registreringsoversigt Sundhedspersonale FluidApp kører, og patienten er oprettet i systemets database samt selekteret. Aktøren har valgt at tilføje/fjerne en parameter til/fra registreringsoversigten. 1. Aktøren udvælger fra en parameterliste de parametre, som skal tilføjes/fjernes en registreringsoversigt for den udvalgte patient. 2. Aktøren vælger at tilføje/fjerne de udvalgte parametre til/fra registreringsoversigten. 3. Systemet opdaterer i databasen patientens tilknytningsstatus til de udvalgte parametre. 4. Systemet opdaterer registreringsoversigten og gør aktøren i stand til at registrere data for de udvalgte parametre. Aktøren kan registrere data for parametre, der er specifikt gældende for den udvalgte patients væskebehandling. 3.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.8: Formaliseret beskrivelse af UC: Tilføj/fjern parametre til/fra registreringsoversigt. Aktør System Tilføj/fjern parametre til/fra registreringsoversigt Vælger parametre der skal tilføjes/fjernes Vælger at tilføje/fjerne valgte parametre til/fra registreringsoversigt Opdaterer tilknytningsstatus i databasen [Kan ikke oprette forbindelse til database] [Ellers] Håndter ingen forbindelse til database Opdaterer registreringsoversigt med de udvalgte parametre Figur 7.9: Aktivitetsdiagram for at tilføje/fjerne parametre til/fra en registreringsoversigt. 50

63 7.4.9 UC: Opret ny parameter For at kunne modificere FluidApp til forskellige patientgrupper, har brugeren mulighed for at oprette en ny parameter, som herefter kan tilknyttes den enkelte patient gennem UC: Tilføj parametre til registrering. Den pågældende UC: Opret ny parameter forekommer som en extension til UC: Registrer data. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Opret ny parameter Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. Aktøren har valgt at oprette en ny parameter. 1. Aktøren indtaster navnet på den nye parameter. 2. Aktøren vælger om parametren er en væskeindgift eller -udgift, eller om parametren er en anden parameter end en væskeparameter. 3. Aktøren specificerer måleenheden for parametren. 4. Aktøren vælger at gemme parameterindstillingerne. 5. Systemet opretter en ny parameter i databasen med de indtastede specifikationer. Aktøren har mulighed for at registrere dataværdier for en ny parameter, hvis denne tilføjes til registreringsoversigten. 5.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.9: Formaliseret beskrivelse af UC: Opret ny parameter. Aktør System Opret ny parameter Indtaster navn på ny parameter Vælger om parameter er en indgift/udgift/andet Parameterspecifikationer gemmes Specificerer måleenhed [Ellers] [Succes] Vælger at gemme data Håndter ingen forbindelse til database Figur 7.10: Aktivitetsdiagram for oprettelse af en ny parameter. 51

64 UC: Se hensigtserklæring Brugeren har mulighed for at se en patients hensigtserklæring for et akutdøgn, dette sker gennem følgende UC: Se hensigtserklæring. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Se hensigtserklæring Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. 1. Systemet indhenter data for en hensigtserklæring for det pågældende akutdøgn fra databasen. 2. Systemet viser en oversigtstabel af dataværdierne i hensigtserklæringen. Aktøren har et overblik over målene for patientens væskebehandling i det pågældende akutdøgn. 1.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. 2. Systemet beder aktøren om at hente tabellens data igen eller annullere datatransaktionen, hvorved en tom tabel fremvises. 1.b: Systemet kan ikke finde en hensigtserklæring for patienten. 1. Systemet informerer aktøren herom. Tabel 7.10: Formaliseret beskrivelse af UC: Se hensigtserklæring. Aktør System [Prøver at oprette forbindelse igen] Indhenter data for hensigtserklæring fra database [Kan ikke oprette forbindelse til database] [Kan ikke finde hensigtserklæring for pågældende patient] [Succes] Giver besked om ingen forbindelse til database Hensigtserklæring fremvises i tabel Giver besked om ingen hensigtserklæring for patienten [Annullerer datatransaktion] Genererer en tom tabel Figur 7.11: Aktivitetsdiagram for UC: Se hensigtserklæring. 52

65 UC: Se væskebalance En bruger har mulighed for at se en patients væskebalance, som visualiseres gennem en oversigtstabel med væskedata. Dette demonstreres gennem UC: Se væskebalance. Tabellen giver således et overblik over patientens væskebalance, både ved visualisering af de samlede væskeindgifter og -udgifter og den udregnede væskebalance. Denne tabel er en erstatning for det nuværende primære papirbaserede væskeskema. Væskebalancen kan dog ligeledes visualiseres grafisk, hvorfor en extension til UC: Se grafisk oversigt af parameterdata forekommer. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Se væskebalance Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. 1. Systemet indhenter data for væskeparametre for en default tidsperiode fra databasen. 2. Systemet beregner patientens væskebalance og den akkumulerede værdi for hver enkelt af patientens registrerede væskeparametre. 3. Systemet viser en default oversigtstabel af de akkumulerede væskeværdier og væskebalancen. Aktøren har et overblik over de akkumulerede væskeindgifter og -udgifter samt over patientens væskebalance for en default tidsperiode. 1.a: Systemet kan ikke forbinde til databasen. 1. Systemet beder aktøren om at hente parameterdata igen eller annullere datatransaktionen, hvorved en tom tabel fremvises. 1.b: Systemet kan ikke finde væskedata for patienten. 1. Systemet informerer aktøren herom. 3.a: Aktøren ønsker en alternativ tidsperiode for tabellen end tabellens defaultindstillede tidsperiode. 1. Aktøren vælger en alternativ tidsperiode for tabellen. 3.b: Aktøren ønsker grafisk at visualisere patientens sygdomsforløb ift. væskebalancen. 1. Systemet viser en grafisk oversigt af parameterdata. Tabel 7.11: Formaliseret beskrivelse af UC: Se væskebalance. 53

66 Aktør System Indhenter data for væskeparametre for en default tidsperiode fra database [Kan ikke oprette forbindelse til database] [Kan ikke finde data for pågældende patient] [Prøver at oprette forbindelse igen] [Succes] Giver besked om ingen forbindelse til database Beregner væskebalance og akkumulerede væskeværdier Giver besked om ingen væskedata for patienten Væskebalance og akkumulerede væskeværdier fremvises i tabel [Annullerer datatransaktion] Genererer en tom tabel Vælg alternativ tidsperiode [Ønsker anden tidsperiode for tabel] [Ellers] [Ønsker at se graf over væskebalancen] [Ellers] Se grafisk oversigt Figur 7.12: Aktivitetsdiagram for visning af patientens væskebalance i en oversigtstabel. 54

67 UC: Se grafisk oversigt En bruger har mulighed for at gemme en række brugerdefinerede grafiske defaultindstillinger gennem UC: Vælg default parameter/parametre og UC: Ændr default tidsperiodeindstilling. Disse valgte defaultindstillinger demonstreres hver gang en grafisk oversigt, UC: Se grafisk oversigt, ønskes. Hvis brugeren ikke har tilknyttet en grafisk defaultindstilling, vil FluidApp automatisk generere en graf visualiserende den pågældende patients væskebalance over en systembestemt tidsperiode gennem UC: Se grafisk oversigt. Use case Se grafisk oversigt Aktør Sundhedspersonale Forudsætninger FluidApp kører, og patienten er oprettet i systemet samt selekteret. MSS 1. Systemet henter data for den/de defaultindstillede parameter/parametre for en default tidsperiode fra databasen. Har brugeren ikke tilknyttede defaultindstillinger, vælges systemets grafiske defaultindstillinger. 2. Systemet genererer en default graf over det indhentede data. Følgetilstand Aktøren har et grafisk overblik over den/de udvalgte defaultparameter/parametre for en default tidsperiode. Extensions 1.a: Aktøren ønsker en grafisk visualisering af andre parametre. 1. Aktøren vælger en parameter eller flere parametre, som skal visualiseres, fra en parameterliste. 1.b: Aktøren ønsker en alternativ tidsperiode end den systembestemte default tidsperiode. 1. Aktøren vælger en alternativ tidsperiode. 2.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. 2.b: Systemet kan ikke finde data i databasen. 1. Systemet meddeler aktøren herom. Tabel 7.12: Formaliseret beskrivelse af UC: Se grafisk oversigt. 55

68 Aktør [Ønsker visualisering af en anden parameter/parametre end væskebalancen] Vælg parameter/parametre [Ønsker en alternativ tidsperiode end den systembestemte tidsperiode] Vælg alternativ tidsperiode System Data hentes i databasen [Kan ikke oprette forbindelse til database] [Ellers] [Succes] Håndter ingen forbindelse til database Viser graf over data [Ellers] Figur 7.13: Aktivitetsdiagram for visning af en grafisk oversigt. [Kan ikke finde data i databasen] Giver besked om ingen data for parametren/parametrene 56

69 UC: Vælg parameter/parametre Ved UC: Se grafisk oversigt fremvises en graf med defaultindstillede parametre. En bruger skal dog kunne vælge at se andre parametre i en graf, hvorfor UC: vælg parameter/parametre forløber. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Vælg parameter/parametre Sundhedspersonale FluidApp kører, patienten er oprettet samt selekteret og aktøren har valgt at se en grafisk oversigt. 1. Aktøren udvælger en eller flere af de patienttilknyttede parametre, som denne vil se i en graf. Aktøren har et grafisk overblik over data for en default tidsperiode for den/de udvalgte parametre. 1.a: Aktøren ønsker at sætte den/de valgte væskeparameter som default parameter/parametre. 1. Aktøren vælger parametren/parametrene som defaultindstilling. Tabel 7.13: Formaliseret beskrivelse af UC: Vælg parameter/parametre. Aktør Vælg parameter/parametre [Ønsker kun én parameter i en graf] [Ønsker at sammensætte parametre i en graf] Vælger én bestemt parameter Vælger flere parametre [Ønsker at sætte parameter el. parametre til default indstilling] [Ellers] Vælg default parameter/parametre Figur 7.14: Aktivitetsdiagram for valg af parameter/parametre. 57

70 UC: Vælg default parameter/parametre Brugeren kan få tilknyttet en parameter/parametre som defaultindstilling. Dette, så FluidApp kan vise en graf med brugerens udvalgte parameter eller parametre uden, at brugeren skal vælge den samme grafindstilling hver gang et grafisk overblik ønskes. Dette kan være anvendeligt, hvis en bestemt graf altid anvendes af den pågældende bruger, hvorved FluidApp vil blive nemmere at anvende for den individuelle bruger. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Vælg default parameter/parametre Sundhedspersonale FluidApp kører, og patienten er oprettet samt selekteret i FluidApp. Aktøren har valgt at se en grafisk oversigt, og har udvalgt en parameter/parametre. 1. Aktøren vælger den selvvalgte parameter eller parametre som default. 2. Systemet gemmer defaultindstillingen i databasen for den enkelte bruger. FluidApp tilpasses til at vise en graf med aktørens udvalgte parameter/parametre frem for en systembestemt default graf. 2.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til databasen. Tabel 7.14: Formaliseret beskrivelse af UC: Vælg default parameter/parametre. Aktør System Vælg default parameter/parametre Sæt parameter/parametre til default Vælger at gemme defaultindstilling Gemmer indstilling for aktøren i database [Ingen forbindelse til database] [Ellers] Håndter ingen forbindelse til database Figur 7.15: Aktivitetsdiagram for valg af en default parameter eller parametre. 58

71 UC: Vælg alternativ tidsperiode Denne UC er en extension af UC: Vis grafisk oversigt og UC: Se væskebalance, da en bruger har mulighed for at vælge en alternativ tidsperiode end den sat som default af FluidApp. Således kan en bruger få et overblik over, hvorledes en patients tilstand har udviklet sig over forskellige tidsperioder. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Vælg alternativ tidsperiode Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. Aktøren har valgt at se en grafisk oversigt eller se patientens væskebalance. 1. Aktøren vælger en alternativ tidsperiode end grafens eller dataoversigttabellens nuværende default tidsperiode. Aktøren har et overblik, grafisk såvel som tabelmæssigt, over de udvalgte parametre for en valgt tidsperiode. 1.a : Aktøren ønsker at sætte den valgte tidsperiode som defaultindstilling for grafen/tabellen. 1. Aktøren ændrer default tidsperiodeindstillingen for grafen og/eller oversigtstabellen med observerede parametre. Tabel 7.15: Formaliseret beskrivelse af UC: Vælg alternativ tidsperiode. Aktør Vælg alternativ tidsperiode Vælger ny grafisk eller tabelmæssig tidsperiode [Vælg alternativ tidsperiode som default] [Ellers] Ændr default tidsperiodeindstilling Figur 7.16: Aktivitetsdiagram for valg af alternativ tidsperiode. 59

72 UC: Ændr default tidsperiodeindstilling En bruger skal have mulighed for at ændre indstillingerne for den default tidsperiode, der er fastsat af systemet. Dette, da systemet skal tilpasses forskellige typer brugere, der kan have forskellige informationsbehov. Følgende UC en extension til UC: Vælg alternativ tidsperiode. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Ændr default tidsperiodeindstilling Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. Aktøren har valgt at se en grafisk oversigt eller en oversigtstabel, og har valgt en alternativ tidsperiode end FluidApps default tidsperiode. 1. Aktøren vælger den selvvalgte tidsperiode som default tidsperiode. 2. Systemet gemmer defaultindstillingen i databasen for den enkelte aktør. FluidApp tilpasses til at vise en graf med aktørens valgte tidsperiode frem for en systembestemt tidsperiode. 2.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.16: Formaliseret beskrivelse af UC: Ændr default tidsperiodeindstilling. Aktør System Ændr default tidsperiodeindstilling Vælger at sætte tidsperiode som default tidsperiode Gemmer indstilling for aktøren i database [Kan ikke oprette forbindelse til database] [Ellers] Håndter ingen forbindelse til database Figur 7.17: Aktivitetsdiagram for ændring af FluidApps default tidsperiodeindstilling. 60

73 UC: Se tidligere data En bruger kan vælge at se en patients tidligere registrerede dataværdier, både i form af observerede dataværdier samt hensigtsmæssige dataværdier. Dette opnås igennem UC: Se tidligere data. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Se tidligere data Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. Aktøren har valgt at se patientens tidligere registrerede dataværdier. 1. Systemet indhenter data fra databasen i form af både tidligere registrerede hensigtserklæringer og observerede dataværdier. 2. Datahistorik for observerede dataværdier samt hensigtsmæssige dataværdier fremvises. 3. Aktøren har mulighed for at redigere de tidligere data. Aktøren har et overblik over patientens datahistorik både for registrerede hensigtserklæringer samt for observerede patientdata. 1.a: Ingen tidligere data er at finde i databasen for den pågældende patient. 1. Systemet informerer aktøren, at ingen tidligere data er tilgængelige. 1.b: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.17: Formaliseret beskrivelse af UC: Se tidligere data. Aktør System Tidligere registreret data hentes fra database [Ellers] [Kan ikke oprette forbindelse til database] [Kan ikke finde registreret data] [Ønsker redigering af data] Datahistorik vises Giver besked om ingen tidligere registreret data Håndter ingen forbindelse til database [Ellers] Rediger tidligere data Figur 7.18: Aktivitetsdiagram for visning af tidligere data. 61

74 UC: Rediger tidligere data Da der kan forekomme fejl ved registrering af parameterdata, skal en bruger have mulighed for at redigere disse. Dette forløber i UC: Rediger tidligere data, som er en extension til UC: Se tidligere data. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Rediger tidligere data Sundhedspersonale FluidApp kører, og patienten er oprettet i systemets database samt selekteret. Væskedata er registreret i systemet, og aktøren har valgt at redigere tidligere data. 1. Aktøren vælger den parameterværdi, som skal rettes. 1. Aktøren redigerer den fejlindtastede dataværdi. 2. Aktøren gemmer den redigerede værdi. 3. Systemet gemmer den redigerede værdi i databasen. 4. Systemet markerer den redigerede dataværdi. Registreret data skulle gerne være korrekt, da aktøren har haft muligheden for at redigere disse. 3.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet håndterer ingen forbindelse til database. Tabel 7.18: Formaliseret beskrivelse af UC: Rediger tidligere data. Aktør System Rediger tidligere data Udvælger fejlindtastede dataværdi Gemmer redigeret data i database [Kan ikke oprette forbindelse til database] [Ellers] Dataværdi rettes Håndter ingen forbindelse til database Markerer redigeret dataværdi Vælger at gemme redigeret dataværdi Figur 7.19: Aktivitetsdiagram for redigering af tidligere data. 62

75 UC: Lav udskrift En bruger har mulighed for at foretage et udprint af enten oversigtstabellerne, tidligere data eller den grafiske oversigt således, at disse udprint kan dokumentere patienttilstanden til f.eks. patientens papirjournal. Udprintet sendes til en printer, men denne forbindelse mellem printer og systemet behandles ikke yderligere i dette projekt. Use case Aktør Forudsætninger MSS Følgetilstand Extensions Lav udskrift Sundhedspersonale FluidApp kører, og patienten er oprettet i systemet samt selekteret. 1. Aktøren vælger at udskrive data. 2. Udskriftet vises på brugergrænsefladen før accept fra aktøren. 3. Aktøren accepterer udskrift. 4. Systemet sender besked til printer omkring udskrift. Aktøren har papirudskrift til patientens papirjournal. 4.a: Systemet kan ikke forbinde til printeren. 1. Systemet informerer aktøren om fejlen. 2. Systemet håndterer ingen forbindelse fejlen. Tabel 7.19: Formaliseret beskrivelse af UC Lav udskrift. Aktør System Vælger udskrift Eksempel på udskrift vises på brugerflade [Ellers] [Accepterer] Printforespørgsel til printer [Kan ikke oprette forbindelse til printer] [Ellers] Giver besked om ingen forbindelse til printer Håndter ingen forbindelse til database Figur 7.20: Aktivitetsdiagram for udprint af patientrelaterede data. 63

76

77 Kapitel 8 Objektorienteret analyse - OOA Behovet for et softwaresystem opstår først i problemdomænet, da alt softwareudvikling udvikles med målet om at afvikle et bestemt problemområde. I dette kapitel er målet at modellere problemdomænet vha. UML, hvor tekniske detaljer omkring softwaresystemet udelades indtil designet af systemet. Modellering af problemdomænet sker gennem en identifikation af analyseklasser, der skal modellere systemets statiske struktur. De fundne analyseklasser opstilles i et klassediagram for at illustrere systemets objekttyper og disses indbyrdes relationer, betegnet som den statiske struktur. Kapitlet afsluttes med en demonstration af systemets dynamiske adfærd, hvordan objekterne interagerer med hinanden, der beskrives ved interaktionsdiagrammer, som i dette projekt afvikles ved anvendelse af sekvensdiagrammer [Arlow og Neustadt, 2005], [Fowler, 2004]. 8.1 Introduktion til objekter og klasser For at fange problemdomænets struktur i en softwarestruktur, er det nødvendigt at identificere en række entiteter, der beskriver problemdomænet. En entitet er enten en konkret ting eller et koncept fra den virkelige verden, hvorfor entiteter er komplekse med multiple egenskaber. Et problemdomæne kan bestå af flere forskellige entiteter, som abstraheres til objekter i softwaredomænet. Denne abstraktion af entiteter til objekter kan gøre, at virkeligheden modificeres, da objekter blot er en samling af states og behaviours associeret med den identificerbare entitet 1, se appendiks B. I den virkelige verden kan mange entiteter, som er af samme type med samme egenskaber, identificeres. Dette afspejles i softwaredomænet med klasser. En klasse kan ifølge [Arlow og Neustadt, 2005] beskrives som en deskriptor for objekter, der alle har samme egenskaber. Klasser er således en form for skabelon, hvorudfra individuelle objekter kan kreeres [Arlow og Neustadt, 2005]. Alle objekter fra den samme klasse må nødvendigvis have samme sæt af operationer, som disse kan udføre, de samme attributter hvori det individuelle objekt kan have specifikke værdier, og de samme relationer [Oracle, 2013c], [Arlow og Neustadt, 2005]. I UML afspejles klasser som et rektangel indeholdene felter, hvor de enkelte felter afspejler henholdsvis klassens navn, attributter, metoder og evt. klassens ansvarsområder [Arlow og Neustadt, 2005]. Dette illustreres i figur Et objekt beskrives ligesom entiteter ved state og behaviour, hvor state af et objekt bestemmes af objektets attributværdier, og objektets behaviour blotlægges gennem dennes metoder [Oracle, 2013c]. 65

78 Klassenavn Attributter Metoder() Ansvarsområder Figur 8.1: Klasseopsætning i UML [Arlow og Neustadt, 2005]. UML yder en vis fleksibilitet ift. hvilke felter, der inkluderes, og i hvilken detaljeringsgrad indholdet er beskrevet ved de enkelte felter i en klasseopsætning. Målet er, at kun den nødvendige information opstilles i klasserne i et klassediagram, hvorfor indholdet i henholdvis analyseklasser og designklasser forekommer forskelligt. Analyseklasser skal præsentere de væsentligste attributter og metoder for en klasse, hvilke den resulterende designklasse (højst sandsynligt) vil indkorporere i en eller anden mere detaljeret form [Arlow og Neustadt, 2005]. I det følgende præsenteres analyseklasserne for FluidApp. 8.2 Identifikation af FluidApps analyseklasser Den statiske struktur af et system beskriver hvilke typer af objekter, som er vigtige for modelleringen af systemet, og hvordan disse objekter er relateret til hinanden. Opbygningen af den statiske systemstruktur kræver således en identifikation af systemets analyseklasser [Arlow og Neustadt, 2005]. Forskellige analyser og teknikker kan anvendes til identifikation af analyseklasser, hvor en substantiv/verbum analyse er blevet anvendt til at identificere kandidatklasser til analyseklasser. En substantiv/verbum analyse blev udført ved identifikation af substantiver og verber fra passende informationskilder såsom systemets opstillede krav, UC s og aktivitetsdiagrammer. De fundne substantiver og verber er blevet anvendt til at kategorisere en række kandidatklasser med tilhørende attributter og ansvarsområder. Ansvarsområderne for den enkelte kandidatklasse er afspejlet gennem metoderne for denne klasse i UMLklasseopsætningsmodellen vist tidligere i afsnit 8.1 [Arlow og Neustadt, 2005]. Resultatet af substantiv/verbum analysen samt de fundne kandidatklasser ses på henholdsvis figur 8.2 og

79 Substantiver Patient Vægt Stregkode CPR Navn Fødselsdag Køn Identifikation Identifikationsmetode Identifikationsnummer Patienttilstand Patientdata Patientoplysninger Bruger Parameter Ny parameter Parameterliste Dataværdi Væskedata Væskebalance Væskeindgift Væskeudgift Måleenhed Infusionsrate Akkumulation Udregning Database Tabel Oversigtstabel Default tabel Graf Tidsperiode Alternativ tidsperiode Default tidsperiode Tidsperiodeindstilling Defaultindstilling Menu Fejl Fejlindtastning Fejlmeddelelse Brugerfejl Ulæselige data Datagrænsetærskel Kommentar Kommentarfelt Meddelelse Tidligere data Datahistorik Udskrift Printer Identificere Registrere Indtaste Prøve Foretage Tidsstemple Brugerstemple Tilføje Oprette Tilknytte Akkumulere Udregne Beregne Sammensætte Selektere Vælge Specificere Tilgå Hente Indhente Gå til Spørge Validere Tillade Gemme Slette Vise Præsentere Demonstrere Anskue Give Sætte Ændre Redigere Markere Håndtere Verber Figur 8.2: Figuren illustrerer henholdsvis substantiver og verber fundet ved gennemgang af UCs, funktionelle krav m.m. De fundne substantiver anvendes til identifikation af attributter og kandidatklassenavne, og de fundne verber anvendes til identifikation af klasseoperationer. En række ændringer foretages på de fundne kandidatklasser, når disse skal omdannes til analyseklasser. Ved omdannelsen oversættes klassenavn, attributter og metoder m.m. til engelsk for at internationalisere FluidApp. På denne måde kan flere personer anvende klasserne i FluidApp. 67

80 Kandidatklasser Patient identifikationsnummer navn fødselsdag køn patientdata tilføjnavn() tilføjvægt() tilføjfødselsdag() tilføjkøn() tilføjidentifikationsnummer() identificerpatient() selekterpatient() hentpatientdata() gempatientdata() sletpatientdata() demonstrerpatientdata() redigerpatientdata() Parametre måleenhed infusionsrate akkumulation parameternavn opretnyparameter() sletparameter() gemparameter() ændrparameter() validerparameter() tilføjparameternavn() tilføjmåleenhed() sætinfusionsrate() Dataværdier tid dato brugerid dataværdi væskedata væskeindgift væskeudgift væskebalance hentvæskedata() gemvæskedata() sletvæskedata() redigervæskedata() validervæskedata() tidsstempeldata() brugerstempeldata() datostempeldata() registrerdata() akkumulervæskeindgift() akkumulervæskeudgift() beregnvæskebalance() gemvæskebalance() Fejl meddelelse fejlmeddelelse fejlindtastning brugerfejl fejl ulæseligdata håndterfejl() visfejlmeddelelse() vismeddelelse() præsenterulæseligdata() præsenterbrugerfejl() Database dataværdi tabel kommentar tidligeredata gemdata() sletdata() tilføjdata() redigerdata() tilføjkommentar() gemkommentar() hentdefaulttabel() hentdatahistorik() Oversigt tabel defaulttabel graf grafparameter tidsperiodeindstilling defaultindstilling datahistorik sammensætgrafparametre() redigertidsperiode() sættidsperiode() gemtidsperiode() sætdefaulttabel() gemdefaultindstillling() UserInterface input output graf tabel data registrerbrugerinput() demonstrerdefaulttabel() demonstrer Tabel() demonstrerdefaultgraf() demonstrergraf() visdatahistorik() Bruger brugerid hentbrugerdata() Figur 8.3: Figuren illustrerer de fundne kandidatklasser. 68

81 Det primære mål med en OOA er at gøre et system vedligeholdbart. Dette gøres ved at dele kandidatklasserne op i mindre klasser, så hver klasse maksimalt har 5 ansvarsområder [Arlow og Neustadt, 2005]. På denne måde indeholder FluidApp en række mindre klasser med specificerede ansvarsområder, som kan anvendes i flere forskellige sammenhænge i systemet. F.eks. kan det være nødvendigt at validere data flere steder i et system, hvorfor en valideringsklasse, hvis eneste funktionalitet er at validere data, kan være anvendelig. For at opnå denne fordeling af ansvarsområder kigges på, om flere klasser har samme attributter. Er dette tilfældet kan nedarvning benyttes. Desuden ses på metoderne for de enkelte kandidatklasser, og om disse kan indikere en inddeling i følgende klassetyper [Arlow og Neustadt, 2005]: «control», kontrollerer datastrømme. «entity», varetager lagring af konstant data. «boundary», kommunikerer med en ekstern aktør. En inddeling af de fundne kandidatklasser ift. ovennævnte klassetyper leder til en omrangering af kandidatklassernes operationer og attributter, hvilket gør, at flere analyseklasser udarbejdes. Kandidatklasserne Patient og Bruger bliver til «entity» klasser, da disse indeholder persistente informationer omkring henholdsvis en patient og en bruger, der anvendes i flere UC s. Kandidatklassen Dataværdier deles op i følgende analyseklasser for at opnå fordelingen med maksimalt 5 ansvarsområder per klasse: Parameter: Objekter af denne klasse repræsentere typer af målbare parametre. ObservedValue: Repræsenterer objekter for hvilke der kan observeres en værdi på et givent tidspunkt. CalculatedValue: Giver en metode til beregning af en værdi for en patient. Perspiratio: Repræsenterer en patients beregnede perspiratio. FluidBalance: Repræsenterer en patients beregnede væskebalance ud fra de observerede værdier og den beregnede perspiratio. Parameter og ObservedValue anses som «entity» klasser, da disse indeholder persistent information, som kan anvendes af flere klasser. Parameter og ObservedValue klasserne har hermed simpel adfærd i form af get()- og set()-metoder, hvor ObservedValue nedarver flere attributter og operationer fra Parameter-klassen. Parameter-klassen er således en superklasse til subklassen ObservedValue. Parameter-klassen sættes som en superklasse, da denne klasse beskriver nogle generaliserbare attributter og metoder, såsom en værdi og en enhed, der kan være anvendelige for flere forskellige klasser, her Observed- Value-klassen. ObservedValue-klassen beskriver derudover flere specifikke attributter og metoder, hvorfor denne er subklasse til Parameter. FluidBalance samt Perspiratio sættes til «entity» klasser, da disse klasser indeholder informationer vedrørende patientens udregnede væskebalance og perspiratio. FluidBalance og Perspiratio klasserne dannes på baggrund af systemkravene i afsnit 7.3, hvor en automatisk udregning af disse er en ønsket funktionalitet af systemet. Disse to klasser nedarver fra CalculatedValue-klassen, da både FluidBalance og Perspiratio-klassen 69

82 indebærer en calculate()-metode for at udregne henholdsvis patientens væskebalance og perspiratio. Ud fra tidligere beskrevne UC s har det vist sig, at data både skal valideres og redigeres. Derfor specificeres en Validator- og Editor-klasse, der begge er af typen «control» og implementerer metoder tilsvarende til henholdsvis validervæskedata() og rediger- VæskeData() fra kandidatklassen Dataværdier. Da flere klasser kan have behov for at validere og redigere data, indeholder disse klasser en række statiske metoder, som kan kaldes direkte på Validator- og Editor-klassen. Parameterdata registreret i systemet skal gerne være i form af talværdier, hvorfor en specifik metode til validering af brugerens systeminput inkorpureres i Validator-klassen i form af isnumeric()-metoden. Redigering af data sker gennem metoden editfaultyvalue() i Editor-klassen. Interaktionen mellem FluidApps brugere og systemet foregår gennem en UserInterfaceklasse, der tilsvarer kandidatklassen UserInterface. Denne klasse er en blanding af typen «boundary» og «control», da denne klasse både står for al kommunikation mellem brugerne og systemet, samt håndterer brugeres interaktioner med systemet, og sætter gang i UC-specifik opførsel alt efter hvordan disse interagerer med FluidApp. Systemet skal kunne visualisere data, hvilket demonstreres gennem kandidatklassen Oversigt. Denne klasse opdeles i to specifikke analyseklasser, henholdsvis en Table- og Graphklasse, begge af typen «entity». Flere klasser kan have brug for at tilgå en patients dataværdier for at kunne udføre klassernes specifikke operationer og dermed udføre systemets funktionaliteter. For at kunne hente patientdata fra en database er det nødvendigt med en klasse, der indeholder statiske metoder til at tilgå databasen. Hermed oprettes en DatabaseManager-klasse af typen «control», der skal kontrollere datastrømmene mellem databasen og de enkelte klasser. DatabaseManager-klassen ekstraherer og gemmer således data gennem henholdsvis extractfromdb()- og savetodb()-metoden. I figur8.4 ses de fundne analyseklasser for FluidApp: 70

83 «control» DatabaseManager data savetodb() extractfromdb() connecttodb() disconnectfromdb() -- Controls the flow of data into and out of the database. «control» Validator textfield IsNumeric() -- Validates whether data has been written in invalid characters. «control» Editor oldvalue newvalue timechanged datechanged editfaultyvalue() -- Enable the user to edit saved data from the database. «control» Printer document connecttoprinter() printdoc() -- Connects to a printer and ables the user to print out data tables. «entity» CalculatedValue result calculateparameter() -- Give methods for calculation of different parameters. «entity» Patient name sex birthday patient_id setpatientinfo() getpatientinfo() viewpatientinfo() -- Objects of this class represents patients and contain various patient- -information * * «entity» Parameter name unit type parameterid value setparameterinfo() getparameterinfo() -- Represents types of measurable parameters -- Give fields to subclasses. «control» DataHistory -- Enable the user to edit former registered data. «boundary/control» UserInterface setgui() showgui() getgui() updategui() showerrormessage() actionperformed() checkinput() markflaweddata() -- Sets up GUI design. -- Communicates with external actors. -- Listens for action events in GUI, and calls methods from other classes. -- Checks for any user input after actions performed, and marks invalid data rate weight «entity» Perspiratio -- Calculate the perspiration of the patient, that is dependent on the patients daily weight. 1 1 «entity» FluidBalance data convertrate() getfluidbalance() getsubtotal() -- Calculate a patients fluidbalance with data from ObservedValue and PerspiRatio * comment timestamp «entity» ObservedValue -- The class represents objects that can be observed as having a value at a given time * 1 * «entity» Table row rowname column columnname displaytable() adjusttimeaxes() -- Objects of this class represents tables that can be displayed in a user interface. «entity» Graph coordinates axes linetype graphtype displaygraph() adjusttimesaxes() adjustparameters() -- Objects of this class represents graphs that can be displayed in a user interface. * 1 1 «entity» User name department position observator_id setuser() getuser() -- Objects of this class represents a user of FluidApp «entity» UserPreferences setdefaulttabel() setdefaultgraph() -- Holds the users preferences for the graphical presentation of data. Figur 8.4: Analyseklasser fundet på baggrund af kandidatklasser fra substantiv-verbum analysen. 71

84 8.3 Dynamisk systembeskrivelse En dynamisk beskrivelse af systemet illustrerer livscyklussen af de objekter, der statisk er beskrevet ved de opstillede analyseklasser. Objekters livscyklus illustreres både ved instantieringen af analyseklasser samt ved interaktionen mellem de instantierede objekter nødvendig for at levere systemets ønskede funktionaliteter. Denne kollaboration mellem analyseklassernes instanser kan demonstreres gennem såkaldte interaktionsdiagrammer. I dette projekt er sekvensdiagrammer valgt til at modellere disse objektinteraktioner, da disse viser interaktionen og livscyklussen af de enkelte objekter i en tidsmæssig sekventiel orden [Arlow og Neustadt, 2005]. De ønskede systemfunktionaliteter udspilles i høj grad gennem de opførte UC s fra afsnit 7.4, hvor sekvensdiagrammerne er en visuel realisering af systemets UC s, og dermed en visuel realisering af systemets funktionaliteter. Den primære systemfunktionalitet beskrives gennem UC: Se væskebalance, hvorfor et sekvensdiagram for denne UC præsenteres i figur 8.5. Netop disse UC er udvalgt, da denne UC giver en bruger mulighed for at se en opgørelse af en patients aktuelle væskebalance, hvilket er kernefunktionaliteten i FluidApp. Væskebalancen udregnes i FluidApp vha. ligning 2.1. Når en patient får en væskeindgift eller -udgift, der gives som en rate, skal denne rate omregnes til en samlet væskeværdi, der skal benyttes i formel 2.1. Måden hvorpå denne rate indgift/udgift bliver beregnet ses i formel 8.1: Samlet indgif t/udgif t f or en rate [ml] = (sluttid [t] starttid [t]) rate [ml/t] (8.1) Den udregnede væskebalance fremvises i en oversigtstabel sammen med subtotaler for de registrerede væskeparametre, hvilket illustreres i figur 8.5. Sekvensdiagrammet indeholder en række gule bokse udgående fra de opstillede analyseklasser, der hentyder til et aktivt objekt. Boksene opstår således først ud fra de enkelte analyseklasser når en metode kaldes på analyseklassens instans eller når en statisk metode kaldes. Statiske metoder defineres som operationer, der ikke kræver instantiering af et klasseobjekt, men udføres direkte på klassen [Murach, 2011]. Denne type metoder er i sekvensdiagrammet markeret med en understregning. De sorte pile illustrerer metodekald, der både kan udføres på de forskellige instanser af analyseklasserne, og kaldes på selve den udførende instans. Dette ses ved, at en sort pil både udgår og går ind til sin egen gule boks. Desuden ses en række interaktionsrammer på figur 8.5, der indeholder en række interaktionsscenarier. Disse scenarier vil betyde noget forskelligt alt efter hvilken interaktionsramme disse foregår indenfor, f.eks. vil interaktionerne inden for en loop-ramme gentages flere gange [Arlow og Neustadt, 2005], [Fowler, 2004]. 72

85 User :UserInterface "Se væskebalance" DatabaseManager actionperformed() new :FluidBalance extractfromdb() alt error [no values] error showerrormessage() [values found] calculate() ObservedValues loop [for every found value] new :ObservedValue filterdata() new new :Table getperspiratio() getsubtotal() getfluidbalance() displaytable() Figur 8.5: Sekvensdiagrammet viser interaktionerne ved udførelse af UC: Se væskebalance. :Perspiratio 73

86

87 Kapitel 9 Objektorienteret design - OOD I foregående analyse blev systemstrukturen defineret uden inddragelse af systemets tekniske detaljer. I dette kapitel er målet at udvide analysen ved at inddrage designmæssige og tekniske beslutninger forbundet med FluidApp. Kapitlet skal således demonstrere de designmæssige valg ift. FluidApps brugergrænseflader og FluidApps designklasser, samt beskrive de anvendte designmønstre i systemets softwarearkitektur. Brugergrænseflader for FluidApp visualiseres i såkaldte mock-ups, der viser et forestillet design for systemets senere implementerede brugergrænseflader. Udformningen af systemets mock-ups designes ift. en række brugbarhedsprincipper eller såkaldte usability - principper, der skal gøre systemet let anvendeligt for brugeren således, at FluidApps funktionaliteter udnyttes bedst muligt. Efterfølgende præsenteres systemets softwarearkitektur i form af udvalgte designmønstre. Den valgte softwarearkitektur skal bidrage med en struktureret løsning for den tekniske opbygning af systemet, og dermed struktureringen af systemets designklasser. Kapitlet afsluttes således med en gennemgang af de fundne designklasser og disses dele i systemstrukturen. Designklasserne illustreres både gennem statiske og dynamiske diagrammer. 9.1 System usability Udviklet software bruger ofte en stor mængde programkode på at definere softwarens brugerflade, hvorfor det findes retfærdigt, at der i selve udviklingsprocessen af et softwaresystem foretages overvejelser omkring, hvorledes god usability kan opnås i dette system [Nielsen, 1993]. Usability af et system er et mindre element i en større overvejelse omkring opnåelsen af systemacceptabilitet. For at et system vil blive anvendt, skal dette ifølge [Nielsen, 1993] have en god systemacceptabilitet. Faktorer indspillende på acceptabiliteten af et system er illustreret i figur

88 Social acceptabilitet Anvendelighed (utility) Brugbarhed (usefulness) Usability Let at lære at anvende Høj effektivitet ved brug Systemacceptabilitet Let at huske, hvordan anvendes Bekostning Kompatibilitet Har en lav fejlrate Subjektivt behageligt at anvende Praktisk acceptabilitet m.m. Pålidelighed Figur 9.1: Figuren viser en række faktorer, der er afgørende for et systems acceptabilitet. Her ses, hvordan utility og usability udgør systemets brugbarhed (usefullness). Figuren er oversat fra [Nielsen, 1993]. Systemacceptabilitet kan beskrives som en kombination af både social og praktisk acceptabilitet. Systemet skal socialt accepteres af brugerne, men skal ligeledes opnå en praktisk acceptabilitet inden for kategorier såsom omkostninger, pålidelighed, kompatibilitet, brugbarhed (usefullness) m.m. Usefullness indebærer, hvorvidt et system kan anvendes til et opnå et bestemt mål, og udgøres af faktorer som utility og usability. Begrebet utility skal udtrykke, hvorvidt et systems funktionalitet er egnet til at løse en opgave, mens usability er et udtryk for, hvorvidt brugeren er i stand til at udnytte systemets funktionalitet [Nielsen, 1993]. Da usability i sig selv er et abstrakt begreb kan det ifølge [Nielsen, 1993] beskrives ud fra flere komponenter, hvilke ses i figur 9.1. For at tilgodese disse komponenter af usability i et systems brugerflade, opstiller [Nielsen, 1993] designprincipper, som en systemudvikler bør følge: 1. Have en simpel og naturlig dialog, da brugerflader ofte kompliceres direkte på grund af antallet af informationer og features, som disse indeholder. Den ideelle brugerflade skal således kun vise den nødvendige information på det nødvendige tidspunkt nødvendige og sted i brugerfladen. Information, som er tiltænkt at anvendes sammen, bør placeres tæt sammen i en brugerflade [Nielsen, 1993]. 2. Tale brugerens sprog. 3. Begrænse brugerens behov for at huske information fra tidligere. 4. Konsistens mellem ordfaser, situationer og aktioner således, at brugeren f.eks. ikke er i tvivl om to forskellige ord betyder det samme. 5. Give feedback, så brugeren er informeret omkring begivenhederne i systemet. 6. Vise tydelige udgange, så brugeren kan komme ud af en forkert valgt tilstand. 7. Implementere genveje for at effektivisere systemet for erfarne brugere. 8. Give gode forklarende fejlmeldinger. 76

89 9. Forebygge fejl. 10. Lettilgængelig og anvendelig hjælp og dokumentation af systemet. 9.2 Grafisk design af FluidApp I følgende afsnit præsenteres FluidApps overordnede brugerfladedesign samt de enkelte brugergrænseflader, som forventes at blive implementeret i det endelige system. Mockups anvendes således som et led i udviklingen af softwaresystemer til at sikre konsistens i designstrukturen af et system. Designstrukturen af FluidApp diskuteres desuden ift. designprincipperne opgivet i foregående afsnit Overordnet design af FluidApps brugergrænseflader FluidApps overordnede design består af et navigationspanel indeholdende en række faneblade, jf. figur 9.2. Panelet placeres øverst i FluidApps brugergrænseflader, og giver en hurtig tilgang til systemets funktionaliteter, da fanerne konstant er synlige for brugere. Anvendelsen af faneblade korresponderer til designkomponenter anvendt i f.eks. internetbrowsere og andre softwaresystemer. Ved at anvende genkendelige komponenter fra andre systemer, kan dette gøre FluidApp mere indlæringsvenligt overfor systemets mindre erfarne brugere, der således kan trække på disses tidligere navigationserfaringer med andre softwaresystemer. FluidApp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Figur 9.2: Figuren viser FluidApps navigationspanel i form af faneblade, hvor Oversigts - fanen er valgt. Da FluidApp skal anvendes på sygehusafdelinger, sandsynligvis intensivafdelinger, skal systemet være gennemskueligt, effektivt og brugervenligt. Dette, da det sundhedsfaglige personale skal have mest mulig tid til patientbehandling frem for afkodning af et systems opbygning og funktionalitet. For at opnå dette, tilstræbes det at anvende de samme grundlæggende designstrukturer som f.eks. kongruente skrifttyper, baggrundsfarver, knapper osv. i systemets brugergrænseflader. Således kan brugeren fokusere på de vigtige informationer i hver brugergrænseflade frem for at skulle forholde sig til forskelligt design mellem hver brugerflade. På denne måde bliver FluidApp mere overskueligt, og funktionaliteter indlæres hurtigere pga. en genkendelsesproces Mock-ups af FluidApps brugergrænseflader Ved opstart af FluidApp vil en bruger møde en startside med indikation om indtastning af en patients identifikationsnummer, jf. figur 9.3. Det er ikke muligt at tilgå systemets andre faner før en patient er blevet identificeret første gang ved systemopstart. Når brugeren har trykket på Find patient -knappen vil systemet søge efter den ønskede patient i 77

90 systemets database i henhold til UC: Identificer patient præsenteret i afsnit 7.4. Findes patienten ikke i databasen, vil systemet give feedback til brugeren omkring denne fejl. Feedback til systemets brugere udskrives i meddelelsesbokse, hvilket ses i figur 9.4. Disse meddelelsesbokse skal anvendes gennemgående af systemet når en fejl forekommer ved en bestemt handling, som et led i systemets fejlhåndtering. FluidApp Filer Hjælp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Velkommen til Fluid-App systemet Indtast identifikationsnummer: Find patient Opret patient Rediger patientoplysninger Figur 9.3: Figuren viser et mock-up af startsiden for FluidApp. Findes en patient ikke i databasen, har en bruger mulighed for at oprette en patient ved at udfylde nogle patientinformations-felter, se figur 9.5. En markering af de nødvendigt udfyldte felter implementeres i designet for at minimere antallet af brugerfejl, og dermed sikre, at systemet fremadrettet kan identificere den pågældende patient. Som det ses i figur 9.5 skal en nyoprettet patient som minimum have tilknyttet et identifikationsnummer. Andre patientinformationer kan registreres på et senere tidspunkt ved valg af Rediger patientoplysninger -knappen under fanen Vælg ny patient. Ved dette valg ledes brugeren til samme vindue som i figur 9.5, hvor systemet blot indskriver tidligere registrerede patientinformationer automatisk i informationsfelterne. Dette for at lette arbejdet for brugeren. 78

91 FluidApp Filer Hjælp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Velkommen til Fluid-App systemet Patienten kan ikke findes i databasen! Indtast identifikationsnummer: Find patient Opret patient Prøv igen Rediger patientoplysninger Opret ny Figur 9.4: Figuren illustrerer de såkaldte fejlmeddelelsesbokse, der anvendes gennemgående i systemets brugergrænseflader som visuel fejlhåndtering. I dette tilfælde indsættes en fejlmeddelelsesboks for at håndtere fejlen omkring, at patienten ikke er fundet i databasen for UC: Identificer patient. FluidApp Patientinformationer Fornavn: Efternavn: Fødselsdato: Køn: *Identifikationsnummer: 4/22/1955 Mand Kvinde (* Markerede felter skal udfyldes.) Gem Annuller Figur 9.5: Figuren illustrerer brugergrænsefladen indeholdende patientrelaterede informationer. Brugergrænsefladen i figur 9.5 implementerer to knapper, henholdsvis en Gem - og Annuller - knap, der skal illustrere en brugers valgmuligheder for at progrediere i systemet. Ifølge usability-principperne i afsnit 9.1 skal softwaresystemer med god usability angive tydelige udgange for brugeren, hvis denne har foretaget et forkert valg. Derfor implementeres Annuller -knappen således, at en bruger kan komme tilbage til sin oprindelige tilstand, 79

92 f.eks. komme tilbage til startsiden hvis patientinformationer ikke ønskes registreret. Ved valg af Gem -knapperne i de forskellige brugergrænseflader vil systemets brugere modtage en besked om, at det ønskede materiale er gemt. Dette vha. en fluebens-indikation som angivet i figur Systemet opbygges således til at give brugeren informativt feedback, som stemmer overens med usability-principperne i afsnit 9.1. Anvendelsen af Gem - og Annuller -knapper og grupperingen af disse går igen i flere af de følgende mock-ups for FluidApps brugergrænseflader. Herved sikres konsistens i designstrukturen, da knapperne repræsenterer samme funktionalitet i hver enkelt brugergrænseflade, som implementerer disse knapper. Funktionaliteterne er som nævnt kategoriseret i en række faneblade, som visualiseres øverst i de brugergrænseflader, der påkaldes ved navigering mellem fanerne. Brugergrænsefladerne for hver fane på nær Vælg ny patient illustreres i følgende mock-ups 9.6, 9.7, 9.9, 9.10 og FluidApp Filer Hjælp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Grafens tidshorisont: 8 timer Ændr Tabellens tidshorisont: 8 timer Ændr Én parameter Flere parametre Gem som default Vælg parameter Gem som default Tidspunkt for opgørelse af væskebalance: Kl. 6:00 4/22/2012 Kl. 12:00 4/22/2012 Ændr tidsperiode Akkumuleret Hensigtserklæring (24 t) Indgift: Per OS 400 ml 450 ml NaCl-IV 300 ml 350 ml Medicin+ vand i sonde 200 ml 150 ml Transducer 100 ml 200 ml Dræn skyl 250 ml 250 ml Indgift total: 1250 ml 1400 ml Udgift: Diurese 1000 ml 1200 ml Afføring 150 ml 200 ml Navn: Anders Andersen Fødselsdato: Identifikationsnummer: Dialyse 500 ml 500 ml Aspirat 50 ml 100 ml Udgift total: 1700 ml 2000 ml Total væskebalance: -450 ml -600 ml Figur 9.6: I figuren ses brugergrænsefladen for fanen Oversigt, der indeholder komponenter udledt af UC: Se væskebalance, UC: Se hensigtserklæring, UC: Se grafisk oversigt, UC: Vælg parameter/parametre, UC: Vælg alternativ tidsperiode, UC: Vælg default parameter/parametre og UC: Ændr default tidsperiode. Brugergrænsefladen i figur 9.6 er designet til at give brugeren et hurtigt overblik over patientens nuværende væsketilstand, hvorfor tilstanden præsenteres gennem en default graf samt en dataoversigtstabel. Faktuelle tal findes i dataoversigtstabellen. Da det er muligt at brugerindstille både graf og tabel, indeholder figur 9.6 en række funktionelle knapper til dette formål. Knapperne indkapsles således, at brugeren kan se, hvilke knapper 80

93 der har en sammenhæng med udførelse af en brugerindstilling. Dette stemmer overens med usability principper i afsnit 9.1. Ved opgørelse af patienters væskebalance over flere døgn kan en del data for hver enkelt patient ophobes. Brugere af FluidApp har mulighed for at se observeret parameterdata samt data for tidligere registrerede hensigtserklæringer ved valg af fanen Datahistorik. Her præsenteres alt patientrelateret data i tabeller, jf. figur 9.7. Data i tabellerne præsenteres kronologisk således, at nyeste måling ligger øverst i tabellen. Hermed kan brugeren nemt finde frem til det rette data sålænge, at personen kender dataenes registreringsdato. Filer Hjælp FluidApp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Historik for observeret data Observationstid Systemtidsstempling Parameternavn Type Værdi Enhed BrugerID Kommentar / / Dialyse Udgift 400 ml/t Mørk væske / / Afføring Udgift 250 ml / / Aspirat Udgift 50 ml / / Medicin+vand i sonde Indgift 200 ml / / Vægt Andet 75 kg / / Diurese Udgift 50 ml Grumset / / Dræn 1 Indgift 50 ml / / Per OS Indgift 100 ml / / Diurese Udgift 200 ml / / Per OS Indgift 150 ml / / Ekstra sved Udgift 160 ml / / Transducer Indgift 100 ml/t / / Diurese Udgift 300 ml "Værdi"-felterne er sensitive, dvs. disse kan redigeres ved at trykke på det ønskede værdifelt, og derefter indtaste en ny værdi i et pop-up vindue. Herefter vil felterne ''Værdi'' og "Systemtidsstempling" opdateres. Historik for hensigtserklæring Systemtidsstempling Parameternavn Type Værdi Enhed BrugerID Kommentar / Dialyse Udgift 400 ml/t / Afføring Udgift 250 ml / Aspirat Udgift 50 ml / Medicin+vand i sonde Indgift 200 ml / Vægt Andet 75 kg / Diurese Udgift 50 ml Figur 9.7: Figuren illustrerer brugergrænsefladen efter valg af fanen Datahistorik. I nogle tilfælde kan det være nødvendigt at redigere i gemt data, hvis en forkert dataværdi er blevet registreret i systemets database. Ved redigering af data vælges en af tabellens rækker ved dobbeltklik, hvorefter et pop-up vindue dukker frem, demonstreret i figur 9.8. Efter en værdi er blevet redigeret, markeres denne værdi med rødt i Datahistorik -fanen for at give et klart overblik over de redigerede dataværdier, og dermed give systemets brugere feedback på en foretaget aktivitet. 81

94 Filer Hjælp FluidApp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Historik for observeret data Observationstid Systemtidsstempling Parameternavn Type Værdi Enhed BrugerID Kommentar / / Dialyse Udgift 400 ml/t Mørk væske / / Afføring Udgift 250 ml / / Aspirat Udgift 50 ml / / Medicin+vand Rediger i sondedata Indgift 200 ml / / Parameternavn: Per OS Vægt Tidligere Andet værdi Redigeringstid 75 kg / / Diurese Udgift 50 ml Grumset / Observationstid: / kl /4-13 Dræn 1 20 ml Indgift kl / ml / / Per OS 50 ml Indgift kl /4-13 ml / / Diurese Udgift 200 ml / Nuværende - 31/ værdi: 100 ml Per OS Indgift 150 ml / Ret værdi: - 31/ Ekstra sved Udgift 160 ml / / Transducer Ret Indgift 100 ml/t / / Diurese Udgift 300 ml Historik for hensigtserklæring Systemtidsstempling Parameternavn Type Værdi Enhed BrugerID Kommentar / Dialyse Udgift 400 ml/t / Afføring Udgift 250 ml / Aspirat Udgift 50 ml / Medicin+vand i sonde Indgift 200 ml / Vægt Andet 75 kg / Diurese Udgift 50 ml Figur 9.8: Figuren illustrerer brugergrænsefladen ved redigering af data. For noget sundhedspersonale kan hårde faktuelle tal, som vist i figur 9.7, give det bedste overblik over patienttilstanden. Patienters væskeskemaer opdateres og vurderes ikke kun af enkeltpersoner, men af flere forskellige personer fra forskellige faggrupper. Derfor ønskes det at give en alternativ måde til vurdering af patienttilstanden gennem grafisk visualisering, grundet litteraturen i afsnit 6.4. Under fanen Grafisk oversigt er det muligt for en bruger at opsætte flere grafer med forskellige parametre, hvilket er illustreret i figur 9.9. Den enkelte bruger har ligeledes mulighed for at brugerindstille de enkelte grafer ved brug af knapperne tilhørende den enkelte graf. Disse knapper er af samme type som ved grafen i fanen Oversigt, hvilket skaber konsistens mellem de enkelte brugerfladers identiske funktionaliteter. 82

95 FluidApp Filer Hjælp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Grafspecifikationer Graf 1 Grafens tidshorisont: 8 timer Ændr Tilføj graf Ved valg af ''Gem som default,'' vil grafens indstillinger gemmes i databasen for den specifikke bruger. Én parameter Flere parametre Vælg parameter Gem som default Graf 2 Grafens tidshorisont: 8 timer Ændr Én parameter Flere parametre Vælg parameter Gem som default Figur 9.9: Figuren viser brugergrænsefladen for Grafisk oversigt. Brugergrænsefladen illustreret i figur 9.10 viser en registreringsoversigt, hvor en bruger kan registrere observerede parameter værdier for en patient. Parametrene under kategorierne Indgift, Udgift og Andet er opstillet i alfabetisk rækkefølge således, at brugeren hurtigere kan finde den ønskede parameter, som denne ønsker at registrere data for. Placeringen af tekstfelter og knapper er ens for indgift, udgift og andre parametre. Denne konsistens gør det lettere for brugeren hurtigt at indtaste dataværdier, tidspunkter og kommentarer, da brugeren har mulighed for hurtigt at lære den ensartede opbygning i figur 9.10 at kende. 83

96 FluidApp Filer Hjælp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Indgift Udgift Dræn 1 Dræn 2 Dræn 3 ml ml ml tid tid tid Kommentar Kommentar Kommentar Afføring Aspirat Dialyse Diurese ml ml ml/t ml tid tid starttid tid Kommentar Kommentar Kommentar Kommentar Forbrændingsvand Infusion Medicin + vand i sonde Per sonde ml ml/t ml ml/t tid starttid tid starttid Kommentar Kommentar Kommentar Kommentar Dræn 1 Dræn 2 Dræn 3 ml ml ml tid tid tid Kommentar Kommentar Kommentar Per OS ml tid Kommentar Ekstra sved ml tid Kommentar Transducer ml/t starttid Kommentar Perspiratio ml tid Kommentar Andre parametre Vægt kg tid Kommentar Tilføj/Fjern parameter Blodtryk sys/dia tid Kommentar Gem Annuller Figur 9.10: Figuren viser brugergrænsefladen for registrering af patientdata i form af væskeindgifter/udgifter eller andre parametre, hvilken stemmer overens med UC: Registrer data. Brugergrænsefladen for registrering af en hensigtserklæring i figur 9.11 ligner til forveksling brugergrænsefladen i figur I denne fane kan brugeren indtaste de ønskede væskeværdier for en række parametre, som skal gives til eller udtrækkes fra en patient i løbet af det kommende akutdøgn. 84

97 Filer Hjælp FluidApp Dataoversigt Datahistorik Grafisk oversigt Registrer patientdata Registrer hensigtserklæring Vælg ny patient Hensigtserklæring for parametre Indgift Udgift Dræn 1 Dræn 2 Dræn 3 ml ml ml Kommentar Kommentar Kommentar Afføring Aspirat Dialyse Diurese ml ml ml ml Kommentar Kommentar Kommentar Kommentar Forbrændingsvand Infusion Medicin + vand i sonde Per sonde ml ml ml ml Kommentar Kommentar Kommentar Kommentar Dræn 1 Dræn 2 Dræn 3 ml ml ml Kommentar Kommentar Kommentar Per OS ml Kommentar Ekstra sved ml Kommentar Transducer ml Kommentar Perspiratio ml Kommentar Tilføj/Fjern parameter Gem Annuller Figur 9.11: Figuren viser brugergrænsefladen for registrering af en hensigtserklæring, hvilken stemmer overens med UC: Registrer data. En bruger har i både figur 9.10 og 9.11 mulighed for at tilføje eller fjerne parametre til/fra den pågældende registreringsoversigt, jf. UC: Tilføj/fjern parametre til/fra registreringsoversigt. Dette vha. Tilføj/Fjern parameter -knappen. Ved valg af denne knap fremvises et pop-up vindue udformet som i figur I dette vindue kan brugeren tilføje eller fravælge parametre, hvilket sker ved afkrydsning af parametre i en parameterliste. Brugeren har således et visuelt billede af, hvilke parametre er valgt til registreringsoversigten, og hvilke er fravalgt. 85

98 Tilføj/Fjern parameter Parameterliste Parameter Opret ny parameter Diurese Dialyse Per OS Aspirat Infusion Albumin Medicin i sonde Dræn 1 Dræn 2 Opdater oversigt Annuller Figur 9.12: Figuren illustrerer et pop-up vindue, hvor systemets brugere har mulighed for at tilføje eller fjerne en parameter eller parametre til/fra en registreringsoversigt, hvorved en fleksibilitet af registreringsoversigten i figur 9.10 og 9.11 opnås. I figur 9.12 kan en bruger desuden vælge at oprette en ny parameter i parameterlisten, jf. UC: Opret ny parameter, ved valg af Opret ny parameter -knappen. Dette fremkalder nedenstående pop-vindue i figur FluidApp Opret ny parameter Parameternavn: Type: Måleenhed: Indgift Udgift Andet ml ml/t Tekstboksen ved "Måleenhed" er ikke tilgængelig, hvis "Indgift" eller "Udgift" er valgt, da en indgift eller udgift skal angives som ml eller ml/t. Tekstboksen er kun tilgængelig ved valg af "Andet", da brugeren her selv skal indtaste en specifik måleenhed. Gem Annuller Figur 9.13: Figuren viser et pop-up vindue, hvor en bruger kan oprette en ny parameter, jf. UC: Opret ny parameter. 86

99 Generelt ønskes konsistens mellem brugergrænsefladerne i FluidApp, hvilket er prøvet opnået gennem ensretning af brugerfladernes udseende og navngivning af elementer med samme handlingsudfald. Så vidt som muligt navngives elementer ud fra systembrugernes daglige termer for at overskueliggøre systemets funktionaliteter Screenflow I figur C ses et screenflow for FluidApp, hvor programmet startes ved velkomstbrugergrænsefladen. Ved enkelte knapper såsom Gem kan der være flere udfaldsscenarier F.eks. kan en fejl opstå ved opret forbindelse til databasen, eller systemet kan gennemføre Gem -handlingen, og derefter fortsætte i systemfunktionerne. 9.3 Databasedesign Databasesystemer anvendes i høj grad til håndtering af store mængder af informationer, men skal ligeledes sikre lagrede data ved systemnedbrud eller mod f.eks. forsøg på uautoriseret adgang [Silberschartz et al., 2006]. I forestående projekt implementeres en relationel database til at lagre patientspecifikke, brugerspecifikke og parameterspecifikke oplysninger således, at observeret parameterdata kontinuerligt kan udtrækkes og anvendes til visualisering af en patients væskebalance, og FluidApps brugerflade kan tilpasses den enkelte bruger. Gennem FluidApp er det muligt for en bruger at tilgå lagrede data, og systemet står derfor for manipulationen af disse data i databasen. I forestående projekt er et ER-diagram til beskrivelse af FluidApps overordnede databasedesign udviklet, med henblik på at vise relationerne mellem entiteter fundet ved vurdering af systemets funktionelle krav. Det opstillede ER-diagram skal således opfylde datakravene sat for systemet. FluidApps ER-diagram ses i figur 9.14, hvor firkantede kasser repræsenterer de fundne entiteter, hvorudfra entiteternes attributter udbredes. Entiteterne er forbundet til hinanden gennem relationssættene demonstreret ved rhombeformede kasser. For at skelne hver enkelt entitet i et entitetssæt fra hinanden, må entitetssættene have tilknyttet en nøgle, defineret som en eller flere attributter, der tilsammen er en unik kombination for den enkelte entitet. En entitets primærnøgle vises i ER-diagrammet ved, at attributter er understreget. Desuden illustreres kardinaliteter mellem entiteterne ved forholdende 1:1 (en-til-en), 1:n (en-til-mange), n:1 (mange-til-en) eller n:n (mange-til-mange). Kardinaliteterne fortæller, hvor mange entiteter i de fremstillede entitetssæt, som associeres med hinanden [Silberschartz et al., 2006]. F.eks. fortæller n:1-kardinaliteten mellem entiteterne Default-tabel og Personale, at en default-tabel tilhører mange fra sundhedspersonalet, men at en fra personalet kun har én default-tabel tilhørende sig. 87

100 Figur 9.14: Figuren illustrerer ER-diagrammet for FluidApps database, som viser systemets entiteter og relationerne mellem disse. Primærnøgler for entiteterne er markeret ved understregning. Ud fra et ER-designet er det muligt at generere et sæt af relationsskemaer, der skal udtrykke det relationelle databasedesign. Det optimale relationelle databasedesign vil indeholde relationsskemaer, der undgår redundans og organiserer data effektivt således, at nemt dataudtræk fra databasen er sikret. For at opnå denne designstruktur, skal relationsskemaer normaliseres til den rette normal form [Silberschartz et al., 2006]. I forestående projekt er et relationsskema udarbejdet, men pga. den begrænsede tidsperiode er skemaet ikke blevet normaliseret. Relationsskemaet for FluidApps database illustreres i figur Selve implementeringen af relationsskemaet optræder senere i afsnit

101 Figur 9.15: Relationsskemaet (databaseskema) for Fluid-App systemets database viser hvilke relationer, der findes i mellem entiteterne. Der illustreres, hvilke attributter, som er primærnøgler og fremmednøgler. Primærnøglerne i de enkelte tabeller vises med (PK) og fra fremmednøgler udfarer en pil mod primærnøglerne hos den entitet, hvor disse stammer fra. 9.4 Anvendelse af objektorienterede programmeringsprincipper Et af de primære mål med den objektorienterede analyse (OOA) og design (OOD) er udviklingen af genbrugelige softwaresystemer se appendiks B. Vedligeholdelse af et software system er ofte mere besværligt end selve udviklingen af systemet. Softwaredesignet skal derfor kunne håndtere fremtidige problemer og krav således, at redesign af et system minimeres. For at opnå dette, kan forskellige designmønstre benyttes sammen med en række fundamentale objektorienterede programmeringsprincipper, hvilke vil blive præsenteret i de følgende afsnit [Gamma et al., 1995]. 89