Rapport - NTNU

Eksperter i Team, Landsby 20: Alltid på nett !!?? 

Doctector 

Forstyrrelser i mobilt arbeid 

Ole Petter Bang, Jørgen Wahl Blakstad, Marthe Fjellheim, Thomas Myren, 

Bjarne Sletten Olsen, Kenneth Stensen, Oddvar Åsmul, Helle Gunelie Økstad 

07.05.2008

Fagrapport – Forstyrrelser i mobilt arbeid 

Sammendrag 

Denne oppgaven dreier seg om den hektiske hverdagen på et sykehus, og kommunikasjonen 

mellom leger og sykepleiere. Vi har forsøkt å se hvordan kjennskap til legenes lokasjon og 

deres tilgjengelighet påvirker sykepleiernes arbeidshverdag, med en hypotese om at det vil 

kunne forbedre og forenkle kommunikasjonen. Med utgangspunkt i dette har vi utviklet 

Doctector, som er en applikasjon som kan gi kjennskap til legenes og sykepleiernes lokasjon 

og tilgjengelighet. Vi har testet denne applikasjonen gjennom et relevant scenario for å uttale 

oss om denne vil kunne påvirke sykepleieres arbeidshverdag, og eventuelt på hvilken måte. 

Doctector kan, ved å vise lokasjonen og tilgjengelighet for legene, gjøre arbeidsformen 

mindre avbrytende. Dette fordi sykepleierne ikke trenger å kalle på legen, men kan ta direkte 

kontakt med ham eller se tilgjengelighet direkte. Dette fører med seg at legen får informasjon 

om hvem som kontakter ham. Han vil, dersom han svarer, kunne få vite graden av viktighet 

av kontakten, og sykepleier unngår å prøve å kontakte leger som ikke er tilgjengelige. 

- 2 -


Innhold 

1. Innledning ............................................................................................................................. 5 

2. Teori ....................................................................................................................................... 6 

2.1 Kommunikasjon og kontekst i et anvendt språkvitenskapssyn ........................................ 6 

2.1.1 Samhandling, forhandling og mening ........................................................................ 6 

2.1.2 Kontekst ..................................................................................................................... 7 

2.1.3 Asymmetri ................................................................................................................ 10 

2.2 Mobilitet ......................................................................................................................... 11 

3. Tidligere forskning og eksisterende systemer .................................................................. 13 

3.1 Hverdagen på et sykehus; relasjoner og roller ................................................................ 13 

3.2 Mobilitetsaspektet i sammenheng med sykehuskonteksten ........................................... 14 

3.3 Kontekst sett i sammenheng med sykehus ..................................................................... 16 

3.4 Eksisterende systemer ..................................................................................................... 18 

3.4.1 AwarePhone ............................................................................................................. 18 

3.4.2 Visma ....................................................................................................................... 19 

3.4.3 Knudsens prototyp ................................................................................................... 19 

4. Våre tekniske løsninger ..................................................................................................... 21 

4.1 Doctector ........................................................................................................................ 21 

4.1.1 Brukergrensesnitt ..................................................................................................... 21 

4.1.2 Administrasjonsgrensesnitt ...................................................................................... 24 

4.1.3 Arkitektur ................................................................................................................. 27 

4.2 Begrunnelse av valg ....................................................................................................... 27 

4.2.1 Lokasjonsteknologi .................................................................................................. 27 

4.2.2 Arena ........................................................................................................................ 27 

4.2.3 Arkitektur ................................................................................................................. 28 

4.3.4 Enheter ..................................................................................................................... 28 

4.3.5 Sentral tjener ............................................................................................................ 29 

4.4 Funksjonalitet ................................................................................................................. 30 

4.5 Erfaringer ........................................................................................................................ 30 

4.5.1 GeoPos ..................................................................................................................... 30 

4.6 Alternative tekniske løsninger ........................................................................................ 31 

4.6.1 Ultralyd .................................................................................................................... 31 

4.6.2 RFID ........................................................................................................................ 31 

4.6.3 Cordis RadioEye ..................................................................................................... 31 

4.7 Problemer med utstyret ................................................................................................... 32 

- 3 -


5. Metoder og scenarier ......................................................................................................... 33 

5.1 Feltobservasjon ............................................................................................................... 33 

5.2 Scenarier ......................................................................................................................... 33 

5.3 Reliabilitet, validitet, og generalisering .......................................................................... 34 

5.4 Prototyp .......................................................................................................................... 34 

5.5 Beskrivelse av utvalgte scenarier ................................................................................... 35 

5.5.1 Sampling, utvalg, og setting ..................................................................................... 36 

5.5.2 Prosedyre .................................................................................................................. 37 

6. Diskusjon ............................................................................................................................. 38 

6.1 Diskusjon rundt reliabilitet, validitet og generaliserbarhet ............................................ 38 

6.2 Doctectors mulige påvirkning på kommunikasjon og relasjoner på et sykehus ............. 39 

6.2.1 Leger og sykepleieres hverdag og kommunikasjon med og uten Doctector ........... 39 

6.2.2 Leger og sykepleieres relasjon med og uten Doctector ........................................... 40 

6.3 Videreutvikling av Doctector ......................................................................................... 42 

6.3.1 Meldingsmaler ......................................................................................................... 42 

6.3.2 Universelt design ..................................................................................................... 42 

6.3.3 Roller og sengeposter ............................................................................................... 42 

6.3.4 Sikkerhet .................................................................................................................. 42 

6.3.5 Automatisk terminal-gjenkjenning .......................................................................... 43 

6.3.6 Nødalarm .................................................................................................................. 43 

6.3.7 Pasientdata ............................................................................................................... 43 

6.3.8 Manuell overstyring av lokasjon .............................................................................. 43 

6.3.9 Opptatt-problematikk ............................................................................................... 44 

6.3.10 Kombinere forskjellige nettverkstyper .................................................................. 44 

6.3.11 Kalender ................................................................................................................. 44 

6.3.12 PC-utgave ............................................................................................................... 44 

6.3.13 IP-telefoni .............................................................................................................. 45 

7. Litteraturliste ...................................................................................................................... 46 

Appendiks A ............................................................................................................................ 48 

Språkhandlingsteori .............................................................................................................. 48 

Appendiks B ............................................................................................................................ 50 

Arkitektur .............................................................................................................................. 50 

- 4 -


1. Innledning 

Hverdagen på et sykehus er hektisk, og det kan ofte være kritisk å få tak i rett person til rett 

tid. I dag brukes systemet ”kalling” på nesten alle sykehus. Man kaller på en personsøker, og 

mottakeren må ringe tilbake til nummeret som dukker opp. Et slikt system tilbyr ingen form 

for info om hvem som ønsker kontakt, eller om graden av viktighet av kontakten. Den som 

ønsker kontakt får heller ingen info om hvorvidt personen det ønskes kontakt med er opptatt. 

Mange mener dette systemet gir en avbrytende arbeidsform, og skaper unødige forstyrrelser 

(Dahl, 2007). Så godt som all forskning på dette temaet tidligere har gått på hvordan leger 

opplever det å bli forstyrret i sitt arbeide (f.eks Bardram & Bossen, 2005, Eistenstadt et al., 

1998), og ikke satt søkelyset på hvordan sykepleierne opplever det å stadig skulle kalle på 

klinikerne, og ikke vite hvem eller når de dukker opp . I vår oppgave har vi derfor forsøkt å 

sette fokus på nettopp dette. Vi ønsker å finne ut om en teknisk innretning, som gir kjennskap 

til leger og sykepleieres lokasjon og tilgjengelighet, vil kunne bidra til en forbedret og 

forenklet kommunikasjon mellom leger og sykepleiere. Vår problemstilling blir dermed som 

følger: Hvordan kan kjennskap til legenes lokasjon og tilgjengelighet påvirke 

sykepleieres arbeidshverdag? 

For å kunne svare på denne problemstillingen har vi opparbeidet oss noe kunnskap om 

hvordan dagens system på et sykehus fungerer, på hvilken måte kommunikasjonen i hovedsak 

foregår mellom leger og sykepleiere og hvilke eksisterende tekniske system som finnes. Med 

utgangspunkt i dette har vi utviklet Doctector, som er en applikasjon som kan gi kjennskap til 

legenes og sykepleiernes lokasjon og tilgjengelighet. Vi har testet denne applikasjonen 

gjennom et scenario for å uttale oss om denne vil kunne påvirke sykepleieres arbeidshverdag, 

og eventuelt på hvilken måte. 

- 5 -


2. Teori 

2.1 Kommunikasjon og kontekst i et anvendt språkvitenskapssyn 

Dette kapittelet tar for seg generelle termer innenfor kommunikasjon, som samhandling, 

forhandling og mening. Dette er sentrale begrep innen enhver samhandlingssituasjon, 

kontekst, og de tre nivåer av kontekst; tekstuell kontekst, situasjonskontekst og kulturell 

kontekst. Kapittelet går også inn på kontekstuelle rammer, og ser til slutt nærmere på 

betydningen av asymmetri og dominans i en samhandlingssituasjon. 

2.1.1 Samhandling, forhandling og mening 

Samhandling, forhandling og mening er tre sentrale begrep innenfor kommunikasjon. 

Samhandling omhandler det at deltakerne tilpasser seg hverandre og koordinerer sine 

handlinger mot en felles oppgave. For at samhandling skal kunne finne sted må taleren rette 

seg mot adressaten slik at vedkommende oppfatter handlingen som en kommunikativ 

intensjon, noe som vil gi signal til adressaten om å lete etter mening i det som blir ytret 

(Svennevig 2001). Taleren er nødt til å ta hensyn til adressaten i form av hvilke språklige og 

ikke-språklige tegn han vil ta i bruk, samt er det viktig at han bruker et ordforråd som 

adressaten har forutsetninger for å forstå. Dette er både fordi man må ta hensyn til, og 

opparbeide en gjendisig bakgrunnskunnskap. Man tilpasser seg hverandre i prosessen med å 

etablere en felles forståelse av språkhandlingen (Svennevig 2001). 

Man forhandler kontinuerlig i en samhandlingssituasjon, og derfor kommer 

forhandlingsprosessen mest tydelig frem gjennom samtale (Svennevig 2001). Underveis i en 

samtale forhandler man om å bli enig om tolkningen av hverandres ytringer slik at samtalen 

kan gå fremover. Taleren trenger bekreftelse på at han blir forstått slik han har intendert det, 

og adressaten/lytteren trenger bekreftelse på at hans tolkninger av det som blir sagt er riktige. 

Tilbakemeldingssignaler er en viktig del av forhandlingsprosessen fordi vi ved hjelp av disse 

signaliserer at vi følger med, at vi er oppmerksomme på det som blir sagt og at vi tolker det 

som blir sagt (Svennevig 2001). Dette gjør oss i stand til å reparere samtalen underveis, i form 

av at både taler og lytter kan reparere sine ytringer, sine intensjoner og sine tolkninger. 

”(…) mening blir til i samspill mellom kommunikasjonsdeltakerne” (Svennevig 2001:75). 

- 6 -


Gjennom samhandling hvor man har en kontinuerlig forhandlingsprosess om å forstå 

hverandres ytringer forhandler man om en felles mening. Språket får mening gjennom en 

situasjon i en kontekst. Dersom en samtale stopper opp, er det gjerne fordi noe skjer i 

prosessen med å skape en felles mening og man må reparere skaden for å komme videre i 

samtalen (Svennevig 2001). 

2.1.2 Kontekst 

Kontekst er den sammenhengen eller de ”omgivelser” en ytring inngår i (Svennevig 2001). 

Kontekst og ytring forutsetter hverandre, det vil si at kontekst eksisterer kun i relasjon til en 

ytring og en ytring trenger en kontekst for å få mening. Det er ikke dermed sagt at kontekst 

omfatter alt som omgir en ytring, men kontekst omfatter det som er relevant bakgrunn for å 

produsere eller forstå en ytring, samt hva deltakerne i interaksjonen velger som bakgrunn for 

ytringen (Svennevig 2001). Vagle, Sandvik og Svennevig (2004) skriver at kontekst er alt 

man trenger ut over ordbok- og grammatikkunnskap for å forstå en ytring (Vagle et al. 2004). 

Dette kan innebære kunnskap om den konkrete samhandlingssituasjonen, tidligere 

samhandlingssituasjoner, den fysiske situasjonen en ytring er en del av og/eller den generelle 

bakgrunnskunnskapen som deltakerne har. Slik bakgrunnskunnskap er i form av blant annet 

holdninger og oppfatninger så vel som faktisk vitenskaplig kunnskap (Vagle, Sandvik og 

Svennevig 2001). Kontekst skapes i fellesskap av de deltakerne som inngår i samhandling, og 

den må skapes av den informasjonen som er tilgjengelig for deltakerne enten psykisk eller 

fysisk. Man kan se dette i sammenheng med aktørene på et sykehus, la oss ta et eksempel. 

Legen sier til sykepleieren at på denne pasienten skal dosen av X økes med Y mg hver fjerde 

time. Sykepleieren vil forstå denne ytringen riktig, fordi den settes inn i kontekst. 

Sykepleieren er på et sykehus, i et pasientrom, kanskje sammen med den faktiske pasienten. 

Disse fysiske omgivelsene gir sykepleieren retningslinjer på hvordan informasjonen skal 

tolkes. Sykepleieren har tidligere erfaringer med samme type kommunikasjonssituasjon med 

leger, og setter seg selv og legen inn i deres respektive institusjonelle roller, samt at 

sykepleieren forstår samhandlingssituasjonen som en samtale mellom lege og sykepleier om 

hva som skal gjøres for denne pasienten. 

