I detta avsnitt diskuteras de resultat som uppnåtts under projektet. Huvudsakligen tas de beslut som tagits kring design, utvecklingsarbetet, ramverk samt programmeringsspråk upp.
Tabell 6.1: Enkel jämförelse mellan React och Angular
Faktor Angular React
Programmeringsspråk TypeScript JavaScript
Arkitektur Komponentbaserad Komponentbaserad
Applikationsstorlek Liten Liten
Template HTML + TypeScript JSX + JS
6.2.2
Kopplingen till openEHR
Teamet beslutade att använda openEHR [3] för att lagra all patientdata då det efterfrågades från kund. Eftersom openEHR stödjer egna formulär, arkitekturer samt databaser kunde en stor andel av serverlagringen flyttas dit. Detta medförde att flera teammedlemmar behövde utbilda sig inom openEHRs API samt webbapplikationen som tillhandahölls.
6.2.3
Kopplingen till RÖD
I början av projektet planerade teamet att skapa en inloggningsvy som kunde anslutas till Re- gion Östergötlands digitaliseringsplattform (RÖD). Mot slutet av projektet diskuterade tea- met tillsammans med kund denna lösning och beslutade att inte prioritera inloggning, utan istället fokusera på användare och olika roller i systemet. Eftersom fokuset lades på roller uppmuntrades tester och demonstration över funktionalitet.
6.2.4
Gränssnitt
Målet med gränssnittet specificerades i början av projektet och fokuset var att leverera ett snabbt, innovativt samt stresståligt gränssnitt som kunde användas i alla tillfällen inom akut- vården. Gränssnittet skulle på ett smidigt tillvägagångsätt indikera nya uppdateringar för användaren, bland annat genom att lägga en ram runt objektet som uppdaterats. En annan funktion som ansågs viktig var att användare ska kunna kontrollera om en annan användare befinner sig på samma inmatningsfält; detta för att minimera risken för begränsningar samt att information skrivs över. Eftersom gränssnittet skulle kunna användas vid intensiva tillfäl- len var teamet tvunget att designa det på så vis att uppgifter kunde utföras med så få klick som möjligt.
Mycket fokus lades även på att designa ett lättsamt gränssnitt med rundade hörn, tydliga skuggningar, 3D-effekter samt animationer. Denna design skulle skapas utan att drastiskt försämra prestandan; målet var att göra gränssnittet användarvänligt och välkomnande för användaren.
Användarvänlighet
Ett av de viktigaste kraven på systemet var användarvänlighet. Kundens målgrupp, det vill säga sjukvårdspersonal, skulle på ett smidigt och lättsamt sätt kunna arbeta i systemet utan behov av långvarig upplärning eller stöd från IT-avdelningen. Redan från början fokuserade teamet på att designa ett intuitivt system som hjälper användaren arbeta. Tydliga exempel på detta är knappar med en accentfärg som kontrasterar mot primärfärgen, stegindikator vid formulär som tydligt visar att det kommer fler uppgifter efteråt, samt tydliga fördelningar av information. Fokus låg i stor utsträckning på att använda rundade hörn, mjuka övergångar, tydliga indikationer samt enkla manövreringar för att ge användaren tillit till systemet.
Färgschema
Under utvecklingen av designprototypen påbörjades undersökningen av färger. Region Ös- tergötland har sedan tidigare en grafisk profil som kunde appliceras; dock var denna generell för hela deras verksamhet och inte direkt mot sjukvården. Med tanke på att systemet leve- rerades under open-source-licens behövdes ett färgschema som kunde användas av alla. I diskussion med kund önskades en konfigurationsfil som smidigt kunde användas för att by- ta exempelvis färgschemat.
Färgschemat som teamet valde fokuserade främst på sjukvården, med tydliga och klara färger som enkelt kan läsas av.
Material Design
Teamet beslutade att använda Material Design [14] som verktyg till designutvecklingen, ef- tersom Material Design är ett känt ramverk som innehåller många färdiga komponenter och klasser som kunde användas till systemet.
Ett annat alternativ som diskuterades var Bootstrap [22]. Bootstrap i jämförelse med Ma- terial Design är mer välkänt och upplevdes av teamet vara mer välutvecklat. Däremot ansågs det ha ett större fokus på egenutvecklad design, vilket hade varit mer tidskrävande. Som standard kommer Angular med en grundversion av Bootstrap, och användaren har möjlig- het att installera hela versionen av Bootstrap.
Trots Bootstraps smidiga integration i Angular valdes Material Design främst för att dess komponenter är designrika och uppmuntrar till användarvänlighet. Det finns ett officiellt bibliotek för Material Design till Angular, Angular Material Design [23], som ger upphov till de flesta Material Design-komponenter. Detta bibliotek är fortfarande under utveckling och fler komponenter planeras tillkomma. I detta projekt var det dock inget problem då Angular Material Design hade de komponenter som efterfrågades.
6.2.5
Systemanatomi
Systemanatomin var väldigt lönsam under uppstarten av projektet då den gav en tydlig över- blick på systemets funktioner, huvudkomponenter samt hur systemet fungerar i helhet. Sys- temanatomin användes även som grund till designspecifikationen. Teamet använde systema- natomin för att försäkra sig om att alla delar fanns med. Med hjälp av systemanatomin kunde teamet analysera vilka delar av systemet som krävde mer fokus, exempelvis externa tjänster såsom RÖD.
6.2.6
Utveckling i Angular
Angular var väldigt nytt för alla inom teamet och i början av implementationen gick utveck- lingsarbetet långsamt för ett flertal teammedlemmar. Vissa teammedlemmar som arbetade mycket med prototyparbete i Figma [6] kom in i implementationen senare än övriga team- medlemmar och hade svårt att komma igång. Detta berodde på att utbildningen i Angular
på grund av att endast en prototyp levererades, men de negativa konsekvenserna bör vägas mot fördelarna och tvärtom. Exempelvis bör ses över huruvida systemet är skalbart eller ej med den nuvarande designen.
6.2.8
Databas och hantering av data
I projektets tidiga stadium, då efterforskning gjordes för att avgöra vilka designval som var nödvändiga, ingick även valet av databas. Teamet hade sedan tidigare erfarenheter av att en databas var oftast nödvändig och utgick från att skapa en struktur som skulle ha stöd för kommunikation med en eventuell databas. Efter att ha sökt efter rekommenderade data- baser för projekt i Angular blev resultaten spridda och teamet hade många valmöjligheter. De två kategorier som undersöktes var icke-relationsbaserade databaser som MongoDB och relationsbaserade databaser som en SQL-baserad databas. Teamet upptäckte allt eftersom projektet började designas att det inte skulle bli nödvändigt att lagra speciellt mycket data i databasen. Detta gav ett argument för att skapa en enkel databas då få anrop till denna skulle behövas göras. Med enkel menas en databas där så lite kod som möjligt behövde skrivas och med låga krav på prestanda. Valet blev MongoDB då denna var dokumentbaserad och kunde implementeras direkt av de JSON-objekt som hämtades av servern. Teamet hade inte heller erfarenhet av denna typ av databas så valet blev att testa denna för teamet nya teknik.
6.2.9
Värde för kund
Teamet fokuserade på att utveckla en prototyp som kan uppmuntra till en effektivare akut- vård med hjälp av digitala hjälpmedel. Kunden kan använda systemet för att bevisa att idén om digitala akutvårdsjournaler faktiskt kan realiseras. Detta möjliggjordes genom att låta teamet arbeta med detta projekt och tillåta att det får användas enligt open-source-licensen.
Inom akutvården är UX ett stort fokus; det är väldigt viktigt att systemet är användarvän- ligt och smidigt att hantera för såväl nya användare som användare som föredrar de tidigare arbetsmetoderna.
6.2.10
Resterande arbete
För tillfället saknar systemet koppling till RÖD för autentisering av personal, fullständig im- plementation av openEHR samt hantering av redan existerande data. För autentisering krävs ett lager ovanför systemet som kan läsa av användarens data och kommunicera med RÖD. openEHR har stor potential när det gäller hantering av patientdata samt åtgärder. Kvantifi- erbara data är något som kunden efterfrågat sedan start; ju mer systemet kommer användas desto mer information kan återanvändas. Patienter som kommer in till akutmottagningen med liknande symtom kan snabbare bli behandlade om systemet har kännedom av tidigare fall.
6.2.11
Vidareutveckling
Systemet har en stor utvecklingspotential; mer fokus på UX, anslutning till sensorer, tred- jeparts tjänster men även AR. Det finns väldigt mycket som kan förbättras; hemsidor kan alltid bli snyggare, snabbare och stabilare. Bättre återkoppling för användare kan ges, tydli- gare animationer kan skapas, och bättre färger kan väljas. Andra förbättringsmöjligheter är exempelvis att koppla sensorer eller Bluetooth-enheter, vilket kan vara hjälpsamt för snab- bare inmatning till systemet, eller bättre och mer koppling till openEHR och andra tjänster. Detta skulle möjliggöra att systemet blir effektivare och underlättar för kunden.