Generell modell för anpassningsbara journalsystemGeneral model for adaptable journal systems

(1)

INOM

EXAMENSARBETE

DATATEKNIK,

GRUNDNIVÅ, 15 HP

,

STOCKHOLM SVERIGE 2021

Generell modell för

anpassningsbara journalsystem

General model for adaptable

journal systems

ANDREAS OLSSON

ERIK WIKZÉN

KTH

(2)

(3)

Generell modell för

anpassningsbara

journalsystem

General model for adaptable

journal systems

ANDREAS OLSSON

ERIK WIKZÉN

Examensarbete inom Datateknik, Grundnivå, 15 hp

Handledare på KTH: Lars Olov Carlheim, Gunno von Zweigbergk Examinator: Ibrahim Ohran

TRITA-CBH-GRU-2021:035

KTH

(4)

(5)

Sammanfattning

Det finns ett behov av användarvänliga, anpassningsbara och tillgängliga journalsystem inom en variation av branscher. Befintliga system har visat sig vara bristfälliga inom dessa tre aspekter. Bristerna bottnar i att systemen sällan är anpassade för det specifika ändamålet, vilket i många fall grundar sig i att slutanvändarna inte varit med i utvecklingsprocessen. När användare har

implementerat befintliga journalsystem inom sina verksamheter har även bristfälligheter gällande tillgänglighet påvisats. På den utvecklade journalsystemprototypen som arbetet resulterade i, utfördes ett antal tester av uppdragsgivarens anställda. Dessa tester påvisade att prototypens användarvänlighet, anpassningsbarhet och tillgänglighet uppnådde de krav som företaget hade på ett journalsystem. Prototypen har, trots det positiva resultatet, fortfarande utvecklingspotential och områden att förbättra.

Nyckelord

(6)

(7)

Abstract

There is a need for user-friendly, customizable and accessible record systems in a variety of industries. Existing systems have proven to be deficient in these three aspects. The shortcomings are due to the fact that the systems are seldom adapted for the specific purpose, which in many cases is a consequence of the end users not being involved in the development process. When users have implemented existing journal systems within their operations, deficiencies regarding

accessibility have also been identified. On the developed record system prototype that the work resulted in, a number of tests were performed by the client's employees. These tests showed that the user-friendliness, adaptability and availability of the prototype met the requirements of the

company for a record system. Despite the positive result, the prototype still has development potential and areas for improvement.

Keywords

(8)

(9)

Förord

(10)

(11)

Ordlista

API - Application programming interface används för att olika program, applikationer och system enkelt ska kunna kommunicera med varandra.

CPU - Central Processing Unit är den enhet som exekverar program i en dator.

CRUD - (Create, Read, Update, Delete) dessa är de fundamentala elementen av beständig lagring i ett system.

HTTP - Hypertext Transfer Protocol är det kommunikationsprotokoll som används för att skicka data mellan en webbrowser och en webbsida.

JAR - Java ARchive används för att samla många Java-filer i en och samma fil för distribution. JSON - JavaScript Object Notation är ett kompakt, textbaserat format som används för att utbyta data och är enkelt för människan att både läsa och skriva.

REST - Representational State Transfer beskriver hur olika tjänster för maskin till maskin kommunicerar via webbteknologi.

SPA - Single page application är en webbapplikation eller hemsida som skriver om en befintlig sida med nya data från en webbserver, i stället för att ladda om en helt ny sida.

SQL - Structured Query Language är ett standardiserat programmeringsspråk som används för att modifiera och hämta data i en relationsdatabas.

(12)

(13)

Innehållsförteckning

1 Inledning ... 1

1.1 Bakgrund ... 1 1.2 Problemformulering ... 1 1.3 Målsättning ... 2 1.3.1 Förstudie ... 2 1.3.2 Mjukvaruutveckling ... 2 1.3.2.1 Webbapplikationen ... 2 1.3.2.2 Modellen ... 2 1.3.3 Utvärdering av modellen ... 2 1.4 Avgränsningar ... 2

2 Teori och bakgrund ... 5

2.1 Typer av journaler ... 5

2.1.1 Driftjournaler ... 5

2.1.2 Huvudfunktioner i digitala journalsystem ... 6

2.1.3 Patientjournal ... 6

2.2 Brister och begränsningar med förekommande journalsystem ... 7

2.2.1 Bristande användarvänlighet i patientjournaler för vårdpersonal ...7

2.2.2 Begränsad åtkomst till journaler tillhörande andra verksamheter ...7

2.3 Användarinvolvering vid utveckling av journalsystem ... 8

2.4 Organisationsuppbyggnad ... 8 2.5 JavaScript-ramverk ... 9 2.5.1 React ... 9 2.6 REST API ... 9 2.6.1 Spring Boot ... 9 2.7 Användargränssnitt ... 10 2.8 Molntjänst ... 10

2.8.1 Docker och containerbaserad driftsättning av mjukvara ... 10

2.8.2 Microsoft Azure ... 11

2.8.3 Heroku ... 11

3 Metoder och resultat ... 13

3.1 Förstudie ... 13

3.1.1 Litteraturstudie ... 13

3.1.2 Analys av befintligt använda journaler ... 14

(14)

3.2 Utveckling av journalsystemprototyp ... 16 3.2.1 Journalsystemsmodellen ... 16 3.2.2 Organisationsmodul ... 16 3.2.3 Webbapplikation ... 17 3.3 Val av molntjänst ... 17 3.4 Alternativa journalsystem... 18 3.5 Utvärdering av journalsystemprototyp ... 18 3.5.1 Utförande av tester ... 18 3.5.2 Intervjuer ... 19 3.6 Resultat av litteraturstudie ... 19

3.7 Resultat för analys av befintligt använda journaler ... 19

3.8 Resultat för sammanställning av en generell modell för journalsystem ... 20

3.9 Resultat för journalsystemprototyp ... 21

3.9.1 Journalmodul ... 21

3.9.1.1 Journalmodellen ... 21

3.9.1.2 Kontrollklass ... 22

3.9.1.3 Hanteringsklass ... 22

3.9.1.4 Journal repository interface ... 22

3.9.2 Verksamhetsmodul ... 23

3.9.2.1 Organisationsmodell ... 23

3.9.2.2 Kontrollklass ... 23

3.9.2.3 Hanteringsklass ... 23

3.9.2.4 Organisation repository interface ... 23

3.9.3 Webbapplikation ... 23

3.10 Resultat för utvärdering av journalsystemprototyp ... 26

3.10.1 Användarvänlighet ... 26

3.10.2 Anpassningsbarhet ... 27

3.10.3 Tillgänglighet ... 27

4 Analys och diskussion ... 29

4.1 Journalsystemprototypen... 29

4.1.1 Modell ... 29

4.1.2 Webbapplikation ... 29

4.2 Analys av respondenternas svar ... 30

4.2.1 Felkällor ... 30

4.2.2 Analys av resultat ... 31

4.3 Alternativ lösning för modellen ... 31

(15)

5 Slutsatser ... 35

5.1 Förslag på fortsatt arbete ... 35

Källförteckning ... 37

Bilaga A: Intervjufrågor ... 40

Bilaga B: Intervju med person 1 ... 41

Bilaga C: Intervju med person 2 ... 42

Bilaga D: Kod för journalmodellen ... 43

(16)

(17)

1 | INLEDNING

1 Inledning

I detta kapitel presenteras arbetets bakgrund, problemformulering, målsättning och avgränsningar.

1.1 Bakgrund

Cemi är ett företag som arbetar inom fyra olika verksamheter: fastighetsförvaltning, bygg och hantverk, utemiljö samt badanläggningar. Företaget använder sig för närvarande av driftjournaler i pappersform som är placerade i mappar som i sin tur är stationerade ute vid de olika anläggningar. För att kunna läsa en ifylld journal måste anställda åka till anläggningarna i företagets bilar, vilket är tidskrävande, kostsamt och ur en miljösynpunkt, skadligt. Anledningarna ovan skapar därför behovet från Cemis sida att implementera ett digitalt journalsystem inom sina verksamheter.

Det är önskvärt att användargränssnittet är lättanvänt och anpassat specifikt för varje verksamhet samt att det är lättillgängligt. Lättanvänt i mening att användaren kan navigera genom systemet på ett effektivt sätt och anpassat för varje verksamhet. Detta eftersom verksamheten för drift av vattenreningsverk i badanläggningar har behov att lagra information om badvattnets kvalitet samt skötsel av reningsverk. Medan verksamheten för fastigheter har behov av att lagra information för fastigheter, som temperatur och ventilationsflöden.

