lasttester av implementationer av...

Kandidatarbete

Lasttester av implementationer

av FHIR-standarden

2

Författare: Päivi Piirainen

Handledare: Tobias Olsson

Termin: VT 2017

Ämne: Datavetenskap

3

Sammanfattning

I dagens sjukvård har patienten allt större möjlighet att själv välja utförare av

vårdinsatser, samtidigt som högspecialiserad vård i högre grad utförs på ett

fåtal ställen i landet. Detta medför ett ökat behov av att kunna ta del av

patientinformation från olika system och vårdgivare. Ett sätt att möjliggöra

detta är att tillgängliggöra standardiserade tekniska gränssnitt i vårdsystemen

för att läsa och spara information. I detta arbete undersöks hur system som

stödjer en av dessa standardiserade tekniska gränssnitt (FHIR) kan testas

avseende prestanda och skalbarhet för att uppfylla de krav som kan ställas på

en implementation som kan användas nationellt. Arbetet omfattar en teoretisk

bakgrund till problemet, framtagande av realistiska tester samt resultatet av att

använda dessa tester på två referensimplementationer av FHIR standarden. När

testerna tillämpades på dessa implementationer framkom i ena fallet vilken

maximal last lösningen kan hantera med den givna servermiljön, och i det

andra fallet avslöjade dessa tester en bug i implementationen som medförde

problem vid höga laster.

Nyckelord: FHIR, skalbarhet, HL7

4

Innehåll

1 Introduktion ________________________________________________ 6 1.1 Bakgrund _____________________________________________ 6

1.2 Tidigare forskning ______________________________________ 8 1.3 Problemformulering _____________________________________ 9 1.4 Motivation ____________________________________________ 9 1.5 Forskningsfrågor _______________________________________ 9 1.6 Avgränsningar _________________________________________ 9

1.7 Målgrupp ____________________________________________ 10 1.8 Disposition ___________________________________________ 11

2 Metod ___________________________________________________ 12 2.1 Tillförlitlighet och validitet ______________________________ 12 2.2 Etiska överväganden ___________________________________ 12

3 Intervju av handledare _______________________________________ 13

3.1 Fråga 1: Hur många tänkbara användare är det som tar del av

vårdinformation? ____________________________________________ 13 3.2 Fråga 2: Hur många av dessa användare tar del av data i en viss

installation av ett vårdinformationssystem? _______________________ 13 3.3 Fråga 3: Hur många patienter finns det dokumentation om? _____ 14

3.4 Fråga 4: När blir en patientjournal läst och skriven? ___________ 14

4 Utformning av prestandatester ________________________________ 15

4.2 Installation av JMeter ___________________________________ 17 4.3 Framtagande av testfall i JMeter __________________________ 18

4.4 Sammanställning av anrop för att läsa och skapa FHIR resurser __ 20 4.5 Testfall primärvård _____________________________________ 21 4.6 Testfall specialiserad vård _______________________________ 22

4.7 Testfall läsa patientdata _________________________________ 23 4.8 Sammanställning av testresultat ___________________________ 24

5 Resultat __________________________________________________ 25 5.1 Tester av Furore Sparks _________________________________ 25 5.2 Tester av Grahame _____________________________________ 26

6 Analys ___________________________________________________ 27

7 Diskussion ________________________________________________ 28

8 Sammanfattning ___________________________________________ 29 8.1 Framtida forskning _____________________________________ 30

9 Referenser ________________________________________________ 31

5

Bilaga 1 JSON för FHIR resurser _________________________________ 33

6

1 Introduktion

Sedan 2000-talet har patientens möjlighet att fritt välja utförare av vård ökat

genom ny lagstiftning (2008:962). Patientlagen (2014:821) som trädde i kraft

2015 har som syfte att stärka patientens självbestämmande och delaktighet i

sin vård.

För att säkerställa en patientsäker vård, krävs tillgång till patientens data

oavsett var denna har vårdats tidigare.

1.1 Bakgrund

Det finns en relativt ny blivande standard för hantering av patientinformation

från standardiseringsorganisationen HL7, Fast Healthcare Interoperability

Resources, som förkortas till FHIR. Standarden beskriver hur vårdinformation

ska kommuniceras mellan olika system genom ett standardiserat tekniskt

gränssnitt (API). Denna standard har väckt stort intresse nationellt i Sverige

och är en möjlig lösning att använda för kommunikation av patientinformation

mellan landsting, kommun och andra myndigheter.

Belastning på ett system med vårdinformation skiljer sig från exempelvis

ett e-handelssystem. Det finns stora mängder strukturerat och ostrukturerat

data i ett vårdinformationssystem och sökmönster skiljer sig markant. Ett e-

handelssystem kan ha ett stort antal kunder och artiklar men antalet kunder

överstiger sannolikt antalet olika artiklar. Ett av de stora undantagen här är

ehandelsbolaget Amazon som agerar återförsäljare åt ett stort antal mindre

bolag. Under år 2015 hade de i storleksordningen lika många artiklar som

registrerade användare [1] [2]. Inom hälso- och sjukvård är förhållandet

annorlunda. En användare arbetar med information om en viss patient och det

är osannolikt att denna information samtidigt används av en annan användare.

Antalet patienter som det finns information om är mycket större än antalet

användare. Dessa sökmönster måste beaktas när man utformar realistiska

prestandatester.

Uppdraget för detta projekt har formulerats av MedMod IT Solutions

AB, ett konsultbolag som har ett flertal uppdrag inom nationell arkitektur och

informationsmodellering inom e-hälsoområdet. Syftet med projektet är att