Kontekst deles gjerne i tre nivåer, tekstuell kontekst, situasjonskontekst og kulturkontekst. 

Den tekstuelle konteksten omhandler de ytringene som har gått forut for 

samhandlingssituasjonen. Nye ytringer ses i lys av forutgående ytringer og tolkes på bakgrunn 

- 7 -


av disse (Svennevig 2001), og slik skapes kontekst i form av at foregående ytringer er en kilde 

til kontekst ved at den skaper klare begrensninger for hva som kan sies når (Svennevig 2001). 

Men det er ikke bare foregående ytringer som skaper kontekst for nye, også nye ytringer kan 

skape bakgrunn for forståelse av de foregående ytringene. 

”Dermed er vi inne i en sirkel, der foregående ytringer skaper kontekst for å forstå nye 

ytringer, samtidig som nye ytringer skaper kontekst for forståelsen av de foregående” 

(Svennevig 2001:85). Dette kan eksemplifiseres ved at en lege og sykepleier har gjentatte 

samtaler om en pasient i løpet av behandlingstiden. Disse samtalene vil ligge som 

bakgrunnskunnskap hos begge samtaledeltakerne, både legen og sykepleieren, i nye samtaler. 

Det som er blitt sagt tidligere skaper en felles forståelse for samtalen som finner sted. 

Situasjonskontekst defineres av Svennevig (2001) som et sett med deltakere som er engasjert i 

en kommunikativ oppgave i visse fysiske omgivelser gjennom et visst medium. Ting som 

påvirker oss i samhandlingssituasjonen ut fra situasjonskonteksten er aspekter som alder, 

kjønn, personlighet, gruppetilhørighet og lignende, samt vår relasjon til deltakerne i 

samhandlingen og hvilke forpliktelser og rettigheter vi har ovenfor hverandre. Med andre ord 

hvilke forhold vi har til de andre deltakerne. Dersom man tar et eksempel fra 

sykehusdiskursen, kan det være det forholdet en lege har til en sykepleier. Dette forholdet 

legger til rette for at legen kan gi sykepleieren informasjon om hva man skal gjøre i forhold til 

behandlingen av en pasient, og sykepleieren kan være den som tar seg av dette. 

Kulturkonteksten defineres gjerne som de begrensninger og muligheter som deltakerne i 

samhandlingssituasjonen har som deltakere i ulike kulturelle fellesskap (Svennevig 2001). 

Dette nivået handler hva som gjør en hendelse til en type hendelse som man ut fra allmenne, 

kulturelle mønstre kan gjenkjenne som en aktivitetstype. Her er de rollene deltakerne har 

viktige for å kunne forstå samtalen riktig. Svennevig (2001) skriver at for at en situasjon skal 

bli gjenkjent som en aktivitetstype, må aktiviteten iscenesettes av deltakerne. Dette gjør de 

ved å gå inn i de standardiserte rollene som er forbundet med aktivitetstypen. Selv om man 

kan se likhetstrekk og mønstre som gjør at man gjenkjenner en aktivitetstype, er det likevel 

slik at hver aktivitetstype blir utført forskjellig, og samtidig er hver person som inngår i 

rollene forskjellige. I denne sammenhengen vil en samtale bli forståelig på bakgrunn at 

deltakerne i samhandlingen har felles ressurser som de har tilgang til gjennom å være del av 

flere kulturelle fellesskap (Svennevig 2001). Det at man jobber på et sykehus legger noen 

- 8 -


begrensinger på kommunikasjonssituasjonene. Man har ulike roller man inngår i, som 

kulturelt og institusjonelt sier noe om arbeidsoppgaver og metoder. I tillegg må man benytte 

seg av disse rollene for å kunne skape de institusjonelle samtalene på sykehuset. 

Som nevnt tidligere er det bare det deltakerne gjør relevant i samhandlingen som kan sies å 

utgjøre konteksten. Vagle et al. (2004) trekker inn begrepet kontekstuelle rammer for å vise 

hvordan dette er i praksis. 

Bakgrunnskunnskap 

(Institusjonell ramme) 

Kulturell/Sosialramme 

Samhandlingssituasjon 

Fysisk ramme 

Fokusert 

hendelse 

Figur 1: Kontekstuelle rammer 

Figur 1 viser hvilke kontekstuelle rammer man tar utgangspunkt i for å forstå en hendelse 

eller en samtale. Det vil alltid ligge en fysisk ramme rundt den fokuserte hendelsen, for 

eksempel på et sykehus vil sykehuset eller det enkelte rommet man oppholder seg i være den 

fysiske rammen. Samhandlingssituasjonen er den faktiske situasjonen hvor to eller flere 

deltakere samhandler, som for eksempel samtalen mellom en lege og en sykepleier. Den 

- 9 -


kulturelle eller sosiale rammen, er gjerne den kulturen man tilhører. For eksempel ved å jobbe 

på et sykehus, blir man del av sykehuskulturen. Den institusjonelle rammen gjøres kun 

gjeldende i institusjonelle situasjoner, som for eksempel en leges samtale med en pasient på et 

sykehus. Bakgrunnskunnskap er en kontekstuell ramme i form av at den viser til alt det 

deltakerne gjør gjeldende i situasjonen, i form av abstrakt bakgrunnskunnskap som tidligere 

samtaler med samme person, samtaler av lignende karakter, eller mer konkret 

bakgrunnskunnskap som vil aktualisere det fysiske rommet rundt samtalen (Vagle et al. 

2004). 

2.1.3 Asymmetri 

Asymmetri defineres av Linell og Luckmann (1991) som ulike uregelmessigheter innenfor en 

dialogisk prosess, oftest knyttet til ulike bakgrunner og betingelser for interaksjonen i form av 

ulik kunnskap og sosiale posisjoner. Disse uregelmessighetene kan være ulike rettigheter i 

forhold til å bestemme tema, utnytte kunnskap og å bestemme hvem som har tilgang til å 

kontrollere perspektivene på temaene. Dersom man ser på asymmetri globalt i interaksjonen 

ser man på de manifesterte mønstrene som skapes underveis, mens dersom man ser på den 

lokale asymmetrien er denne gjerne knyttet til enkeltytringer eller enkeltturer (Linell og 

Luckmann 1991). Asymmetri er naturlig til stede i hver interaksjon man inngår i fordi den ene 

parten alltid vil ha mer kunnskap enn den andre. Dette kan være så enkelt som at hvis den ene 

parten forteller en historie, vil den andre ikke ha kunnskap om hva som kommer til å skje i 

historien og asymmetri kommer dermed til uttrykk. Fordi asymmetri alltid vil være naturlig 

tilstede i enhver interaksjon må det ses på som nøytralt i forhold til suksess eller ikke-suksess 

i kommunikasjonen. Asymmetri kan lede til hindringer, problemer og dårlig kommunikasjon, 

men som Linell og Luckmann (1991) sier, det finnes ikke noe logisk forhold mellom 

asymmetri og problematiske samtaler. Det som er viktig å merke seg er at asymmetri kun er 

tilstede når det gjøres aktuelt i samhandlingssituasjonen. 

Dominans er et begrep som er knyttet opp mot asymmetri, og dette anses som mindre naturlig 

enn asymmetri i en interaksjonssituasjon. Dominans forekommer når den ene parten 

dominerer samtalen, for eksempel gjennom å være den som har ordet mest eller bestemmer 

temaene i samtalen. Dette er knyttet til de globale mønstrene som kommer til uttrykk, og har 

liten overføringsverdi til enkeltytringer og enkeltturer (Linell og Luckmann 1991). 

- 10 -


Som nevnt tidligere kommer asymmetri og/eller dominans til uttrykk gjennom samhandling 

mellom to eller flere personer. De mønstrene som kommer til uttrykk gjennom interaksjonen 

kan være påvirket av personlig egenskaper, og de kan være påvirket av de rollene som 

pålegges personene ut fra den institusjonen eller organisasjonen de er en del av. Likevel er det 

viktig å merke seg at den asymmetrien og symmetrien man finner i en samtale ikke kun er et 

uttrykk for enkeltindividenes motivasjoner for samtalen, men heller at de er bundet av sosiale 

strukturer og tradisjoner for muntlig tale (Linell og Luckmann 1991). 

2.2 Mobilitet 

Mobilitet kommer av det latinske ordet mobilitét som betyr det å være mobil, og beskriver 

evnen til å forflytte seg sosialt eller en bevegelsesevne (Wangsteen 2006). Mobilitet er 

essensielt for alle typer av delte ressurser og for kommunikasjon. 

Andresen (2007) definerer fem forskjellige typer mobilitet. Terminalmobilitet er at 

terminalen, for eksempel en mobiltelefon eller PDA (lommedatamaskin), opprettholder 

tjenesten selv om terminalen forandrer posisjon i nettet. Brukermobilitet handler mer om at 

brukeren får tak i sine tjenester, selv om brukeren bytter terminal. Den tredje typen mobilitet 

Andresen (2007) nevner er sesjonsmobilitet. Denne mobiliteten tillater brukeren å holde på 

sesjonen, det vil si påloggingsøkten mot tjenesten, selv om brukeren bytter terminal. 

Tjenestemobilitet tillater tjenester eller programmer å bli overført fra en maskin, eller 

terminal, til en annen. Den siste typen mobilitet som blir nevnt er personmobilitet. Andresen 

(2007:60) definerer personmobilitet slik: ”Personmobilitet tillater en person å benytte 

tjenester som er tilpasset egne preferanser, og brukere (abonnementer) uavhengig av fysisk 

plassering og spesielt utstyr”. 

I tillegg til disse fem forskjellige mobilitetstypene definerer Andresen (2007) rollemobilitet. 

Rollemobilitet er at brukeren kan skifte mellom roller der brukeren for eksempel får adgang 

til rettigheter og lignende. 

Andresen (2007) skiller også mellom kontinuerlig og diskret mobilitet. Innenfor telematikken 

skilles det i denne sammenhengen mellom ”soft” og ”hard” handover. Kontinuerlig mobilitet 

vil si at tjenesten holder seg avbruddfri selv når terminalen er under bevegelse. Diskret 

mobilitet tillater til en viss grad avbrudd, men tjenesten skal være tilgjengelig etter avbruddet. 

Et eksempel på kontinuerlig mobilitet er når man snakker i mobiltelefon. Selv om man 

- 11 -


beveger seg fra et sted, der man har kontakt med en mottaker, i vårt tilfelle en basestasjon, til 

et annet sted der man har kontakt med en annen mottaker, blir ikke samtalen avbrutt. Dersom 

man hadde blitt avbrutt en liten periode og deretter kommet inn i samtalen igjen hadde vi 

kunne kalt det tilfellet diskret mobilitet. Dette er noe man lett kan oppleve hvis man snakker i 

telefon over trådløst nettverk. 

- 12 -


3. Tidligere forskning og eksisterende systemer 

3.1 Hverdagen på et sykehus; relasjoner og roller 

En studie fra Danmark (Holm-Pettersen, Asmussen og Willemann, 2005), viser at sykepleiere 

inngår i relasjoner de har skapt med hverandre ved at de arbeider sammen på avdelinger. Selv 

om legene inngår i relasjoner med sykepleierne i løpet av arbeidsdagen, og dermed er en del 

av det fellesskapet som sykepleierne har skapt på en avdeling, er legene også en gruppe som 

er annerledes enn sykepleierne. Denne annerledesheten kommer til uttrykk både i forhold til 

nærhet til pasienten og i profesjonsfagidentiteten. 

Relasjonen mellom leger og sykepleiere er hierarkisert, noe som forutsetter at sykepleiere må 

være aktivt oppmerksomme på å komme til ordet med beretninger om sine observasjoner og 

sine perspektiver når legen er tilstede. Når sykepleiere ser seg selv i relasjon til legene ønsker 

de ofte å sette fokus på at de innehar andre kvaliteter enn legene, og at sykepleiere og leger på 

denne måten supplerer hverandre. Dette skaper en gjensidig avhengighet. Likevel er 

relasjonen også preget av respekt og avstand (Holm Pettersen et al. 2005). 

Legene omtales av sykepleierne som noen som tilhører en selvstendig gruppe fremfor å være 

en del av sengeavdelingen. De omtales gjerne ikke med navn, men som ”de, dem, legen, 

legene” og lignende. Holm-Pettersen et al. har gjennom forskningen funnet ut at 

avstandsskapende kategorier gjerne blir brukt av sykepleierne når de ønsker å markere en 

forskjell eller vise avstand til legene. Små bemerkninger, ansiktsuttrykk og måter å omtale 

legene på skaper en verbal distanse, og viser daglig og fortløpende hvordan sykepleierne er 

annerledes enn legene. Det hender også at sykepleierne har et ironisk toneleie og forvrengning 

av stemmen når de snakker til sine sykepleierkolleger om en leges beslutning. Dette er 

virkemidler som ikke forekommer når sykepleierne snakker om hverandre. Dette blir derfor 

en avstandsmarkør, legene står utenfor det nære arbeidsfellesskapet (Holm-Pettersen et al. 

2005). 

Sykepleiere og leger har svært forskjellige arbeidsoppgaver som bidrar til at de oppfatter seg 

forskjellig fra den andre gruppen. Likevel er de flettet inn i hverandres arbeidsoppgaver, hvor 

begge sider må bidra aktivt for å løse oppgaven (Holm-Pettersen et. al. 2005). I en 

arbeidssetting er det sykepleieren som først kommer i besittelse av den sentrale observasjonen 

- 13 -


som vedkommende må gjøre legen oppmerksom på, i tillegg til at sykepleieren også er den 

som sjekker og utfører legenes ordre. Legene ser på dette samarbeidet som et godt, gjensidig 

samarbeid hvor de har bruk for sykepleiernes observasjoner av pasienter i arbeidet med å 