Cemi anser att journalsystem som för tillfället figurerar på marknaden inte uppfyller de krav som företagets fyra verksamheter har. Detta skulle tvinga Cemi att införskaffa olika journalsystem för varje enskild verksamhet.

Utöver ett lättanvänt användargränssnitt är det önskvärt att de olika verksamheterna inom Cemi ska ges möjligheten att kontrollera driftjournaler utfärdat av en annan verksamhet. Detta eftersom det förekommer sådana fall hos företaget. Exempelvis kan verksamheten för badanläggningar vara beroende av åtgärder gjorda av anställda hos fastighetsavdelningen. En reglering av

inomhustemperatur kan påverka temperaturen i badvattnet. Det skapar behovet att en verksamhet behöver åtkomst till journaler för en annan verksamhet, för hänsynstagande till externa åtgärder som kan påverka tillståndet för ett objekt.

För att användargränssnittet ska vara användbart för alla fyra verksamheterna ska ansvarande chef för varje verksamhet själv kunna skapa anpassade driftjournaler, med hjälp av den webbapplikation som komma att utvecklas.

1.2 Problemformulering

Det generella problemet som existerar hos dagens journalsystem är att de ofta är anpassade för en specifik verksamhet och kan därför inte tillämpas på ett önskvärt sätt hos andra verksamheter. I vissa fall tvingas verksamheter använda sig av journalsystem som inte är anpassade för deras ändamål, vilket ofta leder till att användarvänligheten fallerar. Utöver detta har olika verksamheter som är beroende av varandra ofta problem att få åtkomst till varandras journaler vid tillfällen då detta krävs. Något som kan bero på att organisationer använder olika journalsystem, som inte är kompatibla med varandra, för olika verksamheter som dessa verkar inom.

(18)

2 | INLEDNING

kunna använda den webbapplikation som skapas, med modellen som grund, och ta fram sina egna journaler som är anpassade för sina egna ändamål. Genom att använda ett och samma system inom en organisation kommer olika verksamheter inom organisationen att ha tillgång till andra

verksamheters journaler när tillfället kräver det.

1.3 Målsättning

Det huvudsakliga målet med projektet är att undersöka om det är möjligt att skapa en generell modell för journaler som kan tillgodose olika verksamheters behov och krav som kan förekomma på journalsystemet samtidigt som det är användarvänligt. Användarvänligt i form av att användare kan skapa, analysera och lämna uppgifter på ett intuitivt sätt.

1.3.1 Förstudie

Förstudien delas upp i flera delar innan arbetet påbörjas för att ha en grund att utgå ifrån. ● Analysera olika typer av journaler i form av patientjournal och driftjournaler för att hitta

likheter och skillnader mellan dessa.

● Analysera tillvägagångssätt vid utvecklande av journalsystem i tidigare arbeten. ● Undersöka problematik som finns i existerande journalsystem.

1.3.2 Mjukvaruutveckling

En användarvänlig, anpassningsbar och tillgänglig journalsystemprototyp kommer att utvecklas. För att uppnå detta i prototypen, genom en anpassningsbar modell för olika typer av branscher, ställs följande krav på prototypen:

1.3.2.1 Webbapplikationen

● Användaren ska kunna skapa en journal anpassad för sin verksamhet.

● Användaren ska kunna fylla i den skapade journalen med de värden som verksamheten kräver.

● Användaren ska kunna analysera journalen i efterhand.

1.3.2.2 Modellen

En generell modell som bidrar med anpassningsbarhet efter behov från användare utvecklas i en server som förser den utvecklade webbapplikationen med data.

1.3.3 Utvärdering av modellen

För att utvärdera om modellen är anpassningsbar för olika typer av branscher utförs en kvalitativ utvärdering utifrån följande kriterier, inom flera verksamheter:

● Går det, på ett effektivt sätt, att skapa en ny journal efter verksamhetens krav och behov? ● Går det att fylla i en skapad journal på ett önskvärt sätt?

● Går det att inspektera befintliga journaler på ett önskvärt sätt?

● Går det att inspektera andra verksamheters journaler på ett önskvärt sätt? ● Uppfyller journalsystemet de krav som verksamheten har på journaler?

1.4 Avgränsningar

Arbetets uppdrag formulerades till att endast undersöka användandet av journalsystem. Därav kommer inte någon typ av säkerhet i form av autentisering för användare att implementeras. Någon mer ingående analys av den data som användare lägger in i journalerna kommer inte att erbjudas i prototypen mer än att det ska vara möjligt att, i efterhand, kunna kontrollera

(19)

3 | INLEDNING

Funktionaliteter i den utvecklade tjänsten ska endast uppfylla krav för att utföra tester.

(20)

(21)

5 | TEORI OCH BAKGRUND

2 Teori och bakgrund

I följande kapitel beskrivs fakta och teori om olika typer av journalsystem och problematik som förekommer i dessa. Även tidigare arbetens förslag, på vad som kan göras annorlunda samt verktyg och ramverk som används för att utveckla prototypen av journalsystemet, presenteras.

2.1 Typer av journaler

En journal är ett formulär som används av verksamheter för att spara information om ett specifikt objekt eller en händelse. Den sparade informationen ger framtida läsare insikt i tidigare händelser och tillstånd för det specifika objektet [1]. Det möjliggör att verksamheter kan utföra analys på förekommande data.

2.1.1 Driftjournaler

När organisationer bedriver en verksamhet eller genomför åtgärder som kan medföra skada, antingen mot människors hälsa eller miljö, ska planering och kontroll av verksamheten göras kontinuerligt för att förebygga sådana effekter [2]. Dessa kontroller dokumenteras oftast i form av driftjournal enligt förordningen om verksamhetsutövares egenkontroll [3]. Några av de områden som tillämpar dessa typer av journaler vid olika typer av kontroller är bland annat badanläggningar, byggarbetsplatser, industrier, parkskötsel och fastighetsförvaltning.

Det finns en mängd olika journalsystem som tillhandahåller driftjournaler för de tidigare nämnda verksamheterna. Ett redan befintligt driftjournalsystem är BAD. BAD är ett webbaserat drift- och egenkontrollsystem speciellt framtaget för kontroll vid drift av badanläggningar, skapat av företaget EQSoft. EQSoft är ett företag som utvecklar mjukvara, driftsystem och andra IT tjänster samt äger och förvaltar fastigheter [4]. Ett exempel på hur deras BAD:s journaler ser ut kan ses i figur 2.1. Checkproof är ett annat typ av driftjournalsystem som assisterar med att optimera arbetet inom ett antal olika branscher: bygg och konstruktion, fordon och maskiner, marint, serviceföretag,

skidanläggningar och nöjesparker, tillverkande industri och uthyrningsföretag med hjälp av skräddarsydda protokoll för egenkontroll och ärenderapportering i mobilen [5]. Figur 2.2 är ett exempel på hur en ifylld journal ser ut i Checkproofs system.

(22)

Figur 2.2 Exempel på en ifyllda journal i Checkproofs system.

2.1.2 Huvudfunktioner i digitala journalsystem

Ett digitalt journalsystem bör ha minst två huvudfunktioner för att vara både användarvänligt och anpassningsbart [1]. Den första huvudfunktionen är att systemet ska vara processorienterat. Med processorienterat menas i kontexten att systemet automatiskt ska distribuera journalerna till rätt användare och verksamhet. Den andra huvudfunktionen är kontextmedvetenhet i systemet. I detta fall fokuserar kontextmedvetenhet på att journalerna i systemet ska vara skapade för det som ska undersökas. Inom vården är det patienten som ska undersökas och inom serviceverksamheter kan det vara en mängd olika saker bland annat en maskin eller anläggning. Med detta menas att endast relevant information ska visas i journalen för varje enskild verksamhet [1].

2.1.3 Patientjournal

Ett journalsystem inom vården är ett verktyg som används av vårdpersonalen med syfte att

(23)

Det existerar i skrivande stund sex journalsystem inom sjukvården som dominerar marknaden: TakeCare, Cosmic, Melior, Infomedix, VAS (Vårdadministrativt System) och SYSteam Cross. I alla dessa system, förutom VAS och SYStem Cross, är det möjligt att installera moduler individuellt vilket gör dem anpassningsbara till en viss grad beroende på vilken typ av verksamhet inom sjukvården som använder systemen [8].