undersöka vilka trafikmönster som uppkommer i verkligheten och efterlikna

dessa i automatiserade lasttester. Dessa tester kan sedan användas för att

utvärdera skalbarhet hos implementationer av FHIR-standarden. I detta projekt

kommer två open source referensimplementationer att testas och utvärderas.

1.1.1 FHIR

Standarden FHIR beskriver hur vårdinformation kan kommuniceras

strukturerat med hjälp av arkitekturprincipen Representational State Transfer

7

(REST). FHIR definierar kommunikationen i ett antal olika

resurser/informationsmängder så som exempelvis information om patient

(Patient), observationer (Observation), utförda aktiviteter (Activity), och

vårdkontakter (Encounter) med mera.

Enligt Fielding [3] är REST en abstraktion av den arkitektur som använts

framgångsrikt inom distribuerade hypermedia system (world wide web). REST

ignorerar implementations och protokoll-syntax och fokuserar istället på

komponenternas roller, hur man kan interagera med dessa och hur deras

informationsinnehåll ska tolkas. En nyckelabstraktion inom REST är en resurs

som representeras av en resursidentifierare (URL). Dessa resurser kan

modifieras läsas, skapas och modifieras med verb enligt http-protokollet (get,

put, delete).

Med vårdinformation avses den information som samlas in och

dokumenteras i planering och utförande av vård av en patient. Interoperabilitet

är förmågan att kunna utbyta och förstå information som kommuniceras mellan

olika organisationer och system.

En resurs i FHIR är en avgränsad mängd information för ett begrepp som

är en del av den dokumenterade vårdinformationen.

1.1.2 Referensimplementationer

FhirServer är en open source referensimplementation av FHIR byggd med

hjälp av språket Pascal i utvecklingsmiljön Delphi med datalagring i en

Microsoft SQL Server databas. Implementationen förvaltas av företaget Health

Intersections och är i huvudsak utvecklat av Grahame Grieve som är en av

grundarna till FHIR-standarden [4].

Spark är ytterligare en open source referensimplementation av FHIR

standarden byggd med programmeringsspråket C# och ASP.NET med

datalagring i MongoDB. Implementationen förvaltas av företaget Furore [5].

8

1.2 Tidigare forskning

Olika former av tester av mjukvara har studerats i ett stort antal artiklar.

Weyuker och Vokolos tar bland annat upp vikten av att definiera mätbara mål

med prestandatester och vikten av att de framtagna testerna kan användas för

att verifiera att dessa uppnås [6].

Det finns forskning på prestanda och lasttester i allmänhet, exempelvis

Jiang [7] har skrivit en sammanfattning av forskningsläget inom lasttester av

storskaliga lösningar år 2015. Denna artikel reflekterar bland annat över olika

strategier för hur tester kan designas. Den ena skolan eftersträvar att efterlikna

driftsituationen så långt det är möjligt. Den andra skolan är att ta fram lasttester

som överbelastar systemet för att undersöka hur systemet uppför sig under

extrema förhållanden.

Det finns specifik forskning kring hur patientjournalsystem ska utformas

för att säkerställa en hög prestanda [8]. Yang och Liu [9] behandlar specifikt

lasttestning av OpenXDS en implementation av XDS standarden (cross

document sharing) för att kommunicera kliniska dokument. Artikelförfattarna

har utfört praktiska tester där de lasttestar OpenXDS för att identifiera

flaskhalsar. Under sitt försök mäter de CPU- och minnes-utnyttjande samt

nätverksbelastning.men dessvärre inte belastning på disksystemet, vilket gör

det svårt att se om den långa svarstiden kan ha med diskläsning att göra.

AbuKhousa, Mohamad och Al-Jaroodi [10] beskriver nyttan med att

bygga system för vårdinformation som molnapplikationer. Genom att dela på

infrastrukturen och den tekniska lösningen kan vården fokusera på sin

kärnverksamhet, att vårda patienter. Författarna listar upp ett antal utmaningar

med den föreslagna lösningen där bland annat tillgänglighet och skalbarhet

dyker upp på denna lista.

9

1.3 Problemformulering

Målet med denna studie är att skapa en uppsättning tester som kan simulera en

realistisk last motsvarande en nationell användning av FHIR standarden.

Dessa tester kommer sedan att användas för att jämföra två befintliga

referensimplementationer av FHIR standarden med varandra med avseende på

prestanda och funktionalitet. De två implementationerna har tagits fram med

olika val avseende på tekniska lösningar. Den första lösningen är byggd i

programspråket Delphi med en Microsoft SQL Server för datalagring. Den

andra lösningen är en .NET lösning där man valt Mongo DB som lösning för

datalagring.

Intresset är både resultatet av prestandatesten, men också det framtagna

automatiserade testerna för att testa FHIR-implementationer med avseende på

deras prestanda i storskaliga miljöer.

1.4 Motivation

Tester av driftmiljöer för storskaliga nationella lösningar inom hälso- och

sjukvård är viktigt för att säkerställa att de kan klara av den belastning som

uppstår i drift. Genom att undersöka hur realistiska tester ska utföras kan

produkter och system utvärderas med högre tillförlitlighet i resultatet.

1.5 Forskningsfrågor

F1 Vilka trafikmönster uppkommer i verkligheten?

F2 Hur ska prestandatester utformas för att bäst efterlikna de trafikmönster

som uppkommer i verkligheten?

De troliga trafikmönster som uppkommer i verkligheten handlar om att många

användare hämtar och skapar information om många olika patienter.

