Utformning och utveckling av ERICA: ett digitalt beslutsstöd för akutmottagningen på NÄL Kandidatarbete vid institutionen för Signaler och system ELIN BLOMGREN OSKAR HENRIKSSON LINNÉA JOHANSSON EDVARD LINDELÖF MARTIN PETTERSSON ÅSA SÖDERLUND Institutionen för Signaler och system Chalmers tekniska högskola Göteborg, Sverige 2016 Utformning och utveckling av ERICA: ett digitalt beslutsstöd för akutmottagningen på NÄL ELIN BLOMGREN OSKAR HENRIKSSON LINNÉA JOHANSSON EDVARD LINDELÖF MARTIN PETTERSSON ÅSA SÖDERLUND Handledare: Kristofer Bengtsson Examinator: Knut Åkesson Institutionen för signaler och system Chalmers tekniska högskola Göteborg, Sverige 2016 SSYX02-16-03 Abstract Background: Work coordination at emergency rooms is a challenging task. A vast amount of information is being registered as work proceeds, but few attempts have been made to transform and visualize this information to benefit coordination and overview. Objective: This paper describes the prototyping and implementation of Emergency Room Information and Coordination Assistant (ERICA), a vir- tual decision dashboard for emergency departments. The purpose of the system is to ease planning and facilitate rapid, well-grounded decision ma- king. Methods: The development of ERICA has been carried out in conjunc- tion with the staff at the emergency room at the hospital Norra Älvsborgs Länssjukhus (NÄL) of Region Västra Götaland, Sweden. Before and during development, there has been access to the data that is continously entered into NÄLs information system ELVIS, as well as historic data from April 2015 and onwards. Results: ERICA consists of a data handling architecture and a user inter- face in the form of a web application. The visualised information consists of presently known data as well as certain predicted wait times. The target audience is the departments nurses – the staff subgroup in charge of most of the work planning. During a seven day test-run, ERICA was positively received and quickly became a natural tool for some aspects of the work co- ordination. The attempts at predicting wait times shows how any of several machine learning models could be used to give a hint about the trend in average wait times, while more accurate prediction requires thorough work with adjustment and choice of parameters. Conclusion: Demand for a virtual dashboard as the one described in this paper is high. ERICA and similar systems could potentially become a na- turally integrated part of work at emergency departments in the future. The thesis is written in Swedish. i Sammandrag Bakgrund: Att planera arbetet på en akutvårdsavdelning är en stor utma- ning. Det registreras en stor mängd information medan arbetet fortgår, men system som ordentligt utnyttjar denna information för att skapa överblick och främja arbetsplaneringen saknas. Syfte: Denna rapport beskriver prototypframtagningen och implemente- ringen av systemet Emergency Room Information and Coordination As- sistant (ERICA), ett visuellt beslutstöd för akutmottagningar. Systemets syfte är att underlätta planering och öka möjligheten att fatta välgrundade beslut. Utförande: Utvecklingen av ERICA har skett i samarbete med personal på akutmottagningen vid Norra Älvsborgs Länssjukhus (NÄL) i Västra Göta- lands län. Det fanns tillgång till den data som kontinuerligt skrivs in i NÄLs informationssystem ELVIS samt till historisk data från och med april 2015. Resultat: ERICA består av en databehandlingsdel och ett användargräns- snitt i form av en webbapplikation. Informationen som visas upp består av redan känd data samt vissa predikterade väntetider. Verktygets målgrupp är mottagningens sjuksköterskor – den yrkesgrupp som sköter större delen av arbetsplaneringen. Under en sju dagar lång testkörning mottogs ERICA positivt och blev snabbt ett naturligt verktyg för att organisera arbetet. Prediktionsförsöken visar att flera olika machine learning-metoder kan an- vändas för att ge en fingervisning om utvecklingen av medelväntetider på akutmottagningen. Slutsats: Efterfrågan på den typ av visuellt beslutstöd som denna rapport beskriver är stor. ERICA och liknande system har potential att i framtiden bli en naturlig del av arbetet på akutmottagningar. ii Förord ERICA, det digitala verktyg som beskrivs i denna rapport, är en del av ett kandi- datarbete vid Institutionen för Signaler och system på Chalmers tekniska högskola, omfattande 15 hp under vårterminen 2016. Projektgruppen bestod av sex studenter från programmen Automation och mekatronik, Datateknik, Teknisk design samt Teknisk fysik. För att underlätta vidareutveckling av detta projekt samt möjliggöra spridning av den uppkomna kunskapen finns all producerad källkod tillgänglig på GitHub under https://github.com/ssyx02-16-03. Kring utvecklingen av ERICA finns det många personer att tacka för bidrag med tankar och kunskap, men några har utmärkt sig lite extra: Tack till vår handledare teknologie doktor Kristofer Bengtsson för ditt engagemang och din vägledning. Tack också för tillgång till kunskap och källkod som gav oss en bra grund att bygga projektet på. Tack till vår examinator docent Knut Åkesson för bra samarbete och givande samtal om vetenskapliga rapporter. Tack till Caroline Fruberg, utvecklingsledare i NU-sjukvården, samt resten av per- sonalen på akutmottagningen på NÄL för informativa studiebesök, svar på frågor på alla nivåer och för värdefulla tankar och åsikter om prototyperna. Tack för att ni trodde på idén och var villiga att testa. Tack till Insieme Consulting och teamet bakom ELVIS för att ni givit oss tillgång till den bakgrundsdata vi behövt för att bygga en applikation baserad på verklig data. Tack till medlemmarna på och grundarna av StackExchange för att ni diskuterar och löser programmeringsproblem, samt gör erfarenheterna offentliga och lättill- gängliga. iii https://github.com/ssyx02-16-03 Ordlista Beslutsstöd Verktyg och metoder för att underlätta välgrundade beslut. Genomförs oftast genom dataprocessering för sållning och prioritering av information samt någon visualisering av re- sultatet. Databuss/buss En gemensam kommunikationskanal mellan programmodu- ler där varje program kan prenumerera på och publicera data. ELVIS Elektroniskt VårdInformationsSystem: Ett informationssy- stem som används i Västra Götalandsregionen för att regi- strera när och hur patienter tar emot olika typer av vård under ett vårdbesök. ERICA Emergency Room Information and Coordination Assistant: det digitala beslutsstöd som beskrivs i denna rapport. NÄL Norra Älvsborgs Länssjukhus i Västra Götalands län. RETTS Rapid Emergency Triage and Treatment System: en algoritm för utförandet av triage. Torg Mindre avdelning på akutavdelningen som tar hand om pa- tienter från samma medicinska specialitet, till exempel me- dicinpatienter eller ortopedpatienter. Triage En metod för att snabbt undersöka allvarligheten i en pa- tients tillstånd och utifrån det kunna tilldela patienten en vårdprioritet. TTK Tid Till Klar: Tid från att patienten kommer in till att denne är färdigbehandlad på akuten. Den sammanlagda tiden på akuten kan dock bli längre, t ex om patienten ska läggas in på avdelning. TTL Tid Till Läkare: Tid från att patienten kommer in till akuten (via ambulans eller kölapp) till att denne fått möta läkare första gången. TTT Tid Till Triage: Tid från att patienten tar en kölapp tills denne har fått triage. TVT Total Vistelsetid: Tid från att patienten tar en kölapp tills denne lämnar akutmottagningen. iv Innehåll 1 Inledning 1 2 Bakgrund 2 2.1 Akutsjukvården i Sverige . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Personalgrupper på akutmottagningen . . . . . . . . . . . . . . . . 2 2.3 Vårdkedjan på akutmottagningen på NÄL . . . . . . . . . . . . . . 3 2.4 Personalens organisatoriska hjälpmedel . . . . . . . . . . . . . . . . 4 3 Problembeskrivning 7 4 Utformningen av ERICA 8 4.1 Förstudie och datainsamling . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Introduktion till ERICA . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Metodik för utvärdering . . . . . . . . . . . . . . . . . . . . . . . . 12 5 ERICAs användargränssnitt 13 5.1 Funktioner till ERICA . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1 Lediga och upptagna rum . . . . . . . . . . . . . . . . . . . 13 5.1.2 Nyckeltal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.3 Patientstatus . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.4 Information om ändringar . . . . . . . . . . . . . . . . . . . 15 5.2 De två vyerna i ERICA . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.1 Koordinatorvy . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2.2 Torgvy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3 Kognitiv ergonomi och synergonomi för digitala gränssnitt . . . . . 18 6 Systemarkitekturen i ERICA 21 6.1 Databehandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1.1 Inkommande rådata . . . . . . . . . . . . . . . . . . . . . . 23 6.1.2 Dataaggregering till webbserver . . . . . . . . . . . . . . . . 23 v 6.2 Databasens implementation . . . . . . . . . . . . . . . . . . . . . . 24 6.3 Realtidsprediktion . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.4 Webbservern – länken mellan buss och klient . . . . . . . . . . . . . 26 6.5 Klienten – visualisering av data till användaren . . . . . . . . . . . 28 6.6 SocketIO – Kommunikation mellan webbserver och klient . . . . . 30 7 Prediktion av väntetider 33 7.1 Mätmetoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.2 Implementering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.3 Extrahering av prediktionsparametrar . . . . . . . . . . . . . . . . . 35 7.4 Modeller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.4.1 Artificiella neurala nätverk . . . . . . . . . . . . . . . . . . . 36 7.4.2 Polynomanpassning och linjär regression . . . . . . . . . . . 37 7.4.3 Närmsta grannar-regression . . . . . . . . . . . . . . . . . . 37 7.4.4 Lasso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.5 Utvärdering av modeller . . . . . . . . . . . . . . . . . . . . . . . . 38 8 Utvärdering och diskussion 41 8.1 Realtidstest på NÄL . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1.1 Åtgärder under testperioden . . . . . . . . . . . . . . . . . . 41 8.2 Validering av resultat . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.2.1 Teoretisk utvärdering av ERICA . . . . . . . . . . . . . . . . 42 8.2.2 Enkätundersökning . . . . . . . . . . . . . . . . . . . . . . . 44 8.2.3 Subjektiv upplevelse . . . . . . . . . . . . . . . . . . . . . . 45 8.3 Databegränsning och tillförlitlighet . . . . . . . . . . . . . . . . . . 45 8.4 Möjligheter med mer data . . . . . . . . . . . . . . . . . . . . . . . 46 8.4.1 Ambulansinformation . . . . . . . . . . . . . . . . . . . . . . 46 8.4.2 Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.4.3 Utökade patientkort . . . . . . . . . . . . . . . . . . . . . . 47 8.4.4 Mobil plattform . . . . . . . . . . . . . . . . . . . . . . . . . 48 vi 8.4.5 Bättre prediktion . . . . . . . . . . . . . . . . . . . . . . . . 48 8.5 Generisk version av ERICA . . . . . . . . . . . . . . . . . . . . . . 48 9 Slutsats 50 A Bilagor 55 A.1 Kravspecifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 A.2 Lagringsformat för enskilda patienter . . . . . . . . . . . . . . . . . 57 A.3 Utvärderingsenkät . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.4 Datamatchning utförd av webserver_comm . . . . . . . . . . . . . . 60 A.5 Jämförelse av prediktionsmetoder . . . . . . . . . . . . . . . . . . . 63 vii 1 Inledning 1 Inledning Sjukhusinstitutioner i allmänhet och akutvårdsavdelningar i synnerhet är arbets- platser utsatta för hög stressbelastning [1], [2]. Kravet att en akutmottagning ska kunna ta emot och behandla patienter med kort varsel, tillsammans med stora fluktuationer i patientflöde, gör planeringen av arbetet till en stor utmaning [3]. Dessutom har antalet patienter som vänder sig till akutmottagningen blivit allt större under de senaste åren [4]. Personalens arbetsuppgifter kräver att de kan hantera mycket information i huvudet, till exempel patienters tilltänkta vårdplan samt planering av det egna arbetet. Tillsammans med svårt sjuka patienter och begränsade resurser [5] bidrar det till en stressig arbetsmiljö. Rapportens syfte är att redogöra för det digitala verktyget Emergency Room Infor- mation and Coordination Assistant (ERICA) som utvecklats för akutmottagningen på NÄL, Norra Älvsborgs Länssjukhus i Västra Götlands län. ERICA är ett digi- talt verktyg som ska hjälpa personalen genom att underlätta planering samt att öka möjligheten att fatta välgrundade beslut. Vidare ska ERICA hjälpa persona- len att arbeta proaktivt för att undvika situationer när kontrollen brister i deras dagliga arbete. Detta sker genom visualisering av överblicksbilder i nutiden och prediktion av läget i framtiden. 1 2 Bakgrund 2 Bakgrund För att utforma tekniska hjälpmedel som är väl anpassade till användarna krävs detaljerad kunskap om informationsflöden, arbetsuppgifter samt i vilken kontext hjälpmedlen ska användas [6], [7]. Därför redogörs här utförligt för arbetsflödet och rutinerna i akutvården. En del av dessa principer är allmänna för svenska akutmottagningar, andra är specifika för NÄL. 2.1 Akutsjukvården i Sverige År 2015 fanns det totalt 71 sjukhusbundna akutmottagningar i Sverige [3] och ännu fler icke sjukhusbundna specialmottagningar. Akutmottagningen på NÄL är en av de tio största mottagningarna i Sverige med ca 75 000 besök under 2015 [8]. Det innebär att mer än 200 patienter inkommer i snitt varje dag. Enligt Socialstyrelsens rapport om väntetider och patientflöden på akutmottag- ningar i Sverige [3] inkommer mellan 70-80% av patienterna till sjukhuset under dagtid. Störst är inflödet på förmiddagen och under lunchtid för att sedan avta framåt sen eftermiddag. Utflödet följer inte riktigt samma kurva som inflödet ut- an ökar först framåt kvällen. Det betyder att beläggningen är som störst under eftermiddag och tidig kväll för sedan minska markant till natten. 2.2 Personalgrupper på akutmottagningen På akutmottagningen arbetar huvudsakligen fyra yrkesgrupper: läkare, sjukskö- terskor, undersköterskor samt medicinska sekreterare [9]. Utöver dessa finns fler- talet mindre yrkesgrupper som till exempel kuratorer och transportörer. Läkarnas främsta fokus på akutmottagningen är att utreda patienternas vård- behov [10]. Arbetsuppgifterna inkluderar ”direkt patientvård” som att prata med och undersöka patienter, ”indirekt patientvård” som att tolka provsvar, prata med läkarkollegor och dokumentera samt ”personlig tid”, exempelvis väntan. Sjuksköterskorna har många olika uppgifter [10], [11], allt från att organisera ar- betet, prioritera i vilken ordning läkare ska besöka patienter till att ta prover och prata med patienter och anhöriga. Sjuksköterskorna ansvarar också oftast för tri- ageringen. Triageringen är den första bedömningen av patienters tillstånd när de anländer till sjukhuset. De fördelar även arbetsuppgifter till undersköterskorna. En koordinator är en specialiserad typ av sjuksköterska. Koordinatorerna plane- rar och dirigerar det övergripande arbetet på akutmottagningen. Arbetet går ut på att effektivisera genomströmningen på akutmottagningen genom att omloka- lisera personal och resurser samt fördela patienter mellan olika avdelningar och rum. Inför ankomst av ambulanser med akut sjuka patienter sammankallar även koordinatorn den personal som behövs för att ta emot patienten. 2 2 Bakgrund Undersköterskornas arbetsuppgifter har fokus på omsorg och omvårdnad [12]. De ser till att patienter känner sig sedda och omhändertagna samt assisterar läkare och sjuksköterskor. I mer konkreta termer betyder det att undersköterskorna bland annat tar prover, förser patienter med mat och dricka, förflyttar patienter samt rengör och förbereder patientrum. De assisterar även sjuksköterskorna vid bland annat triagering och patientvård. De medicinska sekreterarna hanterar administration och dokumentation på akut- mottagningen [13]. De tar emot patienter i receptionen och skriver in dem, skapar journaler och renskriver läkarnas diktat. När en patient är färdigbehandlad på akutmottagningen hanterar sekreterarna utskrivningar och betalningsfrågor. 2.3 Vårdkedjan på akutmottagningen på NÄL Patienten följer oftast en förbestämd väg genom sjukhuset, hela processen visas i Figur 1 och beskrivs nedan. Figur 1: Flödesschema över processen på NÄL akutmottagning. 3 2 Bakgrund Patienter kan komma till akutmottagningen på två olika sätt, antingen i ambulans eller genom egen transport. De patienter som ej anländer med ambulans kommer på eget initiativ, med remiss från vårdcentral eller med rekommendation från Vård- guiden 1177 – den nationella sjukvårdsrådgivningen. Patienter som anländer med egen transport till akutmottagningen tar en nummerlapp för att få registrera sig i receptionen. När registreringen är färdig får patienten vänta på triagering. Triageringen är den första bedömningen av hur stort vårdbehov patienten har och hur troligt det är att patientens hälsa kommer försämras inom den närmaste tiden. Väntetiden till triageringen beror både på hur sjuk patienten upplevs vara samt när den regi- strerades. Triageringen utförs oftast av ett dedikerat triageteam som består av en sjuksköterska och en undersköterska. NÄL, liksom de flesta andra akutvårdsenheter i Sverige, använder triageringssy- stemet RETTS [14] för att gradera patienter efter allvarlighetsgrad och på så sätt ange hur prioriterad patienten är [15]. Patienten bedöms utifrån vitalparametrar och allmäntillstånd och sorteras utifrån en stigande färgskala: blå, grön, gul, orange och röd. Patienter som istället kommer till akutmottagningen med ambulans triageras i ambulansen på innan ankomst. De tilldelas direkt vid ankomst en avdelning, också kallat torg. Efter att en patient har triagerats hamnar denne, i väntan på läkare, antingen i ett eget rum eller i ett inre väntrum tillhörande ett av torgen på akutmottagningen. På NÄL finns torgen ortopedi, kirurgi och två stycken medicintorg. På kvällar, nätter och helger finns även ett torg för avdelningarna gynekolog, barn och öron- näsa-hals (ÖNH). Hur länge patienten behöver vänta på läkare grundas på vilken färg patienten fått vid triageringen samt patient- och läkarsituationen vid det givna tillfället. Patienten får sedan möta en läkare som bedömer nästa steg i vårdplanen, till exempel om fler prover ska tas eller om patienten behöver röntgas. Därefter fattas beslut om huruvida patienten ska läggas in för slutenvård eller om patienten kan åka hem. Under akutbesöket mäts ett antal tider, så kallade nyckeltal. Dessa tider används internt för kvalitetsutveckling, men även nationellt för att kunna jämföra olika akutmottagningar [4]. De olika nyckeltalen presenteras i Tabell 1 och illustreras i Figur 1. 2.4 Personalens organisatoriska hjälpmedel Idag använder personalen både digitala och fysiska hjälpmedel för att underlätta sitt organisatoriska arbete. De digitala hjälpmedel som används mest är ELVIS, se beskrivning nedan, samt journalsystemet Melior. De fysiska systemen är istället en akutjournal: en journal i pappersform, samt patientkort: kort som innehåller den mest basala informationen om varje patient och dennes besöksdata. 4 2 Bakgrund Tabell 1: Tabell över tider som mäts på NÄL för egen utvärdering av kvalitet samt för nationell jämförelse mellan akutmottagningar. Nyckeltal Kommentar Typ av nyckeltal Tid till triage – TTT Tid från ankomst till första be- dömning, ofta av triageteam. Lokalt Tid till läkare – TTL Tid från ankomst till första mötet med läkare. Nationell [4] Tid till klar – TTK Tid från ankomst till att perso- nen är färdigbehandlad på akut- mottagningen. Kan sedan gå hem eller skickas vidare till annan av- delning. Lokal Total vistelsetid – TVT Tid från ankomst till att patienten lämnar akutmottagningen. Nationell [4] ELVIS – Elektroniskt VårdInformationsSystem – är ett datorbaserat system som innehåller patientspecifik information och används bland annat för att hålla upp- sikt över var patienterna befinner sig fysiskt, vem som är ansvarig läkare och när ett moment är genomfört. I Figur 2 visas en skärmdump av ELVIS och den vy som sjuksköterskorna på akutmottagningen oftast använder. Varje patient sparas som en post och visas på en rad. Information som lagras är bland annat: person- nummer, namn, prioriteringsfärg, fysisk plats, avdelning och vårdgivare. Dessutom finns ett kommentarsfält där personalen kan skriva om exempelvis patientens sta- tus och troliga diagnos, uppgifter som kan vara till nytta för kollegorna. Om en patient är markerad visas även en tidslinje längst ned till vänster över patientens händelser under besöket. Utöver informationen som visas i denna vy finns även upplysningar om hur patienten anlänt till akutmottagningen och om patienten har sekretesskydd. När en patient förändras registrerar personalen ändringen i ELVIS. Det sker ge- nom att personal ändrar i ett fält eller att de ”drar” en patient, det vill säga att de markerar en patient och drar den till en mapp i gränssnittet. Då registreras en händelse som motsvarar mappen patienten drogs till, exempelvis besök av läkare. Varje gång en uppdatering av en patient görs i ELVIS skrivs den gamla infor- mationen om patienten över. Den historik som finns kvar är tidslinjen över vilka aktiviteter som skett och när. ELVIS räknas juridiskt sett inte som en journal. De två fysiska organisatoriska hjälpmedlen är en akutjournal och ett patientkort per patient. Akutjournalen innehåller detaljerad information om varje patient och dess medicinska status och historik. Den finns i endast ett exemplar och används av både läkare och omsorgspersonal och finns därför inte alltid tillgänglig när personalen behöver den. Varje patient har även ett patientkort. Kortet innehåller översiktlig information och status om patienten och förvaras i en korthållare på torget. Korthållaren har fickor 5 2 Bakgrund Figur 2: Skärmdump på systemet ELVIS. som motsvarar olika platser på akutmottagningen, till exempel rum och väntrum, och används parallellt med ELVIS för att hålla reda på var patienter befinner sig. Korten används även för att få överblick över vilka rum som är upptagna och som minnesstöd när vårdpersonal rutinmässigt besöker patienten och akutjournalen används av någon annan. 6 3 Problembeskrivning 3 Problembeskrivning Utifrån bakgrunden har de viktigaste problemen på akutmottagningen identifie- rats. Fokus kom att ligga på kommunikation och hög arbetsbelastning. God kommunikation är viktigt för att hålla en hög patientsäkerhet. Missförstånd i kommunikationen mellan personalen på akutmottagningar är den största bidra- gande faktorn till att patienter tar onödig skada i vården [16], [17]. Det stora patientgenomflödet på akutmottagningen gör att mycket information måste kom- municeras mellan vårdpersonalen. Det kan exempelvis vara information om pa- tienters fysiska position, vilka lokaler och resurser som är lediga eller patienters provsvar [17]. Personalen måste ofta uppsöka sina kollegor för att få tillgång till denna information. Arbetstid tillägnas alltså att uppsöka kollegan – som i sin tur kanske behöver leta efter en tredje kollega. Det skapar mycket stress vilket försämrar såväl arbetsmiljö som produktiviteten väsentligt [18]. Sjukhuspersonal är ofta under en hög stressbelastning [19]. En känsla av otill- räcklighet och höga stressnivåer är även enligt Yuwanich m. fl. [20] vanligt bland personal inom sjukvården. Enligt Yuwanich m. fl. har också de sjuksköterskor med administrativt ansvar större arbetsbelastning än andra sjuksköterskor. Detta ef- tersom de ofta behöver sköta både de administrativa arbetsuppgifterna och sina vanliga uppgifter, vilket ökar stressnivån ytterligare för denna personalgrupp. På akutmottagningen på NÄL används ELVIS är att visa en nutidsbild av mottag- ningen. Trots det registreras många händelser i efterhand. Det orsakas oftast av tidsbrist men också av att det inte finns något tydligt incitament för att registrera händelser i realtid. Vidare har ELVIS begränsad funktionalitet för att visualisera data, vilket gör det svårt för personalen att få en överblick över patienter och resur- ser. Ett exempel är fördelningen av patienter mellan de två medicintorgen. När en patient tilldelas ett torg tar koordinatorn hänsyn till flera olika parametrar: bland annat antal lediga rum per torg, antal patienter som inte fått träffa läkare, totalt antal patienter och antal allvarligt sjuka patienter. Samtliga av dessa parametrar beräknas manuellt i ELVIS, likaså måste vyn manuellt uppdateras av användaren för att visa aktuell data. För att förebygga stressiga situationer bör personalen arbeta proaktivt. För att arbeta proaktivt krävs förståelse och överblick av både nuläget och framtiden, nå- got som är mentalt belastande. Vid hög belastning saknas mental kapacitet för att arbeta proaktivt och personalens handlingsmönster blir istället reaktivt och foku- serat på att lösa de på kort sikt mest viktiga arbetsuppgifterna [21]. Det riskerar att försämra vårdkvalitén och ökar risken för långvarig stress hos personalen [19]. 7 4 Utformningen av ERICA 4 Utformningen av ERICA ERICAs utformning grundades i teoretiska studier samt studiebesök och har sedan utvärderats och utvecklats i samråd med slutanvändarna i en process genom flera iterationer. Följande avsnitt ger en översikt över data- och informationsinsamling, ERICAs uppbyggnad och slutligen utvärdering. I avsnitt 5, 6 och 7 beskrivs sedan systemet mer ingående och i avsnitt 8.2.2 beskrivs utfallet av utvärderingen. 4.1 Förstudie och datainsamling Inför utformningen genomfördes en förstudie för att undersöka vilka behov som fanns på akutmottagningen på NÄL och därmed vilken huvudfunktion verktyget skulle uppfylla. Tre ostrukturerade, öppna observationer och intervjuer genomför- des enligt metodik presenterad av Osvalder m. fl. [22], då utvecklarna under hel- dagar skuggade personal på akutmottagningen. Vid dessa tillfällen observerades nuvarande lösningar, arbetsmiljö, arbetsrutiner och flöden samtidigt som intervju- er genomfördes med sekreterare, undersköterskor, sjuksköterskor, koordinatorer, läkare och ambulanspersonal. Under besöken söktes svar på frågeställningarna i Tabell 2. Tabell 2: Frågeställningar inför utformning av verktyg Fråga Hur planeras och utförs arbetet idag? Hur skapas och bibehålls översikt idag? Var brister översikt och planering? Vilken information skulle öka översikten och underlätta planeringen? Hur bör denna information presenteras för att vara användbar? Vilken yrkeskategori har störst behov av översikt? Resultaten från observationerna och intervjuerna sammanställdes och resulterade i en lista av önskvärda funktioner. Under dessa besök framkom behovet av att visa två separata vyer till de två personalgrupper som ansågs ha störst behov av ett beslutstöd i sitt arbete. Det togs hänsyn till hur mycket information personal- gruppen behövde hålla i huvudet, hur kritiskt det var om information glömdes bort samt vilken eventuell information som skulle förbättra arbetet men som inte finns tillgänglig idag. Utifrån ovanstående parametrar utmärkte sig koordinatorn som den personalgrupp med tydligast behov av en bättre översiktsbild över hela akutmottagningen och den som skulle kunna ha störst nytta av ett beslutsstöd. Dessutom fungerar ko- ordinatorplatsen som en knutpunkt där mycket kommunikation sker mellan olika arbetsgrupper. 8 4 Utformningen av ERICA Förutom koordinatorn identifierades sjuksköterskorna på torgen till att ha stort behov av en bättre överblick. Sjuksköterskorna håller mycket information i huvudet och fungerar som en slags koordinator på varje torg. Genom att ge sjuksköters- korna den relevanta informationen som behövs för att de ska kunna utföra sina arbetsuppgifter på ett smidigt sätt, är förhoppningen att arbetet kommer att ske mer effektivt samtidigt som risken att någonting glöms bort minskar. Några av de funktioner som bedömdes vara av högst vikt för respektive vy pre- senteras i Tabell 3, kravlistan som helhet finns i bilaga A.1. Tabell 3: Ett urval av de viktigaste önskemålen/kraven som ställs på produktens två vyer. Fullständig kravlista finns i bilaga A.1. Koordinator Torg Visa lediga rum Ange helhetsbild av patient Ange antal patienter per torg Ange tid sedan senaste tillsyn Ange antal patienter som ej fått triage Ange triagefärg per patient Ange antal patienter som ej träffat läkare Ange läkarstatus per patient Informera om inkommande ambulanser Informera om inkommande patienter Informera om trender för nyckeltal Informera om trender för nyckeltal Inför utformningen har även data samlats in för att möjliggöra utformning av ett beslutsstöd. Insamlingen har pågått från ELVIS på NÄLs akutmottagning sedan april 2015. Datatyperna som sparats finns listade i Tabell 4. Av hänsyn till patientsäkerhet och sekretess gavs inte tillgänglighet till personnummer, namn och vårdkommentarer, något som annars finns i ELVIS. 4.2 Introduktion till ERICA Utifrån den data som fanns tillgänglig från ELVIS och de önskade funktionerna utformades ERICA – Emergency Room Information and Coordination Assistant. ERICA är ett system utformat för att ge sjuksköterskor och annan vårdpersonal stöd vid beslutsfattande och hjälp att få en överblick över hela akutmottagningen respektive över sitt torg. Som nämnts i avsnitt 2.4 finns det på NÄL många system där patientinforma- tion skrivs in. För att undvika införandet av ytterligare ett system som kräver uppdatering utformades ERICA som ett passivt verktyg utan inmatning. Istäl- let används endast den redan tillgängliga datan, i detta fall från ELVIS. Det har medfört funktionsbegränsningar, men förebygger samtidigt att ERICA blir en be- lastning för personalen. Genom att integrera fler system i ERICA kan fler av de önskade funktionerna implementeras. 9 4 Utformningen av ERICA Tabell 4: Data som inför utvecklingen av verktyget fanns tillgänglig från ELVIS på NÄL. Tillgänglig data Kommentar Patient ID Unikt anonymt patientnummer CareContact ID Unikt anonymt besöksnummer Ansvarig avdelning Exempelvis medicin, kirurgi eller ortope- di Besöksorsak Ordinarie, provtagning, trauma eller me- dicinskt larm. Nuvarande placering Exempelvis B24 Ankomsttid Tidpunkt för triage Triagestatus Färg som anger vårdprioritet: röd, oran- ge, gul, grön, blå. Tidpunkt(er) för läkarbesök Ansvarig läkare Tidpunkt(er) för omvårdnad Tillsyn, mat o.dyl. Tidpunkt(er) för viss undersökning Röntgen, uppkoppling till övervak o.dyl. Tidpunkt(er) för organisatoriska besök Vårdplatskoordinator och omsorgskoor- dinator Uttider Tidpunkt då patient registreras som klar respektive lämnar systemet För att sortera och tolka datan från ELVIS behandlas den i olika steg. I Figur 3 visas den väg informationen tar från ELVIS till slutanvändaren i webbapplikatio- nen. Datan lagras i en databas, används till prediktion och statistisk analys samt transformeras på olika sätt för att till sist skickas till en webbserver och använ- darens webbläsare. En närmare beskrivning av dessa steg presenteras i avsnitt 5 ERICAs användargränssnitt, 6 Systemarkitekturen i ERICA samt 7 Prediktion av väntetider. 10 4 Utformningen av ERICA ELVIS-data Databehandling Användargränssnitt AnalysTransformationer PrediktionDatabaslagring Funktioner, design och ergonomi Webbapplikation: server och klient Figur 3: Översikt över datans väg från insamling i ELVIS till visualisering för användaren i en webbapplikation. De gula fälten motsvarar element i respektive blått område. Systemet har två vyer, en koordinatorvy och en torgvy. Den sistnämnda vyn an- passas till respektive torg för att ge en representativ bild av torget den avspeglar. I stora drag visar torgvyn, Figur 4a, en karta med lediga och upptagna rum på tor- get, en samlad bild av varje inskriven patient på torget, de senaste ändringarna för torgets patienter i ELVIS, samt nyckeltalen TTL och TTK för nutid och förväntad framtida trend. På koordinatorvyn visas istället information om akutmottagning- en som helhet: läkar- och patientstatus för varje torg, lediga respektive upptagna rum samt nyckeltalen TTT, TTL, TTK i dåtid, nutid och predikterad framtid, se Figur 4b. En detaljerad beskrivning av vad som visas samt hur, återfinns i avsnitt 5. Figur 4: Skärmdump av de två vyerna i ERICA. Den högra (a) visar vyn över medicintorg blå och den vänstra (b) visar koordinatorsvyn . 11 4 Utformningen av ERICA 4.3 Metodik för utvärdering Under utvecklingen av ERICA utvärderades prototyperna kontinuerligt mot de tänkta slutanvändarna på NÄL. Utvärderingarna gav input om möjliga använd- ningsområden, funktioner och design samt förbättringsområden i systemet. ERICA testkördes under en vecka i slutet av utvecklingen, då det användes i det dagliga arbetet på NÄL. De två vyerna testades då vid koordinatorn respekti- ve på medicintorg blå. I samband med testet genomfördes en enkätundersökning bland personalen som använde ERICA, frågorna som ställdes går att se i Tabell 5. Frågorna i enkäten är inspirerade av Dolan m. fl. [23]. Resultatet av denna enkät- undersökning presenteras och diskuteras i avsnitt 8.2.2, och enkäten visas i helhet i bilaga A.3 Tabell 5: Frågor som användes vid utvärdering av systemet. Fråga I hur stor utsträckning. . . (skala 1-6) 1. ...är informationen som visas relevant? 2. ...är skärmen lätt att använda? 3. ...är det lätt att ta till sig informationen? 4. ...förstår du vad som visas? 5. ...hittar du informationen du söker på skärmen? 6. ...är designen passande? 7. ...litar du på informationen som visas? 8. ...hjälper informationen dig att planera ditt arbete? 9. ...hjälper informationen dig att förstå läget på akuten nu? 10. ...skulle du använda detta verktyg om det var permanent? Helhetsintryck? 12 5 ERICAs användargränssnitt 5 ERICAs användargränssnitt Det användarna ser av ERICA är en webbapplikation som kan visas i valfri webb- läsare. Detta avsnitt beskriver vad användaren ser, det vill säga de funktioner som visas, en detaljerad beskrivning av de två vyerna samt en beskrivning av de ergonomiska och designmässiga beslut som ligger bakom utformningen. 5.1 Funktioner till ERICA Baserat på intervjuer och observationer sammanställdes en lista över önskade funk- tioner. Dessa matchades sedan med den tillgängliga datan från ELVIS för att av- göra vilka funktioner som var möjliga att implementera i ERICA och vilka som utifrån indatan inte var implementerbara. I följande avsnitt presenteras de imple- menterade metoderna, medan de som önskades men i nuläget ej var implementer- bara diskuteras i avsnitt 8.3. 5.1.1 Lediga och upptagna rum Från flera personalgrupper uttrycktes behovet att snabbt kunna avgöra vilka rum som är lediga och vilka som är upptagna. Den önskade detaljnivån varolika be- roende på var personalen arbetade: koordinator och ambulanspersonal fokuserade på lediga rum medan personalen på torgen mer var intresserade av de upptagna rummen och vilka som befann sig i dem. Detta skapade behov av två lösningar, en med fokus på lediga rum för koordinatorn och en med fokus på upptagna rum för torgen. För att visa en rumsöversikt med fokus på de lediga rummen provades flera lös- ningar, bland annat rutor, olika listor och kartor. Valet föll till slut på att visa alla rum på en karta efter deras reella placering. Kartan valdes av två anledningar, för det första är kartan en känd bild för personalen vilket gör att det blir lättare att ta till sig den väsentliga informationen om vilka rum som är lediga och vilka som är upptagna. För det andra kan ambulanspersonalen direkt när de kommer med en patient hitta till ett ledigt rum genom att på kartan se ledighetsstatus, nummer och rummets placering. Kartan kompletterades med en lista för de som föredrar siffror framför grafik, och för att kunna jämföra mängden lediga rum mellan torg. Flera lösningar diskuterades även för rumsöversikten med fokus på de upptagna rummen. Förslag var att visualisera patienter och rum ihop eller var för sig, rum i lista, i rutnät eller som en kartbild likt verklighetens placering. Valet föll på att skapa översikt genom att visa patienter och rum i samma modul, där rummen ligger placerade som i verkligheten. Den största fördelen med placeringen är att det är lätt att koppla verklighet och visualisering vilket tar kognitivt mindre kapacitet. Nackdelen är att denna metodik blir svår att tillämpa på torg med många eller utspridda rum. 13 5 ERICAs användargränssnitt 5.1.2 Nyckeltal Nyckeltalen används som riktlinje för att se till att patienterna får vård inom rimlig tid. Dessa tider presenteras i dagsläget först i efterhand, när det är omöjligt att göra något åt dem. Genom att presentera dem löpande är förhoppningen att de ska hjälpa personalen att arbeta förebyggande och ge dem en signal om när åtgärder behövs. Nyckeltalen kan presenteras på flera nivåer, historiskt, nuläge och predikterad framtid, där framtiden kan visas som faktiska siffror eller en trendriktning. Tagna ur sitt sammanhang säger de inte mycket, men vid jämförelse med sjukhusets egna riktlinjer för hur lång väntetid som är acceptabel ger de en tydlig indikation om arbetsbelastningen på akutmottagningen. I dagsläget finns fyra huvudsakliga nyckeltal nämligen TTT, TTL, TTK samt TVT, vilka beskrevs i Tabell 1. Av dessa fyra värden kan tre av dem, TTT, TTL samt TTK, påverkas direkt av arbetet på akutmottagningen [4]. TVT beror på ytt- re omständigheter, så som tillgängliga vårdplatser på sjukhusets andra avdelningar. Kombinationen av hög kontroll och låg påverkningsförmåga är enligt professorerna Karasek och Theorell [24] en utlösande faktor för ohälsa på arbetsplatsen. Nyckel- talet TVT valdes att inte visas just eftersom den ligger utanför den påverkbara zonen. För att visualisera nyckeltalen testades flera olika koncept, bland annat staplar, linjediagram och siffror. Stapeldiagrammen testades till följd av önskemålet att kunna göra jämförelser mellan torg. Detta ansågs dock efter flera iterationer allt för rörigt och oöverskådligt. Att bara visa siffror var svårt att tolka när de inte sattes i relation till något. När flera avdelningars nyckeltal visades samtidigt gick det dessutom åt för mycket kraft för att förstå vad de egentligen avsåg samtidigt som det blev väldigt svårt att göra en intuitiv jämförelse mellan olika avdelningar. Idén med siffror togs dock vidare och kompletterades med symboler för att ge ytterligare information. En smiley indikerar om nulägets nyckeltal är bra, ok eller dåligt enligt akutmottagningens egna målvärden och en pil indikerar om nyckeltalet under närmsta timmen beräknas gå upp, ner eller hålla sig på samma nivå. Detta koncept fungerade bra när endast nyckeltal för ett torg i taget behöver visas. För att kunna göra meningsfulla jämförelser mellan torgen utvecklades linjedia- gramkonceptet. Linjediagrammet kan visa både tidigare nyckeltal och kommande prediktion på ett tydligt sätt samtidigt som det är lätt att jämföra till exempel olika avdelningars nyckeltal med varandra. Försök gjordes även med att lägga in den längsta och den kortaste väntetiden men efter noga övervägningar kasserades denna idé då linjediagrammet då blev för svårläst. 14 5 ERICAs användargränssnitt 5.1.3 Patientstatus Behovet att få veta enskilda patienters status uttrycktes av flera personalgrupper, men på olika detaljnivå. Koordinatorn behöver översikt om hur fördelningen är, exempelvis fördelningen av patienter mellan olika triagefärger, status för läkar- besök, placering och hur länge patienter måste vänta, medan torgen utöver detta behöver specifik status om varje patient. Detta gör att samma information från ELVIS används i båda vyerna men visualiseras på olika sätt. Fördelning av patienter kan visas på flera sätt, till exempel genom siffror, träddi- agram, stapeldiagram eller cirkeldiagram. Ensamt presenterade siffror är för kog- nitivt belastande att jämföra men är ett bra komplement till något annat. Träd- diagram ger en tydlig hierarkisk struktur över fördelning men behöver liksom siff- ror kompletteras med något annat för att bli lätta att jämföra. Av cirkeldiagram och stapeldiagram ger cirkeldiagram en tydligare jämförelse internt medan stapel- diagrammen kan jämföras både internt inom stapeln men också mellan staplar. Staplar har också fördelen att delarna summeras i stapeln, vilket visar att de olika placeringarna summerar ihop till ett totalt patientantal. För koordinatorn visas patientstatusen i stapeldiagram enligt beskrivning ovan, medan staplarna för torgen kompletteras med ”kort” för varje patient. Korten inspirerades av det kortsystem som redan används på sjukhuset (se avsnitt 2.4) och hjälper sjuksköterskorna att få en översikt över vilka patienter som finns på torget och deras status. Korten beskrivs mer i avsnitt 5.2.2. 5.1.4 Information om ändringar Det är svårt att genom ELVIS se vad som har hänt med de inskrivna patienterna. ELVIS måste uppdateras manuellt genom att trycka på tangenten F5 och när vyn uppdateras blinkar den till och ny information ersätter den gamla utan att markera var förändringen skett. Detta resulterar lätt i förändringsblindhet [25]: man vet inte vad som är ändrat sedan den förra bilden då oväntade förändringar inte registreras av den mänskliga hjärnan. Följden av detta är att det är svårt för personalen att ta del av vilka uppgifter kollegorna utfört utan att fråga dem. I och med att sjuksköterskorna gemensamt har ansvar för alla patienter på sitt torg händer det att arbetsuppgifter utförs utan att de andra sjuksköterskorna in- formeras eller tvärtom, att någon tror att en uppgift är utförd trots att det inte är det. Därför gjordes en funktion där de fem senaste händelserna i ELVIS kan ses i en lista. Genom att ERICA får datan direkt från ELVIS är detta ändringsfält inte beroende av extra uppdatering. Att ändringarna listas motverkar förändrings- blindhet genom att varje förändring blir betonad. 15 5 ERICAs användargränssnitt 5.2 De två vyerna i ERICA De olika funktionerna som presenterades ovan kombinerades för att skapa två olika vyer, en torgvy och en koordinatorvy, anpassade efter vilka behov respektive personalgrupp hade. 5.2.1 Koordinatorvy Utifrån resultatet av observationerna på NÄL och utvärderingen av dessa togs ett förslag på en koordinatorvy fram, som går att se i Figur 5. Detta koncept utvecklades främst för koordinatorer och ambulanspersonal och har som mål att främst förbättra översikten och sekundärt erbjuda beslutsstöd. Figur 5: Prototypskiss av koordinatorskonceptet. Denna vy är utformad för att visas på en större skärm på en central plats där koordinering sker. All information är översiktlig vilket gör att både personal och patienter kan titta på den, även om den endast är utformad för att användas av personal. Komponenter i denna vy är en karta för att visa lediga/upptagna rum, stapeldiagram för att visa patientstatus samt linjediagram för att visa nyckeltal. Stapeldiagrammet i övre vänstra hörnet illustrerar hur många patienter som har fått träffa läkare, hur många patienter det finns totalt och vilken triagefärg pa- tienterna har. Eftersom koordinatorn framförallt använder denna information för att jämföra belastningen mellan olika avdelningar passade stapeldiagramsvisua- liseringen mycket bra. Effekten av detta är till exempel att koordinatorn lättare kan fördela patienter mellan blått och gult medicintorg, se och planera åtgärder när för många patienter väntar på triage och agera när för stor andel på torgen är klara och bara väntar på att få läggas in på en sjukhusavdelning. Även vid visualiseringen av nyckeltalen var jämförelsen mellan avdelningarna vik- tig. Både tidigare värden på nyckeltalen och predikterade framtida värden visas 16 5 ERICAs användargränssnitt på ett tydligt sätt samtidigt som det är lätt att jämföra de olika avdelningarnas nuvarande nyckeltal, vilket går att se i det nedre vänstra hörnet i Figur 5. Detta hjälper koordinatorn att se att förstärkning behövs om tid till läkare blir för stor eller sätta in ett till triageteam när patienter får vänta för länge på triage. De hjäl- per också till vid fördelning till gul/blå genom att ge likvärdig väntetid på båda torgen. Hela den högra sidan i vyn i Figur 5 används för att visualisera de lediga rummen enligt kartmodellen som beskrevs i avsnitt 5.1. Kartan ger en tydlig blick över vilka rum som är upptagna respektive lediga, men även vilket torg som använ- der specialrum, exempelvis infektionsrum. Med hjälp av kartan kan koordinatorn snabbt tilldela rum till de patienter som behöver. Ambulanspersonal med inkom- mande patienter kan dessutom själva hitta ett ledig rum att ta patienten till, utan koordinatorns inblandning. Detta sparar tid både för ambulanspersonal och för koordinatorn. 5.2.2 Torgvy Torgvyn är främst anpassad för sjuksköterskor på torgen, men även läkare och undersköterskor har nytta av den. Vyn ska både ge översikt och underlätta beslut om vad som bör göras härnäst. Designen till torgvyn går att se i Figur 6. Figur 6: Prototypskiss av vyn för torgen, här medicintorg blå. På torgen är patienterna centrala. Det innebär att information kopplade till varje individ kommer att visas på skärmen, information som kan vara känslig. Denna vy är därför anpassad för att visas på en skärm i datorskärmsstorlek som är placerad på en plats där personal men inte patienter har tillgång till den. En stor del av skärmen utnyttjas till att visa var de enskilda patienterna befinner sig. Varje patient motsvaras av ett patientkort som är placerat utifrån patientens 17 5 ERICAs användargränssnitt verkliga placering. Möjliga placeringar illustreras med hjälp av en rumsöversikt där rummen har ordnats enligt deras verkliga placering, ett stort väntrum där patienter placerade i inre väntrummet på blå medicintorget visas samt ett fält för patienter placerade på annan plats – till exempel i ett infektionsrum. Väntrum- met kan ibland vara väldigt full. För att det då ska vara lätt att få en överblick över väntrummet har patienterna sorterats på, i inbördes ordning, prioritetsfärg, läkarstatus och sist ankomsttid. Denna sortering används redan idag av personalen i andra sammanhang och därför anses den vara den mest lättorienterade. Varje patient motsvaras som tidigare nämnts av ett patientkort. Detta kort in- nehåller information om patientens placering, ankomsttid, läkarstatus, triagefärg, senaste ändring i ELVIS, tid sedan senaste ändring samt, om tillgång till informa- tionen fanns, patientens namn och personnummer. Korten är färgade efter triage- färgen och får en svart ram runt om sig, enligt sjukhusets riktlinjer, för lång tid har gått sedan interaktionen med patienten skedde (exempelvis en tillsyn) och en ändring registrerades i ELVIS. I det tomma utrymmet som uppkommer i och med att rumsplaceringen är U- formad har nyckeltalen TTK och TTL placerats. Sidorna har inte ett lika stort behov som koordinatorn att använda nyckeltalen för att veta när tempot behö- ver skruvas upp. Detta i kombination med nyckeltal inte behöver jämföras med varandra gjorde att visualiseringsvalet föll på sifferförslaget i kombination med en färgad smiley som indikerar hur nulägets tider ser ut och en pil som indikerar hur trenden för den närmaste timmen ser ut. Till höger i Figur 6 syns stapeldiagram som visar fördelningen av patienterna med avseende på triagefärger, läkarstatus (om patienterna är klar, påtittade av läkare eller opåtittade av läkare) och var patienterna befinner sig just nu. Detta ska ge en snabb överblick över hur beläggningen på avdelningen ser ut i nuläget. Diagrammet visar även inkommande patienter, oftast patienter som väntar på triage, så att personalen proaktivt kan förbereda för dessa med exempelvis sängplatser. Under stapeldiagrammet finns en ändringslista som ska hjälpa personalen att se när någon förändring sker. Detta underlättar kommunikation mellan personalen då de kan meddela varandra vad de nyss gjort utan att båda parter måste vara närvarande. 5.3 Kognitiv ergonomi och synergonomi för digitala gräns- snitt Vyerna är designade med hänsyn till både fysisk ergonomi, i det här fallet fram- förallt synergonomi, och kognitiv ergonomi som i hur gränssnitt ska utformas för att minska mental belastning och underlätta tolkning. Som riktlinjer för synergonomin användes Arbetarskyddsstyrelsens föreskrifter om arbete vid bildskärm som riktlinjer [26]. Enligt detta dokument är bland annat teckenstorlek, kontrast och bildens polaritet viktiga parametrar för att minska både 18 5 ERICAs användargränssnitt fysiska och psykiska belastningar vid arbete med bildskärm. För att läsbarheten ska vara god rekommenderas att ett tecken upptar en synvinkel på 0,33-0,37 grader, vilket motsvarar en teckenstorlek på ca 3,5-4mm om användaren sitter 70 cm från skärmen. Eftersom informationen i koordinatorvyn respektive torgvyn ska intas på kort tid och från längre avstånd valdes en större teckenstorlek än den minsta rekommenderade för att öka läsbarheten. Samma dokument [26] tar även upp betydelsen av kontraster och luminans. Här rekommenderas en ljus bildskärm med ljus bakgrund och mörka tecken, det vill säga en positiv polaritet. Detta motiveras med att luminansskillnaderna i synfältet då blir mindre eftersom exempelvis väggar och papper är ljusa. Omgivningarna på sjukhuset är mycket ljusa och personalen kommer att växla mellan att titta på skärmen och i sina papper. Om skärmen har positiv polaritet behöver inte ögat ställa om sig vid växlande av fokus. Denna omställning är, enligt Arbetarskydds- styrelsen, ”tröttande för ögat, speciellt om den måste ske ofta, och kan ge upphov till olika besvär såsom huvudvärk och trötthetskänsla.”[26](s. 9). varför en ljus bildskärm med mörka tecken valdes. Mycket av informationen som ska visas på skärmen har en stark koppling till nå- gon form av färgkodning. Bland annat har avdelningarna var sin färg, patienterna får olika prioriteringsfärger och nyckeltalsdiagrammen illustreras med färger. Att använda färg som informationsbärare kan göra informationen mer överblickbar samt lättare att urskilja, identifiera och tolka [26]. Osvalder och Ulfvengren, med- författare av boken Arbete och teknik på människans villkor [21], är inne på att färger är något som är väldigt svårt att använda rätt vid design. Osvalder och Ulfvengren tar dock upp fördelar med att använda färger vid design. Fördelar kan bland annat vara att färgkodning separerar objekt som ligger nära varandra, snab- bar upp reaktionstiden, gör avläsningen mer naturlig och ger ett snabbare intag av informationen. I koordinatorvyn användes färgkodning bland annat för att separera de olika tor- gen i kartan. På detta sätt ser användaren snabbt vilka rum som hör till vilket torg och får därigenom lättare att orientera sig till rätt rum. Färgerna för torgen följer dessutom sjukhusets egen konvention, så att samma färg som visas i ERICA motsvaras av samma verkligheten. Denna mapping – koppling mellan verklighet och gränssnitt [27] – minskar risken för fel och underlättar tolkning. Triagefärgerna är ett väldigt etablerat begrepp på akutmottagningen. Att använda dessa för att representera i gränssnittet gör att informationen blir lätt och naturlig att ta till sig. De används därför både i stapeldiagrammen och på patientkorten. För att skilja färgerna från kartfärgerna har en starkare kulör använts för triage- färgerna. Detta gör även att de sticker ut mer, något som är bra då triagefärger är mer kritiska än torg – som dessutom representeras av både form och färg. På linjediagrammen i koordinatorvyn applicerades färgkodning i form av ljusa zoner i grönt, gult och rött för att möjliggöra att snabbt kunna ta till sig om väntetiderna är bra, ok eller dåliga. Dessa har gjorts blekare för att inte konkurrera med, eller blandas ihop med de övriga färgfälten på skärmen. 19 5 ERICAs användargränssnitt För att visualisera nyckeltalen i torgvyn kombinerades färgkodningen med en sym- bol. I boken Arbete och teknik på människans villkor tas även symbolhantering upp där skrivs det att ”Symboler kan med fördel användas i ett användargräns- snitt, men det förutsätter att symbolen är välkänd och otvetydig i sin tolkning av operatören”[21](s. 390). Varje nyckeltal har fått en smiley som syftar till hur väntetiderna ser ut i nuläget. En glad, grön smiley betyder att väntetiderna är bra, en gul neutral indikerar okej. och en ledsen, röd smiley indikerar att väntetiderna är dåliga. Dessa smileys indikerar både med min och färg hur väntetiderna är. En smiley anses vara en välkänd symbol som användaren har lätt att tolka. Utöver färgkodning har även andra designprinciper använts för att göra ERICA lättare att tolka. Staplarna ligger i samma ordning på de båda vyerna vilket gör det enkelt att byta mellan vyerna utan att behöva fundera på vad man ser. Staplarna på koordinatorvyn är dessutom grupperade två och två för att det lätt ska gå att se vilka staplar som hör till samma torg. Mellan modulerna i vyn finns tunna streck – även det för att hjälpa till med gruppering för att tolka vilken information som ska läsas tillsammans. 20 6 Systemarkitekturen i ERICA 6 Systemarkitekturen i ERICA I detta avsnitt beskrivs arkitekturen bakom ERICA, det vill säga hur olika mo- duler är uppbyggda och hur de kommunicerar. En övergripande illustration av hela arkitekturen visas i Figur 7 där databussen, se beskrivning nedan, syns till vänster och moduler till höger. Modulerna i figuren är färgkodade beroende på programspråk, där orange representerar Scala, lila Python och ljusblå JavaScript. Datasystemet har realiserats med en dynamisk och modulariserad systemarkitek- tur där data från ELVIS mottages, analyseras, behandlas, lagras och till sist pre- senteras för användaren, enligt Figur 3. Modulerna är uppbyggda av olika services som exekveras parallellt enligt en service-oriented architecture (SOA). En SOA är enligt Bean [28] ”a combination of consumers and services that collaborate, is supported by a managed set of capabilities, is guided by principles, and is governed by supporting standards.”(s. 4) För att hantera dataöverföringen mellan varje service används en central data- buss: enterprise service bus (ESB) [28]. Det möjliggör asynkron publicering och prenumeration av data på olika ämnestrådar, topics, på begäran av varje enskild service. Det är ett enligt Bengtsson och Lennartson [29] ett mycket effektivt sätt att skicka data, specifikt när en SOA används. Även Bonnet m. fl. [30] påtalar att ESB är nödvändigt i infrastruktur där data transformeras. I Tabell 6 visas alla topics som publiceras på bussen. Dessa förklaras närmare i nästa avsnitt. Tabell 6: Alla topics som används på bussen samt vilka typer de kan vara topic Typer elvisSnapshot elvisDiff new, diff, new_load webserver_package room_occupation, bar_graphs, blue_side_overview, recent_changes, coordinator_line_graph, blue_side_status, status_message 6.1 Databehandling Rådatan från ELVIS databas hämtas via ett SOAP/WSDL Access Protocol In- terface (API) och innehåller en ögonblicksbild av informationen i ELVIS, en elvisSnapshot. Detta elvisSnapshot transformeras till ett json-dokument och publiceras sedan på den gemensamma databussen. Vidare aggregeras patientdatan till en central databas där data sedan hämtas och paketeras för att skickas vidare till webbservern som distribuerar ut data och det implementerade användargräns- snittet till alla anslutna klienter. 21 6 Systemarkitekturen i ERICA D at ab us s ELVIS på NÄL Skickar snapshots till bussen. TransformationService Transformerar snapshots till diffs. OngoingPatientsService Transformerar data från Elasticsearch och diffs till pågående patienter. Elastic search PatientRemover Flyttar patienter till ett eget index när de tagits bort. ElasticAPI API-modul med rele- vanta sökmetoder för Elasticsearch. Prediction Predikterar väntetider utifrån en machine learning-modell. Webserver_comm Levererar färdigfor- materad data till webbservern. WebServer Skickar ut webbklienten vid http-request och lag- rar senaste uppsättning- en data. WebClient Systemets gränssnitt. Figur 7: Övergripande diagram av systemets moduler. Modulerna är färgkodade beroende på programspråk. Orange är Scala, lila är Python och ljusblå är Java- Script 22 6 Systemarkitekturen i ERICA 6.1.1 Inkommande rådata Systemet behandlar datan stegvis i olika moduler kopplade till den gemensamma bussen i form av en instans av Apache ActiveMQ. Varje elvisSnapshot inkommer med intervall på 0,5 s till bussen. För den första behandlingen av datan används modulen TransformationService, som är utvecklad av Bengtsson och Lennart- son för användning i EVAH-projektet [29]. I TransformationService jämförs var- je elvisSnapshot med det föregående och differensen mellan de två, om någon finns, publiceras till bussen under topic elvisDiff. Tidsstämplar sparas för varje förändring för att ge möjligheten att spara en fullständig historik. Modulen OngoingPatients hanterar långtidslagringen av patienter i den centrala Elasticsearch-databasen. Detta sker genom att lyssna på topic elvisDiff. När en diff publiceras avgör programmet först om det är en ny patient eller en förändring på en patient – detta anges i meddelandet i ett dedikerat fält isa. Om det är en ny patient (meddelande av typ new eller new_load) så postas den direkt till databasen. Om det är en förändring på en patient (typen diff) så hämtas den patienten först från databasen. Den inkomna differensen appliceras sedan på patienten, och patienten skrivs tillbaka till databasen. Borttagning av patienter, det vill säga patienter som inte längre finns på akutmottagningen, sköts av servicen PatientRemoval. Denna service lyssnar på elvisSnapshotoch extraherar alla CareContactId ur elvisSnapshot. Där- efter hämtas alla nuvarande patienters CareContactId från databasen. Alla CareContactId som hittas på databasen men inte i elvisSnapshot flyttas på databasen från index ongoing_patients till index finished_patients, ett index dedikerat till att lagra historiken för alla borttagna patienter. 6.1.2 Dataaggregering till webbserver Sökningar ur databasen sker via modulen ElasticAPI. Modulen utför dataag- gregeringar som används i både i prediktionsalgoritmerna (se avsnitt 7.3) och av tjänsten webserver_comm. webserver_comm är den modul som hanterar aggregeringen och publiceringen av den data som används av webbservern. Modulen hämtar med 0,5 s intervall data från databasen och formaterar den för att skickas vidare till webbservern. Datan formateras härifrån så att ingen ytterligare databehandling behöver göras senare, varken för prediktion, webbserver eller klient. Varje modul behöver därmed inte på nytt implementera samma aggregeringar som en annan modul redan implemen- terat. En fullständig specifikation av datapaketens format och de mönstermatch- ningar som görs för att skapa datan finns i bilaga A.4. Modulen webserver_comm publicerar data i form av paket på databussen via kom- munikationsprotokollet Simple Text Oriented Message Protocol (STOMP). Proto- kollet använder sig i sin tur av nätverksprotokollet Transmission Control Protocol (TCP). Datapubliceringen görs under en och samma topic: webserver_package. 23 6 Systemarkitekturen i ERICA Datapaketen är standardiserade och innehåller tre fält: type, hash och data. Ta- bell 7 visar formatet på de meddelanden som publiceras av webserver_comm. type definierar typ och form på fältet data, enligt fördefinierade konventioner anpassade till de olika grafiska komponenterna i klienten, se avsnitt 6.5. hash innehåller en hashsträng som genererats av webserver_comm med funktionen Python.hash(). Hashning genererar systematiskt en unik sträng av tecken från en datamängd, strängen blir densamma oavsett hur många gånger den genereras, så länge data- mängden är identisk, skiljer den sig däremot åt gör hashsträngen det med. Att jämföra hashsträngar istället för hela datapaketet möjliggör snabbare verifiering för mottagaren om paketet innehåller ny data, förutsatt att modulen har lagrat hashvärdet på det senaste mottagna paketet av samma typ. Denna typ av datavalidering är inte en långsiktigt bra lösning, om data endast publicerats utfall den var uppdaterad skulle validering vara onödig. Utfall en om- start av lyssnaren, modulen WebServer skulle behövas kunde denna sända ut en begäran på bussen att all data av den senaste versionen ska publiceras på nytt. Det grundar sig i att webserver_comm hämtar all typer av data på ett jämnt tidsintervall och publicera denna. Istället bör den endast uppdatera och aggregera data för en specifik typ när något ändras som berör det specifika datapaketet. Det skulle kunna göras genom att prenumerera på ändringar som publiceras på topic elvisDiff. Tabell 7: Formatet för paket publicerade av webserver_comm, ägnade åt modulen WebServer. Fält Beskrivning type Specificerar vilken typ av data som paketet innehåller. Detta gör att alla paketet publicerade av webserver_comm kan publiceras på samma topic data Innehåller själva datan för paketet. Formatet på datan i detta fält skiljer sig helt beroende på vilken modul paketet ska mottagas av hash För varje paket genereras en hashsträng så att datamottagaren ska kunna avgöra om ett identiskt paket redan mottagits utan att göra en fullständig jämförelse av paketen 6.2 Databasens implementation Grunden till databasen består av en Elasticsearch-instans. Elasticsearch är en sök- bar databasserver som automatiskt skapar indexeringar av sin data, vilket enkelt möjliggör filtrerade sökningar och aggregeringar av datan [31]. Detta är något som behövs för körningen av webserver_comm. Informationen om varje patient lagras i databasen som ett separat json-objekt. Datan som lagras i databasen har olika ursprung. Den kan antingen hämtas direkt från ELVIS, som till exempel fälten Location, Team och ReasonForVisit vilka hämtas direkt från textfälten i ELVIS, eller genereras genom att bearbeta datan 24 6 Systemarkitekturen i ERICA som kommer från ELVIS. I Tabell 8 visas en lista över alla datafält i databasen. En mer detaljerad beskrivning av datafälten och deras ursprung finns i bilaga A.2 Tabell 8: Sammanfattning av sökbara datafält som sparas i databasen. En full- ständig tabell över data i databasen samt datans ursprung finns i bilaga A.2 Datafält CareContactId PatientId Priority ReasonForVisit Team Location Events Updates CareContactRegistrationTime TimeOfTriage TimeOfDoctor TimeOfFinished TimeOfRemoved TimeToTriage TimeToDoctor TimeToFinished TimeToRemoved Eftersom databasen är under hög belastning från OngoingPatients och framförallt webserver_comm ställs krav på databasens effektivitet, framförallt på hastigheten av filtererade databassökningar. För att minska belastningen är aktiva patienter: de som befinner sig på akutmottagningen, indexerade separat från historiken: de patienter som inte längre är på akutmottagningen. Detta ger en signifikant minsk- ning av söktiden för de sökningar som bara efterfrågar aktuella patienter, vilket utgör majoriteten av alla sökningar. Varje patient har ett fält Events. Detta är en lista med de händelser som skapats av ELVIS händelsefunktion, alltså de händelser som genereras i ELVIS genom att ”dra” en patient till en mapp enligt beskrivning i avsnitt 2.4. Dessa händelser sparas i ELVIS och visas i ELVIS tidslinje men sparas också i databasen. Ur Events hämtas även Priority, vilket representerar patientens RETTS-status, som sparas i ett eget fält. Fältet Updates sparas också i databasen. Det innehåller historiken av alla inmat- ningar i ELVIS som inte lagras i Events – alltså den data som skrivs in i cellerna i ELVIS interface. Eftersom den datan ej sparas i ELVIS konstrueras den fortlöpan- de av OngoingPatients varje gång ett textfält förändras. Varje händelse i Updates innehåller en beskrivning av förändringen och en tidsstämpel för förändringen. I databasen sparas också ett antal tidspunkter för varje patient. Fältet CareContact-RegistrationTime representerar den tidpunkt då patienten skrevs in i ELVIS för första gången under besöket. Fältet RemovedTime är den tidpunkt då patienten raderades från ELVIS. En sökning efter alla patienter som var vid mottagningen vid en given tidpunkt blir mycket effektiv om den filtreras på dessa två fält. Detta är en filtrering som används i hög grad av prediktionsalgoritmerna för att hämta historisk data. Ett exempel på en sådan sökning är ”alla närvarande patienter som ej hade fått triage klockan 14:00 idag”. 25 6 Systemarkitekturen i ERICA Andra exempel på tidspunkter som sparas är TimeToDoctor, TimeToTriage och TimeToFinished. Dessa anger hur många millisekunder som passerat från CareContact-RegistrationTime till sin respektive händelse. Tidsvärdena beräk- nas genom att genomsöka fältet Events och göra en beräkning. Att gå igenom fältet är en kostsam operation och därför sparas värdena i sina egna fält – trots att det innebär en viss redundans. snapshot-datan som inkommer till bussen saknar i nuläget patienternas namn och personnummer. Istället används ett anonymiserat värde lagrat i fältet CareContactId för att kunna identifiera patienten på databasen. Detta tal ge- nereras av ELVIS innan patientdatan skickas till ERICAs databuss. Varje patient lagras i ett eget dokument som kan hämtas från databasen genom att ange pati- entens CareContactId. 6.3 Realtidsprediktion Både i vyn för koordinator och för torgen finns moduler som kräver prediktion av väntetider. I ERICA predikteras det väntade medelvärdet för TTT (tid till triage), TTL (tid till läkare) och TTK (tid till klar) för nästkommande två timmar. Prediktion innebär i korta drag att en framtidsmodell skapas, som utifrån ett an- tal parametrar beräknar utvecklingen av efterfrågade värden. Denna modell, som beskrivs närmare i avsnitt 7, lagras i en prediktionsmodul. webserver_comm skic- kar en fråga till prediktionsmodulen för att få det aktuella predikterade värdet. Prediktionen behöver då hämta data som inparametrar till modellens prediktions- funktion. Parametrarna som efterfrågas för prediktionen hämtas från databasen genom ElasticAPI. Där kallas på modellens prediktionsfunktion med de valda inparametrarna och skickar tillbaka ett resultat: det predikterade värdet. Resul- tatet returneras sedan tillbaka till webserver_comm som via bussen skickar vidare informationen till webbservern. 6.4 Webbservern – länken mellan buss och klient Webbservern består av modulen WebServer som har två funktioner. Den första är att tillhandahålla klienten det vill säga det webb-baserade användargränssnittet, klienten beskrivs mer avsnitt 6.5. Den andra funktionen är att samla in data som färdigpaketerats av webserver_comm och förse klienten med denna. Webbservermodulen är helt baserad på JavaScript och innehåller tre moduler: en Hypertext Transfer Protocol (HTTP) server, en datakommunikations länk till bussen med hjälp av en STOMP-klient samt tillhandahållandet av data till klient med hjälp av biblioteket socket.io. Ett enkelt diagram över dessa moduler syns i Figur 8. För att möjliggöra exekvering av JavaScript utanför en webbläsare an- vänds ramverket Node.js. Node.js använder Googles JavaScript-Motor V8, som konverterar JavaScript ned till maskinnära kod för snabbast möjliga exekvering. Webbservern är helt event-baserad och asynkron. Ett typexempel på detta är vid 26 6 Systemarkitekturen i ERICA prenumeration av data. När prenumeration påbörjas på ett ämne förväntas inget svar, istället exekveras koden vidare. För att behandla ett svar skickas ett handtag till en databehandlingsfunktion med prenumerationen. När data mottages exekve- ras databehandlingsfunktionen med datan som inparameter. Index Anropas från kommandora- den för att starta servern. PassiveDataService Sparar senaste informationen av varje informationstyp. StompAPI Sköter kommunikation med webserver_comm. SocketIOServer Sköter kommunikation med klienten. Figur 8: Webbserverns moduler. Pilarna representerar komposition: A→ B bety- der att B har en A. Vid överföring av data från buss till slutanvändaren används databuffertservicen PassiveDataService. Insamling av data till bufferten sker via prenumeration på topic webserver_package med protokollet STOMP. Varje grafisk komponent pre- numererar i sin tur på data från PassiveDataService vilket illustreras i Figur 9. Datan valideras sedan i tre steg. Det första datavalideringssteget kontrollerar att datapaketet följer den framtagna konventionen med fälten type, hash och data. Steg två kontrollerar att datatypen existerar i latestData, finns den inte avslutas datavalideringen. Steg tre jämför den nya hash-strängen i datapaketet mot den fö- regående som lagrats i latestHash. Överensstämmer inte hash-strängarna tolkas datan som ny. I sådant fall skrivs föregående hash och data över för den aktuella datatypen i latestHash respektive latestData. Servicen skapar ett oberoende mellan klient och databehandlingen, där klient alltid blir tilldelad senaste data, oavsett när publikationen skett av webserver_comm. 27 6 Systemarkitekturen i ERICA subscribe(status_message) PassiveDataService Ny modul Uppkopplad modul latestData(status_message) hash data type:bar_graphs latestData(bar_graphs) bar_graphs room_occupation status_message latestHash bar_graphs room_occupation status_message latestData Figur 9: PassiveDataService tillhandahåller data åt samtliga grafiska moduler via prenumeration 6.5 Klienten – visualisering av data till användaren Klienten är det webbaserade program som visar upp systemets gränssnitt i använ- darens webbläsare. Förutom de grafiska modulerna innehåller den en kommuni- kationsmodul för att kunna ta emot data från webbservern. För att initiera detta görs en prenumeration, varefter klienten kommer ta emot data från webbservern efterhand den uppdateras. De ramverk som klienten baseras på är TypeScript och Googles ramverk Angu- lar2. TypeScript är ett superset-språk till JavaScript, det vill säga det kompilerar till JavaScript. Fördelarna gentemot vanlig JavaScript är att det är starkt typat och objektorienterat. Angular2 är i grund och botten en stor samling väl förekom- mande open source-moduler tillsammans med ett antal egna moduler. Ramverket möjliggör bland mycket annat ett praktiskt sätt att dela upp webbapplikationen i moduler, kallade Components. Varje komponent innehåller eller importerar den nödvändiga HTML, TypeScript och CSS vilket minimerar mängden hämtad data och exekverad kod. ERICAs användargränssnitt består av en webbapplikation med olika vyer anpas- sade för olika avdelningar på akutmottagningen. Respektive vy laddas in i form av en vykomponent som i sin tur laddar in funktionskomponenter, enligt Figur 10. En funktionskomponent har en huvudklass som påbörjar prenumeration av data samt visualisering av komponenten via metoden draw. Varje funktionskomponent kan instansieras oberoende av andra komponenter, vilket möjliggör användandet av samma komponent i olika vyer och bibehåller den höga modularitet som genomsy- rar ERICA. Ett diagram över webbapplikationen visas i Figur 11. Här syns förutom vy- och funktionskomponenterna även huvudkomponenten App som tillhandahål- ler vykomponenterna, listan med vyer Components samt modulen SocketIO som på ett generiskt sätt sköter kommunikation med webbservern. 28 6 Systemarkitekturen i ERICA Webbapplikation Vykomponent Funktionskomponent Funktionskomponent Funktionskomponent Figur 10: Principskiss över hur komponenter av klienten läggs ihop till större kom- ponenter. App Importerar komponenter från listan Components och genererar till dessa navigeringsknappar och URL:er. Components Lista med de olika vyer- na, namn och URL:er. SquareView Vy anpassad till torgen. Faces Changes PatientCards SquareBarChart CoordinatorView Vy anpassad till koordi- natorn. Map FreeRooms TrendDiagrams CoordBarChart SocketIO Sköter kommunikatio- nen med webservern. Är en singleton, d.v.s. respektive klient har en enda instans. Figur 11: Webbapplikationens komponenter. Figuren visar hur olika komponenter hör samman, där pilarna representerar komposition: A → B betyder att B ingår i A. Streckad linje illustrerar kommunikation mellan komponenterna. Samtliga visuella komponenter är skalbara och helt oberoende av den pixelmatris webbapplikationen visas på. Det enda givna är ett koordinatsystem med ett fast förhållande mellan bredd och höjd. All grafik är vektoriserad och genereras till ele- ment som tolkas av Hyper Text Markup Language 5 (HTML5) och dess tillhörande stöd för vektorgrafik: Scalable Vector Graphics (SVG). Alla moderna webbläsare 29 6 Systemarkitekturen i ERICA stödjer idag tekniken som är mycket utbredd, därav finns det en stor mängd do- kumentation och verktyg för att utforma många typer av scenarion, till exempel användes biblioteket Data-Driven Documents (D3) för att visualisera statistiken i ERICA i SVG format. Eftersom klienten förser användaren med en realtidssituation är uppdaterad da- ta essentiellt för hela verktygets existensberättigande, därav behövs någon typ av indikation på systemets status. Genom att signalera användaren när data in- te är tillförlitlig skapas förtroende och transparens till användaren. Detta görs genom tjänsten BrokenService, som verifierar tillförlitligheten genom prenume- ration på status_message med en instans av modulen SocketIO. Data av typen status_message innehåller en nutidsstämpel som genereras av webserver_comm. Om differensen mellan föregående tidsstämpel och den nya är otillfredsställande slås varningen på, likaså om ingen tidsstämpel erhållits under samma tidsperiod. 6.6 SocketIO – Kommunikation mellan webbserver och kli- ent Socket.io är ett JavaScript-bibliotek som använder sig av WebSockets (ett kom- munikationsprotokoll) och möjliggör event-baserad, tvåvägs- och realtidskommu- nikation mellan server och klient. Socket.io är välanvänt och har ett enkelt och kraftfullt API. Socket.io:s server API och klient API har små skillnader. Båda följer en gemensam eventkanal där data kan publiceras via emit och prenumereras på via on. Det sker på ett ämne som bestäms av en arbiträr sträng som namnger typen av event tillsammans med data vid publicering, alternativt den funktion som exekveras när data på det prenumererade ämnet anländer. Om exempelvis en klient exekverar följande socket.emit("chat message", "webbutveckling är ett rörigt elände"); kommer ett event som är av typen ”chat message” och innehåller datan ”webbut- veckling är ett rörigt elände” att skickas till servern. Om serverns svarsfunktion till eventet är definierad med on-funktionen serverSocket.on("chat message", function(message) { console.log(message); }); blir resultatet att ”webbutveckling är ett rörigt elände” skrivs ut i serverns konsol. API:t med emit och on är i de flesta fall identiskt i båda riktningar. Ett sätt det skiljer sig på är givetvis att 30 6 Systemarkitekturen i ERICA socket.connect(); som implicit kopplar upp socketen till samma server som levererade klienten, en- dast kan exekveras på klientsidan. connect skickar ut ett event där datan är ett handtag till klientsocketen själv. Detta är praktiskt då det exempelvis möjliggör serverSocket.on("connection", function(socket) { socket.emit("connectionResponse", "hej"); }); som en enkel handskakningsprocedur vid uppkopplingen. Serverns emit skickar i detta fall ut eventet enbart till den socketen som precis kopplat upp. I ERICA representerar ett event en uppdatering av informationen som visas av någon av de flera komponenterna. För server-klient-kommunikationen ska fungera på ett förutsägbart sätt är det viktigt att implementationen av socket.io fokuseras på ett och samma ställe. Som beskrivits i avsnitt 6.4 har webbservern som enda uppgift att skicka data vidare samt att spara en uppsättning av den senaste da- tan av respektive datatyp. På serversidan blir fokuseringen av socket.io:s funktion därför helt naturlig. För att fokusera klientens implementation läggs så stor del av funktionaliteten som möjligt i klassen SocketIO, som utformas efter design- mönstret singleton. För denna implementation kommer TypeScript väl till pass. Implementationen static subscribe(eventType: string, onEventFunction: (eventData: any) => void) { this.connect(); socket.on(eventType, function(data) { onEventFunction(data); console.log(’received data of type ’ + eventType); }); } private static connect() { if (!this.socket) { this.socket = IO.connect(); } } är gjord så att den egendefinierade funktionen subscribe anropas av den klient- modul som vill ha en viss typ av data. Den statiska klassen SocketIO kopplar upp en socket till servern endast om denna uppkoppling inte gjorts redan. Uppkopp- ling av en ritande komponent till realtidsdata sker med ett enda funktionsanrop till subscribe, exmepelvis sker det med 31 6 Systemarkitekturen i ERICA SocketIO.subscribe(’faces_blue’, function(facesData) { this.draw(facesData); }); i modulen Faces. 32 7 Prediktion av väntetider 7 Prediktion av väntetider I detta avsnitt beskrivs och utvärderas de olika modeller som testats för att pre- diktera framtida väntetider. Samtliga modeller kan sägas tillhöra området machine learning – en vetenskap som beskriver hur datorer kan tränas att se mönster med hjälp av stora mängder data. I ERICA är prediktionens mål att i förväg utröna hur nyckeltalen TTT, TTL och TTK, beskrivna i avsnitt 2.3, kommer utvecklas. Dessa väntetider är kontinuerliga tal och det föreligger alltså ett regressionsproblem. Givet en vektor x av väl valda tillståndsvariabler för akutmottagningen söks en funktion h(x) som väl approxi- merar den framtida väntetiden y. Alla modeller som testats bygger på anpassning till ett facit av historisk data, en samling av M par som vardera består av en tillståndsvektor och en väntetid: {(x(1),y(1)), . . . ,(x(M),y(M))}. Anpassningen kallas även träning och för att detta steg skall kunna genomföras måste tillgänglig data först formateras till korrekt format. Bra grunddata att träna modellen på är avgörande för prediktionens kvalitet. I detta fall var tillgänglig data begränsad till det som kunde fås från ELVIS via ElasticAPI, se avsnitt 6.2. Ett exempel på en parameter som hade varit intressant att ta med men inte fanns tillgänglig är listan på personal som jobbar. Enligt Barrick m. fl. [32] är just sammansättningen av personalen som arbetar av stor vikt för hur många patienter som hinner behandlas per timme. Denna syn delas av personalen på NÄL. 7.1 Mätmetoder För att visa nuvarande och historiska data över TTT, TTL och TTK utvärderades flera metoder. Framförallt olika varianter på glidande medelvärden. Ett glidande medelvärde tas fram genom att ta medelvärdet av alla punkter inom ett visst intervall, i det här fallet ett tidsintervall. Alla datapunkter med väntetid 0 sorterades bort innan uträkningarna eftersom de kan antas vara triage som skett i ambulans och alltså inte är relevanta för att ge en representativ bild av väntetiden på akutmottagningen. Utvärderingen skedde genom att rita ut varianter av glidande medelvärden, linjer, tillsammans med de faktiska värdena, kryss, enligt Figur 12. Figuren visar att de olika metoderna både har fördelar så väl som nackdelar. Medelvärdet för de senaste 60 minuterna, den lila kurvan, går ner snabbast på kvällen/natten då det är få och låga triagetider – vilket är önskvärt. Dock är denna modell också mycket känslig för en enskild hög tid då det finns få tider i intervallet och går då ett för stort utslag. 33 7 Prediktion av väntetider 0 200 400 600 800 1000 1200 1400 minuter på dagen 0 20 40 60 80 100 120 TT T i m in ut er 10% nya Glidande 10p 60 min medel Exp glidande 20p Faktiska TTT-tider Figur 12: Olika sätt att beräkna glidande medelvärden samt alla TTT-värden. Y- axeln visar TTT i minuter. X-axeln visar minuter sedan kl 00:00 en exempeldag. Det glidande medelvärde på de senaste 10 datapunkterna, den gröna kurvan, har mycket stora variationer då den ändras kraftig för varje ny patient som triageras. Kurvan som representerar det 10% nya värdet, blå, är beräknad enligt formeln Tt+1 = Tt(1− α) + Tsampelα, för TTT är Tt är den senast uträknade TTT och Tsampel är den senast gjorda triagetiden. Parametern α motsvarar hur stor vikt som ska läggas på det nya medelvärdet, i det här fallet 10%, det vill säga α = 0,1 Det exponentiellt glidande medelvärdet, den gula kurvan, är beräknat på de senaste 20 triagetiderna som har fått vikter så att nya värden väger tyngre än gamla. De faktiska TTT-tiderna som visas är placerade när triaget ägde rum. På samma sätt kan även formlerna användas till TTL och TTK. För prediktionen valdes metoden med medelvärden under fasta intervall. Detta både för att prediktionen skulle vara av ett värde oberoende av nuvärdet och för att det bildar en lagom känslig kurva. Det är också något som är enkelt att förstå för personalen. Parametern som predikteras är medelvärdet på väntetiderna till eventen som kommer ske inom närmsta två timmar. Som prediktionsparametrar finns också motsvarande medelvärde för både en halvtimme, timme och två timmar vilket beskrivs i avsnitt 7.3. 34 7 Prediktion av väntetider 7.2 Implementering För att prediktera nyckeltalen användes programspråket Python och machine learning-biblioteket scikit-learn [33], [34]. Detta bibliotek valdes för att det har ett enkelt gränssnitt, god tillgång till kraftfulla algoritmer och en lämplig abstrak- tionsnivå. scikit-learn möjliggör modifikation av algoritmerna på detaljnivå men det går även att använda default-värden för att snabbt få en prediktionsmodell att utgå från. 7.3 Extrahering av prediktionsparametrar De testade prediktionerna baseras på data i Elasticsearch-databasen. Ett par in- tressanta parametrar för prediktionen finns lagrade direkt i databasen, men desto fler kan beräknas. De flesta parametrarna fås fram med den generella metoden att av Elasticsearch efterfråga en lista med närvarande patienter vid en viss tidpunkt eller inom ett visst intervall och därefter räkna antalet förekomster av något sär- skilt mönster som finns lagrat i dessa patienter. För att exempelvis få fram antal patienter som träffat läkare under senaste timmen är förfarandet: 1. Be Elasticsearch om en lista av närvarande patienter den senaste timmen. 2. Sortera ut alla event från dessa patienter märkta ”Läkare”. 3. Räkna hur många av de utsorterade eventen som skett senaste timmen. Metodiken är inte optimerad, men kraftfull för ändamålet: att med enkla medel extrahera ett stort antal prediktionsparametrar. Med en enda Elasticsearch-query och ett fåtal generella sorteringsmetoder fås ungefär 30 olika parametrar ut. Pa- rametrarna finns listade i Tabell 9, utöver dessa finns även väntad medeltid för patienter i väntrum just nu. De flesta av de implementerade modeller, som närmare beskrivs i avsnitt 7.4, är olämpliga att använda med hela den kompletta mängden tillgängliga parametrar, detta på grund av risken för överanpassning och med hänsyn till beräkningstiden. Därför används till dessa ett sparsammare urval, vilka visas i listan nedan, base- rat på de studier av arbetsgång på akutmottagningen som utförts samt mindre testningar: • Genomsnittlig väntetid senaste halvtimmen • Genomsnittlig väntetid senaste timmen • Genomsnittlig väntetid senaste två timmarna • Antal nya patienter senaste timmen • Antal event av efterfrågad typ som skett senaste timmen • Antal patienter som väntar på eventet • Genomsnittlig tid spenderad i kön för de patienter som väntar på eventet Där event motsvarar att patienten har blivit triagerad, fått träffa läkare eller blivit klar. 35 7 Prediktion av väntetider Tabell 9: Parametrar till grund för prediktion Belastningsparametrar Antal otriagerade patienter, antal patienter som inte tilldelats rum, antal som ej träffat läkare samt totalt antal patienter på mottagningen. Antalen ovan filtrerade på prioritetsfärg, det vill säga antal gröna patienter som ej träffat läkare och så vidare. Antal nyinkommande patienter under ett tidsintervall fram till nutid. Antal förmodade larmpatienter (patienter med TTT 0) under ett tidsintervall fram till nutid. Parametrar som representerar arbetskapacitet Antal triage och antal läkare-patient-möten under ett tidsintervall fram till nu- tid. Uppskattat antal läkare på mottagningen (antal unika läkarID bland eventen). Parametrar baserade på historiska värden för väntetiden Rullande medelvärde, det vill säga medelväntetiden för händelser som skett un- der ett tidsintervall fram till nutid. Ett förväntat värde för väntetiden baserat på tid på dagen och veckodag. Inför varje träning av modellerna har orimligt långa värden sorterats ut. Detta för att dessa värden oftast beror på att ELVIS har varit dåligt uppdaterat. Endast de värden som har ett output-medelvärde som uppfyller 0 < Ttriage < 100, 0 < Tläkare < 500 och 0 < Tklar < 800 minuter har använts vid träning. 7.4 Modeller Sex olika modeller har testats utförligt, ett neuralt nätverk samt fem olika sta- tistiska anpassningar: polynomanpassning, linjär regression, närmsta grannar- regression och två varianter av lasso-algoritmer, som skiljer sig när det gäller antal och typ av inparametrar. 7.4.1 Artificiella neurala nätverk Artificiella neurala nätverk är en förenklad modell av hur biologiska neuronnät fungerar. Metoden kan användas för många olika typer av machine learning med små modifikationer. Gemensamt är att metoderna bygger på att man har ett antal ”lager” av noder, först ett input-lager, därefter n stycken ”gömda” lager som kallas för kärnan och till sist ett output-lager. I metoden som används här är n = 100. När modellen tränas görs upprepade iterationer där felet varje gång mäts, utifrån 36 7 Prediktion av väntetider dessa mätningar får varje nod olika vikter. Till slut fås ett fel som är mindre än en förutbestämd tolerans och modellen är färdigtränad. Det finns flera olika metoder för hur viktningen ändras mellan iterationerna. Metoden som används här heter Adam och är en algoritm för första ordningens gradientbaserade stokastiska optimeringssystem [35]. När prediktionen sker skickar man inparametrarna till input-lagret och signalerna propageras ner till output-lagret där det predikterade värdet kan läsas av. 7.4.2 Polynomanpassning och linjär regression Polynomanpassning är en generalisering av den vanliga minstakvadratmetoden (linjär regression). Dess formella beskrivning är min θ∈RN M∑ i=1 ( y(i) − θ>φ(x(i)) )2 , därM är antalet mätningar, y(i) är utvärdet för mätning i och denN -dimensionella vektorn φ(x(i)):s element är potenser av de valda inparametrarna i x(i). Som pre- diktionsfunktion används sedan polynomet h(x) = θ>φ(x). Två olika implementeringar av algoritmen gjordes. För den första sattes φ(x):s element till samtliga produkter av x:s element med gradtal ≤ 2. Detta gradtal förmodades ge en modell som, samtidigt som den tar hänsyn till parametrar med en starkare än linjär påverkan på väntetiden, inte blir för komplicerad med över- anpassning som följd. Det gjordes ett medvetet val att i φ(x) inte bara inkludera envariabelmonom utan även monom med blandade index (produkter med blanda- de index som exempelvis x3x 2 2), då det mycket väl kan tänkas finnas ”korseffekter”; när flera olika belastningsparametrar är höga samtidigt kan den samlade effekten på väntetiden bli starkare än en superposition av de enskilda parametrarnas effek- ter. För den andra implementeringen sattes gradtalet till 1, vilket ger vanlig linjär regression. Detta är den enklaste prediktionsalgoritm som testats. 7.4.3 Närmsta grannar-regression I närmsta grannar-regression utförs inget explicit optimeringssteg. Träningsdatan används istället direkt vid varje prediktion, som är ett viktat medelvärde av de närmsta mätningarnas utvärden. Prediktionsfunktionen med hänsyn till N närms- ta mätningar kan skrivas h(x) = ∑N i=1 w (i)y(i)∑N i=1 w (i) , där w(1), . . . ,w(N) är vikter, som kan vara lika stora eller låtas bero på avståndet mellan x(i) och x. Vid aktuell implementering togs som närmsta grannar de 5 mätningar med kortast euklidiskt avstånd ∥∥∥x− x(i) ∥∥∥ 2 från den nya mätpunkten. Grannarna viktades med inversen på det euklidiska avståndet. 37 7 Prediktion av väntetider 7.4.4 Lasso Lasso-algoritmen liknar minstakvadratmetoden men skiljer sig med den tillkomna termen α ‖θ‖1. Denna term kan sägas minska inflytandet från de inparametrar som har liten påverkan på y, sådana parametrars tillhörande koefficienter i θ går mot 0. Benämningen lasso syftar till att algoritmen viktar, och därmed kan sortera ut, de inparametrar som har störst påverkan på y. Lasso kan användas med väldigt många inparametrar. Optimeringsproblemet kan skrivas min θ∈RN 1 2M N∑ i=1 ( y(i) − θ>x(i) )2 + α ‖θ‖1 och prediktionsfunktionen är h(x) = θ>x. Två olika implementeringar av lasso-algoritmen gjordes. Vid den första användes listan med sju utvalda inparametrar, vilket med ett rimligt valt α ger en predik- tionsfunktion där de flesta inparametrarna fortfarande är med men är viktade efter betydelse. Den andra implementeringen är inspirerad av artikeln ”Accurate Emer- gency Department Wait Time Prediction” [36] och med filosofin ju fler desto bättre beträffande inparametrarna. Artikeln beskriver en algoritm namngiven Q-lasso där Q syftar på ett flödestänk. Q-lassos inparametrar genereras genom att utifrån de parametrar givna i Tabell 9 ta samtliga bråk av formen arbetsbörda/arbetstakt. Bråken har dimensionen tid och anses vara betydelsefulla för väntetiden [36]. Vari- abeln α sattes för implementationen med färre parametrar med hjälp av program- varan, som själv testar olika värden och väljer det den finner bäst. För Q-lasso sattes värdena ”för hand” genom att testa sig fram och välja ett α som ger litet medelfel, ett rimligt antal icke-nollställda koefficienter (. 15) och en rimlig graf. För lasso respektive Q-lasso blev α-värdena αTTT = 0,24 αTTL = 4,54 αTTK = 12,18 ,  αTTT = 0,1 αTTL = 1,0 αTTK = 4 . 7.5 Utvärdering av modeller Metoden som använts för att utvärdera modellerna för prediktionen är k-fold cross validation [34]. Modellerna tränas då k gånger på en k−1 k -andel av datan och testas sedan på den resterande datan. I utvärderingen användes k = 10 vilket alltså innebär att datan har delats upp i tio delar, och att modellen för de tio möjliga uppdelningarna tränas på nio delar och testas på den tionde. I Figur 13 visas resultatet av k-fold cross validation för TTT för vardera av de tes- tade modellerna, med predikterat värde på y-axeln och korresponderande uppmätt värde på x-axeln. Motsvarande diagram för TTL och TTK finns i bilaga A.5. 38 7 Prediktion av väntetider Tabell 10: Medelvärde, median, standardavvikelse och procentuell avvikelse på absolutbeloppet på felen från utvärdering av prediktionsmodellerna för TTT, TTL och TTK genom k-fold cross validation. Medelvärde Median STD Procentuellt TTT Neuralt nätverk 5,062 3,793 8,479 28,1% Lasso 5,055 3,825 8,231 28,1% Linjär 5,056 3,833 5,394 28,1% Polynom 5,058 3,874 5,728 28,1% KNN 5,706 4,200 6,010 37,1% Q-Lasso 5,381 4,116 8,173 29,9% TTL Neuralt nätverk 28,68 18,08 62,83 22,5% Lasso 28,34 19,01 60,11 22,2% Linjär 28,43 19,19 33,06 22,3% Polynom 28,01 18,95 31,98 22,0% KNN 32,60 21,46 36,43 22,5% Q-Lasso 28,48 19,10 60,81 22,3% TTK Neural nätverk 33,88 21,00 73,12 15,0% Lasso 32,70 20,31 70,08 14,5% Linjär 32,80 20,29 42,15 14,5% Polynom 33,21 20,76 41,95 14,7% KNN 39,32 25,43 49,33 17,4% Q-Lasso 40,88 28,25 68,38 18,1% I Tabell 10 syns resultatet av k-fold cross validation för modellerna. Det är intres- sant att se att så väl medelvärdet som medianen av absolutbeloppet på felet är väldigt likt mellan modellerna, framförallt för TTT. Medianen är också lägre än medelvärdet för alla modellerna vilket beror på att vissa extrema värden drar upp det senare. Detta syns i Figur 13 där de flesta prickarna ligger i en klump nära y = x men några enstaka ligger långt bort. Något annat intressant som syns i Figur 13 är att de flesta modeller aldrig eller mycket sällan predikterar värden under 10 minuter. Att anpassningarna fungerar i vissa mätområden men inte i andra kan tänkas vara ett tecken på att någon typ av lokal viktning skulle vara lämplig. Denna förmodan stöds av det faktum att närmsta grannar regressionen (KNN), som är lokalt viktad, verkar ge rimligast prediktion vid låga värden. 39 7 Prediktion av väntetider 20 0 20 40 60 80 100 Pr ed ik te ra t Neuralt Nätverk Lasso 20 0 20 40 60 80 100 Pr ed ik te ra t Linjär Polynom 20 0 20 40 60 80 100 Uppmätt 20 0 20 40 60 80 100 Pr ed ik te ra t KNN 20 0 20 40 60 80 100 Uppmätt Q-Lasso Tid till triage Figur 13: Resultat av prediktionsutvärdering baserad på k-fold cross validation. På y-axeln visas det predikterade värdet och på x-axeln visas de uppmätta värdena. Alla värden är medel-TTT i minuter. Den streckade linjen går längs y = x. Medelvärdet för TTT på testvärdena var 18 minuter, jämfört med 128 minuter för TTL och 226 minuter för TTK. Trots att det vid en första anblick i Tabell 10 ser ut som om felen är större på TTL och TTK än TTT bör det jämföras med medelvärdena för de olika tiderna som skiljer sig. Det tas i beaktning i kolumnerna ”procentuell avvikelse på absolut fel” som är medelvärdet på absolutbeloppet av felet dividerat med medelvärdet på TTT, TTL respektive TTK. Jämförs de ko- lumnerna syns att det är TTK som har lägst procentuellt fel och därför i någon mån det lättaste nyckeltalet att prediktera. Utvärderingen visar att de olika prediktionsmodellerna gav ungefär lika bra resul- tat. Valet på modell till ERICA föll till slut på polynomanpassningen. Detta för den har bra resultat för alla jämförelsevärden och dessutom är snabb, till skillnad från vissa av de andra modellerna. 40 8 Utvärdering och diskussion 8 Utvärdering och diskussion Avsnittet behandlar och presenterar resultatet av den testning som utförts på NÄL, de åtgärder som gjorts under testperioden samt den framtida utvecklings- potentialen för ERICA. Vidare diskuteras problematik och möjligheter med den begränsning av data som finns idag. 8.1 Realtidstest på NÄL ERICA testkördes under sju dagar på plats på NÄL. Första tiden av testperioden kantades av många små problem som åtgärdades fortlöpande när de upptäcktes. Under de tre sista dygnen genomfördes dock testningen utan avbrott och inga ytterligare fel hittades. Systemet mottogs mestadels väl från användarna och blev mycket uppmärksam- mat på arbetsplatsen. ERICA blev ett naturligt verktyg i arbetet och personalen uttryckte saknad av framförallt koordinatorvyn när testet avslutades. En nackdel under testet var att personuppgifter, eller andra uppgifter som lätt kopplar en patient till viss data, inte fanns tillgängliga. Detta gjorde testet av torgvyn bristfälligt då den är uppbyggd med patienten i fokus. 8.1.1 Åtgärder under testperioden I prototypskissen över torgkonceptet, beskriven i avsnitt 5.2.2, är den nedre vänst- ra ytan med plats för patienter är uppdelad i Inre väntrum och Övriga platser. Under den slutliga testningen upptäcktes att detta skapade en odynamisk situa- tion då respektive kategori hade ett statiskt maxantal samtidigt som fördelningen varierade. Patienter i väntrum och på andra platser sammanfogades därför på en gemensam yta. I samma vy finns de två cirklarna som visar TTL och TTK med tillhörande smiley, som indikerar hur nyckeltalen är i nuläget, och en pil, som visar den förväntade utvecklingen av nyckeltalen. Vid testning på NÄL framkom det att denna funktion inte hjälpte personalen. Istället upplevdes nyckeltalen bidra negativt till arbetet genom att visa information som inte går att påverka, se avsnitt 5.3. Vidare upplev- des funktionen väl pessimistisk, bland annat på morgonen då det inte hade varit någon läkare på plats under natten vilket gjorde att tid till läkare, helt naturligt, hade ökat. Funktionen doldes därför under den senare delen av testet. För vidare utveckling av systemet bör de här symbolerna ses över för att de ska fylla sitt syfte att visa hur belastningen på akutmottagningen ser ut utan att påverka personalen negativt. Tidigare tog servicen OnGoingPatients bort patienter när en diff fås av Trans- formationService enligt beskrivning i avsnitt 6.1.1. En svaghet som upptäck- tes under testningen var att om en diff missas tas patienten aldrig bort. För 41 8 Utvärdering och diskussion att råda bot på det skapades en ny service, PatientRemover. Modulariteten hos ERICAs moduler och med bussen som kommunikationslänk var införandet av PatientRemover en problemfri uppgradering av systemet. Även denna modul finns beskriven i avsnitt 6.1.1. 8.2 Validering av resultat För att utvärdera funktionerna i ERICA har ett antal testscenarion utförts i ERI- CA samt ELVIS där antalet interaktioner i de olika systemen mätts och jämförts. Någon omfattande utredning av hur arbetssituationen på akutmottagningen har förbättrats med hjälp av ERICA har inte genomförts, men för att ge en fingervis- ning om resultatet presenteras här en kort enkätundersökning som personal som arbetat med och runt ERICA fått svara på. Dessutom gjordes en sammanställning av subjektiva bedömningar från utvecklarna, cheferna på akutmottagningen samt slutanvändarna. 8.2.1 Teoretisk utvärdering av ERICA Det finns vissa informationssökningar som görs mycket frekvent i ELVIS. Förhopp- ningen är att ERICA ska underlätta dessa genom att visualisera data direkt utan att en aktiv sökning behövs. För att belysa skillnaderna mellan systemen baseras den här utvärderingen på antalet interaktioner som krävs för att få fram viss in- formation. Sökningarna som testades valdes utifrån hur vanligt förekommande och hur kritiska de är för arbetet på mottagningen. För koordinatorvyn granskades antalet interaktioner för att få följande informa- tion: antal patienter på ortopedtorget, antal patienter på medicintorg blå, jämfö- ra antal patienter mellan medicintorg blå och gul samt hitta ett ledigt rum. På torgvyn studerades istället hur många interaktioner det krävs för att ta reda på följande: om någon patient är i behov av omvårdnad samt ta reda på vad den senaste händelsen på avdelningen var. Antalet interaktioner i ERICA jämfördes med antalet interaktioner med ELVIS. Resultaten från de teoretiska testerna redovisas i Tabell 11. Varje interaktion är separerad med →. Notera att ELVIS är ett interaktionsbaserat system medan ERICA är ett mer passivt system. Det gör testet fördelaktigt för ERICA. Utvär- deringstabellen visar tydligt att ELVIS är ett system som kräver mycket mer tid och fokus än vad ERICA gör för att få ut mycket enkel information. 42 8 Utvärdering och diskussion Tabell 11: Ett urval av vanliga informationssökningar som kan utföras med ELVIS respektive ERICA samt interaktionsföljden för de båda systemen. System Interaktioner Koordinatorvyn, antal patienter på ortopedtorget ELVIS Sortera på avdelning → Räkna antalet patienter ERICA Titta i stapeldiagram för ortoped Koordinatorvyn, antal patienter på ett medicintorg ELVIS Sortera på avdelning → Sortera på rum → Räkna antalet patienter ERICA Titta i stapeldiagram för respektive medicintorg Koordinatorvyn, jämför antal patienter på medicintorgen ELVIS Sortera på avdelning