2.2 Brister och begränsningar med förekommande journalsystem

Tidigare studier visar missnöje hos användare av befintliga journalsystem. IHP-undersökningen från 2015 visar att endast 37% av primärvårdsläkare i Sverige är nöjda med befintligt journalsystem [9].

2.2.1 Bristande användarvänlighet i patientjournaler för vårdpersonal

Grundorsaken till missnöjet med journalsystem inom vården är bristande användarvänlighet [10]. Sjuksköterskor som hanterar journalsystem, vid vård av patienter anger att det finns behov av anpassningsbarhet i journalsystemet. Anpassningsbarhet efterlyses på tre olika plan för att tillgodose ett mer användarvänligt journalsystem [11]. Önskvärda aspekter är personlig, efter avdelning och yrkesprofessionell anpassning. Genom att vårdpersonal kan anpassa journaler efter behov, möjliggör detta att systemet upplevs mer användarvänligt. Detta då endast aspekter och information som är relevant för personalen framställs i systemets journaler [11].

Det finns faktorer som gör att journalsystem blir mer ändamålsenliga ur läkarnas perspektiv. En betydande faktor för ändamålsenliga journalsystem inom primärvården är att systemet ska ange relevant information vid rätt tidpunkt för att läkare ska kunna vidta ändamålsenliga åtgärder [9].

2.2.2 Begränsad åtkomst till journaler tillhörande andra verksamheter

Händelser och tillstånd rörande ett objekt i fokus hos verksamheter kan ha en påverkan på andra objekt. Händelser rörande ett objekt utgörs av åtgärder utförda för att ändra objektets nuvarande tillstånd [12]. Ett tydligt exempel på detta är hur klorhalten i badvatten kan skapa behov för reglering av ventilationen i en bad- och simanläggning. Ventilationen i bad- och simanläggningar bör anpassas efter mängden gaser som bildas vid vattenytan för att undvika hälsorisker [13]. Gaser bildas till följd av att kemikalier, som klor, används i badvatten. Här påverkar händelsen “ökad dosering av klor” hos objektet “badvatten” villkoren för objektet “ventilation” som bör åtgärdas till följd av den ökade klordoseringen.

För företaget Cemi innebär det att en åtgärd som ökning av klorhalten i badvattnet utförd av verksamheten för drift av vattenreningsverk i bad- och simanläggningar har en påverkan på mängden gas vid vattenytan. I sin tur medför det att åtgärder för ventilationen måste utföras av verksamheten för drift av anläggningen, för att undvika hälsorisker. Det visar att händelser kopplat till ett objekt som är av intresse för en verksamhet kan ha en påverkan på tillståndet för objekt som är av intresse för en annan verksamhet.

Klarläggande av förekommande skillnader i ambitioner för strategi och de reella upplevelser läkare ger uttryck för, vid användandet av journalsystem, kan ge stöd för systemutvecklare genom att ta lärdom av tidigare misstag vid utvecklandet av nya journalsystem [14]. Resultatet av en

(24)

2.3 Användarinvolvering vid utveckling av journalsystem

Experter inom området, där journalsystemet ska användas, är en faktor att ta hjälp av vid utvecklandet av journalsystem [16].

I en kandidatuppsats av Linus Bratt och Louise Jägerstad, undersöker de hur mycket medverkan, vid utvecklande av journalsystem, användare har [17]. Några av användarna av systemen

medverkade i undersökningen i form av intervjuer. Bland dessa användare är det en

barnoftalmolog, två läkare och en sjuksköterska. Samtliga tillfrågade ansåg sig inte ha något att säga till om, varken gällande journalhanteringen eller beslut som tas om systemen. Att slutanvändarna får medverka vid systemutvecklingen samt att deras synpunkter tas i beaktning är något samtliga tillfrågade skulle vilja se mer av. Detta för att kunna skapa ett mer användarvänligt och anpassat journalsystem [17]. En kvalitativ intervjustudie om vilka faktorer som påverkar acceptans för journalsystem utfördes inom region Kronoberg. I studien kom de fram till att om utvecklarna kontinuerligt lyssnar på feedback från slutanvändaren kan designval av digitala journalsystem optimeras, något som höjer användarvänligheten och användbarheten, vilket således ökar acceptansen [18].

I en annan studie undersöktes det om användarinvolvering är ett viktigt element i ett användarvänligt journalsystem inom vården. Studien påvisade just detta, nämligen att

användarinvolvering är ett viktigt tillvägagångssätt för att identifiera användarnas behov och genom detta anpassa systemet efter de identifierade behoven [14].

2.4 Organisationsuppbyggnad

I verksamheter och organisationer förekommer det strukturer till uppbyggnaden av verksamheten. I Cemis fall existerar ett flertal verksamheter inom företaget. Varje verksamheter har ett antal

(25)

Figur 2.3 Del av organisationsstrukturen för Cemi AB.

Samma princip gäller för sjukvården. Där utgör region Stockholm roten som förgrenar sig till olika sjukhus. Sjukhusen har i sin tur olika avdelningar där varje avdelning kan ha flera arbetsområden osv. Varje organisation och verksamhet utgörs av en trädstruktur där personer av intresse, som exempelvis anställda och patienter, förekommer på olika nivåer i trädstrukturen beroende på personens verksamhetsområde [19].

2.5 JavaScript-ramverk

JavaScript ramverk renderar färdigskriven JavaScript kod som producerar programmeringsfunktioner som underlättar utvecklingsprocessen av ny kod.

2.5.1 React

React (även känt som React.js eller ReactJS) är ett frontend, öppen källkod, JavaScript bibliotek, vilket används för att bygga användargränssnitt eller komponenter för användargränssnitt. React utvecklas och underhålls av Facebook Inc och ett samfund av individuella utvecklare och företag. React kan användas som grund vid utvecklande av SPA, och mobila applikationer [20].

2.6 REST API

Ett REST API är ett sätt för två datorsystem att kommunicera över HTTP, likt hur en webbrowser och en server kommunicerar [21]. REST genererar HTTP förfrågningar som utför CRUD

operationer på data, som returneras i JSON format [22].

2.6.1 Spring Boot

(26)

Spring Boot gör det enklare att distribuera fristående applikationer i produktionskvalitet med mycket liten konfigurering. Spring tillhandahåller flera autokonfigurationsinställningar för att starta upp en applikation med vilka beroenden som helst. Till skillnad från att identifiera ramverksberoenden och associerade bibliotekversioner, som måste finnas för att utveckla en applikation, tillhandahåller Spring Boot enklare beroendehantering. Detta utförs genom användning av ett omfattande och samtidigt flexibelt ramverk, tillsammans med de associerade biblioteken, i ett enda beroende. Det här tillgodoser alla Spring relaterade teknologier som behövs för att starta projekt jämfört med CRUD webbapplikationer. Webbapplikationer är generellt paketerade som WAR och driftsatta till en webbserver [23]. Spring Boot applikationer paketeras antingen som WAR eller JAR filer vilket tillåter applikationen att köras utan att behöva installera eller konfigurera det i applikationsservern [24].

2.7 Användargränssnitt

I en undersökning utförd av Ali Darejeh och Dalbir Singh, doktorander inom datateknik, undersöktes design av användarvänliga användargränssnitt för ovana datoranvändare. Undersökningen resulterade i sju principer (se tabell 2.1) [25]. Dessa sju principer kan användas vid utveckling av användarvänliga användargränssnitt.

Tabell 2.1 Alis och Dalbirs sju principer för användarvänligt användargränssnitt.

1 Reducera antalet tillgängliga funktioner överallt i systemet.

2 Designa gränssnittet för att användaren inte ska behöva utreda var olika verktyg är. 3 Använd stora komponenter och ikoner för att visa huvudfunktioner av mjukvaran. 4 Undvik att använda facktermer i gränssnittet.

5 Tillhanda möjligheten att ändra, font, färg och storlek. 6 Använd ett beskrivande språk runt om i systemet. 7 Använd lämpliga ikoner.

2.8 Molntjänst

Molntjänster är leveransen av datatjänster, här inräknat: servrar, lagring, databaser, nätverk, mjukvara, analysering och intelligens över internet “molnet” för att erbjuda snabbare, innovativare, flexiblare resurser och billigare lösningar i en stor skala. Kunderna betalar vanligtvis endast för molntjänsterna som används, vilket oftast sänker kostnaderna för användaren gentemot andra alternativa lösningar. Molntjänster erbjuder även möjligheten att driftsätta infrastruktur mer effektivt och möjliggör även att expandera en verksamhet om det skulle krävas [26].

