Verktyg för kostnadsberäkning av röntgenundersökningar

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Verktyg för kostnadsberäkning av

röntgenundersökningar

Gabriel Jonsson

LIU-IDA/LITH-EX-A--11/012--SE

2011-04-14

Linköpings universitet Institutionen för datavetenskap

Examensarbete

Verktyg för kostnadsberäkning av

röntgenundersökningar

Gabriel Jonsson

LIU-IDA/LITH-EX-A--11/012--SE

2011-04-14

Handledare: Johan Åberg, IDA, Linköpings Universitet Per Bankvall, Sectra Sverige AB

Mattias Nylen, Sectra Sverige AB

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga

extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,

skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för

ickekommersiell forskning och för undervisning. Överföring av upphovsrätten

vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av

dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,

säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ

art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i

den omfattning som god sed kräver vid användning av dokumentet på ovan

beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan

form eller i sådant sammanhang som är kränkande för upphovsmannens litterära

eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se

förlagets hemsida

Sammanfattning

En viktig del i verksamhetsstyrningen vid en röntgenklinik är att sätta priser på de undersökningar man erbjuder, ett problem man jobbat med på olika sätt genom tiderna. MedEko var ett gammalt verktyg, utvecklat på 90-talet, som löste det här problemet men som av olika anledningar inte längre går att använda. Sectra utvecklar och säljer IT-system till röntgenkliniker och ser ett behov av att för vissa kunder erbjuda en mer avancerad typ av verksamhetsstödjande tjänster. Det här examensarbetet har varit en del av en förstudie för att utreda om ett verktyg motsvarande MedEko passar in i den kategorin.

Syftet med projektet har varit att kartlägga och utvärdera MedEko:s värden och funktionalitet, realisera de mest tydliga värdena i en prototyp och slutligen validera dem mot tre av Sectras kunder med målsättningen att bilda en uppfattning om intresset för den här typen av verktyg.

Två övergripande värden har identierats och verierats. Det primära värdet är att få fram detaljerad kostnadsinformation för specika under-sökningar baserat på verksamhetens bentliga produktionsfaktorer. Det gör det möjligt att veriera att de priser man sätter på undersökningar speglar självkostnaden, vilket är speciellt viktigt i samband med upphandlingar där konkurrensen är hård och priserna spelar en viktig roll. Ett annat tydligt vär-de är möjligheten att simulera förändringar i produktionen och analysera vär-de ekonomiska eekterna. Det kan t ex användas för att motivera investeringar eller omfördelningar av resurser.

Den beräkningsmodell som ligger till grund för MedEko och som även an-vänds i prototypen kräver ett komplext dataunderlag som till stor del består av klinikspecik produktionsdata som beskriver undersökningars förbruk-ning av olika resurser. Intresset för en potentiell produkt är starkt kopplat till hur pass enkel och eektiv insamlingen av detta dataunderlag kan göras och hur väl det stämmer överens med verkligheten.

Abstract

An important part of operating a radiology department is to establish prices of the examinations. This is a problem that has been dealt with in dierent ways throughout history. MedEko was a desktop application, developed during the mid 90s, that helped solving this problem. For dierent reasons it is no longer usable. Sectra develop IT systems for radiology departments and for some of their customers they see a growing need to oer a more advanced type of business supporting services. This project is part of a pilot study to determine if a tool that corresponds to MedEko could t into this category.

The objective of the project was to identify the values and functionality of MedEko, implement the most distinct values in a Mixed Fidelity Prototype and nally validate these values against three customers of Sectra. The aim was to obtain a general opinion about the interest in a tool of this kind.

Two overall values were identied and veried. The primary value is to get detailed information about the costs of specic examinations based on the current production factors. This makes it possible to verify that the prices reects the actual cost of each examination, which is particularly important in public procurements where competition is tough and prices have a big impact. Another clear value is the ability to simulate changes in the production and analyze the economic eects on the business.

The calculation procedures, which form the foundation of both MedEko and the prototype developed in this project, requires a comprehensive set of production data. This data contains detailed information about the con-sumption of dierent resources for each examination. The overall interest in a potential product of this kind is strongly coupled to its ability to deliver this data in an ecient way.

Innehåll

1 Inledning 1

1.1 Introduktion . . . 1

1.2 Syfte och målsättning . . . 1

1.2.1 Förstudie . . . 1

1.2.2 Prototyputveckling . . . 2

1.2.3 Validering . . . 2

1.3 Problemställning . . . 2

1.4 Avgränsningar . . . 2

1.5 Diskussion kring källor . . . 3

1.6 Språkbruk . . . 3

1.7 Rapportens disposition . . . 4

2 Bakgrund 5 2.1 Sectra . . . 5

2.1.1 Samarbete med CMIV . . . 5

2.2 Prissättning av röntgenundersökningar . . . 5

2.3 Klassikationskoder för undersökningar . . . 6

2.4 Beräkningsmodellen . . . 6

2.4.1 Identiering av kostnader . . . 6

2.4.2 Fördelning av kostnader på undersökningar och besök 7 2.4.3 Beräkning av direkta kostnader . . . 7

2.4.4 Kostnad för läkare och sjukvårdspersonal . . . 9

2.4.5 Lokalkostnader . . . 10

2.4.6 Apparatkostnad . . . 10

2.4.7 Beräkning av indirekta kostnader . . . 11

3 Metodteori 12 3.1 Kvalitativa intervjuer . . . 12

3.1.1 Semistrukturerade Intervjuer . . . 12

3.1.2 Fokusgrupper . . . 13

3.2 Provisional Personas och Scenarion . . . 13

3.2.1 Personas . . . 13

3.2.3 Scenarion . . . 14 3.3 Prototyper . . . 14 3.3.1 Low-Fidelity Prototypes . . . 14 3.3.2 High-Fidelity Prototypes . . . 15 3.3.3 Mixed-Fidelity Prototypes . . . 15 3.4 Mental Models . . . 16 4 Förstudie 17 4.1 Metod . . . 17 4.1.1 Studiebesök . . . 17 4.1.2 Intervjuer . . . 17 4.1.3 Litteraturstudie . . . 19 4.1.4 Funktionsanalys av MedEko . . . 19

4.1.5 Beräkningsteknisk prototyp i Excel . . . 19

4.1.6 Kick-o . . . 20

4.1.7 Möte med beställare . . . 20

4.1.8 Använding av Provisional Personas och Scenarion . . . 20

4.2 Resultat . . . 21

4.2.1 Presentation av MedEko . . . 21

4.2.2 Identierade värden . . . 23

4.2.3 Förbättringsområden . . . 24

4.2.4 Inriktning och avgränsningar för prototyputveckling . 25 4.3 Resultatdiskussion . . . 26

4.3.1 Personor och Scenarion . . . 26

5 Utveckling av Prototyp 28 5.1 Metod . . . 28 5.1.1 Agil utveckling . . . 28 5.1.2 Pappersprototyper . . . 28 5.1.3 Teknisk plattform . . . 29 5.2 Resultat . . . 29 5.2.1 Avgränsad funktionalitet . . . 29 5.2.2 Implementerad Funktionalitet . . . 30 5.2.3 Dataunderlag i prototypen . . . 34 5.2.4 Konceptuell datamodell . . . 35 5.2.5 Beräkningsprinciper . . . 36 5.3 Resultatdiskussion . . . 37 5.3.1 Flexibel beräkningsmodell . . . 37

5.3.2 Exportera prislista till Excel . . . 37

5.3.3 Denition av slutgiltig prototyp . . . 37

6 Utvärdering och validering 40

6.1 Metod . . . 40

6.1.1 Planeringsmöte . . . 40

6.1.2 Möte med kunder . . . 41

6.2 Resultat . . . 42

6.2.1 Intresse och behov . . . 42

6.2.2 Koncept och funktionalitet . . . 43

6.2.3 Sammanfattning av resultat . . . 44

6.3 Resultatdiskussion . . . 45

6.3.1 Potential för vidareutveckling . . . 45

6.3.2 Revidering av personor och scenarion . . . 46

7 Diskussion 47 7.1 Vidareutveckling . . . 47

7.1.1 Direkta kostnader . . . 47

7.1.2 Insamling av dataunderlag . . . 47

7.1.3 Ändrade förutsättningar för materialkostnader . . . . 48

7.1.4 En webbaserad referensdatabas . . . 48

7.1.5 Internationellt perspektiv . . . 49

8 Slutsats 50 A Appendix 54 A.1 Primary Provisional Persona . . . 55

Figurer

2.1 Den direkta kostnaden för två undersökningar kan variera kraftigt beroende på dess utnyttjande av olika resurser. (Käl-la: SPRI-rapport 299) . . . 8 2.2 Den indirekta kostnaden utgör ett baspris för ett patientbesök