utrede og behandle pasientene. Det er ikke nok å lese pasientjournalene, og legene er derfor 

avhengige av sykepleiernes observasjoner. De opplever at sykepleierne gjerne vil være aktive 

i behandlingen av pasienten, noe som kan føre til irritasjoner dersom legen ikke er 

oppmerksom på det sykepleieren har å komme med. Konflikter oppstår gjerne, i følge legene, 

i forhold til hvilke oppgaver som tilhører hvem. Spørsmål oppstår rundt hva som er legens 

oppgave, hva som er sykepleierens oppgave og hvem som kan ta hvilken beslutning. Selv om 

sykepleierne diskursivt bekjemper forestillingen om at de er legenes assistent, vil det likevel 

oppstå situasjoner hvor de føler seg slik. Sykepleierne ønsker ikke å overta oppgaver fra 

legene. Dette er fordi de oppgavene legene ikke selv vil ha oppfattes som kjedelige oppgaver, 

og derfor ikke kompetanseutviklende for sykepleierne (ibid.). 

Sykepleierne oppfatter seg selv som mer enn legenes assistenter og mer enn noen som bare 

utfører legens ordre. De ønsker å oppfattes som likestilte med legen. Sykepleierne har den 

holdningen at det viktigste ikke er hvem som er klokest, men at pasienten får den beste 

behandling. Blant legene er det forskjellige holdninger til hvilken rolle sykepleierne skal ha i 

forhold til å komme med input i behandling av pasienter. Noen leger diskuterer gjerne med 

sykepleierne i forhold til deres innspill, mens andre leger mener at sykepleierne ikke skal 

komme med innspill til behandlingen fordi dette er noe de ikke har kunnskap om (ibid.). 

3.2 Mobilitetsaspektet i sammenheng med sykehuskonteksten 

Yngve Dahl (2007) skriver at sengeposter er karakterisert av omfattende mobilitet, som vil si 

at sykehusarbeidere er mobile i forhold til å være tilgjengelige for pasienter og å skaffe seg 

felles kunnskap om pasientene. Bardram og Bossen (2005) ser i sin studie på hvordan 

samarbeid foregår i den romlige delen av arbeidet på sykehus. Mye av arbeidet og hendelsene 

på sykehuset skjer mobilt, pasienter blir trillet fra operasjonsstue til røntgen og videre til 

sengepost. Sykepleiere, leger og andre ansatte på sykehuset forflytter seg også hele tiden etter 

pasientene og til ulike pasienter. 

Det er flere årsaker til at det foregår mye mobilitet på sykehus. Bardram & Bossen (2005) 

kommer opp med fire ulike aspekter av mobilt arbeid på sykehus og hvorfor mobilt arbeid 

oppstår på sykehusene. 

- 14 -


For det første er sykehus spesialtilpassede steder med unik kompetanse, kunnskap og 

personell, noe som gjør sykehuset til et sted der det er en stor grad av mobilitet. Det er også 

steder med kunnskap og erfaring, et sykehus innehar et høyt kunnskapsnivå med mange 

spesialister. For å få tilgang til kunnskap og erfaring trengs det kontakt med spesialister. Her 

kan det videre skilles på kunnskap som kan spres (slik at flere kjenner til den) og kunnskap 

som må være pålitelig for eksempel ekspertuttalelse i pasientens journal. Sykehus innehar 

også mye dyrt og spesialtilpasset utstyr. Dette er delte ressurser som ofte en pasient skal 

kobles til eller fra. Utstyret kan også trilles sammen med pasienten. I tillegg kommer det å få 

tak i en pasient slik at en får undersøkt personen, eller få tak i portiere som kan trille personen 

til et annet sted. Her må enten pasienten forflytte seg til klinisk personell, eller motsatt. 

Bardram & Bossens (2005) feltstudie studerte blant annet klinikeres bevegelsesmønster. 

Undersøkelsen viste at ansatte på sykehus kan bevege seg opp mot 15 kilometer på et skift. 

Dette er selvsagt avhengig av personens arbeid og sykehusets oppbygning, men illustrerer et 

viktig poeng - mange ansatte beveger seg og utfører mye mobilt arbeid. Klinikernes hverdag 

handler mye om å bevege seg fra et sted til et annet, og hjelpemidler som kan være med å 

effektivisere arbeidet deres vil være nyttig både for sykehuset og pasientene. Basert på 31 

målinger over en 20-dagers periode, viste feltobservasjonen at en lege i gjennomsnitt 65% av 

tida var borte fra gruppe- og møterom og uten tilgang til PC. 

Flere studier har sett på kommunikasjon på sykehus og problemene kommunikasjonsfeilene 

eller mangelen på kommunikasjon har ført med seg. Dårlig kommunikasjon kaster ikke bare 

bort verdifull tid, det kan også føre til feil pasientbehandling, og er hovedproblemet til feil 

som kan unngås på sykehuset (Gopher et al. 2003). Dette kan igjen føre til pasientskader, eller 

i verste fall dødsfall, som følge av feil eller dårlig kommunikasjon mellom klinikerne. En 

studie viste at 37% av alle registrerte feil på sykehuset, var feil relatert til kommunikasjon 

(Gopher et al. 2003). Dette viser hvor viktig det er med god og riktig kommunikasjon i en 

klinisk setting. Et forskningsstudie har sett på å utvide dagens kalleløsning til 2-veis kalling 

(Eisenstadt et al. 1998). De testet ut en løsning der en kunne motta tekstlige meldinger på en 

kaller med display. Løsningen tilbød mulighet for å sende og motta tekstlige beskjeder. 

Systemet ga også meldinger til klinikerne, som for eksempel når ønskede blodprøveresultater 

var ferdig og liknende. Klinikerne som deltok i testingen av 2-veis kallingen mente denne 

hadde vært verdifull i deres pasientbehandling og hadde ved flere anledninger fått raskere 

- 15 -


tilgang på klinisk informasjon. Gjennom uttestingen fant forskeren også ut at brukerne ønsket 

mulighet for utfylling av skjemaer, mulighet til å kjøre applikasjoner og en bedre løsning for 

tekstlig input, enn den 2-veis kallingen kunne tilby. Bruk av mobil enhet i en klinisk setting 

har stort potensial med tanke på å løse deler av problemene som klinikere har med tanke på 

kommunikasjon og informasjons prosesser når de er mobile. Ofte er leger og sykepleiere 

veldig vanskelig å nå på telefon direkte. Asynkron kommunikasjon som kalling mislykkes 

med å gi detaljert informasjon om årsaken for anropet og dens nødvendighet (Ammenwerth et 

al. 2000). På bakgrunn av deres undersøkelse og dens resultater hevedes det at en mobil enhet 

vil kunne være nyttig i mange situasjoner. 

3.3 Kontekst sett i sammenheng med sykehus 

Kommunikasjon er viktig i arbeidsdagen, og innenfor kommunikasjon er det viktig med 

kontekst. Kontekst er informasjon som kan brukes til å karakterisere en enhets situasjon. 

Enheten kan være en person, et sted eller et objekt som er antatt å være relevant for 

interaksjonen mellom en bruker og en applikasjon, inkludert brukeren og applikasjonen selv 

(Dey og Abowd 1999). Ved hjelp av kontekst kan enkeltpersoner og sykehus som 

organisasjon forenkle kommunikasjon og ha mulighet til å effektivisere arbeidsflyten. 

Kontekst brukes for å unngå at interaksjonen mellom bruker og system blir en flaskehals, man 

kan spare tid, og bruke tiden mer effektivt. Man snakker om kontekst-sensitive systemer. 

Primære konteksttyper er tid, identitet, lokasjon og aktivitet. Disse kan igjen knyttes til 

sekundære konteksttyper, som f.eks at et navn knyttes til et telefonnummer eller epostadresse. 

Dette gir et mer nyansert bilde. Kontekst kan hjelpe ansatte på sykehus i en 

beslutningsprosess, med hensyn til hvem man skal kontakte i ulike situasjoner. Kontekst som 

lokasjon, rolle, tilstedeværelse og tid sier noe om hvilken informasjon brukere prioriterer for å 

hjelpe brukere i deres arbeidsoppgaver (Karlsen 2004). 

Tid informerer når en aktivitet starter og slutter, og sier noe om når personen blir tilgjengelig 

eller opptatt. Dette kan være nyttig for brukerne av et kontekstinformativt system på et 

sykehus, fordi man får en indikasjon på hvor lenge en aktivitet er ment å vare. Ved at en 

bruker kan sette start-tid og slutt-tid på en aktivitet kan medarbeider se når vedkommende er 

tilgjengelig igjen. 

- 16 -


Identitet er ofte knyttet til roller, som lege, bakvakt, avdelingssykepleier, pasientkoordinator 

osv., men kan også være navn. Ideelt viser man navn og rolle til personen, etterfølgende i en 

kontekstinformativ oversikt. Ved å søke etter slik informasjon kan man enkelt finne de 

personer eller roller man ønsker å kontakte. Man vil også kunne se hvilken rolle personen har, 

ikke nødvendigvis hvem den personen er, f.eks ved å søke etter avdelingslege eller ansvarlig 

sykepleier. 

Et annet viktig aspekt med kommunikasjon på et sykehus er lokasjon. Man kan bruke 

lokasjonsbaserte systemer for å se hvor på sykehuset ansatte befinner seg, slik kan man se om 

personen er tilgjengelig eller oppsøke personen ansikt-til-ansikt om man ønsker det. 

I tillegg snakker man gjerne om tilgjengelighet eller aktivitet. En persons aktivitet sier noe om 

tilstedeværelsen til personen. Det kan være tilgjengelighet som opptatt, ledig, møte, kontortid, 

pasientvisitt etc. I noen tilfeller der aktivitet står på kontortid eller pasientvisitt får man også 

en antydning om hvor vedkommende er. Tilgjengeligheten kan også enkelt markeres med 

fargekoder. Da vil man ikke få noen indikasjon på hva personen gjør eller hvor den er, det 

ideelle ville være en kombinasjon av disse, slik at man lett kan ta en vurdering om man 

fortsatt ønsker å kontakte en person selv om den står registrert som opptatt. Forthun (2003) 

mener tilgjengeligheten bør kombineres med lokasjon, slik kan tilgjengelighet endres 

automatisk ved hjelp av innendørs lokasjon og bruker slipper å endre tilgjengelighet manuelt. 

Mye av kommunikasjon på sykehus er synkron, som telefonsamtaler, medarbeidermøter eller 

kallinger som fører til telefonsamtaler. Det er imidlertid ikke alle situasjoner der det egner seg 

å kalle eller ringe en lege eller andre klinikere, og i slike situasjoner kan man bruke asynkron 

kommunikasjon. Asynkron kommunikasjon er ikke i sanntid, og man får ikke umiddelbar 

tilbakemelding (f. eks. epost). Det er også kommunikasjonssettinger som kan sies å være 

”nesten” synkrone, IM-baserte systemer er eksempel på dette. Ved at man bruker 

kontekstinformasjon vet man om en person er tilgjengelig for kommunikasjon 

(”tilgjengelighet”). 

Human Computer Interaction (HCI), eller menneske-maskin-interaksjon (MMI) på norsk. 

Menneske-maskin-interaksjon er studie av samhandling mellom mennesker og datamaskiner. 

- 17 -


Fokuset ligger på ulike, viktige elementer for å utvikle god program- og maskinvare. Slike 

elementer kan være brukervennlighet, design, psykologi, sosiologi og kognitiv teknologi som 

alle er med på å påvirke hvordan sluttbruker oppfatter samhandling. 

3.4 Eksisterende systemer 

3.4.1 AwarePhone 

Et dansk forskningsprosjekt (Bardram og Hansen 2004) tilbyr tekstlig visning av lokasjon og 

tilgjengelighet til sykehuspersonell med spesielt fokus på operasjonsavdelingene. 

AwarePhone skal gjøre det enklere å avgjøre hvilke kolleger man kan ringe eller sende 

meldinger til. 

Lokasjon blir automatisk oppdatert ved 

forflytting, men tilgjengelighet blir valgt 

manuelt. Brukerne angir ikke sin tilgjengelighet 

i klartekst, men velger i stedet en aktivitet fra 

en forhåndsbestemt liste. Samtidig blir avtaler 

og andre aktiviteter fra kalenderen automatisk 

hentet fram og vist (se figur 1). 

Figur 1: AwarePhone-brukergrensesnitt 

Fordi den manuelt valgte tilgjengeligheten er uavhengig av kalenderavtalene, blir det 

nødvendigvis ikke samsvar mellom disse to. Dette kan naturligvis skape forvirring og over tid 

frustrasjon. Det blir opp til kollegene selv å tolke om den enkelte bør kontaktes på et gitt 

tidspunkt. 

Tre forskjellige utgaver av AwarePhone er implementert: Symbian for mobiltelefon, HTMLversjon 

for PDA og Java for PC. Systemet bruker blåtann (mobil) og WLAN (PDA og PC) til 

å lokalisere brukerne. GPRS blir brukt som databærer i Symbian-utgaven. Kolleger uten egen 

terminal kan bruke en liten sender for å bli sporet. 

- 18 -


3.4.2 Visma 

En løsning kalt ”Mobil profil” for bruk på bærbare enheter (PDA) i den kommunale 

hjemmetjenesten (Buvik 2008). Brukerne får hentet fram sine arbeidslister med angitte 

tidspunkt, arbeidsoppgaver, besøksadresser og kart. Det er fyldig informasjon om både 

diagnoser og medisinering for alle de pleietrengende. Det er også mulig å skrive mindre 

rapporter. 

Visma har fokusert på flyten av formell informasjon mellom hjemmehjelperne, og ikke de 