2.8.1 Docker och containerbaserad driftsättning av mjukvara

(27)

2.8.2 Microsoft Azure

Microsoft Azure är en molnplattfrom utvecklad av Microsoft som används för att skapa och driftsätta webbapplikationer via Microsofts egna datacenter [26].

Azure Container Registry är en tjänst i Microsoft Azure som möjliggör lagring och hantering av containeravbilder. Förekommande containeravbilder kan byggas och köras som containerinstanser på Microsoft Azure [29].

Driftsättning av databaser är en tjänst i Microsoft Azure. Det erbjuds tjänster för MySQL databaser där användare kan anpassa lagringsutrymme, säkerhet och tillgänglighet [30].

2.8.3 Heroku

(28)

(29)

13 | METODER OCH RESULTAT

3 Metoder och resultat

Kapitlet för metoder och resultat tar upp metodik i utförandet av arbetet med motiveringar till val utförda under arbetets gång. Metodiken för utförandet börjar med en förstudie till arbetet

innehållande en litteraturstudie, analys av befintligt använda journaler samt sammanställande av en generell modell för journalsystem. Metodiken beskriver utvecklandeprocessen av journalsystemet samt motivering till val av molntjänst för driftsättning av systemet. Avslutningsvis för metoder tar metodiken, till utförandet, upp utvärdering av journalsystemprototypen i avsnitt 3.5.

Resultatet till förstudien framställs i avsnitt 3.6, 3.7 och 3.8 som anger resultat för litteraturstudien, resultat för analys av befintligt använda journaler samt den resulterande generella modellen för journalsystemet. Avsnitt 3.9 framställer resultatet av den utvecklade journalsystemsprototypen. Avslutningsvis framställs resultatet för utvärderingen av det utvecklade systemet i avsnitt 3.10.

3.1 Förstudie

Arbetets förstudie utfördes i tre moment. Det första momentet utgjordes av en litteraturstudie. Litteraturstudien utfördes i syfte att hitta tidigare arbeten och dokumentation om problematik med befintliga journalsystem som används inom olika typer av verksamheter och med den

informationen klargöra befintlig problematik i journalsystem. Det andra momentet analyserar journaler som används av verksamheter. En analys av journaler utfördes i syfte att kartlägga likheter och skillnader mellan journaler som används inom olika typer av verksamheter. Det tredje utförda momentet sammanställde en generell modell för journalsystem. Det syfte som

sammanställningen av en generell modell hade, grundade i att tillgodose en potentiell lösning för den problematik som existerar i befintliga journalsystem.

3.1.1 Litteraturstudie

Litteraturstudien som genomförts är av typen kritisk litteraturgranskning. Sökstrategier för projektet har till största del byggt på sökorden patientjournal och driftjournal. Dessa sökningar utfördes i databaserna Google Scholar, IEEE Xplore och Diva Portal. När sökandet av väsentliga artiklar och uppsatser utfördes blev mängden sökträffar stor, vilket medförde att mer precision av sökord och applicering av flera filter krävdes. Selektionen av information delades upp i två steg. Det första steget innebar att läsa titel, sammanfattning och resultat. Om första steget resulterade i relevans påbörjades andra steget, vilket innebar att läsa resterande delar i artikeln, om första steget inte resulterade i relevans lämnades artikeln.

Syftet med litteraturstudien av tidigare arbeten, kopplat till patientjournalsystem, grundade i att finna potentiella brister och begränsningar i dessa lösningar. Artiklar och uppsatser som tar upp vad som har genomförts och vad som kunde gjorts annorlunda inom områden där journaler och

journalsystem används, tillämpas också i arbetet. Sökområdet begränsades till sjukvården och med djupare fokus inom den svenska primärvården och specialistvården. I det första selektionssteget av data valdes de åtta sökträffar som ansågs mest relevanta för varje område. Dessa områden är relevanta i den mening att de berörde det som ska undersökas. Artiklar som utelämnades i det andra urvalet, var sådana som endast undersökte integrationsmöjligheterna mellan

(30)

Artiklar bedömdes som relevanta, vid granskning av tidigare arbeten med koppling till

driftjournalsystem, om de berörde bristfälligheter gällande användarvänlighet, anpassningsbarhet och tillgänglighet i ett driftjournalsystem som används av någon av de verksamheter som Cemi verkar inom. I det första selektionssteget av data valdes sex sökträffar som ansågs relevanta för områden rörande Cemis verksamheter. I det andra selektionssteget valdes de tre sökträffar som påvisade tidigare nämnda brister i befintliga driftjournalsystet, vilket resulterade i totalt tre sökträffar.

3.1.2 Analys av befintligt använda journaler

En förstudie utfördes i form av analys av två befintliga journaler som används inom verksamheterna, (se figur 3.1 och figur 3.2). Journalerna valdes med motivering att

användningsområdet skulle vara från två olika verksamheter där en variation av journalens struktur förekommer. Variation i journalens struktur syftade på att olika typer av notationer och olika mängd ifyllbara fält. Förekommande skillnader på journalerna gav utrymme för hänsynstagande till skillnaderna i utförandet av analysen. Den första journalen är en driftjournal för

vattenreningssystemet vid bad- och simanläggningen Parkmöllan, använt av Cemi när underhåll av anläggningen utfärdats (se figur 3.1). Den andra journalen är en driftjournal för underhåll av kylanläggningar skapad för företaget Huurre (se figur 3.2).

(31)

Figur 3.2 Huurre driftjournal för kylanläggningar.

(32)

3.1.3 Sammanställning av en generell modell för journalsystem

När resultatet från analysen av befintliga journaler hade sammanställts, utfördes en

sammanställning av de parametrar som utgör modellen till systemet. Varje likhet som resulterades av analysen undersöktes utifrån antalet parametrar den kan utgöras av. När endast en parameter krävdes, identifierades en relevant datatyp för parametern. Om det krävdes flera parametrar för att representera likheten, skapades en klass med parametrarna, vilket utgörs av relevanta datatyper. Den resulterade modellen framställs i kapitel 3.8.

3.2 Utveckling av journalsystemprototyp

Till följd av förstudien utvecklades en journalsystemsprototyp för att kunna utvärdera om en generell modell för journalsystem tillgodoser en lösning på den resulterade problematiken från förstudien.

3.2.1 Journalsystemsmodellen

Modellen för journalsystemet utvecklades utifrån resultatet förstudien bidrog med, vid framtagandet av den generell modellen. Det objektorienterade programmeringsspråket Java nyttjades för att modellera klasserna som representerade uppbyggnaden av journaler i systemet. Det gav möjligheten att efterlikna den verkliga strukturen för journaler på ett digitalt

tillvägagångssätt.

Java valdes som språk vid utvecklandet av modellen för journaler med anledning av att det är ett objektorienterat programmeringsspråk. Eftersom journaler är objektet i fokus, möjliggör Java en förenklad utveckling av objektklassen som tillhandahåller modellen för journaler i systemet. Möjligheten att skapa modeller för objekt förekommer i språk som inte är objektorienterade. Ett exempel på detta är programmeringsspråket C som inte är objektorienterat. Trots detta kan språket ändå uppfylla objektorienterade egenskaper genom att skapa abstrakta datatyper med hjälp av .h filer [32]. Av den anledningen valdes Java, eftersom Java i det här fallet möjliggjorde en underlättad utvecklingsprocess. Detta eftersom, hänsyn till hantering av ytterligare förekommande filer vid skapandet av modellen, inte behövdes.

Den framtagna modellen utvecklades i Java med stöd från ramverket Spring Boot. Spring Boot möjliggör en RESTful tjänst vilket tillåter att förfrågningar om hämtning och hantering av data kan utföras. En klass för kontroll av möjliga metoder att anropa utvecklades med syfte att kontrollera och begränsa användare till ett urval av funktioner som bidrog med hämtning och hantering av data. För hantering av data utvecklades en klass som utgick från strukturen av data utifrån den utvecklade modellen. Hanteringsklassen har till uppgift att hantera data beroende på anropad funktion.

3.2.2 Organisationsmodul

Som angivet i avsnitt 2.4 förekommer det en struktur för organisationsuppbyggnad. En organisation består av en eller fler verksamheter. Verksamheterna kan i sig ha ytterligare verksamheter eller objekt i fokus. För hänsynstagande till strukturen för organisationer utvecklades en modul för en organisation och förekommande verksamheter.

