4.2 Resultat
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 be ntli-
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 de nitiv 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 gra ska gränssnittet och den övergripande strukturen och interaktions- designen. Baserat på det insamlade materialet från förstudien identi erades 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.
1Fö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 gra kskt 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 de nierades under förstudien och som nns dokumenterad i avsnitt 4.2.4.
5.2.2 Implementerad Funktionalitet
Gra skt användargränssnitt (GUI)
Den övergripande strukturen i det gra ska 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 be nna 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 speci ka undersök- ningar och speciellt dess förbrukning av olika resurser. Den består av en lista där varje undersökning speci ceras 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 de nierade 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 de ni- 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 de nieras 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 de nierade, 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 be ntliga 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.
Figur 5.2: Skärmdump från prototypen som visar arbetsytan Resurser Utöver detta alternativ nns möjligheten att fördela indirekta kostnader över alla undersökningspriser. Det nns två fördelningsalternativ implementerade i prototoypen. Det ena är att fördela kostnaden jämnt över alla undersök- ningar. Detta kan dock innebära en ojämn fördelning i förhållande till det ursprungliga priset mellan undersökningar. Det andra sättet är därför att fördela kostnaden i förhållande till den beräknade direkta kostnaden för un- dersökningarna. En undersökning med en hög direkt kostnad får ta större del av den indirekta kostnaden jämfört med en undersökning med låg direkt kostnad. Hur denna fördelning beräknas redovisas i 5.2.5.
Sidhuvudet innehåller knappar för att lägga till och ta bort indirekta kostnader, varav funktionalitet endast är implementerad för den förstnämn- da. Det nns dock inte möjlighet att spara ändringarna så värdet i detta är endast möjligheten att förtydliga principen. Figur 5.3 visar en skärmdump över arbetsytan Övriga kostnader.
Prislista
Fliken Prislista innehåller slutprodukten av all information som matats in under de övriga ikarna. Den består av en lista med samma uppsättning undersökningar som nns de nierade under iken Undersökningar. För var- je undersökning visas den beräknade direkta kostnaden för respektive re-
Figur 5.3: Skärmdump från den slutgiltiga prototypen som visar arbetsytan Övriga Kostnader
surs, summan av dessa, eventuella indirekta kostnader fördelade på under- sökningskostnaden, samt total kostnad3. Under listan med undersökningar
nns information om Baspris för ett besök. Här anges antalet primärunder- sökningar (vilket motsvarar antalet besök) vid kliniken. Baserat på detta värde beräknas ett baspris som utgörs av alla de indirekta kostnader som inte fördelas direkt på undersökningspriserna.
Längst upp nns knappar för att exportera prislistan till Excel eller skriva ut den, varav den förstnämnda har implementerad funktionalitet. Det nns även en kryssruta för att välja om antalet undersökningar ska visas i listan. Anledningen till denna funktion är främst att det är användbart vid export till Excel för vidare bearbetning av informationen, t ex för att skapa diagram. Figur 5.4 visar en skärmdump från arbetsytan Prislista.
3Att använda ordet pris i det här sammanhanget är egentligen synonymt med ordet kostnad. Det som visas är beräknad kostnad vilket i praktiken inte är samma sak som det slutgiltiga priset för en undersökning.
Figur 5.4: Skärmdump från den slutgiltiga prototypen som visar arbetsytan Pris- lista
5.2.3 Dataunderlag i prototypen
Data från RIS
Det huvudsakliga dataunderlaget som används i prototypen utgörs av en uppsättning undersökningskoder med en beskrivande text och antal utförda undersökningar per kod. Informationen exporterades från en av Sectras ut- vecklingsdatabaser för RIS. I samma tabell där alla undersökningstyper nns listade nns även en kolumn för Undersökningstid. Denna kolumn användes för att hämta värden för tidsattributet Us Personal för varje us-kod. Ingen närmare analys gjordes av var dessa värden kommer ifrån.
Antal utförda undersökningar för varje us-kod exporterades genom att summera antalet utförda undersökningar för ett tidsintervall på ett år. En viss ltrering gjordes för att minska omfattningen av datamängden vilket resulterade i ett betydligt färre antal undersökningar (ca 250 st) än vad som skulle användas i ett verkligt scenario (uppemot 900 st).
Övrig data
Det resterande dataunderlaget är påhittat eller hämtat från SPRI-rapporten. Ingen ansträngning gjordes för att få fram autentiskt kostnadsunderlag för
Figur 5.5: Konceptuell datamodell i form av ett ER-diagram för de objekt som ingår i beräkningen av direkta kostnader i prototypen.
personalkategorierna och därmed är de resulterande minutkostnaderna inte realistiska. Fokus låg på att skapa ett dataunderlag som gjorde det möjligt att implementera och demonstrera beräkningsprinciperna och prototypens funktionalitet på ett korrekt sätt. Korrektionsfaktorn användes som verktyg för att hitta en lämplig total arbetstid för respektive personalkategori som matchade den förbrukningsdata som hämtades från RIS.
5.2.4 Konceptuell datamodell
Den konceptuella datamodellen för prototypen utvecklades genom ER-modellering. Figur 5.5 visar det resulterande ER-diagrammet. Det består av fem enti- teter; Examination, Sta, TimeConsumer, ConsumedExamination och In- directCost. TimeConsumer motsvarar tidsattributen. ConsumedExamination är egentligen en många-till-många-relation mellan Examination och Time- Consumer, med ett attribut för tid, men av programmeringstekniska skäl modellerades den som en egen entitet. Den håller information om en under- söknings förbrukning av ett tidsattribut. Den femte entiteten, IndirectCost håller informationen om indirekta kostnader. Det saknar relationer till de andra entiteterna. Attributet DistributionType anger enligt vilken princip kostanden ska fördelas (se avsnitt 5.2.5).
5.2.5 Beräkningsprinciper
De beräkningsprinciper som används i prototypen är i grund och botten samma som används i MedEko och som beskrivs i SPRI-rapport 299. Det som skiljer är dels att prototypen tillåter en dynamisk uppsättning perso- nalkategorier och tidsattribut och dels att indirekta kostnader kan fördelas över undersökningskostnaderna istället för enbart på primärundersökningar. Detta avsnitt redovisar beräkningsprinciperna för dessa båda detaljer. Registrerad arbetstid för en resurs
Det är möjligt att de niera ett valfritt antal resurser (personalkategorier) och för varje resurs matas följande information in av användaren:
• Total kostnad per år • Total arbetstid per år
• Uppskattad administrativ tid per år
Varje resurs har ett antal tidsattribut kopplade till sig. Exempelvis kan resur- sen Läkare ha tidsattributen Us Läkare och Granskningstid kopplat till sig. För varje undersökning och tidsattribut anges en förbrukningstid. Skillnaden i beräkningen av direkt kostnad för en undersökning är hur den registrerade arbetstiden för varje resurs räknas ut, som i sin tur används för att beräkna korrektionsfaktorn.
Den sammanlagda registrerade arbetstiden, reg-arbtid, för en resurs er- hålls genom att för varje undersökning multiplicera de sammanlagda för- brukningstiderna, för de tidsattribut som är kopplade till aktuell resurs, med antalet utförda undersökningar per år och summera resultaten. Principen är densamma som i ekvation 2.2, med skillnaden att antalet tidsattribut här är dynamiskt. Beräkning av minutkostnad, oregistrerad arbetstid och korrek- tionsfaktor sker sedan enligt 2.1, 2.3 och 2.4.
Fördelning av indirekta kostnader på undersökningspris
För att fördela en indirekt kostnad på undersökningar baserat på deras di- rekta kostnad beräknas först en fördelningsfaktor F fram genom att dividera summan av alla resursers (r) totala direkta kostnad med den indirekta kost- naden som ska fördelas:
F = P
rreg-arbtidr× minutkostnadr× korrektionsf aktorr
Indirekt Kostnad (5.1)
Den indirekta kostnaden per undersökning beräknas sedan utifrån den direkta kostnaden för varje undersökning:
5.3 Resultatdiskussion
5.3.1 Flexibel beräkningsmodell
En målsättning med prototypen var att göra en mer exibel implementation av beräkningsmodellen. Bakgrunden till detta nns beskrivet i 4.2.3. Resul- tatet av målsättningen består dels av möjligheten att själv bestämma vilka personalkategorier och vilka tidsattribut man vill använda för att beräkna direkt kostnad för Perosnal, och dels möjligheten att fördela indirekta kost- nader direkt på undersökningspriserna. Detta är två nya koncept som inte nns med i MedEko eller i SPRI-rapport 299.