Udvikling af applikation til væskeregistrering. Gruppe 670 Bachelorprojekt Sundhedsteknologi 6. Semester hos urologiske patienter

Transkript

1 Udvikling af applikation til væskeregistrering Gruppe 670 Bachelorprojekt Sundhedsteknologi 6. Semester 2014 hos urologiske patienter

2

3 AALBORG UNIVERSITET Det Sundhedsvidenskabelige Fakultet SYNOPSIS TITEL: Udvikling af applikation til væskeregistrering hos urologiske patienter PROJEKTPERIODE: Fra 3. februar 2014 til 27. maj 2014 PROJEKTGRUPPE: Claus Hougaard Pedersen Josephine E. Schmidt Swing Malene Møller Larsen Mie Vestergaard Andersen Simona Læsø Christensen VEJLEDERE: Ulrike Pielmeier Mark Lillelund Rousing ANTAL SIDER: 144 På Urologisk Afdeling, Aalborg Universitetshospital monitoreres væskebalance hos de patienter, der efter operation indlægges på Urologisk Sengeafsnit. Dette gøres, da patienterne ofte er overhydrerede i den postoperative fase, og det ønskes at sikre, at disse kommer inden for normalområdet igen. Derudover har personalet mulighed for at opdage komplikationer, opstået i forbindelse med operationen. Opgørelse af væskebalance registreres på nuværende tidspunkt i et papirbaseret system, hvilket er forbundet med flere fejlkilder, f.eks. håndskrift, fejlberegninger og dobbeltarbejde ved overføring til EPJ fra papirbaseret væskeskema. For at optimere disse problemstillinger ses der muligheder i udvikling af et elektronisk væskeskema som alternativ. Dette system kan mindske fejlkilder og effektivisere arbejdsgangen på Urologisk Afdeling. Et sådan system udvikles ved objektorienteret analyse, design, implementering og UML. Det udviklede system, HyMa, testes efterfølgende. Testen viste, at HyMa kan oprette nye patienter, tilknytte væskeparameterdata (VPD) til en patient ved registrering af VPD i form af indog udgifter samt vægt, gøre data traceable og automatisk beregne den akkumulerede væskebalance. HyMa kan ligeledes visualisere VPD i form af grafer over den akkumulerede væskebalance og vægt, samt oversigtstabel. De foretagne tests viste dermed, at de implementerede dele af HyMa løste de opstillede problemstillinger, men videre optimering og udvikling er ønskværdig.

4

5 Abstract At the Department of Urology at Aalborg University Hospital, fluid balance is monitored for patients that are admitted to the Urology ward after surgery due to a common rate of these patients being over hydrated in the postoperative phase. Consequently, it is desirable to monitor and thereby ensure that fluid levels are brought back within the normal range. Moreover, the process of monitoring fluid levels enables staff to detect complications arising from the surgery. Currently, fluid balance is registered through a paper-based system that accounts for a severe margin of error, for instance in terms of handwriting, miscalculations, and extended work processes in transferring data to the Electronic Patient Journal from the paper-based fluid monitoring reports. In an attempt to optimize the process of monitoring fluid balance, the development of an electronic fluid monitoring system is proposed as a possible alternative, as the electronic system could reduce the margin of error while simultaneously streamlining workflow at the Department of Urology. A system of this type is established and developed by an object-oriented analysis, design, implementation and UML. Subsequently, the developed system HyMa is tested. The test showed that HyMa can create profiles for new patients, ascribe fluid parameters to a specific patient by reporting and registration in the form of input, output, or weight, thereby making data traceable and automatically calculate the cumulative fluid balance. HyMa can also visualize the fluid parameters in the form of graphs of the cumulative fluid balance and weight, along with providing summary tables. The completed tests thereby confirmed that the implemented parts of HyMa solve the initially stated complications, however, further optimization and development is required.

6

7 Forord Dette bachelorprojekt er udarbejdet på 6. semester i perioden fra den 3. februar til den 27. maj 2014 af gruppe 14gr670 fra Civilingeniør-uddannelsen, Sundhedsteknologi, på Aalborg Universitet. Temaet for projektet er Design af sundhedsteknologiske systemer. Projektet udarbejdes med henblik på implementering af væskebalance-applikation til registrering af patienters væskebalance på Urologisk Afdeling, Aalborg Universitetshospital. For læseren kan det være en fordel at have kendskab til begreber indenfor sundhed og sundhedsteknologi, samt programmering. Til implementering af HyMa er udviklingsværktøjet NetBeans IDE 7,4 anvendt. HyMa er programmeret i JavaFX. Læsevejledning I læsevejledningen beskrives, hvordan projektet bør læses med henblik på henvisninger til kilder samt referencer til projektets figurer og tabeller. Kildehenvisninger er opstillet efter Harvard-metoden med forfatterens efternavn og årstal i parentes. Ved flere forfattere tilføjes et al. f.eks [Pedersen, et al., 2011]. Kilden i teksten angives til slut i afsnittet, hvis den er gældende for hele afsnittet, og før punktum, hvis den er gældende for sætningen. Litteraturlisten bagerst i rapporten lister kilderne i alfabetisk orden. I litteraturlisten er kilderne angivet med forfatter, udgivelsesår og titel, derudover er der ved bøger også angivet forlag, og internetkilder er listet med lokaliseringsdato og URL. ISBN, ISSN og DOI er angivet, hvor det er muligt. Figurer og tabeller er nummereret i henhold til kapitel og afsnit, og forklarende tekst er angivet i figur- eller tabeltekster.

8

9 Indhold Indhold i 1 Indledning Initierende problem I Problemanalyse 3 2 Væskemonitorering Væskebalance Patienter på Urologisk Afdeling Væskeskema på Urologisk Afdeling Workflow for arbejdsgang Problemstillinger ved anvendelse af papirbaserede væskeskemaer Problemformulering Motivation for problemformulering Problemformulering II Metode 17 4 Metode Interview Unified Modeling Language V-modellen IIIProblemløsning 25 5 Optimering af væskeskema 27 i

10 ii INDHOLD 5.1 Automatiske beregninger Opdatering af væskebalance Færre indtastninger Visualisering Systemkrav Funktionelle krav Non-funktionelle krav Systembeskrivelse Brugervenlighed Antagelser Analyse Use case-diagram Aktivitetsdiagrammer Analyseklasser og analysediagram Analyseklasser Design Objektorienterede principper Trelagsarkitektur Applikationslayout Designklasser og designklassediagram Klasser i presentationlayer Designklasser i businesslayer Designklasser i datalayer Databasedesign Sekvensdiagrammer Implementering Afvigelser fra analyse og design Eksempler på kode implementeret i HyMa Saveable Implementering af database SQL-database kommunikation Sceneimplementering Test Funktionalitetstests Acceptance Test af HyMa IV Syntese Diskussion 117

11 INDHOLD iii 11.1 Løsninger på problemstillinger ved implementering af HyMa Automatiske beregninger Opdatering af væskebalance Færre indtastninger Visualisering Diskussion af test Forbedringer til HyMa Anvendelse af HyMa i et større perspektiv Konklusion 121 Litteratur 123 V Appendiks 127 A Interviewguide 129 A.1 Interviewguide til interview med Urologisk Afdeling A.2 Interviewguide til interview med Skejby Sygehus B Meningskondensering 135 B.1 Meningskondensering af interview med Knud Fabrin B.2 Meningskondensering af interview med Rikke Vormstrup Kristensen B.3 Meningskondensering af interview med Peder Pedersen C Væskeskema 141

12

13 Indledning 1 Hver uge gennemgår, i gennemsnit, ti urologiske patienter operationer på Aalborg Universitetshospital, hvor de efterfølgende indlægges på et stationært sengeafsnit, udtaler sygeplejerske Rikke Kristensen og overlæge Knud Fabrin fra Urologisk Afdeling, Aalborg Universitetshospital i et interview. Disse patienter får monitoreret deres væskebalance ud fra vægt samt ind- og udgifter, der alt sammen registreres i papirbaserede væskeskemaer. [Fabrin, 2014] [Kristensen, 2014] Knud Fabrin og Rikke Kristensen udtaler, at en af begrundelserne for at føre væskeskema er, at patienter, der har gennemgået et større kirurgisk indgreb, ofte er i positiv væskebalance, hvilket kan være uhensigtsmæssigt for kredsløbet og kan forårsage ødemer, hvorfor det på Urologisk Afdeling ønskes at holde patienterne i en neutral væskebalance. Derudover monitoreres væskebalance også for at overvåge patienterne og opdage eventuelle komplikationer i den postoperative fase. Manglende diurese kan være et tegn på komplikationer, og dette kan opdages ved væskemonitorering. [Fabrin, 2014] [Kristensen, 2014] Rikke Kristensen fortæller, at der på nuværende tidspunkt anvendes flere forskellige former for papirbaserede væskeskemaer. Dette kan medføre registreringsfejl, da én type væskeskema anvendes, når en patient bliver opereret, og når patienten derefter vender tilbage til stamafdelingen, tages der stilling til, om der fortsat skal føres væskeskema. Hvis dette er tilfældet, føres væskeparametrene over på et af afdelingens øvrige væskeskemaer. [Kristensen, 2014] I interviewet forklarer og beskriver Knud Fabrin og Rikke Kristensen en række problematikker ved anvendelse af papirbaserede væskeskemaer, blandt andet at de kan være svære at aflæse grundet håndskrift. Derudover forekommer registreringsfejl, hvor både Knud Fabrin og Rikke Kristensen udtrykker, at de kan være i tvivl om, hvorvidt det, der er noteret, stemmer overens med realiteterne. I nogle tilfælde sker der også regnefejl i forbindelse med udregningen af den samlede ind- og udgift. [Kristensen, 2014] [Fabrin, 2014] For at mindske komplikationer ved anvendelse af papirbaserede væskeskemaer og følge 1

14 2 KAPITEL 1. INDLEDNING den teknologiske udvikling, er der på Skejby Sygehus intensive afdelinger, operationsog opvågningsstuer implementeret et elektronisk PDM system (Patient Data Management system [Sundhedsinformatik, 2011]) til blandt andet dataopsamling. Systemet anvendes som erstatning for de papirbaserede væskeskemaer, herunder til væskemonitorering, men også med ekstra funktioner tilføjet, eksempelvis monitorering af medicinering. [Bøttger, 2007] I et interview med anæstesisygeplejerske, Peder Pedersen, fra Skejby Sygehus Gynækologisk Obstetriske Afdeling udtales, at et af Skejby Sygehus mål er at være et papirløst sygehus, hvorfor PDM-systemet er implementeret. En af fordelene ved PDM-systemet er, at det kan tilkobles medicinpumper og dråbetællere, således det automatisk opdateres, hvor meget og hvilke typer medicin og væske patienten får. Brugeren kan endvidere indføre væskeparameterdata (VPD) manuelt i systemet. [Pedersen, 2014] For at indføre it-løsninger i sundhedssektoren, såsom væskeregistreringen på Skejby Sygehus, arbejder Aalborg Universitetshospital ud fra handleplaner, der har til formål at sætte mål for it-strategien i regionen. Ifølge Handleplanen for Aalborg Universitetshospital 2013 ønsker Aalborg Universitetshospital..at prioritere indsatser, der forbedrer kvaliteten, styrker effektiviteten og reducerer omkostningerne [RegionNordjylland, 2013]. It-strategi for Region Nordjylland 2014 indbefatter blandt andet punktet effektivisering af arbejdsgange, hvor Teknologien skal hjælpe os til at udnytte ressourcerne mere effektivt [KoncernIT, 2014]. Derudover er det i Region Nordjylland målet at afprøve og implementere nye it-løsninger for at sikre høj datasikkerhed og på den måde minimere muligheden for fejl. [KoncernIT, 2014] [RegionNordjylland, 2013] Et led i at opfylde disse mål kan være at undersøge mulighederne for udvikling af et elektronisk væskeskema til brug på Urologisk Afdeling, hvorfor følgende initierende problem opstilles: 1.1 Initierende problem Hvordan håndteres væskeregistrering for patienter tilknyttet Urologisk Afdeling, Aalborg Universitetshospital, og hvilke problemer er der ved de eksisterende løsninger?

15 Del I Problemanalyse

16