(33)

organisationer utgörs av en modell, där organisationer är objekt, är ett objektorienterat språk lämpligt. Anledningen är densamma som presenterades i avsnitt 3.2.1, det vill säga en underlättad utvecklingsprocess.

Framtagandet av modellen för organisationer utfördes med hänsyn till strukturen för organisationer och att journaler förekommer på olika nivåer i en organisations verksamhet, som är angivet i avsnitt 2.4. Hänsyn togs till struktur för organisationer då modellen skulle tillfredsställa en önskad ordning på journaler som organisationen har.

3.2.3 Webbapplikation

I journalsystemprototypen utgörs användargränssnittet av en webbapplikation. Webbapplikationen är framtagen med hjälp av React.js. Detta ramverk användes i utvecklandet av ett flertal

anledningar. Framför allt nyttjas React.js eftersom det är flexibelt och erbjuder låg CPU användning [20]. Flexibiliteten och den låga CPU användningen som erbjuds möjliggör utveckling av effektiva webbapplikationer som kan nyttjas i mobiltelefoner, eftersom dessa enheter oftast har en lägre prestanda. Detta är relevant eftersom systemprototypen ska användas i mobiltelefoner. Utöver flexibilitet och effektivitet är det enkelt att testa webbapplikationen under

utvecklingsprocessen. Enkelheten i testningen reflekteras vid implementering av ny kod, genom att webbapplikationen uppdateras omedelbart. Detta leder till att utvecklingsprocessen effektiviseras, vilket var av högsta vikt eftersom arbetet hade en tidsbegränsning.

Webbapplikationen utformades efter de konstaterade kraven användare från förstudien hade på journalsystem. Dessa användare hade möjligheten att vara delaktiga i utvecklingsprocessen av journalsystem som utvecklas [14][17]. Detta genom en anpassningsbar modell, med ett anpassningsbart användargränssnitt, som gav användaren möjlighet att själva utveckla sina journaler efter sina behov.

Alis och Dalbirs sju principer [25] tillämpades för att tillhandahålla ett användarvänligt användargränssnitt som även är lättanvänt för människor med mindre datorerfarenhet. Detta genom ett minimalistiskt användargränssnitt med få funktioner, beskrivande funktionsnamn och lämpliga ikoner. Få funktioner i den mening att gränssnittet direkt visar funktioner som

tillhandahålls i systemet utan undermenyer att gå emellan. De funktioner som användaren har tillgång till har namn som tydligt beskriver funktionaliteten för dessa, med visst stöd från tydliga ikoner. Till exempel är en papperskorg placerad bredvid objekten i systemet, som användaren kan trycka på när denne vill radera ett valt objekt och ett plustecken när användaren vill addera någonting till journalen.

3.3 Val av molntjänst

Journalsystemet utvecklades lokalt i utvecklarnas programmeringsmiljö. För att användarna hos Cemi, skulle få tillgång till systemet ute på anläggningarna hade en lokal server behövts driftsättas hos varje enskild anläggning som företaget verkar inom. Servern skulle även tvingas vara

(34)

För att journalsystemet skulle kunna förbättra Cemis situation vad det gäller driftjournaler,

driftsattes applikationen molnet. Det som en molnbaserad tjänst bidrar med är att användaren kan ha åtkomst till systemet överallt i världen, förutsatt att användaren är uppkopplad till ett nätverk eller mobildata [23][31]. När val av molntjänst skulle genomföras, stod valet mellan två tjänster, Microsoft Azure och Heroku.

Heroku har till syfte att göra det enkelt för utvecklare att bygga och driftsätta webbapplikation i molnet [31]. Medan Microsoft Azure möjliggör för utvecklare att nyttja hela Microsofts ekosystem och dra nytta av olika integrationer såsom Microsoft SQL Server databas [26]. Detta är några av styrkorna som de två molntjänsterna besitter. Detta medförde att Heroku användes för att driftsätta webbapplikationen och Microsoft Azure nyttjades för att driftsätta hela backend, databasen

inkluderat.

3.4 Alternativa journalsystem

De system som presenterats i 2.1 är alla tillgängliga på marknaden och skulle av den anledningen kunna användas av Cemi. BAD skulle kunna implementeras vid Cemis badanläggningar och

Checkproof inom Cemis andra serviceområden. Nackdelen, bortsett från kostnaden som uppstår vid användningen av flera olika driftjournalsystem, är att anställda på företaget som arbetar inom flera olika verksamheter tvingas lära sig båda systemen. Alternativt skulle Cemi kunna välja att använda Checkproof inom alla verksamheter, även på de anläggningar som journalsystemet inte är lämpat för. Detta skulle däremot leda till att systemet inte längre är ändamålsenligt.

Utöver detta är journalsystemen som är anpassade specifikt för sjukvården, inte ett alternativ för Cemi eftersom företaget inte verkar inom sjukvården. Av dessa anledningar, nämligen att inga tidigare journalsystem täcker alla de verksamheter som Cemi verkar inom, utvecklades journalsystemprototypen för företaget.

3.5 Utvärdering av journalsystemprototyp

Användartester tillämpades som utvärderingsteknik för att utvärdera journalsystemsprototypen. Tekniken valdes utifrån de fördelar som användartester besitter. Användartester är en väsentlig del för att verifiera att de funktioner som systemet erbjuder uppfyller användarnas förväntningar [33].

3.5.1 Utförande av tester

Den internationella standarden ISO 9241–11 är en standard för användbarhet i mjukvarusystem [34]. I standarden används det tre nyckelord som beskriver användbarhet. De tre nyckelorden är effektivitet, ändamålsenlighet och tillfredsställelse.

De framtagna testerna som två anställda på Cemi skulle utföra definierades för att täcka standarden för användbarhet och kontrollera de sju principerna för användbarhet [25]. Användarna tillämpade det utvecklade journalsystemet inom sin verksamhet, likt de befintliga pappersjournalerna.

3.5.1.1 Testuppgifter

● Första uppgiften som användaren tilldelades byggde på att skapa en helt ny journal. Journalen skulle anpassas för verksamheten som användaren verkar inom.

● I den andra uppgiften skulle användaren fylla i den skapade journalen med de värden/notering som verksamheten kräver.

(35)

● Som sista uppgiften skulle användaren kontrollera en annan verksamhets journaler.

3.5.2 Intervjuer

Efter utförda tester besvarade användarna ett antal frågor (se bilaga A). Dessa frågor täcker de områden som arbetets syfte ligger till grund för. Svaren som genererades från frågorna nyttjades sedan som stöd för att utvärdera systemprototypens användbarhet, anpassningsbarhet och tillgänglighet.

3.6 Resultat av litteraturstudie

Från litteraturstudien av tidigare arbeten togs två brister fram samt förslag på hur bristerna kunde elimineras. Den första bristande egenskapen som figurerar i många av de journalsystem som används, ofta inom vården, är användarvänligheten. Användare uttrycker att systemen bör vara anpassningsbara, i mån av de tre olika aspekterna nämligen person, avdelning och yrkesprofession. Personalen anser att om systemet är anpassningsbart och täcker alla tre aspekterna, då upplevs systemet som ändamålsenligt och sålunda användarvänligt [11].

Det andra problemet som upptäcktes i litteraturstudien var att många av de journalsystem som figurerar på marknaden inte tillhandahåller funktionaliteten att distribuera ifyllda journaler mellan olika verksamheter [15]. Detta leder till att verksamheter som är i behov av information från en annan verksamhets journaler inte längre kan garantera människors hälsa eller miljömässiga effekter [13].

Förslag på vad som kan göras annorlunda i utvecklandet av ett användarvänligt journalsystem är att utvecklarna involverar dem som komma att använda systemet [14][17]. Genom detta

tillvägagångssätt vid utvecklandet är funktioner, tabeller och inmatningsfält anpassade för användarna, vilket resulterar i ett ändamålsenligt journalsystem.

3.7 Resultat för analys av befintligt använda journaler

Det första utkastet av likheter och skillnader gjordes mellan två olika journaler, från två olika företag och verksamheter. En journal från Cemis vattenrening i bad- och simanläggningar och en journal från företaget Huurre, vid drift av kylanläggningar. Analyseringen mellan de två journalerna resulterade i följande:

Likheter:

- Objekt i fokus. (Anläggning/System) - Datum när journalen fylldes i. - Titel på Journalen.