mer eller mindre akutte behovene for å kontakte hverandre. 

3.4.3 Knudsens prototyp 

(Knudsen 2007) har skrevet en masteroppgave som først og fremst ser på generell bruk av 

mobile enheter og kommunikasjon ved sykehus. Det ble likevel utviklet en prototyp på en 

tenkt implementering. 

Figur 2: Protoyp-brukergrensesnitt 

- 19 -


Lokasjon er utelatt. I stedet velger brukerne en aktivitet fra en forhåndsbestemt liste. Den 

enkelte aktivitet er knyttet opp mot tilgjengelighet og en farge: 

Grønn: 

Gul: 

Rød: 

Ledig (f.eks. ”på kontoret”) 

Opptatt, men kan forstyrres (f.eks. ”visittrunde”) 

Opptatt, kun forstyrres hvis det er viktig (f.eks. ”operasjon”) 

Når man forsøker å ringe en kollega med ”rød aktivitet” får man opp en ekstra advarsel der 

man blir spurt om du virkelig ønsker å forstyrre denne personen. 

Muligheter for både tekst- og talemeldinger er også tenkt implementert. Avsender kan gi disse 

meldingene rangert prioritert, og dermed blir mottaker varslet i henhold til sin egen 

tilgjengelighet: Mottak av en melding med lav prioritet gir for eksempel ikke lydsignal ved 

”rød aktivitet”. 

- 20 -


4. Våre tekniske løsninger 

4.1 Doctector 

Ett skreddersydd verktøy er et nyttig hjelpemiddel for å kunne gi et godt svar på 

problemstillingen vi har valgt. Det eksisterer som nevnt tidligere flere løsninger som skal 

forenkle hverdagen til leger og sykepleiere. Vi kan tenke oss at disse kan være så kompliserte 

at de hemmer brukervennligheten. Vår tekniske løsning skal være enkel for en bruker å 

benytte, samt skal være tilgjengelig på flere typer enheter. 

Doctector er verktøyet gruppen har laget for å forenkle hverdagen til sykepleiere. Ved hjelp 

av Doctector kan en bruker, i vårt tilfelle en sykepleier eller lege, enkelt finne eller 

kommunisere med andre brukere. Informasjonen en bruker kan få om en annen bruker på er 

dens lokasjon og tilgjengelighet. Lokasjon er realisert gjennom at hver bruker befinner seg 

innenfor en forhåndsdefinert sone, som f. eks. kan for eksempel være en operasjonssal. En 

bruker kan ha tilgjengelighet satt til tilgjengelig eller opptatt, representert med hhv. grønne og 

røde farger, og denne kan enten settes manuelt av hver bruker, eller fås automatisk basert på 

sonen man befinner seg i. 

En bruker kan kommunisere med en annen bruker enten ved å ringe denne opp eller sende en 

melding – begge deler gjøres direkte fra Doctector. Man kan også lese mottatte meldinger og 

bli varslet dersom nye meldinger har kommet i innboksen, verktøyet skiller her mellom uleste 

og leste meldinger, og sorterer deretter. 

Doctector har to grensesnitt som skal gjøre verktøyet enkelt og håndterlig, både fra brukerens 

ståsted og fra en eventuell administrators ståsted. Først vil vi presentere verktøyet sett fra en 

brukers synsvinkel, deretter hvordan grensesnittet vil være for en administrator. 

4.1.1 Brukergrensesnitt 

Brukeren møter i hovedsak fire forskjellige sider av Doctector, avhengig av operasjonen 

brukeren ønsker å utføre. Første side brukeren møter er en påloggingsside, som vist i Figur 1. 

På denne siden kan brukeren skrive inn et brukernavn og trykke på en ”Logg på”-knapp. 

Dersom brukernavnet ikke gjenkjennes vil brukeren sendes tilbake til samme side igjen, ellers 

logges brukeren inn og sendes så videre til forsiden, vist i Figur 2. 

- 21 -


Forsiden er delt inn i to hoveddeler; en liten oversikt over brukerens personlige data og en 

oversikt over kolleger og deres tilgjengelighet og lokasjon. De personlige dataene viser om 

brukeren er doktor eller sykepleier samt dens navn. Det vises også hvor mange nye meldinger 

som ligger i innboksen, og man kan gå direkte til denne ved å klikke på informasjonen om 

antall meldinger. Sist men ikke minst kan brukeren se og endre sin egen tilgjengelighet og 

lokasjon. Tilgjengeligheten kan her byttes mellom ledig (tilgjengelig) og opptatt. Per nå vil 

tilgjengelighet gitt av sonen brukeren befinner seg i, ha prioritet over tilgjengeligheten 

brukeren selv setter dersom sonen pålegger brukeren tilgjengelighet opptatt. I alle tilfeller 

brukes en grønn firkant foran brukerens navn til å symbolisere at den er ledig, og tilsvarende 

en rød firkant for å symbolisere at den er opptatt. Lokasjonen vises som navnet på den 

forhåndsdefinerte sonen brukeren befinner seg i, eller ”Befinner seg på udefinert område”, 

dersom brukeren befinner seg mellom soner. 

Figur 1: Pålogging 

Figur 2: Forsiden 

I oversikten over kolleger kan brukeren sortere disse etter tilgjengelighet slik at de som er 

ledige kommer øverst, eller alfabetisk etter navn eller posisjon. Her brukes også grønne og 

røde firkanter for å markere kollegers tilgjengelighet, slik som i delen for brukerens 

personlige data. I oversikten vises det også et telefon- og meldingsikon per kollega. Ved å 

klikke på telefonikonet vil man få spørsmål om å ringe opp den gitte kollega, og klikker man 

på meldingsikonet kommer man til meldingssiden hvor den gitte kollega automatisk blir satt 

- 22 -


som mottaker av meldingen, og man umiddelbart kan fokusere på å skrive selve 

meldingsteksten, som vist i figur 5. Når man så klikker på ”Send melding”-knappen får man 

beskjed når meldingen er sendt, som vist i figur 6. 

Ved å klikke på informasjonen om antall meldinger i innboksen på forsiden tas brukeren til 

innbokssiden, vist i figur 3. Her vil uleste meldinger ligge øverst, merket med grønt. Eldre, 

leste meldinger vil også ligge tilgjengelige, sortert kronologisk. Brukeren kan ut fra 

meldingsoversikten se hvem som har sendt meldingen og når den ble sendt, i tillegg til et lite 

utkast av meldingen, bestående av de første 20 tegnene fra meldingen. Dersom brukeren 

trykker på en av meldingene blir brukeren sendt videre til meldingssiden, vist i figur 4. På 

denne siden vil hele meldingen vises, og brukeren har muligheten til å skrive returmelding 

eller ringe tilbake. Både innbokssiden og meldingssiden har linker som fører tilbake til 

forsiden. Meldingssiden har i tillegg en link tilbake til innbokssiden. 

Figur 3: Innboks 

Figur 4: Les melding 

- 23 -


Figur 5: Send melding 

Figur 6: Melding sendt 

4.1.2 Administrasjonsgrensesnitt 

For å lettere administrere og visualisere verktøyets overordnede tilstand er et 

administrasjonsgrensesnitt utviklet. Dette kjører sammen med den sentrale tjeneren, som er 

selve hjernen i Doctector og fungerer som tilkoblingspunkt for alle klientene. 

Administrasjonsgrensesnittet består av to vinduer med oppdatert, relevant informasjon. Det 

ene vinduet, vist i figur 7, viser et kart over bygningen hvor Doctector er satt opp og plotter 

tilkoblede brukeres posisjoner i forhold til de forhåndsdefinerte sonene, samt tilgjengeligheten 

hver enkelt bruker har. Her symboliseres brukeres tilgjengelighet ved at brukerens symbol 

tegnes grønt eller rødt, analogt med tidligere beskrevet symbolikk. Videre er soner hvor 

tilgjengelighet for brukere som entrer automatisk settes til opptatt også markert i rødt. Kart for 

den enkelte bygning og definering av soner kan ikke gjøres direkte fra dette grensesnittet, men 

kan lett gjøres manuelt ellers. Dermed kan Doctector tilpasses vilkårlige bygninger hvor 

vilkårlige soner defineres. 

Det andre vinduet administrasjonsgrensesnittet består av er et logg-vindu, vist i figur 8. Dette 

vinduet gir administratoren løpende informasjon om hva som foregår i Doctector. Denne 

- 24 -


Figur 7: Kart over bygning 

informasjon er imidlertid mest nyttig i forbindelse med målrettet feilsøking. I figur 8 ser vi et 

eksempel der tjeneren nettopp har startet, og brukere bli identifiser. Når en bruker logger seg 

på Doctector eller foretar seg andre ting som å lese meldinger vil administratoren få 

informasjon om dette i logg-vinduet. 

- 25 -


Figur 8: Logg-vindu 

Både grunnet mulig fravær av nettdekning eller lokasjonsinformasjon, er et grensesnitt for å 

manuelt angi brukeres posisjoner utviklet, vist i figur 9. Dette er også gunstig for å få testet ut 

annen funksjonalitet. 

Figur 9: Manuell lokasjon 

- 26 -


4.1.3 Arkitektur 

All logikken bak Doctector kjøres på en sentral tjener. Denne lar klienter koble seg til og 

vedlikeholder informasjon om klienters tilstedeværelse i nettverket, slik som hvem klienten er 

og hvilken tilgjengelighet denne har. Klientenhetene tilbyr bare et bilde av informasjonen den 

sentrale tjeneren holder på, være seg kontaktinformasjon, meldinger eller tilgjengelighet og 

lokasjon. Det er den sentrale tjeneren som kontakter lokasjontjenesten brukt, GeoPos i 

Trådløse Trondheim, for å be om lokasjonen til hver klient registrert. 

Den sentrale tjeneren eksponerer en ordinær web-tjeneste som kan nås fra hver klient 

gjennom dens innebygde nettleser. All kommunikasjon skjer på denne måten. 

4.2 Begrunnelse av valg 

4.2.1 Lokasjonsteknologi 

Gruppen fikk tidlig i semesteret presentert lokasjon i trådløse nettverk, i form av 

lokaliseringstjenesten GeoPos i Trådløse Trondheim. Denne tjenesten skulle tilby 

tilfredsstillende nøyaktighet av lokasjon til gruppens formål, noe som helt ukritisk ble 

akseptert av gruppen. En kort diskusjon rundt alternative teknologier for lokasjon ble tatt, men 

da GeoPos var en tjeneste som allerede var på plass og skulle være dekkende for gruppens 

behov, ble ikke alternative teknologier tatt i videre betraktning. 

I en tidlig fase av prosjektet ble lokasjonstjenesten utprøvd, da kun for å se at denne lot seg 

bruke rent teknisk. Man fikk varierende resultater med avvik på bortimot 10 meter i alle 

retninger, men dette var forventet, og skulle være tilfredsstillene for gruppens behov. 

Utfyllende testing for å avdekke nøyaktighet ble ikke gjennomført i denne omgang, det ble 

snarere konstatert at lokasjonstjenesten fungerte som forventet og utvikling av gruppens 

system ble påbegynt. 

4.2.2 Arena 

Trådløse Trondheim er tilgjengelig i store deler av Trondheim sentrum, og GeoPos kan 

brukes til å lokalisere tilkoblede enheter i dette nettverket. Nødvendig trådløs dekning er 

imidlertid vanskelig å oppnå innendørs, med unntak av kjøpesenteret Solsiden, hvor Trådløse 

Trondheim er bygget ut i form av tre innendørs aksesspunkter. 

- 27 -


For å imøtekomme gruppens problemstilling var en innendørs arena ønskelig, og Solsiden var 

dermed et opplagt valg. Omgivelsene på et kjøpesenter er naturlig nok svært forskjellige fra 

en avdeling på et sykehus, men det finnes likheter man kan tillate seg å trekke inn. 

Vrimleområder og gangveier kan brukes som korridorer like fullt som enkeltbutikker kan gå 

for å være pasientrom. Det ville også vært fullt mulig å benytte en utendørs arena, men dette 

ville blitt mindre realistisk i forhold til problemstillingen, samt at man rent praktisk måtte tatt 

høyde for utilregneligheter som vær og vind. Et slik alternativ ble derfor ikke videre vurdert. 

4.2.3 Arkitektur 

Omgivelsene for problemstillingen satte få begrensninger på valgt arkitektur. De to mest 

betydningsfulle faktorene var valget av lokasjonsteknologi og like fullt valget av enheter som 

kunne dekke de nødvendige behov. 

4.3.4 Enheter 

Gitt av problemstillingen er det informasjon om tilgjengelighet og lokasjon som skal tilbys. 

En sykepleier skulle kunne se andres tilgjengelighet og lokasjon, samt oppgi sin egen 

tilgjengelighet. Disse kravene impliserte behovet for en interaktiv enhet, og 

lokasjonsteknologien krevde videre en enhet som kunne koble seg til trådløse nettverk. 

Klassen av enheter som tilfredsstilte de ovenfornevnte krav var mobiltelefoner med støtte for 

trådløse nettverk. Noen av gruppens medlemmer hadde slike mobiltelefoner, og det ville være 

mulig å få lånt flere kvalifiserte mobiltelefoner. 

Enhetenes funksjonalitet måtte også kunne utvides for å dekke problemstillingens behov. 

Valg av arkitektur falt umiddelbart på en klient-tjener-arkitektur, som i korte trekk innebærer 

at en sentral tjener holder på det meste av data mens flere klienter kontakter denne og 

utveksler nødvendig informasjon. Dette er en selvskreven arkitektur grunnet behovet for en 

sentral database for tilgjengelighet, lokasjon og meldinger for personer samt selve kontakten 