17 Væskemonitorering 2 I dette projekt fokuseres der på indlagte urologiske patienter, da Urologisk Afdeling har særlig fokus på væskebalancen. Dette skyldes, at urinvejene er implicerede, og det efter operation er essentielt at observere patientens væskebalance og i særdeleshed diurese. Dette gøres dels for at sikre, at patienterne ikke er overhydrerede eller dehydrerede, men i særdeleshed for at observere for komplikationer i den postoperative periode. [Kristensen, 2014] I følgende kapitel beskrives væskebalance og betydningen af, at kroppen er i neutral væskebalance. I forbindelse med registrering af væskebalance er det, overordnet set, indgifter og udgifter, der observeres, hvorfor en forståelse for dette er essentiel for udviklingen af et system til væskemonitorering. For at udvikle et forbedret system til væskeregistrering på Urologisk Afdeling beskrives arbejdsgangene i forbindelse med brugen af væskeskema. Dette gøres ved hjælp af workflow-diagrammer, der er med til at skabe overblik. Derudover beskrives væskeskemaets opbygning og anvendelse. Denne beskrivelse skal sammen med workflow danne grundlag for udviklingen af en ny applikation til væskemonitorering. Endvidere beskrives problemstillingerne ved anvendelse af det nuværende system for at undgå disse i et nyt. 2.1 Væskebalance Opretholdelse af en passende væskebalance er vital for helbredet. Væskeunderskud af væsentlig størrelse kan føre til dehydrering, hvilket kan påvirke hjerte- og nyrefunktion, mens væskeoverskud kan føre til ødemer. En utilstrækkelig urinproduktion kan føre til væskeoverskud og nyresvigt. Ved at være opmærksom på patienters væskebalance kan ovenstående undgås. [Scales and Pilsworth, 2008] Nedenstående afsnit har til formål at afdække de fysiologiske aspekter, der er relevante i forhold til at kunne forstå vigtigheden af at monitorere væskebalance. Hos voksne består % af kropsvægten af vand [Schroeder et al., 2007] [Jéquier and Constant, 2010]. Væskeindholdet er i gennemsnit højere ved mænd end kvinder, 5

18 6 KAPITEL 2. VÆSKEMONITORERING men faldende med alderen for både mænd og kvinder [Leech and Nesbitt, 2013]. Væskeindholdet i kroppen kan opdeles i to; den ekstracellulære væske, som opdeles i interstitielvæske og blodplasma, og den intracellulære væske [Leech and Nesbitt, 2013]. Den ekstracellulære væske udgør cirka 35 % af kroppens væskeindhold, mens den intracellulære udgør 65 %. Mellem 5-10 % af væsken udskiftes dagligt. Væsketabet sker gennem urin og afføring, perspiratio og respiration, imens metabolismen producerer væske. [Sawka et al., 2005] Tabel 2.1 viser, hvor mange ml væske der mistes og produceres dagligt. Kilde ml/døgn Respiration -250 til -350 Urin -500 til Afføring -100 til -200 Perspiratio -400 til Metabolisme +250 til +350 Total til Tabel 2.1: Daglig væsketab og -produktion. Redigeret fra [Sawka et al., 2005]. Under kroppens metabolisme omdannes fødevarer til næringsstoffer grundet fordøjelsesenzymer. Et biprodukt af denne proces er vand. [Martini et al., 2012] Dette vand svarer ikke til den mængde, som kroppen udskiller, hvorfor væsketilførsel er nødvendig for at opretholde neutral væskebalance. [Sawka et al., 2005] Hvis væskeindtaget er mindre end væsketabet, vil der ikke være neutral væskebalance, og kroppen dehydreres, hvilket har en negativ indvirkning på kroppen. Dehydrering medvirker et nedsat volumen af plasma i blodet, hvilket kan resultere i mindsket slagvolumen og dermed højere puls for at bibeholde samme minutvolumen. [Kavouras, 2002] For at opretholde blodvolumen og dermed blodtrykket kan interstitialvæsken, ved osmose, diffundere ind i blodet, hvorved blodvolumen stiger. [Scales and Pilsworth, 2008] Denne mekanisme kan kompensere for væskeunderskuddet i en periode, men når interstitialvæsken ikke længere er til rådighed, vil flere symptomer opstå, heriblandt lavt blodtryk, takykardi, patientens ekstremiteter føles kolde, og diuresen vil være mindre end 0,5 ml/kg/time, hvor dennes normalområde typisk er 1,5-2 ml/kg/time [Scales and Pilsworth, 2008] [Schroeder et al., 2007]. Ved disse symptomer vil kroppen allerede være i et væskeunderskud på flere liter. [Scales and Pilsworth, 2008] Overhydrering ses sjældnere, men ofte efter store kirurgiske indgreb. [Fabrin, 2014] Det er nødvendigt, at patienternes væskebalance monitoreres og holdes så neutral som muligt, da overhydrering kan føre til, at patienten i værste tilfælde får ødemer. Ødemer kan opstå, når volumen af interstitialvæske er langt større end normalt [Scales and Pilsworth, 2008]. Dette skyldes, at det osmotiske tryk i blodbanerne falder, hvilket medfører, at filtrationen af blodet gennem kapillærvæggene øges, og at den frafiltrerede

19 2.2. PATIENTER PÅ UROLOGISK AFDELING 7 væske ophobes i omkringliggende væv [Bjålie et al., 2004]. Ødemer øger risikoen for komplikationer men kan behandles med vanddrivende medicin [Schulze and Schroeder, 2011]. 2.2 Patienter på Urologisk Afdeling Urologisk Afdeling står for udredning, undersøgelse, behandling og kontrol af sygdomme og funktionsforstyrrelser i urinvejene, samt de mandelige genitalia, primært prostata [UrologiskAfdeling, 2014]. Urologisk Afdeling er opdelt i et dagafsnit og sengeafsnit. På Urologisk Dagafsnit udskrives de fleste patienter kort efter operation, hvorfor disse ikke er relevante for projektet, da der normalvis ikke væskemonitoreres på dagkirurgiske patienter. På Urologisk Sengeafsnit ligger de patienter, der får foretaget større kirurgiske indgreb såsom prostatektomi, nefrektomi eller urinafledende operation. Disse får efter operation monitoreret væskebalance, hvis dette ordineres af lægen. [Kristensen, 2014] Inden et større kirurgisk indgreb indtager patienterne 2 liter sukkervand fordelt på aftenen før operation og morgenen på selve dagen for at sikre mod insulinresistens på grund af kirurgisk stress [Kristensen, 2014] [Fabrin, 2014]. I forbindelse med kirurgiske indgreb i urinvejene er det vigtigt at observere patientens væskeind- og udgifter efter operationen, da det kan føre til komplikationer i form af væskeophobning omkring tarmene, grundet væskeoverskud i kroppen, hvis patienten ikke har diurese [Kristensen, 2014]. At patienten ikke kan tømme urinblæren efter et kirurgisk indgreb er en komplikation, som også betegnes som postoperativ urinretention. Hvis patienten har postoperativ urinretention, skal denne observeres rutinemæssigt, hvis patientens urinblære bliver overspændt, kan dette medføre intens visceral smerte. [Nordling et al., 2011] 2.3 Væskeskema på Urologisk Afdeling Væskebalancen kan estimeres ud fra væskeskemaer, hvor patientens ind- og udgifter registreres. [Shepherd, 2011] Dette gøres for, at den mest optimale væskebehandling kan tilbydes [Eidemak et al., 2011]. Ved væskebehandling er det vigtigt, at indgift og udgift på sigt balanceres [Schroeder et al., 2007]. Væskebalancen kan estimeres ud fra ligning 2.1 [Eidemak et al., 2011] [Kristensen, 2014] væskebalance = akkumuleret indgift akkumuleret udgift. (2.1) Et andet estimat til væskeregistrering er ændring i kropsvægt, som anses for at være et pålideligt estimat af væskebalancen over en kortere tidsperiode, idet vægtændringer efter operation forbindes med ændringer i mængden af kropsvæske. [Schneider et al.,

20 8 KAPITEL 2. VÆSKEMONITORERING 2012] På Urologisk Afdeling, Aalborg Universitetshospital anvendes væskeskema til estimering af væskebalancen, hvor også vægten registreres. Væskeskema anvendes ikke ved alle indlagte patienter, men ordineres af lægen. Der anvendes tre typer af væskeskemaer: Simpel skema, Udvidet væskebalance og Registreringsskema (til døgn ind- og udgifter). [Kristensen, 2014] Disse væskeskemaer er vist i appendiks C, hvor anvendelsen af disse beskrives i det følgende. Simpel skema er det skema, der oftest anvendes på Urologisk Afdeling. Simpel skema indeholder indgift, opdelt i intravenøs væske (IV Væske) og PER OS. Ved anvendelse af Simpel skema registreres udgift ved at aflæse udskillelsen fra blærekateter, da de fleste patienter, indlagt på Urologisk Afdeling, har dette. Simpel skema er gældende for et døgn, fra kl 24.00, og PER OS registreres ved tildeling, altså hver gang patienten modtager væske, som registreres i form af væsketype og mængde. Når patienten har modtaget væsken, noteres dette med en streg på skemaet, og når væsken er indtaget, noteres et kryds i stedet for en streg. Patientens indgifter opgøres efter et døgn. [Kristensen, 2014] Simpel skema kan anvendes samtidig med Udvidet væskebalance efter nødvendighed. Udvidet væskebalance anvendes primært i forbindelse med patienter, som gennemgår større operationer, for eksempel ved urinafledende operationer, og andre komplicerede tilfælde. [Fabrin, 2014] Udvidet væskebalance indeholder patientens ind- og udgifter, hvor indgifter er inddelt i IV Væske, PER OS og Sondeernæring. Udvidet væskebalance registreres tre gange i døgnet - kl. 6, 14 og 23. [Kristensen, 2014] [Jensen and Fly, 2011] Registreringsskema anvendes til at samle Simpel skema og Udvidet væskebalance for at danne et overblik over patientens væskebalance, i op til en uge. Registreringsskema indeholder patientens indgifter, udgifter og vægt. Registreringsskema opgøres én gang i døgnet. [Kristensen, 2014] I tabel 2.2 er vist de indgifter, som registreres på Urologisk Afdeling, hvor ofte disse registreres og hvordan. PER OS registreres ved tildeling, og inden tildeling afmåles mængden af væske. Ved IV noteres, hvor mange ml der er opsat, og herefter aflæses, hvor mange ml patienten har modtaget, hvilket registreres tre gange i døgnet. Blod registreres på samme måde som IV. Ved sondeernæring noteres tidspunktet for tildeling, hvor mange ml der er opsat, og herefter aflæses, hvor mange ml patienten har modtaget. Vand produceret ved metabolisme noteres ud for feltet Metabolisme, som ses i tabel 2.2, med en fastlagt værdi på 300 ml i døgnet for voksne (>16 år) [Mikkelsen et al., 2012]. I tabel 2.3 vises udgiftparametre, som registreres på Urologisk Afdeling, hvor ofte disse registreres og hvordan. Der anvendes forskellige typer katetre, hvilke er blære-,

21 2.3. VÆSKESKEMA PÅ UROLOGISK AFDELING 9 Indgift Registrering af parameter (tid) Registrering af parameter (hvordan) PER OS Ved tildeling Måling IV Tre gange i døgnet Aflæsning Blod Tre gange i døgnet Aflæsning Sondeernæring Ved tildeling Aflæsning Metabolisme Tre gange i døgnet Fastlagt værdi (300 ml i døgnet) Tabel 2.2: Parametre for indgift som registreres på Urologisk Afdeling, samt hvor ofte og hvordan disse registreres. [Kristensen, 2014] brickerblære-, ureter-, suprapubik- og nefrokateter. I tabellen samles disse under kateter. Ved dræn noteres typen, for eksempel lungedræn. Ved kateter og dræn aflæses, hvor meget der er udskilt, hvilket registreres tre gange i døgnet. [Kristensen, 2014] Afføring registreres kun i væskeskemaet, hvis patienten har diarré, hvilket i de fleste tilfælde vil være et skøn, medmindre patienten bruger bækken. [Kristensen, 2014] [Fabrin, 2014] Perspiratio (sved i tabel 2.3) estimeres og sættes som standard til 1000 ml i døgnet. [Kristensen, 2014] Perspiratio kan ligeledes estimeres ved et væsketab på 10 ml/kg/døgn [Perren et al., 2011] [Eidemak et al., 2011]. Hvis patienten er febril, tillæges en ekstra udgift, afhængig af kropstemperaturen, på grund af øget væsketab. [Kristensen, 2014] Ved feber over 38 C tillægges 25 % per C [Eidemak et al., 2011]. Aspiration registreres ved behov og foregår ved estimering eller aflæsning, afhængig af om patienten anvender pose ved opkastning. Hvis aspiration estimeres, foretages et skøn af sygeplejersken. Tab er udgifter, der ikke indgår i tabel 2.3, for eksempel væske fra sår eller diurese. Hvis patienten ikke har kateter, noteres diurese under tab, men kun i forbindelse med kolbe eller bækken. [Kristensen, 2014] Udgift Registrering af parameter (tid) Registrering af parameter (hvordan) Kateter Tre gange i døgnet Aflæsning Dræn Tre gange i døgnet Aflæsning Afføring Ved behov Estimering Sved Tre gange i døgnet Estimering Aspiration Ved behov Aflæsning/estimering Tab Tre gange i døgnet Aflæsning/estimering Tabel 2.3: Parametre for udgift, som registreres på Urologisk Afdeling, samt hvor ofte og hvordan disse registreres. [Kristensen, 2014] På Urologisk Afdeling er de vigtigste parametre i forbindelse med væskebalance vægt og diurese [Fabrin, 2014]. Efter større kirurgiske indgreb er patienten i væskeoverskud

