Kandidatarbete Lasttester av implementationer av FHIR-standarden
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
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
I nedanstående sekvensdiagram (se Figur 4.5) beskrivs hur testfallet med en
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
I nedanstående sekvensdiagram (se Figur 4.6) beskrivs hur testfallet med en
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": [{
"system": "http://snomed.info/sct",
"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":
"http://spark.furore.com/fhir/Patient/${patientid}"
},
"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": [{
"system": "http://snomed.info/sct",
"code": "308046002",
"display": "Superficial forearm vein"
}]
},
"method": {
"coding": [{
"system": "http://snomed.info/sct",
"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":
"http://spark.furore.com/fhir/Patient/${patientid}"
},
"effectiveDateTime": "2012-09-17",
"performer": [{
"reference":
"http://spark.furore.com/fhir/Practitioner/example"
}],
}
37
FHIR Procedure
{ "resourceType": "Procedure",
"subject": {
"reference":
"http://spark.furore.com/fhir/Patient/${patientid}"
},
"status": "completed",
"code": {
"coding": [{
"system": "http://snomed.info/sct",
"code": "90105005",
"display": "Biopsy of soft tissue of forearm
(Procedure)"
}],
"text": "Biopsy of suspected melanoma L) arm"
},
"bodySite": [{
"coding": [{
"system": "http://snomed.info/sct",
"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"
}]
}