med GeoPos for å spørre om posisjoner til hver enkelt enhet. I tillegg har enhetene begrenset 

kapasitet og typisk ustabil tilkobling til det trådløse nettverket. 

Det siste valget vedrørende enhetene som skulle brukes var hvor mye funksjonalitet som 

skulle plasseres i disse i forhold til i den sentrale tjeneren. Av grunnene nevnt ovenfor var det 

- 28 -


klart at enhetene måtte brukes som tynn-klienter, altså at all primær funksjonalitet skulle 

befinne seg på tjeneren. Det var likevel to alternativer for hvordan tynn-klientens 

funksjonalitet for å snakke med tjeneren skulle implementeres: 

• Man kunne utvikle egen programvare for enhetene. Dette ville gjøre det mulig å 

tilpasse brukergrensesnittet maksimalt, men kunne fort ta lang tid siden det ville bli en 

del arbeid. Videre måtte man håndtere kommunikasjon med tjeneren frem og tilbake, 

noe som fort kunne by på problemer gitt den ustabile tilkoblingen. 

• Alternativet, som gruppen valgt å gå for, var å la tjeneren eksponere den velkjente 

HTTP-protokollen, brukt til ordinære web-tjenester, og la enhetene bruke sin 

innebygde nettleser for å aktivt hente informasjon fra tjeneren ved jevne intervaller. 

Dette førte til at ingen ny funksjonalitet måtte implementeres på klientsiden, men at alt 

ble håndtert på tjenersiden. Bruken av den eksisterende protokollen for overføring av 

data gjorde også at dette ikke var noe man trengte å tenke på verken på klient- eller 

tjenersiden. Sist, men ikke minst, ville en større mengde enheter kunne fungere på 

denne måten enn om man hadde utviklet spesifikk programvare. 

4.3.5 Sentral tjener 

En sentral tjener ble, som nevnt, brukt for å avlaste kravet til funksjonalitet hos klientene. 

• Tjeneren benyttet seg av en ekstern database, for at man under utviklingen parallelt 

skulle kunne teste mot én og samme database fra flere arbeidsstasjoner. 

• Programmeringsspråket Java ble brukt da dette var det språket gruppen hadde høyest, 

felles kompetanse på. I tillegg fikk man platformuavhengighet på tjenersiden med på 

kjøpet. 

• Behovet for å hvert 30. sekund spørre GeoPos-tjenesten om lokasjon til hver av 

klientene, gjorde at man ikke kunne bruke en ren HTTP-tjener. En HTTP-tjener ble 

derfor bare brukt i tillegg til den primære tjeneren for å eksponere dens funksjonalitet 

til klientene. 

• Siden Java allerede var valgt som programmeringsspråk, ble Apache Tomcat valgt 

som HTTP-tjener for å lette kommunikasjonen mellom den primære tjeneren og 

HTTP-tjeneren, i form av Java RMI. HTTP-tjenerens minimale, nødvendige 

funksjonalitet ble følgelig også utviklet vha. Java. 

- 29 -


For mer detaljert informasjon, se Appendiks B. 

4.4 Funksjonalitet 

Funksjonaliteten til systemet, tett knyttet til brukergrensesnittet på klientene, ble med hensikt 

begrenset til det mest nødvendige. Dette både fordi tiden man hadde til rådighet var svært 

begrenset, og at det var ønskelig å oppnå en enkel og intuitiv løsning. 

Funksjonalitet for å legge til nye personer, rom, tilgjengelighetsnivåer m.m. ble ikke utviklet 

da dette ikke var nødvendig for å gjennomføre forsøk. Slik informasjon ble direkte modifisert 

i den bakenforliggende databasen. For enkelthets skyld ble også et gitt rom tilordnet en 

bestemt tilgjengeliget som alle personer som entret dette romme skulle tildeles, i stedet for det 

som i reelle omgivelser hadde vært mer naturlig, nemlig at et rom kunne hatt forskjellige 

tilgjengelighetsnivåer knyttet til seg alt etter hvilken person som entret rommet. 

Da dette var et rent eksperimentelt forsøk ble svært viktige elementer som personvern og 

sikkerhet generelt mer eller mindre ignorert. Den eneste informasjonen som lagres om 

personer er imidlertid kun deres nåværende lokasjon. Denne informasjonen lagres ikke i 

databasen, men tas bare vare på så lenge tjeneren er operativ. Videre er sikkerheten rundt 

klientpålogging og all videre informasjonsutveksling bortimot fraværende. Dette er imidlertid 

ikke noe som har blitt fokusert på, da det er ansett som irrelevant i forhold til 

problemstillingen. 

Utvidbarhet av den produserte programkoden har heller ikke vært veldig i fokus, men snarere 

å ferdigstille systemet for å kunne gjennomføre forsøk. Skulle man fokusert mer på dette 

måtte man hatt mer tid til rådighet til implementasjon av systemet. 

4.5 Erfaringer 

4.5.1 GeoPos 

Posisjoneringssystemet på Solsiden består av tre aksesspunkter som henger etter hverandre i 

hovedbygningen på kjøpesenteret. Det lave antallet punkter gjør at triangulering basert på 

signalstyrke ved et sett basestasjoner kan bli vanskelig. Disse tre punktene henger også etter 

hverandre på en relativt rett linje, og i stor grad mister en da posisjonering i to dimensjoner. I 

tillegg er de fysiske egenskapene til Solsiden, som f.eks. glasstaket, begrensende for 

- 30 -


posisjoneringssystemets funksjonalitet og kvalitet. I tillegg var GeoPos konfigurert med en 

begrensing på lokasjon av maksimalt 2500 enheter, etter førstemann til mølla-prinsippet. 

Dette førte til at ingenting fungerte som forventet da vi skulle teste GeoPos for første gang. På 

grunn av tidspress måtte vi fortsette med utviklingen, og valgte derfor å se på nedetiden som 

et midlertidig fenomen. Dette skulle senere vise seg å ikke stemme, og er en av grunnene til 

gruppens samlede oppfatning om at vi i større grad burde ha vurdert alternative tekniske 

løsninger. 

4.6 Alternative tekniske løsninger 

4.6.1 Ultralyd 

Studentersamfundet i Trondheim hadde under UKA et prøveprosjekt i samarbeid med 

Accenture der Samfundets medlemmer kunne bære med seg en liten brikke som periodisk 

sendte ut ultralyd impulser. Mikrofoner som var oppstilt i lokalene fanget opp disse 

impulsene. Ved hjelp av triangulering kunne posisjonen til hver enkelt brikke bestemmes. 

Nøyaktigheten av dette systemet har ikke blitt undersøkt, men den var tilfredsstillende i 

forhold til en per-rom-nøyaktighet, som ville ha vært dekkende i vårt tilfelle. 

Automatiseringen ved bruk av ultralyd kan også opprettholdes på samme måte som i vår 

implementasjon av Doctector. Dersom en ser på de teknologiske mulighetene vil ultralyd 

være en reell utfordrer til lokasjon i trådløse nettverk. Bruk av ultralyd ville imidlertid krevd 

en del ekstra utstyr, i form av mikrofoner og kabling. 

4.6.2 RFID 

En mer halvautomatisk tilnærming av lokasjonssystemet kan være bruken av RFID-brikker. 

Hver bruker kan benytte sin mobile enhet til å markere når de kommer inn i et rom. På samme 

måte som i vår løsning kan hvert rom få angitt en standard tilgjengelighet, som denne 

personen da får tildelt når den entrer rommet. På grunn av den manglende automatiseringen, 

vil en måtte stille større krav til enkelte brukere dersom en hadde implementert vha. RFID, 

mens det for andre brukere vil kunne ligne mer på dagens løsninger. 

4.6.3 Cordis RadioEye 

Verktøy for lokasjon av enheter i WLAN-soner. En ekstern ”boks” utviklet av Radionor blir 

koblet sammen med den trådløse ruteren. I likhet med løsninga til Trådløse Trondheim blir 

enhetene identifisert ved hjelp av MAC-adressene. 

- 31 -


Både Telenor og Statoil har brukt RadioEye i forskningsprosjekter. Blant annet har systemet 

blitt installert i Nidarosdomen og Erkebispegården, der relevant informasjon blir sendt til 

håndholdte terminaler ut fra lokasjon (Evjemo 2005). 

4.7 Problemer med utstyret 

Etter at deler av Doctector var implementert og målinger ble gjort for å kartlegge 

unøyaktighet ble en del problemer med utstyret avdekket. Utstyret det her er snakk om er for 

det første enhetene tidligere nevnt, da mobiltelefoner med støtte for trådløst nettverk. I tillegg 

ble bærbare datamaskiner brukt til å foreta en del målinger i mangel på mobiltelefoner. Det 

viste seg at måleresultater varierte i langt større grad enn først antatt og målt. Straks litt 

bevegelse og flere typer enheter kom inn i bildet ble resultatene spredt utover et uakseptabelt 

stort areal, som gav en slik unøyaktighet at arenaen for forsøket så vidt kunne brukes til en 

middelmådig gjennomføring av det hele. Forskjellige mobiltelefoner gav svært forskjellige 

resultater, og én og samme telefon kunne også gi store avvik fra nøyaktig samme plassering 

ved gjentatte målinger. Dette førte til at prosessen med å definere ikke-overlappende soner for 

å gjennomføre et forsøk ble svært vanskelig, og vi endte opp med 4 soner vi med sikkerhet 

klarte å skille fra hverandre. Dette var bare halvparten av sonene man så for seg at man skulle 

kunne klare å definere. 

- 32 -


5. Metoder og scenarier 

Dette forsøket ble gjennomført som en pilotstudie hvor hensikten var å kartlegge hvordan den 

utviklete applikasjonen/prototypen fungerte (eventuelt ikke fungerte) i en bestemt setting, 

samt oppdage mulige forbedringspotensialer. 

5.1 Feltobservasjon 

Feltobservasjoner kan være til stor nytte når man ønsker å samle inn deskriptiv informasjon 

angående atferd og er ofte basert på teori som veileder fokuset av forskningen. Falluken med 

observasjoner derimot er at det kan være vanskelig å tilskrive kausale forhold mellom 

variabler. En fordel med feltobservasjoner er at de innehar større økologisk validitet 

sammenlignet med fullt strukturerte (kontrollerte) laboratorieeksperimenter, det vil si dataens 

betydning i den settingen den naturlig (og spontant) forekommer. Datainnsamlingen kan 

eksempelvis skje ved notattaking eller videoopptak. Dette medfører at dataen som innsamles 

er svært subjektiv av natur siden det er observatørens oppmerksomhet og tolkninger som leder 

datainnsamlingen. Kvalitative tilnærminger på sin side gjenkjenner og godtar dataens 

subjektive natur, og jobber med den slik den fremtoner seg i stedet for å redusere den 

(Langdridge 2004). 

5.2 Scenarier 

Det finnes flere definisjoner på scenarier. Carroll (1995, i Gallis og Kasbo, 2002) beskriver 

systemutvikling og brukerinteraksjon som en narrativ beskrivelse av hva folk gjør og erfarer 

mens de prøver å bruke systemer og applikasjoner. Videre kan scenarier bli brukt til å 

representere, analysere, samt planlegge hvordan brukerens aktivitet og erfaring bør bli 

påvirket av et datasystem (Gallis og Kasbo 2002). Nielsen (1995, i Gallis og Kasbo 2002) på 

sin side har valgt å definere et scenario som en tilkapslet beskrivelse av en individuell brukers 

interaksjon med et spesifikt sett av datainnredninger for å oppnå et spesifikt resultat i en 

spesifikk situasjon over et bestemt tidsintervall. Siden mobile tjenester ofte blir utført i 

heterogene kontekster, så kan scenarier være behjelpelig i å identifisere relevante problemer. 

Scenarier er også nyttige for utviklere ved at de tidlig retter fokuset mot brukeren (Nielsen 

1995, Carroll 1995, i Gallis og Kasbo 2002). 

- 33 -


5.3 Reliabilitet, validitet, og generalisering 

Reliabilitet omhandler stabiliteten av det som måles. Reliable målinger gir like resultat på 

forskjellige men sammenlignbare tilstelninger. I observasjonssettinger kan man benytte seg av 

inter-rater-reliabilitet, det vil si graden av enighet mellom de som observerer. I dette tilfellet 

vil observasjonene være reliable om observatørene fanger opp den samme informasjonen. 

Validitet på sin side omhandler kort sagt om målingen faktisk måler det den er ment å måle. 

”Face”-validitet er den enkleste formen for validitet og er en subjektiv vurdering om 

måleinstrumentet later til å måle slik som planlagt. En beslektet form av ”face”-validitet er 

konstruktvaliditet. Denne formen for validitet er opptatt av om målingene faktisk når inn til 

konseptet som studeres. Økologisk validitet ble beskrevet kort tidligere og omhandler den 

innsamlete dataens betydelighet i den settingen den naturlig og spontant forekommer 

(Langdridge 2004). 

Det er ofte ønskelig å generalisere funn fra et utvalg av folk tilbake til populasjonen fra hvor 

de ble trukket ut fra. For å ta for seg generaliserbarheten av de funn som blir gjort så må man 

ta i betrakting hvilke subjekter som utgjorde utvalget og hvordan disse ble rekruttert. 

Effektive samplingsmetoder er en viktig måte å øke et studies generaliserbarhet og første steg 

for all sampling er å tydelig definere populasjonen av interesse (Langdridge 2004). 

5.4 Prototyp 

En prototyp er en foreløpig versjon av et softwaresystem som skal brukes for å demonstrere et 

konsept, teste ut designmuligheter og generelt finne ut mer om problemer og 