22 10 KAPITEL 2. VÆSKEMONITORERING og kan veje 2-5 kg over startvægten, hvorfor det er vigtigt at observere, om patienten har diurese, således der igen opnås en neutral væskebalance. [Kristensen, 2014] Vægt er dermed en simpel men værdifuld parameter for, om patienten er i væskeover- eller underskud [Fabrin, 2014] [Eidemak et al., 2011]. Vægt kan betegnes som en mere præcis parameter i forhold til væskeskema, i den forstand at det er en parameter, som kan måles forholdsvis præcist, mens der i forbindelse med væskeskema foretages flere estimater, for eksempel defineres perspiratio til 1000 ml/døgn uanset patientens størrelse. Derudover er vægt og diurese, hvis disse sammenholdes, en vigtig indikator for patientens tilstand, og om der er opstået komplikationer. [Fabrin, 2014] 2.4 Workflow for arbejdsgang I følgende afsnit beskrives arbejdsgangene i forbindelse med registrering af væskebalance på Urologisk Afdeling. Dette gøres ved hjælp af workflow-diagrammer, som kan bruges til at skabe et overblik over rollefordelingen i væskeregistreringen. Workflowet undersøges for at analysere, hvorvidt arbejdsgangene fungerer, eller om der er områder, hvor disse kan optimeres ved hjælp af et elektronisk væskeskema. Dette er relevant, da problemstillingerne ved de eksisterende systemer og arbejdsgange i forbindelse med disse ligger til grund for at afgøre, hvorvidt indførsel af et alternativt system er aktuelt. På figur 2.1 ses et workflow over arbejdsgangen. Ved indlæggelse af en ny patient vil denne blive vejet, hvilket gentages hver dag i indlæggelsesforløbet og noteres i væskeskemaet [Fabrin, 2014] [Jensen and Fly, 2011]. Det ordineres af en læge, hvorvidt der skal føres udvidet væskeskema [Jensen and Fly, 2011]. Hver gang en patient får tildelt væske, enten PER OS, IV eller i sonde, bliver dette noteret i væskeskemaet. Ligeledes noteres hver gang, en udgift finder sted. Tre gange i døgnet beregnes den akkumulerede væskebalance. Nattevagten fører den samlede ind- og udgift ind i EPJ. [Kristensen, 2014] Workflow over arbejdsgangen i forbindelse med anvendelse af væskeskemaer ses på figur 2.2. Når en patient overføres fra Intensiv Afdeling til Urologisk Afdeling, for eksempel efter en operation, vil et væskeskema følge patienten. På Intensiv Afdeling føres et mere uddybende væskeskema end på Urologisk Afdeling. [Kristensen, 2014] Ved mindre operationer, såsom fjernelse af polypper i blæren eller forhudsforsnævringer, er det ikke nødvendigt at starte op på et af afdelingens egne væskeskemaer, i stedet fortsættes registreringen på skemaet fra Intensiv Afdeling. [Kristensen, 2014] [Fabrin, 2014] Ved større operationer vil ind- og udgifter fra Intensiv Afdeling blive overført til et skema fra Urologisk Afdeling. [Kristensen, 2014]

23 2.4. WORKFLOW FOR ARBEJDSGANG 11 Figur 2.1: Workflow over arbejdsgangen på Urologisk Afdeling.

24 12 KAPITEL 2. VÆSKEMONITORERING Figur 2.2: Workflow over hvilke typer væskeskemaer, der bliver anvendt, når en patient overføres fra Intensiv Afdeling til Urologisk Afdeling.

25 2.5. PROBLEMSTILLINGER VED ANVENDELSE AF PAPIRBASEREDE VÆSKESKEMAER Problemstillinger ved anvendelse af papirbaserede væskeskemaer Registrering af ind- og udgifter foregår på tre typer af papirskemaer, der udelukkende bliver anvendt på Urologisk Afdeling. Dette medfører, at patienter, der overføres fra andre afdelinger, kan have andre former for væskeregistreringsskemaer tilknyttet. Disse skal derfor overføres til et af afdelingens egne skematyper. De papirbaserede skemaer på Urologisk Afdeling føres endvidere ind i EPJ en gang i døgnet af nattevagten. Dette betyder, at et væskeskema skrives adskillige gange i løbet af et døgn, hvilket giver både personalet en større arbejdsbyrde og medvirkende til risiko for notationsfejl. [Kristensen, 2014] Ved anvendelse af papirbaserede væskeskemaer skal sygeplejerskerne notere, hvad patienterne drikker og hvilke mængder. Dette noteres, når patienten tildeles væske, og når glasset er tomt, eller patienten ikke ønsker mere. Der noteres ikke altid direkte i papirskemaet, men i stedet på håndskrevne noter, som i visse tilfælde bliver forlagt og derved aldrig registreret. [Kristensen, 2014] [Fabrin, 2014] En anden fejlkilde ved de håndskrevne væskeskemaer er, at de kan være vanskelige at aflæse, grundet håndskrift. Ligeledes skal den akkumulerede væskebalance beregnes tre gange i døgnet, hvorfor der kan forekomme regnefejl. [Kristensen, 2014] [Fabrin, 2014] Rikke Kristensen og Knud Fabrin udtaler, at de ofte undrer sig over, om væskeskemaet stemmer overens med virkeligheden om data er korrekt ført ind i væskeskemaet. [Kristensen, 2014] [Fabrin, 2014] Ovenstående problemstillinger gør det relevant at overveje alternative løsningsmodeller til væskeregistrering.

26

27 Problemformulering 3 I dette afsnit formuleres en motivation, der leder op til problemformuleringen. Motivationen vil være en sammenfatning af essentielle punkter fra problemanalysen samt relevante dele af interviewet med anæstesisygeplejerske Peder Pedersen fra Skejby. 3.1 Motivation for problemformulering Det er gennem problemanalysen belyst, at det papirbaserede væskeskema er problematisk for såvel patienter, som læger og sygeplejersker, hvorfor det er aktuelt at overveje alternative metoder til væskeregistrering. Formålet ved at fokusere på problemerne ved de eksisterende løsninger er at undgå disse ved implementering af et nyt system. Det er nødvendigt at monitorere patienters væskebalance, da denne giver indikationer for patientens postoperative tilstand. Monitoreringen kan give tegn på eventuelle komplikationer opstået i forbindelse med operation. Denne monitorering foregår i et papirbaseret system og er en uhensigtsmæssig løsning for personalet, da dette indebærer en række mulige fejlkilder. Der er derfor plads til en række væsentlige forbedringer i det eksisterende system. Et eksempel på et sygehus, der har implementeret et elektronisk væskeregistreringssystem (PDM-system), er Skejby Sygehus. Ved et interview på Skejby Sygehus udtaler anæstesisygeplejerske, Peder Pedersen, at der ved anvendelse af et elektronisk system er mulighed for at minimere fejlkilderne samt simplificere arbejdsgangene, da systemet kan give mulighed for automatisk udregning af akkumulerede ind- og udgifter samt væskebalance, endvidere samler det også registreringerne et sted. [Pedersen, 2014] I et elektronisk system undgås problemerne med ulæselig håndskrift, og parametrene registreres ensartet hver gang. Den ensartede registrering kan være med til at fjerne tvivlen om, hvorvidt registreringen er foregået korrekt, hvilket er til fordel for både patienter, sygeplejersker og læger. Risikoen for fejl kan dermed minimeres ved indførelse af et elektronisk system. Der kan være tidsbesparende elementer ved implementering af 15

28 16 KAPITEL 3. PROBLEMFORMULERING et nyt væskeregistreringsssystem, dog afhænger dette i høj grad af brugervenligheden og kompleksiteten af det nye system, hvorfor dette område af et nyt system kræver fokus. Efter erfaringer med Skejby Sygehus PDM-system har Peder Pedersen umiddelbart svært ved at finde ulemper ved systemet og muligheder for at forbedre det yderligere. [Pedersen, 2014] Problemstillingerne ved de eksisterende løsninger leder frem til følgende problemformulering. 3.2 Problemformulering Hvorledes kan en applikation til væskeregistrering på Urologisk Afdeling, Aalborg Universitetshospital designes og implementeres med henblik på optimering af det nuværende papirbaserede væskeskema?

29 Del II Metode

30

31 Metode 4 I dette kapitel beskrives de metoder, der er anvendt til udarbejdelse af problemanalysen og problemløsningen. De anvendte metoder er interview, Unified Modeling Language (UML) samt V-modellen. 4.1 Interview I dette projekt anvendes interviews til at give indblik i brug og udarbejdelsen af væskeskemaer. Anvendelsen af interviews muliggør besvarelse af spørgsmål i forhold til væskeskemaers anvendelse og arbejdsgangen forbundet med denne, som ikke er tilgængeligt andetsteds. Der er udført tre kvalitative ekspertinterviews på formerne ustruktureret og semistruktureret, da dette giver mulighed for en fleksibel interviewstruktur, hvor informanternes egne erfaringer kan inddrages og belyses. Det ustrukturerede interview blev afholdt 7. marts 2014 på Intensiv Afdeling, Aalborg Universitetshospital med overlæge Søren Kjærgaard for at indsamle viden om væskeskema, hvorledes disse udføres, samt vigtigheden bag patienters væskebalance. De semi-strukturerede interviews blev afholdt på hhv. Urologisk Afdeling, Aalborg Universitetshospital og Skejby Sygehus, Aarhus Universitetshospital. Interviewet på Urologisk Afdeling blev foretaget 28. marts 2014 med overlæge Knud Fabrin og sygeplejerske Rikke Vormstrup Kristensen for at få et bredere indblik i og forståelse for viden indsamlet fra interviewet på Intensiv Afdeling. På Skejby Sygehus blev anæstesisygeplejerske Peder Pedersen interviewet 14. april 2014 for at få indblik i fordele og ulemper ved et elektronisk væskeregistreringssystem samt registrering og monitorering af patienten. Inden interviews blev informanterne briefet om overordnede emner samt strukturen af interviewet for at indlede en forudgående refleksion og tankerække omkring interviewspørgsmålene. Hertil blev det også nævnt, at interviewet blev optaget for senere at kunne transskribere og sende det til godkendelse. Dette er beskrevet i en interviewgui- 19

32 20 KAPITEL 4. METODE de, se appendiks A. Formålet med de semi-strukturerede interviews er at få indblik i arbejdsgangen med papirbaserede væskeskemaer på Urologisk Afdeling og PDM-systemet, der anvendes på Skejby Sygehus. Desuden anvendes de semi-strukturerede interviews til at definere krav samt mangler til et elektronisk væskeskema. Formålet med det ustrukturerede interview er at blive introduceret for de praktiske aspekter af væskeregistrering på Intensiv Afdeling, samt danne grundlag for et semistruktureret interview på Urologisk Afdeling. Desuden anvendes det ustrukturerede interview til at definere en patientgruppe, hvorpå projektet kan målrettes. Opsætningen af interviewene er inspireret af Kvales syn på kvalitativ forskning, som består af syv faser [Kvale and Brinkmann, 2009]. Disse faser anvendes for at organisere en struktureret proces og sikre, at fokus, vision og engagement bevares gennem hele processen [Kvale and Brinkmann, 2009]. Interviewguides og dernæst spørgsmål er designet ud fra overordnede emner. Interviewene transskriberes for at sikre, at alle kommentarer og udtalelser tages i betragtning, og på denne måde skabe mulighed for at bruge svarene som citater og argumenter i analysen. Interviewene meningskondenseres for at belyse de dele af problemformuleringen, hvor det ikke har været muligt at finde brugbar litteratur. Meningskondensering omfatter den proces, hvori transskriptionen omformuleres, således den kan inddrages til kortere udsagn. Meningskondenseringen sendes til informanterne for indholdsgodkendelse. Meningskondenseringen kan ses i appendiks B Unified Modeling Language Unified Modeling Language (UML) er en familie af grafiske notationer, der anvendes til at beskrive og designe softwaresystemer. UML er oftest relateret til objektorienterede softwaresystemer. Alene kan UML ikke beskrive, hvordan en kode skal skrives, men det kan give et billede af, hvordan den tilsvarende kode kan skrives. På trods af dette er UML en forholdsvis åben standard, som anvendes til at give udviklere/ingeniører et overblik over, hvordan forskellige aspekter i systemet kommunikerer og danner grundlag for, hvordan programmeringskoden skal sammensættes. [Fowler, 2004] [Arlow and Neustadt, 2002] Indenfor UML findes forskellige diagramtyper til visualisering af et systems funktionaliteter og dets objekter. [Arlow and Neustadt, 2002] [Fowler, 2004] I det følgende beskrives de diagramtyper, der anvendes i projektet. Use case(uc)-diagrammer beskriver de ønskede krav til et system, og hvordan en bruger interagerer med dette. Derudover viser et UC-diagram, hvilke scenarier syste-