Prestandatester borde därför kräva att ett stort antal unika patienter skapas

under lasttester.

1.6 Avgränsningar

Det finns flera tänkbara standarder för kommunikation av vårdinformation

men i detta arbete undersöks endast den i uppdraget givna standarden FHIR.

Under detta arbete kommer endast ett verktyg för att utföra lasttester

användas. Ingen jämförelse mellan olika alternativ kommer att genomföras

utan fokus kommer att vara på hur testerna ska utformas utan att vara

verktygsspecifikt.

De scenarion som kommer att testas är endast den primära användningen

och skapandet av vårdinformation som sker under vård och behandling av

10

enskild patient, inte uppföljning och statistik av grupper av patienter. Denna

typ av uppföljning förutsätts kunna utföras genom export av data från den

primära lagringskällan till sekundära lösningar specialiserade för

uppföljningssyftet.

Inom vården samlas olika typer av information in. Denna kan vara i form

av kodad information, löpande text, eller binära format som exempelvis bild,

ljud eller video. Bildmedicin är ett speciellt delområde inom vården som

hanterar bland annat magnetresonanstomografi. Denna typ av undersökning

genererar mycket stora volymer av bilddata som lagras i för detta speciellt

avsedda lagringslösningar. Detta arbete kommer att avgränsas till att endast

titta på kodad information samt löpande text som lagras i det primära

vårdinformationssystemet.

1.7 Målgrupp

Detta arbete är främst av intresse för de som arbetar med arkitektur, utveckling,

implementation och test av vårdinformationssystem nationellt, regionalt eller

lokalt.

11

1.8 Disposition

Rapporten är disponerad enligt följande:

• Kapitel 2 Metod

Metoden för hur arbetet är utfört.

• Kapitel 3 Implementation

Beskriver den praktiska implementationen av lasttesterna.

• Kapitel 4 Resultat

Här redovisas resultatet av att tillämpa lasttester.

• Kapitel 5 Analys

En analys av resultatet av de genomförda lasttesterna.

• Kapitel 6 Diskussion

Diskussion avseende hur denna studie svarar på forskningsproblemen.

Samt jämförelsen med tidigare forskning inom området.

• Kapitel 7 Sammanfattning

Sammanfattningen reflekterar över resultatens relevans för vetenskap,

industri eller samhälle.

12

2 Metod Projektet omfattar två forskningsfrågor som besvaras med olika metoder.

Första frågan som berör de verkliga trafikmönstren, utreds med en informell

intervju med handledaren. Den andra frågan som berör utformning av

prestandatester besvaras genom framtagande av användarscenario och

implementation av dem i form av exekverbara lasttester. Dessa lasttester

används sedan för att testa två referensimplementationer av FHIR-standarden.

Experimentets beroendevariabler är latens och antal anrop per tidsenhet.

Latens är tiden det tar för att utföra ett enskilt anrop till en tjänst, exempelvis

lagra information om en utförd medicinsk åtgärd. Oberoende variabel är antal

anrop per tidsenhet. Värdet justeras för att undersöka hur latensen förändras

beroende på antal anrop per tidsenhet. Ovanstående mätningar utförs med hjälp

av JMeter och de tidigare framtagna testerna.

2.1 Tillförlitlighet och validitet

Resultatets validitet är i huvudsak beroende av hur väl lasttesterna kan

efterlikna verkliga trafikmönster. Experimentet kommer att utföras i en

kontrollerad miljö som isolerar vissa utvalda aspekter av en verklig användning

av systemet. Validiteten i experimentet är beroende av vad som väljs och vad

som väljs bort att simulera. En del av arbetet omfattar att under intervjufasen

identifiera de testfall som bäst motsvarar den förväntade användningen av ett

verkligt system.

Till resultatet redovisas använda verktyg, maskinvara samt mätmetod för

att säkerställa att experimentet går att utvärdera och upprepa.

2.2 Etiska överväganden

Även om projektet avser information om personers hälsa, är allt data fiktivt.

Resultatet främjar kunskap om hur prestandatester kan utformas för att

simulera verklig användning av vårdinformationsystem.

13

3 Intervju av handledare Den informella intervjun med handledaren omfattar fyra stycken frågor. Den

första frågan handlar om antalet användare som tar del av vårdinformation följt

av en fråga som berör användarnas fördelning över installationer av olika

vårdsystem. Den tredje frågan handlar om hur många dokumenterade patienter

det finns. Sista frågan definierar när en vårdinformation blir läst och skriven.

Svaren på intervjufrågorna används som utgångspunkt för framtagande

av användarscenario och implementation av dem. Handledaren har under

intervjun möjlighet att söka fram statistik som bidrar till svaren på frågorna.

Statistiken fungerar som underlag till utformning av tester.

3.1 Fråga 1: Hur många tänkbara användare är det som tar del av

vårdinformation?

Varje år skrivs en rapport om ehälsa [11] på uppdrag av SLIT (Landstingens

IT-strateger/IT-chefer). I den rapport som publicerades i maj 2016 kan man

läsa att det fanns totalt 257237 användare av vårdinformationssystem inom

landstingen idag. Dessa användare har tillgång till cirka 260 000

datorarbetsplatser, det vill säga färre än en användare per dator. Utöver detta

nämner rapporten ett växande antal mobila klienter som i 8 landsting stödjer

2-faktor/stark autentisering som är en förutsättning för att kunna ta del av

patientinformation [12]. Av detta kan man dra slutsatsen att antalet samtidiga

användare inte kommer att begränsas av brist på datorarbetsplatser eller mobila