problemløsninger (Sommerville 2002, i Gallis og Kasbo 2002). Prototyping impliserer 

produksjon av tidlige versjoner av fremtidige applikasjoner, tjenester og løsninger, og på 

denne måten å danne basis for diskusjoner mellom de grupper som er involvert i 

utviklingsprosessen (Budde, Kautz, Kuhlenkamp, & Züllinghoven 1992, i Gallis og Kasbo 

2002). Et fungerende system, dog begrenset, kan raskt demonstrere nytteverdien av 

applikasjonen. En prototyp gir dermed brukeren en tidlig følelse av hvordan det fremtidige 

systemet vil bli, samt at misforståelser kan løses tidlig i prosessen (Gallis og Kasbo 2002). 

- 34 -


5.5 Beskrivelse av utvalgte scenarier 

De ulike scenarioene er ment å gjenspeile sykehussituasjoner med varierende grad av 

akutthet, hvor en sykepleier har behov for å komme i kontakt med en lege. I alle scenarioene 

ble forsøkspersonene tildelt en rolle (tre leger og én sykepleier) og rom hvor de skulle 

oppholde seg i visse tidsrom. Settingen ble inndelt i fire ulike soner for å simulere rommene 

hvor forsøkspersonene skulle oppholde seg, eventuelt bevege seg mellom. Rommene skulle 

blant annet simulere kontorer, sengepost, og operasjonssal. 

Romliste (for alle scenarier): 

Rom 1 – Kontor A 

Rom 2 – Kontor B 

Rom 3 – Operasjonsstue 

Rom 4 – Sengepost A 

Scenario 1 

Lege 1 sitter på kontor A 

Lege 2 sitter på kontor B 

Sykepleier er på sengepost A 

En pasient ser ut til å ha bivirkninger på medisineringen som er gitt, og sykepleieren har 

behov for å konsultere lege. Lege 1 er pasientens visittlege, og sykepleieren ønsker å få 

kontakt med denne. Tar frem enheten, og ser at legen er ledig. Ringer. Legen svarer, og de 

avtaler at legen skal komme til sengepost A 

Scenario 2 

Lege 1 er på operasjonssal og er markert opptatt 

Lege 2 er på kontor B 


En pasient ser ut til å ha et problem med magen. Sykepleieren ønsker å konsultere legen for å 

følge dette opp. Sykepleieren tar opp enheten og ser at lege1 som er visittlegen er opptatt. Ser 

derimot at den andre visittlegen som er lege2 er ledig og ringer denne. Legen gir beskjed om 

medisinering. 

- 35 -


Scenario 3 

Lege 1 er opptatt 

Lege 2 er på operasjonssal – automatisk opptatt. 


Lege 4 er ledig 


En pasient trenger oppfølging, dog ikke akutt. Sykepleieren tar opp modulen, ser at lege 1 er 

opptatt. Ser også at lege 2 og 3 er opptatt. Ser derimot at lege 4 er ledig. Ringer denne. Her får 

han vite at lege 1 straks er ledig, straks ferdig med en konsultasjon og at han kan sende en 

melding om å ringe opp straks denne er ledig. Sykepleieren takker, legger på og sender ei 

melding til lege 1, og venter. Etter en 5 min. tid ringer lege 1. 

Scenario 4 



Lege 3 er ledig 



En pasient trenger oppfølging. Sykepleieren tar opp enheten og ser at div. leger er opptatt, at 

han må ta til takke med lege 3. Ringer denne og konsulterer pasientens problemer. Legen sier 

at han kommer bort en tur og ser på pasienten. 

5.5.1 Sampling, utvalg, og setting 

Subjektene ble rekruttert gjennom bekvemmlighetsutvelgelse (convenience sampling), det vil 

si at rekrutteringen skjedde så å si på hvilken som helst måte, og i dette tilfellet plukket vi oss 

selv ut. I dette forsøket utgjorde fire av de åtte forfatterne av denne fagrapporten utvalget (n4) 

hvor de spilte hver sin respektive rolle som enten lege eller sykepleier, mens de resterende fire 

tok rollen som observatører. Forsøket utspilte seg på Solsiden kjøpesenter i tidsrommet 12:40- 

13:35. 

- 36 -


5.5.2 Prosedyre 

Etter en kort gjennomgang av applikasjonens (Doctector) funksjonalitet (presentert tidligere i 

rapporten), fikk subjektene tildelt sine roller mer eller mindre tilfeldig ut fra ønsker. 

Påfølgende ble det utlevert individuelle adferdsbeskrivelser og utsagn som de ulike subjektene 

skulle utspille under forsøket. Observatørene fokuserte på sykepleieren og noterte adferd samt 

utsagn. Først ble de ulike scenarioene gjennomført kronologisk med pause mellom hver, før 

de til slutt ble kjørt fortløpende i femminutt- intervaller uten pauser mellom hvert scenario, 

med tanke på å simulere en mer kompleks og realistisk sykehussituasjon. 

- 37 -


6. Diskusjon 

6.1 Diskusjon rundt reliabilitet, validitet og generaliserbarhet 

Hensikten med pilotstudiet av applikasjonen (prototypen) var først og fremst å teste ut om den 

fungerte i en bestemt setting og ikke nødvendigvis dens nytteverdi. Applikasjonen svarte til 

forventningene ved at den viste seg som intuitiv og oversiktelig med tanke på lokasjon og 

kalling, hvor sykepleierrolleinnehaveren tilkalte legene i henhold til scenariobeskrivelsene 

uten videre problemer. Siden testingen ble utført på kun et tidspunkt så er det vanskelig å 

fastslå applikasjonens reliabilitet, dermed bør fremtidig testing ta sikte på å gjennomføre 

gjentatte målinger i ulike lokasjonssettinger (spesielt sykehus i dette tilfellet) og med trente 

observatører med forhåndsdefinerte observasjonsrammer. Det positive med å benytte seg av 

konkrete forhåndsdefinerte scenarioer er at dette vil bidra til å øke studiets reliabilitet og 

eksterne validitet ved at det letteliggjør replikering. På den andre siden så kan konkrete 

forhåndsdefinerte scenarioer gå på bekostning av aktørenes spontane atferd og evne til 

problemløsning og kreative tenkning. En mulighet ville vært å designe mer åpne scenarioer 

hvor atferden ikke var kronologisk og forhåndsdefinert noe som ville gitt uttestingen en større 

grad av spontanitet og naturlig atferd. 

De scenarioene som ble brukt i dette studiet kan ses på som tilstrekkelige for å teste ut selve 

applikasjonen, men de er nok utilstrekkelige til å gjenspeile sykehussituasjoner som i større 

grad er mer intense og komplekse. Videre så må framtidig testing utprøves på et sykehus eller 

tilsvarende (for eksempel rollespill i en mer realistisk setting) med virkelige aktører (dvs. 

leger og sykepleiere). Dette vil kunne styrke studiets økologiske- og eksterne validitet 

(generaliserbarhet). Om man i tillegg vil prøve ut applikasjonen i andre land enn Norge så må 

det først gjøres mulig å bytte språk (for eksempel til engelsk). Fremtidige modeller basert på 

denne prototypen bør gjennomgå en konseptuel analyse av applikasjonens for å anslå dens 

nytteverdi i en sykehussetting. Den videre testningen kan også gi et større innblikk i 

prototypens aktuelle potensialer og begrensninger, samt eventuelle konfunderende variabler 

som kan true dens interne validitet. Om det for eksempel viser seg at sykepleiernes kunnskap 

om andre sykepleiere og legers rutiner (for eksempel lokasjon) er årsaken til økt nytteverdi og 

ikke selve applikasjonen, så kan man si at dette er en konfunderende variabel, med andre ord 

en underforeliggende variabel som påvirker resultatet. Slike variabler er det ønskelig å 

kontrollere om man vil teste ut applikasjonens nytteverdi, med andre ord holde alle andre 

- 38 -


mulige forklaringer, med unntak av applikasjonens påvirkning, konstante. En annen mulighet 

er å teste vår applikasjon opp mot en annen som ikke viser tilgjengelighet men som kan han 

meldingsfunksjon. Dette kan bidra til å avdekke om vår applikasjon har en signifikant effekt 

eller ikke. 

6.2 Doctectors mulige påvirkning på kommunikasjon og relasjoner på et 

sykehus 

Doctector har som formål å skulle vise legers og sykepleieres lokasjon og tilgjengelighet. 

Hvordan kan dette påvirke kommunikasjonen og relasjonen mellom leger og sykepleiere? 

6.2.1 Leger og sykepleieres hverdag og kommunikasjon med og uten Doctector 

Som nevnt i ”Innledning” (kap 1), er hverdagen til leger og sykepleiere hektisk, det er et høyt 

tempo både for arbeidsoppgaver og kommunikasjonen. For å få tak i leger må sykepleierne 

kalle på dem. Kallingen av leger fører med seg at legen ikke får noen info om hvem som 

ønsker kontakt, ingen info om graden av viktighet av kontakten og den som ønsker kontakt får 

ingen info om personen de ønsker kontakt med er opptatt. Dette fører til en svært avbrytende 

arbeidsform (Dahl 2007). 

Doctector kan, ved å vise lokasjonen og tilgjengelighet for legene, gjøre arbeidsformen 

mindre avbrytende. Dette fordi sykepleierne ikke trenger å kalle på legen, men kan ta direkte 

kontakt med ham eller å se tilgjengelighet direkte. Dette fører med seg at legen får 

informasjon om hvem som kontakter ham. Han vil, dersom han svarer, få vite graden av 

viktighet av kontakten, og sykepleier unngår å prøve å kontakte leger som ikke er 

tilgjengelige. 

Det kan se ut som Doctector kan ha en positiv virkning på kommunikasjonen mellom leger og 

sykepleiere gjennom å gi informasjon om kontekst. Dette fordi kontekst omfatter det som er 

relevant bakgrunn for å produsere eller forstå en ytring (Svennevig 2001). Når Doctector gir 

legen informasjon om hvem som ringer vil han kunne aktualisere relevant kontekst for 

samtalen som skal finne sted, og som nevnt kan dette være kunnskap om den konkrete 

samhandlingssituasjonen, tidligere samhandlingssituasjoner, den fysiske situasjonen en 

ytring/samtale er en del av og den generelle bakgrunnskunnskapen man har i form av 

holdninger, oppfatninger og vitenskaplig kunnskap (ibid.). Legen ser hvilken sykepleier som 

ringer, og vil kanskje klare å knytte denne sykepleieren til en spesifikk avdeling og har 

- 39 -


dermed aktualisert kontekst i form av den fysiske situasjonen ytringen er en del av. Han har 

dermed allerede gått inn i samhandlingen med sykepleieren før han har svart på samtalen. 

Dette er en fordel ved det tekniske systemet på den måten at det kan gjøre det mer lettvint for 

legen fordi han allerede har kunnskap om samtalen før den har startet. Gjennom å se hvem 

som prøver å få tak i han, har legen aktualisert relevante kontekstuelle rammer for 

situasjonen, som den fysiske rammen i form av å knytte sykepleieren til en spesifikk avdeling, 

den kulturelle rammen i form av å tilhøre sykehuskulturen og den institusjonelle rammen 

fordi han er tilgjengelig for sykepleieren som ringer. De kontekstuelle rammene som 

bakgrunnskunnskap, som gjerne er det sykepleieren og legen gjør gjeldende i interaksjonen i 

form av kunnskap fra tidligere samtaler med samme person, samt bakgrunnskunnskap om den 

gjeldende pasienten og samhandlingssituasjonen, aktualiseres først i samtale med 

sykepleieren. 

Kommunikasjonsmessig kan det se ut som Doctector kan ha en positiv virkning på 

kommunikasjonen mellom leger og sykepleier. Doctector gjør legen i stand til å aktualisere 

relevant kontekst for den foregående samhandlingssituasjonen ved å kunne se hvem som 

ønsker kontakt med han. For at dette skal kunne skje, må Doctector brukes etter intensjonene. 

Det vil si at legen ikke kan sette seg selv manuelt som opptatt hele dagen på Doctector. Det 

vil også være viktig at sykepleierne ikke misbruker Doctector, og ringer ledig lege for hver 

minste ting. Doctector er ment som et verktøy for både leger og sykepleiere, som gjør at leger 

lettere kan ta tak i avbrytelsene det medfører å være tilgjengelig ved at de har muligheten til å 

kontektstualisere situasjonen ved å kunne se hvem som ønsker kontakt. Sykepleiere slipper å 

kalle på en opptatt lege, men kan ta direkte kontakt med den som er ledig. Dersom Doctector 

blir brukt etter intensjonene, kan den påvirke kommunikasjonen for leger og sykepleiere, men 

dersom legene stadig vekk setter seg selv som opptatt for å slippe å bli kontaktet av 

sykepleierne, vil ikke denne ha noen funksjon på kommunikasjonen. 

6.2.2 Leger og sykepleieres relasjon med og uten Doctector 

Som nevnt i ”Hverdagen på et sykehus; roller og relasjoner” (kap 3.1), er relasjonen mellom 

leger og sykepleiere hierarkisert gjennom at begge disse gruppene innehar ulike kvaliteter. 

Den er preget av respekt og avstand. Mens sykepleierne er de som er nærmest pasienten og 

dermed kommer først i besittelse av observasjonen, er det legene som har bruk for 

sykepleiernes observasjoner. Dette gjør at legene ser på sykepleierne som sine assistenter, 

mens sykepleierne på sin side ønsker å være likestilt med legen (Holm-Pettersen et al. 2006). 

- 40 -


De språkhandlingene man da finner på et sykehus vil sannsynligvis bestå av konstantiver, som 

inneholder handlinger som å informere, å gjengi og å forklare, direktiver, som består av å be 