- Signatur från personen som fyllde i/utfärdade en anteckning i journalen. - Övrig anteckning.

- Formulär.

Skillnader:

- Vad som noteras i ett fält. - Antal parametrar

(36)

- Hur frekvent journalen fylls i.

Det andra utkastet resulterade i en lista med endast likheter. Detta till följd av analys på gemensamma drag i de förekommande skillnaderna. De resulterande likheterna blev följande:

Likheter:

- Objekt i fokus. (Anläggning/System) - Datum journalen fylldes i.

- Titel på Journalen.

- Signatur från personen som fyllde i/utfärdade en anteckning i journalen. - Övrig anteckning. - Formulär - Frekvens - Fält med noteringar - Noteringar - Notationstyp - Ifyllbart textfält - Ifyllbart nummerfält - Ifyllbar checkruta - Ifyllbart procentfält - Statisk text

Gemensamheter som förekom i de olika skillnaderna är variation i hur ofta journalen fylls i, den här gemensamheten anges som frekvens. Ett gemensamt drag är att formulär består av ett antal fält. Det som fylls i och hur det fylls i kan gemensamt anges som noteringar som har en notationstyp. Genom detta blev resultatet att en journal består av formulär. Formulär som består av fält, fält består av noteringar och noteringar har en notationstyp. Notationstyper utgörs av ifyllbara textfält, ifyllbara nummerfällt, ifyllbara checkrutor, ifyllbara procentvärden och statisk text.

3.8 Resultat för sammanställning av en generell modell för journalsystem

Som angivet i avsnitt 3.1.3 sammanställdes en modell för journaler i systemet utifrån resultatet av analys på befintliga journaler. Sammanställningen av den generell modellen, för journaler i systemet, resulterade i följande.

Figur 3.3 Klass-diagram av modellen.

● Journal består av ett id och ett modellformulär som utgör mallen för formulären och en lista med alla ifyllda formulär.

● Form består av ett id, datum för ifyllning av formuläret, signatur av den som fyllt i formuläret och en lista med fält som utgör formuläret.

● Field består av ett id samt en lista med notationer som utgör fältet.

(37)

● NotationType är en Enumeration, vilket är alla typer av notationer som förekommer i systemet.

3.9 Resultat för journalsystemprototyp

Utvecklandet av journalsystemprototypen resulterade i tre tjänster som utgör systemprototypen och en databas för lagring av data. De förekommande tjänsterna i systemet är en modul för

journalhantering, en modul för organisationshantering samt ett användargränssnitt i form av en webbapplikation.

3.9.1 Journalmodul

Utvecklandet av mjukvaran för journalmodellen resulterade i en tjänst som hanterar ärenden i systemet specifikt ägnade åt journalhantering. Tjänsten innehåller modellen för journalen, en kontrollklass, en hanteringsklass samt interface för transaktioner till databasen.

3.9.1.1 Journalmodellen

Utifrån det angivna resultatet i avsnitt 3.8 utvecklades modellen för journalsystemet med programmeringsspråket Java. Den utvecklade modellen utgörs av följande klasser.

● JournalDAO ● FormDAO ● FieldDAO ● NotationDAO

Klassen JournalDAO består av fem parametrar (se bilaga D, figur 1). ● journalId, utgörs av datatypen Long.

● title, utgörs av datatypen String. ● object, utgörs av datatypen String.

● modelForm, utgörs av datatypen FormDAO. ● forms, utgörs av datatypen List<FormDAO>.

Klassen FormDAO består av fyra parametrar (se bilaga D, figur 2). ● formId, utgörs av datatypen Long.

● date, utgörs av datatypen Date. ● signature, utgörs av datatypen String. ● fields, utgörs av datatypen List<FieldDAO>.

Klassen FieldDAO består av två parametrar (se bilaga D, figur 3). ● fieldId, utgörs av datatypen Long.

● notations, utgörs av datatypen List<NotationDAO>.

(38)

● notationType, utgörs av en enumeration NotationType (se bilaga D, figur 5). ● text, utgörs av datatypen String.

I samtliga klasser som utgör modellen för journaler i systemet har varje parameter två tillägnade metoder. En set-metod som ger parameter ett nytt angivet värde samt en get-metod som returnerar parameterns värde.

För klargörande exempel om journalmodellens struktur med ifyllda värden, se bilaga E.

3.9.1.2 Kontrollklass

Kontrollklassen JournalController består av fyra metoder som utgör systemets REST API. ● getJournalsByObject returnerar alla ifyllda formulär till journalen för ett objekt. ● Metoden getModelJournalByObject returnerar journalmallen för ett objekt.

● Metoden addFilledJournalByObject lägger till ett ifyllt formulär i journalen för ett objekt. ● Metoden addNewJournalByObject skapar en ny journal för objekt.

Metoderna i JournalController utför ingen logik eller hantering av data utan kallar endast på metoderna i hanteringsklassen.

3.9.1.3 Hanteringsklass

Hanteringsklassen JournalService har fyra metoder som anropas av JournalController. Metoderna i hanteringsklasserna hanterar data så inkommande data är anpassat för lagring enligt

journalmodellen samt att utgående data är anpassat för användargränssnitt. Förekommande metoder är följande.

● getJournalDtosByObject, hämtar ifyllda formulär i journalen för ett objekt och strukturerar om formulären till ett format, anpassat för användargränssnitt, som returneras.

● getModelJournalByObject, hämtar journalmallen för ett objekt och strukturerar om mallen till ett format, anpassat för användargränssnitt, som returneras.

● addFilledJournalByObject, tar emot ett ifyllt formulär som struktureras om utifrån journalmodellen och läggs till i listan med ifyllda formulär för ett objekts journal.

● addNewJournalByObject, tar emot data som beskriver en ny journal och hanterar data för att skapa en ny journal för det angivna objektet.

3.9.1.4 Journal repository interface

För tillgång till databasen skapades flera interface förlängda av spring-ramverkets CrudRepository bibliotek. Ett interface förekommer för varje klass som modellen består av. Följande interface har utvecklats:

● JournalDaoRepository ● FormDaoRepository ● FieldDaoRepository ● NotationDaoRepository

(39)

3.9.2 Verksamhetsmodul

Utvecklandet av modulen för organisation- och verksamhetshantering resulterade i en tjänst skriven i programmeringsspråket Java med ramverket Spring Boot. Tjänsten hanterar ärenden och innehåller funktionalitet specifikt ägnat åt organisationer och verksamheter. Tjänsten utgörs av modellen för organisationer, en kontrollklass, en hanteringsklass samt interface för transaktioner till databasen.

3.9.2.1 Organisationsmodell

Den resulterande modellen för organisationer utvecklades med programmeringsspråket Java. Modellen för organisationer i systemet består av klassen OrganisationDAO. Förekommande parametrar som utgör modellen är följande.

● organisationId, utgörande av datatypen Long. ● orgName, utgörande av datatypen String.

● subOrgs, utgörande av datatypen List<OrganisationDAO>

Varje parameter i modellen för organisationer har två metoder. En get-metod som returnerar värdet för parametern samt en set-metod som sätter parametern till ett angivet värde.

3.9.2.2 Kontrollklass

Kontrollklassen OrganisationController består av en metod som utgör systemets REST API. ● getAllOrganisations returnerar alla registrerade organisationer.

Metoderna i JournalController utför ingen logik eller hantering av data utan kallar endast på metoder i hanteringsklassen.

3.9.2.3 Hanteringsklass

Hanteringsklassen OrganisationService har en metod som anropas av OrganisationController. Metoden i hanteringsklassen hanterar data, utgående data är anpassat för användargränssnitt. Den förekommande metoden är getAllOrganisations som hämtar alla organisationer och strukturerar informationen till ett format för användargränssnittet som sedan returneras.

3.9.2.4 Organisation repository interface

För tillgång till databasen skapades interface förlängt av spring-ramverkets CrudRepository bibliotek. Det skapade interfacet är OrganisationDaoRepository.

Metoder för skapade interface används i klassen OrganisationService vid behov av tillgång till databasen. Behov av tillgång är vid lagring, hantering och hämtning av data.

3.9.3 Webbapplikation

Webbapplikationen är utformad att endast aktivera den funktionalitet som är tillgänglig. Ett

(40)

Figur 3.4 Webbsidans förstasida där användaren väljer verksamhet.