enheter utan endast av om arbetsuppgifterna vid ett givet tillfälle kräver

datoranvändning.

Utöver vårdpersonalen finns det idag ett betydande antal patienter som

har möjlighet att ta del av sin journal. Det fanns i februari 2017 enligt en

rapport från Inera (ett dotterbolag till Sveriges Kommuner och Landsting) 1

miljon registrerade användare i e-tjänsten Journalen som ger patienten

möjlighet att ta del av sin egen journal på nätet. I snitt 20 000 av dessa

användare loggar in för att ta del av sin journal per dag.

3.2 Fråga 2: Hur många av dessa användare tar del av data i en

viss installation av ett vårdinformationssystem?

Sedan 2008 finns en ny patientdatalag [13] i Sverige. Den möjliggör något som

benämns som ”sammanhållen journalföring”, vilket innebär att vårdpersonal

med patientens samtycke har rätt till att ta del av information från samtliga

vårdgivare som patienten har besökt. Den nationella arkitekturen medger idag

att vårdpersonal via exempelvis webbapplikationen NPÖ (nationell

patientöversikt) läser all tillgänglig information om en patient. Inom

14

arkitekturen finns en optimering (Engagemangsindex) som har information om

i vilka system det finns vilken typ av information om en given patient. Detta

innebär att frågor endast skickas till de system som faktiskt har information om

den givna patienten.

3.3 Fråga 3: Hur många patienter finns det dokumentation om?

Det är svårt att hitta exakt statistik om hur stor vårdkonsumtionen är totalt i

Sverige. I en artikel från 2014 i tidningen sjukhusläkaren [14] nämns siffran

3,8 patienter per dag och läkare. Antalet anställda läkare återfinns i statistik

från SKL, Sveriges Kommuner och Landsting, i tabell 4A [15]. År 2015

uppgick detta till 33 159 st. Kombinationen av dessa siffror ger ungefär 126

000 besök per dygn. Om man i sin tur tittar på hur många patientjournaler det

finns i vårdsystemen kan man exempelvis titta på siffror från Stockholms Läns

Landsting som har systemet TakeCare från företaget CompuGroup Medical

(CGM) som huvudjournalsystem. På leverantörens hemsida kan man läsa att

den installationen idag innehåller cirka 2,3 miljoner journaler. Detta är i

storleksordningen lika många journaler som det finns invånare i länet.

3.4 Fråga 4: När blir en patientjournal läst och skriven?

Enligt lagstiftning ska patientjournal föras vid all utövning av hälso- och

sjukvård [16]. Detta innebär att journalen blir både läst och skriven vid

samtliga 126 000 dagliga besök. Man kan anta att större delen av dessa besök

består av unika patienter. Utöver de skrivningar och läsningar som hälso- och

sjukvårdspersonal utför så läggs ytterligare 20 000 läsningar per dygn till från

patienterna själva (en patient har inte laglig rätt att skriva i journalen). Detta

innebär nära 150 000 skrivna och lästa journaler per dygn över hela landet. För

ett enskilt system är siffran troligen lägre. Vid skrivning av journal kan man

räkna med att ett antal olika uppgifter skrivs med separata systemanrop. Om vi

antar att ungefär 20 uppgifter läses och skrivs per patientjournal samt att

huvuddelen av den vård som bedrivs sker under normal kontorstid 8-18 så ger

detta sammanräknat ungefär 85 anrop per sekund. Ett rimligt antagande är att

ett system då bör testas för 100 anrop per sekund för att säkerställa att det finns

marginaler. Notera att i ovanstående resonemang används hela nationens

belastning som beräkningsgrund.

15

4 Utformning av prestandatester Tre användarscenarion har tagits fram för att simulera realistisk användning av

vårdinformationssystem. Den första beskriver patient i primärvården, den

andra simulerar patient i sluten vård och den sista handlar om läsning av

patientens vårdinformation.

4.1.1 Patient i primärvård

I det första scenariot (se Figur 4.1 ) gör en patient ett besök i primärvård/öppen

vård. Detta är vanligtvis en kort process som inleds med att patienten

registreras i kassan. Efter en viss väntetid får patienten besöka en

primärvårdsläkare eller distriktssköterska. Patienten genomgår då en

undersökning där en eller flera observationer dokumenteras. Efter detta ställs

en diagnos som också dokumenteras och noll till flera åtgärder vidtas.

Scenariot avslutas utan ytterligare dokumentation. Enligt statistik från Sveriges

Kommuner och Landsting [17] är ungefär hälften av de utförda läkarbesöken

inom primärvård.

Figur 4.1 Patient i primärvård/öppen vård samt mappningar till FHIR-

resurser

16

4.1.2 Patient inom sluten vård

I det andra scenariot skrivs patienten in i sluten vård (se Figur 4.2 ). Inskrivning

innebär att en vårdplats reserveras för patienten, exempelvis en säng eller ett

rum på en avdelning. Efter inskrivningen genomgår patienten en kombination

av undersökningar och medicinska åtgärder innan patienten slutligen är

färdigbehandlad och skrivs ut. Efter dokumentation av utskrivning lämnar

patienten avdelningen och inget mer dokumenteras inom scenariot.

4.1.3 Patient läser sin egen vårdinformation

I detta scenario väljer patienten att efter avslutad vård ta del av sin egen journal

elektroniskt (se Figur 4.3 ). Den tekniska lösning som patienten använder läser

ut information om patientens samtliga vårdtillfällen, undersökningsresultat

samt dokumentation om utförda åtgärder.