(om noe), å anmode, å beordre og å kreve, og kommissiver som er handlinger hvor taleren 

forplikter seg selv til å utføre en handling (Vagle et al. 2004). Her vil sykepleieren være den 

som anmoder om at legen kommer og ser til pasienten, mens legen vil være den som beordrer 

eller gir sykepleieren ordre om å utføre noe. 

Selv om Doctector ikke nødvendigvis vil ha en direkte virkning på relasjonen mellom leger 

og sykepleiere, kan bruken av den ha en indirekte virkning. Dersom dette er tilfelle vil det 

sannsynligvis komme til uttrykk gjennom asymmetrien og dominansen i samtalene mellom 

lege og sykepleier. Asymmetri er naturlig i en samtale, og er ofte knyttet til besittelse av ulik 

kunnskap og sosiale posisjoner eller institusjonelle roller, likevel kan det skape hindringer, 

problemer og dårlig kommunikasjon (Linell og Luckmann 1991). Asymmetri i samtalen vil 

derfor skapes av begge parter, både lege og sykepleier, i interaksjonen fordi både lege og 

sykepleier i løpet av en arbeidsdag vil være i besittelse av kunnskap som den andre ikke 

innehar og dermed har bruk for. Dette vil ikke Doctector ha noen relevant innvirkning på, 

derimot vil Doctector kunne ha innvirkning på hvordan dominansen mellom leger og 

sykepleier oppleves. Dominans er ikke noe som forekommer naturlig i en interaksjon, og 

forekommer når en person bestemmer temaene, temautviklingen i interaksjonen, og er den 

som har flest turer (ordet mest). I og med at dominans er et begrep som er knyttet opp til 

asymmetri, kan dominans også komme til uttrykk gjennom manifesteringen av de 

institusjonelle rollene legen og sykepleieren innehar, samt de begrensningene og mulighetene 

som aktualiseres gjennom dette (Vagle et al. 2004). 

Gjennom å få direkte tilgang til legenes tilgjengelighet og lokasjon gjennom Doctector kan 

dette gjøre at sykepleierne ikke føler at hierarkiet er like fremtredende mellom dem selv og 

legene. I dagens system kaller de på legen, og aner ikke om legen egentlig er tilgjengelig og 

når de kan forvente at han kaller tilbake. Det kan tenkes at sykepleierne derfor kan føle at 

legene har mer makt enn dem selv, noe som kan være med å skape skillet mellom disse to 

arbeidsgruppene. Holm-Pettersen et al. (2006) nevner at sykepleierne vil ses på som likestilte 

med legene av legene. Det kan tenkes at det å få tilgang til å se om legen er tilgjengelig eller 

opptatt, kan ha en positiv virkning på sykepleiernes følelse av å likestilles med legene fordi de 

enklere kan få kontakt med dem, samt se om de er opptatt og derfor slipper ventetiden på å 

- 41 -


kalle og lure på hvorfor legen ikke ringer tilbake. Noe som kan problematiseres i forhold til 

dette er det faktum at legers bruk av tid ofte er selvbedragende (Wagner 1993). Wagner 

(1993) har et eksempel på dette hvor hun viser til de kalenderne som leger bruker for å sette 

opp hva de skal gjøre og når de er opptatt. Dersom de skal i en operasjon beregner de tid til 

blant annet eventuelle komplikasjoner, så de ikke er ledige før operasjonen er ferdig. Faren 

ved at man har mulighet til å sette tilgjengelighet på Doctector selv, er at legen kan sette 

tilgjengeligheten til opptatt hele dagen. Dersom dette skjer vil ikke Doctector fungere etter sin 

hensikt, fordi man ikke vil få en reel oversikt på Doctector over hvilke leger som faktisk er 

tilgjengelige. Dette er det blitt gjort forskning på tidligere, og det kan tyde på at leger gjerne 

setter seg selv som opptatt. Det kan derfor argumenteres for at tilgjengelighet i hovedsak skal 

komme automatisk etter hvilke rom man er i. 

6.3 Videreutvikling av Doctector 

Dette avsnittet tar for seg noen tanker om hva man kunne ha gjort med ytterlige ressurser, tid 

og arbeidskraft. 

6.3.1 Meldingsmaler 

Meldingsfunksjonen er ment til å gi korte, enkle beskjeder, og derfor kan det være en idé å 

lage en liste med meldingsmaler. Disse kan være forholdsdefinerte og/eller egendefinerte av 

brukerne. For å gjøre løsninga mer brukervennlige kan muligens disse malene ha egne 

ikoner/snarveier på meldingssida. 

6.3.2 Universelt design 

De grønne og røde firkantene foran navnet på kollegene er bare ren farge. Ved i tillegg å lage 

en formmessig forskjell mellom disse, vil ikke fargeblinde ha problemer med å skille fargene. 

Det gjelder i og for seg også administrasjonskartet der de figurene bare har forskjellig farge; 

rød og blå. 

6.3.3 Roller og sengeposter 

Prototypen deler ikke de ansatte inn i sengeposter og skiller heller ikke mellom forskjellige 

roller i ”hierarkiet”. Ved å ha implementert dette kunne man ha gjort enda lettere å finne rett 

person til sengepost. 

6.3.4 Sikkerhet 

Vi valgte å se helt bort fra sikkerhetsaspektet i applikasjonen vår. Innlogging skjer gjennom 

bare å oppgi brukernavn. En opplagt autentiseringsfunksjonalitet som passord mangler rett og 

- 42 -


slett. Det er åpenbart noe av det første som må på plass om vi skulle ha videreutviklet 

Doctector. 

Utover dette bør overføring av data generelt sikres bedre. Serveren mangler kryptering, og 

SSL vil være et naturlig alternativ for å hindre ”tjuvlytting” og at noen endrer på 

overføringene. Dessuten er det viktig at lagring av passordene blir godt beskyttet med blant 

annet hash-funksjoner. 

6.3.5 Automatisk terminal-gjenkjenning 

GeoPos gjenkjenner terminaler basert på MAC-adressen. Denne må i dag manuelt angis, og 

kobles opp mot brukeren. En automatisk funksjon ville ha forenklet prosessen kraftig. 

6.3.6 Nødalarm 

Det vil være ønskelig at sykepleierne og legene i akutte situasjoner skal kunne slippe å ta 

standpunkt til hvem som skal kontaktes. Derfor bør en slags nødknapp bli bygget inn. Ved å 

trykke denne, vil de nærmeste kollegene automatisk bli tilkalt. (Forthun 2003) har skissert en 

slik løsning. 

6.3.7 Pasientdata 

Lignende kommersielle løsninger har stort fokus på å tilby presentasjon av pasientdata. En 

spennende mulighet kunne ha vært å kombinere lokasjon med automatisk uthenting av 

pasientdata. Altså at sykepleiere og leger ved å plassere seg ved senga får lastet inn journalen 

til personen under dyna. En slik mulighet vil imidlertid kreve atskillig større presisjon i 

sporinga av terminalene enn hva vi har i dag. 

6.3.8 Manuell overstyring av lokasjon 

Når det gjelder manglende presisjon, kan det være en idé å legge inn ytterligere muligheter for 

å overstyre den automatiske lokasjonen. I den nåværende løsninga kan brukerne korrigere 

posisjon ved å velge fra en liste over rom. En videreutvikling kan være å legge inn noen 

”hjelpemidler” for å gjøre overstyring mer halvautomatisk. For eksempel kan ID-/ 

nøkkelkortene til brukerne bli utstyrt med radiobrikker (RFID), som blir avlest ved passering 

av enkelte viktige punkter. 

Hva som skal være et slikt fysisk punkt vil være et emne for diskusjon, men om hver 

pasientseng får sin egen avleser av brikker, vil problemet i foregående punkt bli løst. Der det 

ikke er viktig å vite eksakt posisjon i rommet vil GeoPos kunne være tilstrekkelig. 

- 43 -


6.3.9 Opptatt-problematikk 

Vi kan tenke oss at enkelte kan misbruke muligheten til manuelt å angi sin egen 

tilgjengelighet gjennom å velge ”opptatt” når man strengt talt bør kunne forstyrres. En mulig 

løsning kan være å legge til en ”merkelapp” som forteller om når tilgjengeligheten sist ble 

oppdatert og om det skjedde automatisk ved forflytting eller manuelt. Dette kan gi en 

pekepinn på om kollegaen egentlig kan forstyrres. I tillegg kan det være mulig å legge inn 

tidsavbrudd, som automatisk gjør tilgjengeligheten om til ”ledig”. 

6.3.10 Kombinere forskjellige nettverkstyper 

Vi valgte å bruke WLAN til å sende og motta data samt ikke minst å lokalisere terminalene. 

Det ville ha vært interessant å kunne kombinere flere typer databærere med innebygd 

lokasjon. Med tanke på at vi benyttet mobiltelefoner som terminaler, ville det ha vært naturlig 

i tillegg å implementere lokasjon i GSM/UMTS for å utvide mulighetene rent geografisk. 

Både Telenor og Netcom tilbyr slike tjenester. Da all data fra og til klientsiden blir lest i 

vanlig nettlesere, kan GPRS allerede problemfritt brukes som databærer i mobiltelefonene. 

Utfordringa er altså lokasjonsdelen. Vi kunne også ha valgt å bruke WLAN eller GPRS bare 

som databærer, og brukt en annen teknologi til lokalisering. Ultralyd er i så fall et 

nærliggende alternativ. 

6.3.11 Kalender 

I utgangspunktet er tilgjengeligheten til alle brukerne satt som ”ledig”. Opphold i enkelte rom 

gjør setter tilgjengeligheten automatisk om til ”opptatt”, men brukerne har mulighet til å 

overstyre til enhver tid. En forenkling for brukerne vil være at tilgjengeligheten automatisk 

blir oppdatert i henhold til møter og avtaler i kalenderne til brukerne. Det er trolig at 

Doctector forholdsvis enkelt kan kunne kombineres med allerede eksisterende 

kalenderløsninger. En naturlig utfordring i den forbindelse er at mange leger i stor utstrekning 

fortsatt bare bruker papirløsninger. 

6.3.12 PC-utgave 

Fordi Doctector er utviklet til bruk på mobiltelefoner er alle skjermbilder tilpasset dertil. En 

nettleser er likevel en nettleser, og løsningen fungerer godt også på vanlige PC-er med 

WLAN. Det er likevel ønskelig å lage en alternativ utgave til bruk på større skjermer for 

bedre å utnytte mulighetene disse gir. Spesielt skriving og lesing av meldinger gjøres enklere 

på PC med vanlig tastatur. 

- 44 -


6.3.13 IP-telefoni 

Den nåværende løsningen for telefoni mellom kolleger er basert på WML-linker som initierer 

den innebygde standard-ringefunksjonen i ordinære mobiltelefoner. Dermed skjer både 

oppringing og mottak av samtaler uavhengig av Doctector over GSM-/UMTS-nettet. Dette er 

en god universalløsning ettersom alle mobiltelefoner dermed kan bli brukt som terminal. 

En mulig videreutvikling vil være å implementere ”voice over IP” gjennom for eksempel SIPprotokollen. 

Dermed vil også bruk av Doctector på vanlige PC-er være trivelt. Utfordringen 

blir at bare de mer avanserte mobiltelefonene støtter ekte VoIP. En løsning kan være å enten 

automatisk eller manuelt å angi hvilken type terminal som blir benyttet, og tilby bare støttede 

tjenester. For eldre terminaler vil det i så fall innebære fortsatt bruk av den nåværende løsning 

for telefoni. 

- 45 -


7. Litteraturliste 

Ammenwerth, E. E., Buchauer, A. A., Bludau, B. B. & Haux, R. R. (2000). Mobile 

information and communication tools in the hospital. International journal of medical 

informatics, 57 (1): 21-40 

Andresen, S. H. (2007). Kompendium i emnet TTM4130 Nettintelligens og mobilitet (versjon 

2.3). Trondheim: Kompendium ved NTNU. Institutt for telematikk. 

Bardram, J.E. & Bossen, C. (2005). Mobility Work: The Spatial Dimension of 

Collaboration at a Hospital. Computer Supported Cooperative Work (CSCW), 14 (2): 131-160 

Bardram, J. E. og Hansen, Thomas R. (2004): The AWARE Architecture: Supporting Context- 

Mediated Social Awareness in Mobile Cooperation. Centre for Pervasive Healthcare 

Depar tment of Computer Science, University of Aarhus. 

Buvik. Eirill Pettersen (2008): Pasientsamhandling og mobile løsninger. Presentasjon for 

Landsby 20, Eksperter i Team 20.02.2008 

Dahl, Yngve (2007): Ubiquitous computing at point of care in hospitals: A User-centered 

Approach, Doctoral Theses at NTNU, 2007:147. Department of Computer and Information 

Science. 

Dey, A.K and Abowd, G.D (1999): Towards a better understanding of Context and 

Context-Awareness, GVT Technical Report, GIT-GVU-99-92, College of Computing 

Georgia Institute of Technology. 

Eisenstadt, S. S. A., Wagner, M. M. M., Hogan, W. W. R., Pankaskie, M. M. C., Tsui, F. F. 

C. & Wilbright, W. W. (1998). Mobile workers in healthcare and their information needs: are 

2- way pagers the answer? Proceedings: 135-9. Center for Biomedical Informatics, University 

of Pittsburgh School of Medicine. Information Services Division, UPMC Health System 

Evjemo, B., Stenvold, L.A., Akselsen, S., Brede, S. og Rafelsen, T. (2005). Opplev 

Erkebispegården med mobilen! Lokasjonsbasert musemsguide på 3G-nettet. Telenor 

forskningsrapport R 41/2005. 