Efter att ha valt objekt vid förstasidan är webbapplikationens utformning därefter utvecklad för att ge en helhetsbild av journalsystemet (se figur 3.5). Detta genom att användaren får tillgång till alla funktioner i form av beskrivande namn på länkar till de olika sidorna som webbapplikationen tillhandahåller. Ska användaren till exempel analysera tidigare ifyllda journaler klickar användaren på länken “View journal” och får därefter upp alla journalerna för just detta objekt (se figur 3.6). Objekt är allt från en patient till en badanläggning. På sida kan användaren bläddra mellan de olika journalerna och analysera dessa.

(41)

Figur 3.6 En ifylld journal, synlig efter att ha klickat på “View Journal”.

Vid skapande av journaler klickar användaren sig till “Create journal”. Här tillhandahålls fyra olika alternativ, i form av knappar, för att lägga till rader i journalen (se figur 3.7). De olika alternativen är textfält, checkbox, värde eller procentfält.

(42)

adderas, vid skapande av journaler, för att användare ska kunna fylla i till exempel ett mätvärde som kontrollerat vid en anläggning. Procentfältet kan användas för att fylla verkningsgraden för exempelvis en motor, rent procentuellt. Checkboxen nyttjas bland annat när någonting, antingen kontrollerats eller om någonting är godkänt eller icke godkänt. Utöver dessa fyra fält, kan användaren även addera ett eller flera anteckningsfält för varje enskilt huvudalternativ. Ett anteckningsfält kan användas om någonting behöver förtydligas vid till exempel en mätning av något slag.

Användaren fyller eller kryssar i de fälten som existerar i journalen som tidigare har skapats, specifikt anpassad för verksamheten (se figur 3.8). De fält som användaren har fyllt i med mätvärden, godkännanden, noteringar eller liknande i journalen, skickas efter att ha klickat på submit, till REST API:et och lagras därefter i databasen.

Figur 3.8 Användaren fyller i en journal, synlig efter att ha klickat på “Fill in journal”.

3.10 Resultat för utvärdering av journalsystemprototyp

Som 3.5 presenterat, testas systemprototypen av två anställda hos Cemi utifrån ett antal punkter. Person 1 jobbar inom verksamheten bad- och simanläggningar och person 2, chef inom

verksamheten fastighetsförvaltning. När testerna genomförts svarade användarna på de

fördefinierade frågorna (se bilaga A). Respondenternas svar på frågorna användes sedan som stöd för att utvärdera systemprototypen (se bilaga B och Bilaga C). Utvärderingen genererade resultat för journalsystemets användarvänlighet, anpassningsbarhet och tillgänglighet.

3.10.1 Användarvänlighet

Vid utförandet av intervjuerna svarade båda respondenterna att det är möjligt att fylla i de skapade journaler i systemet på ett önskvärt sätt. Person 1 beskrev att “ifyllningen är enkel” och person 2 beskrev att “det var enkelt att fylla i en journal”.

Vid frågan om det gick att inspektera befintliga journaler på ett önskvärt sätt svarade båda

(43)

Svaren från båda respondenterna angav att journalsystemet tillgodoser verksamheternas krav på användarvänlighet. Resultatet från utvärderingen av journalsystemets användarvänlighet påvisade att journalsystemet är användarvänligt.

3.10.2 Anpassningsbarhet

Vid intervjun beskrev de båda respondenterna att möjligheten att skapa journaler existerade. Person 1 angav att “det gick bra att skapa en journal med de parametrar vi önskar ha med”. Person 2 beskrev det som att “det var enkelt att skapa journaler som var anpassade för vår verksamhet”. Respondenternas svar påvisade att journalsystemet bidrar till anpassningsbarhet vid utformning av journaler. Eftersom systemet kunde tillgodose lämpliga parametrar och önskade parametertyper resulterade utvärderingen av journalsystemets anpassningsbarhet i att journaler i systemet är anpassningsbara utifrån verksamhetens krav och behov.

3.10.3 Tillgänglighet

Under utförandet av tester anslöt sig person 1 och person 2 till webbtjänsten med sina

mobiltelefoner där båda fick koppling till systemet. Vid utförandet av intervjun efter genomförda tester svarade båda respondenter på frågan angående möjligheten att inspektera andra

verksamheters journaler att det på ett önskvärt sätt är möjligt. Person 1 menade på att det var “enkelt” att hitta informationen utfärdad av person 2. Person 2 förklarade det som att menyn med företagets verksamheter gjorde det möjligt att inspektera andra journaler inom företagets

verksamheter.

Möjligheten att koppla upp mobila enheter till systemet samt respondenternas beskrivna upplevelse av tillgänglighet anger att systemet bidrar med önskad tillgänglighet av journaler. Eftersom person 1 och person 2 kunde få tillgång till ifyllda journaler samt att de kunde få tillgång till andra journaler inom företagets verksamheter resulterar utvärderingen i att systemet har en tillräcklig

(44)

(45)

29 | ANALYS OCH DISKUSSION

4 Analys och diskussion

I detta kapitel analyseras journalsystemprototypen utifrån dem utförda användartesterna och de sju principerna (se tabell 2.1) för att utveckla användarvänliga användargränssnitt. Svaren från testerna som har gjorts och valet av lösning för den utvecklade modellen analyseras. Kapitlet avslutas med en diskussion om sociala, ekonomiska och miljömässiga aspekter.

4.1 Journalsystemprototypen

Analys av journalsystemprototypen utförs i delar, uppdelat i den framtagna modellen och den utvecklade webbapplikationen. Delen kring modellen analyseras utifrån den resulterande modell och webbapplikationsdelen analyseras utifrån de sju principer för användarvänlighet.

4.1.1 Modell

Modellen utvecklades i syfte att bidra med en lösning för att tillgodose olika verksamheters behov och krav som kan förekomma på journaler i ett journalsystem. Den utvecklade modellen resulterade i en prototyp som tillgodoser krav och behov från två olika verksamheter inom ett företag.

Systemets anpassningsbarhet förekom i form av de två verksamheternas möjlighet att utforma journaler efter sina egna behov av parametrar som önskades förekomma i journalerna. Detta möjliggjordes genom att modellen utvecklades för att vara flexibel i den mening att ta hänsyn till ett varierat antal parametrar i journalen som önskas vara med. Modellen tar även hänsyn till ett varierat antal värden som kan beröra en parameter.

Modellen åstadkom flexibilitet genom att nyttja klassen Notation i en tvådimensionell lista. Den tvådimensionella listan utgörs av klassen Form som innehöll en lista utgörande av klassen Field som i sig utgörs av en lista med klassen Notation. Eftersom klassen Notation består av data och en NotationType kan användaren välja vid skapandet av journaler vilken typ av notation data som representerar information i notationen. Genom att Field består av en lista med Notations medför det att ett obestämt antal notationer kan förekomma i ett fält. Notationerna i fältet utgör en parameter med alla ifyllningsbara värden. Antalet parametrar blir flexibelt eftersom klassen Form innehåller en lista med fält. Det möjliggör att antalet parametrar varierar i ett formulär beroende på vad som önskas av användaren. Detta gör modellen flexibel eftersom användaren själv väljer antal parametrar, antal värden tillhörande en parameter och vilket typ av värde en parameter ska ha.

4.1.2 Webbapplikation

Webbapplikationen utvecklades för att tillhandahålla funktionaliteten från modellen i backend. Detta genom en verktygliknande applikation, ämnad för att skapa journaler anpassad för varje enskild verksamhet. Tillhandahållandet möjliggjordes genom funktionaliteten att kunna fylla i den skapade journalen på ett användarvänligt sätt och kunna kontrollera journalerna i efterhand, både för sin egna och även andra verksamheter inom företaget. Analys av tillgänglighet utförs vid analys av testsvar från respondenterna, senare i avsnitt 4.2. Detta eftersom endast respondenterna kan ge en objektiv bild av hur systemprototypens tillgänglighet är. För att bedöma användarvänligheten görs en subjektiv analys utifrån de sju principerna som Ali och Dalbir [25] tagit fram. Detta styrks med hjälp av de användare som testat journalsystemprototypen och deras åsikter kring

(46)