33 4.3. V-MODELLEN 21 met skal indebære, hvor hvert scenarie benævnes som en UC. En UC defineres som en sekvens af aktiviteter (inkl. fejl og variationer), som brugeren ønsker, at systemet skal udføre. UCs kan også karakteriseres ved, at de altid sættes i gang af en bruger og udformes fra brugerens synsvinkel. [Arlow and Neustadt, 2002] Ud fra en sekvens af handlinger udarbejdes et aktivitetsdiagram, som illustrerer den ønskede rækkefølge af de enkelte UCs aktiviteter. Aktivitetsdiagrammer er oftest tilknyttet for eksempel UCs, klasser eller interfaces. I et aktivitetsdiagram kan der forekomme en eller flere aktiviteter, hvor en aktivitet kan medføre, at systemet skal træffe et valg. [Arlow and Neustadt, 2002] Klassediagrammer benyttes til at beskrive systemets klasser, samt disses attributter, metoder og relation til hinanden. Disse relationer påføres multipliciteter, som fortæller om relationen. [Arlow and Neustadt, 2002] Indenfor klasser findes to typer, analyse- og designklasser. Forskellen på disse er, at der ved designklasser noteres, hvorledes klassens attributter og funktioner skal karakteriseres. [Fowler, 2004] Sekvensdiagrammer er den mest anvendte type indenfor kategorien af interaktionsdiagrammer og anvendes til at beskrive samarbejdet mellem systemets faktiske grupper af objekter og deres strukturelle forhold [Fowler, 2004]. Disse grupper omtales også som instanser af en klasse. Interaktionsdiagrammer realiserer ønskede krav fra det udarbejdede UC-diagram. Et sekvensdiagram indfanger opførslen af et enkelt scenarie, som illustreres i et UC-diagram, og viser dermed interaktionen mellem objekter i en tidssekvens. Et sekvensdiagram lægger i særdeleshed vægt på rækkefølgen, hvorved meddelelser til objekter sendes. [Arlow and Neustadt, 2002] 4.3 V-modellen V-modellen (verifikations- og validationsmodellen) er en struktureret metode til udvikling af softwareprojekter. V-modellen betegnes som en udvidelse af Waterfall-modellen, hvor V-modellen, i modsætning til Waterfall-modellen, bevæger sig op ad igen efter kode-fasen, se figur 4.1. Dette skaber en anden sammenhæng imellem de enkelte faser i udviklingsfasen og de tilsvarende faser i testningen af softwaren. [Mathur and Malik, 2010] Ved projekter, der tager udgangspunkt i V-modellen, startes i øverste venstre hjørne af V-formen, hvorefter der trinvis gås frem. Det er tilladt at gå baglæns i modellen, hvis der opstår problemer i testfasen, hvilket beskrives ved de bagudvendte pile fra højre del af modellen. Hvis der opdages problemer i Integration Testing, vendes tilbage til designprocessen, hvor et nyt design udarbejdes eller det gamle modificeres, herefter genoptages testfasen. Det venstre ben i modellen er verifikationsfasen, hvor kravene til software fastlægges, og designprocessen foregår. Det højre ben er valideringsfasen, hvor softwaren testes.

34 22 KAPITEL 4. METODE Figur 4.1: De ni trin i V-modellen, redigeret fra [Mathur and Malik, 2010]. Nederst i modellen kobles de to ben sammen af kodningsfasen. De enkelte trin beskrives i det følgende. Requirement Analysis: I dette trin af V-modellen forstås kundens præcise krav (funktionelle og non-funktionelle krav) til softwaren, hvilket kræver kommunikation mellem kunde og udvikler. Da projektgruppen agerer både kunde og udvikler, tages der udgangspunkt i rollen som kunde, hvorfor de funktionelle og non-funktionelle krav for softwaren defineres på baggrund af interviews. System Design: I dette trin laves et overordnet design af det komplette program ud fra kundens krav fra det forrige trin. Formålet med dette er at klarlægge brugerens interaktioner med systemet, hvorfor der udarbejdes et UC-diagram. UC-diagrammet er med til at definere programmets funktioner til det videre designforløb og derved danne rammen for programmets struktur. Architectural Design: Ud fra det overordnede design laves der, i dette trin, et highlevel design, hvor der sættes fokus på softwarearkitekturen og dennes udformning. Formålet med at lave high-level design er at skabe overblik over projektets størrelse samt

35 4.3. V-MODELLEN 23 identificere de mere komplicerede dele af programmet. For at skabe overblik udarbejdes aktivitetsdiagrammer, hvis formål er at dele programmet op i et tilstrækkelig antal mindre dele, der skaber en tilfredsstillende forståelse for underelementerne i applikationen. Aktivitetsdiagrammerne bygger på det udarbejdede UC-diagram og giver en mere detaljeret delelementbeskrivelse af de enkelte hændelser fra UC. Module Design: Her designes softwaren som low-level design. Formålet med low-level design er at skabe en mere detaljeret delelement beskrivelse og derved beskrive funktionerne af disse. Dette gøres ved hjælp af klassediagrammer, hvis formål er at definere attributter og metoder for de enkelte klasser. Coding: I denne fase konverteres design til kode med udgangspunkt i low-level design. Deleelementerne, der blev defineret i de tidligere trin af V-modellen, kodes, og den grafiske brugergrænseflade udvikles. I udvikling af brugergrænsefladen tages højde for brugervenlige løsninger, og der tages i projektet højde for, at softwaren udvikles til tablet. Formålet, i denne fase, er at få de definerede delelementer kodet og slutteligt samlet for at få et helhedsindtryk af softwarens funktionalitet. Unit Testing: I dette trin testes delelementer fra low-level design af softwaren enkeltvis. Dette gøres, i takt med at de enkelte delelementer udvikles, og løbende for at verificere, at de enkelte dele fungerer efter hensigten. Formålet ved løbende at teste delelementerne er at få et lettere forløb, når de enkelte kodeelementer senere sammensættes. Integration Testing: Her testes de dele af systemet, der er sammensat af to eller flere elementer. I Integration Testing anvendes samme fremgangsmåde som ved Unit Testing. Det testes derfor løbende, at de sammensatte delelementer fungerer. Formålet er, at lette forløbet når delelementerne sammensættes til den samlede kode. System Testing: Her testes, hvorvidt softwaren virker, når alle dele sammensættes. De enkelte funktioner i programmet testes for at verificere, hvorvidt de lever op til de opstillede UC s. Testen opdeles i en kort funktionsbeskrivelse, fremgangsmåde for testen, resultat heraf samt det forventede resultat. Formålet er at verificere funktionaliteten af systemet. Acceptance Testing: I dette trin testes, at softwaren lever op til kundens krav. Der tages udgangspunkt i de opstillede systemkrav, og det vurderes, hvorvidt slutproduktet lever op til disse. Formålet med dette er at vurdere, hvorvidt systemet er færdigudviklet og klar til kunden. Unit Testing og Integration Testing udføres løbende i projektperioden, men dokumenteres ikke i rapporten. System Testing og Acceptance Testing udføres og beskrives i kapitel 10.

36

37 Del III Problemløsning

38

39 Optimering af væskeskema 5 For at designe et velfungerende elektronisk væskeskema, der som minimum er bedre end det papirbaserede, er det essentielt at tage hensyn til de brugere, som skal anvende væskeskemaet. Hertil beskrives tiltag, som kan forbedre det papirbaserede væskeskema i henhold til Handleplanen for Aalborg Universitetshospital 2013 og It-strategi for Region Nordjylland 2014 vedrørende effektivisering af arbejdsgange, mere effektiv udnyttelse af ressourcer samt kvalitetsforbedringer [RegionNordjylland, 2013] [KoncernIT, 2014]. I dette kapitel præsenteres de områder, hvor brugerne af væskeskemaet ser et behov for optimering, og de områder, der kan forbedres i forbindelse med førnævnte Handleplan og It-strategi. 5.1 Automatiske beregninger Ved de papirbaserede væskeskemaer beregnes den akkumulerede væskebalance af systemet, EPJ, men dette gøres først, når væskeskemaerne indføres heri. Hvis personalet har behov for den akkumulerede væskebalance inden, må de selv beregne den, med risiko for regnefejl. [Kristensen, 2014] Det vil derfor være en fordel, hvis den akkumulerede væskebalance beregnes automatisk, når der tilføjes ind- og udgifter for patienten. Automatiske beregninger vil kunne effektivisere arbejdsgangen, da personalet ikke skal bruge tid på at beregne væskebalance. Fejlberegninger kan også udgås, hvis der implementeres et gennemtestet system. Ved det nuværende væskeskema sættes perspiratio-standarden til 1000 ml/døgn, hvorved der ikke tages hensyn til patientens vægt. Overlæge Knud Fabrin fortæller i denne sammenhæng, at perspiratio er et skøn og varierer fra patient til patient [Fabrin, 2014] [Sawka et al., 2005]. For at forbedre kvaliteten og præcisionen af denne parameter ønskes derfor i stedet at anvende formlen 10 ml/kg/døgn til beregning af perspiratio for den enkelte patient [Eidemak et al., 2011] [Perren et al., 2011]. 27

40 28 KAPITEL 5. OPTIMERING AF VÆSKESKEMA 5.2 Opdatering af væskebalance Den akkumulerede væskebalance opdateres hver gang, der indtastes ind- og udgifter for patienten og derudover hver time. De kontinuerte væskeparametre opdateres ligeledes løbende for at få en mere præcis registrering end ved opdatering en gang dagligt. Dette gøres for, at personalet har mulighed for at se den aktuelle status på den akkumulerede væskebalance. 5.3 Færre indtastninger Sygeplejerske Rikke Kristensen udtaler, at det er besværligt med dobbeltarbejdet, der er i forbindelse med at føre væskeskema ind i EPJ. Derudover er der problemer med, at de papirbaserede væskeskemaer forsvinder. [Kristensen, 2014] Ved implementering af elektronisk væskeskema forekommer der ikke dobbeltindtastninger i form af data, der indføres fra papirskema til EPJ, hvilket er medvirkende til at mindske personalets arbejde, hvorfor der eventuelt frigøres mere tid til behandling af patienten. Samtidig sikrer det elektroniske væskeskema, at problemet med de papirbaserede væskeskemaers forsvinden ikke længere er aktuelt. 5.4 Visualisering Knud Fabrin og Rikke Kristensen udtaler, at det ikke er svært at få et overblik over patientens tilstand med de nuværende papirskemaer, da der er et Registreringsskema, som samler patientens ind- og udgifter [Kristensen, 2014] [Fabrin, 2014]. Knud Fabrin udtaler endvidere, at det kunne være en idé med en visualisering af vægten, hvor der er et normalområde omkring startvægten og farveskift, hvis vægten kommer uden for dette område. [Fabrin, 2014] PDM-systemet på Skejby Sygehus indeholder ligeledes en form for visualisering, men her i form af ind- og udgifter. De forskellige parametre er repræsenteret med forskellige farvede søjler. [Pedersen, 2014] Inspireret af systemet på Skejby Sygehus og Knud Fabrins udtalelse designes, til det elektroniske væskeskema, en visualisering af patientens vægt. Det ønskes yderligere at repræsentere ind- og udgifter i form af en graf og tabeloversigt, således der hurtigt kan fås et overblik over patientens væskebalance. Dette gøres for, at funktionen med Registreringsskema fra det papirbaseret væskeskema bibeholdes, da Knud Fabrin og Rikke Kristensen udtaler, at dette giver et godt overblik over patientens væskebalance [Kristensen, 2014] [Fabrin, 2014].