Forthun, M. (2003): Group Communication for healthcare workers designed in ServiceFrame, 

Prosjektoppgave, Institutt for elektronikk og telekommunikasjon, NTNU, Trondheim 

Gallis, H. E. & Kasbo, J. P. (2002). Walking away from the PDA. Masteroppgave, 

institutt for informatikk, Universitetet i Oslo, Oslo 

Gopher, D., Donchin, Y., Olin, M., Badihi, Y., Biesky, M., Sprung, C. L., Pizov, R. & 

Cotev, S. (2003). A look into the nature and causes of human errors in the intensive care 

unit*. Quality & safety in health care, 12 (2): 143 

Holm Pettersen, Christina, Asmussen, Marete & Willemann, Marlene (2005): 

Sygeplejerskers fagidentitet og arbejdsopgaver på medicinske afdelinger. DSI Institutt 

for Sundhedsvæsen, DSI rapport, 2006:8 

- 46 -


Karlsen, E-B (2004): Hensiktsmessig bruk av IKT i den kommunale hjemmetjenesten, 

Prosjektoppgave, Institutt for elektronikk og telekommunikasjon, NTNU, Trondheim 

Knudsen, Pål V. (2004): ”Bruk av mobile enheter for kommunikasjon på sykehus”. 

Masteroppgave, Institutt for Informatikk, UiO. 

Kristoffersen, S. & Ljungberg, F. (1999). Designing Interaction Styles for a Mobile Use 

Context. I: vol. 1707 / 1999 Handheld and Ubiquitous Computing: First International 

Symposium, HUC'99, Karlsruhe, Germany, September 1999. Proceedings, Springer Berlin / 

Heidelberg. 

Langdridge, D. (2004). Introduction to Research Methods and Data Analysis in 

Psychology. Pearson Education Limited 

Linell, Per & Luckmann, Thomas (1991): “Asymmetries in dialogue: some conceptual 

preliminaries”. I: Markova, Ivana Foppa, Klaus (eds.): Asymmetries in dialogue. Hemel 

Hempstead: Harvester Wheatsheaf, s. 1-20 

Svennevig, Jan (2001): Språklig kommunikasjon. Innføring i kommunikasjonsteori og 

diskursanalyse. Oslo: Cappelen Akademiske Forlag 

Sægrov, A. (2008): Cordis RadioEye. Lokalisert 06.05.2008 på World Wide Web: 

http://www.radionor.no . 

Vagle, Wenche, Sandvik, Margareth & Svennevig, Jan (2004): Tekst og kontekst. En 

innføring i tekstlingvistikk og pragmatikk. Bergen: J.W. Cappelens Forlag 

Valmot, O. (2003): Radioøyet ser deg. Teknisk Ukeblad 31/2003. 

Wagner, I. (1993). Caught in a Web of Fuzzy Problems. Confronting the Ethical Issues in 

Systems Design. Communications of the ACM 36/4, pp. 94-101. 

Wangsteen, A. B. (2006). Bokmålsordboka. Lokalisert 15.04.2008 på World Wide Web: 

http://www.dokpro.uio.no/perl/ordboksoek/ordbok.cgi?OPP=mobilitet&bokmaal=S%F8k+i+ 

Bokm%E5lsordboka&ordbok=bokmaal&alfabet=n&renset=j. 

- 47 -


Appendiks A 

Språkhandlingsteori 

Språkhandlingsteori legger et funksjonelt perspektiv på språk ved at man ser på ytringer som 

språkhandlinger. Den har som formål å beskrive mer avgrensede bruksenheter (Vagle et al. 

2004). Selv om det blir for upresist å si at en språkhandling er det vi gjør når vi kommer med 

en ytring, er det likevel dette vi gjør, bare litt mer avansert. Vi refererer til forhold i 

virkeligheten og ”(…) ytringene er avhengig av en helt spesifikk kontekstuell ramme for å 

virke etter hensikten” (Vagle, Sandvik og Svennevig 2004:86). Det finnes flere betingelser for 

at en språkhandling skal kunne kalles vellykket, altså at den er utført, forstått og respondert. 

En betingelse viser til at handlingen må utrykkes i en språklig ytring slik at både sender og 

mottakere må forstå den. ”Andre betingelser spesifiserer de kontekstuelle forutsetningene som 

gjør språkhandlingen relevant” (Vagle et al. 2004:88). Dette er fordrende betingelser, som vil 

si at de forutsetter at språkhandlingen har betydning i situasjonen, eksempelvis vil en 

sykepleier se på ordre fra en lege som en ordre, noe som skal utføres, fremfor en anmodning. 

Dette har å gjøre med den institusjonaliserte autoritetsposisjonen legen har ovenfor 

sykepleieren. Til slutt kan vi nevne den betingelsen som stiller krav til at senderen må 

intendere at ytringen skal gjelde som en gitt handling (Vagle et al. 2004). Searle (i Vagle et al. 

2004) har satt opp fem ulike klasser av språkhandlinger. Det er ikke slik at det finnes en liste 

over hvilke illokusjonære handlinger (”Dette er standardiserte handlingstyper som 

språkbrukerne har et visst forråd av og som de søker å gjenkjenne i hverandres ytringer” 

(Vagle et al. 2004:86) som finnes, men man har prøvd å lage noen grunnleggende klasser som 

man kan kategorisere språkhandlingene etter. 

Den første gruppen av språkhandlinger kalles konstantiver. Ytringene som realiserer denne 

språkhandlingstypen er som regel utsagnssetninger (Svennevig 2001), og det ligger et krav 

om oppriktighet som vil si at mottakeren må tro at innholdet er sant (Vagle, Sandvik og 

Svennevig 2004). Denne klassen inkluderer handlinger som å informere, å fortelle, å påstå, å 

gjengi, å forklare. 

Den neste gruppen av språkhandlinger kalles direktiver. Disse ytringene har som hensikt å 

fremkalle en handling hos mottakeren. Her ligger det et gyldighetskrav om legitimitet. Denne 

- 48 -


klassen inkluderer handlinger som å be (om noe), beordre, anmode og kreve. I tillegg kan det 

godt være ting som er i vedkommendes interesse å gjøre, som å invitere, å råde (noen til noe) 

og å tillate. Spørsmål er også eksempler på handlinger innenfor denne gruppen av 

språkhandlinger, fordi man med spørsmål kan prøve å få adressaten til å gjøre noe. Direktiver 

forutsetter en framtidig handling, og den fremsettes som ønskelig, gjerne i form av 

spørresetninger eller imperativsetninger (Vagle, Sandvik og Svennevig 2004, Svennevig 

2001). 

Den tredje gruppen av språkhandlinger kalles kommissiver. Dette er språkhandlinger hvor 

taleren selv forplikter seg til å gjøre noe, som regel en fremtidig handling (Svennevig 2001). I 

følge Vagle, Sandvik og Svennevig (2004) ligger noen språkhandlinger i grenseland mellom 

direktiver og kommisiver fordi de forutsetter en gjensidig forpliktelse hos sender og mottaker. 

Forskjellen ligger her på at ”Direktivene forutsetter et ønske (om at handlingen skal bli utført), 

mens kommissivene forutsetter at senderen har en viss hensikt (nemlig å utføre handlingen) 

(Vagle, Sandvik og Svennevig 2004:90). 

Neste gruppe av språkhandlinger kalles ekspressiver, hvor hovedintensjonen er å uttrykke en 

psykologisk tilstand. Eksempler på slike språkhandlinger er å gratulere, å unnskylde seg, å 

fordømme, å gi komplimenter og å ønske noen lykke til (Vagle, Sandvik og Svennevig 2004). 

De uttrykkes gjerne i setningsemner og særegne setningstyper, samt gjennom ønskesetninger 

og konjunktiver (Svennevig 2001). 

Den siste gruppen av språkhandlinger kalles kvalifiseringer. Ytringer innenfor denne klassen 

skaper en ny virkelighet, og disse er gjerne også knyttet til institusjonelle sammenhenger. Her 

ligger det et krav om legitimitet. Eksempler på dette er domsavsigelser, ekteskapsløfter og 

offisielle erklæringer av forskjellig slag (Vagle, Sandvik og Svennevig 2004). Til slutt er det 

vesentlig å nevne at ”Språkhandlingsfunksjonene er (…) avhengig av kontekst, og er ikke 

kodet direkte inn i betydningen av ord og setninger” (Svennevig 2001:63). 

- 49 -


Appendiks B 

Arkitektur 

Det følgende avsnittet inneholder en beskrivelse av det overordnede designet for systemet. 

Det tar for seg hvordan de ulike delene av systemet kommuniserer sammen, og hvilke 

teknologier som ligger til grunn for funskjonaliteten systemet tilbyr. Her følger en beskrivelse 

av de valgene vi har tatt, begrunnelser for disse valgene følger i senere avsnitt. 

Figur 1: Overordnet arkitektur 

Figur 1 beskriver den overordnede arkitekturen for systemet. Om en begynner ytterst til høyre 

i figuren, ser en de mobile enheter som helsepersonellet bærer med seg til enhver tid. Disse 

enhetene har mulighet til å aksessere internett sider som presenterer lokasjon og 

tilgjengelighet for enhver person som er registert i systemet. Denne aksessen skjer gjennom 

WLAN. 

- 50 -


Internettsidene blir genrert av en HTTP server som kjører på samme maskin som Doctectorserveren. 

HTTP serveren kjører Apache, og Tomcat for å generere HMTL sider fra PHP. 

HTTP serveren puller data fra Serveren. Dette skjer fordi hver Doctector-klient automatisk 

oppdaterer sin internettside hvert femte sekund. Overføringen av data muliggjøres av servlets 

og RMI. Serveren oppretter en RMI server, som HTTP serveren kobler seg opp i mot for å få 

tak i de ønskede objekter. 

Ved oppstart av Doctector serveren, leses en liste over registerte personer og rom fra 

databasen. Sammen med hver person som er regisrert i databasen ligger det en MAC-adresse. 

To ganger i minuttet henter Doctector serveren ut lokasjonsinformasjon for de registerte 

MAC-adressene. Dette muliggjøres av at serverene kommuniserer ved hjelp av XML. For 

hver MAC-adresse returneres det en XML som inneholder lokasjon representert ved X- og 

Y- koordinater. Doctector serveren transformerer disse koordinatene til hvilket rom MAC'en 

befinner seg i. Data som blir generert mens Doctector serveren kjører, blir ikke propagert til 

databasen. 

Figur 2: Sekvensdiagram for pålogging Doctector 

- 51 -


Figur 2 beskriver hva som foregår når en bruker logger på systemet med et tidligere tildelt 

brukernavn. Doctector registrer brukernavnet sammen med IP-en forespørselen kommer ifra i 

personList, en liste over personer registrert i systemet. Når Doctector har oppdatert 

personList, returnerer den det Person-objektet som korresponderer til det gitte brukernavnet. 

Dette Person-objektet inneholder informasjon som navn, rolle, lokasjon, tilgjengelighet osv. 

Dersom en bruker foretar endringer som f. eks. å endre tilgjengelighet eller lokasjon, 

oppdateres dette person-objektet, og sendes tibake til Doctector, som igjen legger dette 

objektet 

inn i sin personList. 

Figur 3: Sekvensdiagram 1 

- 52 -


Figur 3 beskriver kommunikasjonen mellom GeoPos, Doctector og en mobil enhet ved 

innhenting av lokasjon Hvert 30. sekund henter Doctector inn informasjon om lokasjonen for 

hver av de enhentene som ligger i databasen. Denne lokasjonsinformasjonen representeres 

ikke i databasen, men i den kjørende instansen av Doctector. Doctector regner om 

koordinatene den mottar fra GeoPos til rom, i henhold til de data som er oppgitt i databasen. 

Hver persons tilgjengelighet blir oppdatert i henhold til lokasjon, basert på den 

tilgjengeligheten hvert rom har i databasen. Dersom en person har angitt en tilgjengelighet 

manuelt, overstyrer dette den automatiske tilgjengeligheten. Doctector har mulighet for å 

legge inn en begrensing på hvor lenge en person kan ha satt manuell tilgjengelighet, for å 

forhindre misbruk av dette systemet. 

Hvert 5. sekund oppdaterer de mobile enhetene webgrensesnittet mot Doctector, og lokasjonog 

tilgjengelighets-informasjonen blir da presentert i grensesnittet til brukeren. 

- 53 -


Figur 4: Sekvensdiagram for meldinger 

Figur 2 viser sekvensforløpet ved meldinger. En klient ønsker å sende en melding til en annen 

klient. Den første klienten skriver meldingen, velger mottaker fra en liste av personer, og 

velger "send". Doctector mottar meldingen, generer en messageHeader for meldingen, og 

lagrer begge i databasen. Hver 5. sekund sjekker alle klienter etter meldinger. Mottaker av 

meldingen vil i dette tilfelle motta en ny messageHeader, som indikerer en ny melding. 

Dersom mottaken velger å lese meldingen, blir hele meldingen hentet fra Doctector serveren, 

og headeren blir markert som lest. 

- 54 -


Doctector er bygd opp på en slik måte at en brukers opplevelse blir avhengig av enhet. Hver 

MAC-adresse hvis lokasjon skal registeres, er lagt manuelt inn i databasen. Når en person 

logger på med brukernavn, blir dens IP registrert opp mot brukernavnet. På denne måten 

fungerer brukergrensesnittet og lokasjonsfunksjonaliteten uavhengig av hverandre. En person 

har nå ikke mulighet til å endre enhet, uten at MAC-adressen til enheten oppdateres manuelt i 

databasen. 

- 55 -

Rapport - NTNU

Create successful ePaper yourself

Delete template?

Save as template?