och utgör i praktiken ett tillägg på priset för primärundersök-ningen. (Källa: SPRI-rapport 299) . . . 9 5.1 Skärmdump från prototypen som visar arbetsytan

Undersök-ningar . . . 31 5.2 Skärmdump från prototypen som visar arbetsytan Resurser . 32 5.3 Skärmdump från den slutgiltiga prototypen som visar

arbet-sytan Övriga Kostnader . . . 33 5.4 Skärmdump från den slutgiltiga prototypen som visar

arbet-sytan Prislista . . . 34 5.5 Konceptuell datamodell i form av ett ER-diagram för de

Förord

Det våras för exjobbaren. Vintern har nyligen släppt sitt hårda grepp och jag börjar på allvar tro på en varm och solig sommar. Även det här examensarbe-tet går mot sitt slut och det är med viss lättnad jag skriver de sista raderna på rapporten. Det har varit en spännande och lärorik tid som exjobbare på Sectra och jag tar med mig många nyttiga erfarenheter och trevliga minnen när jag nu ska ta steget ut i arbetslivet.

Till att börja med vill jag tacka Johan Åberg för god handledning genom ett aktivt engagemang och snabb respons på frågor. Tack Per Bankvall och Mattias Nylen, mina handledare på Sectra, för hjälp och inspiration, givande diskussioner och vägledning under arbetets gång. Jag vill även tacka resten av alla medarbetare på Sectra för er hjälpsamhet, trevliga karaster och ett allmänt varmt bemötande. Slutligen vill jag rikta ett tack till alla som ställt upp på intervjuer eller på annat sätt bidragit till arbetets genomförande.

Gabriel Jonsson Tranås, 2011-04-13

Kapitel 1

Inledning

1.1 Introduktion

Vad är det egentligen som utgör kostnaden för en röntgenundersökning och hur kan man avgöra om det pris man sätter på en undersökning speglar den faktiska kostnaden?

MedEko är ett gammalt verktyg som hjälpte till att ge svar på just de här frågorna. Det utvecklades under 90-talet och nådde en stor skara användare. Av olika anledningar har det inte vidareutvecklats eller uppdaterats och idag är det inte längre möjligt att använda.

Sectra är ett företag som utvecklar och säljer IT-system för röntgenklini-ker. De ser framför sig ett ökat behov av att för vissa av sina kunder erbjuda en mer avancerad nivå av verksamhetsstödjande tjänster. Ett verktyg av den typ som MedEko är skulle kunna passa in i den kategorin.

1.2 Syfte och målsättning

Syftet med det här examensarbetet har varit att utvärdera nyttan i MedEko, realisera en del av dess tydligare värden i en prototyp och slutligen validera prototypen mot några av Sectras kunder. Arbetet delades därför upp i tre faser: förstudie, prototyputveckling och validering.

Resultatet förväntas ge en uppfattning om huruvida det hos Sectras kun-der nns ett behov av ett verktyg motsvarande MedEko, samt vilka möjlig-heter Sectra har att tillfredsställa ett sådant behov.

1.2.1 Förstudie

Förstudiefasen syftade till att kartlägga och utvärdera MedEko:s värden och funktionalitet. Den förväntas ge svar på frågor som:

• Vilka styrkor och svagheter hade verktyget?

• Fanns det någon funktionalitet som saknades eller var överödig? • Vad kan göras bättre eller annorlunda?

1.2.2 Prototyputveckling

Målsättningen med utvecklingsfasen var att bygga en prototyp som realiserar en del av de värden och koncept som identierades under förstudien. Syftet var att göra det möjligt att demonstrera dem för potentiella slutanvändare och för olika intressenter inom Sectra.

1.2.3 Validering

Syftet med valideringsfasen var att presentera och demonstrera prototypen för några av Sectras bentliga kunder och därigenom bilda en uppfattning om intresset för och behovet av den här typen av verktyg.

1.3 Problemställning

Rapporten förväntas ge svar på följande övergripande frågeställningar: • Vilka problem löste MedEko och i vilken utsträckning är de aktuella

idag?

• Tillför en applikation som motsvarar en modern version av MedEko något värde i samband med verksamhetsplanering på en röntgenavdel-ning i nutid?

• Vilka möjligheter nns det att integrera en applikation som motsvarar MedEko med Sectras bentliga informationssystem och vilka värden medför det?

1.4 Avgränsningar

På grund av den begränsade tidsomfattningen för examensarbetet, 20 veckor, gjordes ett antal begränsningar i vilken funktionalitet som implementerades i prototypen. Detaljer om vilka avgränsningar som gjordes redovisas och motiveras i kapitel 5.

En målsättning med arbetet var att undersöka möjligheterna att inte-grera verktyget med Sectras bentliga informationssystem. Arbetet påvisar vilken information som är önskvärd att hämta från dessa system. För att avgöra tillgänligheten av denna information krävs en djupare analys av da-tabaserna i de bentliga systemen och den ryms ej inom ramen för det här

examensarbetet. Information om hur denna analys kan angripas framgår i diskussionsdelen (kapitel 7).

Examensarbetet omfattar inte någon utvärdering av den beräkningsmo-dell som ligger till grund för MedEko och som används i prototypen som utvecklats. Förutsättningen för arbetet var att använda samma beräknings-principer som används i MedEko.

1.5 Diskussion kring källor

Resultatet av valideringsfasen som presenteras i avsnitt 6.2 baseras på samtal med tre av Sectras kunder (totalt fem personer). Det är en liten delmängd av alla potentiella slutanvändare och syftet med valideringen är att ge en initial uppfattning om intresset för och behovet av den typ av verktyg som prototypen realiserar. Resultatet är därför inte tillräckligt för att dra några denitiva slutsatser om aärsmässiga potentialer i de koncept som ingår i prototypen.

1.6 Språkbruk

Här följer en förlaring till vissa förkortningar och facktermer som är vanligt förekommande inom problemområdet och som även förekommer i rapporten:

• RIS

Radiology Information System. Informationssystem som hanterar ad-ministrativ data kring röntgenundersökningar som patientinformation, remisser, tidbokning och rapportering.

• PACS

Picture Archiving and Communication System. Informationssystem som hanterar lagring, åtkomst, distribution och presentation av di-gitala röntgenbilder.

• SPRI

Sjukvårdens och Socialvårdens Planerings- och Rationaliseringsinsti-tut. Bildades av staten och sjukvårdshuvudmännen 1968 och lades ned år 2000. [6]

• CMIV

Center for Medical Imaging and Visualization. Ett forskningscenter i Linköping som bedriver forskning inom medicinsk bildbehandling och visualisering.

• Modalitet

Samlingsnamn för utrustning som används för att generera röntgenbil-der.

• us

En förkortning av ordet undersökning som förekommer på vissa ställen i rapporten.

1.7 Rapportens disposition

1. Inledning

Här presenteras syftet och målsättningen med arbetet och vilka fråge-ställningar som rapporten förväntas ge svar på. Dessutom innehåller kapitlet en diskussion kring källor och vilka avgränsningar som gjorts. Slutligen presenteras rapportens disposition.

2. Bakgrund

Det här kapitlet presenterar grundläggande teori kopplat till problem-området. Här ges även en övergripande presentation av den beräknings-modell som ligger bakom MedEko och som utgör grunden för detta projekt. Syftar är primärt att förklara viktiga begrepp och beräknings-principer.

3. Metodteori

Här presenteras teorin för de metoder som använts projektet. 4. Förstudie

Det här kapitlet innehåller en beskrivning av hur förstudien genom-fördes och vilka resultat den frambringade. Kapitlet avslutas med en resultatdiskussion.

5. Utveckling av prototyp

Det här kapitlet beskriver utvecklingen av prototypen, hur metoderna tillämpades och tekniska detaljer kring implementationen. Här presen-teras även vilka avgränsningar som gjordes och hur den resulterande prototypen ser ut och fungerar. Slutligen diskuteras resultatet utifrån teorin för Mixed Fidelity Prototype.

6. Validering

Här beskrivs hur prototypen validerades mot ett antal av Sectras kun-der och vilka resultatet som frambringades. Den avslutande resultatdis-kussionen behandlar de frågeställningar och målsättningar som sattes upp i planeringen av valideringsfasen.

7. Diskussion

Det avslutande diskussionskapitlet behandlar primärt framtida arbete och vilka möjligheter det nns till vidareutveckling av projektet. 8. Slutsats

Här dras ett antal slutsatser som återkopplar till de övergripande frå-geställningar som sattes upp i inledningskapitlet.

Kapitel 2

Bakgrund

Det här kapitlet syftar till att ge läsaren en grundläggande förståelse för problemområdet.

2.1 Sectra

Sectra är ett företag som utvecklar och säljer medicinska IT-system. Deras kärnprodukter, RIS och PACS, bildar tillsammans en omfattande lösning för hantering av röntgenundersökningar.