Figur 2.3 Patient tar del av egen journal med mappningar till FHIR-resurser Figur 4.3 Patient tar del av egen journal med mappningar till FHIR-resurser

Figur 4.2 Patient inom sluten vård samt mappningar till FHIR-resurser

17

4.1.4 Teknisk implementation

Implementation av de tre ovanstående scenarierna sker i verktyget Apache

JMeter. JMeter är utvecklat för att lasttesta webapplikationer och dess

funktionalitet samt mäta prestanda. Verktyget kan laddas ner och användas

kostnadsfritt.

För att kunna simulera olika patienter med olika problem,

undersökningar och åtgärder finns möjlighet att använda JMeters inbyggda

komponenter samt vid behov Groovy script. Groovy script är skriptspråket som

JMeter använder för att scripta avancerade dynamiska tester. De framtagna

testerna kan exekveras mot systemet under test med hjälp av programmet

JMeter.

4.2 Installation av JMeter

Innan det faktiska implementationsarbetet kan börja, sker det en installation av

JMeter. Det är viktigt att säkerställa att det verkligen fungerar att köra

lasttester mot HTTP och att det går att scripta lasttesterna för att simulera olika

patienter i det valda testverktyget. Verifieringen utfördes genom att studera

JMeter-dokumentationen och jämföra mot de kraven som ställs för att kunna

genomföra testerna. I detta projekt har version 3.2 av JMeter använts [18].

18

4.3 Framtagande av testfall i JMeter

När installationen av JMeter är avslutad och fungerar korrekt påbörjar man

arbetet med en ny testplan. Testplanen består av de tre huvudsakliga

testscenario som har tagits fram. Dessa tre är döpta till PrimaryCare,

SpecialistCare samt PatientDataAccess (se Tabell 4.1 Förteckning över Thread

Groups ) och representeras av det som i JMeter benämns Thread Groups. I

varje Thread Group skapas en HTTP request för varje interaktion det vill säga

skrivning eller läsning av en FHIR resurs. I REST-protokollet utnyttjas HTTP

verb GET och POST för att skilja på läsning och skrivning av en resurs. Även

om möjligheten fanns att utnyttja Groovy script i JMeter så behövdes detta inte

i praktiken för de valda testfallen.

Thread group Beskrivning

PrimaryCare Simulerar patientbesök i primärvård

med dokumentation av en

vårdkontakt, en diagnos/observation

och en åtgärd

SpecialistCare Simulerar patientbesök i slutenvård

med inskrivning, utskrivning och

upprepade observationer och

medicinska åtgärder.

PatientDataAccess Simulerar att en patient via

elektronisk åtkomst hämtar all sin

tillgängliga dokumentation.

Tabell 4.1 Förteckning över Thread Groups

19

Vid läsning returnerar REST-tjänsten data i JSON format och vid skrivning

postar klienten JSON till tjänsten. Dynamisk data genereras med JMeters

inbyggda funktion för detta: Random Variable. I Tabell 4.2 Förteckning över

variabler nedan beskrivs vilka variabler som genereras och vad de används till.

Variabelnamn Beskrivning

PatientId Slumpmässigt patientid för att

kunna simulera besök från olika

patienter.

EncounterId Slumpmässigt nytt id för

vårdkontakt.

ObservationId Slumpmässigt nytt id för

observationer utförda på patient.

DiagnosisId Slumpmässigt nytt id för diagnoser

satta på patient.

Tabell 4.2 Förteckning över variabler

20

4.4 Sammanställning av anrop för att läsa och skapa FHIR

resurser

För att läsa och skapa FHIR-resurser, används JMeters HTTP request anrop. I

Tabell 4.3 beskrivs vilka request som är del av testplanen och vilka FHIR-

resurser de interagerar med.

HTTP request FHIR-resurs Beskrivning

NewProcedure Procedure Ny utförd åtgärd för en

patient.

NewEncounter Encounter Ny vårdkontakt.

NewObservation Observation Kliniskt fynd, sjukdom

eller mätvärde.

NewDiagnosis Observation Ny Diagnos. Notera att

samma FHIR resurs

används för både

observationer i allmänhet

och de specifika kodade

diagnoserna.

GetProcedures

Procecedure Läs dokumenterade

kliniska åtgärder.

GetEncounters

Encounter Läs dokumenterade

vårdkontakter.

GetObservations

Observation Läs kliniska fynd,

sjukdomar och

mätvärden.

Tabell 4.3 Förteckning över HTTP requests

21

4.5 Testfall primärvård

I nedanstående sekvensdiagram (se Figur 4.4) beskrivs hur testfallet med en

patient i primärvård är implementerat. När testerna körs kommer varje tråd

inom denna thread group gå igenom nedanstående sekvens uppifrån och ned.

Detta upprepas tills testkörningen avslutats.

Figur 4.4 Testfall primärvård

22

4.6 Testfall specialiserad vård


patient som blir inlagd i specialiserad vård och får en längre behandling är

implementerat. När testerna körs kommer varje tråd gå igenom nedanstående

steg uppifrån och ned. Detta upprepas tills testen avslutas.

Figur 4.5 Testfall specialiserad vård

23

4.7 Testfall läsa patientdata


patient eller vårdgivare som söker journalinformation är implementerat. När

testerna körs kommer varje tråd gå igenom nedanstående steg uppifrån och

ned. Detta upprepas tills testen avslutas.

Figur 4.6 Testfall patientdata

24

4.8 Sammanställning av testresultat

För att kunna ta del av resultatet från en testomgång används Aggregate Graph

funktionen. Den presenterar teststatistik i grafisk form.

