1. No category

Aalborg Universitet
Institut for Sundhedsteknologi
TITEL:
Vægtning af penaltyfunktioner til et intelligent ventilatorsystem ved anvendelse af utilityteori.
TEMA:
Design af sundhedsteknologiske systemer
PROJEKTPERIODE:
6. semester
2/2-2004 - 27/05-2004
PROJEKTGRUPPE:
691
GRUPPEMEDLEMMER:
Mads Hylleberg
Nlandu Kamavuako
Line Michelsen
Mogens Nielsen
Brynjar Vatnsdal Pálsson
Signe Stougård Pedersen
VEJLEDERE:
Stephen Rees
Nico Rijkhoff
ANTAL KOPIER: 10
RAPPORT SIDEANTAL: 144
APPENDIKS SIDEANTAL: 40
SAMLET SIDEANTAL: 184
SYNOPSIS
Når en kliniker skal indstille en respirator for
en kritisk syg patient, skal klinikeren vægte
forskellige kliniske surrogatmål som indikatorer for det kliniske effektmål. Denne tradeoffproblematik kan beskrives teoretisk ved hjælp
af utilityteori.
Der er taget udgangspunkt i en intelligent respirator INVENT, der indeholder én vægtning
af fem kliniske surrogatmål, der er beskrevet
som penaltyfunktioner. I projektet er der udarbejdet et softwaresystem Dr. Know, der skal
producere forskellige vægtninger for penaltyfunktionerne. Dette gøres ved at indsamle og
formalisere klinikeres subjektive holdninger til
de mest rationelle respiratorindstillinger.
Der er med udgangspunkt i objektorienteret
analyse og design og i samarbejde med rekvirenten og klinikere implementeret et vidensindsamlingssystem Dr. Know. Systemet kan
formalisere en præferencestruktur for penaltyfunktionerne for tre udvalgte patientgrupper:
Hjernetraumepatienter, post-operative hjertepatienter og intensivpatienter.
Det konstruerede system Dr. Know vurderes til
at kunne producere vægtninger for de forskellige patientgrupper, og det vurderes således,
at disse vægtninger kan anvendes til at kalibrere INVENT. Systemets beregning af vægtningskonstanterne for penaltyfunktionerne tager lang tid, hvilket ses nødvendigt at optimere
i en senere version af systemet.
Forord
Denne rapport er det skriftlige resultat af et 6. semesters projekt på Civilingeniøruddannelsen Sundhedsteknologi på Aalborg Universitet foråret 2004. Rapporten henvender sig til medstuderende på AAU og de tilknyttede
vejledere samt fagpersoner, der beskæftiger sig med udvikling af INVENT.
Temaet for dette semester er: Design af Sundhedsteknologiske systemer. Dette er specielt med henblik på en
konkret sundhedsteknologisk problemstilling og de biologiske og brugermæssige grænseflader. Med udgangspunkt i dette tema er der arbejdet med at konstruere et vidensindsamlingssystem til anvendelse i et allerede
konstrueret intelligent respiratorsystem.
I forbindelse med projektet vil projektgruppen rette en tak til Dr. Med Charlotte Allerød for hjælp til konstruktion af patientcases, en tak til Dr. Tech Steen Andreassen for hjælp til at stille brugermæssige krav til det
konstruerede system, en tak til Dr. Med. Per Thorgaard for at give brugermæssige krav til det konstruerede
system samt for at give projektgruppen en forståelse for anvendelsen af respiratorer på intensivafdelingen på
Aalborg Sygehus, og en tak til Dr. Med Søren Kjærgaard for at teste det konstruerede system.
Aalborg Universitet d. 27. maj 2004.
———————————–
Mads Hylleberg
———————————–
Nlandu Kamavuako
———————————–
Line Michelsen
———————————–
Mogens Nielsen
———————————–
Brynjar Vatnsdal Pálsson
———————————–
Signe Stougård Pedersen
Læsevejledning
Rapporten er opbygget således, at den første del af rapporten belyser problemområdet i projektet, mens anden
del af rapporten udgør dokumentationen af det konstruerede system. Rapporten er inddelt i følgende områder:
Problemanalyse, systemanalyse, systemdesign, implementering og test samt diskussion. Der vil desuden være
et appendiks indeholdende uddybninger til rapporten samt et bilag indeholdende de foretagede interviews.
I rapporten er kildehenvisningerne angivet [X], hvor X angiver nummeret på kilden i kildelisten. Ligninger er
angivet i parentes (Y.Z), hvor Y henviser til kapitlet hvori ligningen er angivet, og Z betegner ligningens nummer. Kapitler i appendiks er nummereret med bogstaver, og kildehenvisninger hertil vil ligeledes indeholde
bogstaver. Figurer og tabeller angives med numre uden parentes.
Grunden til, at rapporten er omfattende med hensyn til dokumentationen af systemanalyse og -design, skyldes
studieordningens krav til 6. semester på Sundhedsteknologi, hvor temaet er Design af sundhedsteknologiske systemer. Analysen og designet af det konstruerede system er foretaget efter objektorienteret analyse og design,
hvor der i rapporten er anvendt UML-terminologi til dette, hvilket omfatter et stort antal figurer og tabeller,
hvilket gør rapporten omfattende. Desuden har analysen, designet og implementeringen af det konstruerede
system været en retrospektiv proces, således at f.eks. dele af dokumentationen af systemdesignet i rapporten er
blevet redigeret efter implementeringen, da systemet undervejs har udviklet sig.
Idet rapporten ikke nødvendigvis skal læses i kronologisk rækkefølge og på grund af rapportens omfang, vælges det at inddele læsere af rapporten i forskellige interesseområder, således læser ikke nødvendigvis bør læse
hele rapporten:
- For læseren der udelukkende er interesseret i systemanalyse og -design og ikke vægter den tilgrundliggende
problembaggrund, anbefales det at springe problemanalysen over og gå direkte til systemanalysen i kapitel 3.
- For den klinisk interesserede med interessere for fysiologisk modellering anbefales det at læse problemanalysen samt diskussion og appendiks A og B. Desuden kan kapitel 17 omhandlende konstruktion af patientcases
læses.
- For læseren der allerede er bekendt med utilityteori anbefales det at springe over afsnittet om utilityteori i
kapitel 2.
Der findes en projektcd som dokumentation og tillæg til rapporten. Denne cd indeholder følgende:
En pdf-version af rapporten
En brugermanual til det konstruerede system
En eksekvérbar fil af det konstruerede system.
Dokumentation af kildekoden i form af et javadoc. Javadoc er en del af JavaT M 2 SDK standarden og
giver en oversigt over udviklede klasser i det konstruerede system. Javadoc genererer en html-kode som
output, som indeholder information om klasserne.
INDHOLD
Indhold
Del I - Problemanalyse
1
1 Indledning
1.1 Respiratorbehandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Tilpasning af respiratorindstillinger . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Surrogatmål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
5
2 Problemområde
2.1 Utilityteori . . . . . . . . . . . . . . . . . .
2.1.1 Multiattribut værdiproblem . . . . .
2.1.2 Formalisering af præferencestruktur
2.1.3 Utilityteori i praksis . . . . . . . .
2.2 INVENT . . . . . . . . . . . . . . . . . . .
2.2.1 Simulering . . . . . . . . . . . . .
2.2.2 Optimering . . . . . . . . . . . . .
2.2.3 Penaltyfunktioner . . . . . . . . . .
2.3 Vægtning af penaltyfunktioner . . . . . . .
2.3.1 Problemformulering . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Del II - Systemanalyse
7
7
7
9
10
10
11
12
12
13
14
15
3 Behovsbeskrivelse og strategi
3.1 Behovsbeskrivelse . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Afgrænsninger . . . . . . . . . . . . . . . . . . .
3.1.2 Patientcases . . . . . . . . . . . . . . . . . . . . .
3.1.3 Penaltyfunktioner og simulering af patientvariable
3.1.4 Input til systemet . . . . . . . . . . . . . . . . . .
3.1.5 Plot af fejl . . . . . . . . . . . . . . . . . . . . . .
3.2 Løsningsstrategi . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Kritérier . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Løsningstrin . . . . . . . . . . . . . . . . . . . .
3.2.3 Bland Altmann-plot . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
19
19
19
20
20
21
21
23
4 Usecases
4.1 Tekstuel beskrivelse af funktionalitetskrav
4.1.1 Detaljeret beskrivelse af Dr. Know
4.2 Definition af aktører . . . . . . . . . . . .
4.3 Definition af usecases . . . . . . . . . . .
4.4 Beskrivelse af de enkelte usecases . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
27
27
28
.
.
.
.
.
.
.
.
.
.
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDHOLD
5 Deploymentdiagram
5.1 INVENT vs. Dr. Know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Applikationsområde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
31
6 Aktivitetsdiagrammer
6.1 Inddeling efter stereotyper . .
6.2 Fælles aktiviteter . . . . . . .
6.2.1 Vælg brugertype . . .
6.2.2 Vælg patientgruppe . .
6.2.3 Hjælp . . . . . . . . .
6.2.4 Afslut . . . . . . . . .
6.3 Klinikeraktiviteter . . . . . . .
6.3.1 Skift bruger . . . . . .
6.3.2 Vælg patient . . . . .
6.3.3 Simulér patientvariable
6.3.4 Godkend indstilling . .
6.4 Udvikleraktiviteter . . . . . .
6.4.1 Vælg kliniker . . . . .
6.4.2 Beregn lambda . . . .
6.4.3 Gem lambda . . . . .
6.4.4 Åbn gemt lambda . . .
6.5 Samlet funktionsoversigt . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
34
34
35
36
36
37
37
38
39
40
41
41
42
43
44
45
.
.
.
.
.
47
47
48
49
50
51
8 Klassediagram
8.1 Objektkandidater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Definition af klasser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Klassediagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
53
54
56
Del III - Systemdesign
59
9 Designkriterier
9.1 Vægtning af designkriterier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
61
10 Komponentarkitektur
10.1 Udvidelse af klassediagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Illustration af klynger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Revideret klassediagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
65
68
68
11 GUI-klasser
11.1 LoginVindue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 KlinikerVindue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
71
72
7 Grafiske brugergrænseflader
7.1 Loginvindue . . . . . . .
7.2 Klinikervindue . . . . .
7.3 Udviklervindue . . . . .
7.4 Grafvindue . . . . . . .
7.5 Hjælpvindue . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDHOLD
11.3 UdviklerVindue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4 HjaelpVindue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5 GrafFunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12 Kontrol-klasser
12.1 PatientState . . .
12.2 InitialState . . . .
12.3 Settings . . . . .
12.4 ErrorData . . . .
12.5 Lambda . . . . .
12.6 LambdaPlusError
12.7 Penalties . . . . .
12.8 Kliniker . . . . .
73
73
74
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
75
76
76
76
77
78
78
78
13 Entity-klasser
13.1 Database . . . . . . . . . . . .
13.1.1 Overordnet struktur . .
13.1.2 Klinikerdata . . . . . .
13.1.3 Respiratorindstillinger
13.2 Database-klassen . . . . . . .
13.3 LambdaGem . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
81
82
83
83
84
14 Procesarkitektur
14.1 Sekvensdiagrammer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.2 Klinikerfunktionaliteter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.3 Udviklerfunktionaliteter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
87
87
88
Del IV - Implementering og Test
91
15 Implementeringsstrategi
15.1 Programmeringssprog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.2 Databasesprog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.3 Programmeringsværktøj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
93
93
94
16 Implementering versus design
16.1 Jar-filer . . . . . . . . . .
16.1.1 VisualNumerics . .
16.1.2 ChartDirector . . .
16.2 Implementerede klasser . .
16.2.1 Scattering . . . . .
16.2.2 DemoModule . . .
16.2.3 DatabaseSetup . .
16.3 Klasser fra INVENT . . .
16.3.1 Predictions . . . .
16.3.2 o2model . . . . . .
16.3.3 co2model . . . . .
16.3.4 IO2Constants . . .
16.3.5 Blood . . . . . . .
95
95
95
95
95
96
96
96
97
97
97
97
97
97
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INDHOLD
17 Patientcases
17.1 Strategi for udarbejdelse af patientcases . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.2 Standardværdier for patientcases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
99
99
18 Dokumentation af Dr. Know
103
18.1 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
19 Test
19.1 Typer af tests . . . . . . . . . . . .
19.2 Integrationstest: Test af usecases . .
19.2.1 Vælg brugertype . . . . . .
19.2.2 Vælg patientgruppe . . . . .
19.2.3 Hjælp . . . . . . . . . . . .
19.2.4 Metoder . . . . . . . . . . .
19.2.5 Afslut . . . . . . . . . . . .
19.2.6 Skift bruger . . . . . . . . .
19.2.7 Vælg patientcase . . . . . .
19.2.8 Simulér patientvariable . . .
19.2.9 Godkend indstilling . . . . .
19.2.10 Vælg kliniker . . . . . . . .
19.2.11 Beregn lambda . . . . . . .
19.2.12 Gem lambda . . . . . . . .
19.2.13 Åbn gemt lambda . . . . . .
19.3 Test af DatabaseSetup . . . . . . . .
19.4 Test af systemeffektivitet . . . . . .
19.4.1 Optimering af beregningstid
19.5 Systemtest . . . . . . . . . . . . . .
19.5.1 Brugertype: Kliniker . . . .
19.5.2 Brugertype: Udvikler . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Del V - Diskussion
20 Diskussion
20.1 Vurdering af Dr. Know
20.1.1 Effektivitet . .
20.1.2 Testoutput . . .
20.2 Konklusion . . . . . .
107
107
108
108
109
109
110
110
111
112
113
113
114
115
116
117
118
119
119
120
120
120
123
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21 Perspektivering
21.1 Forbedring og optimering . . . . .
21.1.1 Tidligere login . . . . . .
21.1.2 Tilføjelse af patientgrupper
21.1.3 Gem grafdata . . . . . . .
21.1.4 Online database . . . . . .
21.2 Integrering med INVENT . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
125
125
126
127
.
.
.
.
.
.
129
129
129
130
130
130
131
INDHOLD
Del VI - Appendiks
135
A Fysiologi i INVENT
A.1 Respiratorindstillinger . . .
A.2 Patientparametre . . . . . .
A.3 Patientvariable . . . . . . . .
A.4 Surrogatmål . . . . . . . . .
A.4.1 Barotraume . . . . .
A.4.2 Acidose/alkalose . .
A.4.3 Atelektase . . . . . .
A.4.4 Oxygentoxicitet . . .
A.4.5 Dårlig Oxygenering .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B Modellerne integreret i INVENT
B.1 O2 -modellen . . . . . . . . . . . . . . . .
B.1.1 Ligninger indeholdt i O2 -modellen
B.2 CO2 -modellen . . . . . . . . . . . . . . .
B.2.1 Interstitiel væske og væv . . . . .
B.2.2 Blod . . . . . . . . . . . . . . . .
B.3 Model af lungedynamikken . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
137
137
137
138
139
139
139
140
140
140
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
141
141
141
144
145
145
145
C GUI-elementer samt underliggende funktioner
C.1 LoginVindue . . . . . . . . . . . . . . . .
C.1.1 GUI-elementer . . . . . . . . . . .
C.2 KlinikerVindue . . . . . . . . . . . . . . .
C.2.1 GUI-elementer . . . . . . . . . . .
C.3 UdviklerVindue . . . . . . . . . . . . . . .
C.3.1 GUI-elementer . . . . . . . . . . .
C.4 HjælpVindue . . . . . . . . . . . . . . . .
C.4.1 GUI-elementer . . . . . . . . . . .
C.5 Liste over funktioner . . . . . . . . . . . .
C.5.1 Loginvindue: level 1 funktioner . .
C.5.2 Loginvindue: level 2 funktioner . .
C.5.3 Klinikervindue: level 1 funktioner .
C.5.4 Klinikervindue: level 2 funktioner .
C.5.5 Udviklervindue: level 1 funktioner .
C.5.6 Udviklervindue: level 2 funktioner .
C.5.7 Hjælpvindue: level 1 funktioner . .
C.5.8 Hjælpvindue: level 2 funktioner . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
147
147
147
148
148
151
151
152
152
153
153
154
154
158
159
160
161
161
.
.
.
.
163
163
164
167
168
D Attributter i GUI-klasser
D.1 LoginVindue . . . .
D.2 KlinikerVindue . . .
D.3 UdviklerVindue . . .
D.4 HjaelpVindue . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
E Bilag 1: Interview med Per Thorgaard
171
F Bilag 2: Interview med Steen Andreassen
173
ix
Del I
Problemanalyse
Formålet med denne del af rapporten er at introducere den problemstilling,
der er blevet taget udgangspunkt i.
Kapitel 1 er indledningen til projektet. Her præsenteres kort, hvad der ligger
til grund for projektet.
Kapitel 2 indeholder en videre analyse af problemstillingen. Her uddybes
desuden den teori, som den videre analyse bygger videre på. Afslutningsvis
vil der forefindes en problemformulering.
1
KAPITEL
1
Indledning
I dette kapitel foreligger der en redegørelse for de grundlæggende principper og problemstillinger med hensyn
til respiratorbehandling. Der bliver lagt særlig vægt på problematikken vedrørende respiratorbehandling af
kritisk syge patienter. Formålet med kapitlet er, at give læseren et indblik i de forudsætninger klinikeren har for
at kunne give en patient den mest rationelle respiratorbehandling.
1.1
Respiratorbehandling
Respirationsinsufficiens er forårsaget af manglende evne til at ventilere alveolerne, hvilket er karakteriseret
ved en forhøjet PaCO2 , eller manglende oxygeneringsevne, karakteriseret ved et lavt PaO2 . Behandlingen af
manglende ventilationsevne er som oftest at øge patientens alveolære ventilation, enten ved at reversere den
tilgrundliggende sygdom eller ved at benytte mekanisk ventilation. Behandling af manglende oxygeneringsevne bygger på gendannelse og vedligeholdelse af lungevolumen, og kritisk syge patienter med behov for
hjælp til opretholdelse af respirationen placeres således i en respirator.
Definitionen på en respirator beskriver denne som en maskine, der kan generere et kontrolleret flow af gas ind
i en patients luftveje, hvorved gasudveksling i alveolerne gøres mulig. Gassen er en blanding af atmosfærisk
luft og O2 , der modtages af respiratoren enten fra gasudtag indbygget i patientstuens vægge eller fra ophængte
cylindre på patientstuen. Gastrykket i disse cylindre er for højt til direkte brug i behandlingen af patienten,
så trykket skal sænkes og blandes med atmosfærisk luft i henhold til den foreskrevne inspirerede O2 -fraktion.
Blandingen af gassen vil typisk ske i en beholder inde i respiratoren. [11]
I dag benytter de fleste respiratorer sig af en standardteknik inden for mekanisk ventilation kaldet Continuous
Positive Pressure Ventilation (CPPV). Det centrale præmis for CPPV er, at den indgivne gas har et flow i
den retning som trykgradienten mellem de øvre luftveje og alveolerne foreskriver, hvilket vil sige, at luften
strømmer mod et lavere tryk. [11]
3
Indledning
1.1.1
Tilpasning af respiratorindstillinger
Klinikeren har alene ansvaret for at indstille respiratoren, så den ventilerer patienten på den mest hensigstmæssige måde. Nogle typiske respiratorindstillinger er fraktion af inspireret O2 (FiO2 ), tidalvolumen (Vt),
respirationsfrekvens (f), Positive End Expiratory Pressure (PEEP) samt forholdet mellem inspirationstid og
ekspirationstid (I:E).
I respiratoren eller i eksternt monitoreringsudstyr findes diverse biomedicinske sensorer, der måler specifikke
parametre og variable for den tilkoblede patient, hvilket giver klinikeren et billede af patientens patofysiologiske tilstand. Indstillingen af respiratoren for den enkelte patient sker bl.a. på baggrund af den enkelte klinikers
erfaring og ekspertviden, og herudover har hospitaler verden over udformet guidelines, som kan støtte klinikeren i indstilling af respiratoren. [17]
Tilpasning af respiratorindstillinger til den enkelte patients behov sker typisk på den måde, at klinikeren evaluerer patientens tilstand på stuegang, hvorefter vedkommende indstiller respiratoren med den antagelse, at
patientens tilstand ikke ændrer sig i et 24 timers interval for stabile patienter. Dette er muligt, da de fleste
respiratorer i dag har indbygget en form for autopilot, som er et mode respiratoren kan sættes i. Automode
indstilles f.eks. til, at der skal leveres et vist volumen pr. minut, og hvis patientens behov ændres, kan automode
korrigere for dette. Ved at sætte respiratoren i dette mode, betyder det, at klinikeren ikke selv behøver at tilpasse
respiratorindstillingerne hele tiden. (Se Bilag 1)
Processen vedrørende tilpasning af respiratorindstillinger er illustreret på Figur 1.1. Som det ses af Figur 1.1
:<;!=.> ? ;/@ A@CB
]^_`
b
^a&bc d c
!"$#&%('!%()*"!#+%
"$#&%,-%."/#&%0%/1 !%
2
3-"54%()*6%,*7879
RST U V+W W X YZ [
TU
Y
S+T U W V Z
O-P > =.> QA@CB
\MN?+> A=(?&B
efgh i j i
fk g l
IJAK.L.> @ MN? ;/@CB
D/
(6& (
m.n+o o pq r s
nt
2E "F#&%(G %()%!H!H!!%E1 H
Figur 1.1: En illustration af respiratorbehandlingen samt klinikerens arbejdsproces i korrektionen af respiratorindstillingerne. Der monitoreres nogle udvalgte patientparametre og -variable, som visualiseres for klinikeren. Klinikeren
kan ud fra kliniske guidelines og egen erfaring give en vurdering af patientparametrene og -variable og tilpasse
respiratorindstillingerne, så de tilpasses den enkelte patients behov.
kan processen for tilpasning af respiratorindstillinger betragte som en cyklus, hvor klinikeren er hovedaktøren.
Patientens fysiologiske tilstand visualiseres indirekte på diverse monitorer på patientstuen i form af talværdier
og kurver samt fra diverse blodprøveanalyser. Disse værdier fortolkes af klinikeren, som dernæst bestemmer
4
Indledning
sig for en behandlingstrategi for patienten. Til sidst implementeres denne strategi i form af indstilling af respiratoren.
Ifølge [14] kan en strategi for ventilationen af den kritisk syge patient inddeles i de tre følgende trin:
En vurdering af den enkelte patients patofysiologiske tilstand, på baggrund af patientparametre for følgende tilstande: Gasudveksling, lungemekanisk tilstand, metabolisk tilstand, cirkulation og blodets tilstand.
En vurdering af hvorledes respiratorindstillingerne vil påvirke patientens fysiologiske tilstand, da en ikke
rationel respiratorindstilling vil kunne forværre en patients kritiske tilstand.
Valg af respiratorindstillingerne, som vurderes at være de mest fordelagtige for patienten og som tager
højde for de konsekvenser, der kan følge af respiratorbehandlingen.
Der er foretaget undersøgelser som viser, at patienter ofte føler ubehag og modarbejder respiratoren under den
mekaniske ventilation grundet fejlagtige eller uhensigtsmæssige respiratorindstillinger. Dette fører til udmattelse og eventuelle uønskede kliniske tilstande hos patienten. Dette skyldes, at klinikeren skal søge at finde en
hårfin balance mellem at få ventileret patienten tilstrækkeligt og mindske de gener der påføres patienten. Disse
gener kan eksempelvis opstå i form af, at der gives for meget eller for lidt ilt. Dette har den følgevirkning,
at pH-værdien i blodet bliver enten for høj eller for lav. Denne balancering handler om tradeoff. Det vil sige
at klinikeren, i det førnævnte tilfælde, skal vægte de konsekvenser der opstår ved at give patienten mere eller
mindre ilt. Denne balancering er vanskelig at finde.
1.2
Surrogatmål
Et essentielt begreb i klinikerens vurdering af patientens tilstand og ventilation af den kritisk syge patient er
surrogatmål. Med et surrogatmål menes, at der ikke vælges det klinisk relevante effektmål, men i stedet vælges
et andet effektmål, surrogatmål, som formodes at være en tilstrækkelig god indikator for det kliniske relevante
effektmål. Dette kan være tilladeligt, men kan volde problemer. Et eksempel på dette er i behandlingen af mavesår (ulcus), hvor effektmålet er at helbrede patienterne for deres mavesår. Surrogatmålet er udryddelsen af
helicobactor pylori-bakterien, der er skyld i det fleste tilfælde af mavesår, og udryddelsen af denne bakterie vil
således være en god indikator for at effektmålet, behandlingen af mavesår, opnås. [18] I de tilfælde hvor klinikeren står over for at skulle vurdere multiple surrogatmål og samtidig bibeholde det klinisk relevante effektmål,
vil vedkommende ofte skulle gå på kompromis med et eller flere af surrogatmålene. Ved at prioritere et enkelt
surrogatmål, vil andre surrogatmål ofte blive nedprioriteret. Dette kunne eksempelvis være, at klinikeren i et
tilfælde ville acceptere en højere acidose mod at få en bedre oxygenering.
Problemstillingen for klinikeren er således, hvordan surrogatmålene skal vægtes over for hinanden. Denne
vægtnings- eller tradeoff-problematik, omkring vurdering af multiple surrogatmål og konsekvenserne ved at
prioritere et surrogatmål frem for et andet, kan beskrives teoretisk ved hjælp af utilityteori, hvilket er beskrevet
i det efterfølgende kapitel.
5
KAPITEL
2
Problemområde
I dette kapitel gennemgås problemområdet i projektet, her bliver klinikerens problemstilling i forbindelse med
tradeoffs teoretiseret, og der gives et eksempel på et allerede eksisterende system, der bygger på denne problematik. Afslutningsvis vil der foreligge en problemformulering for projektet. Afsnittet om utilityteori er udarbejdet på baggrund af [8].
2.1
Utilityteori
Utilityteorien finder anvendelse i flere forskellige brancher, eksempelvis medicin og økonomi, hvor vigtige
beslutninger skal tages ud fra givne eller indsamlede data. Essensen af en utilityanalyse er at fastsætte utilityværdier til de konsekvenser, der affødes af et bestemt valg. I en reel problemstilling kan der eksempelvis være
utallige økonomiske, psykologiske og livskvalitetsmæssige forhold (cost and benefit) relateret til det enkelte
valg. Indvirkningen af disse forhold bestemmes ved at associere en konsekvens til ethvert valg. Konsekvensen
beskriver valgets implikation. Det kan eksempelvis være at afgøre, hvordan en beslutning vil påvirke en patients
tilstand.
Efter bestemmelse af disse indvirkninger skal beslutningstageren indkode sine præferencer over for konsekvenserne i form af talværdier, hvor størrelsen af en talværdi vil afbilde graden af indvirkninger og dermed også
præferencen. Bestemmelse af utilityværdier udføres med henblik på at maksimere den forventede utility, som
dernæst bliver det centrale kriterium for den mest fornuftige og rationelle beslutning.
2.1.1
Multiattribut værdiproblem
Såfremt der skal tages højde for flere valg, der indebærer forskellige konsekvenser, opstår et multiattribut værdiproblem. Disse komplekse beslutninger implicerer flere forskellige overvejelser, da det er næsten umuligt at
udpege ét enkelt alternativ, som altid vil være bedst egnet til forskellige effektmål. Det vil sige, at det ikke er
muligt at maksimere multiple mål samtidig. Det er således ikke muligt at maksimere benefits og minimere costs
på en gang. Dette er et spørgsmål om tradeoffs.
7
Problemområde
Systematisk strukturering af ovenstående form for problemstilling er essentielt for forståelsen af utilityteorien.
Essensen er således, at beslutningstagerne ofte støder på problemer med at afveje mellem det ene mål frem for
det andet. I tilfældet af at konsekvenserne for ethvert muligt valg kendes, da bliver problemstillingen således:
Hvor meget udførelse af mål 1 er man villig til at ofre,
for at kunne forbedre udførelsen af mål 2 en vis grad?
Tradeoff-problematikken bliver ofte et individuelt værdispørgsmål, og i nogle tilfælde kræver det beslutningstagerens subjektive opfattelse. Der eksisterer to strategier for besvarelse af dette spørgsmål:
1. Beslutningstageren kan informelt vægte disse tradeoffs.
2. Beslutningstageren kan eksplicit formalisere sin præferencestruktur, som skal bruges til at evaluere alternativerne.
Det vil sige, at beslutningstageren enten kan vælge at udføre en subjektiv tradeoff af de konsekvenser der
eksisterer, eller at beslutningstageren kan formalisere de præferencer vedkommende har og herudfra anvende
dette til at evaluere konsekvenserne af de forskellige handlinger.
Utility-problematik
Lad a være et muligt valg, og lad A være en samling af alle mulige valg. Til enhver handling a i A associeres
n værdier: X1 (a),..., Xn (a). Udtrykkene kan betragtes som evalueringer eller transformationer af handlinger.
X1 ,...,Xn afbilder enhver handling a fra handlingsrummet A over i et n-dimensionelt konsekvensrum som vist
på Figur 2.1. Det skal bemærkes, at hvis x=(x1 , x2 ,...,xn ) er et punkt i konsekvensrummet, da sammenlignes
…-†‡+…/ˆ&‰ ‰ ‰ …-Š
‹Œ7 ‹ †CŽ   ‹ Š
€Ew|z(‚+ƒ(zNwN|N} ~
„
uvxwNyzN{ |z|(} ~
Figur 2.1: Afbilding af a over i konsekvensrummet.[8]
størrelser af xi og x j for i ’ ‘ j ikke, idet attributterne Xi og X j sandsynligvis er målt i forskellige enheder. Det
handler derfor om at vælge den handling a i A, som giver det største payoff X1 (a),..., Xn (a). Sidstnævnte kan
kombineres i en skalár af præferencer eller værdier. Dette kan gøres ved at specificere en skalár-værdi funktion
v defineret i konsekvensrummet med følgende egenskab:
v “ x1 ” x2 ”!•••” xn –˜— v “ x1™ ” x2™ ”!•••” xn™ –
š
“
“
x1 ” x2 ”!•••” xn –œ›
x1™ ” x2™ ”!•••” xn™ –/”
hvor symbolet › betyder ”foretrukket eller ligegyldig”, og hvor v betegnes som en værdifunktion eller en utilityfunktion. Idéen med en utilityfunktion er at kunne vælge a i A, således at v maksimeres. Utilityfunktionen
8
Problemområde
v bruges indirekte til at sammenligne forskellige niveauer af forskellige attributter. Dette gøres ved at sammenligne de effekter, som xi , i=1,...,n, har på utilityfunktionen v.
Af det ovenstående forbliver problemet at kunne strukturere og bestemme utilityfunktionen v. Dette kan simplificeres ved at finde en funktion f med udtrykket:
v “ x1 ” x2 ”!•••” xn –
’
f  v1 “ x1 –/” v2 “ x2 –/”!•••” vn “ xn –ž”
hvor vi er en utilityfunktion for den enkelte attribut Xi .
2.1.2
Formalisering af præferencestruktur
Såfremt der eksisterer adskillige konsekvenser til de valg, der skal træffes, og disse ikke umiddelbart kan vægtes subjektivt, kan det være tilrådeligt at udarbejde en formaliseret præferencestruktur. En måde at repræsentere
konsekvenserne af de valg der træffes, er at benytte en additiv utilityfunktion, også kaldet en additiv værdifunktion.
Additiv værdifunktion
Såfremt der er givet nogle præferenceuafhængige evalueringer eller attributter X1 ,...,Xn af et valg, eksisterer der
en additiv værdifunktion:
n
∑ vi “ xi –/”
’
v “ x1 ” x2 ”!•••” xn –
(2.1)
iŸ 1
hvor vi er en værdifunktion for Xi . I stedet for at benytte sig af ovenstående repræsentation, kan det være mere
praktisk at skalere v og hver attribut værdifunktion fra 0 til 1, således at den additive værdifunktion bliver af
formen:
v “ x1 ” x2 ”!•••” xn –
’
n
∑ λi vi “ xi –/”
(2.2)
iŸ 1
hvor v og vi , i=1,2...,n, i ligning (2.2) er skaleret fra 0 til 1 og
n
∑ λi ’
iŸ 1
1 ” λi
0•
(2.3)
Bestemmelse af en additiv værdifunktion
Det antages, at der skal vælges mellem n alternativer, og at hvert alternativ kan udtrykkes ved hjælp af m attributter. For alternativet Ai eksisterer størrelserne x1i ”!•••” xmi . Der gælder følgende for en additiv værdifunktion:
v j (værst x j ) = 0, v j (bedst x j ) = 1 ” j ’ 1 ”!•••” m;
0 ¡ λj
¡
1, j ’ 1 ”!•••” m
n
∑ λi ’
1.
iŸ 1
9
Problemområde
Her betegner v j den j´te komponent af værdifunktionen v, og λ j er vægten der associeres til attributten X j .
Værdifunktionen v j findes ved at udregne den subjektive middelværdi flere gange i træk. Hvis det antages, at vm
er en middelværdi, skal der gælde, at punkterne (værst x j , vm ) og (vm , bedst x j ) er differentielt værdiækvivalente.
Dette betyder, at man er villig til at ofre lige meget, om man går fra værst x j til vm eller fra vm til bedst x j . λværdierne, hvilke er vægtningerne associeret til den enkelte attribut, bestemmes ud fra værdifunktionerne.
Utilityteori omhandler således bl.a. disse to aspekter:
Utilityfunktionerne samt bestemmelse af disses kurveformer
Vægtningen af utilityfunktionerne og hermed bestemmelse af lambdaværdier
2.1.3
Utilityteori i praksis
Der findes adskillige softwarebaserede systemer, som bygger på utilityteori. Et eksempel på et softwarekonstrueret system er et intelligent respiratorsystem INVENT, der bygger på utilityteori i forbindelse med indstillingen
af respiratorer. INVENT er et beslutningsstøttesystem, der anvender tradeoff-problematikken i de kliniske konsekvenser, der kan opstå i klinikerens indstilling af respiratoren ved en kritisk syg patient.
INVENT har utilityfunktionskurveformer implementeret og har én vægtning af disse utilityfunktioner integreret
for én patientgruppe. INVENT mangler dog en formaliseret præferencestruktur for utilityfunktionerne.
2.2
INVENT
INVENT, som er udviklet på Aalborg Universitet, er et softwarebaseret beslutningsstøttesystem udviklet med
det formål at understøtte klinikeren i at foretage respiratorindstillinger. INVENT bygger på de i indledningen tre nævnte trin (se afsnit 1.1.1 på side 5): Vurdering af patientens patofysiologiske tilstand, forudsigelse af
hvorledes ændringer i respiratorindstillingerne påvirker patientens fysiologiske tilstand, samt valg af respiratorindstillinger til den individuelle patient. [14] På Figur 2.2 ses en overordnet illustration af INVENT. INVENT
er således udviklet til at indgå i processen omkring indstillingen af respiratorer, og på Figur 2.3 på næste side
gives en illustration af, hvorledes INVENT fra udviklerens side er tiltænkt at skulle indgå i processen. For at
Ý5ÖÞ*Ø-Õ ÙCÓEÔCß5ÙÕ ×à*Þ.ÔÕ á á Õ ×â*Ö-ÙÜ
Þ Õ ß5á ß-â5Õ Þ*åÖ
ãä *
ÚÛß*à*Ö-á á Ö*ÙÜ
ÒFÓÔÕ Ö*×.Ôì/Ó/Ù&Õ Ó!í*á Ö$Ü
¤ ϦJÀ<¤ÏпJ¸
µ °J·E¸³JºÑ³J´­!·J¶ ´
¹ °·E¸J³²­!¶ ­!¾Jµ ³
J
§x³J·.ê/¯½$¾µ ¿±
ë ½³J¶ ³Jµ ½$¾µ ¿±
¢F£ ¤7¥-¦!¢*¦E§5¨5¦-£ © ª5¦!«5ª5ª5«
ÒFÓEÔÕ Ö*×.ÔØ/Ó!Ù+Ó!ÚÛÖ.ÔÙÖ$Ü
¬®­J¯E°E±E².³J´¯.µ ¶ ·E¸
¹°·.¸³º»³´­!·¶ ´
¼®³½­!¾E¿/µ ¶ ¯.´½C¶ µ ¯(½­!·E±
ÀÁ¶ ´°Jµ ­½C¶ ¿!·
Ã5µ ¿±J³½¯7½C¶ µ ¯½­!·.±
æç ÙÙß*âFÓÔÚéè/á Ü
¤ÅÄ·.ÆǽC¶ µ ¯(½C ÈÉ´´³µ ¶ ¸»¿ÊËE¸J³·E³J¶ ·E¸
¢/¿!Â̶ ·.±! ³»¾E­! ¿E½C ­!°º»³
¢/¿!Â̶ ·.±! ³Å­½³µ ³´N½­¯³
¢/¿!Â̶ ·.±! ³Å­ÍE¶ ±¿¯³Î­/µ ´­/µ ¿¯³
¢/¿!Â̶ ·.±! ³Å¿ÊË.¸³J·8½¿EÊ.¶ Í.¶ ½³½
Figur 2.2: En illustration af INVENT. Klinikerens foreslåede respiratorindstillinger samt de konstante patientparametre er
input til INVENT. Matematiske modeller over fysiologien for O2 - og CO2 -transporten i blodet samt lungedynamikken er funktioner af førnævnte inputs. Klinikeren kan simulere patientvariable for lungefunktionen og blodet,
der simuleres på baggrund af modellerne og førnævnte inputs. Surrogatmålene kan betragtes som output for INVENT, hvilket er de surrogatmål som ønskes opnået med respiratorbehandlingen af patienten. Modificeret fra
[1]
kunne støtte klinikeren i at foretage respiratorindstillinger gør INVENT som beskrevet brug af utilityfunktioner. I INVENT kaldes de penaltyfunktioner, hvilket er negative utilityfunktioner. Disse penaltyfunktioner er i
10
Problemområde
! "#! $
M N(OPNQ$
îï&ð ñ òóCð ô&ïNõ ïNöFò+ð õ ò-÷ø
ô&ï&ð ñ òóCð ùï(õ ñ ï(úû òü
2 354 6
387 9
:;: 9
÷Nõ þû ïø*ð
òýCþüÿï îï.úÿù Nî î
ò ô ï5ö$
ö ñû
õ ò&þôñ õ ï&ð ÷Nõ ñ óþCð ñ û û ñ óøòõ ü
Z [ \]
^ _ \]
_`a
k
bc [ \]
a
_
^b
g
i j g l mo g f
ii
de f g h k n l
lm h
&DFE
î''î#Dxñ
( ñ DHGI ü 'JDK
ð#DL
-. /0"! $
1#, "$
< =5>
)"*+# ! , ! $
?@A = B >
@
C
%òþôñ õ ïð ÷(õ ñ óþð
ñ û û ñ ó&øòõ ü
R(S T T U V W X
SY
(ñ & ð Nî(''î ü '
Figur 2.3: Illustration af respiratorbehandling samt klinikerens arbejdsproces i tilpasningen af respiratorindstillingerne ved
brugen af INVENT. Der monitoreres nogle udvalgte patientparametre som visiualiseres for klinikeren. Klinikeren
kan ud fra en vurdering af patientparametrene tilpasse respiratorindstillingerne, så de er tilpasset den enkelte patients behov. Til tilpasningen kan klinikeren få støtte ved at simulere patientvariable for patientens lungefunktion
og blodets tilstand. Inden den endelige respiratorindstilling foretages, kan klinikeren sammenholde sin indstilling
med de respiratorindstillinger, som INVENT foreslår for den pågældende patient.
INVENT funktioner for fem definerede kliniske tilstande, der skal undgås, og surrogatmålene bliver således
at skulle undgå dem: Barotraume, acidose/alkolose, atelektase, oxygentoxycitet og dårlig oxygenering. Klinikerens problemstilling i processen omkring indstillingen af respiratorer er som beskrevet at skulle vægte disse
surrogatmål over for hinanden, idet en prioritering af ét surrogatmål vil kunne nedprioritere et andet surrogatmål. Som INVENT er konstrueret nu, skal klinikeren subjektivt foretage denne vægtning, idet INVENT ikke
har nogen formaliseret præferencestruktur for vægtningen af de forskellige kliniske tilstande, som i praksis skal
prioriteres forskelligt, afhængig af hvilken tilstand den kritisk syge patient er i.
INVENT indholder to overordnede funktionaliteter til at kunne støtte klinikeren i indstillingen af respiratorer:
Simulering
Optimering
2.2.1
Simulering
For at kunne vurdere patientens patofysiologiske tilstand har INVENT et sæt patientparametre visualiseret
for klinikeren. Disse patientparametre er parametre for gasudveksling, lungemekanisk tilstand, metabolisk tilstand, cirkulation og blodets tilstand, og udgør patientparametrene: shunt, FA2, Vd, compliance, modstanden
˙ DPG, Hb, COHb, MetHb og temperatur. Disse patientparametre er i INi respirationsvejene, VO2 , VCO2 , Q,
VENT værdier, der monitoreres af andet apparatur, og sættes i INVENT til at være konstante. Dette skyldes, at
de antages at være statiske for patienten, idet en ændret respiratorindstilling ikke vil ændre parameterværdien
markant.
Respiratorindstillingerne i INVENT er FiO2 , Vt, f, PEEP og I:E. INVENT har matematiske modeller for O2 ,
CO2 og lungedynamik integreret (se appendiks B på side 141), som anvendes til at kunne forudsige effekten
11
Problemområde
af at ændre på respiratorindstillingerne. Dette er i INVENT en simulering af patientvariable. Patientvariablene
er således variable, der simuleres på baggrund af respiratorindstillingerne, patientparametre og de matematiske
modeller over fysiologien. Patientvariablene er variabler for lunger og hhv. arterielt og venøst blod og udgør
patientvariablene: FeCO2 , FeO2 , SaO2 , PaO2 , PaCO2 , pHa, BE, SvO2 , PvO2 , PvCO2 , pHv.
2.2.2
Optimering
INVENT er udviklet således, at klinikeren kan optimere respiratorindstillinger og patientvariable, og klinikeren
får hermed INVENTs forslag til, hvilke respiratorindstillinger og patientvariable der findes mest fordelagtige
for patienten. Denne optimering sker i INVENT ved en optimeringsfunktion, hvilket foreslås på baggrund af de
fem integrerede penaltyfunktioner for de fem kliniske tilstande: Barotraume, atelektase, acidose/alkalose, oxygentoksitet og dårlig oxygenering. Optimeringsfunktionen er specificeret til at kunne foreslå de mest rationelle
respiratorindstillinger for en post-operativ CABG-patient1 , dvs. de indstillinger der minimerer de fysiologiske
skadevirkninger og således optimerer denne type patients tilstand. Optimeringsfunktionen i INVENT giver klinikeren de respiratorindstillinger med den laveste samlede penalty for de fem penaltyfunktioner, og klinikeren
får således systemets forslag til de mest fordelagtige respiratorindstillinger.
I det følgende uddybes de penaltyfunktioner, der er integreret i INVENT.
2.2.3
Penaltyfunktioner
I INVENT definerer penaltyfunktionerne de formåede risici, der er forbundet med en bestemt respiratorindstilling eller simuleret variabel for patientgruppen post-operativ CABG. Penaltyfunktioner er funktioner, der beskriver den negative utility og er derved en specialisering af utilityfunktioner.
Hvor der i utilityteorien søges at opnå en høj utility, søges der for penaltyfunktionerne at finde en lav penalty
for de enkelte kliniske tilstande.
Figur 2.4: Penaltyfunktionerne inkluderet i INVENT. Penalty er skaleret op ad ordinaten. (a) Barotraume er plottet som
en funktion af PIP. Der er illustreret penalties for forskellige respirationsfrekvenser hhv. 5, 10, 15, 20, 25, 30.
(b) Atelektase er plottet som en funktion af Vt. (c) Acidose/alkalose er plottet som en funktion af venøs pH
(d) Forringet oxygenering er plottet som en funktion af venøs oxygensaturation. (e) Oxygentoxicitet er plottet
som en funktion af FiO2 , og her er der repræsenteret penalties for varierende timer efter FiO2 -indstillingen er
foretaget. [14]
1 CABG
= Coronary Artery Bypass Grafting
12
Problemområde
Penaltyfunktionerne er produktet af en dialog mellem udvikleren af INVENT og klinikere. Formålet med dialogen er at tilskrive nogle værdier til de forskellige tilstande, som kan karakterisere hvor alvorlige tilstandene
er. Kurverne på Figur 2.4 på forrige side afbilder klinikeres opfattelse af, hvor fejlagtige respiratorindstillinger
er. Kurverne er subjektive, idet de afbilder klinikerens personlige holdning til, hvor kritisk en tilstand er, hvilket
betyder, at penaltykurveformerne ikke er konstruerede ud fra formaliserede data. Dette skyldes, at der findes
mange individuelle fysiske og psykologiske faktorer, som kan have indflydelse på disse kurver. [2]
Eksempelvis ved klinikeren, at det er skadeligt for en patient, hvis SvO2 kommer under 60% og derved skal
der knyttes en høj penalty til denne tilstand. Dog er den risiko patienten løber når iltmætningen er lidt under
60 ikke den samme som hvis den er langt under 60. Resultatet af dialogen mellem udvikleren af INVENT og
klinikeren bliver, at der knyttes nogle penaltyværdier til parameterværdierne. Disse penaltyværdier er klinikerens vurdering af hvor kritisk en tilstand er, samt hvor meget skade tilstanden vil påføre patienten. Herved er
det muligt at knytte en penaltyværdi til den pågældende parameterværdi. Et eksempel på resultatet af en dialog
mellem udviklereren af INVENT og klinikere kan ses i tabel 2.1. Tabellen viser klinikerens vurdering af, hvor
kritiske forskellige iltmætningsniveauer er for patienten. Penaltykurveformerne i INVENT er fundet ved brug
SvO2 (%)
Penalty
0
100
50
5
52
3.6
54
2.2
56
1.4
60
0.6
66
0.18
70
0.05
72
0.02
74
0
80
0
95
0
100
0
Tabel 2.1: Tabellen er et resultat af dialogen mellem udvikler og kliniker. Her er illustreret forskellige niveauer af venøs
iltmætning samt klinikerens forslag til en tilsvarende penalty. Det ses, at en iltmætning på 0% giver den højest
mulige penalty (100), mens en iltmætning på 74% giver den lavest mulige penalty (0), idet klinikeren har vurderet
denne iltmætning til at være tilfredsstillende.
af lineær interpolation ud fra de penaltyværdier klinikeren har oplyst. Lineær interpolation anvendes således
til at finde koordinaterne for penaltykurven for punkterne der ligger mellem de punkter som et opgivet af klinikeren. Idet kurverne repræsenter negative utilties, sigter INVENT mod stabiliseringen af en patient ved at
foreslå den respiratorindstilling som giver den laveste penalty. Dette gøres ved at undersøge gradientretningen
af kurveformerne. INVENT betragter den respiratorindstilling med den laveste total penaltyværdi som den mest
optimale. Til dette formål har INVENT en total penaltyfunktion defineret, der er en additiv værdifunktion, som
er summen af den enkelte penalty for henholdsvis pH, SvO2 , PIP, FiO2 og Vt. Minimeringen af denne funktion
giver den mest optimale respiratorindstilling.
2.3
Vægtning af penaltyfunktioner
Ifølge utilityteori skal der skabes en dialog mellem kliniker og udvikler, hvor beslutningstageren subjektivt
vægter konsekvenserne ved et bestemt valg. En anden mulighed er, at beslutningstageren kan formalisere en
præferencestruktur.
Dette projekt vil fokusere på at udarbejde en matematisk løsning for en formaliseret præferencestruktur. Projektet vil beskæftige sig med at få produceret et softwaresystem, der kan producere en formaliseret præferencestruktur for de allerede udarbejdede penaltyfunktioner i INVENT. Softwaresystemet skal producere forskellige
vægtninger af penaltyfunktionerne ved at indsamle og indirekte registrere klinikeres holdning til, hvordan penalties skal vægtes ved forskellige patientgrupper med forskellige tilgrundliggende sygdomme.
Det tænkes, at INVENT kan kalibreres ved at inkludere formaliserede vægtninger for forskellige patientgrupper,
således at INVENT kan anvendes på flere patienttyper end post-operative CABG-patienter. Disse vægtninger
er de beskrevne lambdaværdier.
13
Problemområde
2.3.1
Problemformulering
Ud fra problemanalysen og med tanke på at skulle konstruere et softwaresystem formuleres følgende problemformulering til projektet:
Hvorledes er det muligt at konstruere et vidensindsamlingssystem, som kan indsamle og formalisere klinikeres subjektíve holdninger til, hvordan respiratorindstillinger indstilles mest fordelagtigt
for en kritisk syg patient, med henblik på en rationel vægtning af penaltyfunktioner?
I resten af rapporten bliver softwaresystemet, der ønskes konstrueret, refereret til som Dr. Know.
14
Del II
Systemanalyse
Formålet med denne del af rapporten er at dokumentere, at der eksisterer et
behov for systemet, samt at udføre en videre analyse af det softwaresystem
der ønskes konstrueret.
Kapitel 3 indeholder en beskrivelse af behovet for softwaresystemet, som udarbejdes i samarbejde med en rekvirent af systemet. Desuden forefindes en
løsningsstrategi.
Kapitel 4 beskriver de funktionaliteter, der er fundet til systemet. Disse beskrives i dette kapitel som usecases.
Kapitel 5 beskriver den fysiske arkitektur af softwaresystemet samt relationen til INVENT og applikationsområdet.
Kapitel 6 indeholder en beskrivelse af de aktiviteter, der forekommer i systemet, i form af aktivitetsdiagrammer.
Kapitel 7 indeholder mock-ups af de forskellige brugergrænseflader, der forventes at eksistere i Dr. Know.
Kapitel 8 indeholder en beskrivelse af de forskellige klasser, der er fundet i
forbindelse med analysen af Dr. Know.
15
KAPITEL
3
Behovsbeskrivelse og strategi
I dette kapitel foreligger en behovsbeskrivelse af Dr. Know, som er udarbejdet på baggrund af dialog med
en potentiel rekvirent og brugere af Dr. Know. Behovsbeskrivelsen indeholder hvilke krav og herunder hvilke
begrænsninger, der sættes til Dr. Know. Efterfølgende foreligger en løsningsstrategi for Dr. Know.
3.1
Behovsbeskrivelse
Behovsbeskrivelsen er udarbejdet på baggrund af samtaler med en potentiel rekvirent af Dr. Know samt nogle
klinikere, der er potentielle brugere af systemet. Der er i beskrivelsen anvendt uddrag fra referater, og disse er
således ikke direkte citeret af kilden. Udvikleren ønsker at få konstrueret et system, der kan producere forskellige vægtninger tilsvarende forskellige patienttyper. Ud fra dialog med en udvikler og klinikere og efterfølgende
overvejelser er det muligt at opstille visse rammer for Dr. Know.
3.1.1
Afgrænsninger
Efterfølgende er der beskrevet en række afgrænsninger til Dr. Know. Det drejer sig om afgrænsninger i de
patientgrupper, respiratorindstillinger og penaltyfunktioner, der ønskes anvendt.
Patientgrupper
Antallet at patientgrupper, der skal produceres vægtninger for, sættes til tre, hvilket vurderes at være et passende
antal at arbejde ud fra. I dialogen med udvikleren argumenteres der for at skulle vægte penalties for forskellige
patientgrupper:
”Argumentet for at vægte penalties forskelligt til forskellige patientgrupper er, at penalties gør
forskellig ”ondt” på forskellige patientgrupper. Patientgrupperne har underliggende forskellige
organproblemer, og det er derfor forskellige organer, man ønsker at skåne hos patienten.” (se
Bilag 2)
17
p
Behovsbeskrivelse og strategi
Patientgrupperne post-operative hjertepatienter, hjernetraumepatienter og intensivpatienter vælges ud fra den
overvejelse, at der ligger forskellige organproblemer til grund for, at respiratorbehandling er nødvendig, og at
det derfor forventes, at respiratorindstillingerne er væsentlig forskellige for de tre patientgrupper. Patienterne
vil alle være intensiv patienter, i den forstand at de alle er under respiratorbehandling. Patientgruppeinddelingen
udgør udelukkende en inddeling i den primære årsag til at patienten er intensivpatient.
Hjernetraumepatienter karakteriseres som patienter, derenten har været udsat for åbent kraniebrud, hvor
dele af hjernen beskadiges, eller også kan der være tale om et lukket kranietraume, hvor hjernen stødes mod
kraniet eller rystes. Dette kan føre til blødninger i selve hjernevævet eller uden for hjernen, der kan trykke
på hjernen og beskadige den. Patienten observeres for forhøjet tryk i hjernen og desuden skal der forsøges
at opretholde et normalt CO2 -niveau i hjernen. For patientgruppen hjernetraume kan patienten f.eks. have et
velfungerende hjerte, og hjertet vil derfor kunne tåle at blive belastet gennem længere tid og ved for dårlig
oxygenering kunne respondere ved at arbejde hårdere.
Postoperative patienter karakteriseres som enhver patient, der har undergået en hjerteoperation, med efterfølgende behov for respiratorbehandling. For post-operative hjertepatienter vil patienten typisk have et svækket
hjerte, hvor de andre organer derimod kan være velfungerende og derfor tåle at blive belastet hårdere end hjertet.
Intensivpatienter karakteriseres som almen intensivpatienter med respirationsproblemer, herunder ikke patienter med ARDS 1 og KOL idet disse patienter beskrives ud fra lungedynamik modellen, som ikke er implementeret fuldkomment i INVENT. Disse patienter er karakteriseret ved et højt shunt og et stort deadspace. En
patient med en kollapset lunge vil således have en højere shunt, mens en patient med lungeødem vil have et
større deadspace. Ved intensivpatienter med lungefunktionsproblemer vil andre organer, såsom hjertet, kunne
tåle at blive belastet hårdere for at opnå tilstrækkelig gasudveksling, så organerne iltes tilstrækkeligt.
Det er således de underliggende organproblemer, der skal være afgørende for vægtningen af penalties for forskellige kritiske tilstande, hvilke forventes at være forskellige for de valgte patientgrupper.
Respiratorindstillinger
INVENT indeholder fem respiratorindstillinger: FiO2 , Vt, f, PEEP og I:E. I Dr. Know ønsker udvikleren, at
der kun skal fokuseres på de tre respiratorindstillinger FiO2 , Vt og f. Dette skyldes, at respiratorindstillingerne
PEEP og I:E på nuværende tidspunkt ikke anvendes i INVENT, på grund af at de fysiologiske modeller for
disse er knap så anvendelige, og det er ikke en del af projektet at udarbejde modeller for PEEP og I:E (Se Bilag
2). Til dette kommenterer udvikleren:
”Det er ikke en realistisk simulering at udelade PEEP og I:E, idet PEEP stort set altid anvendes
i praksis, men ved at fastholde PEEP og I:E kan de andre værdier/indstillinger observeres.” (se
Bilag 2)
Penaltyfunktioner
Som beskrevet indeholder INVENT fem penaltyfunktioner for henholdsvis barotraume, acidose/alkalose, oxygentoxicitet, dårlig oxygenering og atelektase, der alle beskriver en kritisk klinisk tilstand hos patienten. I
1 Acute
Respiratory Distress Syndrome
18
Behovsbeskrivelse og strategi
INVENT er den integrerede lungedynamikmodel for atelektase ikke opdateret, hvilket ifølge udvikleren skyldes:
”Atelektase, som den er integreret i INVENT nu, er en funktion af tidalvolumen. Den bygger på en
ældre forståelse af lungedynamikken, hvilken er ringere end forståelsen nu.” (se Bilag 2)
I Dr. Know foretages der derfor den afgrænsning, at penaltyfunktionen for atelektase ikke medtages, og der
anvendes derfor kun de fire resterende penaltyfunktioner.
3.1.2
Patientcases
Til at kunne producere en vægtning for hver af penaltyfunktionerne i hver af de tre definerede patientgrupper foreslår udvikleren, at der skal udarbejdes et bestemt antal patientcases. En patientcase skal indeholde på
forhånd definerede patientparametre, da disse som beskrevet er statiske i INVENT. De på forhånd definerede
patientparametre og en indtastning af de tre respiratorindstillinger indgår i en simulering, og give et output i
form af patientvariable. Udvikleren ønsker, at patientparametrene skal udarbejdes som værende realistiske for
kritisk syge patienter, og ikke med tanke på at patienten f.eks. er post-operativ hjertepatient. Det vurderes, at
20 patientcases er tilstrækkeligt for hver patientgruppe.
3.1.3
Penaltyfunktioner og simulering af patientvariable
Formålet med udviklingen af Dr. Know er som beskrevet at producere forskellige vægtninger af de fire penaltyfunktioner for hver af de tre udvalgte patientgrupper. Til at simulere patientvariablene vil der derfor blive
anvendt fysiologiske modeller til simulering fra INVENT, idet formålet med Dr. Know ikke er at kunne reproducere disse. Penaltyfunktionerne i INVENT vil ligeledes blive anvendt.
3.1.4
Input til systemet
Klinikere, som i det daglige foretager respiratorindstillinger for de respektive patientgrupper, skal komme med
input til Dr. Know, hvilke kan producere de ønskede vægtninger. I det eksisterende INVENT kan brugeren af
systemet se patientparametre for henholdsvis gasudveksling, cirkulation, lungedynamik, metabolisme og blod,
som klinikeren skal foretage respiratorindstillingerne ud fra.
I en dialog med en kliniker er vedkommende blevet præsenteret for muligheden for, at kunne se de enkelte
patientparametrene inddelt efter de ovennævnte undergrupperinger af patientparametre, og adspurgt hvorledes
dette vil have indflydelse på klinikerens vurdering af patientens tilstand.
Klinikeren fortæller, at der i praksis kun er adgang til et fåtal af alle de patientparametre som klinikeren er
blevet præsenteret for; nogle er online, nogle kan fås med mellemrum, mens andre sjældent er tilgængelige. I
den sammenhæng giver klinikeren udtryk for, at det at kunne se alle patientparametrene vil kunne understøtte
klinikeren bedre i respiratorindstillingen. (Se Bilag 1) Ud fra dialogen med klinikeren er det besluttet, at klinikeren skal kunne se samtlige patientparametre, som også er visualiseret i INVENT, samt konsekvensen af de
respiratorindstillinger, der foretages. Det vil kunne understøtte klinikeren i vurderingen af patienttilstanden og
således støtte klinikeren i at foretage den bedste respiratorindstilling.
Klinikeren skal ud fra patientgruppe og patientparametre give en vurdering af patientens tilstand og på baggrund
heraf kunne indstille respiratoren og simulere patientvariable, og ud fra patientvariable vurdere om respiratorindstillingen er acceptabel.
19
p
Behovsbeskrivelse og strategi
Information om/til klinikeren
Udvikleren ønsker at kunne få information om den kliniker, der har givet input til Dr. Know, idet klinikere
har forskellig erfaring og ekspertviden, som danner grundlag for indstilling af en respirator. Der skal dog ikke
udarbejdes statistik over klinikeroplysningerne.
”Det kunne være interessant at få information om klinikeren, men statistikken er ikke nødvendigvis
så interessant.... ” (se Bilag 2)
Det vurderes, at den information, som klinikeren skal give systemet, er fornavn, efternavn, afdeling, anciennitet
og stillingsbetegnelse, og der skal således være en oprettelse af klinikeren i systemet.
3.1.5
Plot af fejl
Udvikleren ønsker at kunne få illustreret, hvor god overensstemmelse der er mellem Dr. Knows forslag til
respiratorindstillinger og klinikerens forslag til respiratorindstillinger. Der gives således udtryk for et ønske om
at få visualiseret, hvor godt et fit systemet har, dvs. hvor god en tilpasning Dr. Know har opnået til klinikerens
respiratorindstillinger. Dette ønskes gjort for hver af de tre valgte respiratorindstillinger FiO2 , Vt og f.
3.2
Løsningsstrategi
Der udarbejdes her en løsningsstrategi for Dr. Know, herunder hvordan lambdaværdierne beregnes samt hvorledes udvikleren skal få illustreret, hvor godt et fit Dr. Know har. Utilityteorien (2.1) anvendes til udarbejdelse
af løsningsstrategien.
Der defineres et handlingsrum H, hvori der findes forskellige kombinationsvalg; i dette tilfælde respiratorindstillinger for FiO2 , Vt og f. Eksempelvis vil en manipulation med indstillingen for FiO2 resultere i en evaluering
af denne handling, h1 , og der gives således fire præferenceuafhængige konsekvenser af handlingen h1 i konsekvensrummet. Følgende er værdifunktionerne for de kliniske tilstande illustreret:
v1 = vFiO2 “ h1 – = oxygentoxicitet
v2 = vSvO2 “ h1 – = dårlig oxygenering
v3 = vPIP “ h1 – = barotraume
v4 = v pH “ h1 – = acidose/alkalose
For at formalisere en præferencestruktur for konsekvenserne af handlingerne, anvendes en additiv værdifunktion kaldet total penaltyfunktion v, som er givet ved:
v “ v1 ” v2 ” v3 ” v4 –
4
∑ vi “ h1 –
’
(3.1)
iŸ 1
Det vælges at skalere v og de fire penaltyfunktioner fra 0 til 1, hvilket betyder at ligning (3.1) kan omskrives til
v “ v1 ” v2 ” v3 ” v4 –
’
4
∑ λi vi “ h1 –
iŸ 1
”
(3.2)
hvor λi er vægten associeret til penaltyfunktionen vi . Det gælder endvidere at:
4
∑ λi ’
iŸ 1
20
1
(3.3)
Behovsbeskrivelse og strategi
3.2.1
Kritérier
Summen af de fire lambdaværdier skal altid give 1, og en lambdaværdi kan ikke antage værdien 0 eller 1. Dette
hænger sammen med, at en penaltyfunktion aldrig kan udelades, hvilket vil sige at den altid vil have et bidrag
til den totale penaltyfunktion v i ligning ( 3.1 på forrige side). Hvis en lambdaværdi f.eks. er 1, udelukkes de
tre andre, idet deres lambdaværdi således er 0, hvilket ikke må ske. Det besluttes derfor, at værdien af lambda
kan være minimum 0,1 og maximum 0,7. Det antages således, at en ændring i en respiratorindstilling altid vil
påvirke enhver patient i de definerede patientgrupper på en måde, som kan beskrives af alle fire penaltyfunktioner.
Normalisering af penaltyfunktioner
De fire penaltyfunktioner skal normaliseres, så de alle har en værdimængde mellem 0 og 1. Grunden til dette
er, at det herved er muligt at sammenligne penaltyfunktionernes output, hvilket vil sige at en penalty på 0,5
svarer til det samme for alle fire penaltyfunktioner. På Figur 3.1 ses de fire penaltyfunktioner normaliseret, så
penalty for den enkelte penaltyfunktionen er skaleret til at ligge mellem 0 og 1. Normaliseringen er udført ved
at dividere hver funktion med den penaltyværdi, klinikeren vurderer at være den værste.
Figur 3.1: De normaliserede penaltyfunktioner er her illustreret, der således hver især er skaleret til at have en værdimængde
mellem 0 og 1, så de kan sammenlignes.
3.2.2
Løsningstrin
Følgende to trin indgår i løsningsstrategien til Dr. Know:
21
p
Behovsbeskrivelse og strategi
Bestemmelse af respiratorindstillinger.
Bestemmelse af lambdaværdier.
Bestemmelse af respiratorindstillinger
I bestemmelsen af lambdaværdierne er det nødvendigt at finde de respiratorindstillinger, som Dr. Know vurderer
som værende de mest fordelagtige for hver patientcase. Disse respiratorindstillinger findes på baggrund af de
matematiske modeller og penaltyfunktionerne fra INVENT, der således giver Dr. Knows forslag til de mest
fordelagtige respiratorindstillinger for patientcasen.
Fremgangsmåden til at finde de mest fordelagtige respiratorindstillinger er at gennemløbe alle mulige kombinationer af FiO2 , Vt og f igennem. Til hver kombination af FiO2 , Vt og f beregnes en total penalty, og kombinationen med den mindste totale penalty (se ligning (3.1)) betragtes således som værende den mest rationelle
respiratorindstilling. Denne kombination af respiratorindstillinger betegnes som Dr. Knows forslag.
For de tre respiratorindstillinger FiO2 , Vt og f skal det først bestemmes, i hvilke intervaller der skal findes
mulige kombinationer mellem dem, da antallet af kombinationer ellers er uendeligt. På baggrund af dialog med
en kliniker og dennes demonstration af en respirator (se Bilag 1) er det bestemt, at respiratorindstillingerne skal
løbe i følgende intervaller:
FiO2
Vt
f
0,21 - 1,00 [frak.]
0,3 - 1,2 [l]
5 - 30 [/min]
De fire penaltyfunktioner er funktioner af henholdsvis PIP, pHv, FiO2 og SvO2 , hvor PIP, pHv og SvO2 er
patientvariable. Til at finde Dr. Knows forslag til respiratorindstillinger simuleres alle patientvariable, hvor PIP,
pHv og SvO2 udvælges for at kunne finde penalties for de tre respiratorindstillinger. Herefter findes penalty for
hver af de fire penaltyfunktioner, der adderet giver den totale penalty. Den respiratorindstillingskombination
med den laveste totale penalty er således Dr. Knows forslag.
Følgende pseudokode illustrerer fremgangsmåden for hver patientcase:
Kør for patientcase.
•!•!• Kør fra FiO2 lig med 0,21 til 1.
•!•!•/•!•!• Kør fra Vt lig med 0,3 til 1,2.
•!•!•/•!•!•*•!•!• Kør fra f lig med 5 til 30.
•!•!•/•!•!•*•!•!•
•!•!•/•!•!•*•!•!•
•!•!•/•!•!•*•!•!•
•!•!•/•!•!•*•!•!•
•!•!•/•!•!•*•!•!•
•!•!•/•!•!•*•!•!•
Simulér patientvariable og udvælg Sv02 , PIP og pHv.
Find penalty v1 (FiO2 ) for oxygentoxicitet.
Find penalty v2 (SvO2 ) for dårlig oxygenering.
Find penalty v3 (PIP) for barotraume.
Find penalty v4 (pHv) for acidose/alkalose.
Find den totale penalty v = v1 + v2 + v3 + v4 .
f-loop slutter her.
•!•!•/•!•!• Vt-loop slutter her.
•!•!• FiO2 -loop slutter her.
Slut for denne patientcase.
Præsentér den kombination af respiratorindstillinger med den laveste totale penalty.
•!•!•/•!•!•*•!•!•
22
Behovsbeskrivelse og strategi
Bestemmelse af lambdaværdier
Den totale penaltyfunktion i Dr. Know vil have følgende udseende:
v “ v1 ” v2 ” v3 ” v4 –
’
λFiO2 q v1 r λSvO2 q v2 r λPIP q v3 r λ pH q v4 ”
(3.4)
hvor λFiO2 , λSvO2 , λPIP og λ pH er de lambdaværdier, som skal bestemmes. Værdien af den totale penaltyfunktion
skal udregnes for hver lambdakombination, hvilket vil sige alle mulige kombinationer af lambda skal løbes
igennem. Dén lambdakombination, som giver den laveste værdi af den totale penaltyfunktion, er den optimale
lambdakombination for netop ét sæt respiratorindstillinger.
Dernæst handler det om at finde ud af, hvor meget Dr. Knows forslag til respiratorindstillingerne afviger fra
klinikerens forslag. Dette gøres ved brug af metoden Least Square Error. Denne metode udregner den totale
error som summen af error for de tre respiratorindstillinger som illustreret følgende:
TotalError ’
“
KnowFiO2 s KlinikFiO2 –
“ KlinikFiO2 – 2
2
“
r
KnowVt s KlinikVt –
“ KlinikV t – 2
2
“
r
Know f s Klinik f –
“ Klinik f – 2
2
”
(3.5)
hvor eksempelvis KnowFiO2 og KlinikFiO2 svarer til henholdsvis Dr. Knows forslag og klinikerens forslag til en
optimal respiratorindstilling for FiO2 . Ligning (3.5) giver et indblik i, hvor god overensstemmelse der er mellem
Dr. Knows forslag og klinikerens forslag. Lambdakombinationen der resulterer i den laveste totale error vælges
som vægtning og er således Dr. Knows output.
Ovenstående fremgangsmåde kan systematiseres og udtrykkes i form af følgende pseudokode:
Kør for λFiO2 lig med 0.1 til 0.7.
•!•!• Kør for λSvO2 lig med 0.1 til (0.8 - λFiO2 ).
•!•!•/•!•!• Kør for λPIP = 0.1 til (0.9 - λSvO2 ).
•!•!•/•!•!•/•!•!• λ pHv = (1 - λFiO2 - λSvO2 - λPIP ).
•!•!•/•!•!•/•!•!•
•!•!•/•!•!•/•!•!•
•!•!•/•!•!•/•!•!•
•!•!•/•!•!•/•!•!•
•!•!•/•!•!•/•!•!•
•!•!•/•!•!•/•!•!•
Kør kombinationer af respiratorindstillinger for FiO2 , Vt og f.
Se forrige pseudokode for bestemmelsen af respiratorindstillinger.
Vælg de respiratorindstillinger med den laveste penalty.
Udregn error på FiO2 , Vt og f for alle patientcases.
Udregn total error.
Gem kombinationerne.
λPIP -loop slutter her.
λ
•!•!•
SvO2 -loop slutter her.
λFiO2 -loop slutter her.
Kombinationen med den laveste totale error bliver til vægtning og således Dr. Knows
output.
•!•!•/•!•!•
3.2.3
Bland Altmann-plot
Udvikleren ønsker at kunne få illustreret, hvor tæt overensstemmelse der er mellem systemets forslag og klinikerens forslag til respiratorindstillingerne. Det vælges, at dette skal gøres ved hjælp af et Bland Altmann-plot.
Dette plot foretages for hver af de tre respiratorindstillinger, da det vurderes at være lettest at fortolke for
udvikleren.
23
p
Behovsbeskrivelse og strategi
Et Bland Altmann-plot har på x-aksen gennemsnitsværdien af henholdsvis Dr. Knows og klinikerens forslag til
en respiratorindstilling, hvilket giver den tætteste approximering til en reel værdi for en respiratorindstilling.
På y-aksen haves differensen mellem systemets og klinikerens forslag, dvs. error. Plottet mellem disse vil
ideelt skulle ligge på nul, idet der således ikke er nogen forskel mellem Dr. Knows og klinikerens forslag
til respiratorindstillingerne. På denne type plot vil udvikleren kunne få illustreret, hvorvidt de producerede
vægtninger er anvendelige eller ej.
24
KAPITEL
4
Usecases
Formålet med kapitlet er at identificere usecases i Dr. Know, hermed hvilke funktionaliteter Dr. Know skal
indeholde. Usecases skal kunne anvendes til at verificere, at Dr. Know kommer til at fungere, som brugerne
ønsker det. Udarbejdelsen af usecases foretages på baggrund af behovsbeskrivelsen og strategien. Der gives
først en tekstuel beskrivelse af Dr. Know og efterfølgende en identificering af usecases samt Dr. Knows aktører.
4.1
Tekstuel beskrivelse af funktionalitetskrav
Ud fra behovsbeskrivelsen udarbejdes den tekstuelle beskrivelse af Dr. Know, som beskriver hvilke krav og
overordnede funktionaliter systemet skal indeholde. Der skal være to brugere af Dr. Know: Klinikeren og
udvikleren. Med udvikleren menes en potentiel rekvirent af Dr. Know, en rekvirent der har været med til at
udvikle INVENT. Klinikeren skal give input til Dr. Know i form af sin kliniske erfaring, mens udvikleren skal
bruge outputtet fra Dr. Know. Kravene til hvilke funktionaliteter Dr. Know skal indeholde inddeles derfor i en
beskrivelse af funktionaliterne for henholdsvis klinikeren og udvikleren.
Klinikeren
Klinikeren skal indtaste oplysninger omkring sin kliniske baggrund, hvilke er fornavn, efternavn, afdeling, stilling og anciennitet.
Klinikeren skal kunne vælge mellem de tre patientgrupper: post-operative hjertepatienter, hjernetraumepatienter og intensivpatienter.
Klinikeren skal kunne vælge mellem de 20 opstillede patientcases.
Hver patientcase skal indeholde følgende konstante patientparametre: shunt, FA2, Vd, Q, compliance,
modstanden i respirationsvejene, VO2 , VCO2 , DPG, Hb, COHb, MetHb og temperatur og BE, og hver
patientcase skal indeholde en allerede foreslået respiratorindstilling med tilhørende simulerede patientvariable. Disse parametre, er de samme som der bliver visualiseret i INVENT, se evt. 2.2.1 på side 11
25
Usecases
Klinikeren skal kunne indtaste nye respiratorindstillinger for hhv. respirationsfrekvens (f), tidalvolumen
(Vt) og inspireret oxygenfraktion (FiO2 ).
Dr. Know skal kunne simulere patientvariable ud fra de indtastede respiratorindstillinger, hvilke er:
FeCO2 , FeO2 , SaO2 , PaO2 , PaCO2 , pHa, SvO2 , PvO2 , PvCO2 , pHv, PIP. Klinikeren skal herefter kunne
gentage og/eller godkende respiratorindstillingen, der automatisk skal gemmes ved godkendelse.
Patientparametre og patientvariable skal præsenteres overskueligt for klinikeren
Klinikeren skal kunne skifte bruger, såfremt der er en anden kliniker eller en udvikler, der ønsker at
anvende Dr. Know.
Udvikleren
Udvikleren ønsker ikke, at Dr. Know implementeres i INVENT, men forventer, at outputtet fra Dr. Know
kan anvendes i INVENT.
Der skal kunne vælges mellem de tre patientgrupper: post-operative hjertepatienter, hjernetraumepatienter og intensivpatienter.
Udvikleren skal kunne beregne vægtninger for penaltyfunktionerne for hver af de tre patientgrupper.
Udvikleren skal kunne vælge at få beregnet vægtninger for enten én af klinikerne eller alle klinikere
inden for den valgte patientgruppe.
De beregnede vægtninger for hver af penaltyfunktionerne samt et plot af afvigelsen mellem systemets og
klinikerens forslag for hver af respiratorindstillingerne skal visualiseres.
For at udvikleren skal kunne anvende de beregnede vægtninger fra Dr. Know i INVENT, skal de beregnede vægtninger kunne gemmes, og tidligere beregnede vægtninger skal kunne hentes frem.
4.1.1
Detaljeret beskrivelse af Dr. Know
Når en bruger skal anvende Dr. Know, skal brugeren i et loginvindue vælge brugertype af systemet, hvilket
er kliniker eller udvikler. Der skal samtidigt være mulighed for at få information om Dr. Know, herunder
vejledning og hjælp til brugen af systemet for både klinikeren og udvikleren. Begge brugere skal desuden
under deres anvendelse af Dr. Know på ethvert tidspunkt kunne få hjælp og vejledning til brugen af systemet.
Vælges brugertypen ”Kliniker”, skal klinikeren i samme loginvindue indtaste specifikke oplysninger om sig
selv, hvilke er fornavn, efternavn, afdeling, stilling og anciennitet. Dr. Know skal kontrollere, at klinikeren
får alle oplysninger indtastet, ellers skal klinikeren ikke kunne fortsætte. Når oplysningerne er indtastet og
godkendt af klinikeren, får vedkommende et nyt vindue præsenteret, betegnet klinikervindue. Klinikervinduet
skal indeholde information om, hvilken kliniker der er i færd med at anvende systemet samt give klinikeren
mulighed for at vælge mellem de foruddefinerede patientgrupper og patientcases. Når klinikeren vælger én af
patientgrupperne, præsenteres patientcase nr. 1 automatisk, hvorefter der frit kan vælges en anden patientcase.
For den enkelte patientcase visualiseres et sæt konstante patientparametrene samt systemets forslag til en respiratorindstilling med tilhørende simulerede patientvariable. Med udgangspunkt i patienttype, patientparametrene og simulerede patientvariable skal klinikeren på baggrund af sin kliniske erfaring og ekspertviden vurdere
og indtaste nye respiratorindstillinger for patienten. Når respiratorindstillingerne er indtastet, kan klinikeren simulere nye patientvariable, som visualiseres, hvilket klinikeren kan gentage, indtil patientens tilstand vurderes
at være mest hensigtsmæssig. Når klinikeren finder de simulerede variable tilfredsstillende, skal klinikeren godkende respiratorindstillingerne. Dette forløb gentages for hver patientcase. Klinikeren kan skifte bruger uden at
skulle afslutte systemet.
26
Usecases
Vælges brugertypen ”Udvikler”, vil udvikleren efter accept af dette få et nyt vindue præsenteret, betegnet
udviklervindue. I udviklervinduet skal udvikleren først vælge, hvilken patientgruppe der skal beregnes vægtninger for. Herefter skal udvikleren vælge, om der skal beregnes vægtninger på baggrund af én klinikers eller
alle klinikeres respiratorindstillinger. Udvikleren skal kun have de klinikere præsenteret, der har indtastet respiratorindstillinger for alle 20 patientcases i den valgte patientgruppe.
Udvikleren kan vælge at få beregnet vægtninger for den valgte patientgruppe. Mens beregningen udføres skal
dette visualiseres. Når beregningen er udført, visualiseres vægtningerne automatisk for udvikleren, én for hver
af de fire penalties. For hver af de tre respiratorindstillinger plottes et plot af fejlene for respiratorindstillingerne,
der visualiserer for udvikleren, hvor anvendelige de beregnede vægtninger er. Udvikleren skal kunne lagre de
beregnede vægtninger og patientgruppenavnet, der er beregnet for, og udvikleren skal desuden kunne hente
tidligere beregnede vægtninger frem. Udvikleren skal til enhver tid kunne afslutte brugen af Dr. Know.
4.2
Definition af aktører
I udarbejdelsen af usecasediagrammet skal aktørerne i Dr. Know identificeres, idet en usecase altid initieres af
en aktør. En aktør kan defineres som noget eksternt, der interagerer med systemet, hvilket både kan være de
personer, der anvender systemet, eller et andet system, der kommunikerer med Dr. Know. [6]
Aktørerne i Dr. Know identificeres til at være:
Klinikeren
Udvikleren
Klinikeren defineres som aktør, idet klinikeren skal give input til Dr. Know, og udvikleren identificeres som
aktør, idet udvikleren skal kunne tilgå det output, systemet har. Outputtet består således af vægtningerne for
penaltyfunktionerne, som udvikleren beregner på baggrund af klinikerens respiratorindstillinger. Vægtningerne
af penaltyfunktionerne vil herefter også blive betegnet lambdaværdier.
4.3
Definition af usecases
En usecase repræsenterer en funktionalitet for en aktør. Ifølge UML-terminologi kan en usecase defineres som
en samling af handlinger, som et system udfører for at bidrage til et specifikt mål. Dette kan være kommunikation med de forskellige aktører, udførelse af beregninger, og handlinger der foregår inde i systemet. [6]
Ud fra den tekstuelle beskrivelse af Dr. Know er følgende usecases identificeret:
Vælg brugertype
Vælg patientgruppe
Hjælp
Afslut
Skift bruger
Vælg patientcase
Simulér patientvariable
Godkend indstilling
Vælg kliniker
27
Usecases
Beregn lambda
Gem lambda
Åbn gemt lambda
Ud fra denne identificering af usecases er et samlet usecasediagram konstrueret, hvilket er illustreret på Figur 4.1. Usecasediagrammet er en samling af alle usecases i Dr. Know og giver et overblik over systemets
samlede funktionalitet samt hvilken aktør der kan initiere den givne usecase.
Figur 4.1: Usecase-diagrammet illustrerer de forskellige usecases, der eksisterer i Dr. Know. Her ses de 12 forskellige
usecases: ”Vælg brugertype”, ”Vælg patientgruppe”, ”Hjælp”, ”Afslut”, ”Vælg kliniker”, ”Beregn lambda”,
”Gem lambda”, ”Åbn gemt lambda”, ”Skift bruger”, ”Vælg patientcase”, ”Simuler patientvariable” og ”Godkend indstilling”.
4.4
Beskrivelse af de enkelte usecases
Beskrivelsen af de enkelte usecases indeholder en specifikation af, hvorledes aktør og usecas interagerer. Usecasebeskrivelsen koncentrerer sig udelukkende om den eksterne funktionalitet og beskriver ikke, hvorledes funktionen udføres internt i Dr. Know.
28
Usecases
Vælg brugertype
Denne usecase initieres, når Dr. Know startes, og kan derfor initieres af begge aktører, hvilke er de to brugere
af systemet. Brugeren skal i et loginvindue vælge, om han er kliniker eller udvikler. Hvis brugertypen ”Kliniker” vælges, skal brugeren desuden efterfølgende indtaste specifikke oplysninger om klinikeren i loginvinduet.
Usecasen termineres for begge brugere ved accept af brugertypeindstillinger.
Vælg patientgruppe
Denne usecase giver brugeren mulighed for at vælge, hvilken patientgruppe vedkommende vil beskæftige sig
med. Usecasen kan både initieres af klinikeren og udvikleren. Usecasen initialiseres ved, at brugeren vælger
én af de tre patientgrupper ud fra en visualiseret liste. For klinikeren vises patientcase nr. 1 inden for denne
patientgruppe automatisk. For udvikleren vil de klinikere, der har indtastet respiratorindstillingerne for den
valgte patientgruppe, blive tilgængelige. For begge brugere terminerer usecasen ved valg af patientgruppe.
Hjælp
Formålet med denne usecase er, at brugeren kan få hjælp til og information om Dr. Know. Usecasen initieres
ved, at brugeren vælger at se Hjælp-funktionens indhold, og termineres ved, at brugeren lukker vinduet. Både
klinikeren og udvikleren har mulighed for at initiere denne usecase.
Afslut
Formålet med denne usecase er, at brugeren kan afslutte at køre Dr. Know. Usecasen initieres ved, at brugeren
vælger at afslutte programmet. Brugeren kan i dette tilfælde både være kliniker og udvikler. Hvis klinikeren vil
afslutte, skal Dr. Know spørge klinikeren, om de indtastede respiratorindstillinger er godkendte. Hvis udvikleren vil afslutte, skal Dr. Know spørge udvikleren, om de beregnede lambdaværdier er gemt.
Skift bruger
Det skal være muligt for brugertypen kliniker at kunne skifte bruger uden at afslutte Dr. Know, idet flere
forskellige klinikere skal anvende systemet. Usecasen initieres ved, at klinikeren i klinikervinduet vælger at
skifte bruger, hvorefter nye brugerindstillinger i login-vinduet kan foretages. Usecasen terminerer, når ”Vælg
brugertype”-usecasen initieres.
Vælg patientcase
Denne usecase gør det muligt for klinikeren at vælge mellem de 20 opstillede patientcases integreret i Dr. Know.
Når en patientgruppe er valgt, vises patientcase nr. 1 automatisk, hvorved denne usecase giver klinikeren mulighed for at springe til en anden patientcase. Usecasen initieres ved, at klinikeren vælger et patientcasenummer
fra en liste, og termineres, når den valgte patientcase vises.
29
Usecases
Simulér patientvariable
Formålet med denne usecase er, at få et input til Dr. Know fra klinikeren. Usecasen initieres ved, at klinikeren vælger at simulere patientvariable ud fra indtastede respiratorindstillinger, og usecasen afsluttes efter endt
simulering, hvorefter de simulerede patientvariable vises for klinikeren.
Godkend indstilling
Formålet med denne usecase er, at få lagret de indtastede respiratorindstillinger. Denne usecase initieres ved, at
klinikeren godkender de indtastede respiratorindstillinger og terminerer, når data er gemt.
Vælg kliniker
Udvikleren skal kunne vælge mellem de klinikere, der har godkendt respiratorindstillinger for alle patientcases
i den allerede valgte patientgruppe, og desuden skal de klinikere, der ikke har givet indstillinger for den valgte
patientgruppe, ikke vises. Hvis udvikleren vil beregne lambdaværdier for alle klinikere, der har godkendt respiratorindstillinger i den valgte patientgruppe, skal denne mulighed også kunne vælges. Usecasen initieres af
udvikleren ved, at han vælger en enkelt kliniker eller alle klinikere ud fra en liste, hvorefter usecasen termineres.
Beregn lambdaværdier
Denne usecase giver udvikleren mulighed for at initiere en beregning af lambdaværdierne. Usecasen initieres
ved, at udvikleren vælger at starte en beregning. Det skal illustreres for udvikleren, når Dr. Know foretager en
beregning samt når beregningen er fuldendt. Hvis beregningen af lambdaværdierne ikke lykkes, skal udvikleren
informeres om dette. Når beregningen af lambdaværdierne er fuldendt, vises lambdaværdierne for udvikleren
automatisk, og usecasen termineres herefter.
Gem lambdaværdier
Formålet med denne usecase er, at udvikleren kan lagre de beregnede lambdaværdier, så de kan implementeres
i INVENT. Usecasen initieres ved, at udvikleren vælger at gemme lambdaværdierne, hvorefter lagringsdestination vælges, og usecasen terminerer, når udvikleren informeres om, at lambdaværdierne er lagret.
Åbn gemt lambda
Formålet med denne usecase er, at udvikleren skal kunne hente tidligere gemte lambdaværdier frem. Usecasen initieres ved, at udvikleren vælger at åbne en gemt lambdaberegning og termineres, idet lambdaværdier
visualiseres.
30
KAPITEL
5
Deploymentdiagram
I dette kapitel foreligger en beskrivelse af den fysiske arkitektur af Dr. Know, samt en beskrivelse af applikationsområdet. Formålet med dette, er at illustrere tilhørsforholdet mellem Dr. Know og INVENT.
5.1
INVENT vs. Dr. Know
Relationen mellem INVENT og Dr. Know kan illustreres ved brug af et deploymentdiagram[6]. Et deploymentdiagram afbilder runtimearkitekturen af et system, eksekveringsmiljøer, samt de komponenter der er indeholdt
i arkitekturen. Herved beskrives hardwarestrukturen samt det software der eksekveres under hver enhed.
Dr. Know anvender dele af INVENT i form af kildekode for de fysiologiske modeller. Dette indikerer at INVENT er en del af Dr. Know-arkitekturen, men understreger også at dette er den eneste relation mellem to
systemer set ud fra et softwaresynspunkt. Således bliver der en skarp skillelinie mellem softwaren i Dr. Know
og softwaren i INVENT. På Figur 5.1 på næste side er deploymentdiagrammet for Dr. Know illustreret.
5.2
Applikationsområde
Applikationsområdet kan defineres som den kontekst, hvori Dr. Know skal implementeres og anvendes. Dr.
Know skal anvendes af to brugertyper, som er henholdsvis udvikleren og klinikeren. Udvikleren er rekvirent
af Dr. Know, og denne brugertype skal bruge outputtet fra Dr. Know, dvs. vægtningen af penaltyfunktionerne.
Kliniker er betegnelsen for den bruger, der giver input til Dr. Know, ved at indtaste respiratorindstillinger til de
forskellige patientgrupper.
Der eksisterer to brugere af Dr. Know: Klinikeren som er en bruger af systemet og udvikleren, der er den egentlige rekvirent af Dr. Know. Det er herved muligt at inddele applikationsområdet i et primært og et sekundært
applikationsområde.
Den kontekst hvor udvikleren vælger at implementere Dr. Know, i INVENT, betegnes som det primære applikationsområde. Dette skyldes, at problemområdet, som er vægtningen af penaltyfunktionerne, skal anvendes i
31
Deploymentdiagram
ttvuwxFy zw|{v{
}F~
€5‚vƒ„
…†
” •v–H—v•v˜
‡vˆ‰Š‹
Œ Ž
’FˆŠ ˆ“
vŠ(‘  Ž
Figur 5.1: Deploymentdiagrammet illustrerer det hardware og software som Dr. Know består af. Det yderste element kaldes
for en node, og repræsenterer et fysisk stykke hardware med beregningsegenskaber eller processorkraft. Den PC
som Dr. Know kører på vil derfor være en node. De to komponenter repræsenterer henholdsvis kildekoden for
Dr. Know og dele af INVENT. De tre stereotyper som findes i Dr. Know: Boundary, control og entity er ligeledes
visualiseret.
INVENT. Det sekundære applikationsområde er den kontekst, det vælges at implementere Dr. Know i, således
klinikeren har mulighed for at give input til systemet. Dette være sig eksempelvis på afdelingen eller på en
privat computer.
32
KAPITEL
6
Aktivitetsdiagrammer
Dette afsnit indeholder aktivitetsdiagrammer som beskriver de definerede usecases. Aktivitetsdiagrammet er et
dynamisk diagram der beskriver et sekventielt flow af de processer der forekommer i hver enkelt usecase. Det
primære formål med konstruktionen af aktivitetsdiagrammer er, at få defineret de funktioner der ligger bag den
enkelte usecase.
6.1
Inddeling efter stereotyper
En af fordelene ved at anvende aktivitetsdiagrammer er, at de forskellige processer der forløber, kan placeres
i såkaldte aktivitets partitioner. Aktivitets partitionerne grupperer processerne efter, hvor samt hvem der er
ansvarlig for at processen eksekveres. [6]
Der findes tre stereotyper som anvendes til inddeling efter hvor en given proces foregår. I det efterfølgende
beskrives funktionaliteten af de tre stereotyper [6]:
1. Boundary anvendes til at kommunikere og præsentere information i ét system til et andet. Dette andet
system kan enten være en human-bruger af systemet eller en maskine.
2. Entity anvendes til at lagre information fra systemet. De er herved persisterende.
3. Control er en stereotype der ofte anvendes til at forbinde boundary objekter med entity objekter samt
til at håndtere en sekvens af operationer i systemet. Control klassen anvendes således til at håndtere en
enkelt eller få usecases.
I de efterfølgende aktivitetsdiagrammer for usecasene i Dr. Know anvendes følgende to aktivitets partitioner:
Boundary og control. Denne inddeling gør det muligt at analysere og realisere usecasene mere detaljeret. At
udelukkende disse to inddelinger forekommer, skyldes at det i aktivitetediagrammerne endnu ikke er muligt at
fastsætte om en given proces forløber i entity eller control.
I de efterfølgende afsnit vil der være en frase fra usecasebeskrivelsen som understreger hvorfor den pågældende
aktivitet er vigtig for Dr. Knows rekvirenter og brugere.
Efter hvert aktivitetsdiagram findes en definition af de funktioner der kan findes ud fra usecasen. Eksisterer den
samme funktion i flere aktivitetsdiagrammer, er dette illustreret med en *.
33
Aktivitetsdiagrammer
6.2
Fælles aktiviteter
I følgende afsnit beskrives usecases som begge brugertyper benytter. Det drejer sig om ”Vælg brugertype”,
”Vælg patientgruppe”, ”Hjælp” og ”Afslut”.
6.2.1
Vælg brugertype
Under usecasebeskrivelsen, er det fundet, at de kommende brugere ønsker at kunne skelne mellem hvilken
brugertype der skal anvende systemet. Dette kan understreges af følgende ønske:
”Når en bruger skal anvende Dr. Know, skal brugeren i et loginvindue vælge brugertype. Her
eksisterer der to muligheder: Kliniker eller udvikler.”
Figur 6.1: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Vælg brugertype” illustreres.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Vælg brugertype”, er det muligt at definere følgende funktioner:
34
Aktivitetsdiagrammer
Navn
kontrollerTypeBruger*
startKlinikerVindue
startUdviklerVindue
kontrollerOplysninger
hentOplysninger
6.2.2
Beskrivelse
Undersøger hvilken bruger der er valgt
Starter kliniker sessionen
Starter udvikler sessionen
Tjekker om kliniker har udfyldt oplysninger
Henter oplysninger om kliniker og gemmer dem
Type
Control
Control
Control
Control
Control
Vælg patientgruppe
Der er fundet i usecasebeskrivelsen at både klinikeren og udvikleren ønsker at kunne vælge at arbejde med de
tre forskellige patientgrupper: postoperativ hjertepatient, intensiv patient og hjernetraumepatient. For klinikeren
er der udtrykt ønske om følgende:
”Klinikeren skal kunne vælge mellem de tre patientgrupper: Post-operative hjertepatienter, hjernetraumepatienter og intensivpatienter.”
For udvikleren er der udtrykt ønske om følgende:
”Udvikleren skal kunne vælge mellem de tre patientgrupper: post-operative hjertepatienter, hjernetraumepatienter og intensivpatienter. Udvikleren skal kunne beregne vægtninger for penaltyfunktionerne for hver af de tre patientgrupper.”
Figur 6.2: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Vælg patientgruppe” illustreres.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Vælg patientgruppe”, er det muligt at
definere følgende funktioner:
35
Aktivitetsdiagrammer
Navn
kontrollerTypeBruger*
hentPatientgrupper
visPatientgrupper
indlæsPatientcase
hentKlinikerListe
6.2.3
Beskrivelse
Undersøger hvilken bruger der er valgt
Henter en liste med patientgrupper
Viser listen med patientgrupper
Henter og viser 1. patientcase
Henter liste med klinikere
Type
Control
Control
Boundary
Control
Control
Hjælp
For at lette brugen af Dr. Know, skal begge brugertyper have mulighed for, at kunne få information omkring
brugen af systemet. Dette er udtrykt således i usecasebeskrivelsen:
”Der skal samtidigt være mulighed for at få information om Dr. Know, herunder vejledning og
hjælp til brugen af systemet for både klinikeren og udvikleren.”
Figur 6.3: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Hjælp” illustreres.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Hjælp”, er det muligt at definere følgende
funktioner:
Navn
kontrollerTypeBruger*
hentHjælp
visHjælp
6.2.4
Beskrivelse
Undersøger hvilken bruger der er valgt
Henter hjælpfilen
Viser hjælpfilen
Type
Control
Control
Boundary
Afslut
Begge brugertyper skal have mulighed for at terminere Dr. Know på et vilkårligt tidspunkt i programmet.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Afslut”, er det muligt at definere følgende
funktioner:
36
Aktivitetsdiagrammer
Figur 6.4: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Afslut” illustreres. Aktivitetsdiagrammet for denne
usecase er kun illustreret for når klinikern aktiverer afslut.
Navn
kontrollerDataGemt*
gemData*
afslutProgram
6.3
Beskrivelse
Undersøger om der findes data som ikke er gemt
Gemmer data som ikke er gemt
Lukker programmet Dr. Know
Type
Control
Control
Control
Klinikeraktiviteter
I afsnittet bliver usecases for klinikeren gennemgået. Det drejer sig om følgende usecases: ”Skift bruger”,
”Vælg patientcase”, ”Simuler patientvariable” og ”Godkend indstilling”.
6.3.1
Skift bruger
Fra klinikerens del af systemet skal der være mulighed for at skifte til en anden bruger af systemet. Både såfremt
en anden kliniker ønsker at anvendes systemet, eller hvis en udvikler ønsker at beregne lambda-værdier. Dette
er udtrykt således i usecasebeskrivelsen:
”Klinikeren kan skifte bruger uden at skulle afslutte systemet.”
Definerede funktioner:
følgende funktioner:
Ud fra aktivitetsdiagrammet for usecasen, ”Skift bruger”, er det muligt at definere
37
Aktivitetsdiagrammer
Figur 6.5: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Skift bruger” illustreres.
Navn
kontrollerDataGemt*
gemData*
afslutSession
startNySession
6.3.2
Beskrivelse
Undersøger om der findes data som ikke er gemt
Gemmer data som ikke er gemt
Afslutter den nuværende session
Starter loginvinduet
Type
Control
Control
Control
Control
Vælg patient
Der skal være mulighed for at klinikeren kan vælge hvilken patientgruppe samt hvilken patient denne ønsker at
indstaste respiratorindstillinger for. Dette ønske kommer til udtryk således:
”Klinikeren skal kunne vælge mellem de tre patientgrupper: post-operative hjertepatienter, hjernetraumepatienter og intensivpatienter. Klinikeren skal kunne vælge mellem de 20 fiktive patientcases.”
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Vælg patient”, er det muligt at definere
følgende funktioner:
38
Aktivitetsdiagrammer
Figur 6.6: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Vælg Patient” illustreres.
Navn
hentPatientOplysninger
indlæsPatientdata
visPatientdata
6.3.3
Beskrivelse
Henter patientnummer og patientgruppe
Indlæser gemt patientdata
Visualiserer patientdata
Type
Boundary
Control
Boundary
Simulér patientvariable
Klinikeren præsenteres for patientparametrene og for at kunne vurdere om de valgte respiratorindstillinger er
hensigtsmæssige for den enkelte patient, skal der være mulighed for at simulere hvorledes patientvariablene vil
være for netop disse respiratorindstillinger. Dette er udtrykt således i usecasebeskrivelsen:
”Hver patientcase skal indeholde følgende konstante patientparametre: shunt, FA2, Vd, Q, compliance, modstanden i respirationsvejene, VO2 , VCO2 , DPG, Hb, COHb, MetHb og temperatur, og
hver patientcase skal indeholde en allerede foreslået respiratorindstilling med tilhørende simulerede patientvariable.”
Figur 6.7: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Simuler patientvariable” illustreres.
39
Aktivitetsdiagrammer
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Simuler respirator”, er det muligt at definere følgende funktioner:
Navn
hentKlinikerIndstilling*
kontrollerIndstilling*
indlæsParametre
udregnVariable
visVariable
6.3.4
Beskrivelse
Henter klinikerens respiratorindstilling
Undersøger om alle felter er udfyldte
Indlæser gemte patientparametre
Udregner patientvariable
Visualiserer udregnede patientvariable
Type
Boundary
Control
Control
Control
Boundary
Godkend indstilling
Når klinikeren har fundet de mest hensigtsmæssige respiratorindstillinger for den udvalgte patient, skal indstillingerne kunne godkendes. Dette ønske er beskrevet således i usecasebeskrivelsen:
”Klinikeren skal kunne indtaste nye respiratorindstillinger for hhv. respirationsfrekvens, tidalvolumen og inspireret oxygenfraktion. Klinikeren skal herefter kunne gentage og/eller godkende respiratorindstillingen, der automatisk skal gemmes ved godkendelse.”
Figur 6.8: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Godkend indstilling” illustreres.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Godkend indstilling”, er det muligt at
definere følgende funktioner:
Navn
hentKlinikerIndstilling*
kontrollerIndstilling*
gemIndstilling
Beskrivelse
Henter klinikerens respiratorindstilling
Undersøger om alle felter er udfyldte
Gemmer klinikerens respiratorindstilling
40
Type
Boundary
Control
Control
Aktivitetsdiagrammer
6.4
Udvikleraktiviteter
I dette afsnit gennemgås aktivitetsdiagrammerne for usecases for udvikleren. Det drejer sig om følgende usecases: ”Vælg kliniker”, ”Beregn lambda”, ”Gem lambda” og ”Åben gemt lambda”.
6.4.1
Vælg kliniker
For at udvikleren kan få et indblik i hvorledes klinikerens erfaring har indflydelse på indstillingen af respiratoren, er der givet udtryk om at udvikleren kan søge på en specifik kliniker. Dette er udtrykt således i usecasebeskrivelsen:
”Udvikleren skal kunne vælge at få beregnet vægtninger for enten én af klinikerne eller alle klinikere inden for den valgte patientgruppe.”
Figur 6.9: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Vælg kliniker” illustreres.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Vælg kliniker”, er det muligt at definere
følgende funktioner:
Navn
indlæsKliniker
visKliniker
kontrollerKliniker*
Beskrivelse
Finder de klinikere som har anvendt Dr. Know
Viser de klinikere der er fundet i Dr. Know
Undersøger om kliniker har gemt data
41
Type
Control
Boundary
Control
Aktivitetsdiagrammer
6.4.2
Beregn lambda
Udvikleren skal have mulighed for at kunne beregne lambda-værdier. Dette er formuleret således i usecasebeskrivelsen:
”Udvikleren kan vælge at få beregnet vægtninger for den valgte patientgruppe. Mens beregningen
udføres, skal dette visualiseres. Når beregningen er udført, visualiseres vægtningerne automatisk
for udvikleren, én for hver af de fire penalties.”
At der skal være indtastet respiratorindstillinger for mindst 20 patienter i en patientgruppe, skyldes at værdien
af den beregnede lambda skal være pålidelig. Det er derfor vurderet at 20 patientcases er nok for at opfylde
dette krav.
Figur 6.10: Aktivitetsdiagram hvor det sekventielle flow i usecasen ”Beregn lambda” illustreres. Denne usecase er illustreret
for beregningen af lambda-værdier for én specifik kliniker.
42
Aktivitetsdiagrammer
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Beregn lambda”, er det muligt at definere
følgende funktioner:
Navn
kontrollerKliniker*
indlæsKlinikerData
beregnLambda
visStatus
visLambda*
6.4.3
Beskrivelse
Undersøger om kliniker har gemt data
Indlæser klinikerens respiratorindstillinger
Beregner lambdaværdier for klinikeren
Viser status for udregningen af lambda
Visualiserer de udregnede lambdaværdier
Type
Control
Control
Control
Boundary
Boundary
Gem lambda
Efter udvikleren har beregnet lambdaværdier, skal der være mulighed for at gemme de beregnede værdier. Dette
er formuleret således i usecasebeskrivelsen:
”Udvikleren skal kunne lagre de beregnede vægtninger og patientgruppenavnet, der er beregnet
for... ”
Figur 6.11: Aktivitetsdiagram for usecasen ”Gem Lambda”.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Gem lambda”, er det muligt at definere
følgende funktioner:
Navn
kontrollerLambda
åbenGemFil
hentLambda
gemLambda
Beskrivelse
Undersøger om der er udregnet lambdaværdier
Åbner en filbrowser hvor filnavn angives
Henter lambdaværdierne
Gemmer Lambdaværdier i den angivede fil
43
Type
Control
Control
Boundary
Control
Aktivitetsdiagrammer
6.4.4
Åbn gemt lambda
For at udvikleren skal kunne anvende de beregnede lambdaværdier i INVENT, skal der være mulighed for at
hente de gemte lambda-værdier frem igen. Dette er udtrykt således:
”....udvikleren skal desuden kunne hente tidligere beregnede vægtninger frem.”
Figur 6.12: Aktivitetsdiagram for usecasen ”Åbn Gemt Lambda”.
Definerede funktioner: Ud fra aktivitetsdiagrammet for usecasen, ”Åbn gemt lambda”, er det muligt at definere følgende funktioner:
Navn
åbenFil
kontrollerFilnavn
kontrollerFilformat
indlæsFil
visLambda*
Beskrivelse
Åbner en filbrowser
Undersøger om filnavn eksisterer
Undersøger om filformatet er korrekt
Indlæser filen med gemte lambdaværdier
Visualiserer de udregnede lambdaværdier
44
Type
Control
Control
Control
Control
Boundary
Aktivitetsdiagrammer
6.5
Samlet funktionsoversigt
I de efterfølgende figurer, vil der være en samlet oversigt over alle de definerede funktioner i Dr. Know.
™š
›œ
¤Ÿ¥v¦
8§ ›
Ÿv¨ ¥Ÿ
žŸ Ÿ¡ž ¢£Ÿ
¦¡œž0 ¡v¨ ¨ Ÿ ©¢£ŸF¤J 8ª|«Ÿv ¬
±¿œ|°Ÿv ¥À«Ÿv µ›§ ¨ ¦ŸvœÂ¦
¨ § œ§ ¦Ÿv F°Ÿv FŸv ›
š¨ «ž
¾²¡œ
ž8 ¡¨
¥ž5šv ž­J¨ § œ§ ¦Ÿv ®¯§ œ|°ªŸ
žšv žŸv ¦
¨ § œ§ ¦Ÿv ¥|Ÿ¥|¥v§ ¡vœ|Ÿvœ
¾²¡œ
ž8 ¡¨
¥ž5šv ž±°|›§ ¦
¨ Ÿv ®²§ œ|°ª|Ÿ
žšv žŸv ª|°›§ ¦
¨ Ÿ ¥|Ÿ¥¥§ ¡œ|Ÿvœ
¾²¡œ
ž8 ¡¨
¦¡œž0 ¡v¨ ¨ Ÿ 8³´£¨ ¢
¥vœ§ œ«Ÿ ©Ä Ÿv¦
¦Ÿ ¡¹Ì¦
¨ § œ§ ¦Ÿv ŸœÂµ|šv ª°» ¢¨ °žFšv¨ ¨ Ÿ´¡£v¨ ¢
¥vœ§ œ|«Ÿv 8œ|Ÿ
¾²¡œ
ž8 ¡¨
µ|Ÿvœ
ž8³´£¨ ¢¥œv§ œ|«Ÿv ÁŸœž5Ÿv F¡v£¨ ¢¥œv§ œ|«Ÿv F¡v¹Ì¦
¨ § œv§ ¦Ÿ ¡«Í«vŸ¹Â¹´Ÿv F°Ÿv¹
¾²¡œ
ž8 ¡¨
¦¡œž0 ¡v¨ ¨ Ÿ ©¢£ŸF¤J 8ª|«Ÿv ¬
±¿œ|°Ÿv ¥À«Ÿv µ›§ ¨ ¦ŸvœÂÁ 8ª|«Ÿv F°vŸ Ÿ ›
šv¨ «ž
¾²¡œ
ž8 ¡¨
µ|Ÿvœ
ž¼šž8§ Ÿvœ
ž5« 0ªv££|Ÿv ÁŸœž5Ÿv FŸvœÂ¨ § ¥žŸÂ¹´Ÿ|°Ç£|šž8§ Ÿœž5« 0ªv££|Ÿv ¾²¡œ
ž8 ¡¨
›§ ¥F¼Hšž0§ Ÿœ
ž« 8ª£v£|Ÿ ®¯§ ¥|Ÿv ¨ § ¥ž5ŸvœÂ¹´Ÿ|°Ç£|šž8§ Ÿvœ
ž5« 8ª££|Ÿv ¤¡vªœ|°vš ¢
§ œ°¨ šŸ|¥¼Hš
ž8§ Ÿvœ
žË|š¥Ÿ
ÁŸœž5Ÿv F¡«´›§ ¥Ÿv ÉÈÊ£š
ž8§ Ÿvœ
žË|š¥Ÿ
¾²¡œ
ž8 ¡¨
¦¡œž0 ¡v¨ ¨ Ÿ ©¢£ŸF¤J 8ª|«Ÿv ¬
±¿œ|°Ÿv ¥À«Ÿv µ›§ ¨ ¦ŸvœÂÁ 8ª|«Ÿv F°vŸ Ÿ ›
šv¨ «ž
¾²¡œ
ž8 ¡¨
µ|Ÿvœ
žÃFÄ Åƨ £
ÁŸœž5Ÿv µ(Ä Åƨ £|»5§ ¨ Ÿvœ
¾²¡œ
ž8 ¡¨
›§ ¥FÃFÄ Åƨ £
®¯§ ¥|Ÿv µ#Ä Åƨ £|»8§ ¨ Ÿœ
¤¡vªœ|°vš ¢
¦¡œž0 ¡v¨ ¨ Ÿ ¶šž5šv·¸Ÿv¹¸ž¬
±¿œ|°Ÿv ¥À«Ÿv F¡v¹Î°Ÿv F»5§ œ|°Ÿ¥´°šžš´¥|¡v¹Ï§ ¦
¦Ÿ´Ÿv F«Ÿv¹Ðž
¾²¡œ
ž8 ¡¨
«Ÿv¹º¶š
žš|¬
·¸Ÿ¹Â¹´Ÿv F°šžš´¥|¡v¹Ì§ ¦
¦Ÿ´šv¨ ¨ Ÿv Ÿ°Ÿ´Ÿv F«Ÿv¹Ðž
¾²¡œ
ž8 ¡¨
š»¥¨ ª
ž¼½ ¡« š¹
Òª¦
¦Ÿv ɶ¿ Ê­Jœ|¡Ó
¾²¡œ
ž8 ¡¨
¦¡œž0 ¡v¨ ¨ Ÿ ¶šž5šv·¸Ÿv¹¸ž¬
±¿œ|°Ÿv ¥À«Ÿv F¡v¹Î°Ÿv F»5§ œ|°Ÿ¥´°šžš´¥|¡v¹Ï§ ¦
¦Ÿ´Ÿv F«Ÿv¹Ðž
¾²¡œ
ž8 ¡¨
«Ÿv¹º¶š
žš|¬
·¸Ÿ¹Â¹´Ÿv F°šžš´¥|¡v¹Ì§ ¦
¦Ÿ´Ÿv F«Ÿv¹Ðž
¾²¡œ
ž8 ¡¨
š»¥¨ ª
ž8ÉŸ¥¥§ ¡œ
ѯ» ¥¨ ª
ž žŸv F°ŸvœÂœª›ÅÆ Ÿœ|°vŸ´¥|Ÿ¥¥§ ¡œ
¾²¡œ
ž8 ¡¨
¥ž5šv ž™½¢ÉŸ¥|¥v§ ¡vœ
žšv žŸv ¨ ¡|«§ œ›§ œ|°ª|Ÿž
¾²¡œ
ž8 ¡¨
µ|Ÿvœ
ž¼šž8§ Ÿvœ
ž0³Ö£¨ ¢¥œ§ œ|«Ÿv ÁŸœž5Ÿv £|šž8§ Ÿvœ
ž0œvª¹Â¹´Ÿ ¡|«Ç£|šž8§ Ÿœž5« 0ªv££|Ÿ
¤¡vªœ|°vš ¢
§ œ°¨ šŸ|¥¼Hš
ž8§ Ÿvœ
ž°šž5š
Ô œ°¨ ÅÕ¥Ÿ «Ÿv¹Ðž£|šž0§ Ÿœ
ž°šž5š
¾²¡œ
ž8 ¡¨
›§ ¥F¼Hšž0§ Ÿœ
ž°šž5š
®¯§ ¥ªš¨ § ¥Ÿ Ÿv £|šž8§ Ÿvœ
ž5°vš
žš
¤¡vªœ|°vš ¢
µ|Ÿvœ
ž­½¨ § œ§ ¦Ÿ Ô œ|°¥ž0§ ¨ ¨ § œ|«¬
ÁŸœž5Ÿv ¦
¨ § œ§ ¦Ÿ Ÿvœ|¥Â Ÿ|¥v£§ š
ž¡ 8§ œ|°¥ž0§ ¨ ¨ § œ|«
¤¡vªœ|°vš ¢
¦¡œž0 ¡v¨ ¨ Ÿ Ô œ|°¥ž0§ ¨ ¨ § œ|«
±¿œ|°Ÿv ¥À«Ÿv F¡v¹Îšv¨ ¨ ŸÖ»Ÿ¨ ž5Ÿv FŸv Hª|°» ¢¨ °žŸ
¾²¡œ
ž8 ¡¨
§ œ°¨ šŸ|¥¼Hš šv¹´Ÿ
ž8 Ÿ
Ô œ°¨ ÅÕ¥Ÿ «Ÿv¹Ðž5ŸÂ£š
ž8§ Ÿvœ
ž8£|š šv¹´Ÿ
ž8 Ÿ
¾²¡œ
ž8 ¡¨
ª|° Ÿ«œ®×šv 0§ šÁv¨ Ÿ
±° Ÿ|«œ|Ÿ H£|šž0§ Ÿœž ›š 8§ švÁ¨ Ÿ
¾²¡œ
ž8 ¡¨
›§ ¥®×šv 0§ šÁv¨ Ÿ
®¯§ ¥ªš¨ § ¥Ÿ Ÿv F°ŸØª|° Ÿ«œ|Ÿ°ŸÂ£|šž0§ Ÿœž ›š 8§ švÁ¨ Ÿ
¤¡vªœ|°vš ¢
Figur 6.13: Oversigt over alle de funktioner der er defineret ud fra usecasene. Fortsættes i tabel 6.14 på næste side.
45
Aktivitetsdiagrammer
فÚÛÜ
äßåæ
à8ç Û
ßvè åß
ÝÞßvà5ßáÞ âã|ß
|ßvÜ
ÞìJè ç Üvç æßvàü Ü|évå
Þ8ç è è ç Üïó
ßvÜ
ÞßàHæ
è ç Üç æßvàßÜåÂàß|åvãç àÚÞáà8ç ÜéåÞ0ç è è ç Ü|ï
äávòÜ|évÚà â
æávÜ
Þ8àáè è ßvàü Ü|évå
Þ8ç è è ç Üï
ù¿ÜéßàåvúFïvßàáñûÚè è ß´ö ßè Þ5ßvàFßvàòéö âè éÞß
ô²áÜ
Þ8àávè
ïßvñºü Ü|éåÞ0ç è è ç Ü|ï
¸ßvñÂñ´ßàHæ
è ç Üç æßvàßÜåÂàß|åvãç à5ÚÞáà8ç ÜéåÞ0ç è è ç Ü|ï
ô²áÜ
Þ8àávè
ÿç Ü|évßàéßÂæ
è ç Üç æßàß´åáñ|ÚvàFÚvÜÛ
ßvÜ|éÞÉí¿àìJÜ|á÷
ô²áÜ
Þ8àávè
æávÜ
Þ8àáè è ßvàìJè ç Üç æßàó
ù¿ÜéßàåvúFïvßàáñÌæ
è ç Üvç æßvà|ÚvàïßñÐÞFévÚ
ÞÚ
ô²áÜ
Þ8àávè
ç Ü|éè êëåFìJè ç Üç æßvàíÚ
ÞÚ
ü Ü|éè êÕå|ßvàHà5ßåvãç àÚÞ5ávà8ç Ü|évå
Þ8ç è è ç ÜïßvàFöávàæ
è ç Üç æßà
ô²áÜ
Þ8àávè
î|ßvàßïÜFð
ÚvñÂî|éÚ
äHßvà5ßïÜßàHè ÚvñÂî|éÚ
Û
êÆàéç ßàöávàæ
è ç Üç æßvàßÜ
ô²áÜ
Þ8àávè
Ûç åvÝÞÚÞ0ò|å
ý²ç åßvàFåÞ5ÚÞ8ò|å´öávàòéàß|ïÜç Ü|ïvßÜ´ÚöHè ÚvñÍîéÚ
äávòÜ|évÚà â
Ûç åð
ÚñÂîéÚ|ó
ý²ç åvò|Úvè ç å|ßvàßàéßÂòéàß|ïÜß|évßÂè ÚvñÂî|éÚ
Û
êÆàéç ßà
äávòÜ|évÚà â
æávÜ
Þ8àáè è ßvàðÚñÂî|évÚ
ù¿ÜéßàåvúFïvßàáñûéßvàFßvàò|éà5ßïÜß
Þè ÚñÂîéÚÛêÆàéç ßvà
õ î Ü|ßvàßÜ´ö8ç è îàá÷ÐåßàÛ
ávàö8ç è Ü|ÚÛÜ´ÚÜ|ïç Û
ßå
ô²áÜ
Þ8àávè
ç Ü|éè ÚßåFìJè ç Üç æßvà
Ûç åì½è ç Üç æßà
þ î|ßvܸßvñºÿç è
|ßvÜ
Þð
ÚvñÂî|éÚ
ý²ç åßvàFéßØæ
è ç Üvç æßvà5ßÖéßvàFßvàFö8òvÜ|éßÞÉüí¿àìJÜ|á÷
ßvÜ
ÞßàHè ÚvñÂî|éÚ
Û
êÆàéç ßà8Ü|ß
äávòÜ|évÚà â
ô²áÜ
Þ8àávè
äávòÜ|évÚà â
ïßvñºð
ÚvñÂî|éÚ
¸ßvñÂñ´ßàHè ÚvñÂî|éÚ
Û
êÆàéç ßà½ü
éßvÜ´ÚÜïç ÛÜ|ß´ö8ç è
ô²áÜ
Þ8àávè
þ î|ßvÜFÿç è
õ îÜ|ßvàö8ç è îàá÷øå|ßvà
ô²áÜ
Þ8àávè
æávÜ
Þ8àáè è ßvàÿç è Ü|Ú
ÛÜ
ù¿ÜéßàåvúFïvßàáñûö8ç è Ü|Ú
ÛÜ´ßæåvç åÞßàßvà
ô²áÜ
Þ8àávè
æávÜ
Þ8àáè è ßvàÿç è ÿávà8ñ´Ú
Þ
ù¿ÜéßàåvúFïvßàáñûö8ç è öávà0ñ´ÚÞß
ÞFßvàæávà8àßæÞ
ô²áÜ
Þ8àávè
ç Ü|éè êëåFÿç è
ü Ü|éè êÕå|ßvàö8ç è ßÜÂñ´ß|éÂévß´ïßvñ¸ÞßÂè ÚñÂî|évÚÛêÆàéç ßvà
ô²áÜ
Þ8àávè
Ûç åð
ÚñÂîéÚ|ó
ý²ç åvò|Úvè ç å|ßvàßàéßÂòéàß|ïÜß|évßÂè ÚvñÂî|éÚ
Û
êÆàéç ßà
äávòÜ|évÚà â
Figur 6.14: Oversigt over alle de funktioner der er defineret ud fra usecasene. Fortsat fra tabel 6.13 på foregående side.
46
KAPITEL
7
Grafiske brugergrænseflader
I dette kapitel vil der foreligge en visualisering af de fire forskellige grafiske brugergrænseflader, GUI´s, i Dr.
Know: loginvindue, klinikervindue, udviklervindue, grafvindue og hjælpvindue. Disse GUI´s er mock-ups baseret på de tidligere omtalte usecases. Formålet med dette er at finde eventuelle udeladte funktioner ved, at
gennemgå funktioner, der ligger bag hver enkelt knap på GUI´en. Disse funktionsgennemgange findes i appendiks C på side 147.
7.1
Loginvindue
Det er valgt, at Dr. Know skal have et loginvindue. Det skyldes blandt andet, at systemet har to brugertyper,
henholdsvis klinikeren eller udvikleren, som hver især ikke har faglig kompetence inden for hinandens områder
og dermed ikke skal anvende en anden GUI, end den, der er konstrueret til ens egen faggruppe. Når Dr. Knowapplikationen opstartes, initieres den første GUI for brugeren af Dr. Know. Den første GUI vil være Dr. Know
loginvinduet, som er en fælles GUI for både udviklere og klinikere. Figur 7.1 på næste side viser et mock-up af
loginvinduet i Dr. Know.
I appendiks vil være en beskrivelse af GUI-elementerne: knapper, input- og outputfelter i afsnit C.1 på side 147
samt en beskrivelse af de tilhørende funktioner i afsnit C.5.1 på side 153.
47
Grafiske brugergrænseflader
! "$#&% '("&)% * +&,)&-
TU! 8 9:8 6)%
.0/&1 +&! /&)3254(1763! 8 9:8 6)%DC?:)% ! "&)
;<* 8 ! ! 8 9":2:#()* )3"<9():! 23)
=>7% 94?79
@71 * )% 94?79
A9(B:8 )9&9:8 * )*
AC1 /:)! 8 9("
EGF
PQ RL S
HJI K3L MON
Figur 7.1: Mock-up af Dr. Know loginvinduet. Brugeren har mulighed for at vælge hvilken type bruger vedkommende er.
Vælger brugeren, at vedkommende er kliniker, da skal denne afgive forskellige informationer om sig selv og sit
arbejde. Når brugeren har valgt brugertype, og eventuelt udfyldt data om sig selv, da kan OK-knappen aktiveres.
OK-knappen kalder enten et klinikervindue eller et udviklervindue frem. Knappen Hjælp kalder et hjælpvindue
frem, som giver brugeren assistance og vejledning i brugen af Dr. Know. Afslut-knappen terminerer loginvinduet
og Dr. Know.
7.2
Klinikervindue
Klinikerdelen af Dr. Know konstrueres med henblik på, at indsamle klinikerens subjektive holdning og formalisering af præferencestruktur. Klinikervinduet konstrueres med henblik på at vedkommende skal være i stand
til at vurdere en patients tilstand og simulere nogle patientvariable ud fra nogle indtastede indstillinger. Klinikeren skal således præsenteres for patientvariablene og parametrene på en sådan måde, at vedkommende har
mulighed for at vurdere patientens fysiologiske tilstand.
Klinikervinduet startes op fra loginvinduet, når brugeren har valgt brugertypen ”Kliniker”, udfyldt oplysninger
og aktiveret ”OK”-knappen. I samarbejde med en kliniker og med inspiration fra INVENT er klinikervinduet
konstrueret. Klinikeren har givet udtryk for ønske om, at patientparametrene og -variablene visualiseres i to
forskellige kolonner eller dele af vinduet. Desuden er der udtrykt ønske om at respiratorindstillingerne ligeledes foretages i en særskilt del af vinduet. Figur 7.2 på modstående side viser en skitse af klinikervinduet i Dr.
Know.
I appendiks vil være en beskrivelse af GUI-elementerne: knapper, input- og outputfelter i appendiksafsnit C.2
på side 148 samt en beskrivelse af de tilhørende funktioner i afsnit C.5.3 på side 154.
48
Grafiske brugergrænseflader
VWXYZ[\^]Y_ `Z` aGbW
¨&€ „ |:~3 ƒ(€:} €(‚|3 } |&©
µ¶€3®:(°:ª:|·q®¬ „ ~(± ©
c<—(f3pOu‘ ’G“ ˆ
ŠOrJŒ‘ ” “ ˆ
…<m‘ •–“ ˆ
¨&€ „ |~3 ª:€} „ €«&¬ |&©
¹&&~(±&|ª:€} „ €«&¬ |&©
²J3ª:³$} |~°:|
¸„ } ·3&¬ € „ ¯7~
Š3h(˜U‹lŒ‘ ’“ ˆ
Š3h(‹CŒ‘ ’“ ˆ
¤0À ¤‘ Á3evJž–‹l“ ˆ
§‘ •O“ ˆ
¿}  |:} „ |¬ 0«:¬ ¯&°0©
¹:&~(±&|3°&º&~(€(‚„ ·:©
˜ 3k eGy5‘ ™ š ›œ0qž Ÿ “
<hqtG‘ › œ0ž Ÿ š ™ š ¡ “
c7‡(‹lŒ‘ ’“ ˆ
¤:‡(‹lŒ‘ n¤:‡q“ ˆ
¤:‡3˜U‹lŒ‘ nq¤:‡“ ˆ
»¶|3 €«¯7¬ „ ®3‚|&©
yv<‡G‘ ” “ ˆ
J… ‹lŒ‘ •o¢ e5d pq“ ˆ
…J˜U‹lŒ‘ •o¢ eGd pq“ ˆ
½ |:~(¾&®0«:¬ ¯&° ©
¼ ¬ ¯&° ©
c&Ž‹CŒ‘ ’G“ ˆ
¤Ž‹CŒ‘ n¤:‡q“ ˆ
¤Žq˜U‹lŒ‘ n¤:‡“ ˆ
y:v7Ž‘ ” “ ˆ
£U¤7j‘ ’“ ˆ
v 5‘ eGek(g ¢ g “ ˆ
˜ kvJ5‘ ” “ ˆ
¥hqu v 5‘ ” “ ˆ
¦7h3eGy”q‘ ˜J“ ˆ
Â0‘ e5ek(g ¢ g “ ˆ
c0nOd s u&3i f†3h3i
­J|3®ƒ&„ } € ¯<} „ ~°:® „ ¬ ¬ „ ~±&|}©
²J3ª:³$} |~°:|
´J„ ‚$&¬ |} |
Šd ‹CŒ
s
…<u
¤00<¤
Àˆ
‘ ’G“
‘ y3i ” e5d pq“
‘ •–“
‘ Á3ev žo‹l“
‘ ”“
c0d e5f3g h(i
²J3ª:³$} |~°:|
vw x$g y
:s u h(pq‡qŽqp3Š3k3i pq‡qŽqp
´J„ ‚$&¬ |} |
jlkmnoh3pqm
´J„ ‚$:¬ |} |
…0xg †y‡Ou d h(pOu †i f3y3yhˆ
z({ |} ~(| } €‚|:ƒ(€ „ |~( |:}
…0xg †y‡Ou d h(pOu p3f3eGeh(i ˆ ‰
rJs t3g fOu
Figur 7.2: Mock-up af Dr. Know klinikervinduet. Som det ses, har klinikeren mulighed for at vælge, hvilken patientgruppe
og dertilhørende patientcase denne vil arbejde med. Patientparametrene for en valgt patientcase, vil blive vist i
tekstfelterne længst til venstre, samt systemets forslag til respiratorindstillinger i tekstfelterne længst til højre.
Hjælp- og Afslut-knapperne har samme funktionaliteter som beskrevet under loginvinduet. Skiftbruger-knappen
giver klinikeren mulighed for at springe tilbage til loginvinduet og dermed afslutte sin brug af klinikerfunktionaliteten i Dr. Know. Simulér-knappen initierer simuleringen af patientvariable og viser resultatet af simuleringen
i form af nye patientvariable, som afspejler konsekvenserne af de indtastede respiratorindstillinger. Godkendknappen gemmer de indtastede indstillinger og kalder den næste patientcase frem for klinikeren.
7.3
Udviklervindue
Udviklervinduet konstrueres med henblik på, at udvikleren skal have mulighed for at beregne vægtninger af
penaltyfunktionerne, ud fra de respiratorindstillinger som klinikeren har indtastet. Udviklervinduet kaldes fra
loginvinduet, hvis brugeren har valgt brugertypen ”Udvikler” og aktiveret OK-knappen. Figur 7.3 på næste side
viser et mock-up af udviklervinduet i Dr. Know.
Udviklervinduet er konstrueret i samarbejde med en udvikler af INVENT. Her er der givet udtryk for, at der
skal være mulighed for at beregne lambda-værdier for en udvalgt patientgruppe. Samtidig skal de beregnede
lambda-værdier visualiseres for brugeren samt fejlgrafer for de forskellige respiratorindstillinger. Der er desuden udtrykt et ønske om en mulighed for at hente allerede beregnede lambda-værdier frem.
I appendiks vil være en beskrivelse af GUI-elementerne: knapper, input- og outputfelter i appendiksafsnit C.3
på side 151 samt en beskrivelse af de tilhørende funktioner i afsnit C.5.5 på side 159.
49
Grafiske brugergrænseflader
ÃÄÅÆÇÈÉ^ÊËÍÌÎÏÐÑ ÒÄ
ÓÔ ÕÖ ×(Õ3Ø Ö ÙÚÛÕÜ(Ù3Ø Ý Õ×(Ø ÕÖ
Þ0ß$à áâqãqä å æ3çOä áè é3â(âqæ
Uì Ý ×&Ý qÕ:Ö ñ7Ü&ì î×&Ý ×(í&ÕÖ
ë<Ø Ý ì ì Ý ×(í&îïÕØ Õ(í7×Õì î3Õ
ð(ñ<Ö ×(Ù3ò&×
ó7ô Ø ÕÖ ×(Ù3ò&×
õl×öÝ Õ×&×&Ý Ø Õ3Ø
õCô ÷&Õì Ý ×í
è æqá:çqæGà ã(ÿ þ ã ù (è(ú(âqæ3å ù å êlê–à å ç3å êoæ3è ã
Þ0ßà áêOà å ç3å êoæ3è
ýCþ æ(çá3æ(ÿlä
à ã(ÿ þ ã
:æ(è æáç
à ã3ÿ þ ã
è æqá:ç3å çqá"$
æ(ÿà ã(ÿ þ ã
"!
–ã(ÿ þ ã–ß$è å æ3è
#
þ æ3è æqá:çqæOä
7è è 3è áè ãqù æ(è
0ÙÖ ñ:Ø Ö ÙÚÛÕ
Ö ì Ý íñí:Õ:×(ÕÖ Ý ×í
õCöÝ ÷&ñ:î3Õ Ùì qÙ:ì ñ:î(Õ
ìØ Ø ñ :Ý öÝ Ø ÕØ
(å æ3è è (è á:è ãù
ûü ß$à â
è æ(ê–æ3çú
æ3è è (è áè ãqù
Þ<ä
æ3è è (è á:è ãù
ø ù ú(à éOä
Figur 7.3: Mock-up af Dr. Know udviklervinduet. Hjælp- og Afslut-knapperne har samme funktion som beskrevet tidligere.
”Beregn lambda”-knappen sætter beregningen af lambdaværdier i gang for en udvalgt patientgruppe. Efter beregningen er fuldført, kan lambdaværdierne gemmes. Der er ligeledes mulighed for at udvælge en bestemt kliniker,
der kan udregnes lamdaværdier for. Vælges en bestemt kliniker, vises informationer for denne i form af stilling,
fornavn, efternavn, anciennitet og afdeling. ”Åbn gemt lambda”-knappen kalder en file-browser frem, hvor udvikleren kan vælge en fil med gemte lambdaværdier. Når denne fil er valgt, vil lambda-værdier blive visualiseret
på udviklervinduet. Der er desuden mulighed for at hente grafvinduer frem for de forskellige respiratorindstillinger.
7.4
Grafvindue
For at kunne visualisere forskellen mellem klinikerens og systemets forslag til respiratorindstillinger, er det
nødvendigt at konstruere et grafvindue, som kan præsentere disse forskelle for udvikleren. Et mockup af dette
vindue ses på Figur 7.4 på modstående side. Dette vindue kaldes fra udviklervinduet, og der eksisterer således
tre grafvinduer i alt, ét for hver af de valgte respiratorindstillinger, FiO2 , Vt og f.
50
Grafiske brugergrænseflader
%'&)(+*-,/./0214365 798;:<&)&=.<&=><&=?A@
IJ J KJ
LDM NPO
BDC EF GH
Figur 7.4: Mock-up af Grafvindue under Dr. Know udviklervinduet. Grafen visualiserer forskellen mellem klinikeren og
systemets forslag til respiratorindstillinger.
7.5
Hjælpvindue
Hjælpvinduet kan kaldes fra alle de andre vinduer og giver brugeren information om hvorledes Dr. Know
anvendes. Et mock-up af hjælpvinduet kan ses på Figur 7.5. Når hjælpvinduet afsluttes, vendes der tilbage til
det oprindelige vindue, hvor hjælpvinduet blev kaldt fra.
I appendiks vil være en beskrivelse af GUI-elementerne: knapper, input- og outputfelter i appendiksafsnit C.4
på side 152 samt en beskrivelse af de tilhørende funktioner i afsnit C.5.7 på side 161.
Q-R)S+T-U/V/W2X4Y6Z=[]\^
_a`=bdce=e f ghi j4g kmln"o=p qr=`smlnatup vwxsy{z
|q=b
Figur 7.5: Mock-up af Dr. Know hjælpvinduet. Hjælpvinduet giver klinikeren eller udvikleren hjælp til brugen af Dr. Know.
51
KAPITEL
8
Klassediagram
Dette kapitel indeholder en definition af objekter samt klasser. Desuden vil der forefindes en inddeling af objekterne i klasser med tilhørende attributter og adfærd. Afslutningsvis vil der være udarbejdet et klassediagram,
som illustrerer den statiske struktur af klasser i problemområdet. Formålet med dette kapitel er at få defineret
de nødvendige klasser i Dr. Know.
8.1
Objektkandidater
I forbindelse med usecase-diagrammet blev der udarbejdet en tekstuel beskrivelse af Dr. Know, som ses i
afsnit 4.1 på side 25. Den tekstuelle beskrivelse anvendes til at finde kandidater til objekterne i Dr. Know.
Fremgangsmåden for at finde kandidaterne til objekterne er, at finde navneordene i den tekstuelle beskrivelse
og derefter undersøge, om det er nogle, der kan styres, kontrolleres, administreres eller overvåges. [6].
Et eksempel på, hvordan kandidaterne til objekterne er fundet, gives følgende:
”Dr. Know skal kunne simulere patientvariable ud fra de indtastede respiratorindstillinger, hvilke
er: FeCO2 , FeO2 , SaO2 , PaO2 , PaCO2 , pHa, SvO2 , PvO2 , PvCO2 , PIP og pHv. Klinikeren skal
herefter kunne gentage og/eller godkende respiratorindstillingen, der automatisk skal gemmes ved
godkendelse.”
Citatet er taget fra den tekstuelle beskrivelse, hvor kandidaterne patientvariable, kliniker og respiratorindstillinger er identificeret ud fra ovenstående metode. Ud fra den beskrevne metode er følgende kandidater til objekter
i den tekstuelle beskrivelse identificeret:
Patient: Postoperativ hjertepatient, hjernetraumepatient, intensivpatient.
Respiratorindstillinger: Respirationsfrekvens, tidalvolumen, inspireret oxygenfraktion.
Penaltyfunktioner: Barotraume, acidose/alkalose, oxygentoxicitet, dårlig oxygenering.
Patientparametre: FA2, Vd, DPG, Hb, MetHb, COHb, Temperatur, Q, VO2 , VCO2 , BE, compliance, resistance, shunt.
53
Klassediagram
}
Patientvariable: SaO2 , PaO2 , PaCO2 , pHa, SvO2 , PvO2 , PvCO2 , pHv, FeCO2 , FeO2 , PIP.
Kliniker: Fornavn, efternavn, afdeling, anciennitet, stilling.
Lambdaværdier: Lambda for barotraume, lambda for acidose/alkalose, lambda for oxygentoxicitet, lambda
for dårlig oxygenering.
Errorgrafer: Errorgraf for f, errorgraf for FiO2 , errorgraf for Vt.
Efter at have identificeret kandidaterne til objekterne i den tekstuelle beskrivelse skal det undersøges, om kandidaten kan eksistere selvstændigt. Kan kandidaten til objektet ikke eksistere selvstændigt, er kandidaten således
en attribut til et andet objekt, som attributten afhænger af. En attribut indeholder objektets karakteristiska, som
skelner den fra andre objekter.
8.2
Definition af klasser
Ud fra de fundne kandidater til objekter er det muligt at definere klasser. Hvis et objekt er det eneste i sin
klasse, bliver objektet således til en klasse. Navnet samt forklaring af klassen er først beskrevet, hvorefter en
figur øverst indeholder klassens navn, i midterste rubrik klassens attributter, og nederst klassens adfærd, hvis
disse er essentielle at fremhæve. Klassernes adfærd indholder de hændelser som sker for objekterne i klassen.
Til at finde adfærden for klasserne er bl.a. funktionerne i de udarbejdede aktivitetsdiagrammer i kapitel 6 på
side 33 anvendt.
PatientState Det er fundet nødvendigt, at der skal eksistere en klasse, der håndterer de tre patientgrupper.
Denne betegnes PatientState. Denne klasse indeholder følgende attributter: De patientparametre, der er sat konstante i Dr. Know, klinikerens respiratorindstillinger og de deraf simulerede patientvariable. Patientparametrene
er FA2, Vd, DPG, Hb, MetHb, COHb, Temperatur, Q, VO2 , VCO2 , compliance, resistance og Shunt, patientvariable er SaO2 , PaO2 , PaCO2 , pHa, SvO2 , PvO2 , PvCO2 , pHv, FeCO2 og FeO2 , og respiratorindstillinger er f,
Vt og FiO2 .
PatientState
FA2, Vd, DPG, ...
SaO2 , PaO2 , ...
f, Vt, FiO2
genererePatientState
InitialState Det er endvidere fundet nødvendigt, at tilføje en ekstra klasse, der håndterer det forslag systemet
kommer med. Det vil sige denne klasse indeholder de initierede værdier for respiratorindstillinger og initierende
værdier for simulerede patientvariable for patienten.
InitialState
SaO2 , PaO2 , ...
f, Vt, FiO2
54
Klassediagram
Settings Det er valgt, at konstruere en klasse der håndterer de respiratorindstillinger, som klinikeren fastsætter. Denne klasse betegnes Settings, og skal anvendes til beregningen af lambdaværdier.
Settings
f, Vt, FiO2
Kliniker For at kunne håndtere de informationer klinikeren indtaster omkring sig selv, konstrueres denne
klasse. De informationer der indtastes er: Fornavn, efternavn, afdeling, anciennitet og stilling. Desuden gives
klinikeren et nummer, så det er lettere at skelne de forskellige klinikere fra hinanden.
Kliniker
Klinikernummer
Fornavn
Efternavn
Afdeling
Anciennitet
Stilling
Lambda Klassen Lambda indeholder lambda for hver af de fire kliniske tilstande: lambda for barotraume,
lambda for acidose/alkalose, lambda for oxygentoxicitet, lambda for dårlig oxygenering, hvilket vil sige et
penaltynavn med en tilhørende lambdaværdi. Formålet med klassen er, at få beregnet lambdaværdierne.
Lambda
Lambda for barotraume
Lambda for acidose/alkalose
Lambda for oxygentoxicitet
Lambda for dårlig oxygenering
Penaltynavn
Lambdaværdi
beregning
Penalties
Klassen Penalties håndterer beregningen af penaltyfunktionerne.
ErrorData Formålet med klassen ErrorData er at få beregnet forskellen mellem klinikerens respiratorindstillinger og systemets forslag til respiratorindstillinger og håndterer de data, der skal anvendes til at plotte errorgraferne for respiratorindstillingerne.
55
Klassediagram
}
Penalties
Barotraume
Acidose/alkalose
Oxygentoxicitet
Dårlig oxygenering
BeregnPenalty
ErrorData
Vektor
f
Vt
FiO2
Visualisering
8.3
Klassediagram
Et klassediagram illustrerer den statiske struktur af klasserne i Dr. Know. Diagrammet er statisk, da strukturen
af klasser, som er illustreret i klassediagrammet, vil være gældende for alle systemets tilstande. Klasserne repræsenterer de processer, som systemet håndterer. Der findes tre forskellige måder, hvorpå klasserne kan være
relateret til hinanden: Klasserne kan være associeret og dermed forbundet til hinanden, de kan være afhængige
og dermed brugere af en anden klasse, eller de kan være specialiserede og dermed en specialisering af en anden
klasse. [6] I klassediagramet er der således udelukkende illustreret klasser og ikke objekter.
På Figur 8.1 på modstående side er klassediagrammet for Dr. Know illustreret. Klassediagrammet illustrerer
problemområdet i Dr. Know, der er defineret som vægtningen af penaltyfunktionerne. Det er på figuren illustreret, hvilke forhold der er mellem klasserne.
56
Figur 8.1: Klassediagrammet illustrerer relationen mellem de definerede klasser i Dr. Know. Det er på figuren ligeledes
illustreret, hvilke klasser der er associeret, og hvilke der arver fra en superklasse. Der ses således at klassen InitialState nedarver fra superklassen PatientState. På diagrammet er det muligt at se om en klasse er associeret med
en anden i forskellige forhold, hvilket vil sige, at forholdet mellem to klasser f.eks. kan være 1:1 eller 1:mange.
Dette er illustreret med et 1-tal eller 1..* mellem de forskellige klassers tilknytninger. Klassediagrammet illustrerer ydermere problemområdet, der er vægtningen af penaltyfunktionerne. Klassediagrammet læses således:
Der læses i pilens retning, hvor navnet på den første klasse læses, herefter læses navnet på associeringspilen og
tilsidst læses den sidste klasses navn. Det skal desuden bemærkes at der kan startes et vilkårligt sted på figuren.
Del III
Systemdesign
Formålet med denne del er at udforme et design af Dr. Know, således at
softwaresystemet kommer til at leve op til de brugerkrav, der er defineret i
usecasebeskrivelsen.
Kapitel 9 beskriver, hvorledes forskellige designkriterier bliver vægtet i dette
projekt.
Kapitel 10 indeholder en beskrivelse af de klasser, der er fundet nødvendige
at implementere yderligere, samt en beskrivelse af komponentarkitekturen i
Dr. Know.
Kapitel 11 beskriver de klasser, der hører til GUI-delen af systemet.
Kapitel 12 beskriver de klasser, der hører til kontrol-delen af Dr. Know.
Kapitel 13 beskriver de klasser, der hører til entity-delen, samt beskriver
hvorledes der skal gemmes data.
Kapitel 14 indeholder en beskrivelse af den dynamiske sammenhæng mellem
objekterne i Dr. Know, hvor det sekventielle flow er visualiseret.
59
KAPITEL
9
Designkriterier
I dette kapitel vil vægtningen af forskellige designkriterier blive beskrevet. Designkriterierne er udarbejdet på
baggrund af [9]. Formålet med designkriterierne er at give en forståelse for, hvordan forskellige designaspekter
bliver vægtet i Dr. Know.
9.1
Vægtning af designkriterier
På figur 9.1 på næste side er de forskellige designkriterier og deres vægtning illustreret. Der skelnes mellem, om
designkriteriet vægtes som ekstremt vigtigt for Dr. Know’s funktionalitet, om designkriteriet er mindre vigtigt,
eller om designkriteriet ikke har nogen betydning. Herimellem findes desuden nogle mellem-vægtninger, hvilket også ses af figuren. Desuden findes en tekstuel begrundelse for de enkelte vægtninger samt designkriteriets
betydning for systemet.
I det følgende er alle vægtninger foretaget ud fra det synspunkt, at Dr. Know skal kunne betragtes som et kommercielt produkt. Det betyder at der skal tages stilling til aspekter, som en eventuel køber kan finde relevant,
herunder omkostninger, vedligeholdelse og fremtidige ændringer ved systemet.
Brugbarhed er, hvor vigtigt det er let at kunne tilpasse Dr. Know til anvendelsesområdet. Brugbarheden
vurderes til at være ”ekstremt vigtigt”, idet applikationsområdet er udvikleren, der skal kunne bruge outputtet
fra Dr. Know i INVENT. Applikationsområdet er ligeledes klinikeren, der skal sørge for input til systemet. For
at få et brugbart input fra klinikeren er det ligeledes vigtigt, at Dr. Know bliver tilpasset klinikeren, i form af at
patientvariablene og patientparametrene bliver præsenteret så overskueligt som muligt.
Sikkerhed er, hvor vigtigt det er at sikre Dr. Know’s data mod uventet og uvedkommende adgang. Sikkerheden vurderes til at være ”irrelevant”, idet Dr. Know ikke indeholder personfølsomme oplysninger. Såfremt
klinikeren skulle indtaste sit CPR-nummer, eller hvis patientcases indeholdt patienternes CPR-nummer, ville
det have været relevant at give systemets sikkerhed en højere prioritet. Personer, der hverken er klinikere eller
udviklere, kan i teorien misbruge Dr. Know, men det vurderes til ikke at være en reel risiko for outputtet fra Dr.
Know.
61
Designkriterier
~
™›šœ {ž/š=œ ž/š
–P—ˆŒ… †‡˜<Œ
‘Ž Œ{Ž aŒ
ŸP…€"m‹’‰… a†‚
¡
•6Ž Œ{Ž Œ
“-Ž Šx‚m… †”‘mŽ Œ{Ž Œ
 …… †‡ †a‘‡’‡Š)Œ
ª/Ž —x—†‡… †‚
¡
–mƒ ƒ†‰—ŒŽ ‘mŽ Œ†xŒ
¡
©¥¦‰…… †‰—Œ a†‚
¡
§¥¨‰ Ž ‚‡†‰ Ž m a†‚
¡
•/†‚m Ž ‡†‰ ¦‡ ‚‰†‡ ˆx†
¡
¤¥†ˆ)Œ{ŠuŽ Šx
¡
A †‰—)ˆŽ ‹DŽ  Ž Œ†xŒ
¡
 ŠŒ{€DŽ Œ{Ž ‘Ž Œ†xŒ
A€D ‚Dƒ P
„ … †‡ ˆx†-†‡…
€x‚‰†‡Š
‹†"Œ x‚mŠuŽ Šx
¡
¢£†‰Š’‡Š"‘‡†‰Šx‚‡†‰ Ž m a†‚
¡
m Œ{‹’‡… Œ
¡
 Š)Œd†am… †‡…‹a’‡… Œ
¡
Figur 9.1: Vægtningen af designkriterierne for Dr. Know er illustreret.
Effektivitet er, hvor vigtigt det er at presse så meget power som muligt ud af den tilgængelige tekniske
platform. Effektiviteten vurderes at være ”mindre vigtig”, idet Dr. Know skal køre for sig selv uafhængig af
andre systemer, idet tiden ikke er så afgørende for outputtet af systemet. Beregningen af lambdaværdierne tager
det meste af regnekraften.
Korrekthed er, hvor vigtigt det er at opfylde de krav, der er fundet i analysen af kravspecifikationerne. Korrekthed vurderes at være ”ekstrem vigtig”, da kravene til Dr. Know er sat efter grundige overvejelser i samarbejde med både udvikler og kliniker.
Pålidelighed er, hvor vigtigt det er at opfylde kravene med en vis nøjagtighed. Pålidelighed vurderes at
være ”vigtig”, da kraverne kan ændres på baggrund af det valgte programmeringssprog, som kan sætte visse
62
Designkriterier
begrænsninger.
Vedligeholdelse er, hvor vigtigt det er at kunne tilføje yderligere funktionaliteter til Dr. Know, efter det er
implementeret i den organisation, som skal bruge det. Vedligeholdelse vurderes at være ”vigtig”, idet det skal
være muligt at kunne udvide Dr. Know.
Testning er, hvor vigtige omkostningerne er for at teste Dr. Know i henhold til kravspecifikationerne. Dette
vurderes at være ”mindre vigtigt”, ud fra den betragtning, at der ikke afsættes en bestem mængde tid til testning,
men at opgaven stadig har en betydning, da testning er en del af projektet.
Fleksibilitet er, hvor vigtige omkostningerne er for at skulle ændre på det færdige Dr. Know. Her er det
vurderet at være ”mindre vigtigt”, idet de ændringer som måtte opstå ikke forventes at være af en større karakter
og derfor forventes at være overskuelige at skulle ændre på.
Intuitivitet er, hvor vigtigt det er, at nye brugere let kan anvende systemet. Intuitivitet vurderes at være
”ekstremt vigtigt”, idet Dr. Know udvikles til at skulle anvendes af blandt andet klinikere, der alle vil være
førstegangs- og eventuelt engangsbrugere af systemet. Desuden er klinikerens input afgørende for udviklerens
output, og det er derfor ikke acceptabelt, at klinikeren indtaster forkerte data pga. manglende intuition for
anvendelsen af Dr. Know.
Genanvendelighed er, hvor vigtigt det er at kunne anvende komponenter fra Dr. Know i andre systemer.
Genanvendelighed vurderes at være ”fuldførelse uden betydning”.
Flytbart er, hvor vigtigt det er, at Dr. Know kan flyttes til andre platforme i fremtiden. Flytbart vurderes at
være ”fuldførelse uden betydning”.
Integrérbart er, hvor vigtigt det er, at Dr. Know kan integreres med andre systemer uden for mange omkostninger/problemer. Det vurderes, at dette prioriteres som ”irrelevant”, idet der ikke tages højde for, at Dr.
Know skal kunne integreres med andre systemer. Det tages til gengæld hensyn til, at outputtet fra Dr. Know
skal kunne kunne integreres i INVENT.
63
KAPITEL
10
Komponentarkitektur
Dette kapitel indeholder en beskrivelse af klassediagrammet for Dr. Know. Klassediagrammet viser organisationen af Dr. Know, hvor klasserne organiseres i tre delsystemer: GUI, kontrol og entity. Afslutningsvist i
kapitlet vil der være et revideret klassediagram indeholdende alle de nye fundne klasser.
10.1
Udvidelse af klassediagram
I det videre design af Dr. Know er det fundet nødvendigt at tilføje nogle ekstra klasser til klassediagrammet, som
blev konstrueret i analysen. Det drejer sig om følgende klasser: LoginVindue, KlinikerVindue, UdviklerVindue, HjaelpVindue, LambdaPlusError, GrafFunktion, LambdaGem, Database samt diverse INVENT-klasser.
Alle disse klasser er blevet tilføjet, da der er opstået et behov for at have disse klasser med i Dr. Know. LoginVindue, KlinikerVindue, UdviklerVindue og HjaelpVindue er alle brugergrænseflader, som er blevet tilføjet
p.g.a. et behov, for at brugerne af Dr. Know kan interagere med Dr. Know.
Klassen LambdaPlusError er tilføjet for at have en klasse, der kan administrere den data, der genereres af lambdaberegningen. GrafFunktion er tilføjet for at give udvikler mulighed for at visualisere error for forskellige
respiratorindstillinger og dermed vise hvor godt et ”fit” der er opnået. Klassen LamdbaGem opfylder det behov, der er for at kunne gemme lambdaværdier i en fil. Klassen Database er tilføjet for at kunne gemme og
administrere den data, klinikeren indtaster i Dr. Know.
De sidste klasser, der er tilføjet, er INVENT-klasserne som anvendes i simuleringen af patientvariablene.
I det efterfølgende vil der forefindes en kortfattet beskrivelse af klassens funktion, og herefter vil der for nogle
klasser være en figur, hvor klassenavnet er vist i øverste kasse, mens attributterne er illustreret i midten og
klassens adfærd vil være at finde i nederste kasse, hvor det findes relevant.
LoginVindue Klassen giver brugeren mulighed for at logge ind i Dr. Know som to forskellige brugertyper:
kliniker eller udvikler. Klassen indeholder de knapper og felter vinduet består af.
65
Komponentarkitektur
LoginVindue
Fornavn
Efternavn
Afdeling
Anciennitet
Stillingsbetegnelse
Kliniker
Kontrollér brugertype
Afslut
KlinikerVindue Klassen KlinikerVindue giver klinikeren mulighed for at vurdere den enkelte patients tilstand. Dette sker ved, at der er visualiseret patientparametre og ud fra disse er der mulighed for at simulere
nogle patientvariable. Klinikeren har ligeledes mulighed for at indtaste respiratorindstillinger til den enkelte
patient. Klassen KlinikerVindue indeholder således alle de komponenter/felter, som vinduet består af.
KlinikerVindue
Alle knapper og tekstfelter
Kliniker
Afslut
Skift bruger
UdviklerVindue Denne klasse giver udvikleren mulighed for at udvælge kliniker samt patientgruppe som
der skal beregnes lambdaværdier for. Udvikleren har ligeledes mulighed for at få visualiseret allerede gemte
lambdaværdier. Klassen UdviklerVindue indeholder de komponenter, som udviklervinduet består af.
UdviklerVindue
Alle knapper og tekstfelter
Kliniker
Afslut
Vis Process
HjaelpVindue Denne klasse er blevet tilføjet, da det vil være nødvendigt at informere brugerne af Dr. Know
omkring funktionaliteten af systemet. Desuden vil der i denne være en beskrivelse af brugen af systemet.
HjaelpVindue
Afslutknap samt tekstfelt
Afslut
LambaPlusError
Klassen LambdaPlusError genererer et objekt, der indeholder data for lambda og error.
66
Komponentarkitektur
LambdaPlusError
bestLambda
errorArrays
GrafFunktion
Klassen GrafFunktion genererer det felt, der skal vise errorgraferne for udvikleren.
GrafFunktion
createChart
LambdaGem
Klassen LambdaGem gemmer de udregnede vægtninger for penaltyfunktionerne.
LambdaGem
Lambda
Kliniker
GemEtEllerAndet
IndlaesEtEllerAndet
Database De respiratorindstillinger samt klinikeroplysningerne, som klinikeren giver Dr. Know, skal lagres.
Lambdaværdierne skal ligeledes lagres, så der er mulighed for at hente allerede beregnede lambdaværdier frem.
Det er valgt, at denne lagring skal foregå i en database. Derfor er der blevet tilføjet klassen Database.
Database
Fornavn
Efternavn
Afdeling
Anciennitet
Stillingsbetegnelse
FiO2
Vt
Frekvens
Patientgruppe
Indsaet
OpretCase
OpdaterCase
HentKlinikerListe
HentData
67
Komponentarkitektur
Diverse INVENT-klasser Disse klasser tilføjes, da de fysiologiske modeller fra INVENT implementeres.
De enkelte klassers funktion er at simulere patientvariable ud fra en given respiratorindstilling. Klasserne er
allerede konstruerede og vil derfor først blive beskrevet under implementering 16.2 på side 95.
10.2
Illustration af klynger
Figur 10.1 viser, hvorledes pakkerne i Dr. Know kan organiseres i tre delsystemer: GUI, kontrol og entity. GUI
indeholder alle komponenter hørende til grænsefladerne med brugerne. Kontrol indeholder alle de funktionelle
komponenter, hvilket vil sige de pakker, der sørger for funktionaliteten i Dr. Know. Entity indeholder de pakker,
der hører til Dr. Know’s interne grænseflader.
«D¬ ­®‰¯)°)±
²´³uµ
»{¼½)¾ ¿ÀD¾ ¿Á)ÂÃ
ÄxÅ ¾ ¿=¾ ÆdÃ=Ç ÀD¾ ¿Á)ÂÃ
®u°a¯¶ ¬ °a·
ÈaÁɾ ÆÅ Ã=Ç ÀD¾ ¿Á)ÂÃ
Ê)Ë ÌÃ=Å ÍÀD¾ ¿Á)ÂÃ
×AÇ ÌØ Ù)Â=¿=ÆÏ ¾ ¼=¿
¸¯=¶ ¹ ¶ º
Î ¿¾ Ï ¾ ÌÅ Ð"Ï ÌÏ Ã
ÑÌÏ ¾ Ã¿Ï Ð"Ï ÌÏ Ã
»{ÌÒ¥ÓÁ=Ì
ÄxÅ ¾ ¿¾ ÆdÃÇ
ÑÿÌÅ Ï ¾ ÃÖ
»{ÌÒ¥ÓÁ=ÌÍ=Å ÂÖ
ÔxÇ Ç ¼Ç
ÔxÇ Ç ¼Ç ÕaÌÏ Ì
ÐxÃÏ Ï ¾ ¿½=Ö
ÕaÌÏ ÌÓÌÖÃ
»{ÌÒ¥ÓÁ=Ì×Ã=Ò
Figur 10.1: Et revideret klassediagram af komponentarkitekturen i Dr. Know. Den overordnede klynge Dr. Know er inddelt
i tre klynger, henholdsvis GUI, kontrol og entity. De tilføjede klasser er: LoginVindue, KlinikerVindue, UdviklerVindue, HjaelpVindue, LambdaPlusError, GrafFunktion, LambdaGem og Database. De diverse INVENTklasser er ikke indeholdt i klassediagrammet, men er dog en del af komponentarkitekturen.
10.3
Revideret klassediagram
På baggrund af de tilføjede klasser kan klassediagrammet fra analysen (Figur 8.1 på side 57) revideres til et
udvidet klassediagram som ses på Figur 10.2 på næste side. I dette klassediagram er de ovenfor beskrevne
klasser tilføjet(dog ikke INVENT-klasserne) og deres relation til de eksisterende klasser illustreret.
68
é)Þ=ê4ë)ì"Þ&Aá=ê
æÞÝ Þ)ëÞç=á
ï
ò=ó ôõ=öó
ø ÿý ü ÷ ý ö ÷
ø ÿ"=öû#=ú =öó
Ú Û"Ü Ý Ü Þ)ß àaÝ Þ=Ý á
ûüó
ï
ôü=ú ø ÷ öó ö ÷
ø÷
ñ ð
ð
!
í‰ß Ü ÛÜ îá)ä ‰Ü Ûì)á ï
àáÝ Ý Ü Û)è"ç
$%
âÞÝ Ü á)ÛÝ àaÝ ÞÝ á
í‰ß Ü Û"Ü îá)ä
ñ ð
ð
ï
÷=ø ù ôú öó öó
ò=ó ôõ=ö=ó
ò=ó ôõ=ö=ó
ï
ï
éÞ=ê6ë)ï ìÞ
ï
ï
ï
ì"Ü î=ß á)ä ‰Ü Û)ì)á
ôü=ú ø ÷ öó ö=ó
ø÷
ý ø ú þÿdý ý ö ÷
ûöÿý ö=ó=üý ü ï
éå"èaÜ Û‰Ü Û)ìá
ï
ñ ð
ð
ï
ãä ä åaä æaÞ=Ý Þ
ï
ï
ï
ñ ð
ð
ï
òó ôõö=ó
âáÛÞß Ý Ü á=ç
òó ôõö=ó
ûüó
ûüó
ï
ûüó
ï
é)Þ=ê6ëì"Þ"ß ï çãä ä åaä
Þ=áß ‰Ü Û)ìá
ûü=ó
$%
&´ä Þ$' ()Û"îÝ Ü åxÛ
ûüó
ûöÿý öó
Figur 10.2: Dette er den reviderede version af klassediagrammet fra analysen. Klassediagrammet illustrerer relationen mellem de definerede klasser i Dr. Know. Det er på figuren illustreret, hvilke klasser der er associeret, og hvilke der
arver fra en superklasse. På diagrammet er det muligt at se om en klasse er associeret med en anden i forskellige
forhold, hvilket vil sige, at forholdet mellem to klasser f.eks. kan være 1:1 eller 1:mange. Dette er illustreret
med et 1-tal eller 1..* mellem de forskellige klassers tilknytninger. Klassediagrammet illustrerer ydermere problemområdet, der er vægtningen af penaltyfunktionerne. Klassediagrammet læses således: Der læses i pilens
retning, hvor navnet på den første klasse læses, herefter læses navnet på associeringspilen og tilsidst læses den
sidste klasses navn. Det skal desuden bemærkes at der kan startes et vilkårligt sted på figuren.
KAPITEL
11
GUI-klasser
I det følgende beskrives designet af klasserne: LoginVindue, KlinikerVindue, UdviklerVindue, HjaelpVindue
og GrafFunktion. Disse klasser hører alle til delsystemet GUI. Først beskrives klassen og dennes tilhørsforhold, og dernæst beskrives den enkelte klasses metoder. Attributterne er beskrevet i appendiks D på side 163.
Nedenstaående figur illustrerer, hvilke klasser der beskrives.
*+ ,.-)/01
2435
< =?>@ A
B@ A9C.D9E
Y4I N?Z
[D9A.H Q @ =.A
FG @ A.@ H E.I
B@ A9CD9E
LM N9E9G O
B@ A9CD9E
JC9K @ H G E.I
B@ A9CD9E
11.1
-)0"/.6 + 07
8 /96 : 6 ;
P A9@ Q @ N9G
R"Q N?Q E
FG @ A.@ H E9I
S
VI I =.I
W$N?Q N
N Q @ E.A Q
S R"Q N?Q E
< N.TU9C.N
O.G D9XV"I I =.I
WN Q N
U9N?X9E
E.A9N9G Q @ E9X
< N.TU9C.N
< N.TU9C9N
YE.T
R$E Q Q @ A9>.X
LoginVindue
Definition Denne klasse visualiserer en GUI for brugerne af Dr. Know og giver mulighed for valget mellem
brugertyperne: Udvikler og kliniker.
Metoder
+LoginVindue():Void Constructor for klassen LoginVindue. Kalder metoderne setup(), resetGUI() og addListeners().
+setup():Void En metode der konfigurerer de grafiske elementer i vinduet.
+resetGUI():Void Nulstiller tekstfelterne for fornavn, efternavn, anciennitet, afdeling og stillingsbetegnelse.
+addListernes():Void En metode der tildeler lyttefunktioner til knapperne i vinduet. Lyttefunktioner bruges
71
GUI-klasser
til at overvåge om knapper, kombinationsboks mm. bliver anvendt.
Indre klasser
-HaendelseKontrol Denne klasse kontrollerer de hændelser, som kan optræde i klassen LoginVindue.
-BoksBrugerKontrol Denne klasse håndterer hændelserne fra kombinationsbokse på GUI.
11.2
KlinikerVindue
Definition Denne klasse giver klinikeren mulighed for at kalde forskellige patientcases frem på GUI, hvorefter denne kan simulére patientvariablene for forskellige respiratorindstillinger.
Metoder
-KlinikerVindue(Kliniker):Void Konstruktor for klassen KlinikerVindue.
-setup():Void En metode der konfigurerer de grafiske elementer i vinduet.
-addListernes():Void En metode der tildeler lyttefunktioner til knapperne i vinduet.
-resetGUI():Void Nulstiller alle tekstfelterne der indeholder systemet forslag til respiratorindstillinger. Sætter
desuden patientcasevælgeren til 1.
-resetAlt():Void Nulstiller alle tekstfelter der indeholder simulerede værdier.
-afslutningsFunktion():Void En metode der terminerer vinduet.
-skiftBruger():Void En metode som giver mulighed for brugerskift.
-skrivVariable(InitialState):Void En metode der henter parameterværdier og printer dem i tekstfelterne.
-skrivVariable(PatientState):Void En metode der henter variabelværdier og printer dem i tekstfelterne.
+hentSettings():Setting En metode der henter klinikerens indtastede respiratorindstillinger og returnerer et
Settingsobjekt.
+hentCasenummer():int En metode som henter caseNummer fra GUI og returnerer en int.
+simuleringFunktion():Void En metode der simulerer patientvariable ud fra patientparametrene og respiratorindstillingerne.
-godkendCase():Void En metode som gemmer klinikerens indtastede respiratorindstillinger.
Indre klasser
-HaendelseKontrol Denne klasse kontrollerer de hændelser, som kan optræde i klassen KlinikerVindue.
-kontrolPatientGruppe Denne klasse håndterer valg af patientgruppe i kombinationsboksen boksPatientGruppe.
-kontrolPatientNummer Denne klasse håndterer valg af patientnummer i kombinationsboksen boksPatientNummer.
72
GUI-klasser
11.3
UdviklerVindue
Definition Denne klasse giver udvikleren mulighed for at beregne og visualisere lambdaværdier og errorgrafer for respiratorindstillinger. Klassen kalder klassen GrafFunktion.
Metoder
-UdviklerVindue():Void Konstruktor for klassen UdviklerVindue. Kalder metoderne setup(), addListeners(),
resetKliniker(), resetLambda() og afslut().
-setup():Void En metode der konfigurerer de grafiske elementer i vinduet.
-addListeners():Void En metode der tildeler lyttefunktioner til knapperne i vinduet.
-resetKliniker():Void Nulstiller tekstfelter som indeholder klinikeroplysninger.
-resetLambda():Void Nulstiller tekstfelter som indeholder lambdaværdier.
+showDialog(String, String, String, char, File):File Metode som viser en dialogboks til valg af fil til at gemme
eller åbne en fil med lambdaværdier.
+visProcess(double):double Viser hvor langt lambdaberegningsprocessen er nået.
+beregningAfLambda():Void Henter data som bruge ved lambdaberegning.
+gemLambda():Void En metode der konstruerer, hvordan lambda skal gemmes i en fil.
Indre klasser
-HaendelseKontrol Denne klasse kontrollerer hændelser fra knapper i klassen UdviklerVindue.
-kontrolPatientgruppe Denne klasse håndterer valg af patientgruppe i kombinationsboksen boksPatientgruppe.
-kontrolKliniker Håndterer valget af, om lambda skal beregnes for en kliniker. Vælget træffes i kombinationsboksen checkBoksKliniker.
-kontrolNavn Håndterer valg af klinikernavn i kombinationsboksen boksKliniker.
-beregn En klasse der initierer beregningen af lambda i en ny tråd.
11.4
HjaelpVindue
Definition
HjaelpVindue giver brugeren hjælp og vejledning til anvendelsen af Dr. Know.
Metoder
-HjaelpVindue():Void Konstruktor for klassen HjaelpVindue.
-setup():Void En metode der konfigurerer de grafiske elementer i vinduet.
-addListernes():Void En metode der tildeler lyttefunktioner til knapperne i vinduet.
+afslut():Void En metode der terminerer vinduet.
73
GUI-klasser
Indre klasser
-HaendelseKontrol Denne klasse kontrollerer de hændelser, som kan optræde i klassen HjaelpVindue.
11.5
GrafFunktion
Definition
Denne klasse genererer de felter, der skal vise errorgraferne for hver af respiratorindstillingerne.
Metoder
+createChart(double[],double[],String,String): Object er en metode, der tager to double og to String som
inputargumenter til at generere errorgraffelterne.
74
KAPITEL
12
Kontrol-klasser
I det følgende beskrives designet af klasserne: PatientState, InitialState, Settings, ErrorData, Lambda, LambdaPlusError, Penalties og Kliniker. Disse klasser hører alle til delsystemet Kontrol. Først beskrives klassen og
dens tilhørsforhold, og dernæst beskrives den enkelte klasses attributter og metoder.
\] ^._)`ab
c4de
k l?mn o
pn o9q.r9s
‡4w |?ˆ
‰r9o.v  n l.o
tu n o.n v s.w
pn o9qr9s
z{ |9s9u }
pn o9qr9s
xq9y n v u s.w
pn o9qr9s
12.1
_)a"`.f ] ag
h `9f i f j
~ o9n  n |9u
€" |? s
tu n o.n v s9w
|  n s.o 
 €" |? s
k |.‚ƒ9q.|
}.u r9†„"w w l.w
…|  |
ƒ9|?†9s
s.o9|9u  n s9†
k |.‚ƒ9q.|
k |.‚ƒ9q9|
‡s.‚

„w w l.w
…$|? |
€$s   n o9m.†
PatientState
Definition Denne klasse håndterer tilstandene for de patientcases, som systemet anvender til at beregne lambdaværdier. Patientcaserne er placeret i denne klasse, idet de alle indeholder attributterne caseNummer, liste over
parametrene, liste over variablene og respiratorindstillingerne.
Attributter
+caseNummer: int : En variabel, som indeholder et casenummer.
+parametrene: double : Shunt, FA2, Vd, Q, compliance, resistance, VO2 , VCO2 , DPG, Hb, COHb, MetHb,
Temperatur, BaseExcess.
+variablene: double : FeCO2 , FeO2 , PIP, SaO2 , PaO2 , PaCO2 , pHa, SvO2 , PvO2 , PvCO2 , pHv.
+respiratorindstillingerne:double : Frekvens, Vt, FiO2
75
Š
Kontrol-klasser
Metoder
+PatientState() En constructor for klassen PatientState . Den genererer et PatientState objekt.
+genererePatientState(int) Tager int, som svarer til patientcase nummer og genererer den patientcase, som
svarer til det nummer.
12.2
InitialState
Definition Denne klasse er en underklasse af klassen PatientState og tager sig af de initiale patientparametre
og Dr. Knows forslag til respiratorindstillinger for hertil hørende patienter. Disse præsenteres for klinikeren for
hver patientcase.
Attributter
Klassen nedarver alle attributter fra superklassen PatientState. Variablene overskrives til nogle konstanter, når
den første simulering af variable foretages.
Metoder
+InitialState(int):InitialState Er constructor for denne klasse. Den tager en int og returner et objekt, der
svarer til patientcase nummer x.
12.3
Settings
Definition
slag.
Denne klasse håndterer respiratorindstillingerne (settings) for både klinikernes og systemets for-
Attributter
+indstillinger: double : Frekvens, Vt, FiO2 .
Metoder
+Settings(double) En konstruktor for klassen Settings.
12.4
ErrorData
Definition Denne klasse genererer ErrorData objekter, som bliver brugt i klassen Lambda til at beregne error.
Desuden plottes og visualiseres errordata for klinikeren.
76
Kontrol-klasser
Attributter
+indstillingError: double[] : fiO2Error, frekvensError, vtError. Array af double der indeholder forskel mellem systemets forslag og klinikerens forslag for hver af respiratorindstillingerne
+meanError: double[] : Fi02, frekvens, Vt. Et array af double som indeholder mean error for indstillingerne.
totalError: double[] Array af variable som indeholder den totale error for alle indstillinger.
Metoder
+ErrorData() En konstruktor for klassen ErrorData. Den genererer et ErrorData objekt.
+plotError(double [], double [], String, String ) Denne metode plotter errorgraferne for de tre respiratorindstillinger.
12.5
Lambda
Definition Denne klasse skal stå for at lambdaværdierne bliver beregnet for hver af de fire penaltyfunktioner:
Barotraume, oxygentoxicitet, acidose/alkalose samt dårlig oxygenering. Derudover beregnes error for respiratorindstillingerne i denne klasse.
Attributter
+lambdaBaro: double En variabel der indeholder lambdaværdi for barotrauma.
+lambdaAcid: double En variabel der indeholder lambdaværdi for acidose/alkalose.
+lambdaToxi: double En variabel der indeholder lambdaværdi for oxygentoxicitet.
+lambdaOxy: double En variabel der indeholder lambdaværdi for dårlig oxygenering.
+lambdaVector: double[] Array af double indeholdende lambdakombinationerne.
Metoder
+Lambda() En konstruktor for klassen. Den genererer et Lambda objekt indeholdende 4 lambda værdier.
+Lambda(λ1 ,λ2 ,λ3 ,λ4 ) En konstruktor for Lambda klassen, som tager 4 argumenter af typen double.
+beregnLambda(PatientState[], Settings[], UdviklerVindue) Metode der beregner lambdaværdierne for de
fire penalties og returnerer dem til UdviklerVinduet.
+findSystemForslag(PatientState, Lambda): Lambda Kører alle kombinationer af Lambda igennem, og finder den som giver minimum penalty og bruger den som systemets forslag.
+errorSet(double, double): double Metode som regner error for indstillingerne.
+vectorToArray(Vector): double [] Tager en vektor af double og returnerer en array af double.
+findMinimum(double): double[] Finder den mindste værdi i en array.
+findMaximum(double): double[] Finder den største værdi i et array.
+class VisProcess En indre klasse som viser, hvor langt beregningsprocessen er nået.
77
Š
Kontrol-klasser
12.6
LambdaPlusError
Definition En klasse som genererer et LambdaPlusError objekt, som indeholder både et ErrorData og Lambda
objekt. Ved beregningen af lambdaværdier findes der for alle kombinationer af lambda de respiratorindstillinger som giver den mindste error. For hver lambdakombination gemmes error og lambdakombinationen i
LambdaPlusError-objektet.
Attributter
+bestLambda: Lambda Et Lambda-objekt som indeholder de lambdaværdier, som giver den mindste penalty.
+errorArrays: errorData Et ErrorData-objekt som indeholder de error vektorer som skal plottes.
Metoder
LambdaPlusError() En konstruktor for klassen som genererer et LambdaPlusError-objekt.
12.7
Penalties
Definition
Denne klasse håndterer de fire penalties og deres funktioner.
Attributter
+baro: double En variabel med værdi til penalty for barotrauma.
+acid: double En variabel med værdi til penalty for acidose/alkalose.
+o2toxy: double En variabel med værdi til penalty for ilt toxicitet.
+oxy: double En variabel med værdi til penalty for dårlig oxygenering.
+total: double En variabel med værdi for den totale penalty.
Metoder
+Penalties() En konstruktor for klassen Penalties.
+calcBaro(double, double): double Metoden udregner penaltyværdi for barotrauma og returnerer den.
+calcOxy(double, double): double Metoden udregner penaltyværdi for dårlig oxygenering og returnerer den.
+calcAcid(double, double): double Metoden udregner penaltyværdi for acidose/alkalose og returnerer den.
+calcO2toxy(double, double): double Metoden udregner penaltyværdi for oxygentoxicitet og returnerer den.
+calcPenalty(PatientState, Lambda): double Metoden udregner den totale penaltyværdi og returnerer den.
12.8
Kliniker
Definition
Denne klasse håndterer de data, som klinikeren indtaster om sig selv i loginvinduet.
78
Kontrol-klasser
Attributter
+klinikernr: int Det nummer som klinikeren gemmes under i databasen.
+klinikerData: String : Fornavn, Efternavn, Afdeling, Anciennitet, Stillingbetegnelse.
Metoder
+Kliniker(String, String, String, String, String) En konstruktor for klassen Kliniker, som genererer et Kliniker objekt uden klinikernummer. Objektet bruges, når oplysningerne om klinikeren gemmes i databasen.
+Kliniker(int,String, String, String, String, String) En konstruktor for klassen Kliniker, som genererer et
Kliniker objekt med klinikernummer. Objektet bruges til at hente data fra databasen.
79
KAPITEL
13
Entity-klasser
I det følgende beskrives designet af klasserne LambdaGem og Database. Disse klasser hører alle til delsystemet
entity. Der er lagt vægt på en beskrivelse af designet af databasen og herefter beskrives klasserne med hensyn
til deres tilhørsforhold og dernæst den enkelte klasses attributter og metoder.
‹Œ .Ž)‘
’4“”
š ›?œ ž
Ÿ ž9 .¡9¢
¶4¦ «?·
¸¡9ž.¥ ®  ›.ž
£¤  ž. ¥ ¢.¦
Ÿ ž9 ¡9¢
©ª «9¢9¤ ¬
Ÿ ž9 ¡9¢
§ 9¨  ¥ ¤ ¢.¦
Ÿ ž9 ¡9¢
13.1
Ž)".• Œ –
— 9• ˜ • ™
­ ž9 ®  «9¤
¯"® «?® ¢
£¤  ž. ¥ ¢9¦
°
³¦ ¦ ›.¦
´$«?® «
« ®  ¢.ž ®
° ¯"® «?® ¢
š «.±²9 .«
¬.¤ ¡9µ³"¦ ¦ ›.¦
´« ® «
²9«?µ9¢
¢.ž9«9¤ ®  ¢9µ
š «.±²9 .«
š «.±²9 9«
¶¢.±
¯$¢ ® ®  ž9œ.µ
Database
Databasen skal opbygges af fire tabeller, som indeholder de data, der gemmes fra loginvinduet og klinikervinduet. Fra loginvinduet gemmes data om den kliniker, som logger på, og fra klinikervinduet gemmes de
respiratorindstillinger, som klinikeren godkender.
13.1.1
Overordnet struktur
Databasens fire tabeller skal indeholde alt data om klinikeren og de indstillinger vedkommende vælger at godkende. For at strukturere denne data anvendes fire tabeller: En som indeholder klinkerens oplysninger, en til
FiO2 -indstillinger, en til Vt-indstillinger og en til frekvens-indstillinger. De fire tabeller benævnes efterfølgende
med deres navn i databasen: Klinikerdata, FiO2_ setting, Vt_ setting og Frekvens_ setting.
I alle tabeller indgår en unik variabel kaldet KLINIKER_ NO, som tilskriver et nummer til hver kliniker. Dette
nummer muliggør, at der oprettes en relation mellem klinikerdata og de tre indstillingstabeller. Relationen
81
Entity-klasser
~
oprettes ved at anvende en ”primary key” og en ”foreign key”, som fortæller databasen, at data for et klinikernummer i en tabel hører til data for samme klinikernummer i en anden tabel. I Figur 13.1 illustreres dette
koncept.
Figur 13.1: Her er det illustreret hvorledes en ”primary key” peger på en ”foreign key” i en anden tabel og dermed opretter en
relation mellem de to tabeller. Figuren viser også den overordnede struktur mellem tabellerne. For enkelthedens
skyld er nogle kolonner udeladt af tabellerne, disse bliver dog beskrevet senere.
I det næste vil de enkelte tabeller bliver forklaret mere detaljeret.
13.1.2
Klinikerdata
Den første tabel skal indeholde alt data om klinikeren, hvilket drejer sig om fornavn, efternavn, anciennitet,
afdeling og stillingsbetegnelse. Dette betyder, at der anvendes en tabel som ser ud som Tabel 13.1.
KLINIKER_ NO
1
2
3
EFTERNAVN
Jensen
Petersen
Hansen
KLINIKERDATA
FORNAVN ANCIENNITET
Jens
6
Peter
8
Hans
9
AFDELING
AIOS
R
O
STILLING
Overlæge
Reservelæge
Overlæge
Tabel 13.1: Tabellen indeholdende alle de data som klinikeren giver om sig selv, når vedkommende logger ind for at bruge
Dr. Know. Første kolonne indeholder et nummer, som er tabellens primary key, det vil sige den nøgle der
sammenkæder tabellen med andre tabeller.
I tabellen KLINIKERDATA tilskrives hver kliniker et unikt nummer, som identificerer dem i de andre tabeller.
Her kunne klinikerens fornavn eller efternavn også være brugt, men p.g.a muligheden for at klinikere kan have
samme fornavn eller efternavn bruges i stedet et tal. Dette forudsætter, at der findes en algoritme, som sikrer,
at kun en kliniker kan have et bestemt nummer, ellers overskrives data. I det tilfælde af en anden kliniker har
brugt Dr. Know og fået tilskrevet nummeret 1, kan dette nummer ikke tilskrives den nye kliniker. Derfor må
der laves en rutine, der tjekker, hvor mange klinikere der har anvendt systemet, således at den nye kliniker
får det rigtige nummer tilknyttet. Dette gøres ved at lave en forespørgsel, som henter antallet af klinikere i
klinikerdata-tabellen ud og derefter lægger en til og gemmer den nye kliniker ved dette nummer. Dette nummer
er en ”primary key” i klinikerdata-tabellen.
82
Entity-klasser
13.1.3
Respiratorindstillinger
De sidste tabeller indeholder respiratorindstillingerne. Der er en tabel pr. indstillingsvariabel, dvs. en for FiO2 ,
en for Vt og en for frekvens. I det følgende vil kun tabellen for FiO2 bliver gennemgået, da opbygningen af de
tre tabeller er ens.
Tabellen for FiO2 skal indeholde en ”foreign key”, som kæder respiratorindstillingerne sammen med en kliniker i klinikerdata-tabellen.
Udover en ”foreign key” skal tabellen indeholde respiratorindstillingerne for hver af de 60 patientcases klinikeren skal bedømme. Tabellen for FiO2 kommer således til at se ud som Tabel 13.2.
FIO2_ SETTING
KLINIKER_ NO
1
2
3
PT_ GRUPPE
Intensiv
Intensiv
Intensiv
A_ 1
30
32
34
A_ 2
21
25
30
¹º¹º¹
¹º¹º¹
¹º¹º¹
¹º¹º¹
A_ 20
45
42
40
Tabel 13.2: Tabellen indeholdende alle de FiO2 indstillinger som klinikeren gemmer, når vedkommende trykker godkend i
klinikervinduet. Første kolonne indeholder et nummer, som er tabellens ”foreign key”.
I denne tabel indsættes klinikernummeret, når en kliniker trykker godkend ved første case.
Når der indsættes data i tabellen, kræves fire variable: Klinikerens nummer, patientgruppe, patientcasenummer
og respiratorindstillingsværdi. Patientcasenummeret er det, der bestemmer hvilken kolonne data skal i, da hver
patientcase har et nummer tilknyttet (A_ 1 til A_ 20).
Gemt data skal bruges i udviklervinduet, derfor skal data også kunne hentes ud. Derudover kræves det også, at
data kan sammenkædes med en kliniker. Fra udviklervinduet kan der vælges en specifik kliniker, hvorefter Dr.
Know skal kunne hente de data der hører til denne kliniker. Det er her, at tabellernes ”primary key” og ”foreign
key” anvendes i søgningen. Database kan bedes om at hente data fra to tabeller samtidigt. Derfor hentes data
ud fra indstillingstabellerne hvor ”foreign key” passer til den ”primary key” for den kliniker, der er valgt.
13.2
Database-klassen
Definition Denne klasse håndterer de værdier og informationer, som Dr. Know skal gemme for hver patientcase og for hver kliniker.
Attributter
-forbindelse:Connection Et objekt som etablerer forbindelse med databasen for Dr. Know.
-kommando:Statement Et objekt som kan bruges til at sende kommandoer og forespørgsler til databasen.
Kliniker:Kliniker Et objekt med klinikerens oplysninger om fornavn, efternavn, afdeling, anciennetet og stillingsbetegnelse.
-rowCount:int En variabel som indeholder antallet af klinikere i klinikerdatatabellen.
-indsatKlin:Kliniker Et objekt som indeholder alle data, der er indsat i klinikerdatatabellen.
+klinikerNummer:int En variabel som indeholder klinikerens nummer i tabellerne.
83
Entity-klasser
~
+patientGruppe:String En variabel som indikerer, hvilken patientgruppe patienten tilhører.
+caseNummer:int En variabel som indeholder et patientcasenummer.
+fio2Setting:double En variabel som indeholder informationer om den indstilling, klinikeren har indtastet for
FiO2 .
+frekvensSetting:double En variabel som indeholder informationer om den indstilling, klinikeren har indtastet for frekvens.
+vtSetting:double En variabel som indeholder informationer om den indstilling, klinikeren har indtastet for
Vt.
+ptGruppe:String En variabel som indeholder navnet for patientgruppen.
Metoder
+Database():Void En konstruktor for denne klasse og opsætter forbindelse til databasen for Dr. Know.
+indsaet(Kliniker):Kliniker En metode der gemmer oplysningerne om klinikeren i klinikerdatatabellen.
+opretCase(klinikerNummer, patientGruppe):Void En metode der opretter klinikeren og den valgte patientgruppe i fio2_ settings-, frekvens_ settings- og Vt_ settings-tabellerne. Alle værdier for respiratorindstillingerne sættes til nul.
+opdaterCase(klinikerNummer, patientGruppe, caseNummer, fio2Setting, vtSetting, frekvensSetting):Void
En metode der gemmer indstillingerne for FiO2 , Vt og frekvens i den dertil hørende casekolonne.
+hentKlinikerListe(ptGruppe):Kliniker[] En metode som henter de klinikere, der har udfyldt alle 20 patientcases.
+hentData(klinikerNummer):Settings[] En metode der henter de respiratorindstillinger, som klinikeren har
udfyldt.
13.3
LambdaGem
Definition Denne klasse håndterer de beregnede lambdaværdier, som Dr. Know skal lagre, når udvikleren
ønsker det.
Attributter
+Lambda:Lambda Et objekt med de udregnede lambdaværdier for barotraume, adicose/alkalose, oxygentoxicitet og dårlig oxygenering.
+Kliniker:Kliniker Et objekt med klinikerens oplysninger, som er fornavn, efternavn, afdeling, anciennitet og
stillingsbetegnelse.
+filnavn:String En variabel der indeholder det angivne filnavn.
+patientGruppe:String En variabel indeholdende patientgruppe.
Metoder
+LambdaGem():Void En konstruktor for denne klasse.
+gemEtEllerAndet(filnavn, Kliniker, Lambda):Void metoden gemmer objektet af typen Lambda på disk.
84
Entity-klasser
+indlaesEtellerAndet(filnavn):Lambda obj En metode der indlæser objektet Lambda fra en fil og returnerer
dette.
85
KAPITEL
14
Procesarkitektur
I dette kapitel er der konstrueret sekvensdiagrammer for udvalgte processer i Dr. Know. Formålet med dette er
at illustrere dataflowet i systemet, samt hvilke objekter der er aktive i den valgte proces.
14.1
Sekvensdiagrammer
Sekvensdiagrammet illustrerer den dynamiske sammenhæng mellem objekter, hvor essensen er, at beskeder der
bliver sendt mellem objekter illustreres. Horisontalt er de aktiverede objekter illustreret, mens deres livslinie
er illustreret vertikalt. Pilene viser de beskeder, der bliver sendt mellem objekterne. Det essentielle ved dette
diagram er, at det tidsmæssige perspektiv er inkluderet, hvor tiden forløber nedad i diagrammet. Objekternes
levetid er således visualiseret via de gråskraverede blokke. [6]
Et tryk på en knap, fra brugerens side, kan aktivere en række af aktiviteter. Det skal bemærkes at i de konstruerede diagrammer er processerne alle initieret af en brugerinteraktion, det være sig en aktivering af en knap på
brugergrænsefladen.
14.2
Klinikerfunktionaliteter
Funktionaliteterne for klinikeren er illustreret i sekvensdiagrammet se Figur 14.1 på den følgende side. De
enkelte processer der foregår er følgende: Klinikerens mulighed for at vælge en patientgruppe, hvorefter den
initierende tilstand for disse indlæses, klinikerens mulighed for at simulere patientvariable samt muligheden for
at godkende de valgte respiratorindstillinger.
I sekvensdiagrammet er processernes sekventielle flow illustreret, hvor det tidsmæssige perspektiv er medtaget.
87
Procesarkitektur
Figur 14.1: Sekvenssdiagram for klinikerfunktionaliteter. Diagrammet illustrerer det sekventielle flow i processen.
14.3
Udviklerfunktionaliteter
For udvikleren er der medtaget fem forskellige brugerinteraktioner, som ikke nødvendigvis forudsætter hinanden. Det drejer sig om følgende processer: Vælg patientgruppe og vælg kliniker, hvor der er mulighed for at
vælge en patientgruppe og efterfølgende en specifik kliniker for patientgruppen, beregn lambda, plot errorgraf
samt gem lambda og åben gemt lambda.
Sekvensdiagrammet for udviklerfunktioneliteterne er illustreret på Figur 14.2 på næste side.
88
Figur 14.2: Sekvensdiagram for udviklerfunktionaliteterne. Diagrammet illustrerer det sekventielle flow i processen.
Del IV
Implementering og Test
Formålet med denne del af rapporten er at dokumentere, hvorledes Dr. Know
er implementeret, samt at dokumentere hvorledes der er udført tests.
Kapitel 15 indeholder en redegørelse for, hvorledes der er lagt en strategi
for implementeringen af softwaresystemet.
Kapitel 16 beskriver, hvorledes implementeringen adskiller sig fra designet.
Kapitel 17 indeholder en beskrivelse af de patientcases, der implementeres
i systemet.
Kapitel 18 indeholder dokumentationen af Dr. Know samt screenshots fra de
forskellige GUIs.
Kapitel 19 beskriver de forskellige tests, der er udført for at verificere, at Dr.
Know fungerer som forventet.
91
KAPITEL
15
Implementeringsstrategi
Formålet med kapitlet er at beskrive realiseringen af Dr. Know, herunder hvilket programmeringssprog, databasesprog og programmeringsværktøj, Dr. Know er blevet realiseret i. Desuden angives den primære litteratur
anvendt til programmeringen.
15.1
Programmeringssprog
Et af formålene med dette projekt er at anvende objektbaserede metoder til analyse, design og implementering
af primært softwarebaserede løsninger til en sundhedsteknologisk problemstilling [16]. Der har i projektforløbet
været afholdt undervisning i UML 2 [6] og programmeringssproget Java. Valget af programmeringssprog i dette
projekt er Java, specielt da dette programmeringssprog er objektorienteret og derfor understøtter det beskrevne
formål med projektet.
Den valgte udgave er JavaT M 2 SDK Standard Edition Version 1.4.1.
Under programmeringen er følgende litteratur anvendt: [7], [12], [5] og [10].
15.2
Databasesprog
Til at lagre data i Dr. Know konstrueres en database. Databasen skal bygges op over en MySQL database. SQL
er et database sprog, som tillader brugeren at sende forespørgsler til databasen. SQL databasen er en såkaldt
”relational database”, hvilket betyder at data i tabellerne kan have en relation til hinanden. Dette bevirker, at
man ved at strukturere sin database fornuftigt kan undgå, at samme data optræder flere gange.
Det valgte databasesprog er SQL, som kører på en MySQL-database, der kan hentes gratis fra internettet.
93
Implementeringsstrategi
15.3
Programmeringsværktøj
Der eksisterer flere udviklingsmiljøer til at afvikle programmer i. I dette projekt er JCreator valgt, da det er et
simpelt og gratis udviklingsværktøj, der ligger lettilgængeligt på internettet.
Den valgte udgave er JCreator LE. [15]
94
KAPITEL
16
Implementering versus design
I dette kapitel beskrives, hvorledes implementeringen adskiller sig fra designet af Dr. Know. Det drejer sig
om tilføjelse af jar-filer, opsætning af databasen og plot af errorgraferne samt implementering af klasser fra
INVENT.
16.1
Jar-filer
Jar-filer er komprimerede klassefiler, det har været nødvendigt at implementere i Dr. Know. Det drejer sig om
VisualNumerics og ChartDirector, som efterfølgende beskrives.
16.1.1
VisualNumerics
Definition
16.1.2
ChartDirector
Definition
16.2
Pakken VisualNumerics indeholder matematiske funktioner som bruges ved udregning i INVENT.
Pakken ChartDirector bruges til opsætning og visualisering af errorgrafer i Dr. Know.
Implementerede klasser
Under implementeringen har det været nødvendigt at konstuere nogle flere klasser. Det drejer sig om Scattering,
DemoModule og DatabaseSetup. Disse beskrives efterfølgende.
95
Implementering versus design
16.2.1
Scattering
Definition Denne klasse laver de grafer, som bliver plottet efter beregning af lambda er udført. Klassen har ingen attributter eller indre klasser, men implementerer et interface ved navnet DemoModule. Klassen er konstrueret på baggrund af den eksterne klasse ChartDirector, som indeholder dette interface. Det er derfor nødvendigt
at overskrive de tre metoder, som interfacet indeholder.
Metoder
+getName():String Denne metode returnerer navnet til den chart, der bliver lavet.
+getNoOfCharts():int Denne metode returnerer antallet af chart.
+createChart(String,double[],double[],String,String): Denne metode bruger ikke den første string, men er
medtaget, idet metoden skal være den samme som i interfacet. De to double[] er de data, som bliver
plottet. De to sidste string er henholdsvis patientgruppe og label for x-aksen.
16.2.2
DemoModule
Definition
attributter.
Denne klasse håndterer de funktioner, som implementeres i klassen Scattering. Klassen har ingen
Metoder
-getName(): er en metode, der returnerer navnet til chart.
-getNoOfCharts(): er en metode, der returnerer antallet af chart, der skal lagres.
createChart(String, double[],double[],String, String): er en metode, der genererer en chart.
16.2.3
DatabaseSetup
Definition Denne klasse opsætter tabellerne i databasen. Disse tabeller skal indeholde oplysninger om klinikerne og respiratorindstillingerne. Denne klasse er en selvstående klasse, der fungerer uafhængigt af Dr. Know.
Attributter
+kliniker_no:int en unik variabel der identificerer klinikerne i tabellerne der indeholder respiratorindstillingerne.
+efternavn:String en variabel med klinikerens efternavn.
+fornavn:String en variabel med klinikerens fornavn.
+stilling:String en variabel med klinikerens stilling.
+afdeling:String en variabel med afdeling som klinikeren er tilknyttet til.
+anciennnitet:String en variabel med klinikerens anciennitet.
+pt_ gruppe:String en variabel som knytter respiratorindstillingerne til en patientgruppe.
+A_ 1 - A_ 20:double 20 variable som indeholder respiratorindstillingerne for de 20 patientcases.
96
Implementering versus design
+klinikerdata:Tabel Tabellen der indeholder oplysningerne om klinikerne. Variablene kliniker_ no, efternavn,
fornavn, stilling, afdeling og anciennitet hører til denne tabel.
+fio2_ settings:Tabel Tabllen der indeholder de indtastede respiratorindstillinger for Fi O2 . Variablene kliniker_ no, pt_ gruppe og A_ 1 til A_ 20 er indeholdt i denne tabel.
+frekvens_ settings:Tabel Tabllen der indeholder de indtastede respiratorindstillinger for respirationsfrekvensen.Variablene kliniker_ no, pt_ gruppe og A_ 1 til A_ 20 er indeholdt i denne tabel.
+vt_ settings:Tabel Tabllen der indeholder de indtastede respiratorindstillinger for tidalvolumen.Variablene
kliniker_ no, pt_ gruppe og A_ 1 til A_ 20 er indeholdt i denne tabel.
Metoder
+main():Void metoden som først etablerer en forbindelse til databasen og dernæst opretter og nulstiller klinikerdata-, fio2_ settings-, frekvens_ settings- og vt_ settings-tabellerne.
16.3
Klasser fra INVENT
Følgende klasser er alle implementeret fra INVENT. Klasserne håndterer simuleringsfunktionaliteten. Attributter og metoder er ikke beskrevet, da klasserne er konstruerede på forhånd i INVENT, og de implementeres
således direkte i Dr. Know.
16.3.1
Predictions
Definition
co2model.
16.3.2
o2model
Definition
16.3.3
Dette er klassen, der håndterer simuleringen ved at kalde klassen Blood og klasserne o2model og
Denne klasse indeholder den matematiske model for fysiologien omkring O2 -transport og -udveksling.
co2model
Definition Denne klasse indeholder den matematiske model for fysiologien omkring CO2 -transport og udveksling.
16.3.4
IO2Constants
Definition
16.3.5
Denne klasse indeholder de definerede konstanter, der anvendes i klassen for O2 -modellen.
Blood
Definition Denne klasse håndterer alle ligninger for blodet, der anvendes i simuleringen af blodets variable
for både arterielt og venøst blod.
97
KAPITEL
17
Patientcases
I det følgende er der opstillet 20 forskellige patientcases, som anvendes i Dr. Know. Formålet med dette afsnit
er at give læseren et indblik i de data Dr. Know, bygger sine beregninger på.
17.1
Strategi for udarbejdelse af patientcases
Det er valgt, at der skal udarbejdes 20 forskellige patientcases til anvendelse i Dr. Know. Tanken er at de 20
patientcases skal være ens for de tre patientgrupper. Herved bliver klinikeren gjort opmærksom på, at patientcasen tilhører en specifik patientgruppe og vedkommende skal således behandle patienten efter at denne tilhører
en specifik patientgruppe, selv om patient nummer 1 har de samme parameterværdier for postoperative hjertepatientgruppen, hjernetraumepatientgruppen og intensiv patientgruppen.
17.2
Standardværdier for patientcases
For at kunne konstruere patientcases for syge personer, er det nødvendigt at vide hvilke værdier der er standard
værdier for rakse personer. Disse værdier betegnes referenceværdier. Disse referenceværdier er udarbejdet i
samarbejde med afdelingslæge og anæstesiolog Charlotte Allerød. Det følgende skema viser alle disse standardværdier. Med ordet standard menes der ”normale” værdier for raske individer.
99
»
Patientcases
Parameter
Shunt
FA2
Vdead
Q
Compliance
Resistance
VO2
VCO2
DPG
Hb
COHb
MetHb
Temp.
Base Excess (BE)
Værdi
5,00
[0,60;0,90]
0,15
5,00
0,05
3,99
0,25
0,20
5,00
9,30
0,00
0,00
37,00
0,00
Enhed
%
fraktion
l
l/min
l/cmH2 O
cmH2 O/l/s
l/min
l/min
mmol/l
mmol/l
fraktion
fraktion
C
mmol/l
Rene påvirkninger
Herefter planlægges det at konstruere patientcases med forskellige påvirkninger, hvilke er: Kredsløbspåvirkede,
respiratorisk påvirkede, transfusionsbehandlede, hypovolæmibehandlede patienter samt patienter med abnorm
BE. Herefter kombineres disse påvirkninger, således at der bliver skabt 20 forskellige patientcases. Værdier for
de rene påvirkninger er illustreret i de efterfølgende tabeller.
Parametre for kredsløbspåvirkede patienter
Q
VO2
VCO2
< 2,00
< 0,15
< 0,12
l/min
l/min
l/min
Parametre for respiratorisk påvirkede patienter
Shunt
FA2
Vd
Compl.
Resis.
10 - 45
0,15 - 0,50
0,15 - 0,30
0,20 - 0,50
3,99
%
fraktion
l
l/cmH2O
cmH2O/i/s
Parametre for transfusionsbehandlede patienter
DPG
6-7
mmol/l
Parametre for hypovolæmi-behandlede patienter
Hb
DPG
5-7
3-5
100
mmol/l
mmol/l
»
Patientcases
Parametre for hyperdynamiske patienter
Q
VO2
VCO2
6 - 10
0,35 - 0,40
0,80 ¹ VO2
l/min
l/min
l/min
Parametre for patienter med abnorm BE
BaseExcess (BE)
(-)7 - 8
mmol/l
Parameterkombinationer
Her er listet, hvorledes der er konstrueret 20 forskellige patientcases med forskellige påvirkninger. Således
gives et bredt billede af de reelle patientcases klinikeren, møder i praksis. Afslutningsvis vil der være en samlet
tabel over de konstruerede patientcases.
Case 1: Kredsløbspåvirket patient.
Case 2: Respiratorisk påvirket patient.
Case 3: Hypovolæmi-behandlet patient.
Case 4: Hyperdynamisk patient.
Case 5: Kredsløb + respiratorisk patient.
Case 6: Kredsløb + hypovolæmi patient.
Case 7: Kredsløb + transfusions patient.
Case 8: Kredsløb + BE patient.
Case 9: Respiratorisk + hypovolæmi patient.
Case 10: Respiratorisk + transfusions patient.
Case 11: Respiratorisk + hyperdynamisk patient.
Case 12: Respiratorisk + BE patient.
Case 13: Kredsløb + hypovolæmi patient.
Case 14: Kredsløb + respiratorisk patient.
Case 15: Kredsløb + transfusions patient.
Case 16: Kredsløbspåvirket + BE patient.
Case 17: Respiratorisk patient.
Case 18: Respiratorisk + hypovolæmi patient.
Case 19: Respiratorisk + hyperdynamisk patient.
Case 20: Respiratorisk + BE patient.
101
»
Patientcases
Parameter / Case#
Shunt [%]
FA2 [fraktion]
Vd [l]
Q [l/min]
Compl. [l/cmH2O]
Resist. [cmH2O/i/s]
VO2 [l/min]
VCO2 [l/min]
DPG [mmol/l]
Hb [mmol/l]
COHb [fraktion]
MetHb [fraktion]
Temp. [C]
Base Ex. [mmol/l]
1
5,0
0,70
0,15
2,00
0,05
3,99
0,12
0,09
5,00
9,30
0,00
0,00
37
0,00
2
30,0
0,45
0,20
5,00
0,03
3,99
0,25
0,20
5,00
9,30
0,00
0,00
37
0,00
3
5,0
0,60
0,15
5,00
0,05
3,99
0,25
0,20
3,00
5,50
0,00
0,00
37
0,00
4
5,0
0,70
0,15
9,00
0,04
3,99
0,37
0,30
5,00
9,30
0,00
0,00
37
0,00
5
15,0
0,15
0,18
2,50
0,05
3,99
0,08
0,06
5,00
9,30
0,00
0,00
37
0,00
6
5,0
0,80
0,15
1,80
0,05
3,99
0,11
0,09
4,00
5,00
0,00
0,00
37
0,00
7
5,0
0,60
0,15
1,50
0,05
3,99
0,10
0,08
6,50
9,30
0,00
0,00
37
0,00
8
5,0
0,65
0,15
2,05
0,05
3,99
0,07
0,05
5,00
9,30
0,00
0,00
37
-5
9
20,0
0,35
0,25
5,00
0,04
3,99
0,25
0,20
4,00
5,00
0,00
0,00
37
0,00
10
30,0
0,30
0,20
5,00
0,03
3,99
0,25
0,20
7,00
9,30
0,00
0,00
37
0,00
Parameter / Case#
Shunt [%]
FA2 [fraktion]
Vd [l]
Q [l/min]
Compl. [l/cmH2O]
Resist. [cmH2O/i/s]
VO2 [l/min]
VCO2 [l/min]
DPG [mmol/l]
Hb [mmol/l]
COHb [fraktion]
MetHb [fraktion]
Temp. [C]
Base Ex. [mmol/l]
11
35,0
0,30
0,15
8,50
0,04
3,99
0,37
0,31
5,00
9,30
0,00
0,00
37
0,00
12
25,0
0,20
0,20
5,00
0,03
3,99
0,25
0,20
5,00
9,30
0,00
0,00
37
-3,0
13
5,0
0,70
0,15
1,90
0,05
3,99
0,13
0,11
3,50
5,50
0,00
0,00
37
0,00
14
15,0
0,30
0,20
2,00
0,03
3,99
0,14
0,09
5,00
9,30
0,00
0,00
37
0,00
15
5,0
0,65
0,15
1,80
0,05
3,99
0,14
0,11
6,70
9,30
0,00
0,00
37
0,00
16
5,0
0,85
0,15
2,00
0,05
3,99
0,07
0,10
5,00
9,30
0,00
0,00
37
5,00
17
35,0
0,25
0,20
5,00
0,03
3,99
0,25
0,20
5,00
9,30
0,00
0,00
37
0,00
18
30,0
0,30
0,20
5,00
0,04
3,99
0,25
0,20
3,50
6,50
0,00
0,00
37
0,00
19
30,0
0,30
0,27
9,50
0,02
3,99
0,35
0,30
5,00
9,30
0,00
0,00
37
0,00
20
15,0
0,45
0,25
5,00
0,04
3,99
0,25
0,20
5,00
9,30
0,00
0,00
37
6,00
102
KAPITEL
18
Dokumentation af Dr. Know
I dette kapitel forefindes dokumentation af Dr. Know, hvilket vil være i form af screenshots. Der vil være screenshots af loginvindue, klinikervindue, udviklervindue, hjælpvindue samt et screenshot af terminalen fra databasen. Formålet med dette afsnit er, at give et overblik over samt visuel dokumentation for, hvorledes Dr. Know
er implementeret.
18.1
Screenshots
I det efterfølgende er illustreret screenshots fra forskellige brugergrænseflader i Dr. Know. Der vil dog ikke
foreligge screenshots af de tre grafvinduer, da disse forefindes i testafsnit 19.5.2 på side 120.
Database
Figur 18.1: Screenshot af oprettelse af databaseserver med navnet drknow.
103
»
Dokumentation af Dr. Know
Klinikervindue
Figur 18.2: Screenshot af Dr. Know: Kliniker. Dette screenshot viser klinikerdelen af Dr. Know, når en patientcase er simuleret med de givne respiratorindstillinger.
104
»
Dokumentation af Dr. Know
Udviklervindue
Figur 18.3: Screenshot af Dr. Know: Udvikler. Dette screenshot viser udviklerdelen af Dr. Know, når patientgruppen er
valgt til at være ”Hjernetraume patient”.
105
»
Dokumentation af Dr. Know
Hjaelpvindue
Figur 18.4: Screenshot af hjælpvindue.
Loginvindue
Figur 18.5: Screenshot af Dr. Know: Login. De to screenshots viser Dr. Know: Login når henholdvis kliniker og udvikler
er valgt som bruger. Når kliniker er valgt skal brugeroplysningerne udfyldes. Hvis udvikler er valgt gråskaleres
disse felter.
106
KAPITEL
19
Test
Dette kapitel handler om de tests, der udføres for at tjekke at Dr. Know virker uden fejl. Først gives en beskrivelse af de forskellige tests, som kan udføres ifølge UML, samt en beskrivelse af udførslen og testresultaterne.
Formålet med kapitlet er at redegøre for, om Dr. Know lever op til krav, der er stillet i analyse- og designprocesserne.
19.1
Typer af tests
For at sikre en god funktionalitet bør et system gennemgå følgende test: modultest, integrationstest, systemtest
og accepttest.
En modultest betyder, at enhver eller en gruppe af klasser bliver testet selvstændigt. I dette projekt er modultest
udført løbende i programmeringsprocessen, og testresultaterne er derfor ikke fremlagt.
En integrationstest integrerer komponenter og klasser med hinanden med den fordel at finde eventuelle fejl
for kun delmængder af klasser og komponenter. Denne test udføres på basis af usecases (se afsnit 4.3 på
side 27). Ved at implementere usecases én ad gangen og herefter teste funktionaliten for denne, medfører
dette også integration af diverse klasser med hinanden. Dette kapitel fremlægger udelukkende resultater af
integrationstesten.
En systemtest ser systemet som en ”sort boks”. En systemtest tester, at alle komponenter og klasser virker
sammen, som det er forventet af brugeren. Systemtest er udført i samarbejde med en kliniker, og resultaterne
for testen findes i diskussionsdelen af rapporten (se kapitel 19.4.1 på side 119).
En accepttest er stort set den samme som systemtest, den udføres blot af rekvirenten af systemet. Accepttesten
er ikke udført.
107
»
Test
19.2
Integrationstest: Test af usecases
I dette afsnit beskrives de tests, der er lavet ved at integrere de definerede usecases. Hermed testes det, at
funktionaliteten er som beskrevet i analysen (se afsnit 6 på side 33). For hver usecase vil de kaldte metoder
blive beskrevet mht. funktion, samt hvorledes usecasen testes og resultaterne heraf.
19.2.1
Vælg brugertype
Denne usecase giver mulighed for at vælge mellem to brugertyper fra loginvinduet. Såfremt der vælges ”Kliniker” skal der udfyldes oplysninger om klinikeren. Hvis en eller flere oplysninger mangler, skal der komme
en besked, som gør brugeren opmærksom herom. Vælges brugertypen ”Udvikler”, skal felterne til brugeroplysninger gråskaleres, så disse ikke kan anvendes. Når brugeren trykker på ”OK”-knappen, skal loginvinduet
lukkes og enten klinikervinduet eller udviklervinduet åbnes, afhængig af hvilken type bruger der er valgt. Er
brugeren en kliniker skal der også etableres forbindelse til databasen, og klinikerens oplysninger skal gemmes
i klinikerdata-tabellen. Hvis der ikke opnås forbindelse til databasen, skal der gives en fejlbesked.
Metoder
I forbindelse med test af usecasen ”Vælg brugertype” bliver følgende metoder og komponenter testet:
LoginVindue BoksBrugerKontrol, HaendelseKontrol.
Database indsaet.
Test
I usecasen ”Vælg brugertype” udføres følgende tests:
1. Udvikler vælges Her testes, om tekstfelterne gråskaleres, når bruger vælges som ”Udvikler”. Herefter trykkes ”OK” og udviklervinduet skal åbnes.
2. Kliniker vælges Her testes, om tekstfelterne aktiveres når bruger vælges som ”Kliniker”.
3. Manglende klinikeroplysninger Her testes om Dr. Know giver en fejlbesked, hvis klinikeren mangler at
indtaste en eller flere oplysninger. Der indtastes alle oplysninger på nær fornavn, hvilket skal give en
fejlbesked. Testen gentages for alle de oplysninger, klinikeren skal indtaste.
4. KlinikerVinudue åbnes Alle klinikeroplysninger indtastes, og der testes om klinikervinduet åbnes, når der
trykkes ”OK”.
5. Klinikeroplysninger gemmes Alle klinikeroplysninger udfyldes, og der trykkes ”OK”. Det undersøges, om
klinikeroplysningerne forefindes i klinikerdata-tabellen i databasen.
6. Klinikeroplysninger gemmes uden database er opsat Alle klinikeroplysninger gemmes og der trykkes ”OK”.
Dr. Know skal give en fejlbesked, som fortæller klinikeren, at der er problemer med databasen.
Resultater
Resultaterne for test af usecasen ”Vælg brugertype” ses i Tabel 19.1 på modstående side.
108
»
Test
Testnummer
1
2
3
4
5
6
Testparametre
Bruger er ”Udvikler”
Bruger er ”Kliniker”
Manglende fornavn
Alle oplysninger er givet
Alle oplysninger er givet
Alle oplysninger er givet
Forventet resultat
Udvikler vinduet åbnes
Tekstfelter aktiveres
Fejlbesked
Kliniker vinduet åbnes
Oplysninger er gemt
Fejlbesked
Testresultat
¼
¼
¼
¼
¼
¼
Tabel 19.1: Testresultater for usecasen ”Vælg brugertype”.
19.2.2
Vælg patientgruppe
Usecasen ”Vælg patientgruppe” bruges hhv. i klinikervinduet og i udviklervinduet. I klinikervinduet indlæses
den første case i patientgruppen automatisk, når en valid patientgruppe vælges. I udviklervinduet skal man
kunne vælge at beregne data for én kliniker eller alle klinikere.
Metoder
I forbindelse med test af usecasen ”Vælg patientgruppe” bliver følgende metoder og komponenter testet:
KlinikerVindue: kontrolPatientGruppe.
UdviklerVindue: kontrolPatientgruppe.
Database: hentKlinikerListe.
Test
I usecasen ”Vælg patientgruppe” udføres følgende tests:
1. Patientgruppe vælges: Der kontrolleres, om der ved valg af patientgruppe indlæses den første patientcase
for gruppen. Dette skal også ske, hvis klinikeren forinden har været i gang med en anden patientgruppe.
2. Invalid valg Hvis ”Vælg patientgruppe” strengen vælges i kombinationsboksen, skal der vises en fejlbesked.
3. Liste med klinikere hentes: Ved valg af en valid patientgruppe i udviklervinduet, skal metoden hentKlinikerListe returnere en array med klinikerdata.
4. Liste med klinikere vises: Fornavn og efternavn elementer i klinikerdata array vises i en kombinationsboks.
Resultater
Resultaterne for test af usecasen ”Vælg patientgruppe” ses i Tabel 19.2 på næste side.
19.2.3
Hjælp
I usecasen ”Hjælp” kontrolleres det, at alle hjælpknapper på alle vinduer fremkalder hjælpvinduet.
109
»
Test
Testnummer
1
2
3
4
Testparametre
Patientgruppe valgt
"Vælg patientgruppe"valgt
Patientgruppe valgt
Patientgruppe valgt
Forventet resultat
Første patientcase indlæses
Fejlbesked vises
En array med klinikeroplysninger returneres
Fornavn og efternavn vises i
comboboks
Testresultat
¼
Kun efter valg af gruppe
¼
¼
Tabel 19.2: Testresultater for usecasen ”Vælg patientgruppe”.
19.2.4
Metoder
I forbindelse med test af usecasen Hjælp bliver følgende metoder og komponenter testet:
Alle GUI Klasser: hjælpKnap.
Test
I usecasen ”Hjælp” udføres følgende tests:
1. Visning af hjælp vindues: Hjælpknappen aktiveres på alle vinduer, og det kontrolleres om hjælpvinduet
vises.
Resultater
Resultaterne for test af usecasen ”Hjælp” ses i Tabel 19.3.
Testnummer
1
Testparametre
Hjælpknap trykkes
Forventet resultat
HjælpVindue vises
Resultat af test
¼
Tabel 19.3: Testresultat for usecasen ”Hjælp”.
19.2.5
Afslut
I denne usecase testes afslut-funktionen for Dr. Know i login-, kliniker- og udviklervinduet. I alle vinduer findes
der to muligheder for at afslutte programmet, én ved krydset op i vinduets højre hjørne og én ved en afslutknap
i bunden af vinduet. Inden Dr. Know afsluttes, skal der vises en dialogboks for brugeren, som skal bekræfte, at
der ønskes at afslutte.
Metoder
I forbindelse med test af usecasen ”Afslut” bliver følgende metoder og komponenter testet:
Alle GUI Klasser: showOptionDialog, systemExit, afslutKnap.
110
»
Test
Test
I usecasen Afslut udføres følgende tests:
1. Afslutknap testes: Afslutknap trykkes, og der vises besked om at bekræfte afslutningen.
2. Vinduelukningskryds testes: Vinduelukningskryds testes på alle vinduer, og det kontrolleres om de forventede dialogbokse vises.
3. Afslutning bekræftes i klinikervindue, udviklervindue og hjælpvindue
4. Afslutning bekræftes i LoginVindue Hvis ”Afslut” vælges i dialogboksen, skal hele systemet afsluttes.
5. Aflutning bekræftes ikke Hvis "Annulér"vælges i dialogboksen, skal dialogboksen lukkes og brugeren føres tilbage til vinduet.
Resultater
Resultaterne for test af usecasen ”Afslut” ses i Tabel 19.4.
Testnummer
1
2
3
4
5
Testparametre
Afslutknap er valgt
Kryds er valgt
"Afslut"valgt
"Afslut"valgt
"Annulér"valgt
Forventet resultat
Dialogboks vises
Dialogboks vises
LoginVindue vises
System afsluttes
Dialogboks lukkes
Resultat af test
¼
Ikke dialogboks, systemet afsluttes
¼
¼
¼
Tabel 19.4: Testresultater for usecasen ”Afslut”.
19.2.6
Skift bruger
Denne usecase giver klinikeren mulighed for at skifte bruger inde fra klinikervinduet. Dette betyder, at klinikervinduet lukkes og data mistes, hvis dette ikke er gemt. Brugeren skal derfor have mulighed for at fortryde og
vende tilbage klinikervinduet. Ønsker brugeren at fortsætte, skal Dr. Know tjekke om nuværende case er godkendt og giver således brugeren mulighed for at godkende, såfremt casen ikke er godkendt på forhånd. Herefter
lukkes klinikervinduet og loginvinduet åbnes.
Metoder
I forbindelse med test af usecasen ”Skift bruger” bliver følgende metoder og komponenter testet:
KlinikerVindue HaendelseKontrol, skiftBruger, godkendCase, skrivVariable, hentCaseNummer, hentSettings.
Database opretCase, opdaterCase.
Test
I usecasen ”Skift bruger” udføres følgende tests:
111
»
Test
1. Acceptér skifte med godkendt case Der trykkes på ”Skift bruger”-knappen, og når Dr. Know spørger om
der skal fortsættes, accepteres det. Herefter lukker klinikervinduet og loginvinduet åbner.
2. Acceptér skifte uden godkendt case Der trykkes på ”Skift bruger”-knappen, og når Dr. Know spørger om
der skal fortsættes, accepteres det. Herefter vises en dialogboks, som giver mulighed for at gemme eller
at fortsætte uden at data gemmes, og dermed lukker klinikervinduet og loginvinduet åbner.
3. Fortryd skifte Der trykkes på ”Skift bruger”-knappen, og når Dr. Know spørger om der skal fortsættes,
fortrydes dette, og der vendes tilbage til klinikervinduet.
Resultater
Resultaterne for tests i usecasen ”Skift bruger” ses i Tabel 19.5.
Testnummer
1
2
Testparametre
Case er godkendt
Case er ikke godkendt
3
Anvend ”Nej”-knappen
Forventet resultat
LoginVinduet åbnes
Giver mulighed for at godkende
Vender tilbage til KlinikerVinduet
Testresultat
¼
ikke ved 1. case
¼
Tabel 19.5: Testresultater for usecasen ”Skift bruger”.
19.2.7
Vælg patientcase
Usecasen giver brugeren mulighed for at vælge en bestemt patientcase. Her tjekker systemet, at der er valgt en
gyldig patientgruppe inden casen indlæses.
Metoder
I forbindelse med test af usecasen ”Vælg patientcase” bliver følgende metoder og komponenter testet:
KlinikerVindue kontrolPatientGruppe, kontrolPatientNummer, skrivVariable.
Test
I usecasen ”Vælg patientcase” udføres følgende tests:
1. Valg af casenummer uden patientgruppe Der vælges casenummer ”2” fra casenummervælgeren. Der er
ikke valgt en gyldig patientgruppe, og dermed skal Dr. Know give en fejlbesked, der fortæller at der ikke
er valgt en gyldig patientgruppe.
2. Valg af casenummer med patientgruppe Der vælges casenummer ”2” fra casenummervælgeren. Der er
valgt en gyldig patientgruppe, og dermed skal Dr. Know indlæse den pågældende patientcase.
Resultater
Resultaterne for test af usecasen ”Vælg patientcase” ses i Tabel 19.6 på næste side.
112
»
Test
Testnummer
1
2
Testparametre
Patientgruppe er ”Vælg patient”, casenummer er ”1”
Patientgruppe er ”Hjernetraume patient”, casenummer er ”2”
Forventet resultat
Fejlbesked
Indlæs patientcase nr. 2
Testresultat
¼
¼
Tabel 19.6: Testresultater for usecasen ”Vælg patientcase”.
19.2.8
Simulér patientvariable
Denne usecase sørger for simulerering af patientvariable ud fra klinikerens respiratorindstillinger og patientparametrene. Der kontrolleres, om klinikeren har givet alle indstillinger, ellers bruges Dr. Know’s forslag til respiratorindstillingen. Herefter beregnes patientvariablene, løsningen vises på skærmen og ”Godkend”-knappen
aktiveres. Finder Dr. Know ingen løsning ved beregningen, gives en fejlbesked til klinikeren.
Metoder
I forbindelse med test af usecasen ”Simulér patientvariable” bliver følgende metoder og komponenter testet:
KlinikerVindue HaendelseKontrol, simuleringFunktion, hentCaseNummer, hentSettings, skrivVariable.
PatientState genererePatientState.
Prediction calculatePrediction.
Test
I usecasen ”Simulér” udføres følgende tests:
1. Simuléring uden alle respiratorindstillinger Her aktiveres Simulérknap, hvor en eller flere af indstillingerne ikke er udfyldt. Her skal Dr. Know bruge dets eget forslag og simulere med dette. Der vil være en
løsning, hvor Dr. Know’s forslag er brugt. Denne test gennemgås for alle tre indstillinger.
2. Simuléring med alle respiratorindstillinger Her aktiveres Simulérknap med alle indstillinger udfyldt. Dr.
Know vil give en løsning.
3. Simulering uden løsning Idet der kan komme urealistiske indtillinger, kan det ske at der ikke findes en
løsning. Denne test forsøger blot at tjekke, om der fremkomer en fejlbesked, som fortæller at der ikke
findes en løsning.
Resultater
Resultaterne for test af usecasen ”Simulér patientvariable” ses i Tabel 19.7 på den følgende side.
19.2.9
Godkend indstilling
Denne usecase anvendes, når klinikeren ønsker at godkende de respiratorindstillinger, vedkommende har indtastet. Inden indstillingerne gemmes i databasen, kontrolleres det om alle indstillinger er angivet. Mangler
113
»
Test
Testnummer
1
2
3
Testparametre
Manglende FiO2
Casenr. 1, FiO2 = 21, Vt =
0.4, frekvens = 12
Casenr. 1, FiO2 = 10, Vt =
0.3, frekvens = 8
Forventet resultat
Løsning vises på skærmen
Løsning vises på skærmen
Fejlbesked
Testresultat
¼
¼
¼
Tabel 19.7: Testresultater for usecasen ”Simulér patientvariable”.
klinikeren at udfylde en indstilling, anvendes Dr. Know’s forslag hertil. Herefter etableres en forbindelse til
databasen og casen gemmes i indstillingstabellen. Hvis der ikke opnås forbindelse til databasen, gives der en
fejlbesked.
Efter patientcasen er godkendt, indlæses næste patientcase, og Godkendknappen deaktiveres indtil klinikeren
har simuleret denne case.
Metoder
I forbindelse med test af usecasen ”Godkend indstilling” bliver følgende metoder og komponenter testet:
KlinikerVindue HaendelseKontrol, godkendCase, skrivVariable, hentCaseNummer, hentSettings.
Database opretCase, opdaterCase.
Test
I usecasen ”Godkend indstilling” udføres følgende tests:
1. Godkend case uden alle indstillinger Efter der er simuleret, trykkes der ”Godkend” uden at alle indstillinger er udfyldt. Casen gemmes og der tjekkes om indstillingerne findes i databasen.
2. Godkend case med alle indstillinger Efter der er simuleret, trykkes der ”Godkend” med alle indstillinger
udfyldt. Casen gemmes og der tjekkes om indstillingerne findes i databasen.
3. Godkend case uden database er opsat Efter der er simuleret, trykkes der ”Godkend” med alle indstillinger
udfyldt. Dette skal give en fejlbesked, som fortæller klinikeren, at der er et problem med at få forbindelse
til databasen.
4. Godkend og indlæs næste case Efter der er simuleret, trykkes der ”Godkend” med alle indstillinger udfyldt. Casen gemmes og næste case vil blive indlæst.
Resultater
Resultaterne for test af usecasen ”Godkend indstilling” ses i Tabel 19.8 på næste side.
19.2.10
Vælg kliniker
I usecasen ”Vælg kliniker” skal klinikeroplysningerne vises i udviklervinduet. Derudover sørger den for, at
indstillinger for lambdaberegning hentes for den kliniker, der skal beregnes for.
114
»
Test
Testnummer
1
2
3
4
Testparametre
Manglende FiO2
Alle indstillinger er udfyldt
Manglende database
Alle indstillinger er udfyldt
Forventet resultat
Casen gemmes
Casen gemmes
Fejlbesked
Næste case indlæses
Testresultat
¼
¼
¼
¼
Tabel 19.8: Testresultater for usecasen ”Godkend indstilling”.
Metoder
I forbindelse med test af usecasen ”Vælg kliniker” bliver følgende metoder og komponenter testet:
UdviklerVindue klasse kontrolKliniker.
Database klasse hentData.
Test
I usecasen ”Vælg kliniker” udføres følgende tests:
1. Vis klinikeroplysninger Her kontrolleres, at de rigtige oplysninger om den valgte kliniker hentes i databasen og vises på de tilhørende felter på udviklervinduet.
2. Indstillinger hentes Inden beregning af lambda foretages skal respiratorindstillinger hentes fra databasen.
Hvis en kliniker er valgt, skal der kun returneres indstillinger for den kliniker.
Resultater
Resultaterne for test af usecasen ”Vælg kliniker” ses i Tabel 19.9.
Testnummer
Testparametre
Forventet resultat
1
En kliniker valgt
2
Database søger kun efter en
kliniker
Klinikeroplysninger vis på
vindue
Kun indstillinger for den
valgte kliniker returneres
Resultat af test
¼
¼
Tabel 19.9: Testresultater for usecasen ”Vælg kliniker”.
19.2.11
Beregn lambda
I test af usecasen ”Beregn lambda” kontrolleres det, at beregningen kun kan foregå, hvis der er fundet data
for den valgte patientgruppe. Efter at beregningen er startet, skal der vises en statusindikator i form af antal
kombinationer, der er beregnet. Når beregningen er færdig, skal det kontolleres, at lambdaværdierne indsættes
i de rigtige tekstfelter på udviklervinduet, og at errorgraferne kan vises ved at der trykkes på de tilhørende
grafknapper.
115
»
Test
Metoder
I forbindelse med test af usecasen ”Beregn Lambda” bliver følgende metoder og komponenter testet:
LambdaPlusError Klasse: beregnlambda.
UdviklerVindue Klasse: Beregn, beregningAfLambda, visProcess.
LambdaPlusError Klasse: findMinimum, findMaximum
Test
I usecasen ”Beregn lambda” udføres følgende tests:
1. Valg af patientgruppe uden data Der vælges en patientgruppe, hvor der ikke er nogen patientcases udfyldt,
og det kontrolleres, om der vises en besked som fortæller, at ingen data findes for patientgruppen.
2. Valg af patientgruppe med data Der vælges en patientgruppe, hvor der findes udfyldte patientcases. Efter
valget skal Beregn-knappen visualiseres for brugeren.
3. Statusindikator testes Det kontrolleres, at statusindikatoren opdateres for hver kombination.
4. Errorgrafer testes Det testes ved at give nogle fiktive data, og det kontrolleres om data plottes, og om den
udregnede middelværdi (µ) og standarddeviationen (σ) er korrekte.
Resultater
Resultaterne for test af usecasen ”Beregn lambda” ses i Tabel 19.10.
Testnummer
Testparametre
Forventet resultat
1
2
3
Patientgruppe uden data
Patientgruppe med data
Kombinationer
4
To arrays
Besked til bruger
Beregnknap aktiveres
Opdateres for enhver kombination
Plottes med µ og σ
Resultat af test
¼
¼
¼
¼
Tabel 19.10: Testresultater for usecasen ”Beregn lambda”.
19.2.12
Gem lambda
I denne usecase skal der testes, om dialogboksen til lagring af lambda vises de rigtige steder. Brugeren skal kun
have mulighed for at gemme lambda, efter at beregning er foretaget. Det testes, om der skrives de rigtige linier
i filen og at lambdaværdierne kan gemmes uden fejl, selv om der ikke er valgt nogen kliniker. Derudover skal
det kontrolleres, at filen gemmes det valgte sted på harddisken.
Metoder
I forbindelse med test af usecasen ”Gem lambda” bliver følgende metoder og komponenter testet:
LambdaGem Klasse: gemEtEllerAndet.
116
»
Test
UdviklerVindue Klasse: gemLambda, showDialog, saveLambda.
Test
I usecasen ”Gem lambda” udføres følgende tests:
1. Gem dialog intitieres Ved tryk på gem knappen skal der vises en gem dialog.
2. Gem for en kliniker Efter at en specifik kliniker er valgt, gemmes beregnet data. Filen kontrolleres og skal
som default gemmes under C:/ og indeholde følgende linier: Linie 1: Patientgruppe, linie 2-6: Klinikeroplysninger, linie 7-10: Lambdaværdier
3. Gem for alle klinikere Ingen kliniker er valgt, og der beregnes for alle klinikere. Filen skal gemmes under
C:/ og linie 2-6 skal indeholde en tom string.
Resultater
Resultaterne for test af usecasen ”Gem lambda” ses i Tabel 19.11.
Testnummer
1
2
3
Testparametre
Gemknap er valgt
Kliniker valgt
Ingen kliniker valgt
Forventet resultat
En gem dialaog vises.
Patientgruppe, lambdaværdier og klinikeroplysninger
gemmes
Patientgruppe og lambdaværdier gemmes i en tesktfil
Resultat af test
¼
Gemmes i installationsmappe
Gemmes i installationsmappe
Tabel 19.11: Testresultater for usecasen ”Gem lambda”.
19.2.13
Åbn gemt lambda
I usecasen ”Åbn gemt lambda” testes, at filåbningsdialogen altid kan åbnes fra udviklervinduet. Det skal kontrolleres, at linierne fra filen bliver indsat på de rigtige pladser i vinduet.
Metoder
I forbindelse med test af usecasen ”Åbn gemt lambda” bliver følgende metoder testet. Metoden showDialog er
den samme som for usecasen”Gem lambda”:
LambdaGem Klasse: indlaesEtEllerAndet.
UdviklerVindue Klasse: showDialog, getLambda.
Test
I usecasen ”Åbn gemt lambda” udføres følgende tests:
117
»
Test
1. Åbn dialog initieres Der trykkes på Åbn-knappen inden og efter, at beregning er foretaget og en tidligere
gemt fil åbnes. Som default skal dialog boksen åbnes i C:/.
2. Filindhold indtastes Den ønskede fil vælges, og det kontolleres at de rigtige linier i filen kommer på sin
plads i udviklervinduet. Linierne skal fordeles i følgende tekstfelter:
½
linie 1 = bruges ikke
½
linie 2 = fieldFornavn
½
linie 3 = fieldEfternavn
½
linie 4 = fieldAfdeling
½
linie 5 = fieldStillingsbetegnelse
½
linie 6 = fieldAnciennitet
½
linie 7 = fieldAcidose/Alkalose
½
linie 8 = fieldBarotraume
½
linie 9 = fieldOxygenering
½
linie 10 = fieldIlttoxitet
Resultater
Resultaterne for test af usecasen ”Åbn gemt lambda” ses i Tabel 19.12.
Test
1
2
Testparametre
Forventet resultat
Resultat af test
Åbn gemt lambda knap er
valgt
Fil med valid indhold
En åbn fil dialaog vises.
¼
Indholdet i filen skal indlæses i de tilhørende tekstfelter
¼
Tabel 19.12: Testresultater for usecasen ”Åbn gemt lambda”.
19.3
Test af DatabaseSetup
Dette er ikke en usecase, men en selvstående fil som anvendes i installationen af Dr. Know. Filen opsætter
databasen, så den indeholder alle de tabeller, som skal anvendes af Dr. Know. Denne fil skal derfor eksekveres,
inden de andre tests kan foretages. Funktionaliteten af denne fil kontrolleres ved at anvende en grafisk SQLadminstrator. Den vil vise, om tabellerne er oprettet med de rigtige atributter.
Resultat
Via MySQL-prompten ses det, at alle tabeller er oprettet med de rigtige attributter. Det konkluderes, at filen
virker som tiltænkt.
118
»
Test
19.4
Test af systemeffektivitet
Implementeringen af Dr. Know følger løsningstrategien, som er beskrevet i kapitel 3.2 på side 20. Løsningsstrategien lægger op til, at Dr. Know skal gennemløbe alle kombinationer af respiratorindtillinger og lambdakombinationer. Beregningstiden for respiratorindstillingerne og lambdaværdierne afhænger af stepstørrelsen på både
respiratorindstillingerne og lambdaværdierne. Det vælges derfor at teste beregningstiden, for at se hvor lang tid
beregningsalgoritmen bruger på beregningen. Følgende værdier for stepstørrelse vælges i første omgang:
Lambda
FiO2
Vt
f
Step
0,1
0,1
0,1
1,0
Med denne stepstørrelse findes det, at beregningstiden bliver for lang. Beregningstiden for at finde den bedste
kombination af respiratorindstillinger for én patientcase bliver ca. 90 minutter på en 1000MHz AMD Athlon
med 256 MB RAM. Idét der er 20 patientcases, tager det for computeren ca. 20 ¹ 90 minutter (ca. 30 timer) at
beregne respiratorindstillingen for en kombination af lambdaværdier.
Et lambdastep på 0,1 giver i alt 84 kombinationer af lambdaværdier (summen af lambda skal være 1), hvilket
betyder, at beregningstiden bliver 84 ¹ 20 ¹ 90 minutter svarende til ca. 3 1/2 måned. Dette vurderes til at være en
for lang beregningsproces, især i betragtning af den relativt dårlige opløsning, og det ses derfor nødvendigt med
en optimering af beregningsalgoritmen. Denne optimering undersøges, inden den endelige systemtest foretages.
19.4.1
Optimering af beregningstid
For at kunne løse problemet med en for lang beregningstid er det nødvendigt med en hurtigere beregningsalgoritme, der dermed kan give mulighed for en bedre opløsning.
Den udviklede algoritme i Dr. Know er konstrueret således, at den undersøger funktionen stykvis. Algoritmen
starter med at undersøge de to yderste punkter i intervallet for hver respiratorindstilling, FiO2 , Vt og f. Algoritmen har således to yderpunkter og finder det midterste punkt mellem disse. Dette giver i alt 3 punkter for hver
af de tre respiratorindstillinger, som kombineres indbyrdes. Området omkring det punkt, som giver den mindste
penalty, undersøges med et step som er halvdelen af det første step. Der findes således tre nye punkter, og det
punkt som giver den mindste penalty bruges som nyt middelpunkt for indstillingen. Denne halvering af steps
fortsætter, indtil steppet er halveret ned til den valgte step for den indstilling. Det punkt, som giver den mindste
penalty ved denne undersøgelse, bruges i beregningen.
Ud over at optimere beregningsalgoritmen, minimeres systemets beregningstid ved at minimere intervallet for
respiratorindstillingerne. Dette gøres ved at gennemgå alle 20 patientcases og udvælge minimum- og maximumindstillinger for både klinikerens og Dr. Knows forslag. Herefter udvælges det største maximum og det
mindste minimum. Disse værdier er intervallets yderpunkter. Dette vil sige, at de 3 ovennævnte punkter, som
findes for hver indstilling, er henholdsvis Dr. Knows forslag, klinikerens forslag og punktet som ligger midt
imellem dem.
Til at finde den rette lambdakombination anvendes overordnet den samme fremgangsmåde som til at finde
respiratorindstillingerne. Lambdakombinationerne undersøges først med et bestemt step, og den bedste kombination findes. Området omkring hver lambdaværdi undersøges derefter med den halve stepstørrelse af første
step, og sådan køres der videre, indtil det ønskede step og dermed den bedste lambdakombination opnås.
119
»
Test
19.5
Systemtest
Systemtestens formål er at verificere, at Dr. Know udfører de specificerede funktionaliteter for brugerne. Der
er udført systemtests for begge brugertyper. Klinikerdelen er testet af en anæstetiolog, mens udviklerdelen er
testet af projektgruppen.
19.5.1
Brugertype: Kliniker
Systemtesten finder sted på Aalborg Sygehus Nord, hvor overlæge Dr. Med Søren Kjærgaard er udvalgt som
testperson af klinikerfunktionaliteterne i Dr. Know. Grunden hertil er, at klinikeren allerede er tilknyttet INVENT og har derfor lettere ved at sætte sig ind i problemstillingen for projektet. Opsætning af MySQL databaseserveren og tabellerne i databasen ”drknow” er foretaget inden testen påbegyndes. Dr. Know bliver afviklet
fra en bærbar PC, som placeres foran klinikeren.
Dr. Know afvikles med programmeringsværktøjet JCreator, hvilket frembringer den første GUI, loginvinduet,
på skærmen. Klinikeren informeres kort om GUI’ens funktionaliteter og indtaster de relevante data i tekstfelterne for klinikeroplysninger. ”OK”-knappen aktiveres og den næste GUI, klinikervinduet, manifesterer sig på
skærmen. Informationer om denne GUIs egenskaber bliver givet til klinikeren, og denne vælger patientgruppen
”Intensiv patienter”. Valget af patientgruppe initierer simuleringen af patientvariabler for case nummer 1 med
Dr. Know’s forslag til respiratorindstillinger. Simuleringen udføres uden problemer, hver gang klinikeren godkender sine indstillinger ved at aktivere ”Godkend”-knappen. Klinikeren gennemfører alle 20 patientcases og
forklarer sin fremgangsmåde, inden han indtaster sit bud på et sæt respiratorindstillinger.
I testen findes det, at patientcase nummer 10 ikke er god, fordi Dr. Know ikke kan finde en løsning til de bedste
respiratorindstillinger.
19.5.2
Brugertype: Udvikler
Grundet den lange beregningstid vælges det at køre beregningen af lambda med nogle større steps. Disse steps
er ikke de mest hensigtsmæssige steps at køre med, idet de kan give nogle urealistiske store spring i respiratorindstillingerne. Det vælges derfor at køre systemtesten for udvikleren med følgende steps:
Lambda
FiO2
Vt
f
Step
0,1
0,1
0,1
2
Det prioriteres derfor, at det bliver testet, om Dr. Know er i stand til at producere vægtninger, frem for at
verificere at de vægtninger der bliver produceret er hensigtsmæssige/realistiske.
Det forventes, at beregningen munder ud i fire lambdaværdier, der sammenlagt har summen 1. Det er fundet, at
de fire lambdaværdier har henholdsvis værdierne:
Lambdatype
λbaro
λaci
λoxy
λtoxy
120
Penalty
0,1
0,1
0,1
0,7
»
Test
Figurerne 19.1, 19.2 og 19.3 på næste side viser errorgraferne i form af Bland Altmann-plot for de tre respiratorindstillinger.
Figur 19.1: Errorgrafen for FiO2 .
Figur 19.2: Errorgrafen for tidalvolumen.
121
Figur 19.3: Errorgrafen for frekvens.
Del V
Diskussion
Formålet med denne del af rapporten er at diskutere de resultater og fremgangsmåder, der er anvendt til designet af systemet.
Kapitel 20 indeholder en vurdering samt diskussion af resultaterne fra Dr.
Know, samt en samlet vurdering af det endelige system og en konklusion på
de opnåede resultater.
Kapitel 21 indeholder en perspektivering indeholdende bl.a. udvidelsesmuligheder for Dr. Know.
123
KAPITEL
20
Diskussion
I dette kapitel forefindes en vurdering af de resultater, der er fremkommet under testene, samt en samlet vurdering af Dr. Know. Der vil desuden foreligge en konklusion på softwaresystemet. Formålet med dette er at give
et indblik i, hvor langt der er nået i processen med udviklingen af Dr. Know.
20.1
Vurdering af Dr. Know
I dette afsnit bliver de resultater, der er fundet under systemtesten og Dr. Know generelt, vurderet.
20.1.1
Effektivitet
Efter systemtesten er det verificeret, at løsningsstrategien er funktionel. Dog kræver løsningen en optimering
med hensyn til effektivitet. Den manglende effektivitet er forårsaget af, at Dr. Know kræver meget processorkraft til at styre de lange vektorer af data.
Som beskrevet i afsnit 19.4.1 på side 119 er der konstrueret en optimeringsalgoritme for at reducere beregningstiden. Med denne algoritme er beregningstiden reduceret til 8 minutter for de tilfælde, hvor hele intervallet
for alle respiratorindstillingerne undersøges. Denne tidsramme er ligeledes gældende for de patientcases, der
ikke er godt nok konstrueret. Beregningstiden reduceres yderligere, såfremt der udelukkende anvendes de intervaller, der ligger omkring klinikerens og Dr. Knows forslag til respiratorindstillinger. Dette giver en samlet
tid på ca. 60 minutter for at køre alle 20 patientcases igennem for en lambdakombination. Med det valgte
step findes der 48 lambdakombinationer, derfor vil den sammenlagte beregningstid blive ca. to døgn, når alle
lambdakombinationer skal beregnes.
Et andet optimeringsaspekt er at sørge for en tilfredsstillende opløsning for respiratorindstillinger og lambdaværdier. Det er valgt at køre udviklerdelen af systemtesten med nogle store steps for respiratorindstillingerne og
lambdaværdierne. Dette har den betydning, at der vil være nogle urealistiske steps i respiratorindstillingerne.
De uhensigtsmæssige steps for lambdaværdierne har den betydning, at vægtningen af penaltyfunktionerne ikke
bliver så præcis, som den kunne være med en bedre opløsning. Det er valgt at prioritere at få resultater fra syste125
Diskussion
¾
met, frem for at resultaterne er præcise. Der vil således frem til projektevalueringen blive beregnet vægtninger
med bedre opløsninger, således disse resultater kan fremlægges og vurderes i henhold til de allerede beregnede
vægtninger for penaltyfunktioner med den ringere opløsning. I systemtesten bruges der således følgende steps
til beregningen:
Lambda
FiO2
Vt
f
Step
0,1
0,1
0,1
0,2
Med denne opløsning bruger systemet ca. 2 døgn på hele lambdaberegningen. For at opnå en større præcision i
beregningen, kunne følgende opløsning i systemet vil være anvendt:
Lambda
FiO2
Vt
f
Step
0,01
0,01
0,01
0,1
Denne opløsning ville give mere realistiske steps i respiratorindstillingerne og dermed mere præcise lambdaværdier. Beregningstiden vil dog stige på baggrund her af.
Endnu et optimeringsområde, er de konstruerede patientcases. Under systemtesten med klinikeren, blev det påpeget at cardiacoutput i de fleste tilfælde var for lave. I klinikken ville disse tilfælde ikke blive betegnet stabile,
som de konstruerede patientcasene er karakteriseret ved. De fleste ville skulle sættes 1l op i cardiacoutput for,
at patienterne vil kunne betegnes som stabile. Dette havde den indflydelse på klinikeren, at vedkommende satte
iltfraktionen en smule mere op end det ville være tilfældet ved en stabil patient med et højere cardiacoutput.
En måde dette problem med de fiktive patientcases kunne løses på, var at implementere virkelige patientcases
i Dr. Know, med data fra patientjournalerne. Dette kunne løse problemerne med de urealistiske tilfælde. Dog
er det vurderet at dette problem ikke er omfattende, idet en anæstesiolog har været med i processen omkring
konstruktionen af patientcasene.
Såfremt, Dr. Know blev konstrueret som et online softwaresystem, med online database, var der mulighed for
at implementere Dr. Know på flere afdelinger, og dermed indsamle data fra mange forskellige klinikere. Herved
vil det være muligt at beregne lambdaværdier som bliver gældende for en større del af klinikerne.
Idet systemet ikke skal bruges online vurderes den tid beregningen tager at være passende. Her kan desuden
henvises til designkriterierne, hvor effektiviteten er vægtet som mindre vigtig, idet Dr. Know skal køre for sig
selv uafhængigt af andre systemer, samtidig med at tiden for beregningen af vægtningerne af penaltyfunktionerne ikke er essentiel for outputtet.
20.1.2
Testoutput
Det ses ud fra resultaterne i systemtesten, at Dr. Know har vægtet oxygentoxicitet højere end de resterende
penalties. Som det allerede er nævnt, ligger klinikerens FiO2 -indstillinger højt. Dette skyldes, at der skal kompenseres for de lave cardiac output. Med de vægtninger, som Dr. Know har forslået, kan det konkluderes, at
systemet har været i stand til at afbilde klinikerens tankemåde.
126
Diskussion
¾
Systemet har beregnet de respiratorindstillinger, som er optimale ud fra den fundne lambdakombination. På
basis af disse er der plottet forskellen mellem klinikerens og systemets forslag. Graferne afbilder derfor, hvor
meget systemets forslag afviger fra klinikerens forslag til respiratorindstillinger.
Vedrørende FiO2 -indstillingen ses det, at et gennemsnit på 6,5 % ikke er så galt, men en spredning på 11,69 er
ikke tilfredsstillende. Dette skyldes, at systemet hele tiden foreslår en lavere FiO2 -procent, der ligger i området
20-25%.
Vedrørende Vt-indstillingen ses det, at systemet foreslår værdier i intervallet 0,5-0,6 liter. Selv om klinikeren
generelt forslår lavere indstillingerne for Vt, ligger middelværdi og spredning tilfredsstillende på trods af de
store steps i udregningen.
Vedrørende frekvens-indstillingen ses det, at systemet foreslår, at den ligger bedst i intervallet 12-16 pr. minut,
med en henholdsvis tilfredsstillende gennemsnit og spredning på 0,518 og 4,4.
Selv om systemet afbilder forsøgspersonens tankegang, viser Bland Altmann-plottene, at systemet har et dårligt
fit i forhold til klinikerens forslag. Systemfit betragtes til at være dårligt, idet punkterne afbilder en ret linje med
en stor hældningskoefficient. Punkterne burde ligge med gennemsnitlig samme afstand til linien i nulpunktet.
Dette kan for eksempel skyldes, at de steps som Dr. Know har kørt med, ikke er optimale nok. Dette gælder
både for respiratorindstillingerne og for lambdaværdierne. For frekvens-indstillingen er gennemsnitsværdierne
tilfredsstillende, hvilket kan skyldes, at linien ligger med en spredning omkring nulpunktet, og de ophæver
således hinanden.
20.2
Konklusion
Der er i dette projekt taget udgangspunkt i følgende problemformulering:
Hvorledes er det muligt at konstruere et vidensindsamlingssystem, som kan indsamle og formalisere klinikeres subjektíve holdninger til, hvordan respiratorindstillinger indstilles mest fordelagtigt
for en kritisk syg patient, med henblik på en rationel vægtning af penaltyfunktioner?
Når en kliniker står over for at skulle tilpasse respiratorindstillingerne hos en kritisk syg patient, står klinikeren
ligeledes med en problemstilling, hvor vedkommende skal afveje, hvilke konsekvenser ændrede respiratorindstillinger vil få. Her vil klinikeren ofte skulle gå på kompromis med et eller flere surrogatmål, såfremt det
kliniske effektmål stadig skal bibeholdes. Denne tradeoff-problematik er beskrevet ved hjælp af utilityteori.
Der blev taget udgangspunkt i et konstrueret beslutningsstøttesystem INVENT, der bygger på utilityteori, som
har implementeret kurveformerne på penaltyfunktionerne, mens der kun er implementeret vægtning af penaltyfunktionerne for én enkelt patientgruppe.
Det blev fundet, at der er muligt at konstruere et softwaresystem, der bygger på en formalisering af klinikerens præferencestruktur og indirekte indsamler viden om forskellige klinikeres tradeoffs af de forskellige
konsekvenser, der opstår ved at træffe et valg af respiratorindstillinger. Systemet kan på nuværnede tidspunkt
indsamle klinikerens viden for de 3 patientgrupper: Postoperativ hjertepatient, hjernetraumepatient og intensiv
patient.
Denne problemstilling blev løst ved hjælp af objektorienteret analyse og design, UML samt Java. Der er herved
blevet konstrueret et vidensindsamlingssystem, i nær kontakt med udviklere af INVENT. Systemet er konstrueret således, at der eksisterer én brugergrænseflade til klinikeren som giver input til Dr. Know, samt én til
udvikleren som bruger outputtet fra systemet.
127
Diskussion
¾
Klinikerdelen af Dr. Know visualiserer patientparametre, initielle patientvariable for 20 forskellige patientcases, samt systemets forslag til de respiratorindstillinger der giver den mindste penalty. Systemets forslag til
respiratorindstillinger er beregnet på forhånd. Dette skyldes at denne beregning er en tidskrævende proces,
når den skal foretages for alle patientcases. Klinikeren bliver således præsenteret for disse når en patientcase
vælges. Klinikeren har mulighed for at indtaste nyt forslag til respiratorindstillinger og herudfra simulere patientvariable. Når klinikeren har opnået en tilfredsstillende patienttilstand, gemmes respiratorindstillingerne i
databasen.
Udviklerdelen af Dr. Know giver mulighed for, at brugeren kan beregne vægtninger af penaltyfunktionerne
for en bestemt patientgruppe samt for en udvalgt kliniker. Efter beregningen af lambdaværdier er der desuden
mulighed for at se et Bland-Altmann plot for de tre valgte respiratorindstillinger FiO2 , Vt og f. Dette plot
giver udvikleren en ide om, hvor god en tilpasning systemet har opnået til klinikerens/klinikernes forslag. Dette
gøres ved at visualisere forskellen mellem klinikerens forslag og systemets forslag til respiratorindstillinger.
Udviklerdelen af Dr. Know giver ligeledes mulighed for at gemme de beregnede lambdaværdier samt at hente
beregnede lambdaværdier frem igen.
For at kunne gemme den data klinikeren indtaster i Dr. Know, er der konstrueret en database. Databasen er
valgt, p.g.a. muligheden for at organisere dataen i tabeller, således at denne data er let af søge i, finde og hente
ud igen. Databasen bevirker også at der ikke skal gemmes redundant data, da det er muligt at oprette relationer
tabellerne imellem, og således kan en kliniker sammenkædes med flere patientgrupper.
Der er udført integrationstests ud fra usecasene for at undersøge, om Dr. Know lever op til brugerkravene.
Alle tolv usecases lever op til brugerkravene og fungerer efter de funktionaliteter, som brugeren har ønsket.
Der er desuden udført en brugertest af programmet for klinikerdelen. Denne er blevet testet i samarbejde med
anæstesiolog fra intensivafdelingen på Aalborg Sygehus Nord. Denne test har vist, at brugervenligheden af
programmet er opnået, dog er der flere parametre visualiseret for klinikeren her, end de har tilgængeligt til i
praksis. Dette giver dog klinikeren en bedre forudsætning for at vurdere patientens tilstand.
Afslutningsvist kan det konkluderes, at det har været muligt at konstruere et softwarebaseret vidensindsamlingssystem, der indsamler klinikerens subjektive holdning og formaliserer en præferencestruktur og derved
afhjælper tradeoff-problematikken. Det konstruerede system Dr. Know er således i stand til at vægte penaltyfunktionerne for de tre patientgrupper: postoperative hjertepatienter, hjernetraumepatienter samt intensiv patienter.
Det skal undersøges hvorvidt systemet kan forbedres, med hensyn til lambdaberegningen. Herunder kan metoden som finder Dr. Knows forslag forbedres, så beregningstiden kan minimeres.
128
KAPITEL
21
Perspektivering
Dette kapitel inkluderer et udvalg af tanker og idéer til videre optimering og udbygning af Dr. Know. Dr. Know
vil blive sat ind i en større sammenhæng samtidig med, at der vil komme forslag til mulige forbedringer af
programmet.
21.1
Forbedring og optimering
Under udviklingen og testningen af Dr. Know er der fundet områder, som kunne tænkes forbedret i næste
version af Dr. Know. Disse forbedringer er ikke blevet udført pga. af semestrets korte tidsrum, men primært
fordi de ikke har været en af de stillede funktionalitetskrav til Dr. Know og ikke har været beskrevet som
usecases.
I det følgende vil disse forbedringer blive beskrevet, samtidig med at der gives en mulig løsning til, hvorledes
disse forbedringer kunne implementeres.
21.1.1
Tidligere login
Under udarbejdelse af login- og klinikervinduet blev det klart, at det vil være ønskværdigt at have en funktion,
som kan tillade klinikeren at vælge et tidligere login. Som Dr. Know er opbygget nu, er det ikke muligt for
klinikeren at afbryde sin vurdering af patientcases ved f.eks. case nummer 6 for senere at genoptage og fortsætte
vurderingen af de 20 patientcases, der er for hver patientgruppe. Klinikeren skal med andre ord udfylde alle
20 patientcases, i én ombæring, da data ellers ikke kan anvendes til udregning af lambda. Ønsker klinikeren at
stoppe ved f.eks. case nummer 6, kan vedkommende ikke logge på igen og fortsætte, hvor klinikeren stoppede
sidst. Dette skyldes, at hver gang en kliniker logger på, oprettes denne som en ny bruger i databasen. Dette
medfører, at hvis klinikeren stopper ved case nummer 6, så bliver der aldrig ført mere data ind i databasen for
denne kliniker. Logger klinikeren på igen, så kommer de nye data til at stå ved den nye kliniker, der oprettes i
databasen.
Med en funktion i loginvinduet som kan hente og vise de klinikere, der tidligere har brugt Dr. Know, kan det
gøres muligt for klinikeren at vælge sig selv ud fra denne liste og logge på igen. Samtidig vil det også være
129
Perspekti
vering
¿
¾
muligt for klinikeren at vurdere de 20 cases af flere omgange, da data så vil blive gemt samme sted i databasen
for hver gang klinikeren logger på.
For at kunne lave et tidligere login, skal der på loginvinduet laves en scrollmenu, hvor kliniker kan vælge sit
navn, såfremt vedkommende har været logget på før. For at kunne fylde navne ind i denne scrollmenu skal
der laves en ny funktion i database-klassen, som henter et klinikerobjekt indeholdende klinikernummeret ud af
klinikerdata-tabellen. Dette klinikerobjekt skal, når der logges på, sendes videre til klinikervinduet, så metoden
godkend kan kaldes med de rigige klinikeroplysninger og dermed sikre, at data sættes ind ved den rigtige
kliniker i databasen.
21.1.2
Tilføjelse af patientgrupper
I Dr. Know eksisterer der på nuværende tidspunkt tre patientgrupper. For at gøre Dr. Know anvendelig for flere
afdelinger kræves det, at der tilføjes flere patiengrupper, som eksempelvis KOL og ARDS patienter. For eksempelvis disse patienttyper forudsættes det, at INVENT har en fuldkommen lungedynamikmodel implementeret.
De tre eksisterende patientgrupper anvender alle de samme 20 patientcases. Såfremt de nye patientgrupper også
kan anvende disse 20 cases, vil det ikke kræve megen programmering at tilføje de nye patientgrupper. Det er
kun et spørgsmål om at udvide valgmulighederne på brugergrænsefladerne, da patientgruppenavnet kun er en
label der påsættes respiratorindstillingerne. De klasser der skal ændres noget i er: KlinikerVindue og UdviklerVindue.
21.1.3
Gem grafdata
Når tidligere gemte lambdaværdier hentes ind i Dr. Know, kan de tilhørende errorgrafer ikke ses, da disse ikke
er gemt. For at udvikleren igen kan vurdere, om de gemte lambdaværdier er anvendelige, vil det være fordelagtigt at gemme data for errorgraferne sammen med lambdaværdierne.
Skal graferne kunne visualiseres igen, kræves det at objektet ErrorData gemmes sammen med lambdaværdierne. ErrorData kan således gemmes i samme fil, som lambdaværdierne gemmes i. Dette betyder, at metoderne
gemEtEllerAndet og indlaesEtEllerAndet i klassen LambdaGem skal rettes til, så disse også kan gemme og
indlæse ErrorData.
21.1.4
Online database
Det kunne af både udvikleren og klinikeren ønskes at have Dr. Know databasen til at ligge online, så klinikeren
og udvikleren ikke behøver at anvende samme computer. Med en online database kunne klinikeren sidde på sin
arbejdsplads og vurdere patientcases, og det giver dermed to store forbedringer i Dr. Know. For det første kan
beregningen af lambdaværdier foregå på en anden computer, da udvikler nu kan hente data ned via internettet
og beregne lambdaværdierne på sin egen computer. Dette medvirker også, at beregningen ikke vil forhindre
klinikere i at anvende Dr. Know på samme tid. Den anden forbedring ligger i, at flere klinikere kan anvende Dr.
Know på samme tid, da de data, der gemmes, overføres til en central database.
For at lave en online database kræves det, at der opsættes en server, som der kan opnås adgang til via internettet
(se Figur 21.1 på næste side). På denne server skal der installeres en SQL database. Dr. Know kan allerede
køre med en online database. Det eneste, der skal rettes i koden, er, at der skal angives den korrekte adresse til
databasen.
130
Perspektivering
¾
Figur 21.1: Illustration af hvorledes en online database kan implementeres, således at flere klinikere kan anvende denne
samtidigt. Udvikleren kan udføre lambdaberegningen uden at klinikerne forstyrres af dette.
21.2
Integrering med INVENT
I Dr. Know anvendes både matematiske modeller og penaltyfunktioner fra INVENT. Dr. Know kan vægte disse
penaltyfunktioner således, at de producerede vægtninger kan anvendes til at kalibrere INVENT, der således kan
tilpasses flere forskellige patientgrupper og ikke kun være tilpasset patienttypen post-operativ CABG. På grund
af at Dr. Know og INVENT deler megen kode og funktionalitet, vil det være fordelagtigt, hvis Dr. Know kan
integreres i INVENT. På denne måde kan Dr. Know blive en funktionalitet i INVENT, således at klinikerne selv
kan have en indflydelse på de respiratorindstillinger, som INVENT foreslår. Ved at have de to systemer samlet i
ét, kan klinikeren til enhver tid gå ind og få indlejret sin egen ekspertviden i INVENT. Dette kræver dog, at der
løses nogle problemer omkring udregningen af lambdaværdierne, da denne udregning på nuværende tidspunkt
tager forholdvis lang tid. I klinisk praksis er der ikke tid til at vente på, at programmet bruger timer eller dage
på beregning og ikke kan anvendes imens. Dette kunne løses ved at lave en beregningsalgoritme som kun kører,
når optimerings- og simuleringsfunktionerne ikke anvendes, eller når computeren har ressourcer tilrådighed.
En anden løsning ville være, at INVENT kørte med en online database som beskrevet tidligere, og udregningen
kunne foregå på en anden computer eller server.
131
Litteratur
[1] C.W. Allerød, S.E. Rees, B.S. Rasmussen, S. Kjærgaard, and S. Andreassen. Retrospektive evaluation of
a system for adjustment of ventilator settings. 1, 1999.
[2] S. Andreassen. Medical Decision Support Systems, based on causal probabilitic networks. Aalborg
Universitet, Dk, 2000.
[3] Mark H. Beers. The merck manual - second home edition. http://www.merck.com/mrkshared/mmanualhome2/sec24/ch295/ch295b.jsp, 2003.
[4] Agamemnon Despopoulos and Stefan Silbernagl. Color Atlas of Physiology. Thieme, 4th edt., 313545004,
1991.
[5] Akeel I Din. Structured Query Language. NCC Blackwell, 1994.
[6] Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado. UML 2 Toolkit. Wiley Publishing
Inc., 0-471-46361-2, 2004.
[7] Ivor Horton. Beginning Java 2. Wrox Press, 2000.
[8] Ralph L. Keeny and Howard Raiffa. Decisions with Multiple Objektives. Press syndicate of the University
of Cambridge, UK, 0521438837, 1999.
[9] L. Mathiassen, A. Munk-Madsen, P. A. Nielsen, and J. Stage. Objekt Orienteret Analyse og Design.
Marko, 2001.
[10] Sun Microsystems. The java tutorial. http://java.sun.com/docs/books/tutorial/index.html, 2004.
[11] Patrick Neligan. Mechanical ventilation. http://www.ccmtutorials.com/rs/mv/, 2004.
[12] Jacob Nordfalk. Objektorienteret programmering i Java. Forlaget Globe Publishing, 2002.
[13] S. Rees, S. Kjærgaard, P. Thorgaard, J. Malczynski, E. Toft, and S. Andreassen. The automatic lung
parameter estimator (alpe ) system: non-invasive estimation of pulmonary gas exchange parameters in
10-15 minutes. Journal of Clinical Moni toring and Computing, 17, 2002.
[14] S.E. Rees, S. Andreassen, M. Freundlich, C. Morgan, E.R. Carson, and P. Thorgaard. Selecting ventilator
settings using invent, a system including physiological models and penalty functions. 1999.
133
LITTERA
TUR
À
¾
[15] JCreator Xinox Software. Jcreator main page. www.jcreator.com, 2004.
[16] Aalborg Universitet. Studieordningen 6.-10. semester. http://www.miba.auc.dk/undervisningsweb/Sstudieordning-S6-S10-jan2004.pdf, 2004.
[17] Chien Sheng Wang, Dein Shaw, and Kuen Shan Jih. An intelligent control system for ventilators. Medical
engineering and Physics, 9:534–542, 1998.
[18] Henrik R. Wulff and Peter C. Gøtzsche. Rationel klinik. Munksgaard bogklubber, 8779361749, 2001.
134
Del VI
Appendiks
I denne del af rapporten vil der forefindes materiale, der er udarbejdet for
at understøtte udvalgte dele af rapporten.
Appendiks A indeholder en beskrivelse af fysiologien, der er anvendt i INVENT.
Appendiks B beskriver de matematiske modeller over fysiologi, der er implementeret i INVENT.
Appendiks C indeholder en beskrivelse af GUI-elementer, input- og outputfelter, samt de underliggende funktioner.
Appendiks D beskriver attributterne til de forskellige GUIs.
Appendiks E indeholder et referat af interview med Dr. Med Per Thorgaard,
benævnt Bilag 1.
Appendiks F indeholder et referatet af interview med Dr. Tech Steen Andreassen, benævnt Bilag 2.
135
APPENDIKS
A
Fysiologi i INVENT
I dette appendiks beskrives kort de respiratorindstillinger, patientparametre og patientvariable, som er indeholdt i INVENT. Desuden gives en definition af de fem kliniske tilstande barotraume, acidose/alkalose, atelektase, oxygentoxicitet og dårlig oxygenering.
A.1
Respiratorindstillinger
I INVENT har klinikeren mulighed for at indstille på de respiratorindstillinger, der ses i Tabel A.1. Det er
respiratorindstillinger for inspireret oxygenfraktion (FiO2 ), tidalvolumen (Vt), respirationsfrekvens (f), positivt
slutekspiratorisk tryk (PEEP) og forholdet mellem tiden for inspiration og ekspiration (I:E). [14] I tabellen er
referenceværdierne angivet.
Respiratorindstilling
FiO2
Vt
f
I:E
PEEP
Forklaring
Inspireret fraktion O2
Tidalvolumenet
Respirationsfrekvensen
Ratioen (inspiration/ekspiration)
Positivt slutekspiratorisk tryk
Referenceværdi
21 %
0,5 l
12-14 /min
0,33
5,0 cmH2 O
Tabel A.1: Overblik over de forskellige respiratorindstillinger.
A.2
Patientparametre
Patientparametrene er inddelt i fem parameterkategorier: Gasudvekslingsparametre, lungemekaniske parametre, metaboliske parametre, circulationsparametre og parametre for blodet. Patientparametrene giver klinikeren
et dybereliggende billede af patientens tilstand og påvirkes ikke markant af respiratorindstillingerne. Det beskrives her, hvilke patientparametre der monitoreres. [4]
137
Fysiologi i INVENT
¾
Gasudvekslingsparametre
Shunt er den mængde blod, der ikke deltager i gasudvekslingen i lungerne (normalværdi 5%).
FA2 repræsenterer den fraktion af ventilation til en lungekompartment, der modtager 90% af blodgennemstrømningen (en FA2 på 0.9 indikerer derfor et match mellem perfusion af blod og ventilation).
Vd er volumenet af deadspace (referenceværdi er 150 ml).
Lungemekaniske parametre
Compliance er lungernes elasticitet givet ved forholdet mellem ændringen i volumen og ændringen i trykket i
lungerne (referenceværdi er 0,05 l/cmH2 O).
Resistance er et mål for modstanden i luftvejene (referenceværdi er 3,99 cmH2 O/l/s).
Metabolisk tilstand
Den metaboliske tilstand er et udtryk for den kemiske balance i vævet, og følgende parametre monitoreres:
˙ 2 er flowet af O2 (referenceværdi er 0,25 l/min).
VO
˙ 2 er flowet af CO2 (referenceværdi er 0,20 l/min).
VCO
Cirkulation
Q˙ er cardiac output, der indikerer hvorvidt patientens blodgennemstrømning er tilstrækkelig for oxygenering af
organismens væv (referenceværdi er 5 l/min).
Blodets tilstand
DPG er 2,3-Difosforglycerat, som mindsker affiniteten for O2 , hvis den findes i for store mængder i blodet
(referenceværdi er 5,00 mmol/l).
Hb er hæmoglobin, som giver et udtryk for blodets evne til at transportere O2 rundt i oganismen (referenceværdi
er 9,30 mmol/l).
COHb er kulmonoxid, der ikke har nogen affinitet for O2 (referenceværdi er 0 mmol/l).
MetHb er methæmoglobin, der ikke har nogen affinitet for O2 (referenceværdi er 0 mmol/l).
Temperatur har en betydning for O2 -transporten i blodet (referenceværdi er 37 Á C).
A.3
Patientvariable
Patientvariable er inddelt i tre kategorier: lungevariable og variable for henholdsvis arterielt blod og venøst
blod. Det beskrives her, hvilke patientvariable, der kan simuleres:
Lungevariable
FeCO2 er den ekspirerede CO2 -fraktion (referenceværdi er 4,4 %).
FeO2 er den ekspirerede O2 -fraktion, der sammen med FeCO2 giver et mål for, hvor meget O2 der optages
i alveolekapillærerne i forhold til den fraktion, der ventileres med samt hvor stor fraktion CO2 der udskilles
(referenceværdi er 15,3 %).
138
Fysiologi i INVENT
¾
Arterielle variable
SaO2 er den arterielle iltmætning (referenceværdi er 96,9 %).
PaO2 er partialtrykket af O2 i det arterielle blod (referenceværdi er 12,4 kPa).
PaCO2 er partialtrykket af CO2 i det arterielle blod (referenceværdi er 4,5 kPa).
pHa er pH-værdien i det arterielle blod (referenceværdi er 7,42).
Venøse variable
SvO2 er den venøse iltmætning (referenceværdi er 73,0 %).
PvO2 er partialtrykket af O2 i det venøse blod (referenceværdi er 5,6 kPa).
PvCO2 er partialtrykket af CO2 i det venøse blod (referenceværdi er 5,6 kPa).
pHv er pH-værdien i det venøse blod (referenceværdi er 7,39).
A.4
Surrogatmål
De fem behandlingsmål i INVENT er at undgå de kliniske tilstande for barotraume, acidose/alkalose, atelektase,
oxygentoxicitet og dårlig oxygenering. De beskrives efterfølgende.
A.4.1
Barotraume
Dette traume er defineret som vævsskade forårsaget af ekspanderingen af O2 i lungerne på grund af et lavere
tryk i pleura. Overinflation af lungerne, for eksempel som følge af mekanisk ventilation, kan forårsage ruptur af
alveolerne og de subpleurale blærer på lungernes overflade, hvilket giver anledning til pneumothorax. Udover
pnemothorax kan der, som følge af barotraume, dannes embolier i blodbanen, hvilket betyder at embolierne
kan forhindre blodgennemstrømningen til kroppens organer.[3]
A.4.2
Acidose/alkalose
I det efterfølgende er henholdsvis respiratorisk acidose og alkalose beskrevet.
Respiratorisk acidose
Denne tilstand kan opstå som et resultat af skader på lungeparenkymet, svækkelse af den alveolære gasudveksling, parese af lungemuskulaturen, insufficient respiratorisk drive, reduceret bryst motilitet mm. Som følge af
ovenstående situationer, vil der forekomme en stigning i CO2 , hvilket derefter resulterer i en øget HCO3 Â og
H Ã produktion. Dette kan ses ud fra reaktion (A.1), som beskriver sammenhængen mellem CO2 og HCO3 Â .
CO2 Ä H 2 O Å
HCO3 Â
Ä
HÃ
(A.1)
pH-værdien vil falde som følge af den øgede produktion af HCO3 Â , hvilket ses ud fra ligning (A.2). Stigningen
i HCO3 Â er meget mindre end stigningen i CO2 , hvilket skyldes buffersystemer i blodet. Dette betyder at ratioen
[HCO3 Â ]/[CO2 ] bliver mindre og pH falder til under det normale.
139
Fysiologi i INVENT
¾
pH
Æ
pKa Ä log Ç
HCO3Â È
CO2 È
(A.2)
Ç
Ligning (A.2) kaldes også for Henderson-Hasselbalch-ligningen, og bruges til at regne pH-værdien ud for en
bikarbonat opløsning. pKa er den negative logaritme af dissociationskonstanten Ka for en syre.
I de tilfælde, hvor PCO2 er vedvarende, kan der forekomme en renal kompensation af den respiratoriske acidose. Nyrerne begynder at udskille stigende mængder H Ã -ioner, hvilket bevirker at syre/base-homeostasen
genoprettes til trods for stigningen i PCO2 .
Respiratorisk alkalose
Tilstanden opstår idet lungerne eliminerer mere CO2 end der produceres ved vævenes metaboliske aktiviteter.
Denne situation kaldes hyperventilation, og resulterer i et fald i PCO2 . Faldet i CO2 betyder ifølge ligning
(A.2), at ratioen [HCO3 Â ]/[CO2 ] bliver større og pH stiger over det normale.
Den dominerende kompensatoriske mekanisme ved respiratorisk alkalose er nyrens reducerede sekretion af
H Ã -ioner og øgede ekskretion af HCO3 Â . Ud fra ligning (A.2) vil man se, at dette vil kompensere for alkalosen.
A.4.3
Atelektase
Atelektase er en tilstand, hvor hele eller dele af lungen er lufttom og sammenklappet. Tilstanden kan være enten
akut eller kronisk. Ved den akutte atelektase er lungen kollapset og er primært genkendelig ved at lungen er
lufttom. En kronisk atelektase vil ofte være karakteriseret ved, at det affekterede område af lungen er præget af
lufttomhed, infektion, bronkiektase og fibrose.
A.4.4
Oxygentoxicitet
Det lægelige term for oxygentoxicitet er hyperoxia, og indtræffer idet det inspiratoriske tryk (PiO2 ) er over 22
kPa, som følge af en stigning i FiO2 eller en stigning i trykket med normal FiO2 . Hos patienter som er under
oxygen- eller ventilationterapi, vil der være en risiko for oxygentoxicitet i lungevævet.
Graden af O2 toxicitet afhænger af niveauet af PiO2 og varigheden af hyperoxia. Lungedysfunktion optræder
når PiO2 på ca. 70 kPa er vedvarende over adskillelige dage eller 200 kPa i løbet af 3-6 timer. Symptomerne er
hoste og dyspnø. Et PiO2 over 220 kPa resulterer ofte i kredsløbskollaps og bevidstløshed.
A.4.5
Dårlig Oxygenering
Hypoxia er modsætningen til hyperoxia, hvilket betyder lavt iltindhold i væv og organer. Dette medfører at
O2 -koncentrationen i blodet er lavere end godt er (hypoxæmi). Den lave O2 -koncentration medfører i værste
fald celle- og vævsnekrose, samt multiorgansvigt.
140
APPENDIKS
B
Modellerne integreret i INVENT
I INVENT er der tre modeller integreret, hvilke er to fysiologiske modeller for henholdsvis oxygen (O2 ) og
kuldioxid (CO2 ) og en lungedynamikmodel. O2 -modellen og CO2 -modellen anvendes i Dr. Know til simulering
af patientvariablene. Idet Dr. Know er afgrænset til ikke at indeholde penaltyfunktionen for atelektase samt at
der ikke skal foretages respiratorindstillinger for PEEP og I:E, hvilke anvender lungedynamikmodellen, bruges
kun en lille del af lungedynamikmodellen. Lungedynamikmodellen beskrives derfor ikke i detaljer. O2 -modellen
og CO2 -modellen vil i dette kapitel blive gennemgået for at give en forståelse for fysiologien anvendt i Dr.
Know.
B.1
O2 -modellen
O2 -modellen er illustreret ved Figur B.1 på næste side, hvor modellen er inddelt i forskellige kompartments,
der beskriver O2 i alveoler og blod. Modellen indeholder 16 ligninger, der deles op i fem dele. Modellens fem
dele beskriver den alveolære ventilation, alveolære gasudveksling, shunt ligningen, oxygenering af blod og
O2 -optagelsen i væv. Modellen er beskrevet på baggrund af [13, 4]. Modellen indeholder to parametre, shunt
og ventilation perfusion (V/Q) mismatch, hvilke beskriver abnormaliteter af ilttransporten. Shunt er hvor stor
en procentdel af blodet, der løber forbi lungerne uden at blive iltet (normalværdi for shunt er 5%), og V/Q
er forholdet mellem ventilationen i alveolerne (V) og mean pulmonary blood flow, eller cardiac output (Q)
(normalværdi 5,25/5 É 1). Værdierne for shunt og V/Q mismatch opnås ved hjælp af en anden model (ALPE),
der måler lungefunktionen. I Dr. Know er disse dog konstante for hver patientcase. Der eksisterer ud over de
følgende beskrevne ligninger to andre ligninger over O2 ’s massebalance i alveoler og blod. Disse to ligninger
beskriver, at O2 opnår ligevægt straks efter ventilationsændring (2-5 minutter efter), hvilket verificerer, at O2 modellen kan integreres i dens steady state form.
B.1.1
Ligninger indeholdt i O2 -modellen
Følgende gennemgås de fem dele af O2 -modellen.
141
Modellerne integreret i INVENT
¾
Figur B.1: Figuren illustrerer O2 -modellen og viser de ligninger, modellen indeholder.[13]
Alveolær ventilation
Ligning 1 i Figur B.1 beskriver O2 -flowet ind i alveolerne (V˙ O2 ) ud fra fraktionen af inspireret O2 (FiO2 ),
ekspireret O2 (FeO2 ) og den alveolære ventilation, der udregnes som forskellen mellem tidalvolumenet (Vt) og
dead space (Vd), ganget med respirationsfrekvensen (f). Tidalvolumen er det volumen, der in- eller ekspireres
under en normal respiration, dead space er den del af lunger og luftveje, hvor der ikke foregår gasudveksling,
og differensen mellem disse to udgør således det volume, der deltager i den alveolære ventilation.
142
Modellerne integreret i INVENT
¾
Modellen indeholder to alveolære kompartments, hvor fA2 er den fraktion af total ventilation til en alveolær
kompartment som modtager en fraktion af den totale blodflow (f2) i alveolerne. 1-fA2 repræsenterer fraktionen
af total ventilation til den anden kompartment. Ligning 3 og 4 viser således O2 -flowet i hver af de kompartments som total O2 -flow ganget med ventilations fraktionen i det kompartment. Det totale flow i alveolerne er
summen af flowet i begge kompartments, som ses af ligning 4. Fraktionen af ekspireret O2 i gennem begge
compartments er summen af fA2 ganget med fraktionen af ekspireret O2 i kompartment 2 og (1-fA2) ganget
med fraktionen af ekspireret O2 i kompartment 1 (ligning 5).
Alveolær gasudveskling
Ligning 6 og 7 udregner partialtrykket af O2 i modellens to lungekapillærkompartments (PcO2 Ê 1 Ë , PcO2 Ê 2 Ë ).
Hvis ingen diffusionsabnormalitet opstår, er partialtrykket i kapillærerne det samme som partialtrykket af O2
i alveolerne (PA O2 =FeO2 (PB -PH2 O )), hvor PB er barometertrykket, PH2 O er vandtrykket, og PB -PH2 O er således
den del af trykket, der udgøres af O2 .
Koncentration af O2 i kapillærkompartments (CcO2 Ê 1 Ë , CcO2 Ê 2 Ë ) beskrives i ligning 8 og 9 som O2 koncentrationen i venerne plus stigningen i O2 koncentration som følge af V/Q mismatch i kompartmenterne.
Shunt-ligning
Ligning 3 er shunt-ligningen og beskriver koncentrationen af O2 i det arterielle blod (CaO2 ), når blodet fra
lungekapillærerne (CcO2 ) er blandet med en fraktion (fs) af det venøse blod (CvO2 ). Udtrykket PcO2 Ê 1 Ë (1fs)(1-f2) + PcO2 Ê 2 Ë (1-fs)f2 repræsenterer det kapillære blod, mens fraktionen af venøst blod er beskrevet ved
fsCvO2 .
Blodparametre
Ligning 11 og 12 implementerer O2 -dissociationskurve (ODC) justeret for pH (pHa er pH i det arterielle blod),
partialtrykket af CO2 (PCO2 ), temperatur (T) og koncentrationen af 2,3-diphosphoglycerat (CDPG) i blodet,
ganget med respirationsfrekvensen fås O2 -saturationen i det arterielle blod (SaO2 ).
Ligning 13 beregner blodets O2 -kapacitet (O2 cap), når den totale hæmoglobinkoncentration (Hb) er justeret for
dens abnorme former (HbMet, HbCO). HbMet er methæmoglobin og HbCO er kulmonoxidhæmoglobin, der
begge ikke har nogen affinitet for O2 .
Ligning 14 og 15 beskriver koncentrationen af O2 i venøst blod (CcO2 ) som summen af O2 bundet til hæmoglobin (O2 cap*ScO2 ) og O2 fysisk opløst (PcO2 *αO2 ). Koncentrationen af fysisk opløst O2 i blodet er lineær
afhængig af partialtrykket af O2 i blodet, hvor α er opløselighedskoefficienten for O2 .
Vævs optagelse
Ligning 16 er Ficks ligning og udregner den venøse O2 -koncentration (CvO2 ) som den arterielle O2 -koncentration
(CaO2 ) minus faldet i O2 -koncentrationen som følge af O2 -optagelse i vævet.
143
Modellerne integreret i INVENT
B.2
¾
CO2 -modellen
CO2 -modellen, der anvendes i INVENT, er implementeret som en tre-kompartmentmodel. Disse kompartments
repræsenterer CO2 i henholdsvis blodet, interstitel væske og vævet. Hertil hører en række ligninger, som beskriver ventilationen af alveolerne, cirkulationen, CO2 -produktionen og bindingen af CO2 i blodet, den interstitielle væske og vævet. På Figur B.2 ses fysiologien i CO2 -modellen illustrereret. CO2 -modellen anvender
ca. 70 ligninger til at forudse effekterne af en ændret ventilation på syre/base-kemien i blodet. I det følgende
vil kun reaktioner for fysiologien i modellen blive beskrevet. CO2 -modellen vil blive beskrevet på baggrund af
[14]. Den alveolære ventilation, cirkulation og CO2 -produktion er beskrevet ved ligninger tilsvarende dem, der
Figur B.2: Figuren illustrerer CO2 -modellen med dens ligninger og kompartments. [14]
anvendes i O2 -modellen (se afsnit B.1.1 på side 141).
VCO2
Æ
f Ê V t Ì V d Ë Ê FeCO2 Ì FiCO2 Ë
CvCO2
Æ
CaCO2 ÄÎÍ
144
˙
VCO
2
Q˙ Ï
(B.1)
(B.2)
Modellerne integreret i INVENT
¾
B.2.1
Interstitiel væske og væv
Der er i modsætning til O2 anselige mængder CO2 i den interstitielle væske og vævet. I modellen er denne
CO2 i den interstitielle væske repræsenteret som et par bicarbonat non-bicarbonat buffere i reaktioner 6 og 7 på
Figur B.2 på forrige side. Et sænket ”i” angiver, at det er tilhørende den interstitielle væske, ”t” er tilhørende
vævet, ”p” er tilhørende plasma, og ”e” er tilhørende erythrocytterne. CO2 i væv er ligesom ved den interstitielle
væske repræsenteret ved et par bicarbonat non-bicarbonat buffere (reaktion 8 og 9 ).
B.2.2
Blod
Ligning 1 viser, hvad der sker, når CO2 tilsættes H2 O og bicarbonat (HCO3Â Ð p ) og brintioner (H Ãp ) dannes. Ligning 2 beskriver, hvorledes plasma-nonbicarbonat-bufferen splittes op i H Ãp og NBB Âp , når dennes tilsættes til
H2 O.
Ligning 3 viser, at CO2 også omdannes til HCO3 Рe og Heà i erythrocytterne. De resterende reaktioner involverer
alle hæmoglobin. Ligningerne indeholder kun de oxygenerede hæmoglobinformer, men de samme ligninger
gælder for de deoxygenerede hæmoglobinformer. Ligning 4a og 4b er kendt som Bohr/Haldane effekten og
beskriver hæmoglobins binding til enten H eller O2 , ligesom ligninger 5a og 5b beskriver, hvordan O2 og CO2
konkurrerende binding til hæmoglobinmolekulet.
B.3
Model af lungedynamikken
Lungedynamikmodellens brug i Dr. Know er begrænset til udregning af positiv inspiratorisk tryk (PIP) som
kan regnse udfra følgende ligning:
Comp Æ
PIP Ì PEEP
VT
(B.3)
Comp er lungernes compliance, dvs. et mål for lungernes elasticitet. Compliance og PEEP har faste værdier i
Dr. Know.
145
APPENDIKS
C
GUI-elementer samt underliggende funktioner
Dette appendiks indeholder de definerede GUI-elementer, input- og outputfelter samt de funktioner, der er
fundet ved at gennemgå hvert enkelt GUI-elementer. Først vil GUI-elementerne for de enkelte vinduer være at
finde, og herefter vil funktionerne forefindes. Formålet med dette er, at finde eventuelle udeladte funktioner.
C.1
LoginVindue
C.1.1
GUI-elementer
I det efterfølgende beskrives GUI elementerne inputfelter, outputfelter og knapper for loginvinduet.
Inputfelter:
ÑÓÒÕÔÔ ÖØ×Ù)ÚÓÚÛÜ
á$×
ÝÛÞß$Ü à áÛâ ÞÛ
ñ)ÚÓôà ×
ôñßÞìÝøÜ ÙëÛ)Ü
ãºä
å
è îìà Ûâ êî)ñÜ ×
è îà Û)â ê4ïé è ÛÜ ×
ò
á×
ä
á×
è îà Û)â êùý×üà Û×)×à è Û$è
ä
ð
Ô ×)çÙ$ä è é Û)â è)è à â$à ×êè Þ
Ô ×)çÙ$è é Û)â è)è à â$à ×êè Þ
Ô ×)çÙ$è é Ûâ èè à â$à ×ê)è Þ
ä
ôñß"Þ)þè à â â à ×ëÞ)ôÛ$è Ûëì×Ûâ ÞÛ
û
ñÚ%ôà ×
ÿ
ó
ä
ä
è ×à ×ë
ä
è ×à ×ë
è ×à ×ë
ä
éìÛé è ÛÜ ×
é
ä
ä
ä
ä
á×í
á×í
×üà Û×)×à è Û$è í
ä
ä
è à ñ×Þôñ)ß"Þõè à âá
ä
ä
147
è
× ä à ×ë ä éìé ñÜ ×
Ô ×)çÙ$è é Ûâ èè à â$à ×ê)è Þ
ó
è îà Ûâ êùúé êÛ)â à ×ë
æ
è à ñ×Þôñß"Þõè à âá â ë
éôÜ ÙëÛ)Ü è öçÛì÷
ß$â à ×)à ßÛÜÛâ â ÛÜ4Ùêáà ß$â ÛÜ í
é
âë
é ê)Ûâ à ×ëí
ä
ä
éÞè à â â à ×ëí
GUI-elementer samt underliggende funktioner
¾
Outputfelter:
Ingen
Knapper:
"1,2 !
)* $& ! $ ! +,./+ 0
(
"' ! ! " #
$
$
$
$ % &
:;
"&9 5 "
/
4365 78 " !
C.2
KlinikerVindue
C.2.1
GUI-elementer
I det efterfølgende beskrives GUI elementerne inputfelter, outputfelter og knapper for klinikervinduet.
Inputfelter:
<=>
> ?@
ABBC
D
KMLI@
ECFGD H IC
J FC
N
O
R [&H CJ U4[XH acbX\H BA
J C
D CR
> @
QAR S C
J R
R H JD CF
QH D LR TD H @UFR H J J H @V
C@&W
[&H acb_
N
`
R [XH C
J U[&D CG6IC@F\H B]AJ CD CR
> @Q
AR S CJ RR H JD CFQ
H D LR T
D H @UFR H J J H @VC
@&W
S D CG6IC@F&_
N
^
R [XH C
J U
YR H UL
J \H B]AJ CD CR
> @Q
AR S CJ R
R H JD CFQH D LR TD H @U
FR H J J H @V
C@XW YZR
N
P
eTG FXgLR H C
@R <D AQ
QC
dTBe
H @LR H T@F
eT
G FfR H J*I LJ VLS
QLR H C
@R V&D A
QQCX_
O
h
eTG*F&gLR H C
@R K,ABBfCD
dTBe
H @LR H T@F
eT
G FfR H J*I LJ VLS
QLR H C@R @A
BBC
D._
148
GUI-elementer samt underliggende funktioner
¾
Outputfelter:
ijkk lmn
oopq
xyvm
r4pstq u vpw sp
z4{
† ‡Xu p
w XŒnm†
l,u s}w y~ pqv8q &u*‚ ƒ
q&s
Œn
m† …
z‹
† ‡Xu p
w ‡Š,‹
l,u s
}w y~p
qXv€q &u ‚ ƒ
qZ‡Š,‹4…
z‰
† ‡Xu p
w 
ˆM
l,u s
}w y~p
qXv€q &u ‚ ƒqXpy
s}y„pX…
z|
† ‡&u pw &
l,u s}w y~p
qXv 8q &u ‚ ƒ
q&„yq &u y„ƒ
n† }n† …
z
† ‡&u pw &Ž,ƒ
o}w u y
m„p
l,u s}
w y~pqv8q Xu ‚ ƒqX„ƒ
o}w u y
m„pX…
zz
† ‡Xu p
w ‘psu s† ym„p
l,u s}
w y~pqv8q Xu ‚ ƒqq psu s† ym„p&…
z’
† ‡Xu p
w 
ˆ”—c‹
l,u s
}w y~pqv€q Xu ‚ ƒqXˆ,—c‹4…
z˜
† ‡Xu p
w 
ˆ”Ž—c‹
l,u s
}w s~p
qXv€q &u ‚ ƒqXˆ,Ž—c‹4…
z–
† ‡&u pw 4l•+i
l”u s}
w y~pqv8q Xu ‚ ƒq+l•Zi…
’“
† ‡Xu p
w œ,™
l,u s
}w y~p
q4Œ8oƒ›Xw ƒ™u m† yw w p† …
’4{
† ‡Xu pw XŽ,ƒ&œ,™
l,u s}
w y~pqŽ,yq ™ƒš ~fŒ€oƒ›Xw ƒ
™u m† yw w p† …
’‹
† ‡&u pw &p† œ”™
l,u s
}w y~p
qXv€q &u ‚ ƒqop† Œ8oƒ›Xw ƒ™u m&…
’‰
† ‡Xu pw 
ž+po}
l,u s
}w y~p
qXv€q &u ‚ ƒ
qX† po}pq y† n
q.…
’|
† ‡&u pw 4‡
pŽ—c‹x,n
l,u s}
w y~pqmnv8q pmpfv€q &u ‚ ƒqX‚ q yt*† u ƒm
pt*s}u q pq p†&Ž—c‹4…
’
† ‡Xu p
w ‡p
Ž—c‹&u o
l”u s}
w y~pqXsu onw pq p†v€q Xu ‚ ƒqX‚ q yt*† u ƒ
m
pt*s}u q pq p†&Ž—c‹4…
’z
† ‡&u pw 4‡
p—c‹x,n
l,u s}
w y~pqmnv8q pmpfv€q &u ‚ ƒqX‚ q yt*† u ƒm
pt*s}u q pq p†&—c‹4…
’’
† ‡Xu p
w ‡p
—c‹&u o
l”u s}
w y~pqXsu onw pq p†v€q Xu ‚ ƒqX‚ q yt*† u ƒ
m
pt*s}u q pq p†&—c‹4…
’˜
† ‡&u pw &+y—c‹x,n
l”u s}
w y~pqmnv8q p
mpfv 8q &u*‚ ƒ
q&y
q † p
q u pw
u w † oŸ† mu m›…
’–
† ‡Xu p
w XZy
—c‹&u o
l,u s
}w y~p
q&s
u on
w p
q p†v 8q &u ‚ ƒ
q&y
q † pq u pw
u w † oŸ† mu m›…
˜“
† ‡&u pw 4•y—c‹x,n
l”u s}
w y~pqmnv8q p
mpfv 8q &u*‚ ƒ
q&y
q † p
q u pw
u w † † q ~t…
149
GUI-elementer samt underliggende funktioner
¾
ÆÇÈ
È ©
ªºº§
¨
¸M¥«©
ɧ¢´¨ ¡ «§
¤ ¢§
¹Å
° ¶X¡ §¤ ­4·¥²c³X»M¡ º
,¡ ¢£
¤ ¥¦§¨X¢¡ ºª¤ §¨ §°
«¬8¨ ­X¡ ® ¯¨X¥¨ ° §¨ ¡ §
¤
¡ ¤ ° ° ¨ ¦´µ
¹
³
° ¶X¡ §
¤ ­·4¥
±²c³4¸,ª
,¡ ¢
£¤ ¥¦§
¨4©
ª«¬€¨ §©­
§f«¬8¨ ­X¡ ® ¯¨X¥¨ ° §¨ ¡ §
¤
±²c³]° ¨ ¦´µ
¹
¼
° ¶X¡ §¤ ­4·¥±²c³X»M¡ º
,¡ ¢£
¤ ¥¦§¨X¢¡ ºª¤ §¨ §°
«¬8¨ ­X¡ ® ¯¨X¥¨ ° §¨ ¡ §
¤
±²c³]° ¨ ¦´µ
¹
Ä
° ¶X¡ §
¤ ­X£&Á¥&¸,ª
,¡ ¢
£¤ ¥¦§
¨4©
ª«¬€¨ §©­
§f«¬8¨ ­X¡ ® ¯¨X¥¨ ° §¨ ¡ §
¤
£&Á «¬€¨ ­&¡ µ
¹
Ã
° ¶X¡ §¤ ­&£&Á¥
»M¡ º
,¡ ¢
£¤ ¥¦§
¨&¢
¡ ºª
¤ §
¨ §°«¬€¨ ­&¡ ® ¯
¨&¥¨ ° §¨ ¡ §¤£XÁÂ
«¬8¨ ­X¡ µ
¹
À
° ¶X¡ §
¤ ­X»+«²c³4¸,ª
,¡ ¢£
¤ ¥¦§¨©ª«¬8¨ §©­§f« ¬8¨ ­&¡ ® ¯
¨X«§
©½X¢
¡ ¤ ° º¬Ÿ° ©
¡ ©¾4µ
¹
¿
° ¶&¡ §¤ ­&»4«²c³X»M¡ º
,¡ ¢
£¤ ¥¦§
¨&¢
¡ ºª
¤ §
¨ §°«¬€¨ ­&¡ ® ¯¨«§
©½X¢
¡ ¤ ° º¬Ÿ° ©
¡ ©¾4µ
¹
¹
° ¶X¡ §
¤ ­·«²c³4¸,ª
,¡ ¢£¤ ¥¦§
¨4©
ª«¬€¨ §©­
§f«¬8¨ ­X¡ ® ¯¨«§©
½&¢°
¡ ¤ ° ° ¨ ¦´µ
¹
Ê
° ¶&¡ §¤ ­4·&«²c³X»M¡ º
,¡ ¢£
¤ ¥¦§¨X¢¡ ºª¤ §¨ §°
«¬8¨ ­X¡ ® ¯¨«§©
½&¢°
¡ ¤ ° ° ¨ ¦´µ
Ê
Í
° ¶X¡ §
¤ ­·«±²c³4¸,ª
,¡ ¢£¤ ¥¦§
¨4©
ª«¬€¨ §©­
§f«¬8¨ ­X¡ ® ¯¨«§©
½&¢°
±²c³]° ¨ ¦´µ
ÊÅ
° ¶&¡ §¤ ­4·&«±²c³X»M¡ º
,¡ ¢£
¤ ¥¦§¨X¢¡ ºª¤ §¨ §°
«¬8¨ ­X¡ ® ¯¨«§©
½&¢°
±²c³]° ¨ ¦´µ
Ê
³
° ¶X¡ §
¤ ­X£&ÁZ«
¸,ª
,¡ ¢£
¤ ¥¦§¨©ª«¬8¨ §©­§f« ¬8¨ ­&¡ ® ¯
¨X«§
©½X¢
£&Á «¬€¨ ­&¡ µ
Ê
¼
° ¶X¡ §¤ ­&£&ÁZ«»M¡ º
,¡ ¢£
¤ ¥¦ §¨X¢¡ ºª¤ §¨ §°
«¬8¨ ­X¡ ® ¯¨«§©
½&¢£XÁÂ
«¬8¨ ­X¡ µ
Ê
Ä
° ¶&¡ §¤ ­4¶X¡ ²c³¸,ª
,¡ ¢£¤ ¥¦§
¨&¢¦¢° §ºf§° ¢® ¯
¨ ¢¤ ¥¾]° ¡ ¤
¨ §¢
£¡ ¨ ¥° ¯¨ ¡ ©­¢° ¡ ¤ ¤ ¡ ©¾
§©&Ë
¶&¡ ²c³4µ
Ê
Ã
° ¶X¡ §
¤ ­
Ì° ¸,ª
,¡ ¢£¤ ¥¦§
¨&¢¦¢° §ºf§° ¢® ¯
¨ ¢¤ ¥¾]° ¡ ¤
¨ §¢£
¡ ¨ ¥° ¯
¨ ¡ ©­¢° ¡ ¤ ¤ ¡ ©¾§
©&ËÌZ° µ
Ê
À
° ¶X¡ §
¤ ­¶&¨ §´6«§©¢&¸,ª
,¡ ¢£¤ ¥¦§
¨&¢¦¢° §ºf§° ¢® ¯
¨ ¢¤ ¥¾]° ¡ ¤
¨ §¢
£¡ ¨ ¥° ¯
¨ ¡ ©­¢° ¡ ¤ ¤ ¡ ©¾§
©&Ë® ¨ §
´*«§©¢&µ
Ê
¿
° ¶&¡ §¤ ­4É¥¢§§ÐЧ¢
,¡ ¢
£¤ ¥¦§
¨4£¥¨ ¥º§° §
¨ «¬8¨ ­X¡ §©f® ¯
¨ZÉÎ
Ê
¹
° ¶&¡ §¤ ­4·ÎÎM·
,¡ ¢£¤ ¥¦§
¨&® ¥¢°« ¬8¨ ­&¡ ® ¯
¨Z·ÎÎM·
Ê
Ê
° ¶X¡ §¤ ­4È Î
,¡ ¥
£¤ ¥¦§
¨&® ¥¢°«¬€¨ ­&¡ ® ¯¨+È Ï Î
ÑÒÓ
Ó ÔÕ
Ö××Ø
Ù
àMáÞÕ
ÚØÛÜÙ Ý ÞØ
ß ÛØ
â
ã
ÜÕáè
ìÜÝ î ç Ú+Ù ÖéØ
Ù
âð
ÜÕáè
ìÝ ×Ö
ß Ø
Ù
â
ë
ÜÕáè
ÑcåæXÜ ØÕæ
ñ íÕØÙß åéXÝ ÕfÞÝ Õæ&ÖØçåé]ç ØÙ ×Ý ÕØÙ Ø
Ù
Üß Ý Õ
Ý Ü*ØÙ ÞÝ ÕæXÖØç ê
ìÝ ×Öß ØÙ ØÙèáç Ý ØÕç Þ áÙ Ý á
íß ØÖæî Ù á
Üß Ý Õ
Ý Ü*ØÙ ØÕæïÝ Õæ
ç áÛç ØæØ
Ù ØÛ
èÝ Ù áç åÙ Ý ÕæÛç Ý ß ß Ý ÕéØ
Ù ê
ÑcåæXÜ ØÕæØ
Ù&æ
ØÝ Õæ
ç áÛç ØæØ
Ù ØÛ
èÝ Ù áç åÙ Ý ÕæÛç Ý ß ß Ý ÕéØ
Ù ê
â
ä
ÜÕáèXù&ø áØ
ß è
óáß æØÙ÷*ø áØ
ß èfÞÝ Õæ&ÖØç ê
â
ö
ÜÕá
èõ,î Ûß Öç
ò+ØÙ ×Ý ÕØÙ Ø
ÙZÔ,Ù êó+Õåôê
Knapper:
150
GUI-elementer samt underliggende funktioner
¾
C.3
UdviklerVindue
C.3.1
GUI-elementer
I det efterfølgende beskrives GUI elementerne inputfelter, outputfelter og knapper for udviklervinduet.
Inputfelter:
ú]ûýü
ü þ ÿ
ÿ
ÿ ÿ $ &
! ÿ
ÿ $( ÿ
$ ÿ '
$&% ÿ ÿ ÿ ÿ ÿ ! #
"
2
$0 #1 - . ÿ
( ÿ ÿ #)#* ,+ ÿ $+ - . / ÿ "
354766 8:9;<<=>
SDI9
O
=AR> ? I=C A=
PQ
K ? =C F(O
D> LM > D;<=
8@? ABC DE=>&F=9G=> =H#9=F=C D<GFDIJ*> F&?
K L>(GD> LM > D;<=&N
P\
K ? =C F#[7UEH=9=> ? 9H
8@? ABC DE=>&F=9G=> =H#9=F=C D<GFDIJ*> F&?
K L>&FZ> C ? HLUEH=9=> ? 9H(N
PX
K ? =C FY@V? FLA=Y7C RDC LA=
8@? ABC DE=>&F=9G=> =H#9=F=C D<GFDIJ*> F&?
K L>&DV? FLA=LH5DC R$DC LA=#N
PW
K ? =C F
6 C M M LU? V? M =M
8@? ABC DE=>&F=9G=> =H#9=F=C D<GFDIJ*> F&?
K L>
? C M M LU? V? M =M N
PT
K ? =C F#b(M ? C C ? 9HAG=M =H&9=C A=
]@? A=>#AM ? C C ? 9H
^K L>#F=9_IDC HM =RC ? 9? R=> N
P`
K ? =C F(aL> 9DI9
]@? A=>(9DI9#^K L>#F=9_IDC HM =RC ? 9? R=> N
cd
K ? =C F(f
K M => 9DI9
]@? A=>#=K M => 9DI9&^K L>&F=9_IDC HM =RC ? 9? R=> N
c
P
K ? =C FYe9V? =99? M =M
]@? A=>#D9V? =99? M =M ^K L>&F=9_IDC HM =RC ? 9? R=> N
cc
K ? =C FY@K F=C ? 9H
]@? A=>#DK F=C ? 9H
^K L>#F=9_IDC HM =RC ? 9? R=> N
cg
H&> DK a#> D<=
a&> D<=hIL>&DK I? H=C A=>
<=C C =<iRC ? 9? R$=>#LH
AEAM =<jK L> AC DHM ? C> =AB? > DM L> ? 9FAM ? C C ? 9H=>
H#> DK => 9=BC LM M =A&N
cQ
K ? =C F(kl> LV=A
],? A;DC ? A=> =>
hIL> C D9HM
G=> =H&9? 9H=9DK
C D<5GFD_=> N
Outputfelter:
151
m
GUI-elementer samt underliggende funktioner
Knapper:
noepp qsrtuuvw
~€|r
x
vyzw { |v} yv
‚
zr‹  „vrn/vu_ˆ Œu„…
 „rvw&‰vu_ˆ v} u„…|†!w …&{ vw#‡ Šw#vr_|} ‰ˆ
z} { r{ zvw#v} } vw(‹ˆ { vrˆ ‰&w t‹‹v

zr‹&x
vw v‰&r&Œu„…
x
vw v‰#rvw(} u„…|†!w …&{ vw#‡ Šw#vr_|} ‰ˆ
z} { r{ zvw#v} } vw(‹ˆ { vrˆ ‰&w t‹‹v
Ž
zr‹n/vuŒu„…
n/vu5uvw
} u„…|†*w …#{ vw&v‡ ˆ vw#|} ‰ˆ
‡ { } …vyˆ { rˆ { Šr
ƒ
zr‹#›&™ v} ‹
”
} …vw
˜$™ v} ‹_|{ r…&tvˆ š
—
zr‹–@‡ y} tˆ
‘lvw u{ rvw vw’q@w “”lrŠ•“
œ zr‹nw ‡ ž#{ Š
”lr‹…vw(z$} …vw#‰#w ‡#|{ r…#tv‡ w vuj‡ Šw
ž&{ Ÿ/
œ

zr‹nw ‡ ž#w v¢
”’r‹…vw
z} …vw&‰#w ‡|{ r…&tv‡ w vuj‡ Šw&‡
œ
zr‹n_w ‡ ¡ˆ
”lr‹…vw
z} …vw&‰#w ‡|{ r…&tv‡ w vuj‡ Šw&¡’ˆ
C.4
HjælpVindue
C.4.1
GUI-elementer
I det efterfølgende beskrives GUI elementerne inputfelter, outputfelter og knapper for hjælpvinduet.
Inputfelter:
Ingen
Outputfelter:
£¤e¥¥ ¦s§¨©©ª«
²³°§
¬
ª­®« ¯ °ª± ­ª
´µ
º ªÃº « ³©ª#Ä&Å ³ª± Æ
¶
« ³©_ª·ª«
¯ §·ª¸¹± ·ª«º ª®­º »·ª«
¼ª­®«¶ ¯ °ª«(¸¸°½®± ¯ §¯ ®ª« ª§­¹¾¨·°¯ ®± ª« ª§­
¼« ¨¾³¿l¦@«À½Ál§¹Â½
ÇÈeÉÉ ÊsËÌÍÍÎÏ
Ö×ÔË
Ð
ÎÑÒÏ Ó ÔÎÕ ÑÎ
ÒË×Þ Ì Ò
Ú
Ì ÒÒ$ÎÏ
Û$Ü Ý!Õ ÞÔÓ Ëß#ÌÎà#áâ5ÔÎËßÎÏà Ó Õ ã×âÎ_à Ó Õ
Ú ßÎÏ#áÞÏ Ó ËßÎÕ Ó âÎ_ÔÓ Ëß&ÌÎ&äÛÔáÏ(ÛåÜ Ý*Õ ÞãÕ ÎÔ
Ò$×Õ ßàæ Ï ×
Knapper:
Ø(Ù
152
m
GUI-elementer samt underliggende funktioner
C.5
Liste over funktioner
Ved at se på hvilke sekvenser af begivenheder, der optræder, når en given knap på GUI´en aktiveres, er det
muligt at finde alle funktionerne. Disse er beskrevet i det efterfølgende. Der inddeles i to forskellige levels:
Level 1: De funktioner der håndterer brugergrænsefladen og dermed hører til boundary.
Level 2: Andre funktioner hørende til control.
C.5.1
Loginvindue: level 1 funktioner
I det efterfølgende opstilles de funktioner, der kan identificeres ud fra aktivitetsdiagrammerne.
Læs fra GUI:
ç&èéê$ë ì íéîï ðséèññòó
÷øõé
ô(òîêó ì õòö îò
ù
òéë ô’ó èòó
òéë òóó èòó ë ýòü ó øì éýèë ü òö ëþ(ù
òéë çíó éøõé
ÿ
òéë ü ë òó éøõé
û òéë òó#òü ë òó éøõéü ó øì éýèë ü òö ëþ#ÿ
ú
òéë eé
ì òééì ë òë
û òéë òó#øéì òééì ë òë#ü ó øì éýèë ü òö ëþ#ú
òéë @ü òö ì é
òéë lë ì ö ö ì éîòë ò
#éòö îò
òéë lö ì éì êòó
û
û
òéë òó#ü íó éøõéü ó øì éýèë ü òö ëþ
òéë òó#øü òö ì é
ü ó øì éýèë ü òö ëþ
òéë òû ó#îë ì ö ö ì é
îòë ò
#éòö îòü ó øì éýèë ü òö ëþ
òéë òó(êö ì éì êòó õì îòóøóõ!ó òëòë
ë ì &ö ì òó òö í
#ì éü ó øì éýèë ü òö ëþ
û
û
GUI knapper:
!#" $%&'&()
.0/,+
*(!+) ,(- !
(
1
/
<+ =3/41
23,+ !'+/4>51'/@ ,() (!;+!+ /) ()
/ !
!(,(
!
?
/
<+ =3/4?
23,+ !'+/4>5?'/@ ,() (!;+!+ /) ()
/ !
!(,(
!
7+9
/
<+ =8
/47+9
23, !'
/46587+9:/ ,() (
!;+! /) ()
/ !
!(,(
!
153
m
GUI-elementer samt underliggende funktioner
C.5.2
Loginvindue: level 2 funktioner
Funktionerne hørende til control er her opstillet.
C.5.3
ABCD@E F GCH#I JKCBL'LMN
SUT+QC
OPM
HDN F QMR HM
VV
T
i HR B+E fG e F C`jF C
]B
M
W8E TN E M
H'X+QF H'D+C
TY>Zh:TDE F QdMN M
H\
Vg
e G
]DdMC]fG e F C
W8E TN E M
H'X+QF H'D+C
TY>Zc:TDE F QdMN M
H\
Vb
DTR ]^_ T
MR Y
`aF C
]BM
WE TN E MH'XQF H'D+CTY>ZV+['TDE F QMN M
H\
Vn
HE TN E m3R F CF DMN `aF C]BM
W8E TN E MNPD+R F CF DMN QF C
]BME \
Vl
H+E TN E k0]
QF DR MN `aF C
]B
M
WE TN E MNB]QF D+R MN QF C
]B
M+E \
Vu
DdGCE N GR R MN rYR oHCF C e MN
mGCE N GR R MN MNGLtD+R F CF DdMN MC'XTNB]i oR ]ETR R M
GYR oHCF C e MN \
Vs
XMC+E rYR odHCC e MN
^0MC+E MNGYR oHCF C e MNi N THDdpqN LMCG e
e ML'L>MN]ML#\
Vh
DGCE N GR R MN w8o+Y
MO8N B e M N
mGCE N GR R MN MNPXQF R DMC'vN B e MN E oYM]MNMN
QTR e E \
Klinikervindue: level 1 funktioner
Læs fra GUI:
xyz{@| } ~z#€ Kzy‚'‚ƒ„
ˆU‰+†z
…Pƒ
{„ } †ƒ‡ ƒ
Š‹
“ƒz| x} ™6–
0ƒz+| ƒ„3x} ™6–: „ ‰'} zy|  ƒ‡ |‘Šš
ŠP˜
“
ƒz+| x„ ƒ{@†ƒz
0ƒz| ƒ„ „ ƒ{†dƒz
> „ ‰'} zy|  ƒ‡ |‘Š—
Š–
“ƒz+| ”0•0} Ž‰‡
0ƒz| ƒ„| } Ž‰‡ †d~‡ y‚ƒz> „ ‰'} zy|  ƒ‡ |‘Š’
ŠŒ
“ƒz+| ›P‰+| } ƒz+| Ÿ„ yƒ
0ƒz| ƒ„P
‰+| } ƒz+| „ y
ƒ „ ‰'} zy|  ƒ‡ |‘Šž
Šœ
“
ƒz| ›P‰| } ƒz| ˆay‚'‚ƒ„
0ƒz+| ƒ„‰| } ƒz| zy‚'‚ƒ„ „ ‰'} zy+|  ƒ‡ |‘š‹
154
m
GUI-elementer samt underliggende funktioner
Skriv til GUI:
¡¢£¤ ¥ ¦¢
§#¨ ©%¢¡ª'ª«¬
°0±®+¢
­«§£+¬ ¥ ®«¯ §
«
²³
§£¬ ¥ ®µ0À¡¢¤
µ0£+¬ ¥ ®«¬®¶·¬ ¸¥d¹ ¦¬§À¡¢¤¤ ¥ ¯d¦¡¤ »¡+¤ ¹ «¯ ¤¼²¿
²¿
§£¬ ¥ ® ¾a½
µ0£+¬ ¥ ®d«¬®¶·¬ ¸¥¹ ¦¬3 ¾a½:¤ ¥ ¯d¦¡¤ »¡+¤ ¹ «¯ ¤¼²½
²½
§£¬ ¥ ®º0¸
µU£¬ ¥ ®«¬®d¶·¬ ¸¥d¹ ¦¬º0¸:¤ ¥ ¯¦¡¤ »¡¤ ¹ «¯ ¤¼²´
²´
§£+¬ ¥ ®Å
µ0£+¬ ¥ ®«¬®¶·¬ ¸¥d¹ ¦¬PÅƤ ¥ ¯d¦¡¤ »¡+¤ ¹ «¯ ¤¼²Ä
²Ä
§£+¬ ¥ ®Ãa¦ª'»¯ ¥ ±¢Á
«
µ0£+¬ ¥ ®«¬®¶·¬ ¸¥d¹ ¦¬Á
¦ª:»¯ ¥ ±¢
Á
«>¤ ¥ ¯d¦¡+¤ »¡¤ ¹ «¯ ¤
¼²Â
²Â
§£¬ ¥ ®Ç0«§¥ §¤ ±¢
Á«
µ0£+¬ ¥ ®d«¬®¶·¬ ¸¥¹ ¦¬¬ «§¥ §+¤ ±¢
Á«>¤ ¥ ¯d¦¡¤ »¡+¤ ¹ «¯ ¤
¼²²
²²
§£¬ ¥ ®ºaÎ6½
µU£¬ ¥ ®«¬®d¶·¬ ¸¥d¹ ¦¬ºaÎ6½:¤ ¥ ¯¦¡¤ »¡¤ ¹ «¯ ¤¼²Ï
²Ï
§£¬ ¥ ®ºaÃÊÎ6½
µU£¬ ¥ ®«¬®¶q¬ ¸¥d¹ ¦¬PÃÊÎ6½:¤ ¥ ¯¦¡+¤ »¡¤ ¹ «¯ ¤¼²Í
²Í
§£+¬ ¥ ®©ÊÉ8Ë
µ0£+¬ ¥ ®«¬®¶q¬ ¸¥d¹ ¦¬8©ÊÉ8Ë̤ ¥ ¯d¦¡+¤ »¡¤ ¹ «¯ ¤¼²È
²È
§£¬ ¥ ®ÐaÑ
µU£¬ ¥ ®«¬®¶q¬ ¸¥d¹ ¦¬3ÐaÑ>¤ ¥ ¯¦¡+¤ »¡¤ ¹ «¯ ¤¼Ï³
ϳ
§£¬ ¥ ®Ãa¦ÐaÑ
µ0£+¬ ¥ ®«¬®¶·¬ ¸¥d¹ ¦¬ Ãa¦ÐaÑ>¤ ¥ ¯d¦¡+¤ »¡¤ ¹ «¯ ¤¼Ï¿
Ï¿
§£+¬ ¥ ®Ò«¤ ÐaÑ
µ0£+¬ ¥ ®«¬®¶q¬ ¸¥d¹ ¦¬PÒ«¤ ÐaÑ>¤ ¥ ¯¦¡+¤ »¡¤ ¹ «¯ ¤¼Ï½
Ͻ
§£¬ ¥ ®Ô8«ª:»
µ0£+¬ ¥ ®d«¬®¶·¬ ¸¥¹ ¦¬Ô8«ª:»>¤ ¥ ¯d¦¡¤ »¡+¤ ¹ «¯ ¤¼Ï´
Ï´
§£+¬ ¥ ® «ÃÊÎ6½°a¡
µU£¬ ¥ ®«¬®¶q¬ ¸¥d¹ ¦¬3 «ÃÊÎ6½PÓ
¢¡+®¶·¬ «¢
¸«Ó¤ ¥ ¯
¦¡¤ »¡+¤ ¹ «¯ ¤¼ÏÄ
ÏÄ
§£¬ ¥ ® «ÃÊÎ6½µU¥ ª
µ0£+¬ ¥ ®d«¬®¶·¬ ¸¥¹ ¦¬3 «ÃÊÎ6½PÓ+§¥ ª'¡¯ «¬ «¤ Ó¤ ¥ ¯
¦¡¤ »¡+¤ ¹ «¯ ¤¼ÏÂ
ÏÂ
§£+¬ ¥ ® «Î6½°a¡
µU£¬ ¥ ®«¬®¶q¬ ¸¥d¹ ¦¬8 «Î6½PÓ
¢¡+®¶·¬ «¢
¸«Ó¤ ¥ ¯
¦¡¤ »¡+¤ ¹ «¯ ¤¼Ï²
ϲ
§£¬ ¥ ® «Î6½µU¥ ª
µ0£+¬ ¥ ®d«¬®¶·¬ ¸¥¹ ¦¬3 «Î6½PÓ+§¥ ª'¡¯ «¬ «¤ Ó¤ ¥ ¯
¦¡¤ »¡+¤ ¹ «¯ ¤¼ÏÏ
155
m
GUI-elementer samt underliggende funktioner
ùäãÖ@å Ø Þã ë#ú û ãäí'íÚ×
ìUß+Ùã
üPÚ ë Ö × Ø ÙÚæ ë Ú
éé
ë Ö+× Ø ÙÕ8ßà6áPìaä
Õ0Ö+× Ø ÙdÚ×ÙÛ·× ÜØÝ Þ×Õ8ßà6áâ
ãäÙdÛ·× Úã
ÜÚâdå Ø æ
Þäå çäå Ý Úæ åèéê
éê
ë Ö+× Ø Ù+Õ3ßà6áÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØdÝ Þ×PÕ8ßà6áâ ë Ø í'äæ Ú× Úå âdå Ø æ
Þäå çäå Ý Úæ åèéî
éî
ë Ö+× Ø ÙïPßà6áPìaä
Õ0Ö+× Ø ÙdÚ×ÙÛ·× ÜØÝ Þ×3ïPßà6áâ
ãäÙdÛ·× Úã
ÜÚâdå Ø æ
Þäå çäå Ý Úæ åèêø
êø
ë Ö+× Ø Ù
ïßà6áÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØdÝ Þ×8ïPßà6áâ ë Ø í'äæ Ú× Úå âdå Ø æ
Þäå çäå Ý Úæ åèêPò
êPò
ë Ö× Ø ÙïPßðÊà6áPìaä
Õ0Ö+× Ø ÙdÚ×ÙÛ·× ÜØÝ Þ×3ïPßðñàñáâ
ãäÙÛq× Úã
ÜÚâdå Ø æ
Þäå çäå Ý Úæ åèêá
êá
ë Ö+× Ø Ù
ïßðÊà6áÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØdÝ Þ×8ïPßðÊà6áâ ë Ø í'äæ Ú× Úå âdå Ø æ
Þäå çäå Ý Úæ åèêó
êó
ë Ö+× Ø ÙçöUßìaä
Õ0Ö+× Ø ÙdÚ×ÙÛ·× ÜØÝ Þ×çö0ßâ
ãäÙdÛ·× ÚãÜÚâdå Ø æ
Þäå çäå Ý Úæ åèê÷
ê÷
ë Ö+× Ø Ù+çö0ßÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØdÝ Þ×Pçö0ßâ ë Ø í'äæ Ú× Ú+å âdå Ø æ
Þäå çäå Ý Úæ åèêõ
êõ
ë Ö× Ø ÙÕÙà6áPìaä
Õ0Ö+× Ø ÙdÚ×ÙÛ·× ÜØÝ Þ×ÕÙà6áPâ
ãäÙÛq× Úã
ÜÚâdå Ø æ
Þäå çäå Ý Úæ åèêô
êô
ë Ö+× Ø Ù+Õ8Ù+à6áÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØdÝ Þ×PÕÙà6áâ ë Ø í'äæ Ú× Úå âdå Ø æ
Þäå çäå Ý Úæ åèêé
êé
ë Ö× Ø ÙïÙà6áPìaä
Õ0Ö+× Ø ÙdÚ×ÙÛ·× ÜØÝ Þ×3ïÙà6áPâ
ãäÙÛq× Úã
ÜÚâdå Ø æ
Þäå çäå Ý Úæ åèêê
êê
ë Ö+× Ø Ù
ïPÙ+à6áÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØdÝ Þ×8ïÙà6áâ ë Ø í'äæ Ú× Úå âdå Ø æ
Þäå çäå Ý Úæ åèêî
êî
ë Ö× Ø ÙïÙðÊà6áPìaä
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØÝ Þ×3ïÙðÊà6áPâ
ãäÙÛq× Úã
ÜÚâdå Ø æ
Þäå çäå Ý Úæ åèîø
îø
ë Ö+× Ø Ù
ïPÙ+ðÊà6áÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛq× ÜØdÝ Þ×8ïÙðÊà6áâ ë Ø í'äæ Ú× Úå âå Ø æ
Þäå çäå Ý Úæ åèîPò
îPò
ë Ö× Ø Ùçö3Ùìaä
Õ0Ö+× Ø ÙdÚ×ÙÛ·× ÜØÝ Þ×çö3Ùâ
ãäÙÛq× Úã
ÜÚâdå Ø æ
Þäå çäå Ý Úæ åèîá
îá
ë Ö+× Ø Ù+çö3ÙÕ0Ø í
Õ0Ö+× Ø ÙÚ×ÙÛ·× ÜØdÝ Þ×Pçö3Ùâ ë Ø í'äæ Ú× Úå âdå Ø æ
Þäå çäå Ý Úæ åèîó
îó
ë Ö+× Ø Ù
ùØ à6áìaä
Õ0Ö+× Ø ÙÚ× ëýë å ÚíÚåÝ Þ× ë æ ß
þ:å Ø æ
× Ú ë çØ × ß+å Þ× Ø ãÜ ë å Ø æ æ Ø ãþÚãâùØ à6áâdå Ø ædÞäå çä+å Ý Úæ å
èî÷
î÷
ë Ö× Ø Ùÿ3å ìaä
Õ0Ö+× Ø ÙÚ× ë ýë å ÚíÚåÝ Þ× ë æ ß
þ:å Ø æ
× Ú ë ç Ø × ßå Þ× Ø ã
Ü ë å Ø æ æ Ø ãþÚãâ+ÿ3å âå Ø æÞä+å çäå Ý Úæ å
èîõ
îõ
ë Ö+× Ø Ùù× ÚÖÙÚã ë ìjä
Õ0Ö+× Ø ÙÚ× ëýë å ÚíÚåÝ Þ× ë æ ß
þ:å Ø æ
× Ú ë çØ × ßå Þ× Ø ã
Ü ë å Ø æ æ Ø ãþÚãâ+Ý × ÚÖ@ÙÚã ë âå Ø æ
Þäå çäå Ý Úæ åèîô
156
m
GUI-elementer samt underliggende funktioner
GUI knapper:
, *-.$3
"# $&%3 ( *) +
2
, *-.$0
"# $&%01 ( *) +
/
, *-.$'
"# $&%' ( *) +
!
, *-.$6
"# $&%6 ( *) +
5
, *-.$4
"# $&%4 ( *) +
23
, *-.$
"# $&% ( *) +
157
m
GUI-elementer samt underliggende funktioner
C.5.4
Klinikervindue: level 2 funktioner
Funktionerne hørende til control er her opstillet.
7*89:<; = >9?@ AB98CCDE
JLKH9
FGD?:E = HDI ?D
MN
?:= _ ; F.E 8 V DE
P; KE ; D?QH= ?:9KR&SN^K:; = HDE D?U
M]
?= C8I DE ZGK; = D9; [LKE = K\I D
P; KE ; D?QH= ?:9KR&SNY1K:; = HDE D?U
MX
V >W:(D9WG@ 9W?; = I I = 9 V DE
P; KE ; D?QH= ?:9KR&SNTK:; = HDE D?U
MO
:KI Wde KDI R[f= 9W8D
P; KE ; D?QH= ?:9KR&SNcK:; = HDE D?U
MM
K_ ?I 8; a.I = 9= :(DE [b= 9W*8D
P; KE ; D?QH= ?:9KR&SN`K:; = HDE D?U
Y^^
QD9; ZK; = D9; @ 9= ; = KI P.; K; D
P; KE ; D?QH= ?:9KR&SNNK:; = HDE D?U
Y^Y
:>9; E >I I DE m.lRDF.E 8 V DE
ib9WDE ?j V DEGQH= I :(D9k\E 8 V DE ; lRDWDE*DE
HKI V ; U
Y^T
QD9; ZGK; = D9; hE 8RRD
dD9; DEGI = ?; DCDWRK; = D9; V E 8RRDEgU
Y^c
:(>9; E >I I DE ALK; Kh1DC&;
P; KE ; D?QH= ?:9KR&SN^K:; = HDE D?U
Y^`
V DCAK; K
P; KE ; D?QH= ?:9KR&SN^K:; = HDE D?U
Y^N
K_ ?I 8; P.D??= >9
P; KE ; D?QH= ?:9KR&SN^K:; = HDE D?U
Y^]
?; KE ; J#lP.D??= >9
aGKI WDEGI > V = 9H= 9W8D;G9nE*WDE*?:KI(?:= _ ; D?
\E 8 V DE U
Y^X
QD9; a.I = 9= :(DE @ 9W?; = I I = 9 V
P; KE ; D?QH= ?:9KR&SNY1K:; = HDE D?U
Y^O
:(>9; E >I I DE @ 9W?; = I I = 9 V
P; KE ; D?QH= ?:9KR&SNY1K:; = HDE D?U
Y^M
= 9W*I KD?ZGK; = D9; ZGKE KCD; E D
P; KE ; D?QH= ?:9KR&SNY1K:; = HDE D?U
YY^
8W*E D V 9[LKE = K\I D
P; KE ; D?QH= ?:9KR&SNY1K:; = HDE D?U
YYY
:(>9; E >I I DE @ 9W?; = I I = 9 V
P; KE ; D?QH= ?:9KR&SNTK:; = HDE D?U
YYT
V DC@ 9W?; = I I = 9 V
P; KE ; D?QH= ?:9KR&SNTK:; = HDE D?U
158
m
GUI-elementer samt underliggende funktioner
C.5.5
Udviklervindue: level 1 funktioner
Læs fra GUI:
opqrs t uqvw xqpyyz{
€}q
|zvr{ t }z~ vz
‚
‰zqs ‹.~ t qt r(z{
ƒzqs z{*}€~ …k€†r~ t qt r(z{† { €t q„ps † z~ s‡.ˆˆ
ˆ
‰zqs ŠG€s t zqs …*{ p„„z
ƒzqs z{„€s t zqs …{ p„„z&}€~ …† { €t q„ps † z~ s
‡ˆ
ŒŽ ‘ ’Ž“” •Ž––—˜
œšŽ
™—“˜ ‘ š—› “—
žž
“˜ ‘ š™G˜ ’ ˜ –—
˜ ‘ š(—˜G› –¡¢£ ’˜¡˜ ’ ˜ –—& ‘ ›
’ ¦ £ —› §¨¬
ž³
“˜ ‘ š±²¯°®—Ž—˜ ‘ Ž®
˜ ‘ š(—˜G› –k¡¢&£ ’˜¢­˜ › ‘ ®’¯(°®—Ž—˜ ‘ Ž® ‘ ›
’ ¦ £ —› §¨Ÿ
ž¬
“˜ ‘ šªf¤‘ ¢’“—ª«› (› ’“—
˜ ‘ š(—˜G› –k¡¢£ ’˜¤‘ ¢’“—¥ › (› ’“—& ‘ ›
’ ¦ £ —› §¨©
žŸ
“˜ ‘ š” ›   ’¯‘ ¤‘  —
˜ ‘ š—˜G› –¡¢£ ’˜G‘ ›   ’¯‘ ¤‘  — ‘ ›(’ ¦ £ —› 
§¨µ
ž©
“˜ ‘ š . ‘ › › ‘ Ž®“¡— —®Ž—› “—
L˜ ‘ š—˜“ ‘ › › ‘ Ž®“¡— —®Ž—› “—& ‘ ›’ ¦ £ —› 
§¨´
žµ
“˜ ‘ šŒ’˜ ŽšŽ
L˜ ‘ š—˜£ ’˜ ŽšŽ& ‘ ›(’ ¦ £ —› §¨·
ž´
“˜ ‘ š¸G£  —˜ ŽšŽ
˜ ‘ š—˜*—£  —˜ ŽšŽ& ‘ ›(’ ¦ £ —› §ž¶
ž·
“˜ ‘ šª«Ž¤‘ —ŽŽ‘  —
L˜ ‘ š—˜Ž¤‘ —ŽŽ‘  — ‘ ›’ ¦ £ —› §*žG¨
³¶
“˜ ‘ šªf£ ¢—› ‘ Ž®
˜ ‘ š—˜ªf£ ¢—› ‘ Ž®k ‘ ›(’ ¦ £ —› §*žž
³¨
“˜ ‘ š¹˜ £g• 
L˜ ‘ š—˜®*˜ £*¢ & ‘ ›’ ¦ £ —› §*ž³
º»¼½¾ ¿ À¼Á ü»ÄÄÅÆ
ÊËȼ
ÇÅÁ½Æ ¿ ÈÅÉ ÁÅ
ÌÍ
ËÕ¾ ¿ À¼*Ö.¼ËÐÍÎ
Ï#È¿ Á½¼ËÐ&ÑÍÎ˽¾ ¿ È(ÅÆ ÅÁ*ÓÁ¾ ËÆ ¾ ÅÁ
˽¾ ¿ À¼ÁÁŽÈżÁÔ
ÌÌ
ËÕ¾ ¿ À¼*Ö.¼ËÐÍØ
Ï#È¿ Á½¼ËÐ&ÑÍØ˽¾ ¿ È(ÅÆ ÅÁ*ÓÁ¾ ËÆ ¾ ÅÁ
˽¾ ¿ À¼ÁÁŽÈżÁÔ
Ì×
ËÕ¾ ¿ À¼*Ö.¼ËÐÍÒ
Ï#È¿ Á½¼ËÐ&ÑÍÒ˽¾ ¿ È(ÅÆ ÅÁ*ÓÁ¾ ËÆ ¾ ÅÁ
˽¾ ¿ À¼ÁÁŽÈżÁÔ
ÌÎ
ËÕ¾ ¿ À¼*Ö.¼ËÐÍÚ
Ï#È¿ Á½¼ËÐ&ÑÍÚ˽¾ ¿ È(ÅÆ ÅÁ*ÓÁ¾ ËÆ ¾ ÅÁ
˽¾ ¿ À¼ÁÁŽÈżÁÔ
ÌØ
ËÕ¾ ¿ À¼*Ö.¼ËÐÍÙ
Ï#È¿ Á½¼ËÐ&ÑÍÙ˽¾ ¿ È(ÅÆ ÅÁ*ÓÁ¾ ËÆ ¾ ÅÁ
˽¾ ¿ À¼ÁÁŽÈżÁÔ
Skriv til GUI:
GUI knapper:
159
m
GUI-elementer samt underliggende funktioner
C.5.6
Udviklervindue: level 2 funktioner
Funktionerne hørende til control er her opstillet.
Û*ÜÝÞ<ß à áÝâã äBÝÜååæç
ëLìéÝ
èGæâÞç à éæê âæ
íî
ñæÝß ü1æå1ß ÷ìåøùì
ðß ìç ß æâñéà âÞÝìò&óîïìÞß à éæç æâõ
íí
øæç æ ö Ý*÷ìåkøùì
ðß ìç ß æâñéà âÞÝìò&óîûìÞß à éæç æâõ
íú
ö æåèGæç æ ö Ýæß ÷ìåøùì
ðß ìç ß æâñéà âÞÝìò&óîôìÞß à éæç æâõ
íï
Þìê ù ìæê òfà ÝùÜæ
ðß ìç ß æâñéà âÞÝìò&óîìÞß à éæç æâõ
íû
ìþ âê Üß ÿùéà Þê æç fà ÝùÜæ
ðß ìç ß æâñéà âÞÝìò&óîýìÞß à éæç æâõ
íô
à Ýù*ê ìæâ.ê à Ýà Þ(æç
ã Ýù*ê ìæâæçÞê à Ýà Þ(æçGç æâòà ç ìß áç à Ýùâß à ê ê à Ý ö æç
í
Þ(áÝß ç áê ê æç .ê à Ýà Þ(æç
ÿfÝùæç â
ö æçáå Þê à Ýà Þ(æçñìç ö æå1ß*ùìß ì*õ
íý
ììøæÝ*Ûà ê
ðß ìç ß æâñéà âÞÝìò&óîïìÞß à éæç æâõ
ú
Þ(áÝß ç áê ê æç Û*à ê ÝìéÝ
ðß ìç ß æâñéà âÞÝìò&óîïìÞß à éæç æâõ
ú
Þ(áÝß ç áê ê æç Û*à ê Ûáç åìß
ðß ìç ß æâñéà âÞÝìò&óîïìÞß à éæç æâõ
úî
à Ýù*ê ìæâÛ*à ê
ðß ìç ß æâñéà âÞÝìò&óîïìÞß à éæç æâõ
úí
ÞáÝß ç áê ê æç ÷ìåøùì
ðß ìç ß æâñéà âÞÝìò&óîôìÞß à éæç æâõ
úú
ììøæÝü1æåÛ*à ê
ðß ìç ß æâñéà âÞÝìò&óîôìÞß à éæç æâõ
úï
ìþ øç (ùèGæç æ ö Ýà Ý ö
160
fþ øç ùæçà ö ìÝ ö é ç æÝùæøæç æ ö Ýà Ý ö ìþ
ê ìåøùìõ
m
GUI-elementer samt underliggende funktioner
C.5.7
Hjælpvindue: level 1 funktioner
Skriv til GUI:
"!#
)+*%'&
$!%&# '!( !
,-
&# '90 *%!( 3:;!5&
.+&# '!#/0 12( 34 !5% !4 (5% 3& 6 !( 78-
<=>?@ A B>CD E>=F F"GH
L+M%J&>
IG%C?&H A JGK CG
MX&@ A B>VY;>MQSO
J&A C ?&>%MQ4RSOTM?@ A J5GH GCVU&C%@ MH @ GC
P
M?@ A B>%CCG?JG>%CW
Z[\]^ _ `\ab c\[d d"ef
j+k%h&\
ge%a]&f _ hei ae
lm
k%u ai [&^ vw kei p%xy_ \zV[e
n;^ kf ^ efo%h&_ a ]\kp4qrsTk]^ _ h5ef eaVt
GUI knapper:
NO
C.5.8
Hjælpvindue: level 2 funktioner
161
APPENDIKS
D
Attributter i GUI-klasser
I dette afsnit forefindes attributterne til de forskellige klasser, der er defineret i kapitlet om GUI-klasser i Dr.
Know (se kapitel 11 på side 71). Attributterne beskrives således for klasserne LoginVindue, KlinikerVindue,
UdviklerVindue og HjaelpVindue. Der beskrives ikke attributter for klassen GrafFunktion.
D.1
LoginVindue
{|}
~ €ƒ‚ „
…%‚ „†ƒ‡ˆ
†Ž‚ ‹ ˆŒ
 …‚ „†ƒ‡Š ˆ
‚ „‚ ‹ ˆŒ
‰5…Š ‚ „†ƒ‡ˆ
ˆ
…%‘ƒ‚ ’ „“ †ƒ‡Š ” ˆ
-kliniker:Kliniker Et objekt som indeholder klinikeroplysninger.
-database:Database Et objekt som opretter forbindelse til databasen.
-vindueTitel:String Titlen på vinduet, som vises i vinduets titellinje.
-knapOk:JButton Knap med label ”Ok”.
-knapAfslut:JButton Knap med label ”Afslut”.
-knapHjaelp:JButton Knap med label ”Hjælp”.
-boksBruger:JComboBox Kombinationsboks til valg af bruger.
-boksStillingsbetegnelse:JComboBox Kombinationsboks til valg af titel.
+labelBrugertype: JLabel Label på GUI med teksten ”Vælg brugertype:´´
-labelFornavn:JLabel Label på GUI med teksten ”Fornavn:”.
-labelEfternavn:JLabel Label på GUI med teksten ”Efternavn:”.
-labelAnciennitet:JLabel Label på GUI med teksten ”Anciennitet:”.
-labelAfdeling:JLabel Label på GUI med teksten ”Afdeling:”.
163
m
Attributter
i GUI-klasser
•
-labelStillingsbetegnelse:JLabel Label på GUI med teksten ”Stillingsbetegnelse:”.
-tFieldFornavn:JTextField Tekstfelt til indtastning af klinikers fornavn.
-tFieldEfternavn:JTextField Tekstfelt til indtastning af klinikers efternavn.
-tFieldAnciennitet:JTextField Tekstfelt til indtastning af klinikers anciennitet.
-tFieldAfdeling:JTextField Tekstfelt til indtastning af klinikers afdeling.
-tAreaKlinikerInfo:JTextArea Tekstområde med teksten ”Udfyldes af kliniker”.
-loginVindue:LoginVindue En reference til LoginVindue. Denne reference bruges af den indre klasse HaendelseKontrol.
D.2
KlinikerVindue
–—˜
™ š›ƒœ 
žœ Ÿƒ ¡
œ œ ¤ ¡¥
¢ž%£ œ Ÿƒ ¡
Ÿ§ œ ¤ ¡¥
¦ žœ Ÿ £ ¡
¡
ž¨œ © ª Ÿƒ £ « ¡
erLoggetPaa:Kliniker Et objekt som indeholder alle oplysninger om klinikeren som er logget på.
+patientState:PatientState Et objekt som indeholder patientvariable.
+simulering:PatientState Et objekt som indeholder de simulerede patientvariable.
+initialState:initialState Et objekt som indeholder patientparametrene.
+settings:Settings Et objekt som indeholder respiratorindstillinger.
prediction:Prediction Et objekt som kaldes når variblene skal simuleres.
+patientGruppe:String Et stringobjekt som indeholder navnet på patientgruppen.
+FIO2:Double En double som indeholder FiO2 -indstillingen.
+Vt:Double En double som indeholder Vt-indstillingen.
+Frekvens:Double En double som indeholder frekvens-indstillingen.
+caseNummer:Int Et heltal som indeholder casenummeret.
+caseNummerFlag:Int[20 ] Et array af 20 heltal.
+patientGruppeFlag:Int[3 ] Et array af 3 heltal.
-vindueTitel:String Titlen på vinduet, som vises i vinduets titellinje.
-knapHjælp:JButton Knap med label ”Hjælp”.
-knapAfslut:JButton Knap med label ”Afslut”.
-knapGodkend:JButton Knap med label ”Godkend”.
-knapSimuler:JButton Knap med label ”Simulér”.
-knapSkiftBruger:JButton Knap med label ”Skift bruger”.
-boksPatientgruppe:JComboBox Kombinationsboks til valg af patientgruppe.
-boksPatientNummer:JComboBox Kombinationsboks til valg af patientcase.
-labelBruger:JLabel Label på GUI med teksten ”Bruger:”.
164
¬
Attributter i GUI-klasser
-labelPatientParametre:JLabel Label på GUI med teksten ”Patientparametre”.
-labelGasudveksling:JLabel Label på GUI med teksten ”Gasudveksling”.
-labelShunt:JLabel Label på GUI med teksten ”Shunt [%]:”.
-labelFA2:JLabel Label på GUI med teksten ”FA2 [fraktion]:”.
-labelVdead:JLabel Label på GUI med teksten ”Vdead [l]:”.
-labelCirkulation:JLabel Label på GUI med teksten ”Cirkulation”.
-labelCardiac:JLabel Label på GUI med teksten ”Q [l/min]:”.
-labelLungedynamik:JLabel Label på GUI med teksten ”Lungedynamik”.
-labelCompliance:JLabel Label på GUI med teksten ”Compliance [l/cmH2O]:”.
-labelResistance:JLabel Label på GUI med teksten ”Resistance [cmH20/l/s]:”.
-labelMetabolisme:JLabel Label på GUI med teksten ”Metabolisme”.
-labelVO2:JLabel Label på GUI med teksten ”V02 [l/min]:”.
-labelVCO2:JLabel Label på GUI med teksten ”VCO2 [l/min]:”.
-labelBlod:JLabel Label på GUI med teksten ”Blod”.
-labelDPG:JLabel Label på GUI med teksten ”DPG [%]:”.
-labelHb:JLabel Label på GUI med teksten ”Hb [mmol/l]:”.
-labelCOHb:JLabel Label på GUI med teksten ”COHb [fraktion]:”.
-labelMetHb:JLabel Label på GUI med teksten ”MetHb [fraktion]:”.
-labelTemp:JLabel Label på GUI med teksten ”Temp [C]:”.
-labelBE:JLabel Label på GUI med teksten ”BE [mmol/l]:”.
-labelPatientVariable:JLabel Label på GUI med teksten ”Patientvariable”.
-labelLungeVariable:JLabel Label på GUI med teksten ”Lungevariable”.
-labelNuvaerende:JLabel Label på GUI med teksten ”Nuværende”.
-labelSimuleret:JLabel Label på GUI med teksten ”Simuleret:”.
-labelFeCO2:JLabel Label på GUI med teksten ”FeCO2 [%]:”.
-labelFeO2:JLabel Label på GUI med teksten ”FeO2 [%]:”.
-labelPIP:JLabel Label på GUI med teksten ”PIP [cmH2 O]:”.
-labelArterieltBlod:JLabel Label på GUI med teksten ”Arterielt blod”.
-labelSaO2:JLabel Label på GUI med teksten ”SaO2 [%]:”.
-labelPaO2:JLabel Label på GUI med teksten ”PaO2 [kPa]:”.
-labelPaCO2:JLabel Label på GUI med teksten ”PaCO2 [kPa]:”.
-labelpHa:JLabel Label på GUI med teksten ”pHa:”.
-labelVeneBlod:JLabel Label på GUI med teksten ”Venøst blod”.
-labelSvO2:JLabel Label på GUI med teksten ”SvO2 [%]:”.
-labelPvO2:JLabel Label på GUI med teksten ”PvO2 [kPa]:”.
-labelPvCO2:JLabel Label på GUI med teksten ”PvCO2 [kPa]:”.
-labelpHv:JLabel Label på GUI med teksten”pHv:”.
165
¬
Attributter
i GUI-klasser
•
-labelRespiratorindstilling:JLabel Label på GUI med teksten ”Respiratorindstilling”.
-labelFiO2:JLabel Label på GUI med teksten ”FiO2 [%]:”.
-labelVtidal:JLabel Label på GUI med teksten ”Vt [l]:”.
-labelFrekvens:JLabel Label på GUI med teksten ”Frekvens [pr. min]:”.
-labelPEEP:JLabel Label på GUI med teksten ”PEEP [cmH2 O]:”.
-labelI:E:JLabel Label på GUI med teksten ”I:E []:”.
-labelVaelgPatientgruppe:JLabel Label på GUI med teksten ”Vælg patientgruppe:”.
-labelVaelgPatientCase:JLabel Label på GUI med teksten ”Vælg patientcase:”.
-tFieldBruger:JTextField Tekstfelt til visning af brugerens navn.
-tFieldShunt:JTextField Tekstfelt til visning af værdi for shunt.
-tFieldFA2:JTextField Tekstfelt til visning af værdi for FA2.
-tFieldVdead:JTextField Tekstfelt til visning af værdi for Vd.
-tFieldCardiac:JTextField Tekstfelt til visning af værdi for Q.
-tFieldCompliance:JTextField Tekstfelt til visning af værdi for compliance.
-tFieldResistance:JTextField Tekstfelt til visning af værdi for Resistance.
-tFieldVO2:JTextField Tekstfelt til visning af værdi for VO2.
-tFieldVCO2:JTextField Tekstfelt til visning af værdi for VCO2.
-tFieldDPG:JTextField Tekstfelt til visning af værdi for DPG.
-tFieldHb:JTextField Tekstfelt til visning af værdi for Hb.
-tFieldCOHb:JTextField Tekstfelt til visning af værdi for COHb.
-tFieldMetHb:JTextField Tekstfelt til visning af værdi for MetHb.
-tFieldTemp:JTextField Tekstfelt til visning afværdi for temperatur.
-tFieldBE:JTextField Tekstfelt til visning afværdi for BaseExcess.
-tFieldNuvFeCO2:JTextField Tekstfelt til visning af nuværende værdi for FeCO2.
-tFieldSimFeCO2:JTextField Tekstfelt til visning af simuleret værdi for FeCO2.
-tFieldNuvFeO2:JTextField Tekstfelt til visning af nuværende værdi for FeO2.
-tFieldSimFeO2:JTextField Tekstfelt til visning af simuleret værdi for FeO2.
-tFieldNuvPIP:JTextField Tekstfelt til visning af nuværende værdi for PIP.
-tFieldSimPIP:JTextField Tekstfelt til visning af simuleret værdi for PIP.
-tFieldNuvSaO2:JTextField Tekstfelt til visning af nuværende værdi for SaO2.
-tFieldSimSaO2:JTextField Tekstfelt til visning af simuleret værdi for SaO2.
-tFieldNuvPaO2:JTextField Tekstfelt til visning af nuværende værdi for PaO2.
-tFieldSimPaO2:JTextField Tekstfelt til visning af simuleret værdi for PaO2.
-tFieldNuvPaCO2:JTextField Tekstfelt til visning af nuværende værdi for PaCO2.
-tFieldSimPaCO2:JTextField Tekstfelt til visning af simuleret værdi for PaCO2.
-tFieldNuvpHa:JTextField Tekstfelt til visning af nuværende værdi for pHa.
-tFieldSimpHa:JTextField Tekstfelt til visning af simuleret værdi for pHa.
166
¬
Attributter i GUI-klasser
-tFieldNuvSvO2:JTextField Tekstfelt til visning af nuværende værdi for SvO2.
-tFieldSimSvO2:JTextField Tekstfelt til visning af simuleret værdi for SvO2.
-tFieldNuvPvO2:JTextField Tekstfelt til visning af nuværende værdi for PvO2.
-tFieldSimPvO2:JTextField Tekstfelt til visning af simuleret værdi for PvO2.
-tFieldNuvPvCO2:JTextField Tekstfelt til visning af nuværende værdi for PvCO2.
-tFieldSimPvCO2:JTextField Tekstfelt til visning af simuleret værdi for PvCO2.
-tFieldNuvpHv:JTextField Tekstfelt til visning af nuværende værdi for pHv.
-tFieldSimpHv:JTextField Tekstfelt til visning af simuleret værdi for pHv.
-tFieldNuvFiO2:JTextField Tekstfelt til visning af nuværende værdi for FiO2.
-tFieldSimFiO2:JTextField Tekstfelt til indtastning af værdi for FiO2.
-tFieldNuvVtidal:JTextField Tekstfelt til visning af nuværende værdi for Vt.
-tFieldSimVtidal:JTextField Tekstfelt til indtastning af værdi for Vt.
-tFieldNuvFrekvens:JTextField Tekstfelt til visning af nuværende værdi for frekvens.
-tFieldSimFrekvens:JTextField Tekstfelt til indtastning af værdi for frekvens.
-tFieldNuvPEEP:JTextField Tekstfelt til visning af nuværende værdi for PEEP.
-tFieldSimPEEP:JTextField Tekstfelt til visning af værdi for PEEP, der er konstant.
-tFieldNuvIE:JTextField Tekstfelt til visning af nuværende værdi for I:E.
-tFieldSimIE:JTextField Tekstfelt til visning af værdi for I:E, der er konstant.
-klinikerVindue:KlinikerVindue En reference til KlinikerVindue. Denne reference bruges af den indre klasse
HaendelseKontrol.
D.3
UdviklerVindue
­®¯ ° ± ²ƒ³ ´
³ ´¶ƒ·¸
µ
³ ´³ » ¸¼
¹5º ³ ´¶ƒ·¸
¶¾³ » ¸¼
½ ³ ´¶ƒ·º ¸
µ
µ
¸
¿ƒ³ À ´Á ¶ƒ·º  ¸
µ
-vindueTitel:String Titlen på vinduet, som vises i vinduets titellinje.
-knapAabnGemtLambda:JButton Knap med label ”Åbn gemt lambda”.
-knapBeregnLambda:JButton Knap med label ”Beregn lambda”.
-knapGemLambda:JButton Knap med label ”Gem lambda”.
-knapHjaelp:JButton Knap med label ”Hjælp”.
-knapAfslut:JButton Knap med label ”Afslut”.
-knapFio2Graf:JButton Knap med label ”Fio2 Errorgraf”.
-knapFreqGraf:JButton Knap med label ”Frekvens Errorgraf”.
-knapVtGraf:JButton Knap med label ”Vt Errorgraf”.
-boksPatientgruppe:JComboBox Kombinationsboks til valg af patientgruppe.
167
¬
Attributter
i GUI-klasser
•
-boksKliniker:JComboBox Kombinationsboks til valg af kliniker.
-ckeckBoksKliniker:JComboBox Kombinationsboks til valg af om lambda skal regnees for en kliniker.
-labelVaelgPatientgruppe:JLabel Label på GUI med teksten ”Vælg patientgruppe”.
-labelValgKliniker:JLabel Label på GUI med teksten ”Vælg kliniker”.
-labelLambda:JLabel Label på GUI med teksten ”Lambda værdier:”.
-labelBarotraume:JLabel Label på GUI med teksten ”Barotraume”.
-labelOxygenering:JLabel Label på GUI med teksten ”Oxygenering”.
-labelAcidoseAlkalose:JLabel Label på GUI med teksten ”Acidose/Alkalose”.
-labelIlttoxitet:JLabel Label på GUI med teksten ”Ilttoxitet”.
-labelFornavn:JLabel Label på GUI med teksten ”Fornavn”
-labelEfternavn:JLabel Label på GUI med teksten ”Efternavn”
-labelStillingsbetegnelse:JLabel Label på GUI med teksten ”Stillingsbetegnelse”
-labelAnciennitet:JLabel Label på GUI med teksten ”Anciennitet”
-labelAfdeling:JLabel Label på GUI med teksten ”Afdeling”
-labelProcess:JLabel Label på GUI med teksten ”% af udregning udført:”
-fieldBarotraume:JTextField Tekstfelt til værdien af lambda for barotraume.
-fieldOxygenering:JTextField Tekstfelt til værdien af lambda for oxygenering.
-fieldAcidoseAlkalose:JTextField Tekstfelt til værdien af lambda for acidose/alkalose.
-fieldIlttoxitet:JTextField Tekstfelt til værdien af lambda for ilttoxitet.
-fieldFornavn:JTextField Tekstfelt til klinikerens fornavn.
-fieldEfternavn:JTextField Tekstfelt til klinikerens efternavn.
-fieldStillingsbetegnelse:JTextField Tekstfelt til klinikerens stillingsbetegnelse.
-fieldAnciennitet:JTextField Tekstfelt til klinikerens anciennitet.
-fieldAfdeling:JTextField Tekstfelt til klinikerens afdeling.
-fieldProcess:JTextField Tekstfelt til at vise hvor stor del af beregningen er udført.
-saveLambda:JFileChooser En filbrowser som bruges når lambdaværdier gemmes.
-getLambda:JFileChooser En filbrowser som bruges når tidligere gemte lambdaværdier åbnes.
-udviklerVindue:UdviklerVindue En reference til UdvilkerVindue. Denne reference bruges af den indre
klasse HaendelseKontrol.
D.4
HjaelpVindue
ÃÄÅ Æ Ç ÈƒÉ Ê
É ÊÌƒÍÎ
Ë
É ÊÉ Ñ ÎÒ
ÏÐ É ÊÌƒÍÎ
ÌÔ É Ñ ÎÒ
Ó É ÊÌÍÐ Î
Ë
Ë
Î
ÕÉ Ö Ê× ÌƒÍÐ Ø Î
Ë
-vindueTitel:String Titlen på vinduet, som vises i vinduets titellinje.
168
¬
Attributter i GUI-klasser
-knapLuk:JButton Knap med label ”Luk”.
-tAreaInfo:JTextArea Tekstområde til indholdet af vejledningen af brugerne.
-hjaelpVindue:HjaelpVindue En reference til HjaelpVindue. Denne reference bruges af den indre klasse HaendelseKontrol.
169
APPENDIKS
E
Bilag 1: Interview med Per Thorgaard
Det primære formål med interviewet er at få viden om, hvordan respiratorer indstilles. Det sekundære formål
er at få kommentarer til klinikerens brugergrænseflade i Dr. Know samt best/worst penalties. I referatet er kun
de vigtigste emner medtaget fra interviewet.
Tilstede: Overlæge og anæstesiolog Dr. Med. Per Thorgaard, Line Michelsen, Brynjar Vatnsdal Palsson og
Mogens Nielsen.
Referat
Hvem er ansvarlig for indstillingen af en respirator?
Lægen er ansvarlig for indstillingen af respiratorer og ingen andre. Hvis der er tale om småjusteringer af respiratorens indstillinger, kan det være en narkosesygeplejerske, men aldrig uden anæstesiologens tilladelse. Det
er kun er ordination fra lægen, som giver tilladelsen, og det er altid lægens ansvar.
Hvilke parametre bruger lægen i indstillingen af en respirator?
Per Thorgaard fik her udleveret billedet af et mockup af klinikerens brugergrænseflade i Dr. Know.
De arterielle blodværdier er tilgængelige i form af et stykke papir udskrevet af blodgasanalysatoren. Metabolismen er langtfra altid tilgængelig. Det er sjældent, at man har et indblik i patientens metaboliske tilstand.
Lungedynamikken visualiseres på skærmen. Lægen bruger det til en vis grad, men dog ikke altid. Værdier for
cardiac output (cirkulation) er ligeledes sjældent tilgængelige, men man har som regel et estimat ud fra nogle
parametre, som for eksempel hudfarve, kapillærrespons, urinladninger mm. I dag visuliseres ingen gasudvekslingsparametre (shunt, FA2 og Vd). Det eneste, som er tilgængeligt, er patientens oxygeneringsevne, som ikke
kan splittes op i de tre nævnte gasudvekslingsparametre.
Hvilke variable bruger lægen i indstillingen af en respirator?
FeCO2 er tilgængeligt, men ikke FeO2 . Alle intensivpatienter er udstyret med et arterielt kateter, hvilket bevirker, at lægen altid har de arterielle blodværdier tilgængelige. Disse værdier er ikke onlineværdier, det er
pointværdier. Der bliver udført en del af disse målinger, som printes ud på en papirstrimmel. Venøst blod bru-
171
¬
Bilag 1: Interview med Per Thorgaard
ges endnu ikke, men det gør de den dag, de får ARTY1
Hvordan er responstiden for de forskellige parametre?
Equilibreringstiden for O2 er ca. 3-5 min, hvor den for CO2 er mellem 20 og 30 min. Alt er forudsat konstant
ventilation, dvs. at man antager, at patienten ikke ændrer ventilationsmønster undervejs. Meget respirationsbehandling i dag bygger på konceptet om assistventilation, hvilket vil sige, at udstyret kun hjælper patienten med
at trække vejret. Et eksempel: En patient har en ikke-tilstrækkelig inspiration, så respiratoren giver et ekstra
volumen ilt under inspiration, dvs. en assist til egen ventilation. Det kræver, at blæsebælgen har en kort responstid, da luften ellers kommer for sent, og det kan vække ubehag hos patienten. Assistventilationen er den mest
udbredte ventilationsmetode.
Hvor ofte indstilles en respirator?
Per Thorgaard regner med, at det er under to gange pr. døgn. Der er kommet en autopilot på respiratorerne i dag
(automode). Specielt på assistventilation; her indstiller man den så på, at den skal levere et vist volumen pr. min.
Hvis patienten så trækker mere end det fastsatte volumen, da giver respiratoren intet luft. Autopiloten betyder, at
lægerne ikke behøver at tilse og monitorere patienten hele tiden. Autopiloten indstilles for 24 timer ad gangen,
ud fra den statiske tilstand patienten har under indtstillingen. Hvis patientens tilstand ændres efterfølgende, kan
automode korrigere for patientens behov.
Pause i interviewet, hvor Per Thorgaard fremviste en ventilator Siemens 390. De tilstedeværende fik en hurtig
gennemgang af indstillingsmuligheder og funktioner i respiratoren.
Input til brugergrænsefladerne
Per Thorgaard havde ikke mange input til vores brugergrænseflader, men tilkendegav, at han også mente, at det
ville være givtigt, hvis lægen ser konsekvensen af sine handlinger.
Best/worst-penalties
Per Thorgaard fik udleveret et penaltyskema, som han ville udfylde. Han kunne ikke give nogle værdier på
stående fod. Han mente, at vore antagelser om, at penaltyfunktionerne kan repræsenteres som lineære eller
eksponentialfunktioner, ikke var helt urealistiske.
1 En
arterialiseringsalgoritme som er under udvikling af Marianne Toftegaard.
172
APPENDIKS
F
Bilag 2: Interview med Steen Andreassen
Steen Andreassen er medudvikler af INVENT. Formålet med interviewet med Steen Andreassen er at få dokumenteret, hvilke behov der er til Dr. Know, samt få dokumenteret afgrænsningerne til systemet. I referatet er
kun de vigtigste emner medtaget fra interviewet.
Tilstede: Dr. Tech. Steen Andreassen, Signe Stougård Pedersen, Mads Hylleberg og Brynjar Vatnsdal Palsson
Referat
Hvorfor er det nødvendigt at kunne tilpasse INVENT til de 3 valgte forskellige patientgrupper?
Hovedargumentet for at skulle vægte penalties forskelligt til de forskellige patientgrupper er, at penalties gør
forskellig ”ondt” på forskellige patientgrupper. Patientgrupperne har underliggende forskellige organproblemer,
og det er derfor forskellige organer, man ønsker at skåne hos patientgrupperne. F.eks. vil den unge motorcyklist
med hjernetraume typisk have et velfungerende hjerte, og hjertet kan derfor godt tåle at blive belastet gennem
længere tid og vil ved for dårlig oxygenering kunne respondere for det ved at arbejde hårdere. I en anden
situation med en ældre patient med svækket hjerte vil det derimod være oxygeneringen, der vil blive vægtet
højere.
Steen Andreassen kom med en overvejelse om, om det er de rigtige penalty-funktioner, vi har med (=de har
med), idet der ikke er nogen penalty-funktion, der beskriver arteriel oxygenering. Der er nu en penalty for
venøs oxygenering, hvilket nok er en rigtig tilnærmelse, idet den beskriver, hvilken tilstand blodet efterlader i
det perifere væv, men det er differensen mellem den arterielle og venøse oxygenering, der beskriver hvor meget
ilt blodet afgiver i cirkulationen.
Hvorfor kan Dr. Know afgrænses til at kun inkludere tre af de fem respiratorindstillinger, dvs freq, VT og FiO2 ?
I INVENT anvendes respiratorindstillingerne PEEP og I:E ikke pga. manglende modeller. Det er ikke en realistisk simulering at udelade PEEP og I:E, idet PEEP stort set altid anvendes. Det er et ”sort hul” i INVENT,
men ved at fastholde PEEP kan de andre indstillinger/værdier dog observeres.
PEEP forbedrer gasudvekslingen i lungerne og reducerer sandsynligvis også risikoen for atelektase, hvilket de
ikke har nogen model for. Shunt- og V/Q-mismatch-parametrene fra ALPE er funktioner af PEEP, og det har
173
¬
Bilag 2: Interview med Steen Andreassen
de aldrig fået modelleret ind i INVENT.
I:E indstilles af hensyn til patienter med obstruktive lungesygdomme. Disse patienter har svært ved at komme
af med luften og kræver derfor længere ekspirationstid. Hvis ekspirationstiden ikke er lang nok, dvs. de kommer ikke af med luften før nyt luft kommer ind, resulterer det i autoPEEP, hvor patienten pustes mere og mere
op. Dét justeres ved I:E-forholdet, men der mangler mekaniske modeller hertil.
Bruges atelektase i udregningen af totalpenalty i INVENT?
Der er noget integreret i INVENT, som kører på tidalvolumen, men det er bygget på en gammel forståelse af
lungedynamikken, hvilken er væsentlig ringere end forståelsen nu. Det kan være en årsag til ikke at inkludere
atelektase i Dr. Know.
Vil det være væsentligt for en udvikler af INVENT at kunne få information om, hvilke klinikere der har anvendt
Dr. Know?
Steen Andreassen synes, det kunne være interessant at få information om klinikeren, men mener ikke, det er
dér kræfterne skal bruges. Det er en bedre idé at hjælpe klinikeren med at forstå og analysere patientcases ud
fra et klinisk synspunkt, og statistikken er ikke nødvendigvis så interessant.
Vil en udvikler af INVENT foretrække et format til at gemme vægtningerne i?
Umiddelbart er formatet ligegyldigt. Det skal selvfølgelig være let tilgængeligt at vide, hvilken patientgruppe
der er udregnet lambdaer for. Hvis det skal kunne implementeres direkte i INVENT, skal der være mulighed
for at kunne tilgå det og evt. redigere i de beregnede lambda. Der vil helt klart være situationer, hvor det
kan være nødvendigt at ændre vægtningerne, og også tillade en form for kommunikation med klinikeren på
lambda-niveau.
Vil en udvikler af INVENT være interesseret i at få errorgrafer visualiseret i Dr. Know?
Det kan være interessant at se, hvor tæt overensstemmelse der er mellem systemets forslag og klinikerens
forslag til respiratorindstillingerne. Herved vil det blive illusteret, hvorvidt de producerede vægtninger er anvendelige eller ej.
174