"Idag används Sectras medicinska produkter av mer än 1100 sjukhus runt om i världen och cirka 52 miljoner röntgenundersökningar diagnostiseras i Sectras system varje år" [15].

Sectra har totalt ca 650 anställda (varav ca 400 i Sverige) med kontor i 12 länder. Huvudkontoret ligger i Linköping.

2.1.1 Samarbete med CMIV

Sectra har sedan en lång tid tillbaka samarbetat med CMIV vid Universi-tetssjukhuset i Linköping. Chefen för CMIV, Anders Persson, har tidigare arbetat som verksamhetschef för en röntgenklinik och är upphovsman till ekonomiapplikationen MedEko. Anders har sedan länge slutat underhålla applikationen och idag är den inte längre användbar. Anders påstår sig dock fortfarande uppleva en efterfrågan men eftersom han själv inte har möjlighet att möta den har han gett Sectra fria händer att överta projektet.

2.2 Prissättning av röntgenundersökningar

I Sveriges har klinikerna inom den oentliga sjukvården sedan en lång tid varit direktnansierade under ledning av Landstingen. Det innebär att man på kliniknivå ansvarar för att verksamhetens intäkter täcker kostnaderna. Ansvaret för att detta uppfylls faller ytterst på klinikchefen. [3]

Vid en röntgenklinik är produkten man säljer röntgenundersökningar och kunderna är i huvudsak olika typer av remitterande kliniker. En viktig del i verksamhetsplaneringen är att sätta priser på de undersökningar man er-bjuder . [3]

I januari 1991 publicerades SPRI-rapport 299: Beräkning av kostnader för radiologiska åtgärder [8]. Den beskriver en metod för att beräkna kost-nader för röntgenundersökningar i samband med prissättning. Den syftade till att ersätta en gammal poängbaserad metod som använts sedan 60-talet vilken innebar grova generaliseringar och snedvridna kostnadsfördelningar [4]. Rapporten inkluderade även en kravspecikation för hur en dataappli-kation skulle utformas för ändamålet, vilket i praktiken var en förutsättning för att kunna använda den nya beräkningsmodellen.

2.3 Klassikationskoder för undersökningar

I Sverige har Socialstyrelsen tagit fram ett klassiceringssystem för röntgen-undersökningar. Varje undersökningstyp klassiceras med en kod bestående av max 6 tecken/positioner. De första tre positionerna anger grundkod och beskriver vilken typ av undersökning det handlar om, t ex konventionell röntgen av lungor. Grundkoden är grupperad efter organ och typ av rönt-gen. Position 4-5 utgör metodkod och används för att ytterligare beskriva hur undersökningen utfördes och i vilket syfte. Oftast ger grundkoden tillräck-lig beskrivning av undersökningen och då anges metodkoden 00. Grundkod och metodkod brukar tillsammans benämnas undersökningskod. Den sjätte positionen kan innehålla en bokstav som utgör en administrativ kod. [17]

Detta klassiceringssystem ger en standardiserad metod för att beskriva undersökningar och används av alla kliniker i hela Sverige. Hur man använder koderna kan dock skilja sig något mellan olika kliniker. [8]

2.4 Beräkningsmodellen

Beräkningsmodellen som ligger till grund för MedEko, och som även använts vid utvecklingen av prototypen i detta projekt, beskrivs utförligt i SPRI-rapport 299 [8]. Detta avsnitt sammanfattar i stora drag beräkningsmodellen som den beskrivs i rapporten och syftar till att ge läsaren en uppfattning om de mest elementära begreppen och beräkningsprinciperna.

2.4.1 Identiering av kostnader

Modellen bygger på att alla kostnader i en verksamhet delas upp i direkta och indirekta kostnader. Direkta kostnader denieras som kostnader för de resurser av vilka åtgången kan mätas per undersökning, [8]. Indirekta kostnader inkluderar alla kostnader som inte har någon logisk förbindelse till

specika undersökningar. Det första steget i beräkningsprocessen är således att identiera verksamhetens direkta respektive indirekta kostnader.

Exempel på direkta kostnader

• Arbetstid för läkare (undersökningstid och granskningstid) • Arbetstid för sjukvårdspersonal i samband med undersökning • Kostnad för undersökningsrum (lokaler och apparater) • Materialkostnader (kontrastvätska, katetrar etc) Exempel på indirekta kostnader

• Administrativa kostnader  Personal

 Lokaler

 Material och data • Overhead-kostnader • Övriga kostnader

2.4.2 Fördelning av kostnader på undersökningar och besök

Direkta kostnader fördelas på alla undersökningar i direkt proportion till re-sursåtgång. Det gör att kostnaden kan variera kraftigt mellan olika typer av undersökningar beroende på hur lång tid det tar att utföra dem, personal-bemanning i labbet, läkarnas granskningtid, materialåtgång osv. Figur 2.1 visar exempel på detta.

Indirekta kostnader summeras och fördelas på totala antalet besök vid kliniken och utgör ett grundpris för ett besök, oavsett hur många och vilken typ av undersökningar man utför. I praktiken läggs den indirekta kostnaden till priset för primärundersökningen vid ett besök (se gur 2.2). Om man endast utför en enkel undersökning med låg direkt kostnad kan den indirekta kostnaden för besöket överstiga den direkta kostnaden.

2.4.3 Beräkning av direkta kostnader

Principen för att beräkna den direkta kostnaden för en undersökning byg-ger på att man specicerar dess förbrukning av resurser. Resurserna består av personal (läkare och sjukvårdspersonal), undersökningsrum (lokaler och apparater) samt olika typer av förbrukningsmaterial. För varje resurs beräk-nas eller anges kostnaden per förbrukad enhet. Den direkta kostnaden för en

Figur 2.1: Den direkta kostnaden för två undersökningar kan variera kraftigt be-roende på dess utnyttjande av olika resurser. (Källa: SPRI-rapport 299)

undersökning beräknas sedan för respektive resurs genom att multiplicera förbrukningsmängden med kostnaden per förbrukad enhet.

All förbrukningsdata samlas i vad som kallas Klinikspecik Lista. Den består av en lista med undersökningskoder för alla de undersökningar man utför vid kliniken. För varje kod anges följande information:

• Antal utförda undersökningar per år

• Undersökningstid för sjukvårdspersonal (min) • Undersökningstid för läkare (min)

• Apparattid (bokad tid i undersökningsrum) (min) • Granskningstid för läkare (min)

Figur 2.2: Den indirekta kostnaden utgör ett baspris för ett patientbesök och utgör i praktiken ett tillägg på priset för primärundersökningen. (Källa: SPRI-rapport 299)

2.4.4 Kostnad för läkare och sjukvårdspersonal

Minutkostnaden beräknas på samma sätt för både läkare och sjukvårdsper-sonal:

minutkostnad = total årlig kostnad_{total årlig arbetstid} (2.1) En uppskattning görs av hur mycket arbetstid som går åt till administrativt arbete och som därmed inte har någon direkt koppling till undersökning-ar. Kostnaden för den administrativa arbetstiden (admin-arbtid) läggs till i kategorin indirekta kostnader.

Den sammanlagda angiva förbrukningstiden för respektive personalkate-gori kallas för registrerad arbetstid (reg-arbtid). Den erhålls genom att för varje undersökning multiplicera antalet undersökningar (antal-us) med sum-man av de angivna förbrukningstiderna. Följande exempel visar denna be-räkningsprincip för personalkategorin Läkare med tidsattributen undersök-ningstid (us-tid) och granskundersök-ningstid.

reg-arbtid =X

antal-us × (us-tid + granskningstid) (2.2) Om man subtraherar den administrativa arbetstiden från den totala arbets-tiden (tot-arbtid) så borde resten bestå av den registrerade arbetsarbets-tiden. Men så är inte fallet. Det blir alltid en dierens som benämns oregistrerad arbetstid

(oreg-arbtid):

oreg-arbtid = tot-arbtid − reg-arbtid − admin-arbtid (2.3) Denna oregistrerade arbetstid utgörs till t ex av väntetider och pauser. Om man utgår från att den skattade administrativa arbetstiden är korrekt borde den oregistrerade tiden vara kopplad till undersökningar. Den fördelas där-för på den registrerade arbetstiden med hjälp av en korrektionsfaktor, som beräknas enligt följande:

korrektionsfaktor = ej registrerad arbetstid_{registrerad arbetstid} (2.4) Den direkta kostnaden för en undersökning beräknas sedan på följande vis för respektive personalkategori:

direkt kostnad = reg-arbtid ×minutkostnad ×(1+ korrektionsfaktor) (2.5)

2.4.5 Lokalkostnader

För att beräkna direkt kostnad för lokalen som en undersökning utförs i måste man först deniera vilka undersökningsrum man har och sedan räkna ut en minutkostnad för var och ett av dem. För att underlätta beräkning-arna får varje undersökningsrum endast innehålla apparater för en typ av undersökningar. Om en lokal har utrustning för att utföra era typer av undersökningar måste den därför delas upp i era ngerade lokaler, en per undersökningstyp.