Innan mätningarna startade kördes testfallen upprepade gånger mot

lösningen för att säkerställa att testerna inte genomförs mot en tom databas.

Get-tjänsterna för att hämta redan dokumenterat patientdata visar en stigande

latens proportionerligt mot mängden data lagrat i tjänsten. Detta har inte

analyserats närmare men antas bero på att det går relativt snabbt att söka data

för de patientidentiteter som ännu inte har något skapat, och dels för att så länge

det finns relativt lite data kan detta mellanlagras i cacheminne för databasen

och är på så sätt effektivt att söka fram. Desto mer data det finns desto troligare

är det att data måste sökas från disk. Syftet med dessa tester är att simulera en

användning där data sällan finns tillgängligt i cacheminne. Detta beror på att

varje patient som utför ett besök är en ny patient och det finns därför liten nytta

med cache:ad information.

25

5 Resultat De framtagna lasttesterna har körts mot respektive referensimplementation.

För att undersöka den maximala belastningen ökades antalet simulerade

användare/trådar stegvis. Det förväntade beteendet är att när den maximala

lasten uppnås har man uppnått maximal genomströmningshastighet

(transaktioner per sekund) och efter det börjar latensen (fördröjning per anrop)

att öka. (se Tabell 5.1 och Figur 5.1)

5.1 Tester av Furore Sparks

Trådar Transaktioner / s Latens (median) / ms

15 4.2 294

24 5.9 600

30 6.3 1156

45 6.1 3583

60 5.5 6886

75 5.1 8853

Tabell 5.1 Resultat för testkörningar med Furore Sparks FHIR-server med

NoSQL-datalager

Figur 5.1 Testresultat för Furore Sparks FHIR-server med NoSQL datalager

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

0

1

2

3

4

5

6

7

15 24 30 45 60 75

Lat

ens

(ms)

Tra

nsa

kti

on

er/s

ek

Trådar

Furore Sparks

Transaktioner Latens

26

5.2 Tester av Grahame

Trådar Transaktioner / s Latens (median) / ms

15 2.8 150

24 - -

30 - -

45 - -

60 - -

75 - -

Tabell 5.2 Resultat för testkörningar med Grahame FHIR-server med SQL-

datalager

Testerna avbröts efter första testomgången eftersom allvarliga fel upptäcktes i

Grahame FHIR-servern. Med 15 trådar och 2,8 transaktioner per sekund

genererade 12.86% fel i form av en deadlock i databasen och data gick förlorat.

De fel som uppkom med gjorde det omöjligt att få rättvisande

prestandauppgifter. Efter att detta upptäckts gjorde handledaren på MedMod

en kontroll av installationen, databasen och felloggar. För säkerhets skull

gjordes en ominstallation av servern med samma resultat som tidigare. (Se

Tabell 5.2)

[Microsoft][SQL Server Native Client

11.0][SQL Server]Transaction (Process

ID 62) was deadlocked on lock resources

with another process and has been chosen

as the deadlock victim. Rerun the

transaction

27

6 Analys Testmetoden visade sig fungera bra för att upptäcka svagheter i de båda

implementationerna. Under testen av Furore Sparks FHIR-servern hittade

testmetoden den maximala genomströmningshastigheten genom stegvis

ökande av lasten (antal trådar/användare). Värdet 30 trådar gav maximal

genomströmningshastighet med 6,3 transaktioner per sekund och en

medianlatens på 1156ms. Under testerna genererades inga fel från Furore

Sparks.

Under första testomgången av Grahame FHIR-servern genererade

testerna 12,8% serverfel och felloggen visade deadlock-meddelanden från

SQL-databasen. Transaktioner som hamnade i deadlock terminerades av

databasservern inom 10-12 sekunder, men detta försköt median och medeltider

i testerna. Beslut fattades om att det inte var meningsfullt att fortsätta med

högre belastning. Testmetoden gav alltså ett värdefullt resultat i och med att en

allvarlig bug i referensimplementationen kunde identifieras med hjälp av

lasttesterna.

28

7 Diskussion

I detta arbete ställdes tre forskningsfrågor. Den första frågan var vilka

trafikmönster som uppkommer i verkligheten och den andra frågan hur

prestandatester bäst ska utformas för att efterlikna dessa. Under intervjudelen

med handledaren besvarades detta delvis baserat på publicerad statistik och

delvis genom handledarens erfarenhet av arbete med nationella

ehälsolösningar. Det är svårt att avgöra om de val som gjordes är tillräckligt

lika verkliga trafikmönster i alla situationer. Det visade sig också att valet av

tekniskt verktyg för utförande av belastningstester styr de val som behöver

göras i utformningen av tester. Det använda verktyget JMeter kan anropa

HTTP/REST-tjänster för att utföra en mer eller mindre dynamiskt anrop i

förutbestämda sekvenser. I någon mening är dessa tester realistiska i och med

att det definitivt är fullt tänkbara anropsföljder där ett antal uppgifter

dokumenteras kring en patient i en realistisk följd. Testerna speglar också det

faktum att det i princip är en ny patient vid varje besök och inte endast ett fåtal

individer som återkommer i en testsekvens. Det finns delar av testerna som är

mindre realistiska som exempelvis att patientbesök endast kategoriseras i två

huvudklasser, primärvård och specialiserad vård. Handledarens uppfattning

var att detta var en rimlig ansats under framtagandet av dessa tester.

Den tredje frågeställningen angående om en NoSQL lösning skulle

medföra prestandafördelar i denna typ av lösning kunde inte besvaras