41 Systemkrav 6 På Urologisk Afdeling, Aalborg Universitetshospital anvendes på nuværende tidspunkt et papirbaseret system til registrering af væskebalance. Dette system skal videreudvikles til en applikation og på den måde optimere det nuværende papirbaserede væskeskema. Det elektroniske væskeskema skal være lige så brugervenligt eller mere brugervenligt end det nuværende væskeskema for at sikre, at personalet er motiveret for at anvende det nye system. Dette gøres ved et layout, der overskueliggør registrering af væskeparametre; vægt, ind- og udgifter, samt beregning af patientens aktuelle væskebalance. Ved brug af det papirbaserede skema kan der forekomme fejl ved både notering og aflæsning af VPD samt ved beregning af den akkumulerede væskebalance. Et elektronisk system vil kunne minimere nogle af disse fejl, da der undgås håndskrift og manuelle beregninger. Derudover vil et sådant system også kunne være tidsbesparende, da data automatisk kan overføres til patientens EPJ. På den måde undgås det, at personalet skal bruge tid på at indtaste data, som det i øjeblikket er tilfældet. [Kristensen, 2014] Formålet med dette kapitel er at opstille systemkrav på baggrund af problemanalysen og fremsætte en systembeskrivelse. Systemkravene vil bestå af både funktionelle og non-funktionelle krav for et elektronisk væskeskema, der kan erstatte det papirbaserede skema. Dette skal danne baggrunden for analyse, design og implementering af systemet. Systemet vil fra næste kapitel og frem betegnes HyMa. HyMa er en sammentrækning af ordene; Hydration Management. 6.1 Funktionelle krav De funktionelle krav opstilles herunder og er opdelt i hoved- og underpunkter. HyMa skal kunne tilgå flere patienter fra samme enhed. Brugeren skal have mulighed for at tilgå alle patienter, der er oprettet i systemet, fra samme enhed, således brugeren ikke skal være afhængig af flere enheder. 29

42 30 KAPITEL 6. SYSTEMKRAV HyMa skal kræve, at brugeren opretter patienten i systemets database med unik identifikation. Hver patient skal oprettes med CPR-nummer, der er en unik identifikation, navn, startvægt og fødselsår. Køn og alder findes automatisk ud fra CPR-nummer og fødselsår. HyMa skal give brugeren mulighed for at vælge senest anvendte patienter fra en liste. HyMa skal give mulighed for registrering af patientoplysninger og VPD samt redigering af disse. Brugeren skal have mulighed for at angive en række mulige parametre og oplysninger samt redigere i disse, hvis de noteres forkert. Brugeren skal have mulighed for at angive navn, CPR-nummer, fødselsår og startvægt. Systemet skal selv finde og angive patientens køn og alder ud fra CPRnummer. HyMa skal have en funktion til redigering af gemte patientoplysninger; navn, startvægt, fødselsår og CPR-nummer. Hvis ikke alle oplysninger er tilgængelige eller indtastet forkert, skal det være muligt for brugeren at angive disse i patientoplysningerne efterfølgende. HyMa skal have en funktion til redigering af gemte VPD, hvis en oplysning er angivet forkert. HyMa skal give brugeren mulighed for at registrere en udefineret VPD for både ind- og udgift. Hvis den rette parameter ikke kan vælges, skal det være muligt for brugeren at indtaste den i et andet felt, således al indgift og udgift registreres. Data indtastet i HyMa skal være brugerregistreret. Det skal være muligt for brugeren at se, hvornår hver parameter er registreret samt af hvem. HyMa skal give et overblik over patientens nuværende vægt i forhold til startvægten. Det skal være muligt for brugeren at se, hvor langt patientens nuværende vægt er fra startvægten. HyMa skal give brugeren mulighed for at angive patientens startvægt. Efterfølgende kan den nuværende vægt indtastes løbende. De to vægte skal vises grafisk for brugeren, således der hurtigt kan skabes et overblik over disse. HyMa skal give brugeren mulighed for at angive et normalområde for patientens vægt, samt give brugeren besked om, hvordan patientens vægt ligger i forhold til normalområdet.

43 6.1. FUNKTIONELLE KRAV 31 HyMa skal give brugeren mulighed for at angive notater i systemet. Brugeren skal have mulighed for at knytte et notat til hver indtastning, således uregelmæssigheder, særlige fokuspunkter eller uhensigtsmæssige hændelser registreres. HyMa skal give et overblik over patientens væskebalance ud fra relevante væskeparametre ved grafisk fremstilling af data og tabeloversigt. HyMa skal overskueliggøre patientens væskebalance for personalet i form af relevante væskeparametre over en tidsperiode. Tidsperioden og parametre skal kunne vælges af brugeren, men systemet skal også have default-indstillinger, således brugeren hurtigt kan få et overblik, uden at skulle indstille systemet. VPD visualiseres både ved grafisk fremstilling og ved en tabeloversigt, hvilket giver personalet mulighed for at overskue og evaluere data ved forskellige præsentationsformer. HyMa skal give mulighed for at vælge en tidsperiode for den grafiske fremstilling af data eller tabeloversigt. HyMa skal give mulighed for grafisk visning af de enkelte væskeparametre. Udover default-indstillingerne for væskeparametrene skal personalet have mulighed for at ændre disse i form af tilvalg og fravalg af væskeparametre, således kun de valgte væskeparametre illustreres grafisk. Dette øger fleksibiliteten for personalet, hvorved behovet for den enkelte bruger kan tilpasses. HyMa skal håndtere akkumulering af kontinuerte væskeparametre såvel som ikkekontinuerte væskeparametre. HyMa skal håndtere kontinuerte væskeparametre, der ikke angives som en enkelt værdi, men som en rate eller mængde hen over et døgn. Ikke-kontinuerte væskeparametre som for eksempel diurese forventes registreret løbende. Kontinuerte væskeparametre som perspiratio, vand fra metabolisme og akkumuleret væskebalance skal udregnes automatisk af HyMa for at undgå fejlberegninger, hvorfor HyMa skal implementere formler til beregning af disse parametre. HyMa skal opdatere patientens væskebalance på relevante tidspunkter. Det er fordelagtigt for personalet, at væskebalancen opdateres kontinuerligt. HyMa skal opdatere væskebalancen kontinuerligt ud fra kontinuerte og ikke-kontinuerte VPD. HyMa skal give brugeren mulighed for at foretage udskrift af VPD. HyMa skal kunne anvendes af læger og sygeplejersker. HyMa skal kunne anvendes af forskellige typer brugere med forskellig faglig baggrund. HyMa skal håndtere fejlindtastninger. HyMa skal indeholde metoder til håndtering af fejlindtastninger.

44 32 KAPITEL 6. SYSTEMKRAV 6.2 Non-funktionelle krav HyMa skal være mindst lige så brugervenlig som det papirbaserede system. HyMa skal mindske antallet af indtastninger for brugeren, samt udføre relevante beregninger, således brugeren oplever anvendelsen af applikationen som en fordel. HyMa skal have en simpel brugergrænseflade. HyMas brugergrænseflade skal være simpel, således applikationen bliver enkel og overskuelig for brugeren. Anvendelsen af systemet skal ske med færrest mulige tryk. Det skal være tydeligt, hvad hver knap gør, og hvor de enkelte funktioner ligger i applikationen. HyMa skal udvikles til en mobil enhed. HyMa skal udvikles til en tablet, således brugeren kan indtaste væskeparametre, der hvor patienten er, og ikke først notere på papir for senere at indføre det i applikationen. HyMa skal understøtte persistering af patientinformation og behandling. HyMa skal gemme data og give brugeren mulighed for at hente data igen på alle tidspunkter. HyMa skal notificere brugeren om systemets netværksstatus. Brugeren skal notificeres, hvis HyMa ikke har været i stand til at oprette forbindelse til databasen. HyMa skal efter en periode med inaktivitet logge brugeren af. Af sikkerhedsmæssige årsager skal HyMa efter fem minutters inaktivitet automatisk logge brugeren ud af systemet. 6.3 Systembeskrivelse I dette afsnit beskrives systemet og dets funktioner ud fra viden indsamlet i problemanalysen, samt de opstillede funktionelle og non-funktionelle krav. Systemets brugere skal hver især registreres og have et unikt login. Dette login kan med fordel være det samme, som anvendes på sygehusets andre systemer. Når brugeren er logget ind, skal der være mulighed for at oprette nye patienter, samt vælge allerede oprettede patienter fra en liste. Oprettelse af nye patienter i systemet skal ske ved indtastning af færrest mulige oplysninger. Hver patient skal oprettes med navn, CPR-nummer, startvægt og fødselsår, hvor alder og køn udledes af CPR-nummer og fødselsår. Dato, patientens navn, CPR-nummer, køn, startvægt og alder vil efterfølgende vises øverst i højre hjørne af skærmen, når der er logget ind på en patient, således brugeren altid nemt og hurtigt kan se disse oplysninger.

45 6.3. SYSTEMBESKRIVELSE 33 Når brugeren vælger en patient, skal der være mulighed for at indtaste værdier for en række prædefinerede væskeparametre. Hvis den nødvendige parameter ikke er defineret, kan værdier noteres i felterne Anden udgift eller Anden indgift. Derudover skal brugeren have mulighed for at redigere de indtastede parametre, hvis disse ved en fejl ikke er angivet korrekt. Ved redigering af parametre kan brugeren indskrive et notat. Brugeren skal endvidere have mulighed for at se en grafisk fremstilling af patientens væskebalance. Den grafiske fremstilling kan plottes ud fra enten den akkumulerede væskebalance eller enkelte parametre, udvalgt af brugeren selv. Derudover skal brugeren have mulighed for at vælge en tidsperiode, som denne ønsker at se den akkumulerede væskebalance for. Udover den grafiske fremstilling skal det være muligt at se en oversigtstabel over den akkumulerede væskebalance samt enkelte parametre. De to fremvisningstyper skal have en default-indstilling, for hurtig anvendelse, mens andre funktioner kræver specifikke valg fra brugeren. HyMa skal desuden have en printfunktion til udskrivning af grafer eller tabel. HyMa skal indeholde beslutningsstøtte i form af startvægt og nuværende vægt, hvilket skal visualiseres på patientforsiden. Beslutningsstøtte defineres i denne sammenhæng som en grafisk præsentation af patientens nuværende vægt i forhold til startvægt. Brugeren har også mulighed for at angive et normalområde for patientens vægt. Hvis brugeren gør dette, vil HyMa informere brugeren, om patienten ligger indenfor eller udenfor dette område. Når brugeren er færdig med at anvende HyMa til monitorering eller notering, skal det være muligt at logge af systemet. Af sikkerhedsmæssige årsager skal der desuden være automatisk logout ved fem minutters inaktivitet Brugervenlighed Det er væsentligt, at systemet udvikles, således det er brugervenligt, hvis det skal kunne erstatte den nuværende løsning. Et system er brugervenligt, hvis det er nemt at lære, effektivt at bruge og giver en god brugeroplevelse. [Rogers et al., 2011] Et godt udgangspunkt for udvikling af et brugervenligt system er Less Is More-begrebet, da funktioner, der ikke anvendes, vil være en irritation for brugeren. Derfor er det vigtigt at udforme systemet så enkelt som muligt, således systemets layout er overskueligt. Brugervenlighed kan opnås ved at forstå brugerens arbejdsgange og behov. [Nielsen, 1993] På Urologisk Afdeling, Aalborg Universitetshospital er den vigtigste parameter vægten, hvorfor startvægt og nuværende vægt præsenteres på patientforsiden, således brugeren ikke skal anvende knapper for at få denne vist. HyMa gøres brugervenlig, ved at alle knapper og funktioner er let tilgængelige og har et præcist navn, således brugeren ved, hvilke knapper der skal anvendes i en given si-

46 34 KAPITEL 6. SYSTEMKRAV tuation, og at der sker det, de forventer, når de trykker på en knap. Derudover skal HyMa have et enkelt design med så få knapper som muligt. Det er en vigtig egenskab for brugerne, at sproget er dansk for at undgå tvetydighed og mindske misforståelser i forbindelse med registrering af væskedata ved monitorering. [Pedersen, 2014] Antagelser I forbindelse med udviklingen af HyMa er der opstillet en række antagelser. Dette gøres af hensyn til, at systemet skal anvendes på Aalborg Universitetshospital, hvor det skal indgå i samspil med de eksisterende it-løsninger. Hvis applikationen skal implementeres på Urologisk Afdeling, vil dataudveksling med EPJ muligvis være en løsning. En patient skal dermed ikke oprettes i HyMa med alle oplysninger, men kan hentes fra EPJ-systemet. Ydermere vil det betyde, at data, der noteres i HyMa, kan tilgås fra alle afdelingens computere. Det kan være kompliceret at implementere nye it-systemer i sundhedssektoren og svært at få adgang til EPJ af sikkerhedsmæssige årsager, hvorfor HyMa er udarbejdes som et selvstændigt system med henblik på mulig integration i EPJ. Det antages også, at brugerne af HyMa allerede er oprettet som brugere af andre systemer på sygehuset. De samme loginoplysninger anvendes derfor i HyMa.