Vid beräkning av minutkostnad behövs information om i vilket rum varje enskild undersökning utförs. Med hjälp av angiven apparattid för undersök-ningen kan man beräkna en total beläggningstid för varje rum. Minutkostna-den beräknas genom att dividera Minutkostna-den totala hyreskostnaMinutkostna-den för ett rum med dess totala beläggningstid. Den direkta lokalkostnaden för en undersökning får man sedan genom att multiplicera den angivna apparattiden med minut-kostnaden för det rum den utförs i. Därmed kan minut-kostnaden variera beroende på var undersökningen utförs.

2.4.6 Apparatkostnad

Varje apparat kopplas till ett av de denierade undersökningsrummen. Där-igenom erhålls den totala utnyttjade apparattiden per år för varje apparat eftersom den är densamma som beläggningstiden för undersökningsrummet. För att beräkna minutkostnaden för en apparat behöver man veta dess ka-pitaltjänstekostnad och servicekostnad. Dessa båda tillsammans utgör den totala årliga kostnaden för en apparat.

Kapitaltjänstekostnaden beräknas enligt annuitetsmetoden. Den innebär att man delar upp den totala investeringskostnaden över dess beräknade

livslängd i ett antal lika stora annuitetsbelopp, ett per år. Annuiteten utgör kapitaltjänstekostnaden per år.

Servicekostnaden kan vara svår att beräkna då det är svårt att veta hur stor del av verksamhetens totala servicekostnader som är knutna till varje en-skild apparat. Det nns två metoder som beskrivs utförligt i SPRI-rapporten, den ena baserar servicekostnaden för en apparat på dess inköpspris och den andra på dess ålder.

Minutkostnaden för en apparat räknas ut genom att dividera summan av kapitaltjänstekostnaden och servicekostnaden per år med den totala be-läggningstiden per år. Apparatkostnaden för en undersökning får man sedan genom att multiplicera apparattiden med minutkostnaden för den apparat som nns i det undersökningsrum som undersökningen utförs i.

2.4.7 Beräkning av indirekta kostnader

Alla övriga kostnader som inte har direkt anknytning till undersökningar de-nieras som Indirekta kostnader med en specikation och total årlig kostnad. Baspriset för ett besök beräknas sedan genom att summera alla indirekta kostnader och dividera med antalet primärundersökningar som utförs per år.

Kapitel 3

Metodteori

Det här kapitlet presenterar teorin för de viktigaste metoderna som använts under projektets gång.

3.1 Kvalitativa intervjuer

I vetenskapliga sammanhang skiljer man på kvantitativa och kvalitativa in-tervjuer. Kvantitativa intervjuer genererar resultat som kan översättas till siror och som sedan behandlas med statistiska metoder för att dra slut-satser och skapa ny kunskap. Upplägget för dessa intervjuer består av ett bestämt antal väldenierade slutna frågor som genererar korta och tydliga svar inom ett begränsat svarsområde. Metoden innebär att ett stort antal intervjuer utförs för att skapa ett stort urval och som därigenom höjer kva-liteten på resultatet. Kvalitativa intervjuer bygger istället på att utföra en färre mängd intervjuer där resultatet av varje intervju består av kvalitativ klartext. Steinar Kvales denition av en kvalitativ interju lyder en intervju vars syfte är att erhålla beskrivningar av den intervjuvades livsvärld i avsikt att tolka de beskrivna fenomenens mening, . En fördel med dessa intervju-er är att de är enklare att utföra och kan ha ett mintervju-er öppet och exibelt upplägg. Det nns ingen direkt standardteknik som bygger på regler för hur en intervju ska utföras. Upplägget liknar en vanlig konversation som karak-täriseras av en systematisk utfrågning enligt en specik struktur och med ett specikt syfte. I det här projektet har kvalitativa intervjuer använts dels under förstudien och dels under valideringsfasen. [10]

3.1.1 Semistrukturerade Intervjuer

Strukturen för en kvalitativ intevju kan variera från ett bestämt antal väl-denierade frågor till helt öppna intervjuer utan manus där intervjuaren och intervjuobjektet diskuterar fritt kring ett ämne. Vid en semistrukturerad in-terjvu används ett intervjuprotokoll där ett antal diskussionsområden med

förslag på relevanta frågor nns denierade. Själva intervjun är sedan exibel då ordningen och formen på frågorna kan ändras under samtalets gång bero-ende på hur det utvecklar sig. Upplägget är speciellt användbart i explorativa undersökningar och fördelen är att intervjuobjektet i fråga inte styrs att sva-ra på frågor som sedan visar sig vasva-ra oväsentliga. Istället tillåts samtalet löpa mer fritt vilket gör det möjligt att fånga upp intressanta frågeställningar på vägen. [10]

3.1.2 Fokusgrupper

Fokusgrupper är ett begrepp för något som kan liknas vid en semistruk-turerad gruppintervju. Det innebär att en grupp människor, som av olika anledningar är representativa för det område man vill utforska, samlas och intervjuvas i grupp. Vanligtvis utgörs antalet personer i en sådan grupp av mellan 5-10 personer. Upplägget går sedan ut på att dessa personer själva för en diskussion kring ett antal frågeställningar under ledning av en mo-derator. Samtalet spelas antingen in på band eller dokumenteras skriftligen. Själv diskussionen föregås ofta av en presentation av något ämne eller av att deltagarna har fått tillgång till relevant information i förväg. [10]

Inom mjukvaruutveckling kan fokusgrupper användas för att samla in information av typen self-reported metrics, vilket innebär att den beskri-ver användarens subjektiva uppfattning av en produkt. Metoden är vanligt förekommande när målsättningen är att få fram information om använda-rens uppfattning och intresse för en ny produkt eller ett nytt koncept. Själ-va fokusgrupp-sessionen inleds då av en presentation och demonstration av produkten i någon form och därefter följer diskussion kring ett antal givna frågeställningar.[18]

Metoden brukar få en del kritik för att resultatet kan påverkas av grupp-tryck och att starka personer i gruppen tar överhand. Fördelen är att de är enkla att genomföra och kräver relativt lite förberedelser. [7] [18]

3.2 Provisional Personas och Scenarion

3.2.1 Personas

Personas är en teknik för att beskriva en potentiell användare av en produkt. I en Persona samlar man all information som beskriver hur, när och varför en person använder produkten. Även personens karaktär beskrivs utförligt med namn, yrke, ålder, intressen, tekniska färdigheter och allt annat som kan vara intressant att veta om den potentiella användaren. Syftet med en Persona är att alla som jobbar med att utveckla en produkt ska ha en specik användare att referera till under hela utvecklingsprocessen, någon som kan motivera olika designbeslut och val av funktionalitet. En Persona är produkten av en omfattande förstudie och användaranalys och man kan lägga ner mycket tid

och arbete för att få fram en så detaljerad och genomarbetad Persona som möjligt. [7]

3.2.2 Provisional Personas

Provisional Personas är en light-version av Personas. De används när man inte har tid eller möjlighet att göra det förarbete som krävs för att ta fram en fullständig Persona. Man baserar dem på den kunskap och det material man har tid och möjlighet att samla in. En Provisional Persona utgör en referenspunkt i utvecklingsarbetet och utgångspunkten är att det är bättre att ha något att sika på än ingenting alls. [7]

3.2.3 Scenarion

Ett scenario beskriver händelseförloppet av en personas interaktion med en produkt för att lösa ett eller era problem. Det är en textbaserad beskriv-ning som både förklarar personans handlingar och målsättbeskriv-ningar såväl som produktens uppförande och respons under ett givet händelseförlopp, med en början och ett slut. [7]

Det nns olika typer av scenarion. Den typen som använts i det här projektet är av typen Context Scenarios, vilket innebär att de beskriver sce-narion på en högre nivå och med en optimistisk inställning till verktygets funktionalitet och uppförande. Context Scenarios bygger på händelser som säkert kommer hända. Andra typer av scenarion som nns är key path-, validation- och communication scenarios, som tar upp mer detaljerade hän-delser som inte är lika självklara att de kommer inträa. Scenarions syfte är att motivera funktionalitet. För varje funktion bör det nnas ett scenario som beskriver en situation där funktionen är viktig för användaren, eller för en persona. [7]

3.3 Prototyper

Begreppet prototyp innefattar ett brett spektrum av användningsområden med olika syften. Det här avsnittet reder ut begreppet och utgör en teoretisk grund för att kunna deniera vilken typ av prototyp som utvecklades i det här projektet.

3.3.1 Low-Fidelity Prototypes

Low delity prototypes, förkortat Lo-Fi, är samlingsnamnet för enkla och pri-mitiva prototyper där dialogrutor, knappar, textfält och andra komponenter i gränssnittet skapas med hjälp av papper och andra typer av kontorsmateri-al. Det är en teknik som gör det möjligt att väldigt snabbt skissa och realisera