Analysering av webbapplikationen med stöd från de sju principerna (se tabell 2.1) tyder, från ett subjektivt perspektiv, på att fem av de sju principerna är uppfyllda. Enligt princip ett är tillgängliga funktioner i systemet reducerade till de absolut mest väsentliga, för att kunna utföra de uppgifter som definierar ett journalsystem. Stora komponenter, tillsammans med lämpliga ikoner ger användaren en tydlig beskrivning av vad som sker vid ett knapptryck samt de beskrivande funktionsnamnen som varje knapp har, vilket täcker principerna tre, sju och sex. Inga facktermer används i systemet, som princip fyra beskriver, för att användargränssnittet ska vara anpassat för alla typer av användare. Princip två och fem har inte implementerats i systemet, då möjligheten till att ändra färg, font och storlek inte ansågs som prioriterat vid utvecklingsfasen.

Som presenterats i 3.5.1 finns det tre nyckelord för att definiera användarvänlighet. Dessa tre ord används för att definiera om användargränssnittet är användarvänlighet eller inte. Trots att alla sju principer inte är uppnådda kan användargränssnittet vara användarvänligt om det uppfyller de tre nyckelorden; effektivitet, ändamålsenlighet och tillfredsställelse [34]. För att tillhandahålla en objektiv bild vidare systemet är användarvänligt eller inte kommer en analys genomföras utifrån användartesterna som utförts.

4.2 Analys av respondenternas svar

Två anställda på Cemi, som verkar inom två olika verksamheter, utförde tester på

journalsystemprototypen och besvarade sedan ett antal frågor. Analys av respondenternas svar, utifrån användarvänlighet, anpassningsbarhet och tillgänglighet komma att göras. Även felkällor som respondenterna upptäckt kommer att analyseras.

4.2.1 Felkällor

Utförda tester gjordes på två verksamheter inom Cemi. Resultatet för utvärdering av tester och resultat rörande systemprototypen visar att kraven de två olika verksamheterna hade på journalerna i systemet kunde tillgodoses. Kraven mellan verksamheterna varierade i form av att det förekom en skillnad på antalet önskade parametrar i en journal samt att önskad parametertyp varierade. Person 1 från sim- och badanläggning önskade ha 20 parametrar varav en av parametrarna bestod av ett ifyllbart textfält och resterande, ifyllbara nummerfält. Person 2 från fastigheter önskade ha 16 parametrar som endast utgjordes av checkrutor.

Genom att analysera de två respondenternas svar från intervjun kan det konstateras att det förekom ett flertal faktorer som bidrog till att systemet ansågs användarvänligt. Vid frågan om det går att fylla i en journal på ett önskvärt sätt säger person 2 att “det var enkelt att fylla i en journal, framför allt eftersom den var anpassad efter verksamheten”. Det visar att möjligheten till att anpassa journaler efter behov bidrog till användarvänlighet genom att person 2 själv kunde ange önskade parametrar. Person 2 upplevde att det inte förekom irrelevanta parametrar i journalen som bidrog till en bristande användarvänlighet.

Eftersom kontroll om krav från två verksamheter kunde tillgodoses medför det att varierande krav från andra typer verksamheter inte har kontrollerats. För att åstadkomma en ökad säkerhet i att den framtagna generella modellen om den kan tillgodose krav från andra typer av verksamheter skulle fler tester behöva utföras. Ytterligare tester hos olika typer av verksamheter bidrar med att

(47)

4.2.2 Analys av resultat

Testerna utförda av anställda på Cemi, analyseras utifrån användarvänlighet, anpassningsbarhet och tillgänglighet i journalsystemprototypen.

4.2.2.1 Användarvänlighet

Testerna som respondenterna utförde och svaren som intervjuerna genererade, resulterade i att användarna ansåg journalsystemprototypen som användarvänlig. Detta eftersom respondenterna ansåg att prototypen uppfyller de tre nyckelorden som ISO-standarden för användarvänligt användargränssnitt bygger på [37], nämligen att den är effektivitet, ändamålsenlighet och tillfredsställelse. Respondenternas åsikt, tillsammans med de fem uppnådda av de sju möjliga principerna för användarvänligt användargränssnitt, tyder på att användargränssnittet är användarvänligt för de verksamheter som testat systemprototypen. Detta skulle, som tidigare nämnt i avsnitt 4.2.1, behöva kompletteras med flera tester inom ännu fler verksamheter och branscher. Bland annat sjukvården som ständigt nyttjar journaler, för att kunna göra ett fastställande om journalsystemprototypen är användarvänlig eller inte.

4.2.2.2 Anpassningsbarhet

Likt användarvänligheten ansåg respondenterna att journalsystemprototypen erbjuder anpassningsbarhet. Båda respondenterna ansåg att de kunde skapa journaler anpassade för

verksamheten samtidigt som de kunde fylla i dessa på ett önskvärt sätt. Webbapplikationen och den modell som utvecklats skapar anpassningsbarhet för användarna i form av dess olika val som användaren har möjlighet att ta. Detta gjordes till syfte att inkludera användarna i utvecklandet av deras egna journaler. Någonting som flera undersökningar har påvisat är väsentligt vid utvecklande av användarvänliga och anpassningsbara journalsystem [14][18]. Eftersom de två anställda från olika verksamheter utförde tester på systemprototypen och båda konstaterade att den är anpassningsbar, medför det att systemprototypen är anpassningsbar.

4.2.2.3 Tillgänglighet

De två respondenterna utförde kontroll av varandras ifyllda journaler och kunde därför slå fast vid att tillgängligheten i systemet existerar. Detta system skulle däremot behöva sättas i ett större sammanhang, med flera organisationer och varje organisations olika verksamheter. Därefter skulle ett test mellan de olika organisationerna och dess verksamheter behöva utföras för att fastställa tillgänglighet mellan olika typer av organisationer. Till exempel skulle detta kunna vara att en av Cemis verksamheter måste göra en kontroll av journaler inom en verksamhet som ett annat företag har för att kunna utföra ett säkert arbete. Konsekvensen är potentiellt att en delning av journaler mellan två olika företag riskerar att krocka, eftersom risken finns att vissa uppgifter i journalerna är konfidentiella. Därför är det endast möjligt att göra ett konstaterande angående tillgängligheten mellan olika verksamheter inom ett och samma företag och inte mellan flera olika företag. Utgår arbetet från Cemi och testerna som utförts fastlägger analysen att journalsystemprototypen är tillgänglig inom ett företags olika verksamheter.

4.3 Alternativ lösning för modellen

(48)

Notationerna med övriga notationstyper har då ingen data vid skapandet av journaler. Det medför att fält i databasen där notationer inte har ett tilldelat värde är tomma, se figur 4.1.

Figur 4.1 Tomma fält i databasen.

En modell för journalmallar hade potentiellt kunna lösa det problemet. Anledningen till att en modell för journalmallen hade kunnat löst problemet är att mallen inte har ett behov för datafält där NotationType är NONE. Den behöver inte ett datafält för övriga typer av notationer med anledning av att mallen inte innehåller några ifyllda värden, utan anger endast vad som ska fyllas i av

användare.

Användandet av en modell för mallen till journalen hade däremot medfört ytterligare funktioner i journalmodulen för hantering av strukturen hos de ifyllda journalerna. Detta eftersom strukturen hos de ifyllda journalerna inte stämmer överens med strukturen för mallen. Det kan vara att modellen för ifyllda journaler har en parameter för data medan modellen för mallen inte har det. Ytterligare funktionalitet för omstrukturering av data hade skapat ytterligare belastning på journalmodulen. Den ökade belastningen hade uppstått på grund av den ökade mängden handlingar av data modulen tvingats utföra vid en omstrukturering.

4.4 Sociala, etiska, ekonomiska och miljömässiga aspekter

Arbetets syfte, bortsett från att skapa en systemprototyp som är användarvänlig, anpassningsbar och tillgänglig, är att bidra till bättre sociala, etiska, ekonomiska och miljömässiga aspekter för företag och samhälle. Detta genom att systemprototypen är användarvänlig, anpassningsbar och är lättillgänglig.

Journalsystemprototypen tillhandahåller ett användarvänligt användargränssnitt i syfte att bättra företags hantering av journaler. Användarvänligheten leder till att användarna effektivt kan utnyttja systemet utan upplärning, vilket resulterar i att mer tid kan läggas på användarens arbete i stället för tid på att utbilda sig i systemet.

Cemi, som tillhandahöll kraven på arbetet, kan nyttja systemet inom alla verksamheter som det verkar inom. Detta eftersom företaget ges möjligheten att skapa journaler som är anpassade för varje enskild verksamhet. När företaget får möjligheten att anpassa sina journaler själva involveras användaren i framtagandet av journalen, vilket leder till ändamålsenliga journaler [17][18].