47 Analyse 7 I dette kapitel vil problemdomænet blive analyseres med henblik på brugerens ønskede softwareløsning. Problemdomænet vil blive modelleret ved brug af en række UML teknikker, der har til formål at hjælpe til i denne proces. Dette foregår blandt andet gennem UC-diagrammer, der beskriver hvordan brugeren interagerer med systemet. Systemets statiske struktur modelleres gennem identifikation af vigtige analyseklasser. Disse vil efterfølgende blive opstillet i et klassediagram, hvor relationen mellem klasserne vil illustreres, samt systemets objekttyper. De vigtige klasser og deres relationer kaldes dermed den statiske struktur. Til sidst i kapitlet vil systemets dynamiske adfærd blive illustreret i form af et sekvensdiagram, som viser, hvordan objekterne interagerer med hinanden. [Fowler, 2004] 7.1 Use case-diagram Ud fra systembeskrivelsen udarbejdes et UC-diagram, som illustreres i figur 7.1. UCdiagrammer er en teknik til at fremvise de funktionelle krav til et system. [Fowler, 2004] Disse illustrerer interaktionerne mellem brugere og det pågældende system, i dette tilfælde en applikation. Disse brugeres rolle i forbindelse med systemet kan variere fra hinanden. [Arlow and Neustadt, 2002] I UC-diagrammet, som illustreres på figur 7.1, er brugerne præsenteret som sundhedspersonale, som både kan være sygeplejersker og læger. Hver handling, som disse brugere kan udføre, kaldes UCs og er illustreret som ovaler. For hver af disse UCs vil der i afsnit 7.2 blive udformet et aktivitetsdiagram. 35

48 36 KAPITEL 7. ANALYSE Figur 7.1: illustrerer UC-diagram for HyMa.

49 7.2. AKTIVITETSDIAGRAMMER Aktivitetsdiagrammer Aktivitetsdiagrammer beskriver det workflow, der tilhører hver UC, som ses på figur 7.1, og den proceduremæssige logik, som ligger bag. I dette afsnit opstilles tabeller for UCs fra figur 7.1. I disse tabeller beskrives brugerens forudsætninger for udførelse af en pågældende aktivitet (UC), Main Success Senario (MSS), følgetilstande samt extensions. MSS beskriver, hvilke handlinger brugeren kan forvente ved succesfuld udførelse af den ønskede aktivitet. Extensions beskriver de variationer, som kan opstå ved udførelse af de enkelte UCs. Til hver tabel udarbejdes et tilhørende aktivitetsdiagram, som illustreres i forhold til den følgende UCs funktion. Login HyMas login-funktion er den første UC, der udføres. Her skal brugeren indtaste sine loginoplysninger, som består af brugernavn og password. Brugerens login valideres ved at tjekke, om samme loginoplysninger findes i databasen. Ved ikke-eksisterende brugeroplysninger i databasen får brugeren feedback om Fejlindtastning. Brugeren får herefter mulighed for at forsøge igen. I tabel 7.1 ses informationer for denne UC. Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Login Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er registreret med loginoplysninger i databasen. 1. Brugeren indtaster login-oplysninger for at logge på systemet. 2. Brugeren trykker Log ind. 3. Systemet opretter forbindelse til databasen. 4. Systemet validerer loginoplysninger. 5. Forbindelsen til databasen afbrydes. 6. Identificer patient-side vises. Brugernavn og password er identificeret, og brugeren logget ind på systemet. 4.a: Login-oplysningerne kan ikke valideres, da brugernavn og password ikke passer sammen. 1. Systemet viser en fejlmelding. 2. Login-siden vises. Tabel 7.1: Beskrivelse af UC: Login. På figur 7.2 ses tilhørende aktivitetsdiagram for login-funktionen.

50 38 KAPITEL 7. ANALYSE Figur 7.2: Aktivitetsdiagram for UC: Login. Logout Det skal være muligt for brugeren at logge af systemet, efter login er foretaget. I tabel 7.2 ses informationer, som er tilknyttet UC: Logout, og figur 7.3 viser tilhørende aktivitetsdiagram. Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Logout Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er logget ind på systemet, og activitytimeren er startet. 1. Systemet logger brugeren ud, hvis log ud knappen aktiveres, eller systemet er inaktivt i fem minutter. 2. Systemet nulstiller loginoplysninger. 3. Systemet går tilbage til login-side. Brugeren logges af systemet, og login-side vises. Tabel 7.2: Beskrivelse af UC: Logout.

51 7.2. AKTIVITETSDIAGRAMMER 39 Figur 7.3: Aktivitetsdiagram for UC: Logout. Activitytimer Når brugeren logger ind, startes en activitytimer, som nulstilles, hver gang der registreres aktivitet i HyMa. Denne timer anvendes til automatisk logout ved brugerinaktivitet i fem minutter. I tabel 7.3 ses informationer, som er tilknyttet UC: Activitytimer, og figur 7.4 viser tilhørende aktivitetsdiagram.

52 40 KAPITEL 7. ANALYSE Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Activitytimer Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er logget ind på systemet. 1. Activitytimeren startes. 2. Timeren er aktiv. 3. Brugeren er inaktiv i fem minutter. 4. Systemet foretager logout. Brugeren logges af systemet, og Login-side vises. 3.a Brugeren foretager en aktivitet inden for fem minutter. 1. Timeren genstartes. Tabel 7.3: Beskrivelse af UC: Activitytimer. Figur 7.4: Aktivitetsdiagram for UC: Activitytimer.

53 7.2. AKTIVITETSDIAGRAMMER 41 Identificer patient Før brugeren kan anvende funktioner tilknyttet en patient, skal patienten identificeres i HyMa. Hvis patienten ikke kan identificeres, betyder det, at patienten ikke er oprettet i databasen, eller at CPR-nummeret er indtastet forkert. Hvis dette er tilfældet, giver HyMa brugeren mulighed for at indtaste CPR-nummeret igen eller oprette en ny patient i databasen. I tabel 7.4 og figur 7.5 ses informationer og udførelse af denne UC. Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Identificer patient Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er logget ind på systemet. 1. Brugeren indtaster patientens CPR-nummer. 2. Systemet tjekker, om CPR-nummer er indtastet korrekt (10 cifre). 3. Systemet opretter forbindelse til databasen. 4. Systemet identificerer CPR-nummer i databasen. 5. Systemet afbryder forbindelse til databasen. 6. Systemet viser patientforside. Patient er identificeret, og patientforside vises. 4.a: Systemet kan ikke identificere CPR-nummer, fordi denne ikke er oprettet i databasen. 1. Systemet informerer brugeren om, at patienten ikke er oprettet. 2. Brugeren kan vælge at oprette CPR-nummer i databasen. Tabel 7.4: Beskrivelse af UC: Identificer patient. Opret patient I tilfælde hvor patienten ikke er registreret i databasen, udfører HyMa UC: Opret patient, hvor brugeren kan registrere de resterende patientinformationer. CPR-nummer overføres automatisk fra identificeringen. I tabel 7.5 findes informationer om denne UC, og på figur 7.6 ses tilhørende aktivitetsdiagram. Rediger patientinformation HyMa gør det muligt for brugeren at redigere i patientinformationer for eksempel i tilfælde af fejlregistrering af patientens CPR-nummer, navn, fødselsår og startvægt. I tabel 7.6 og figur 7.7 ses informationer og workflow for denne UC.

54 42 KAPITEL 7. ANALYSE Figur 7.5: Aktivitetsdiagram for UC: Identificer patient. Tilføj notat Brugeren kan vælge at indtaste et notat til hver VPD eller oprette et generelt notat på Notatside. I tabel 7.7 og på figur 7.8 ses workflow og informationer for denne UC. Registrer VPD I forbindelse med væskemonitorering har HyMa en UC, hvor brugeren kan registrere nye væskeparametre eller data til allerede registrerede parametre. Informationer og illustration af workflow for UC: Registrer VPD ses i tabel 7.8 og på figur 7.9.

55 7.2. AKTIVITETSDIAGRAMMER 43 Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Opret patient Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er logget ind på systemet. Systemet har udfyldt feltet CPR-nummer angivet på Identificer patient-siden. 1. Brugeren indtaster patientoplysninger. 2. Systemet finder køn og alder via patientens CPR-nummer. 3. Systemet opretter forbindelse til database. 4. Systemet gemmer patientens informationer i databasen. 5. Systemet afbryder forbindelse til database. 6. Systemet viser Patientforside for brugeren. Patient er oprettet og identificeret. Brugeren har mulighed for at anvende systemets funktioner. 3.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet giver fejlmelding til brugeren. Tabel 7.5: Beskrivelse af UC: Opret patient. Figur 7.6: Aktivitetsdiagram for UC: Opret patient. Rediger VPD Ved indtastningsfejl gør HyMa det muligt for brugeren at redigere i indtastede VPD, hvis denne er kommet til at angive en forkert værdi. Denne UC forklares i tabel 7.9 og

56 44 KAPITEL 7. ANALYSE Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Rediger patientinformation Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er logget ind på systemet. Patient er identificeret. 1. Brugeren vælger Rediger patient-knap. 2. Systemet opretter forbindelse til databasen. 2. Systemet henter og viser patientens oplysninger. 3. Brugeren vælger den oplysning, der skal ændres. 4. Brugeren indtaster ny data og trykker gem. 5. Systemet gemmer ny data. 6. Systemet afbryder forbindelse til database. Patientinformation er redigeret, og brugeren kan logge ud eller vælge anden funktion. 2.a: Systemet kan ikke oprette forbindelse til database. 1. Systemet giver fejlmelding til bruger. Tabel 7.6: Beskrivelse af UC: Rediger patientinformation. Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Tilføj notat. Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er logget ind. Systemet viser patientoversigt. 1. Brugeren vælger Tilføj notat. 2. Brugeren tilføjer notat. 3. Systemet gemmer notat. 4. Det gemte notat vises for brugeren. Brugeren har tilføjet et notat til den valgte patient. Tabel 7.7: Beskrivelse af UC: Tilføj notat. illustreret i figur Vis beslutningsstøtte I HyMa vises beslutningsstøtte på Patientforside i form af et barchart, der illustrerer den aktuelle vægt og den nuværende vægt for patienten. Det undersøges også, om patientens vægt ligger inden for normalområdet, og dette visualiseres for brugeren. Normalområdet defineres af brugeren. Denne UC forklares i tabel 7.10 og illustreres i figur 7.11 og 7.12.

57 7.2. AKTIVITETSDIAGRAMMER 45 Figur 7.7: Aktivitetsdaigram for UC: Rediger patient. Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Registrer VPD Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonale skal være logget på systemet. Patient er identificeret. 1. Brugeren vælger parameter, der skal angives. 2. Brugeren angiver parameterværdi. 3. Systemet opretter forbindelse til database. 4. Systemet gemmer parameter. 5. Systemet afbryder forbindelse til databasen. Brugerens indtastning af VPD er gemt i patientens oplysninger. Tabel 7.8: Beskrivelse af UC: Registrer VPD.

58 46 KAPITEL 7. ANALYSE Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Figur 7.8: Aktivitetsdiagram for UC: Tilføj notat. Rediger VPD Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonale er logget på systemet. Patient er identificeret. Der er registret en eller flere væskeparametre. 1. Brugeren vælger den parameter, der skal redigeres. 2. Brugeren redigerer den valgte parameter. 3. Systemet opretter forbindelse til database. 4. Systemet overskriver den gamle parameter. 5. Systemet beregner den aktuelle væskebalance. 6. Systemet afbryder forbindelse til database. 7. Systemet viser Patientforside. Nye VPD er gemt. 3.a Systemet kan ikke oprette forbindelse til database. 1. Systemet giver fejlmelding til brugeren. Tabel 7.9: Beskrivelse af UC: Rediger VPD. Visualisering af VPD For visning af indtastede data kan HyMa generere en tabeloversigt eller grafisk fremstilling af de registrerede VPD. Informationer og aktivitetsdiagram for denne UC kan