idéer och testa dem mot användare utan att behöva tänka på bakomliggande teknik.

Lo-Fi handlar om de stora och övergripande idéerna i designprocessen; arbetsöden, strukturer, interaktion, dataobjekt, dialoger, ord och begrepp. Tekniken är därför speciellt lämplig att använda i ett tidigt stadie av ut-vecklingsprocessen, när detaljerna inte är viktiga. Det nns olika nivåer av Lo-Fi-prototyper. Allt ifrån enkla skisser gjorda för hand, med penna och papper, till mer avancerade klipp- och klistra-baserade användargränssnitt, med komponenter utformade med olika typer av material [14].

3.3.2 High-Fidelity Prototypes

Motsatsen till Lo-Fi är att bygga datorbaserade prototyper med en högre teknisk nivå. Denna typ av prototyper brukar benämnas High-Fidelity Pro-totypes. Kvalitén och den tekniska nivån kan variera kraftigt, från visuellt avancerade Powerpoint-prototyper till fullfjädrade program utvecklade till en teknisk nivå motsvarande en färdig produkt. Det kan nnas många an-ledningar till att utveckla Hi-Fi-prototyper. De gör det möjligt att testa, demonstrera och validera koncept och funktionalitet på ett sätt som inte går att uppnå med Lo-Fi. Det går att utföra kvalitativa prestandatester och göra utvärderingar och jämförelser av nya koncept jämfört med bentliga. Nackdelen med Hi-Fi-prototyper är att de tar lång tid att utveckla och det nns risk att man lägger energi på fel saker.

3.3.3 Mixed-Fidelity Prototypes

Den vanligaste uppfattningen av ordet delity i detta sammanhang är att det i någon mening syftar på en teknisk detaljnivå i implementationen av en prototyp. Denna nivå kan dock skilja sig utifrån olika aspekter i imple-mentationen. I vissa avseenden är prototypen Lo-Fi och i andra avseenden är den Hi-Fi.

McCurdy & Connors m  har tagit fram en metod för att karaktärisera en prototyp genom att deniera nivån av delity i fem olika dimensioner. De kallar metoden för Mixed-Fidelity Prototypes. Fördelen med den är att man kan anpassa nivån i de fem dimensionerna efter vilka behov och målsättningar man har med prototypen. På så vis kan man spara tid och pengar genom att undvika att lägga energi på sådant som inte har någon betydelse för resultatet [12]. De fem dimensionerna utgörs av:

• Level of Visual Renement

Motsvarar den visuella nivån i prototypen. En låg nivå motsvarar enkla skisser på papper eller wireframes som beskriver gränssnittet. En hög nivå motsvaras exempelvis av en datorgenererad bild av ett fullt ut-vecklat och genomarbetat gränssnitt som i detalj överenstämmer med målbilden av slutprodukten.

• Breadth of Functionality

Beskriver hur stor del av den totala funktionaliteten i slutprodukten som ingår i prototypen. En hög nivå innebär att det nns funktionalitet för att utföra många olika typer av handlingar.

• Depth of Functionality

Beskriver hur långt funktionaliteten är implementerad för en viss funk-tion i prototypen. En hög nivå innebär att funkfunk-tionaliteten är komplett. Man kan utföra en uppgift, bestående av ett antal delmoment, tills att den är fullständigt slutförd. En låg nivå innebär att endast en del-mängd av den totala funktionaliteten är implementerad och skulle t ex kunna innebära att man kan påbörja en uppgift men inte slutföra den fullständigt.

• Richness of Interactivity

Beskriver nivån av interaktiv respons på olika handlingar från använda-ren. En hög nivå innebär att systemet fångar och svarar på användarens inmatningar och handlingar på ett naturligt och konsekvent sätt, t ex när man klickar på knappar eller väljer ett meny-alternativ.

• Richness of Data Model

Beskriver hur representativ den data som används i prototypen är för det aktuella användningsområdet. En hög nivå motsvarar användning-en av data som är autanvändning-entisk med verklig data, medan användning-en låg nivå mot-svarar användningen av ktiv data vars likhet med verklig data är låg.

3.4 Mental Models

Människor bygger upp mentala modeller av olika företeelser i sin omgivning som antingen baseras på erfarenhet eller föreställning av hur saker fungerar. Dessa modeller används för att förstå och förutse saker som händer i omgiv-ningen. När man utvecklar mjukvara kan man utgå från användarens mentala modell av de dataobjekt som ingår i systemet och sträva efter en konceptuell struktur och funktionalitet som motsvarar den. Ett sådant system är lättare att förstå och använda. [7]

Kapitel 4

Förstudie

4.1 Metod

Det här kapitlet beskriver tillvägagångssättet och genomförandet av förstudi-en.

4.1.1 Studiebesök

Förstudien inleddes med ett studiebesök hos Pia Säfström, verksamhetschef för röntgenkliniken på Universitetssjukhuset i Linköping. Det syftade till att ge en grundläggande förståelse för användaren och den verksamhet som MedEko riktar sig till. Besöket gjordes tillsammans med en annan examens-arbetare på Sectra och hade därför ett generellt upplägg som inte enbart utgick från målsättningarna med det här examensarbetet.

Besöket inleddes med ett samtal där Pia berättade hur verksamheten drivs idag utifrån personal- och budgetansvar, ekonomiska förutsättningar och rapporteringskrav. Hon gav även exempel på tekniska hjälpmedel hon har att tillgå i sitt arbete.

Därefter gjordes en rundvandring på kliniken där Pia berättade om de olika labben, hur arbetsödet är upplagt och tänkt att fungera. Hon visade vilka typer av lokaler som nns och redogjorde för deras syften. Hon berät-tade även om olika typer av personal och i vilka delar av verksamheten de jobbar.

4.1.2 Intervjuer

Två stycken semistrukturerade intervjuer gjordes under förstudien. Vid båda intervjuerna fördes anteckningar under samtalets gång som sedan samman-ställdes i ett dokument för respektive intervju.

Intervju med Anders Persson

Syftet med intervjun var dels att få en introduktion till MedEko och dels att diskutera vilka möjligheter som fanns att sätta upp en testmiljö av applika-tionen för utvärdering och test. Som underlag och stöd till samtalet fanns följande punkter förberedda:

• Bakgrunden till MedEko:s uppkomst och utveckling • Vem använder applikationen?

• Vad för typ av problem löser den? • Teknisk implementation

 Hur är systemet uppsatt där det används?

 Har det skett någon vidareutveckling och i vilken omfattning? • Personer att ta kontakt med?

Intervjun ägde rum på Anders kontor på CMIV, där han hade en fun-gerande version av MedEko installerad på en bärbar dator. Samtalet utgick från att Anders redogjorde för funktionaliteten i MedEko genom enkla de-monstrationer på datorn. Diskussioner fördes kring frågor som uppstod på vägen. Anders visade även manualen och berättade kort om den [13], samt upplyste om SPRI-rapport 299 och dess betydelse i sammanhanget.

Intervju med Lars-Åke Johansson

Enligt förslag av Anders Persson gjordes en intervju med Lars-Åke Johans-son, utvecklingschef på Diagnostikcentrum vid Linköpings Universitetssjuk-hus. Lars-Åke besitter spetskompetens inom tillämpningsområdet, har en bred allmän ekonomisk kompetens och har arbetat både med MedEko och utvecklat ett eget verktyg i Microsoft Excel baserat på de beräkningsprinci-per som används i MedEko.

Intervjun gjordes efter studie av SPRI-rapport 299 och funktionsanalys av MedEko. Syftet var att få veta mer om hur och varför ett verktyg som MedEko används, hur han som erfaren användare ser på MedEko idag, och vilka synpunkter han har inom området i allmänhet. Även här fanns ett antal stolpar för samtalet förberedda:

• Erfarenhet av MedEko: styrkor och värden, svagheter och förbättrings-områden?

• Indata/dataunderlag, insamling och användning? • Hur används MedEko?

4.1.3 Litteraturstudie

SPRI-rapport 299 har utgjort en viktig del i litteraturstudien men eftersom det gått lång tid sedan den publicerades kan man anta att det har forskats vidare inom området sedan dess. För att öka förståelsen för problemområdet gjordes en ytlig kartläggning av vad som uträttats inom området sedan SPRI-rapporten publicerades. Två artiklar studerades: Activity-based costing in radiology [11], Activity-based Cost Analysis: A Method of Analyzing the Fi-nancial and Operating Performance of Academic Radiology Departments [5]. De beskriver båda hur man kan applicera metoden Activity Based Costing inom radiologiska verksamheter. Det visade sig att den beräkningsmodell som beskrivs i SPRI-rapporten har många likheter med denna metod. Ing-en djupare analys gjordes av värdet i dIng-enna metod Ing-enligt avgränsningIng-en i avsnitt 1.4.