tillfredställande på grund av en bug i den relationsdatabasbaserade

referensimplementationen som omöjliggjorde rättvisa prestandatester.

29

8 Sammanfattning Projektet har resulterat i en implementation av tester som visat sig vara

användbara både för att undersöka prestanda i FHIR-implementationer samt

för att upptäcka funktionella problem. Resultatet är användbart för att verifiera

andra FHIR-implementationer samt för att undersöka deras lämplighet för

storskalig användning. Resultatet är framförallt relevant för industri och

samhälle. Detta arbete är en god grund för att lägga till tester som verifierar

mer av FHIR-gränssnittet.

I denna studie skapades en uppsättning tester som kan simulera en

realistisk last motsvarande en nationell användning av FHIR standarden.

Lösningar som testades var Grahame som är byggd i programspråket Delphi

med en Microsoft SQL Server för datalagring och en .NET lösning Furore

Sparks som använder Mongo DB som lösning för datalagring.

Målet var att kunna jämföra dessa två referensimplementationer med

varandra med avseende på prestanda och maximal last. Intresset var både

resultatet av prestandatesten, men också det framtagna automatiserade testerna

för att testa FHIR-implementationer med avseende på deras prestanda i

storskaliga miljöer.

Det går att konstatera att de framtagna testerna är användbara för att hitta

problem och svagheter samt at bedöma hur stor belastning system under hög

last kan hantera. Under testerna med Grahame upptäcktes funktionella fel i

implementationen. Testerna av Furore Spark kunde användas för att hitta

maximal genomströmningshastighet på den givna serverhårdvaran samt vilken

latens anropen uppvisade vid olika belastningar.

Denna studie har framgångsrikt utformat testerna utifrån de teoretiska

resultaten från Jiangs och Hassans undersökning av hur man lasttestar

storskaliga system. I testen har metoden stegvis belastning använts. Testerna

designades med hjälp av UML-modeller över tre olika användarscenarion [7].

Forskningsfrågan gällande trafikmönster som uppkommer i verkligheten

besvarades i en intervju med handledaren som refererade till tidigare studier

och statistik över bland annat vårdproduktion, antal patienter och vårdpersonal.

Hur prestandatester ska utformas besvaras delvis i studien. I testerna har

en del av den verkliga trafiken identifierats och modellerats. Verkligheten

uppvisar sannolikt en mycket större variation än testerna kan spegla.

Den tredje forskningsfrågan angående uppenbara prestandafördelar

mellan SQL och NoSQL implementationer kunde inte besvaras eftersom

testerna mot SQL inte kunde slutföras på grund av en bug i det testade systemet

Grahame.

Jiang och Ahmeds undersökning över aktuellt forskningsläge visade sig vara

mycket användbart under detta arbete [7]. Framförallt i avvägningen mellan att

endast simulera en förväntad belastning jämfört med att utföra lasttester för att

30

studera hur systemet uppförs sig under olika laster samt hur maximal

belastning beräknas.

8.1 Framtida forskning

En idé för framtida forskning som diskuterades under projektets gång var

möjligheten att simulera individer som patienter och vårdpersonals beteende

och interagerande och utifrån denna simulering generera trafik, snarare än att

som idag manuellt omsätta ett tänkt beteende till tekniska anrop i ett

testramverk. Det manuella framtagandet av testplaner är tidskrävande och det

är svårt att skapa variation i testerna.

31

9 Referenser

[1

]

”Export-X Word Wide Access,” December 2015. [Online]. Available:

https://export-x.com/2015/12/11/how-many-products-does-amazon-sell-

2015/. [Använd 25 11 2017].

[2

]

”Statista,” 2015. [Online]. Available:

https://www.statista.com/statistics/237810/number-of-active-amazon-

customer-accounts-worldwide/. [Använd 25 11 2017].

[3

]

R. T. Fielding, Architectural Styles and the Design of Network-based

Software Architectures, UNIVERSITY OF CALIFORNIA, IRVINE:

University of California, 2000.

[4

]

G. Grieve, ”Reference Implementation Server for the FHIR

Specification,” Mars 2017. [Online]. Available:

https://github.com/grahamegrieve/fhirserver. [Använd 26 Mars 2017].

[5

]

”Furore's public domain FHIR server,” [Online]. Available:

https://github.com/furore-fhir/spark. [Använd 20170326 mars 2017].

[6

]

E. J. Weyuker och F. I. Vokolos, ”Experience with Performance Testing

of Software Systems: Issues, an Approach and Case Study,” IEEE

Transactions on sowtware engineering, vol 26, no. 12, pp. 1147-1156,

December 2000.

[7

]

Z. M. Jiang och E. H. Ahmed, ”A Survey on Load Testing Large-Scale

Software Systems. Software Engineering (ICSE),” IEEE Transactions on

software engineering, vol. 41, nr 11, pp. 1091-1114, 2015 November.

[8

]

T. Z. Xin Zhang, ”Achieving scalability in a distributed electronic health

record system Science and Information Conference (SAI),” 2013.

[9

]

C.-Y. Yang och C.-T. Liu, ”Performance assessment and tuning for

exchange of clinical documents cross healthcare enterprises,” Computer

Standards & Interfaces, 28 February 2016.

[1

0]

E. AbuKhousa, N. Mohamad och J. Al-Jaroodi, ”e-Health Cloud:

Opportunities and Challanges,” 2012. [Online]. Available:

www.mpdi.com/journal/futureinternet. [Använd 26 11 2017].

[1

1]

L. J. o. T. Pehrsson, ”Inera,” Maj 2016. [Online]. Available:

http://www.inera.se/Documents/OM_OSS/Styrdokument_o_rapporter/SL

IT-rapporter/eHlsa_i_landstingen_SLIT_2016.pdf. [Använd 03 04 2017].

[1

2]

Datainspektionen, ”Mobila enheter - Checklista för behandling av

personuppgifter,” Maj 2013. [Online]. Available:

http://www.datainspektionen.se/Documents/faktablad-mobila-

enheter.pdf. [Använd 03 April 2017].

32

[1

3]

”Patientdatalag (2008:355),” 29 Maj 2008. [Online]. Available:

http://www.notisum.se/rnp/sls/lag/20080355.htm. [Använd 03 April

2017].

[1

4]

”Vår statistik över patientbesöken är korrekt,” 10 December 2014.

[Online]. Available: http://www.sjukhuslakaren.se/var-statistik-over-

patientbesoken-ar-korrekt/. [Använd 03 April 2017].

[1

5]

”Landstingsanställd personal 2015,” 30 Mars 2017. [Online]. Available:

https://skl.se/ekonomijuridikstatistik/statistik/personalstatistik/personaleni

diagramochsiffror/tabellerlandstingsanstalldpersonal2015.8833.html.

[Använd 03 April 2017].

[1

6]

”Frågor och svar om patientjournaler,” [Online]. Available:

http://www.socialstyrelsen.se/fragorochsvar/patientjournaler#anchor_2.

[Använd 03 April 2017].

[1

7]

Sveriges Kommuner och Landsting, ”Statistik om hälso- och sjukvård

samt regional utveckling 2012,” Oktober 2013. [Online]. Available:

http://webbutik.skl.se/bilder/artiklar/pdf/7164-984-3.pdf. [Använd 02

April 2017].

[1

8]

[Online]. Available: http://jmeter.apache.org/. [Använd 05 2017].

33

Bilaga 1 JSON för FHIR resurser I denna bilaga redovisas exempel JSON kod som använts för att skapa FHIR-

resurser. I koden markeras dynamiska variabler med ett $-prefix följt av

variabelns namn inom {}, exempelvis ${patientid}.

FHIR Encounter {

"resourceType": "Encounter",

"identifier": [{

"value": "${encounterid}"

}],

"status": "finished",

"class": "inpatient",

"type": [{

"text": "Orthopedic Admission"

}],

"patient": {

"reference":

"http://spark.furore.com/fhir/Patient/${patientid}"

},

"period": {

"start": "2013-01-20T12:30:02Z",

"end": "2013-02-01T12:30:02Z"

}

}

34

FHIR Observation

{

"resourceType": "Observation",

"extension": [{

"url":

"http://hl7.org/fhir/StructureDefinition/observatio

n-bodyPosition",

"valueCodeableConcept": {

"coding": [{

"system": "http://snomed.info/sct",

"code": "33586001",

"display": "Sitting position

(finding)"

}]

}

},

{

"url":

"http://hl7.org/fhir/StructureDefinition/observatio

n-delta",

"valueCodeableConcept": {

"coding": [{


"code": "1250004",

"display": "Decreased (qualifier

value)"

}]

}

}],

"status": "final",

"identifier": [{

"value": "${observationid}"

}],

"code": {

"coding": [{

"system": "http://loinc.org/",

"code": "30350-3",

"display": "Hemoglobin [Mass/volume] in

Venous blood"

}]

},

"subject": {

35

"reference":


},

"effectivePeriod": {

"start": "2013-04-02T10:30:10+01:00",

"end": "2013-04-05T10:30:10+01:00"

},

"issued": "2013-04-03T15:30:10+01:00",

"valueQuantity": {

"value": 7.2,

"unit": "g/dl",

"system": "http://unitsofmeasure.org/",

"code": "g/dL"

},

"interpretation": {

"coding": [{

"system": "http://hl7.org/fhir/v2/0078",

"code": "L",

"display": "Below low normal"

}]

},

"bodySite": {

"coding": [{


"code": "308046002",

"display": "Superficial forearm vein"

}]

},

"method": {

"coding": [{


"code": "120220003",

"display": "Injection to forearm"

}]

}

}

36

FHIR Observation (diagnos) {

"resourceType": "Observation",

"status": "final",

"code": {

"coding": [{

"system": "http://hl7.org/fhir/sid/icd-

10 ",

"code": "I21.4",

"display": "Akut subendokardiell

infarkt"

}]

},

"identifier": [{

"value": "${diagnosisid}"

}],

"subject": {

"reference":


},

"effectiveDateTime": "2012-09-17",

"performer": [{

"reference":

"http://spark.furore.com/fhir/Practitioner/example"

}],

}

37

FHIR Procedure

{ "resourceType": "Procedure",

"subject": {

"reference":


},

"status": "completed",

"code": {

"coding": [{


"code": "90105005",

"display": "Biopsy of soft tissue of forearm

(Procedure)"

}],

"text": "Biopsy of suspected melanoma L) arm"

},

"bodySite": [{

"coding": [{


"code": "368225008",

"display": "Entire Left Forearm"

}],

"text": "Left forearm"

}],

"reasonCodeableConcept": {

"text": "Dark lesion l) forearm. getting darker

last 3 months."

},

"performer": [{

"actor": {

"reference":

"http://spark.furore.com/fhir/Practitioner/example",

"display": "Dr Bert Biopser"

}

}],

"performedDateTime": "2014-02-03",

"followUp": [{

"text": "Review in clinic"

}],

"notes": [{

"text": "Standard Biopsy"

}]

}