59 7.2. AKTIVITETSDIAGRAMMER 47 Figur 7.9: Aktivitetsdiagram for UC: Registrer VPD. ses i tabel 7.11 og på figur Vis akkumuleret væskebalance For at give brugeren overblik over patientens væskebalance skal denne være synlig. Tabel 7.12 og figur 7.14 viser informationer og workflow for denne UC. Udskriv VPD Brugeren har mulighed for at få en udskift af den grafiske fremstilling i form af tabel eller graf. Tabel 7.13 og figur 7.15 viser denne UC.

60 48 KAPITEL 7. ANALYSE Figur 7.10: Aktivitetsdiagram for UC: Rediger VPD.

61 7.2. AKTIVITETSDIAGRAMMER 49 Use case Bruger Forudsætninger MSS Følgetilstand Extension Vis beslutningsstøtte Sundhedspersonale (Læge, sygeplejerske) Appen kører Sundhedspersonalet er logget på systemet. En patient er identificeret. 1. Systemet opretter forbindelse til databasen. 2. Systemet henter nuværende og startvægt. 3. Systemet afbryder forbindelse til databasen. 4. Systemet viser patientens status. 5. Systemet viser nuværende vægt og startvægt i barchart samt patientens status på Patientforside. Barchart og status vises på Patientforside. 2.a Der er ikke indtastet nuværende vægt. 1. Nuværende vægt vises ikke. Tabel 7.10: Beskrivelse af UC: Vis beslutningsstøtte. Use case Bruger Forudsætninger MSS Følgetilstand Extension Visualisering af VPD Sundhedspersonale (Læge, sygeplejerske) Appen kører. Sundhedspersonalet er logget ind på systemet. Patienten er identificeret. Der er indtastet en eller flere VPD er. 1. Brugeren vælger funktionen visualisering af VPD. 2. Brugeren vælger visning af tabeloversigt eller en grafisk fremstilling. 3. Brugeren vælger hvilke parametre der skal visualiseres. 4. Brugeren vælger den periode der skal visualiseres. 5. Systemet opretter forbindelse til database. 6. Systemet henter valgte data. 7. Systemet afbryder forbindelse til database. 8. Systemet laver dataoversigt. 9. Brugeren introduceres for oversigten. Brugeren kan se data fremstillet på den ønskede måde. 5.a Systemet kan ikke oprette forbindelse til database. 1. Systemet giver fejlmelding til brugeren. Tabel 7.11: Beskrivelse af UC: Visualisering af VPD.

62 50 KAPITEL 7. ANALYSE Figur 7.11: Aktivitetsdiagram for UC: Vis beslutningsstøtte.

63 7.2. AKTIVITETSDIAGRAMMER 51 Figur 7.12: Aktivitetsdiagram for Vis status. Use case Bruger Forudsætninger MSS Følgetilstand Extension Vis akkumuleret væskebalance Sundhedspersonale (Læge, sygeplejerske) Appen kører. Sundhedspersonalet er logget ind på systemet. Der er logget ind på en patient. 1. Systemet opretter forbindelse til database. 2. Systemet udregner den aktuelle væskebalance. 3. Systemet afbryder forbindelse til database. 4. Systemet beregner den akkumulerede væskebalance. 5. Brugeren introduceres for den aktuelle væskebalance. Brugeren præsenteres for væskebalance. 1.a: Systemet kan ikke oprette forbindelse til databasen. 1. Systemet giver fejlmelding til brugeren. Tabel 7.12: Beskrivelse af UC: Vis akkumuleret væskebalance.

64 52 KAPITEL 7. ANALYSE Figur 7.13: Aktivitetsdiagram for UC: Visualisering af VPD.

65 7.2. AKTIVITETSDIAGRAMMER 53 Figur 7.14: Aktivitetsdiagram for UC: Vis akkumuleret væskebalance. Use Case Bruger Forudsætninger MSS Følgetilstand Extensions Udskriv VPD. Sundhedspersonale (Læge, sygeplejerske). Appen kører. Sundhedspersonalet er logget ind på systemet. Patient er identificeret. 1. Bruger vælger VPD, der skal udskrives. 2. Bruger trykker på Udskriv-knap. 3. Systemet opretter dokument med valgte VPD. 4. Systemet opretter forbindelse til printer. 5. Systemet sender dokument til printer. VPD er udskrevet. 4.a: Systemet kan ikke oprette forbindelse til printer. 1. Systemet giver fejlmelding til bruger. Bruger kan vælge at afbryde eller prøve at oprette forbindelse igen. Tabel 7.13: Beskrivelse af UC: Udskriv VPD.

66 54 KAPITEL 7. ANALYSE Figur 7.15: Aktivitetsdiagram for UC: Udskriv VPD.

67 7.3. ANALYSEKLASSER OG ANALYSEDIAGRAM Analyseklasser og analysediagram Ud fra UCs konstrueres analyseklasser og analyseklassediagram. Analyseklasser illustrerer dermed de klasser, som skal anvendes for at opfylde systemets funktioner. Disse klasser indeholder kun attributter og high-level metoder og ansvarsområder. Analyseklassediagrammet viser relationer og multipliciteter mellem analyseklasserne. [Arlow and Neustadt, 2002] I UML illustreres en klasse som en tabel bestående af tre til fire felter, hvori klassens navn og tilhørende attributter, metoder og eventuelt ansvarsområde. Denne opsætning er vist på figur [Arlow and Neustadt, 2002] Indholdet af klassernes felter kan variere fra analyse til design, da designklasser opstilles i en mere detaljeret form, som ses i kapitel 8. Figur 7.16: Opbygning af en klasse ifølge UML. [Arlow and Neustadt, 2002] Analyseklasser I forbindelse med identifikation af analyseklasser for HyMa benyttes substantiv/verbum analyse. Denne metode anvendes for at sikre, at de rigtige analyseklasser identificeres, da dette er essentielt i objektorienteret analyse og design. Identificeres forkerte analyseklasser kan dette påvirke designet [Arlow and Neustadt, 2002]. Substantiv/verbum analysen foretages på baggrund af UC-diagrammet og aktivitetsdiagrammerne, hvor substantiver og verber, som beskriver systemet, opstilles. Substantiver indikerer ofte klasser eller attributter, mens verber indikerer klassers metoder eller ansvarsområder. Ud fra listen med substantiver og verber laves en figur med kandidatklasser, som senere anvendes til at opstille analyseklasser [Arlow and Neustadt, 2002]. Substantiv/verbum analysen er vist i tabel Ved hjælp af substantiv/verbum analysen konstrueres kandidatklasserne, som ses på figur 7.17 med tilhørende attributter og metoder. For at overskueliggøre analyseklasserne og deres relationer inddeles disse i stereotyper baseret på tre typer [Arlow and Neustadt, 2002]. Derudover oversættes klasser, metoder

68 56 KAPITEL 7. ANALYSE Substantiver Patient CPR-nummer Navn Fødselsdato Køn Vægt VPD Timestamp Graf Brugernavn Password ParameterType ParameterVærdi ParameterNavn Notat AkkumuleretVæskebalance TabelOversigt Periode Printlayout Printer PrinterNavn PrinterStatus Verber Validere Registrere Login Logout Identificere Oprette Redigere Tilføje Udskrive Vise Vælge Sende Lave Hente Beregne Tabel 7.14: Substantiv/verbum analyse. og attributter til engelsk, således der er mulighed for, at HyMas klasser kan anvendes internationalt. «boundary» klasser interagerer med brugeren af systemet «control» klasser skaber forbindelse mellem «boundary» og «entity» klasser, samt kontrollerer datastrømme «entity» klasser lagrer data Analyseklasserne identificeres ud fra kandidatklasserne, som revurderes i forhold til ovenstående stereotyper og to af klasserne inddeles i flere. Database deles op i DatabaseHandler, DatabaseExport og DatabaseImport for at skabe en klasse, der ikke er systemspecifik, men kan anvendes i andre henseender. DatabaseHandler er en generel klasse, mens DatabaseImport og DatabaseExport er systemspecifikke. Visualisering

69 7.3. ANALYSEKLASSER OG ANALYSEDIAGRAM 57 Figur 7.17: Kandidatklasser for HyMa konstrueret ud fra substantiv/verbum analysen. inddeles i to systemspecifikke klasser; Table og Graph. På figur 7.18 ses analyseklassediagram for HyMa. I analyseklassediagrammet, figur 7.18, ses klassernes relationer og stereotype. Klassen Patient er af typen «entity» og har klasserne; Note og VPD tilknyttet. Note og VPD er ligeledes tilknyttet User, da der kræves en bruger til at oprette begge.

70 58 KAPITEL 7. ANALYSE Table og Graph er begge tilknyttet Userinterface, der er af typen «boundary». Dette skyldes, at Userinterface er den brugergrænseflade, hvor Table og Graph vises, hvorfor disse ikke kan eksistere uden UserInterface. Table og Graph er endvidere afhængige af VPD, da disse anvender VPD. Klassen FluidBalance, der er af typen «entity», er tilknyttet klasserne; VPD og Patient. Dette begrundes med, at en patient har en væskebalance, og at væskebalancen ikke kan udregnes uden VPD. Print er af typen «control» og tilknyttet Table og Graph, da der ikke kan printes, medmindre der er en graf eller tabel. Alle klasser af typen «entity» er afhængige af «control» klasserne; DatabaseHandler, DatabaseExport og DatabaseImport, da disse klasser håndterer oprettelse af forbindelse til databasen samt import og eksport af data. Dette vises med den blå indramning på figur 7.18.

71 7.3. ANALYSEKLASSER OG ANALYSEDIAGRAM 59 Figur 7.18: Analyseklassediagram for HyMa. Den blå ramme indeholder klasser, der har forbindelse til DatabaseHandler, DatabaseImport og DatabaseExport.

72

73 Design 8 I kapitlet beskrives de vigtigste objektorienterede principper samt trelagsprincippet, der anvendes til udarbejdelsen af HyMa. Derudover udarbejdes mockups, der danner grundlag for applikationslayoutet, samt et screenflowdiagram, der viser, hvordan det er muligt for brugeren at navigere mellem HyMas scener. HyMa designes ud fra resultatet af analysen. HyMa designes ved hjælp af designklasser, hvorefter databasen designes ved hjælp af et ER-diagram. Afslutningsvis laves sekvensdiagrammerne på baggrund af de ovenstående designs. 8.1 Objektorienterede principper De tre vigtigste principper indenfor objektorienteret design og -programmering er nedarvning, polymorfisme og encapsulation. Principperne anvendes til udviklingen af HyMa og beskrives i det følgende. Nedarvning tillader at oprette en klasse ud fra en eksisterende klasse. Den nye klasse oprettes som en subklasse. Subklassen vil nedarve alle variable, constructors og metoder fra superklassen, således subklassen kan anvende disse. Dette princip anvendes i objektorienteret programmering for at genanvende kode. I subklassen kan der tilføjes flere metoder og variabler. [Murach, 2011] Polymorfisme gør det muligt at behandle objekter af forskellige typer, som om de var af samme type, hvis de har en fælles superklasse. Dette gør, at der kan skrives en generisk kode til en superklasse, der kan anvendes af alle superklassens subklasser og at nye subklasser altid kan tilføjes og anvende samme kode. [Murach, 2011] Polymorfisme kan også opnås gennem interfaces. Et interface indeholder en række metoder, der kan implementeres af en klasse. En klasse, der implementerer et interface, skal implementere alle metoderne fra interfacet. [Murach, 2011] Encapsulation benyttes, på den måde at en klasse kan kontrollere, hvilke af klassens variabler og metoder der kan tilgås fra andre klasser. Dette gøres ved, at gøre klassens 61

74 62 KAPITEL 8. DESIGN variabler private, således data kun tilgås gennem getters() og setters(), der henholdsvis henter og ændrer dataværdier. Tilgængeligheden til de indkapslede data bestemmes ud fra, hvilke af de to metoder der implementeres. [Murach, 2011] 8.2 Trelagsarkitektur Dette afsnit beskriver trelagsarkitekturen, som benyttes i designfasen af HyMa. Trelagsarkitekturen er en klient-server-arkitektur, der anvendes som mønster til softwaredesign. Denne arkitektur strukturerer proceslogik, dataadgang og -lagring, samt brugergrænseflade. Disse anvendes som selvstændige moduler, der kan forbindes til og kommunikere med hinanden. [Janssen, 2014] Disse moduler oprettes som packages i Java. [Murach, 2011] Denne arkitekturform består af tre lag; presentation-, business- og datalayer. [Murach, 2011] Opbygningen illustreres i figur 8.1. Figur 8.1: Illustration af trelagsarkitektur. Redigeret fra [Murach, 2011]. Presentationlayer kontrollerer applikationens brugergræseflade ved hjælp af præsentationsklasser. Det meste af denne kode udføres i startmetoden, som kalder efter metoder fra andre klasser. [Murach, 2011] Businesslayer håndterer kommunikationen mellem datalayer og presentationlayer. Metoder til behandling af data findes også i dette lag. [Murach, 2011] Datalayer indeholder databaseklasser, der varetager datahåndtering og databasekald. Dette lag indeholder klasser, som kan oprette forbindelse til databasen, samt hente, gemme, slette og opdatere informationer heri. [Murach, 2011] Fordelene ved at anvende trelagsarkitektur er blandt andet, at det er nemt at dele op, således en gruppe kan arbejde med for eksempel businesslayer og en anden på presentationlayer.