4.1.4 Funktionsanalys av MedEko

För att kunna analysera funktionaliteten i MedEko sattes ett testsystem upp. Systemkravet för att kunna köra MedEko på en dator innefattar explicit Microsoft Windows NT 4 och Microsoft Excel av senast version 5.0. Senare versioner av dessa båda mjukvaror innebär alltså att MedEko ej går att köra. Detta är en anledning till att verktyget idag inte längre är använbart.

Den smidigaste lösningen på problemet var att klona Anders bentliga demosystem. Det innebär att man med hjälp av speciell mjukvara tar en exakt kopia av ett komplett fungerande system som sedan yttas till en annan dator. Anders tillhandahöll även användarmanualen för MedEko i elektroniskt format.

Systemet innehöll en viss mängd förinmatad indata, men eftersom den var bristfällig och till viss del trasig, gjordes vissa kompletteringar med ktiv data för att ge ett heltäckande dataunderlag för en fullständig funktionsa-nalys.

Funktionaliteten i MedEko analyserades systematiskt genom att följa manualen och i tur och ordning studera samtliga dialoger och inmatnings-formulär. Under tiden fördes anteckningar och jämförelser gjordes mot SPRI-rapportens beskrivningar av olika beräkningsrutiner.

4.1.5 Beräkningsteknisk prototyp i Excel

Efter att ha studerat SPRI-rapporten utvecklades en enkel beräkningsproto-typ i Excel. Syftet med den var att bekanta sig ytterligare med beräknings-modellen och dataunderlaget samt att testa de olika beräkningsprinciperna i praktiken. Den har även fungerat som ett hjälpverktyg under utvecklingen av den slutgiltiga prototypen för att testa vissa konceptuella förändringar i beräkningsmodellen. Den har även använts för att kontrollera att beräk-ningsresultaten stämmer i prototypen.

4.1.6 Kick-o

I slutfasen av förstudien genomfördes en kicko för projektet där ett an-tal olika intressenter från Sectra var närvarande. Dessa bestod av teknisk handledare Mattias Nylen, beställare och ansvarig för exjobbet Per Bankvall, applikationsspecialister Regina Rosander och Petra Granlund samt produkt-ledare för Control Tower1 _{Ylva Aspenberg. Syftet var att alla intressenter}

inom Sectra skulle få en union bild av bakgrunden för projektet, vad MedEko är för typ av verktyg, vilka huvudsakliga problem den löser och vilka förut-sättningarna var för projektet. Syftet var även att få feedback, synpunkter och idéer från dessa personer som har lång erfarenhet och kännedom om branschen samt att de skulle ha möjlighet att påverka inriktningen i projek-tet.

Mötet inleddes med att en sammanfattning av resultaten från förstudien presenterades med en kort efterföljande demo av MedEko. En öppen diskus-sion fördes kring frågor som uppstod allt eftersom presentationen fortgick och mötet avslutades med en diskussion kring förväntningar, frågeställning-ar och fortsatt riktning i projektet.

4.1.7 Möte med beställare

Tillsammans med Per Bankvall och Mattias Nylen denierades ett antal riktlinjer och övergripande målsättningar för implementationsfasen. Ett do-kument skapades som beskrev ett antal specika koncept och värden som en målbild för prototypen. Dokumentet denierade även vilka allmänna av-gränsningar som kunde göras. En sammanställning av innehållet åternns i avsnitt 4.2.4. Utifrån detta dokument utformades en specikation över all funktionalitet som prototypen kunde innehålla och vilken typ av data den skulle kunna behandla. Här gjordes ingen denitiv avgränsning över vilka delar av beräkningsmodellen som skulle implementeras. Dessa beslut togs istället under utvecklingens gång enligt agil utvecklingsmetodik (se avsnitt 5.1.1).

4.1.8 Använding av Provisional Personas och Scenarion

I det här projektet skapades två stycken Provisional Personas med ett Con-text Scenario vardera. I första skedet baserades de på funktionsanalysen av MedEko, studien av SPRI-rapporten, intervjuerna med Lars-Åke och An-ders, samt på samtal med intressenter inom Sectra (främst från kick-o och möten med Per och Mattias).

De har sedan följt med under projektets alla faser och reviderats under arbetets gång. Den slutgiltiga versionen fastställdes efter valideringen mot

1_{ControlTower är en produkt för verksamhetsstyrning och uppföljning. Den innehåller} funktionalitet för att generera en mängd olika rapporter baserat på den egna verksamhe-tens produktion och statistik.

kund baserat på den feedback som framkom. De nns med i sin helhet i bilaga A.

4.2 Resultat

Det är kapitlet redovisar en sammanställning av resultatet av förstudien.

4.2.1 Presentation av MedEko

Detta avsnitt ger en beskrivning av MedEko och baseras på den information som samlades in vid de intervjuer som gjordes under förstudien [1] [2] (en-ligt beskrivning i avsnitt 4.1.2) samt genom funktionsanalysen av MedEko (avsnitt 4.1.4).

Bakgrund

Efter att SRPI-rapport 299 publicerats började Ander Persson snart utveckla ett eget verktyg i Excel baserat på den nya beräkningsmodellen. Han skriver i användarmanualen att Målsättningen har varit att skapa ett enkelt verktyg för kostnadsanalys, verksamhetsplanering och prissättning av röntgenunder-sökningar i samband med interndebitering, [13]. Verktyget riktade sig till verksamhetschefer med radiologisk bakgrund, utan ekonomisk eller datatek-nisk expertis. Tanken var att verksamhetschefer skulle kunna använda det utan några speciella krav på förkunskaper. Fokus låg på att tillhandahålla ett graskt gränssnitt med så enkel datainmatning som möjligt, allt för att undvika att användaren exponerades för den avancerade tabellstruktur som ligger bakom beräkningarna.

Grundläggande funktionalitet

Det primära syftet med MedEko är att skapa en prislista med detaljerad kostnadsinformation för alla undersökningar. Förutom att utföra själva be-räkningarna består den övergripande funktionaliteten av olika hjälpmedel för att mata in och strukturera det verksamhetsspecika dataunderlaget. MedE-ko gör det möjligt att tillämpa beräkningsmodellen i SPRI-rapport 299 på ett enkelt och eektivt sätt.

Teknisk implementation

MedEko är en implementation av de beräkningsprinciper som beskrivs i SPRI-rapport 299. Verktyget är byggt i Excel och består av en mängd olika tabeller och makron. De tabeller som exponeras mot användaren är utforma-de med ett graskt användargränssnitt och användaren kan navigera mellan tabellerna med hjälp av knappar. Stora delar av tabellerna är låsta för edi-tering, bortsett från de fält där olika typer av data ska matas in.

Själva logiken i verktyget styrs av ett stort antal makron som körs i bakgrunden när användaren klickar på olika knappar. Detta innebär att ord-ningen i vilken inmatning och uppdatering av dataunderlaget utförs är viktig för att programmet ska fungera korrekt. Dessa makron är odokumenterade vilket innebär att det skulle vara mycket tidskrävande att återanvända eller vidareutveckla något av den underliggande beräkningslogiken. Övrig Excel-funktionalitet är bortskalad och applikationen upplevs därför som fristående. Insamling och inmatning av data

En viktig del av dataunderlaget utgörs av den klinikspecika tabellen som innehåller undersökningskoder för alla tillgängliga undersökningar. För varje kod nns information om antal utföra undersökningar, vilket labb de utförs i samt tider för följande tidsattribut:

• Undersökningstid Övrig Personal • Undersökningstid Läkare

• Granskningstid • Apparattid

MedEko levereras med en standarduppsättning koder med tillhörande tids-värden för undersökningstider och granskningstider. Denna referenstabell kan man utgå från och ändra efter behov. Det nns även möjlighet att läsa in undersökningskoder, inklusive antal utförda undersökningar per kod, från textler.

Förbrukningen av material för varje undersökning matas in i en sepa-rat tabell som innehåller samma uppsättning koder som den klinikspecika tabellen. En stor del av materialet utgörs av sådant som krävdes för att framkalla analoga röntgenbilder för varje undersökning, som t ex lm, fram-kallningsvätska och videokassetter.

Utöver dessa tabeller nns tabeller för att mata in kostnadsunderlag för de resurser som används för att beräkna direkt kostnad per undersökning. Det innefattar personalkostnader, hyror, kapitalkostnader, materialkostna-der osv.

Simulering och statistik

När all information nns lagrad i de underliggande tabellerna är det möj-ligt att simulera förändringar och åtgärder i verksamheten genom att göra ändringar i dataunderlaget. Man kan t ex lägga till eller ta bort personal och se hur det påverkar korrektionsfaktorn, undersökningskostnader, perso-nalbeläggning, budgetutslag osv.

I tabellen Totalekonomi sammanfattas alla kostnader i kategorier och underkategorier. Det ger en övergripande bild av ekonomin och kan användas

för att veriera att budgetkrav uppfylls. Det nns även ett stapeldiagram som visar labbutnyttjande i minuter för de olika undersökningsrummen. Det kan användas för att jämföra beläggningen mellan olika labb.

Prislista

Prislistan är det slutgiltiga målet med att använda MedEko. Den innehåller alla de undersökningar som nns specicerade i den klinikspecika listan och varje undersökning listas med undersökningskod, beskrivande klartext och total direkt kostnad. Här nns information om baspris per besök och eventuella jourtillägg och det nns även möjlighet att skriva ut prislistan. Dessutom nns en detaljerad vy där direkt kostnad per resurs presenteras för varje undersökning.

4.2.2 Identierade värden

Kostnadsanalys

Det mest tydliga värdet med MedEko är att kunna beräkna kostnader för specika undersökningar, baserat på den egna verksamhetens produktions-faktorer. Resultatet används sedan som underlag vid prissättning av under-sökningarna. Verktyget gör det möjligt att med hjälp av utförliga anvisning-ar använda en komplett beräkningsmodell utan att behöva tänka på hur de bakomliggande beräkningarna utförs. Arbetsbördan består av att samla och mata in ett korrekt dataunderlag.

Det är framför allt den direkta kostnaden som är intressant och det är den som utgör kärnan i den beräkningsmodell som ligger till grund för MedEko. För att beräkna den direkta kostnaden krävs ett komplext dataunderlag och omfattande beräkningsrutiner vilket i sin tur kräver ett datorbaserat verktyg. Man kan därför sammanfatta värdet i MedEko med att det gör det möjligt att tillämpa den beräkningsmodell som beskrivs i SPRI-rapport 299 på ett enkelt och eektivt sätt.

Simulering

Ett annat tydligt värde är möjligheten att simulera och analysera eekten av olika åtgärder och förändringar i verksamhetens produktion. När allt da-taunderlag för den bentliga produktionen är inmatat kan man enkelt göra ändringar i underlaget, som t ex att ändra antalet utförda undersökningar av en typ eller i vilket labb den utförs, och sen analysera vilken eekt det ger på kostnader etc. Både Anders och Lars-Åke vittnar om att det är ett användbart verktyg vid verksamhetsplanering. Det kan t ex ge incitament till nya investeringar eller förändringar i verksamheten.

4.2.3 Förbättringsområden

Insamling av data

Den största arbetsbördan i att använda MedEko är att mata in all den information som utgör underlag för beräkningsmodellen. All eektivisering inom det här området skulle höja användningsvärdet i verktyget. Den del av dataunderlaget som är svårast att få fram är förbrukningsdata för varje un-dersökning, som t ex undersökningstider, granskningstider och apparattider. De baseras antingen på manuella tidsmätningar eller uppskattade tidsvärden. Åtgärder som underlättar insamlingen av denna data som stämmer överens med verkligheten skulle vara av stort värde. [2]

Flexibilitet i beräkningsmodellen

Under intervjun med Lars-Åke framkom att en begränsning med MedEko var dess låsta koppling till beräkningsmodellen. Det fanns få möjligheter att göra ändringar i hur beräkningarna utfördes eller vilka parametrar som skul-le vara med. Som exempel nämndes ett behov att ha med Dubbelgranskning som ett tidsattribut utöver de som fanns med i MedEko. En anledning till att MedEko inte längre kunde använda var behovet av att kunna räkna på kostnader för era kliniker. Vidare framkom att MedEko hade en tendens att bli för detaljerat i beräkningarna. Det fanns t ex inget behov av att speci-cera materialförbrukningen för varje undersökning. Önskemålet var istället att kunna fördela den kostnaden på undersökningspriset på något sätt. Ett annat problem var att principen med ett baspris per besök inte användes vid klinikern. Därmed fanns ett behov av att även fördela indirekta kostnader på undersökningspriserna. Hur denna fördelning kan göras är något som ofta diskuteras enligt Lars-Åke. [2]

Sammanfattningsvis resulterade detta i två specika förbättringsförslag: • Möjlighet att själv välja vilka tidsattribut som ska användas för att

ange förbrukningen av personalarbetstid per undersökning.

• Möjlighet att fördela indirekta kostnader över alla undersökningspriser istället för att tillämpa principen med ett baspris per besök.

Simuleringsmöjligheter

I den klinikspecika tabellen anges för varje undersökning vilket rum den utförs i med en sira mellan 1-12. Man kan som mest ha tolv undersök-ningsrum denierade och en undersökning kan bara utföras i ett av dessa. Detta är en förenkling av verkligheten. I praktiken kan en undersökning utfö-ras i olika undersökningsrum som innehåller olika uppsättningar utrustning och som därmed har olika kostnadsunderlag. För att kunna göra detaljerade

simuleringar av förändringar i produktionen, framför allt kopplat till under-sökningsrum och modaliteter, krävs att kostnadsberäkningarna tar hänsyn till att undersökningar kan utföras i olika labb.

Visuell presentation

Möjligheten att åskådliggöra kostnadsinformationen visuellt är mycket be-gränsad i MedEko. Att presentera stora datamängder i exempelvis diagram och grafer är ett eektivt verktyg för att öka förståelsen för informationen. Det är speciellt användbart när man vill göra jämförelser mellan olika data-mängder. I det här fallet skulle det t ex kunna användas för att visa resultatet av två olika simuleringsutfall.

4.2.4 Inriktning och avgränsningar för prototyputveckling

Utgångspunkten för utvecklingen av prototypen är att göra en modern ver-sion av verktyget MedEko. När den sedan valideras mot kund ska den kunna köras i windows-miljö och detaljnivån i implementation ska vara tillräckligt hög för att kunna demonstrera de beräkningstekniska koncepten i prototy-pen. Det övergripande målet för funktionaliteten är att generera prislistor för undersökningar, inklusive detaljerad information om direkta- och indirekta kostnader, samt möjligheten att simulera eekter av förändringar i indata. Allmänna avgränsningar som kan göras är att indata kan hårdkodas istäl-let för att implementera funktionalitet för att faktiskt hämta den från olika datakällor.

Övergripande målsättningar och riktlinjer

• Enkel och eektiv insamling av indata Utnyttja information som Sectra har exklusiv tillgång till genom sina kärnsystem, RIS och PACS, för att eektivisera och i viss mån automatisera insamlingen av indata till beräkningsmodellen.

• Flexibel beräkningsmodell Sträva efter en generell och exibel be-räkningsmodell i avseende vilka parametrar man vill ha med i beräk-ningarna av direkta- respektive indirekta kostnader.

• Användbar utdata Samla och strukturera utdatan på ett sätt så att den dels kan presenteras tydligt och informativt direkt i verktyget, och dels kan extraheras och användas som indata i andra system.

• Simulering Genom enkla ändringar i indata ska man kunna simulera eekten på kostnader och undersökningspriser.

• Skillnadsanalys Prototypen ska innehålla funktionalitet för att göra minst en visuell skillnadsanalys av olika simuleringar. Det innebär att

man på ett enkelt och överskådligt sätt, t ex genom grafer och diagram, ska kunna jämföra resultatet av ett simuleringsutfall med verkligheten. Analysen kan göras med hjälp av extern mjukvara som t ex Excel eller Qlikview.

I det här stadiet gjordes ingen denitiv avgränsning av vilka delar av be-räkningsmodellen för att beräkna direkt kostnad som skulle implementeras.

4.3 Resultatdiskussion

En viktig aspekt i sammanhanget är att MedEko utvecklades för snart 20 år sedan. Ett i manualen påpekat värde med verktyget var det faktum att det hade ett musstyrt graskt användargränssnitt [13]. Idag är detta en själv-klarhet för vilket datorbaserat verktyg som helst. MedEko riktade sig till personer utan ekonomisk eller datateknisk expertis som inte hade möjlighet att tillämpa beräkningsmodellen på egen hand. Mycket har hänt i den tek-niska utvecklingen sedan början av 90-talet och idag är förutsättningarna annorlunda. Människor i allmänhet besitter en större vana att arbeta med datorer. Man kan anta att det nns en mer utbredd kompetens vad gäller att arbeta med verktyg som Excel vilket gör det möjligt att utveckla egna beräkningsverktyg motsvarande MedEko. Det här examensarbetet har inte innefattat någon omfattande utredning av vem dagens användare är av ett motsvarande verktyg och vilka behov de har.