75 8.3. APPLIKATIONSLAYOUT Applikationslayout I dette afsnit illustreres og beskrives de forskellige scener for at give en præsentation af HyMas layout. Til sidst vises et screenflowdiagram af, hvordan det er muligt at navigere mellem scenerne. Når HyMa startes, vises startvinduet, som illustreres i figur 8.2. På denne scene logges brugeren ind på systemet ved at angive korrekt brugernavn og password. Brugeren skal være registreret i databasen for, at login kan foretages. Figur 8.2: Mockup af Login-scene for HyMa. Efter korrekt login vises Patientidentifikation-scenen, som vises på figur 8.3. På denne scene identificeres den ønskede patient ved angivelse af CPR-nummer. Der er i forbindelse med dette mulighed for at vælge en patient fra en liste med senest anvendte patienter. Det tjekkes om patienten er oprettet i databasen ved at validere det angivne CPR-nummer. Hvis patienten ikke er oprettet, får brugeren mulighed for at oprette en ny patient, hvilket illustreres på figur 8.4.

76 64 KAPITEL 8. DESIGN Figur 8.3: Mockup af Patientidentifikation-scene for HyMa. Ved valg af Opret ny patient vises scenen Opret Patient som ses på figur 8.5. Her oprettes patienten ved at angive CPR-nummer, navn og startvægt. Når en patient er blevet oprettet eller succesfuldt identificeret fra databasen, vises Patientforside-scenen, som ses på figur 8.6. På denne scene vises patientinformationer i øverste højre hjørne, hvilket også vises på de øvrige scener. Barchartet på scenen viser startvægten og den nuværende vægt for patienten. I forbindelse med dette er der mulighed for at angive et normalområde for vægten, således systemet notificerer brugeren, hvis vægten ligger udenfor dette område. Brugeren kan derudover vælge en række andre funktioner ved tryk på de implementerede knapper. Hvis Patient information vælges kan brugeren redigere patientoplysningerne. Det er valgt at implementere Log ud-knappen på alle scener. Hvis funktionen Indtast VPD vælges, vises scenen Registrer VPD, som ses på figur 8.7. Her kan brugeren registrere VPD for patienten.

77 8.3. APPLIKATIONSLAYOUT 65 Figur 8.4: Mockup af pop-up meddelelse som vises, hvis det angivne CPR-nummer ikke eksisterer i databasen. Hvis funktionen Vis VPD oversigt vælges, præsenteres brugeren for en grafisk visning af registrerede VPD, hvilket ses på figur 8.8. Her er det muligt at vælge en prædefineret tidsperiode, som viser valgte VPD indenfor perioden. Det kan også vælges at få vist en tabeloversigt over de valgte VPD. Hvis funktionen Notater vælges, præsenteres brugeren for Notat-scenen som vist på figur 8.9. Her kan brugeren tilføje notater knyttet til patienten. Derudover vises historikken for tidligere indtastede notater. For at illustrere og give et overblik over, hvilke af HyMas scener der har forbindelse til hinanden, er der udarbejdet et screenflowdiagram, som ses på figur 8.10.

78 66 KAPITEL 8. DESIGN Figur 8.5: Mockup af Opret Patient-scene for HyMa.

79 8.3. APPLIKATIONSLAYOUT 67 Figur 8.6: Mockup af Patientforside-scenen for HyMa.

80 68 KAPITEL 8. DESIGN Figur 8.7: Mockup af Registrer VPD-scenen for HyMa.

81 8.3. APPLIKATIONSLAYOUT 69 Figur 8.8: Mockup af Visualisering af VPD-scenen for HyMa.

82 70 KAPITEL 8. DESIGN Figur 8.9: Mockup af Notat-scenen for HyMa.

83 8.3. APPLIKATIONSLAYOUT 71 Figur 8.10: Screenflowdiagram, der viser, hvordan der kan navigeres mellem HyMas scener.

84 72 KAPITEL 8. DESIGN 8.4 Designklasser og designklassediagram I dette afsnit beskrives, hvordan HyMa implementeres i forhold til de opstillede analyseklasser. Designklasserne konstrueres ud fra analyseklasserne, hvor analyseklasserne revurderes for at anvende objektorienterede principper. DataImport fra figur 7.18 opdeles i fire klasser; PatientRepository, UserRepository, NoteRepository og VPDRepository, som sørger for import af data fra databasen via SQL-kald. Polymorfisme anvendes ved implementering af interfaces, hvor et Saveable-interface introduceres og implementeres af klasserne; Patient, VPD og Note. User implementerer ikke dette interface, da der ikke skal være mulighed for at oprette nye brugere. Saveable-interfacet fungerer som erstatning for DatabaseExport og anvendes sammen med Save-metoden i DatabaseHandler. Der er tilføjet to klasser, VPDTable og VPDGraph, som begge er tilknyttet VPDOverviewScene. Nedarvning benyttes i forbindelse med VPDGraph, da der skal genereres flere typer grafer, hvorfor superklassen Graph introduceres. Graph er abstract, da den indeholder en abstract metode, som gør det muligt for subklasser at kalde og anvende denne metode. På figur 8.11 er vist designklasser for HyMa. Trelagsarkitekturen er ligeledes vist på figuren, hvor designklasserne er inddelt i presentationlayer, businesslayer og datalayer. Figur 8.11: Designklasser for HyMa.

85 8.4. DESIGNKLASSER OG DESIGNKLASSEDIAGRAM Klasser i presentationlayer Alle designklasser i presentationlayer interagerer med en bruger, og hver designklasse repræsenterer en scene som vist i afsnit 8.3. Figur 8.12 viser klassen UserLoginScene, der fungerer som HyMas startside, hvor brugeren logger ind på systemet. Metoden validateuser() validerer brugernavn og password i databasen. Figur 8.12: Designklassen UserLoginScene. Figur 8.13 viser designklassen VPDOverviewScene med metoderne; showgraph() og showtable(). VPDOverviewScene er tilknyttet klasserne; VPDGraph() og VPDTable(), som genererer tabellen og grafen, som vises i VPDOverviewScene. Figur 8.14 viser abstract-klassen Graph, der indeholder attributter og metoder, som er generelle for subklassen VPDGraph. På figur 8.15 ses designklassen for RegisterVPDScene, der giver brugeren mulighed for at angive og registrere VPD. RegisterVPDScene har metoden registervpd(), som forbereder data til at blive gemt i databasen. Designklassen PatientIdentificationScene ses på figur PatientIdentificationScene giver brugeren mulighed for at angive CPR-nummer og søge efter en patient eller vælge at oprette en ny patient, hvis denne ikke findes. Metoden validatecpr() validerer, om CPR-nummer eksisterer i databasen. På figur 8.17 ses designklassen for AddPatientScene, hvor brugeren har mulighed for at oprette en ny patient ved at angive oplysninger om patienten. Metoden savepatient() forbereder data til at blive gemt i databasen. Figur 8.18 viser designklassen NoteScene, der har forbindelse til NoteTable, som genererer tabellen på NoteScene. NoteScene har metoden shownote(), der viser tabellen

86 74 KAPITEL 8. DESIGN Figur 8.13: Designklassen VPDOverviewScene, hvor forbindelsen til VPDTable og VPD- Graph er vist. Figur 8.14: Designklassen Graph. fra NoteTable med registrerede notater. Figur 8.19 viser designklassen for PatientPageScene. Denne klasse har metoden showweight- BarChart(), som viser barchartet, der bliver genereret i WeightBarChart Designklasser i businesslayer I det følgende afsnit beskrives klasserne i businesslayer, som er de klasser, der forbinder data- og presentationlayer.

87 8.4. DESIGNKLASSER OG DESIGNKLASSEDIAGRAM 75 Figur 8.15: Designklassen RegisterVPDScene. Figur 8.16: Designklassen PatientIdentificationScene. Figur 8.17: Designklassen OpretPatientScene. På figur 8.20 ses designklassen Patient. Klassen har attributterne; CPR, birthdate, gender, name og startweight. Klassen har derudover setters() og getters() for tilhørende attributter, samt calculatenormalrange, som udregner patientens vægtniveau i forhold til det angivne normalområde. Designklasserne; User, Note og VPD ses på henholdsvis figur 8.21, figur 8.22 og figur Disse klasser indeholder attributter og tilhørende setters() og getters(). Figur 8.24 viser designklassen FluidBalance, der indeholder metoden getfluidbalance(), der beregner patientens akkumulerede væskebalance ud fra patientens registre-

88 76 KAPITEL 8. DESIGN Figur 8.18: Designklassen NoteScene, hvor forbindelsen til NoteTable er vist. Figur 8.19: Designklassen PatientPageScene. rede ind- og udgifter. Figur 8.25 viser designklassen Print, der indeholder attributten printlayout og metoderne getprintlayout() og Print(). getprintlayout() klargør data til udskrivning,

89 8.4. DESIGNKLASSER OG DESIGNKLASSEDIAGRAM 77 Figur 8.20: Designklassen Patient. Figur 8.21: Designklassen User. Figur 8.22: Designklassen Note. mens print() udskriver de givne data. Klasserne; Patient, User, Note og VPD implementerer alle interfacet Saveable, som ses på figur 8.26, og kan derved gemme data i databasen. Saveable indeholder kun metoden getpreparedstatement(), som muliggør lagring af data i databasen.

90 78 KAPITEL 8. DESIGN Figur 8.23: Designklassen VPD. Figur 8.24: Designklassen FluidBalance. Figur 8.25: Designklassen Print. Figur 8.26: Saveable-interface.

91 8.4. DESIGNKLASSER OG DESIGNKLASSEDIAGRAM Designklasser i datalayer I det følgende afsnit beskrives klasserne i datalayer, hvilket vil sige de klasser, der sørger for kommunikationen med databasen. På figur 8.27 ses designklassen DatabaseHandler, som indeholder generelle databaseoperationer. getdatabaseconnection anvender attributterne; url, username og password til at oprette forbindelse til databasen. Derudover er der tilføjet connection, preparedstatement og resultset, da det vælges at anvende API et JDBC (Java Database Connectivity). Databasehandler indeholder databaseoperationerne getdatabaseconnection(), save() og close(). Figur 8.27: Designklassen DatabaseHandler. Designklasserne VPDRepository, PatientRepository, UserRepository og NoteRepository ses på figur Disse klasser håndterer import af data fra databasen. For at danne et overblik over HyMas designklasserelationer på tværs af de tre lag, udarbejdes et designklassediagram, som ses på figur I diagrammet er klasserne farvekodet, således det fremgår, hvilke klasser der tilhører hvilket lag. Orange klasser illustrerer datalayer, blå klasser businesslayer og grønne klasser presentationlayer. Den blå ramme til venstre indikerer, hvilke klasser der er tilknyttet PatientPageScene, VPDOverviewScene og Print, mens den blå ramme til højre indikerer, hvilke klasser der er knyttet til respositories. Designklassediagrammet illustrerer relationer og multipliciteter mellem designklasserne. UserLoginScene er for eksempel tilknyttet User, som er tilknyttet UserRepository for, at loginoplysninger kan valideres. Multipliciteten fra UserLoginScene til User er 1 til 1, da der kun kan være en bruger logget på af gangen. Multipliciteten fra User til UserRespository er 1 til 1, da der kun udtrækkes data for en bruger af gangen.

92 80 KAPITEL 8. DESIGN Figur 8.28: Designklasserne VPDRepository, PatientRepository, UserRepository og NoteRepository.

93 8.4. DESIGNKLASSER OG DESIGNKLASSEDIAGRAM 81 Figur 8.29: Klassediagram over HyMas designklasser. Orange klasser illustrerer klasser fra datalayer, blå klasser er fra businesslayer, og grønne klasser repræsenterer klasser fra presentationlayer. Den blå ramme til venstre indikerer, hvilke klasser der er tilknyttet PatientPageScene, VPDOverviewScene og Print. Den blå ramme til højre indikerer, hvilke klasser der er knyttet til respositories.