De värden och koncept som nns denierade i 4.2.4 innefattar dels de grundläggande värden som identierades i MedEko och dels ett antal nya potentiella värden som bygger på förbättringsförslagen i 4.2.3. Större delen av dessa förbättringsförslag bygger i sin tur på intervjun med Lars-Åke. Han är både ekonomiskt och datatekniskt kompetent och representerar därmed en annan typ av användare än den som MedEko i huvudsak riktade sig till. De koncept som bygger på förbättringsförslagen är alltså riktade till använ-dare med högre krav på de ekonomiska beräkningsmöjligheterna. Det är inte säkert att denna inriktning är rätt väg att gå vid utvecklingen av en modern motsvarighet till MedEko, men det förväntas resultatet av valideringen ge en del klarhet i.

4.3.1 Personor och Scenarion

Två personor med ett scenario vardera skapades i slutfasen av förstudien, varav den ena utgör primär persona och den andra sekundär persona. Dessa baserades på den kunskap som frambringats genom intervjuer, studiebesök och samtal med intressenter inom Sectra [3] [1] [2]. Scenariot till den primära personan baserades på det mest tydliga värdet i MedEko (se avsnitt 4.2.2). Det går ut på kostnadsanalys av undersökningar baserat på den

bentli-ga produktionen i samband med prissättning. Scenariot till den sekundära personan bygger på värdet av att simulera förändringar i produktionen.

Kapitel 5

Utveckling av Prototyp

5.1 Metod

5.1.1 Agil utveckling

Under utvecklingen av prototypen tillämpades vissa grundläggande delar av metoden Scrum1_{, som tillhör kategorin agila utvecklingsmetoder. Syftet med}

agil utveckling är att sträva efter en exibel utvecklingsprocess där man är öppen och mottaglig för förändringsförslag och nya inriktningar på vägen. Det nns många olika agila metoder men gemensamt för alla är att de bygger på en inkrementell och iterativ utvecklingsprocess.

Den totala planerade tiden för utvecklingsfasen delades upp i tre de-lar, kallade sprinter. Under varje sprint implementerades en delmängd av den slutgiltiga prototypen och avslutades med en sprintdemo där resultatet presenterades och utvärderades tillsammans med inbjudna intressenter på Sectra. Efter utvärdering beslutades vad som skulle implementeras i kom-mande sprint. Detta innebar att ingen denitiv avgränsning av vad som skulle implementeras gjordes i förväg, utan innehållet bestämdes utifrån vad beställaren ansåg viktigast och mest intressant att få med. Utgångspunk-ten var den inriktning och de målsättningar som fastställdes efter avslutad förstudie (avsnitt 4.2.4).

5.1.2 Pappersprototyper

I inledningen av utvecklingsfasen användes pappersprototyper för att utveck-la det graska gränssnittet och den övergripande strukturen och interaktions-designen. Baserat på det insamlade materialet från förstudien identierades ett antal Mental Models för olika dataobjekt som skulle ingå i prototypen (se avsnitt 3.4). Enkla skisser på papper skapades över arbetsytor och dialoger som sedan utvärderades tillsammans med Per och Mattias.

1_{För mer information om utvecklingsmetoden Scrum hänvisas läsaren till boken Scrum} and XP from the Trenches, [9]

5.1.3 Teknisk plattform

Språk och ramverk

Den slutgiltiga prototypen är byggd med C# och Microsoft Windows Pre-sentation Foundation2 _{(WPF), som är en del av Microsoft .NET Framework}

4. Anledningen var att plattformen används på Sectras utvecklingsavdelning för kundanpassningar. Det gjorde det möjligt att dra nytta av kompetensen på företaget och att använda klass-bibliotek som Sectra byggt upp och som används i anpassningsprojekten.

Designmönster

Ett grundläggande konceptuellt designmönster som användes för att utveckla den slutgiltiga prototypen var Model View ViewModel (MVVM). Det är en variant av Model View Controler (MVC) som är speciellt anpassat för WPF. Syftet är bl a att separera de tre komponenterna grakskt gränssnitt, logik och datamodell. För en utförlig beskrivning av detta designmönster hänvisas läsaren till artikeln WPF Apps With The Model-View-ViewModel Design Pattern [16].

5.2 Resultat

5.2.1 Avgränsad funktionalitet

En central del av MedEko var dess funktionalitet för att beräkna den direk-ta kostnaden för undersökningar baserat på förbrukningen av olika resurser. Hur denna förbrukningskostnad beräknas skiljer sig lite mellan de olika resur-serna, men principen är densamma. Prototypen avgränsades till att endast innefatta resursen Personal i beräkningen av direkt kostnad. Anledningen var att tiden inte räckte till att implementera funktionalitet för de övriga resurserna och Personal var den som ansågs viktigast och mest lämplig.

Målsättningen med prototypen var att kunna demonstrera koncepten med en fullt fungerande beräkningsprocess och därför prioriterades en hög nivå av Depth of Funcionality framför en hög nivå av Breadth of Functio-nality. Utifrån resursen Personal kan man sedan förklara att samma princip går att applicera för att beräkna direkt kostnad för t ex undersökningsrum och apparater.

I övrigt har avgränsningar och prioriteringar i implementerad funktiona-litet gjorts i enlighet med den inriktining och målsättning som denierades under förstudien och som nns dokumenterad i avsnitt 4.2.4.

5.2.2 Implementerad Funktionalitet

Graskt användargränssnitt (GUI)

Den övergripande strukturen i det graska gränssnittet består av fyra olika arbetsytor: Undersökningar, Resurser, Övriga kostnader och Prislista. De är ordnade i ett ikbaserat gränssnitt. Upplägget kallas för Parallel Workspaces och syftar till att era arbetsytor existerar parallellt men en användare kan bara benna sig i en arbetsyta åt gången [7].

Varje arbetsyta har ett sidhuvud som innehåller en rubrik och en enkel toolbar med knappar för olika typer av funktionalitet kopplat till aktuell ar-betsyta. Längst ner nns även en sidfot som innehåller knappar för att spara eller avbryta ändringar. Figurerna 5.1, 5.2, 5.3 och 5.4 visar arbetsytorna med de komponenter som beskrivits i detta stycke.

Undersökningar

Arbetsytan Undersökningar samlar all information om specika undersök-ningar och speciellt dess förbrukning av olika resurser. Den består av en lista där varje undersökning speciceras med en undersökningskod (grundkod + metodkod), en beskrivande klartext och antal utförda undersökningar per år. För varje undersökning bestäms förbrukningen av olika resurser genom att ange värden för ett antal tidsattribut som nns denierade och som är kopplade till olika resurser (Personalkategorier). Tiderna anges i minuter. Figur 5.1 visar en skärmdump över arbetsytan Undersökningar med de tre tidsattributen Us Personal, Us Läkare och Granskningstid.

I överkant nns tre knappar. De första två är till för att manuellt lägga till och ta bort undersökningar. Den tredje är till för att importera data från RIS. Funktionaliteten för dessa är inte implementerade.

Resurser

Fliken Resurser hette från början Personal och här nns möjlighet att deni-era ett valfritt antal personalkategorier och tidsattribut. För varje personal-kategori matas information in om årlig kostnad, årlig arbetstid och uppskat-tad administrativ tid. Information om Registrerad arbetstid, Ej registrerad arbetstid, Minutkostnad och Korrektionsfaktor uppdateras automatiskt och visas för varje personalkategori. Denna information beräknas baserat på det inmatade kostnadsunderlaget och den summerade förbrukningsdatan, som är angiven för alla undersökningar, för aktuell resurs.

Tidsattribut denieras och kopplas till en valfri resurs med hjälp av en rullgardinsmeny. Dessa tidsattribut dyker sedan upp i listan med undersök-ningar. Figur 5.2 visar en skärmdump från arbetsytan Resurser där två per-sonalkategorier är denierade, Sjukvårdspersonal och Läkare. Man kan även

Figur 5.1: Skärmdump från prototypen som visar arbetsytan Undersökningar se hur tidsattributen Us Personal och Us Läkare är kopplade till dessa båda resurser.

Vid utvärderingen i samband med första sprintdemo:t faställdes att det inte var möjligt att hinna med att implementera de övriga resurserna Lokaler och Apparater. Istället kom förslaget att byta ut rubriken Personal mot Resurser i den bentliga prototypen för att göra det möjligt att skapa och ange förbrukning av andra resurser på samma sätt som för Personal. Det visar att principen gäller även för andra resurser. Upplägget har dock vissa uppenbara brister eftersom kostnadsunderlaget ser annorlunda ut för andra resurser och därför behöver andra inmatningsalternativ.

Övriga kostnader

Övriga kostnader är ett annat uttryck för Indirekta kostnader, baserat på den mentala modellen hos en potentiell användare baserat på de personor som tagits fram (se avsnitt 4.3.1). Här matas ett valfritt antal indirekta kostnader in med en beskrivning och ett belopp.

En speciell funktion, som bygger på ett nytt koncept inom målsättningen med en exibel beräkningsmodell, är möjligheten att ange hur varje indirekt kostnad ska fördelas. Standardinställningen är att alla indirekta kostnader fördelas på antalet primärundersökningar och utgör ett baspris för ett besök.