FHIR-standardin ominaisuudet ja soveltaminen

Markus Huhta

Pro gradu -tutkielma

Tietojenksittelytieteen laitos

Tietojenksittelytiede

Lokakuu 2016

i

IT-SUOMEN YLIOPISTO, Luonnontieteiden ja metstieteiden tiedekunta, KuopioTietojenksittelytieteen laitosTietojenksittelytiede

Markus Huhta: FHIR-standardin ominaisuudet ja soveltaminenPro gradu -tutkielma, 74 s.Pro gradu -tutkielman ohjaaja: FT Juha MykknenLokakuu 2016

Terveydenhuollon tietojrjestelmiss yhteentoimivuus on aina ollut trke, eik senmerkitys ole vhenemn pin. Yhteentoimivuus voidaan saavuttaa kyttmll yh-teentoimivuusstandardeja, joista HL7:n standardiperhe on yksi trkeimmist. Tutki-musmenetelmn sovellettiin kirjallisuuskatsausta ja systemaattista arviointia raken-teista arviointimallia hyvksi kytten.

HL7 versio 2 ja 3 standardit ovat kytetyimmt ko. standardiperheen standardeja ja nesaavat lhivuosina jatkoa FHIR-standardin muodossa. FHIR-standardin on tarkoitusvastata haasteeseen terveydenhuollon standardien nykyaikaistamisesta. Tutkielma va-lottaa FHIR-standardin kehityksen nykytilaa ja tarkastelee sen soveltuvuutta kytn-nn esimerkin muodossa. Tutkielman tarkoitus on vastata seuraaviin tutkimuskysy-myksiin:

1. Antaa yleiskuva FHIR-standardista ja sen suhteista aiempiin keskeisiin tervey-denhuollon tietojrjestelmien standardeihin.

2. Kuvata FHIR-standardin keskeiset ominaisuudet, kehitysvaiheineen, sek ar-vioida FHIR-standardin soveltuvuutta terveydenhuollon standardina ja lopuksisoveltaa standardia esimerkin voimin.

Tutkielman aiheen FHIR-standardi on vasta kehitysasteella oleva standardi, joten re-levantin ja laajasti aihetta ksittelevn aineiston lytminen oli haaste. Suurin osa ai-neistosta on kuitenkin alaa ksittelevst kirjallisuudesta ja FHIR-kehittjien verkko-sivuilta. Kirjallisuuskatsaus ei ole systemaattinen, vaan sit on sovellettu palvelemaantutkielman tarkoitusta.

Tutkielma osoittaa FHIR-standardin olevan nykyaikainen standardi, jossa on valmis-tuessaan potentiaalia tuotantokyttn. Tutkielma vastaa tutkimuskysymyksiin yleis-kuvan antamisen lisksi kuvaamalla ko. standardin keskeisimmt ominaisuudet ja ke-hitysvaiheet. Standardin kytt tutkitaan kytnnn esimerkin kautta.

Avainsanat: Yhteentoimivuus, standardit, potilastietojrjestelmt, FHIR

ACM-luokat (ACM Computing Classification System, 1998 version): Standards,Interoperability, Medical information systems, Software development

i

UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, KuopioSchool of ComputingComputer Science

Markus Huhta: Features and application of FHIR-standardMasters Thesis, 74 p.Supervisor of the Masters Thesis: PhD Juha MykknenOctober 2016

Interoperability has always been an important aspect of healthcare information sys-tems. High level of interoperability can be achieved through the use of interoperabilitystandards, of which the HL7 family of standards is among the most important. Litera-ture review and systematic evaluation of structured review models were the primaryresearch methods in this work.

The most widely utilized standards among the HL7 family are versions 2 and 3, andthey are expected to be succeeded by the FHIR standard. There is a need for modern-ization within the industry of standards, and thus the (contemporary) focus of this the-sis is to explore the current development state of the FHIR standard, as well as examineits feasibility by means of a case study. This thesis also aims to answer the followingresearch questions:

1. Provide an overall description of the FHIR standard and its relationships withrespect to previous, dominant healthcare information system standards.

2. Describe the central properties and development phases of the FHIR standard,as well as evaluate its viability as a healthcare IT standard, and finally applythe standard through a case study.

The FHIR standard, which forms the focus of this thesis, is still in its developmentalphase. This made the search for broad and relevant literature challenging. However,the majority of the referenced works come from literature related to the field of thestudy, as well as the FHIR developers websites. The literature review is not strictlysystematic; rather it was applied to serve the purposes of this thesis.This thesis demonstrates that FHIR is a contemporary standard that carries potentialfor production use once it reaches its mature release state. In addition to providing anoverview and answering the research questions, this thesis also delineates the stand-ards central features and development phases. Finally, the standards utility is exem-plified through a practical case study example.

Keywords: Interoperability, standards, electronic health records, FHIR

CR Categories (ACM Computing Classification System, 1998 version): Standards,Interoperability, Medical information systems, Software development

ii

Esipuhe

Tm tutkielma on tehty It-Suomen yliopiston Tietojenksittelytieteen laitoksellesyksyll 2016. Haluan kiitt seuraavia ihmisi tmn tutkielman tuesta. Juha Myk-kst, jonka asiantuntemus on vailla vertaansa ja joka aktiivisesti tuki tutkielman kir-joittamista. Toista graduni tarkastajaa ja viimeisten kirjoitusvirheiden lytj AnneEerolaa. Vaimoani, joka tuki ja arvosti tekemni tyt. Sek poikaani, joka syntyitutkielman loppumetreill. Kavereitani, joiden vertaistuki ja aktiivisuus olivat ilmi-mist. Ilman teit tm tutkielma olisi varmasti valmistunut aikaisemmin. Typaik-kani tukea ja erityisesti Petteri, joka toimii osaltaan mentorin roolissa ja oli vaikutta-massa aiheen valintaan. Lisksi kiitn muuta perhettni ja heit, jotka unohdin mainita.

iii

LyhenneluetteloASTM American Society for Testing and MaterialsCDA Clinical Document ArchitectureDICOM Digital Imaging and Communications in MedicineDMIM Domain Message Information ModelDSTU Draft Standard For Trial UseEHR Electronic Health RecordEHR-S Electronic Health Record -SystemFHIR Fast Healthcare Interoperability ResourcesHIMSS Healthcare Information and Management Systems SocietyHIS Hospital Information SystemHL7 Health Level 7HMD Hierarchical Message DescriptionHTML Hyper-Text Markup LanguageHTTP Hypertext Transfer ProtocolHTTPS Hypertext Transfer Protocol SecureIEEE Institute of Electrical and Electronics EngineersIHE Integrating the Healthcare EnterpriseITS Implementation technology specificationISO International Organization for StandardizationJSON JavaScript Object NotationJPEG Joint Photographic Experts GroupMIME Multipurpose Internet Mail ExtensionNEMA National Electrical Manufactures AssociationPACS Picture Archiving and Communication SystemPDF Portable Document FilePHR-S Personal Health Record SystemPMI Project Management InstituteREST Representational State TransferRIM Reference Information ModelRIS Radiology Information SystemRMIM Refined Message Information ModelRSNA Radiological Society of North AmericaSOA Service Oriented ArchitectureSR Structured ReportingURI Uniform Resource IndicatorURL Uniform Resource LocatorWADO Web Access to DICOM Persistent ObjectsXML Extensible Markup Language

iv

Sisllysluettelo

1 Johdanto .................................................................................................. 12 Menetelmt ja viitemallit ......................................................................... 3

2.1 Kirjallisuuskatsauksen ja konstruktiivisen tyn menetelmt ............. 32.2 Yhteentoimivuusstandardin arviointimalli ........................................ 62.3 Ksitteist ........................................................................................ 9

2.3.1 Standardi ........................................................................ 102.3.2 Yhteentoimivuus ............................................................ 102.3.3 Shkiset potilastietojrjestelmt .................................... 112.3.4 Terveydenhuollon tietojrjestelmt ................................. 122.3.5 EHR ............................................................................... 122.3.6 PHR ............................................................................... 132.3.7 Muut keskeiset ksitteet .................................................. 13

3 Terveydenhuollon sovellusten yhteentoimivuusstandardit ja REST ........ 173.1 Yhteentoimivuuden ja standardien merkitys terveydenhuollossa .... 173.2 HL7-standardit ............................................................................... 18

3.2.1 HL7 v2 sanomastandardit ............................................... 183.2.2 HL7 v3 standardiperhe ................................................... 193.2.3 CDA ............................................................................... 20

3.3 DICOM ......................................................................................... 213.4 IHE ja IHE-profiilit ........................................................................ 223.5 REST ............................................................................................. 24

4 FHIR-standardi ...................................................................................... 26

4.1 FHIR-yleiskuva.............................................................................. 264.2 FHIR:n kehittyminen ..................................................................... 264.3 Resurssiajattelu FHIR-standardissa ................................................ 27

4.3.1 Resurssin vaatimukset .................................................... 284.3.2 Resurssin sislt (elementit) ........................................... 284.3.3 FHIR-Profiilit ................................................................. 30

4.4 Koodistojen kytt ......................................................................... 314.5 Tietotyypit ..................................................................................... 324.6 FHIR-Toteutustavat ....................................................................... 344.7 REST-interaktioiden tyypit FHIR-standardissa............................... 354.8 FHIR-standardin rakenteinen yhteenveto........................................ 36

5 Millainen on FHIR-standardia hydyntv rajapintamrittely............... 40

5.1 Ajanvarauksen perusarkkitehtuuri esimerkiss ............................... 405.2 Kytttapauksen kuvaus ................................................................. 415.3 Tarvittavat tietosisllt ja tynkulut ............................................... 425.4 Tarvittavat interaktiot ..................................................................... 445.5 Tarvittavat resurssit (FHIR) ........................................................... 46

5.5.1 1/4 Appointment-resurssi ................................................ 475.5.2 2/4 Schedule-resurssi ...................................................... 50

v

5.5.3 3/4 Slot-resurssi .............................................................. 515.5.4 4/4 Encounter-resurssi .................................................... 54

6 Pohdinta ................................................................................................ 59

7 Yhteenveto ............................................................................................ 61Viitteet .......................................................................................................... 62

1

1 JOHDANTO

Terveydenhuollon tietojrjestelmiss standardien kyttminen luo pohjan potilastieto-

tietojrjestelmien yhteentoimivuudelle. Standardeja hyvksi kytten eri toimijoiden

jrjestelmt kykenevt keskustelemaan keskenn, mink lisksi ne tuovat moninaisia

hytyj niin teknisest kuin taloudellisestakin nkkulmasta. Lisksi standardit mm.

yhdenmukaistavat tuotantoprosesseja, sek parantavat eri mittarien luotettavuutta ja

oikeudenmukaisuutta. (Mykknen et al., 2008) Yhteentoimivuuden ja standardien

merkityst ksitelln tarkemmin luvussa 3.1.

Vaikka standardeja on kytetty eri tietojrjestelmiss vuosikymmenien ajan, ovat ne

siit huolimatta silyttneet ajankohtaisuuden niit tarkastaltaessa. Tutkielman ai-

heena olevan FHIR-standardi on luonteva valinta tutkittavaksi aiheeksi, johtuen sen

sen tuoreesta nkkulmasta ja edeltjiens laajasta kytst. Tulevaisuudessa FHIR-

standardilla on mahdollisuus korvata vanhat HL7 v2 ja v3 -standardit. Tutkielma tar-

kasteleekin osaltaan, onko FHIR (Fast Healthcare Interoperability Resources) -stan-

dardissa potentiaalia vastaamaan haasteeseen.

Tm tutkielma tarkastelee yhteentoimivuusstandardeja keskittyen HL7-organisaation

kehitteill olevaan FHIR-standardiin, jonka lisksi sivutaan mys vanhempia HL7

standardeja. Tutkielman loppupuolella selvitetn FHIR-standardin soveltuvuutta

ajanvarausjrjestelmn yhteentoimivuusstandardina. Onko uusimmasta FHIR-stan-

dardista korvaamaan vanhoja jo vakiintuneita standardeja?

Tutkielman tarkoitus ja selvitettvi asioita ovat:

1. Antaa yleiskuva FHIR-standardista ja sen suhteista aiempiin keskeisiin terveyden-

huollon tietojrjestelmien standardeihin.

2. Lisksi tarkoitus on kuvata FHIR-standardin keskeiset ominaisuudet ja kehitysvai-

heet. Sek arvioida FHIR-standardin soveltuvuutta terveydenhuollon standardina ja

lopuksi soveltaa standardia esimerkin voimin.

2

Tutkielman aihe on melko uusi ja kirjoitetun kirjallisuuden mr rajallinen, joten osa

aiheen aineistosta otettiin mm. koulutusmateriaaleista ja FHIR-standardin kotisivuilta

lytyvst dokumentaatiosta. Rajallinen lhdekirjallisuus korostui nimenomaan

FHIR-standardia ksittelevn materiaalin suhteen. Tutkielman alustusluvun ksittele-

mist asioista lytyi runsaammin mys kirjoitettua ja julkaistua materiaali (esimerkiksi

artikkelit vanhemmista standardiversioista).

Tutkielma koostuu alun johdannon jlkeen tulevista luvuista, joista toisessa luvussa

selvitetn tutkielmassa kytettyj menetelmi ja viitemalleja. Lisksi luvussa esitel-

ln trkeimpien ksitteiden lisksi tutkielmassa kytettyj tutkimusmenetelmi.

Kolmannessa luvussa kerrataan yhteentoimivuuden ja standardien merkityst tervey-

denhuollossa. Lisksi esitelln REST ja miten se liittyy terveydenhuollon yhteentoi-

vuusstandardeihin.

Neljnness luvussa keskitytn FHIR-standardiin aloittaen sen taustasta ja nykyisest

kehitysvaiheesta. Luku kuvaa standardin keskeisi ominaisuuksia, kuten resurssien ja

koodistojen kytt. Sanastot ja toteutustavat huomioidaan mys. Lopuksi suoritetaan

FHIR-standardin rakenteinen yhteenveto.

Viidenness luvussa paneudutaan FHIR:i hydyntviin rajapintamrittelyihin. Ta-

pauksessa ko. standardi valjastetaan kytnnn tasolla ajanvarauspalvelujen rajapinto-

jen mrittelyyn rajapintojen toteutusta varten. Luvussa tarkastellaan esimerkin kautta,

tarjoaako FHIR tarvittavat komponentit ajanvarausjrjestelmn toteuttamiseen.

Kuudennessa luvussa on pohdinta ja viimeisess seitsemnness luvussa on yhteen-

veto.

3

2 Menetelmt ja viitemallit

Luvun tavoitteena on kuvata tutkielmassa kytettvi menetelmi ja viitemalleja. Me-

netelmn kytetn kirjallisuuskatsausta sek systemaattista arviointia rakenteista ar-

viointimallia hyvksi kytten. Niden pohjalta luodaan luvussa 4.8 konstruktiivinen

esimerkki standardin soveltamisesta. Menetelmien ja viitemallien konteksti on tervey-

denhuollon tietojrjestelmiss ja yhteentoimivuuden merkityksess erityisesti standar-

dien nkkulmasta.

Tutkielmassa on kytetty kirjallisuuskatsausta relevantin tutkimustiedon etsimiseen ja

sopivan tutkimusmetodin lytmiseen. Kirjallisuuskatsaus ei ole systemaattinen, vaan

sit on sovellettu palvelemaan tutkielman tarkoitusta.

2.1 Kirjallisuuskatsauksen ja konstruktiivisen tyn menetelmt

Kirjallisuuskatsaus on tsmllinen ja toistettavissa oleva metodi identifioimaan, kehit-

tmn ja syntetisoimaan muiden tutkijoiden, tiedemiesten ja ammatinharjoittajien kir-

jallisia tit. Kirjallisuuskatsaus voidaan toteuttaa joko systemaattisena tai ei-syste-

maattisena. Katsauksessa pyritn kyttmn alkuperisi lhteit, jotta tiedonlaatu

silyy hyvn ja relevanttina. (Fink, 2009)

Kirjallisuuskatsaus koostuu Arlene Finkin mukaan (Fink, 2009) seitsemst eri vai-

heesta:

1. Tutkimuskysymysten valinta.

2. Aineiston hakeminen tietokannoista, internetist ja muista sopivista lhteist.

3. Valitaan hakutermit ja luodaan hakulauseet.

4. Valitaan valintakriteerit, joiden mukaan tuloksia rajataan.

5. Valitaan metodi, jonka mukaan aineistoa kydn lvitse.

6. Tehdn itse kirjallisuuskatsaus.

7. Syntetisoidaan tulokset. (Fink, 2009)

4

Tutkielmassa ei ole laajaa systemaattista kirjallisuuskatsausta, jossa olisi mritelty

hakustrategiat yms. Sen sijaan tutkielmassa mukaillaan ja sovelletaan Arlene Finkin

esittmn kirjallisuuskatsauksen rakenteen seitsem vaihetta. Kyseinen teos valittiin

tarkastelun pohjaksi, koska sit on kytetty laajasti ja se soveltuu tss tehtvn tut-

kimukseen. Tutkielma aloitettiin valitsemalla aihe ja sille sopivat tutkimuskysymyk-

set, joita vasten aihetta lhdettiin tarkastelemaan eri tietolhteit hyvksikytten.

Aineistohakuja tein niin kirjallisuutta etsivist tietokantapalveluista kuin julkisista ha-

kukoneistakin (Google, Google scholar). Vastaavasti kirjoittamisen tukena on ollut

esimerkiksi FHIR-koulutusmateriaalit ja kontekstiin liittyvien tutkimusten lhdeluet-

telot. Tutkielmaa tukevaa sislt lytyi runsaasti mys terveydenhuollon tietohallin-

non kirjallisuudesta (health informatics) ja HL7-standardeista kertovasta kirjallisuu-

desta.

Lukua kaksi varten jouduin tekemn melko runsaasti hakuja laajasta ksitteistst

johtuen. Monet ksitteist ja mritelmist tydentyivt tutkielman edetess. Muuta-

mien ksitteiden osalta aineistoa etsin suoraan Google scholarista ja Nelli-hakupalve-

lusta. Ksitteit etsin kytten ksitteen englanninkielist nime tai lyhennett.

Toisessa luvussa ksiteltiin tietojrjestelmien yhteentoimivuutta ja HL7-standardeja.

Aihealueesta lytyi runsaasti kirjallisuutta, joten jouduin tarkentamaan hakulauseita

seuraavin termein: hl7, framework, health informatics ja interoperability. T-

mn luvun kontribuutio koostuu kytettvien ksitteiden ymmrtmisest, sek tarvit-

taessa niiden yhteensovittamisesta tai vaihtoehtoisista mritelmist sopivimman va-

litsemista.

Lukua kolme varten lytyi runsaasti painettua kirjallisuutta ja artikkeleita. Kytetty

materiaalia etsittiin pasiassa Google scholaria kytten. Hakusanoina kytettiin lu-

vun kolme otsikoiden englanninkielisi vastineita. Luku koostuu melko selkeist ali-

lukujen muodostamista kokonaisuuksista, joten lhdeaineiston etsiminen oli siten suo-

raviivaista. Kolmannessa luvussa tarkasteltiin yhteentoimivuutta ja siihen liittyvien

5

standardien kirjallisuutta. Luvun kontribuutio koostuu terveydenhuollon eri standar-

dien vlisest ymmrryksest ja kyvyst hahmottaa eri standardien oikean kytttar-

koituksen oikeassa vaiheessa.

Luku nelj keskittyy FHIR-standardin ksittelemiseen. Tmn osion aineiston etsimi-

nen oli haastavaa. FHIR on standardina melko tuore ja viittauksia siihen lytyi suh-

teellisen vhn. Painetusta kirjallisuudesta onnistuin lytmn lyhyen selonteon stan-

dardista, mutta muutoin jouduin turvautumaan muutamaan Nellist ja Google schola-

rista lydettyyn artikkeliin. FHIR-standardiin liittyvien julkaisujen ollessa melko v-

hisi, riitti monesti hakusanaksi pelkk FHIR.

Suurin osa kytetyst aineistosta lytyi FHIR-standardin internetsivuilta, jossa oli mm.

teknisi mrityksi runsaasti. Lisksi kytin google-hakukoneella ja Slidesharesta

lydetty koulutusmateriaalia hyvkseni. Yhdeksi trkeksi aineistoksi osoittautui Su-

hosen, Mykksen, Miettisen ja Virkasen Fast Health Interoperability Resources

FHIR- standardin kuvaus ja arviointi -dokumentti (Suhonen et al., 2013), joka loi poh-

jan tekemlleni tutkielmalle.

Luvussa oma kontribuutio kohdistuu FHIR-standardin rakenteisen yhteenvedon li-

sksi (luku 4.9) FHIR-standardin yleiskuvan ymmrtmisest ja kyvyst soveltaa sen

eri ominaisuuksia mrittelytasolta sovellustasoon asti.

Viides luku keskittyi pitklti FHIR-standardin tekniseen toteutukseen. Luvussa ei en

nojauduta niinkn teoriapohjaiseen tietoon, vaan kytetn hyvksi FHIR-standardin

teknist lhdemateriaalia. Tt FHIR-projektisivuilta lytynytt teknist mrittely

sisltv materiaalia kytettiin aineistona FHIR:i hydyntvn esimerkin mritte-

lyss. Merkittv osa lhdeaineistosta lytyi FHIR-standardin projektisivuilta.

Aineiston valintakriteereiksi valitsin FHIR:iin liittyvss aineistossa englannin- ja

suomenkielisen aineiston, joka sai olla maksimissaan viisi vuotta vanhaa materiaalia.

Muissa luvuissa pyrin tuoreen aineiston kyttn, mutta jos vanha aineisto ei ollut ris-

tiriidassa uudemman aineiston kanssa, hyvksyin molempien aineistojen kytn. Ky-

tetyist koulutusmateriaaleista suurin osa oli englanninkielist standardien kehittjien

6

tuottamaa materiaalia. Suomenkielist koulutusmateriaalia kytin pasiassa englan-

ninkielisen materiaalin tukena.

Luvuissa 5.1 ja 5.2 tarkastellaan oman kontribuution tuloksena syntynytt ajanva-

rausesimerkki, joka on luotu konstruktiivisesti etsimll sopivat standardista sovel-

lettavat osat. Samoin sanomia, resursseja ja tiedonvlitysratkaisuja ksittelevt alalu-

vut sisltvt omaa kontribuutiota ko. asioiden ymmrtmisen ja soveltamisen osalta.

2.2 Yhteentoimivuusstandardin arviointimalli

Tutkielma mukailee Mykksen ja Tuomaisen viitemallia, joka jaetaan yhdeksn eri

osaan. Ensimminen kohta ksittelee standardin perustietoja sen hydyntmist ajatel-

len. Kohdat 2-5 kuvaavat vastaavasti standardin yksityiskohtaisempia tietoja niin tie-

don soveltamisen, semantiikan, toiminnallisuuden ja vuorovaikutuksien, sovelluksen

infrastruktuurisista kuin teknisist nkkulmista. Kohtia 6 ja 7 kytetn enemmn

standardin mukautuvuuden, tarkkuuden ja kypsyyden arviointiin. Kohdassa kahdek-

san ksitelln standardin toiminnallisuutta sovelluksissa ja jrjestelmiss. Yhdekss

kohta ottaa kantaa terveydenhuollon toimialuekohtaisiin ominaisuuksiin. (Mykknen

et al., 2008)

Yleisesti viitekehyksen avulla tarkastellaan standardia monista yhteentoimivuuden n-

kkulmista. Sen pasiallinen kytttarkoitus on luoda tiivistelm standardin tavoitel-

lusta lopputuloksesta, sovellettavuudesta, laadusta ja analyysi standardin kytettvyy-

dest. Lopullinen ja tarkka standardin arviointimenettely perustuu tavallisesti projek-

tin vaatimuksiin, standardin mrittelyyn ja sit tukevaan materiaaliin. (Mykknen et

al., 2008)

Viitekehyksen kytt voidaan nhd laadullisena kokeiluna, jonka perusteella voidaan

analysoida haluttuja ominaisuuksia. Vastaavasti viitekehyst kytetn yhteenvetojen

tekemiseen pmrn, tavoitteen ja sovellettavuuden perusteella. Lisksi huomioi-

daan yhteentoimivuuden nkkulmat yksityiskohtaisemmassa analysoinnissa. Sen

7

ptarkoitus on ohjata projektissa kytettvien standardien kyttmiseen siten, ett so-

velluksen integraation myt saavutettaisiin komponentin parempi yhteentoimivuus.

(Mykknen et al., 2008)

Seuraavassa luettelossa esitelln viitekehyksen eri tarkastelualueet:

1. Perustiedot ja kohdealue (Scope). Kuvataan sanallisesti standardin tarkoitus,

kohdealue ja kytttarkoitus halutussa ympristss. Lisksi standardia on

mahdollista arvioida suhteessa eri nkkulmiin: (Mykknen et al., 2008)

a. enterprise

b. information

c. computation

d. engineering

e. technology. (Mykknen et al., 2008; Mykknen et al., 2004)

2. Tieto ja semantiikka (Information and semantics). Kuvataan tiedonsiirron ele-

mentit, parametrit ja muut tiedonsiirrossa kytettvt komponentit. Standar-

dissa voidaan mritell tietosisltihin liittyvi seikkoja neljll eri tavalla:

a. Standardissa mritetn sallitut arvot esimerkiksi tiettyyn tietokent-

tn tai elementtiin (koodistot, luokitukset).

b. Standardi kuvailee parametrin tai elementin nimen tyyppeineen tai ele-

menteist ja parametreista koostuvia tieto-, sanoma- tai dokumenttira-

kenteita.

c. Standardi yksili eri objektien semanttisia yhteyksi.

d. Standardi sislt metatason kuvauksen kytten erilaisia konkreettisia

rajapintoja. (Mykknen et al., 2008; Mykknen et al., 2004)

3. Toiminnot ja sovellusten vuorovaikutus (Functionality and interactions). Stan-

dardi kuvaa prosessit ja tynkulut tarkemmalla tasolla. Tarkastellaan standar-

din mrittelem toiminnallisuutta, kyttytymist ja organisoitumista. Toi-

minnallisuudet jaetaan neljn osaan:

a. Operaatioiden ja aktiviteettien toiminallisuudet.

b. Kyttytyminen, eli aktiviteetin aikataulut, sekvenssit yms.

c. Organisaatio, miss ja kenen toimesta aktiviteetit suoritetaan.

8

d. Tieto, kuvataan aktiviteetin rakenne ja sen vaikutukset tietojenksitte-

lyyn. (Mykknen et al., 2008; Mykknen et al., 2004)

4. Sovellusarkkitehtuuri (Application infrastructure aspects). Kuvataan standar-

din arkkitehtuuria hajauttamisen nkkulmasta ja kuinka standardin mukaan

ratkaisujen eri komponentit liittyvt toisiinsa. Yksinkertaisimmillaan arkkiteh-

tuuri kuvailee kuinka tieto liikkuu kahden ohjelman, palvelun tai kyttjn v-

lill. Hajautettua arkkitehtuuria kyttviss jrjestelmiss edell mainitut toi-

minnot voivat toimia useiden eri tietokantojen ja palvelinkomponenttien lisksi

erillisiss kyttliittymiss. (Mykknen et al., 2008; Mykknen et al., 2004)

5. Tekninen nkkulma (Technical aspects). Kuvataan standardin tekninen nk-

kulma tarpeeksi tarkalla tasolla. Tllin otetaan huomioon esimerkiksi kytet-

tviss olevat teknologiat ja erilaiset tekniset ympristt. Tekninen puoli ko-

rostuu erityisesti, kun integraatioratkaisuissa kytetn alustariippumattomia

rajapinta- ja tiedonsiirtotekniikoita. (Mykknen et al., 2008; Mykknen et al.,

2004)

6. Laajennettavuus (Flexibility, accuracy, extensibility). Kuvataan standardin

kyky mukautua erilaisiin kytttarkoituksiin ja kyttympristihin. Standar-

dille on tyypillist yksiselitteisyys ja tarkkuus. (Mykknen et al., 2008; Myk-

knen et al., 2004)

7. Levinneisyys (Maturity, usage, official status). Standardit voidaan luokitella

niiden hyvksymisasteen perusteella viralliseksi tai teolliseksi standardiksi.

Standardi voi olla suunnattu niin kansainvlisille (esimerkiksi ISO) markki-

noille kuin alueellisillekin (esimerkiksi ANSI). Standardin kehityksess on

usein mukana mys kansainvlinen yleis. Standardin kypsyys ja kytt voi-

daan jakaa neljn pvaiheeseen:

a. Aloitus, jolloin standardia kehitetn, mutta se on epvakaa ja hauras.

b. Edistynyt, jolloin ensimmiset testaukset ja esittelyt on tehty.

c. Nopea edistys, jolloin standardi on saanut julkisuutta kasvavin mrin.

Standardin ymprille on tllin ilmestynyt julkaisuja ja yleis.

d. Valmistuminen, jolloin enemmist on mukana kehityksess. Yhteen-

toimivuus on kasvanut vakaan version myt. (Mykknen et al., 2008;

Mykknen et al., 2004)

9

8. Jrjestelmn elinkaari (System lifecycle). Elinkaari kertoo kuinka standardin

on otettava huomioon jrjestelmn elinkaaren eri vaiheissa.

a. Vaatimusmrittely. Esimerkiksi lainsdnnn vaikutus standardiin.

b. Toimialueen analysointi. Tarkastellaan kohdejrjestelm.

c. Mrittelyt. Otetaan kantaa tekniseen mrittelyyn, kyttliittymt,

teknologiat, arkkitehtuuri jne.

d. Kyttnoton valmistelu. Varmistetaan kohdejrjestelmn sopivuus

jne.

e. Kyttnotto ja esittely. Asennetaan jrjestelm eri ympristihin.

f. Yllpito ja versiointi. Jrjestelmn hallinta, migraatio ja konfigurointi-

jrjestelmt. (Mykknen et al., 2008; Mykknen et al., 2004)

9. Toimialuekohtaiset ominaisuudet (Domain-specific features). Terveydenhuol-

lon konteksti luo standardille omat erityispiirteet. Huomioon otettava asia on

esimerkiksi se, mink tyyppisiin terveydenhuollon tietojrjestelmiin standardi

vaikuttaa tai se on tarkoitettu:

a. kommunikointi ja asiakasjrjestelmt (konsultaation ja itsehoito)

b. hallinnointijrjestelmt (kuva-arkistointi, materiaalin tilaus)

c. suorat hoitojrjestelmt (lkelistaukset)

d. diagnostiikkajrjestelmt (kliininen ptksen tuki).

(Mykknen et al., 2008; Mykknen et al., 2004)

Tutkielman aluksi kydn terveydenhuollon standardeja lpi yleisesti kartoittaen sa-

malla terveydenhuollon kentt jrjestelmkehittjn nkkulmasta. Tutkielma paneu-

tuu luvusta nelj lhtien FHIR-standardiin, jonka jlkeen pstn rajapintamritte-

lyyn luvussa viisi. Viitemallia sovelletaan tarkemmin luvussa 4.8, jossa esitelln

FHIR-standardin rakenteinen yhteenveto. (Mykknen et al., 2008)

2.3 Ksitteist

Tss tutkielmassa on ksitelty seuraavia ksitteit.

10

2.3.1 Standardi

Project Management Institute (PMI) mrittelee standardin asiakirjaksi, joka on va-

kiintunut ja tunnustettu. Se tarjoaa yleiseen ja toistuvaan kyttn soveltuvia sntj,

ohjeita, ominaisuuksia, toimintoja ja tuloksia. Standardia kyttmll on tavoitteena

saavuttaa optimaalisin jrjestys halutussa kontekstissa. Standardi on kehitetty proses-

sissa, joka perustuu yhteiseen ksitykseen, avoimuuteen ja tasapainoon. (PMI, 2014)

Hyvksytyll standardilla on runko, joka sislt snnt, ohjeet tai ominaisuudet yh-

denmukaista ja toistuvaa kytt varten eri tuotteissa, prosesseissa ja palveluissa.

Luonnollisesti eri prosessit ja tuotteet kyttvt erilaisia, kyttn sopivia standardeja.

(PMI, 2000)

Terveydenhuollon standardit ovat keskittyneet monimutkaisen terveystiedon vlitt-

miseen turvallisesti ja tehokkaasti eri jrjestelmien vlill. Nm standardit mahdol-

listavat mys potilastietojrjestelmien laajemman kytn siten, ett sama tieto on ky-

tettviss niin ammattilaisen jrjestelmss, kuin potilaan itsehoitopalvelussa. (Kalra,

2006)

2.3.2 Yhteentoimivuus

IEEE mrittelee yhteentoimivuuden kyvyksi siirt ja kytt tietoa kahden tai use-

amman jrjestelmn tai komponentin vlill. Mritelmss korostuu tiedonvaihto (to

exchange) ja siirretyn tiedon kytt (to use). (Fridsma, 2013; IEEE, 1990) Toisaalta

yhteentoimivuus voidaan mritell tuotteen kykyn toimia yhdess muiden jrjestel-

mien ja tuotteiden kanssa ilman asiakkaan erityist ponnistelua. Standardien kyttn-

ottaminen on mahdollistanut yhteentoimivuuden, joka voidaan jakaa kolmeen eri n-

kkulmaan: (IEEE, 2014) (Benson, 2012)

1. Tekninen yhteentoimivuus (technical interoperability) tai perustava yhteentoi-

mivuus (foundational), jossa tavoitteena on saada tieto liikkumaan eri jrjes-

telmien vlill ilman tarvetta datan kuvaamiselle (Benson, 2012; HIMMS,

2013). Thn yhteyteen sopii mys rakenteellinen yhteentoimivuus (structu-

11

ral), jolloin yhteentoimivuutta tarkastellaan tiedonvaihdon rakenteen ja muo-

don pohjalta. Siirrettvn tiedon tytyy olla muutettuna siirrettvn muotoon.

(HIMMS, 2013)

2. Semanttinen yhteentoimivuus (semantic interoperability) tarkoittaa merkityk-

sien yhtenevisyytt. Tm mahdollistaa dokumenttien ja sanomien siirtmi-

sen jrjestelmien vlill, sek tietojen kyttmisen. Tll varmistetaan lhett-

vn ja vastaanottavan jrjestelmn yhtenisyys, jotta tiedon merkitys pysyy

siirrettess samana. Semanttinen yhteentoimivuus on yleens riippuvainen

toimialueesta ja kontekstista. (Benson, 2012; HIMMS, 2013) Semanttinen yh-

teentoimivuus voi parantaa jrjestelmien laatua, turvallisuus- ja kustannuste-

hokkuutta, jotka ovat nykyaikaisen terveydenhuollon tietojrjestelmn vaati-

muksia. (En, 2015; HIMMS, 2013)

3. Prosessien yhteentoimivuus (process interoperability) on saavutettu, kun ihmi-

sill on yhteinen ksitys liiketoiminnasta, toimintaympristst ja toimintapro-

sesseista (Benson, 2012).

2.3.3 Shkiset potilastietojrjestelmt

Potilastietojrjestelmien shkistminen on ollut pitk tie. Paperille kirjaamisesta on

onnistuttu siirtymn tietokonepohjaisiin jrjestelmiin, jotka tarjoavat huomattavia

etuja verrattuna paperille kirjaamiseen. Tietokoneella kytettvt jrjestelmt sislt-

vt lisksi monipuolisia ominaisuuksia tiedon kermisest tiedon varastointiin.

(Coiera, 2015)

Shkisten potilastietojrjestelmien tavoitteena on laskea terveydehuollon kuluja, eh-

kist hoitovirheit sek parantaa hoidon laatua ja saatavuutta. Lisksi niiden etuja

ovat mm. nopea tiedonhaku jrjestelmist halutuilla kriteereill, sek muut teknolo-

gian tuomat edut niin digitaalisessa sisllntuottamisessa kuin suurilla kosketusny-

till tyskennellesskin. (Coiera, 2015; Nelson et al., 2009)

12

2.3.4 Terveydenhuollon tietojrjestelmt

Mit ovat terveydenhuollon tietojrjestelmt? Mriteltess terveydenhuollon tieto-

jrjestelmi, lydetn helposti erilaisia tietojrjestelmien luokitteluja. Pekka Turunen

ja Aapo Immonen luokittelevat tietojrjestelmi Terveydenhuollon tietojrjestelmien

luokittelu arviointia varten -artikkelissa seuraavasti: (Turunen et al., 2004)

a) Asiakkaiden oman terveytens yllpitoa tukevat jrjestelmt.

b) Vuorovaikutusta tukevat jrjestelmt. Esimerkiksi shkinen ajanvaraus ja po-

tilaskontaktin suorittaminen tietokoneen vlityksell.

c) Konsultaatiojrjestelmt. Potilaan ja hoitohenkilkunnan vuorovaikutusta tu-

kevat tykalut.

d) Ptksentekoa tukevat jrjestelmt. Ptksen tueksi tietoa tuottavat jrjestel-

mt.

e) Prosessia tukevat jrjestelmt. Terveydenhuollon operatiivisia toiminnanoh-

jausjrjestelmi.

f) Talouteen liittyvt jrjestelmt. Rahavirtaan liittyvt jrjestelmt.

g) Valmisteluun liittyvt jrjestelmt. Potilaan operoinnin valmisteluun liittyvt

tykalut. Esimerkiksi ennen leikkausta suoritettavat tarkistuslistat.

h) Hallinnon tykalut. Esimerkiksi terveydenhuollon pttji tukevat ja tilastoja

kokoavat jrjestelmt. (Turunen et al., 2004)

2.3.5 EHR

EHR (Electronic health record) eli shkinen potilaskertomus on keskeinen tykalu

osana potilaan hoitoa. Sen avulla potilasta hoitavat ammattilaiset kommunikoivat kes-

kenn ja jakavat tietoja potilaasta ja hnelle tehdyist tutkimuksista ja toimenpiteist.

(Coiera, 2015)

Shkinen potilaskertomus on suojattu ja turvallinen sovellus (kts. kuva 1), jonka

avulla kyttj voi tarkastella, muokata ja jakaa potilaan terveystietoja. Lisksi se on

palveluntuottajan vastuulla oleva tuote, johon potilaalla ei yleens juurikaan ole oi-

keuksia. (Nelson et al., 2009)

13

Kuva 1: Shkinen potilaskertomus on monipuolinen tykalu. (Coiera, 2015)

2.3.6 PHR

PHR:ss (Personal Health Record) eli henkilkohtainen terveyskansio tukee shkist

potilaskertomusta tarjoten potilaalle mahdollisuuden list jrjestelmn itsen kos-

kevia tietoja. Terveyskansio voi sislt potilaan itse kirjoittamia muistiinpanoja, ko-

kemuksia ja arkipivisi tietoja. Kansioon voidaan list mys varsinaisia hoitoa tu-

kevia tietoja, kuten tieto rokotuksista, allergioista ja mittaustuloksista. (Coiera, 2015)

2.3.7 Muut keskeiset ksitteet

Tss aliluvussa kerrotaan muiden keskeisten ksitteiden merkitys.

14

2.3.7.1 Tietomallit

Tietomallien (information model) tarkoitus on kuvata kytettvi tietojoukkoja ja m-

ritell niiden sisltj ja rakennetta. Tietomallin avulla voidaan taata ptsten perus-

tuvan oikeelliseen tietoon. (Coiera, 2015)

2.3.7.2 Sovellusarkkitehtuuri

Sovellusarkkitehtuuri (application architecture) on arkkitehtuurinen nkkulma, jonka

pohjalta tehdn sovelluksen arkkitehtuuria koskevat ptkset, ohjeet ja tarvittavat

standardit, joita tarvitaan toimivaan komponenttipohjaisen jrjestelmn luomiseen.

Arkkitehtuurissa voidaan ottaa huomioon esimerkiksi tarve jrjestelmn skaalautuvuu-

delle ja siten otetaan jo varhaisessa vaiheessa virtualisointi mukaan sovellusarkkiteh-

tuurissa. (Herzum et al., 1999)

2.3.7.3 Rajapinta

Rajapintojen kytt on komponettipohjaisissa jrjestelmiss kytettvyyden kannalta

avainasemassa. Rajapinta toimii kahden eri komponentin tai komponentin ja loppu-

kyttjn vliss mahdollistaen tiedon liikkumisen molempiin suuntiin niden vlill.

Komponentit ovat uudelleenkytettvi ja monesti ne muodostavat monimutkaisen ko-

konaisuuden. (Mykknen, 2007)

Rajapinta sislt mm. seuraavia kytttarkoituksia:

Rajapinta voidaan jakaa useaan eri komponentin kanssa.

Rajapinta mahdollistaa komponentin kyttmisen, kunhan komponentti on

kyttjn saavutettavissa.

Rajapinta mahdollistaa yhteentoimivuuden tarjoamalla sen toiminnallisuuden

ja tiedot, jotta komponentin kyttminen onnistuu.

Rajapinnan kyttminen mahdollistaa ohjelmiston hajautetun kyttmisen.

(Mykknen, 2007)

Koska yksi EHR-standardi ei voi tarjota terveydenhuollon jrjestelmlle kaikkia sen

tarvitsemia toimintoja, tarvitaan rajapintoja standardien vlill. Rajapinta mahdollistaa

15

kommunikoinnin kahden, tarvittaessa hyvin erilaisen tietojrjestelmn vlill. Tervey-

denhuollossa tm tarkoittaa esimerkiksi potilastiedon siirtymist ajanvaraus- ja las-

kutusjrjestelmien vlill. (Nelson et al., 2009)

2.3.7.4 Sanomarajapinnat

Jrjestelmien vliset sanomat liikkuvat sanomarajapintaa kytten eri jrjestelmien v-

lill. Sanomarajapintojen kytt mahdollistaa suurten moninaisten tietojoukkojen siir-

tmisen eri jrjestelmien vlill. HL7 v2 -standardeihin pohjautuvat sanomarajapinnat

ovat maailman eniten kytettyj rajapintoja sanomien vlittmiseen terveydenhuollon

jrjestelmiss. (Dogac et al., 2007)

2.3.7.5 Palvelurajapinnat

Palvelurajapinnat varmistavat eri komponenttien integroitumisen osaksi jrjestelm.

Tllaisia komponentteja ovat esimerkiksi terminologiaan ja oikeuksien hallintaan liit-

tyvt komponentit. (HL7, 2004)

2.3.7.6 Profiilit

Profiilit rajoittavat standardien kytt tarkasti mritellyn tarpeen mukaan kyttkoh-

teessa tai kytttapauksessa. Nin standardi saadaan profiilia kyttmll tarjoamaan

halutut toiminnollisuudet kohdesovelluksessa. Tm mahdollistaa plug and play -

tyyppisen kytn yhteentoimivuusstandardeissa. Esimerkiksi WS-I on tllainen tekni-

nen profiili, joka mahdollistaa teknisesti rajapintojen kytn. (Mykknen, 2007)

2.3.7.7 Koodistot ja luokitukset

Luokittelun tarkoitus on jakaa asioita eri ryhmiin ja luokkiin sisltjen perusteella.

Koodistojen tarkoitus on yksilid sisltj koodaamalla ne ihmisen ymmrtmss

muodossa, jolloin sit voidaan kytt helpommin tiedon siirtmiseen tietojrjestel-

miss. (Benson, 2012)

16

2.3.7.8 Terminologiat

Terveydenhuollon yhteisell terminologialla kyetn selittmn monimutkaiset ja

kontekstiriippuvaiset asiat, vhenten vrinymmrryksen mahdollisuutta. Kun esi-

merkiksi henkil A ja henkil B keskustelevat potilaasta, on hyvin trke, ett mo-

lemmat ymmrtvt toisiaan. (Hovenga et al., 2010)

17

3 Terveydenhuollon sovellusten yhteentoimivuusstan-

dardit ja REST

Tmn luvun tavoitteena on perustella yhteentoimivuuden merkitys terveydenhuollon

tietojrjestelmiss. Luvun toisena pmrn on esitell keskeisimpi terveydenhuol-

lon tietojrjestelmien yhteentoimivuusstandardeja.

3.1 Yhteentoimivuuden ja standardien merkitys terveydenhuollossa

Potilastietojrjestelmien yhteentoimivuus tuo organisaatiolle tehokkuutta ja taloudel-

lisuutta yllpitokustannuksien ja ihmistyvoiman vhenemisen myt. Kytnnss

yhteentoimivuuden parantuminen nkyy esimerkiksi parempana potilaiden tiedon ha-

kuna, niin kliinisess kuin hallinnollisessa tyss. Vastaavasti potilastiedon automaat-

tinen siirto eri jrjestelmien vlill nopeuttaa tiedon siirtymist ehkisten mahdollisten

virhetilanteiden syntymist. (Eichelberg et al., 2013)

Yhteentoimivuusvaatimukset ovat yleens trkeimpi vaatimuksia terveydenhuollon

jrjestelmien vaatimusmrittelyiss. Ammattilaiset ovat lisksi havainneet jrjestel-

mien yhteentoimivuuden parantaneen potilasturvallisuutta, johtuen tuoreimmasta ja

parhaasta saatavilla olevasta potilastiedosta (Bender et al., 2013). Terveydenhuollon

standardit ovat yksi osatekij parantamaan terveydenhuollon jrjestelmien kytett-

vyytt. Standardeja kyttmll voidaan edist turvallista ja laadukasta hoitoa. (Ben-

son, 2012)

Potilastietojrjestelmt on laajalti digitalisoitu. Nykyisin potilaat liikkuvat paikkakun-

nalta toiselle ja kyvt julkisen terveydenhuollon lisksi mys yksityisiss hoitopai-

koissa. Tm on luonut tarpeen shkiselle potilastietojrjestelmlle. Potilastiedon

saatavuuden merkitys korostuu potilaan kytettess eri toimipaikkoja. Lisksi poti-

lastiedon tytyy olla prosessoitavissa koneellisesti ja jrjestelmn tytyy tukea niin

lkrin ja hoitajan ptksentekoa, kuin potilaan itsehoitoakin. Potilastiedon tulee

olla rakenteistettu ja standardisoitu. (Quinn, 2014b)

18

Standardien kytn kautta pyritn vhentmn riskej ja kustannuksia, parantamaan

prosessien laatua, sek lyhentmn projektien toteutusaikoja. (Bender et al., 2013;

Coiera, 2015)

3.2 HL7-standardit

HL7 on riippumaton ja voittoa tavoittelematon jrjest, joka perustettiin Yhdysval-

loissa 1987. Jrjestn tavoitteena on edist tiedon kermist, siirtmist ja integroi-

mista eri tietojrjestelmien vlill. (Coiera, 2015; Eichelberg et al., 2013; Nelson et al.,

2009) HL7 tarjoaa monipuolisen viitekehyksen ja standardiperheen terveydenhuollon

tietojrjestelmien yhteensopivuutta ajatellen. HL7-standardien kytt globaaleissa

terveydenhuollon jrjestelmiss on merkittv. (Coiera, 2015; Nelson et al., 2009)

Monista kehitetyist standardeista shkisten dokumenttien ja viestinvlityksen stan-

dardit ovat kytetyimpi kliinisiss sovelluksissa. Kyseiset standardit kuvaavat kliinis-

ten dokumenttien rakenteen ja niiden vliset semanttiset suhteet. Standardeista esi-

merkiksi HL7 CDA kehitettiin dokumenttien, kuvien ja erilaisten raporttien siirtmi-

seen eri jrjestelmien vlill. (Coiera, 2015)

Uudet tuloillaan olevat HL7 -standardit kehitetn ensin kokeilustandardina (DSTU),

joissa niit testataan ja jatkokehitetn. Vasta tmn jlkeen standardit voidaan hyvk-

sy lopullisiksi standardeiksi. (Benson, 2012; HL7, 2015b)

Terveydenhuollon tietojrjestelmiss yleisimmin kytettvt HL7 -standardit ovat

HL7 v2, HL7 v3 standardiperhe ja dokumenttistandardi CDA. Huomion arvoista on,

ett HL7 julkaisee mys muunkin tyyppisi standardeja. Nit ovat esimerkiksi poti-

laskertomusjrjestelmiss kytettv HL7 EHR-S FM ja henkilkohtaisissa terveys-

kansiojrjestelmiss kytettv PHR-S FM. (HL7, 2015k; HL7, 2015j)

3.2.1 HL7 v2 sanomastandardit

HL7 v2 on yksi suosituimmista terveydenhuollon tietojrjestelmiss potilastiedon v-

litykseen kytettv yhteentoimivuusstandardi (Eichelberg et al., 2013). Esimerkiksi

19

Yhdysvalloissa valtaosa sairaaloista kytt HL7 v2 -standardiin pohjautuvia potilas-

tietojrjestelmi. (Benson, 2012)

HL7 versio 2 standardeja on kehitetty yli 25 vuotta vuodesta 1988 lhtien. Standardi

on kehittynyt valtavasti tuona aikana tuoden paljon uusia ominaisuuksia. Sen etuihin

kuuluu monipuolisuuden ja joustavuuden ohella yhteensopivuus niin eteen- kuin taak-

sepin (Benson, 2012). HL7 version 2 standardeja on Suomessa kytetty laajasti esi-

merkiksi terveyskeskusten ja sairaaloiden sisll jrjestelmien vlisiss integraati-

oissa. (Paakkanen, 2007)

HL7 versio 2 ei ole kuitenkaan tydellinen standardi. Se ei kata tydellisesti kaikkia

kytttilanteita eik se tuo tydellist yhteentoimivuutta potilastietojrjestelmien v-

lille. Sen taustalla ei ole tarpeeksi tarkasti mritelty tietomallia, ja sen monien kent-

tien mritelmt ovat epmrisi. Tmn vuoksi standardi on joustava, mutta yhtei-

set kytnnt on sovittava tietoa vlitettvien jrjestelmien kesken, jotta toimiva ko-

konaisuus saataisiin aikaiseksi. Tmn ongelman ratkaisemiseksi julkaistiin HL7 ver-

sio 3. (Benson, 2012; Eichelberg et al., 2013)

HL7 versio 2 standardeihin kuuluu mys suuri joukko koodistoja ja luokituksia, joita

sanomapohjaisessa tiedonvlityksess kytetn. Ne ovat omalta osaltaan merkitt-

vss roolissa jrjestelmn kytettvyytt parantaessa. (Benson, 2012)

3.2.2 HL7 v3 standardiperhe

HL7 versio 3:sen kehitys alkoi jo vuonna 1992, mutta se julkaistiin vasta 2004. Kol-

mannen version pohjalla toimii oliopohjainen RIM-tietomalli, jonka tarkoitus oli kat-

tavuutensa ja toimivuutensa puolesta korjata toisen version ongelmakohdat. (Benson,

2012; Eichelberg et al., 2013)

RIM:lle on tyypillist tiukka ja muodollinen tietosislln mallinnus, joka jtti hyvin

vhn sijaa valinnaiselle ja eprakenteiselle tiedolle. Mallin tavoite oli tarjota stan-

dardi, joka olisi vakaa, testattavissa oleva ja tarjoaisi mahdollisuuden mys toimivuu-

den sertifioinnille. (Benson, 2012)

20

HL7 v3 luotiin korvaamaan v2, mutta sen kyttnotto ja kytt on koettu vaikeaksi

eri projekteissa. HL7 v3 ei ole onnistunut syrjyttmn v2:sta, joten vanhempi stan-

dardi jatkoi terveydenhuollon tietojrjestelmien trkeimpn yhteentoimivuusstandar-

dina. (Benson, 2012)

HL7 v3 toi mukanaan rajoitetut tietomallit, joita voitiin luoda RIM-mallin pohjalta

rajatuin ominaisuuksin mys tarkempiin kohdealueisiin. Nin sopivia ja rajattuja mal-

leja voitiin luoda erilaisia kytttapauksia varten. Malleilla pystyttiin takaamaan stan-

dardin oikeaoppinen kytt yhteentoimivuuden takaamiseksi. Tllaisia malleja ovat

DMIM, RMIM ja HMD.

DMIM (Domain Message Information Model) on yleinen rajatun soveltamisalueen

malli, josta voidaan johtaa sanomien tekniset vaatimukset. RMIM (Refined Message

Information Model) on sanomien rakennetta kuvaava malli. HMD (Hierarchical Mes-

sage Description) on taulukkomuotoinen vastinen RMIM-mallille, mutta graafista

RMIM:i on helpompi kytt ja ymmrt. (Benson, 2012)

HL7 versio 3 standardi toimii viestinvlitystasolla yleens sanomapohjaisesti XML-

skeemaa hyvksikytten. Mainitsemisen arvoisia teknologioita on XML:ss kytet-

tv Implementation technology specification (ITS), joka kuvailee kuinka yksittinen

RMIM- tai HMD-mallin mukainen viesti muodostetaan XML-skeeman mukaiseen

muotoon. Lisksi HL7 versioon 3 kuuluu mys suuri joukko koodistoja ja luokituksia,

joita sanomien tarkentamisessa ja toteuttamisessa kytetn. (Benson, 2012)

2000-luvulla HL7 v3:sen jlkeen esiteltiin uusi, monipuolisempi ja kettermpi HL7

FHIR -standardi, jonka oli tarkoitus vastata nykyajan tarpeisiin (Bender et al., 2013;

Benson, 2012). Tmn tutkielman myhemmt luvut keskittyvt FHIR-standardiin.

3.2.3 CDA

HL7 CDA on XML-pohjainen standardi, jota kytetn potilasdokumenttien semant-

tiseen ja rakenteiseen mrittelyyn. CDA:n on maailman laajimmin kytetty HL7

v3:sen sovellus potilasdokumenttien vlitykseen. Sen tarkoitus on kuvailla esimerkiksi

potilaskertomuksen rakennetta tiivistelm- ja muistiinpano-osioineen mahdollistaen

21

tiedon liikuttamisen jrjestelmien vlill. Siirrettv tieto voi mys koostua esimer-

kiksi tekstist ja kuvista. (Benson, 2012; Eichelberg et al., 2013)

CDA-standardin mukaiselle dokumentille on ominaista:

Pysyvyys (persistence), jolloin dokumentilla on selke elinkaari; luotu, ky-

tss ja tuhottu. Dokumentin sislt on pysyv, kunnes se ptetn tuhota.

Yllpidettvyys (stewardship), jolloin dokumentti on aina jonkin henkiln tai

organisaation vastuulla, joka huolehtii dokumentin arkistoinnista, kopioin-

nista, edelleen lhettmisest ja lopulta tuhoamisesta.

Kokonaisuus (wholeness), jossa dokumentti on tydellinen sislten metatie-

dot dokumentin luojasta, kytttarkoituksesta ja ajankohdasta.

Luettavuus (human readable), jolloin ihminen pystyy lukemaan ja ymmrt-

mn dokumentin siit huolimatta, ett dokumentti olisi tietokoneen ymmrt-

mss muodossa (XML).

Tunnistautuminen (Potential for authentication), jolloin dokumentit voidaan

allekirjoittaa fyysisesti tai shkisesti. (Benson, 2012)

HL7 CDA ei ole kaikenkattava EHR-standardi, koska se kuvailee vain osan EHR-ark-

kitehtuurista. Vaikka sen varaan ei voida rakentaa kokonaista jrjestelmn, on se kui-

tenkin trke osa EHR: ja on yhteentoimiva vastaavien rakenteiden EN 13606 ja

openEHR kanssa. (Eichelberg et al., 2013)

3.3 DICOM

DICOM-standardia kytetn lketieteellisten kuvien tallentamiseen ja siirtmiseen.

Siit on tullut lketieteellisen kuvantamisen tiedonsiirrossa ainoa tosiasiallinen stan-

dardi. Standardi kuvailee tietorakenteet ja palvelut toimittajariippumattomia kuvasiir-

toja varten. DICOM-standardi ja sen edeltj aloitettiin kehittmn vuodesta 1983.

Nykyisess muodossaan se ollut kytss vuodest 1993 ja nykyisin sen kehityksest

vastaa NEMA (National Electrical Manufactures Association). CDA:n ja DICOM:n

rakenteiset raportointimallit ovat konseptiltaan hyvin samanlaiset. (Eichelberg et al.,

2013)

22

DICOM:n standardi koostuu varsinaisesta standardista ja sit tukevasta mallista. Web

Access to DICOM Persistent Objects (WADO) -standardista ja DICOM Structured

Reporting -mallista. WADO:n kehittivt yhdess DICOM ja ISO -jrjestt. Standar-

dilla kuvataan verkkopalvelua, jolla voidaan hakea DICOM-objekteja kuten kuvia ja

raportteja http:n ja https:n yli suoraan palvelimelta. Kytnnss web-palvelin ja asia-

kasohjelmisto kyttvt yksilllisi tunnuksia turvallisen lhettmisen takaamiseksi.

Pelkn kuvan lisksi voidaan palvelimelle lhett mukana mys muita tietoja tai vas-

taavasti taata kuvan tietosuoja lhettmll se tarvittaessa ilman siihen liitetty suoraa

potilastietoa. (Eichelberg et al., 2013)

DICOM:in lisosa, Structured Reporting (SR) on rakenteistettu malli, jonka perus-

teella lkrinlausunnot muokataan varsinaiselle DICOM-standardille sopivaksi.

Standardi julkaistiin vuonna 2000 varsinaisen DICOM-standardin komponentiksi,

joka kattaa lkrinlausunnot ja muun kliinisen tiedon. Malli on hyvin mukautuva pys-

tyessn ksittelemn niin vapaamuotoista teksti, kuin mys tysin rakenneistettua

tietoa koodistoineen ja sanastoineen. Pelkst mallista ei luultavasti tule virallista

EHR-standardia koskaan, johtuen sen rajatuista kyttmahdollisuuksista. Kuitenkin

osana varsinaista DICOM WADO -standardia se toimii erinomaisesti. DICOM:ia ei

juurikaan kytet kuvantamisen ulkopuolella, mutta yhdess SR-mallin kanssa siit on

tullut hyvin merkittv kuvantamisessa kytettv standardi kaupallisia sovelluksia

myten. (Eichelberg et al., 2013)

3.4 IHE ja IHE-profiilit

Integrating the Healthcare Enterprise (IHE) on voittoa tavoittelematon jrjest, joka

perustettiin Radiological Society of North American (RSNA) ja Healthcare Infor-

mation and Management Systems Society (HIMSS) toimesta vuonna 1998. IHE:n ke-

hityst varten on perustettu kansallisia tyryhmi Euroopassa ja Japanissa. IHE:n ta-

voitteena on edist terveydenhuollon tietoresurssien integraatiota. (Eichelberg et al.,

2013; Oosterwijk, 2006; Suhonen et al., 2013)

23

IHE ei jrjestn itse kehit yhtn standardia vaan se valikoi ja suosittelee sopivia

standardeja tiettyihin kytttapauksiin. IHE pyrkii kehittmn sovellusprofiileja stan-

dardeista, jotka mahdollistavat yksinkertaisen jrjestelmintegroinnin. Teknisen tyn

tulokset julkaistaan valmiina toteuttavissa olevina paketteina, jotka julkaistaan IHE

Technical Framework -julkaisuissa vuosittain. (Eichelberg et al., 2013; Suhonen et al.,

2013) IHE tekee lheist yhteistyt mys HL7-organisaation kanssa. (Kalra, 2006;

Oosterwijk, 2006)

IHE:n kohdalla on merkitsev sen saama vahva tuki teollisuudelta, koska yli 160 yri-

tyst on osallistunut sen kehitykseen ja testaukseen vuosien 1999 ja 2005 vlill. Eri-

tyisesti RIS:i (Radiology Information System), PACS:ia (Picture Archiving And

Communication System) kyttvt tahot ovat tukeneet EHI:n kehityst. Samoin monet

potilastietojrjestelm tuottajat ovat tt kehityst tukeneet. (Eichelberg et al., 2013;

Oosterwijk, 2006; Suhonen et al., 2013)

IHE-standardi on tekninen viitekehys, joka sislt kokoelman mrityksi kyttn-

otosta. yhteentoimivuudesta ja integraatio-ongelmista. (Oosterwijk, 2006) IHE-profii-

lit eivt itsessn ole standardeja, vaan profiilin tarkoituksena on kertoa kuinka eri

standardeja kytetn yhdess. Eli profiililla voidaan sitoa useita palasia monesta eri

standardista. Profiilia kytten konfliktit eri asetuksia sisltvien standardien vlill

saadaan estetty. (IHE, 2016a; Oosterwijk, 2006)

IHE kytt IT Infrastructure Technical Framework:ia (ITI TF) kuvaamaan standar-

dien tarkempaa integraatiota teknisell tasolla, jotta tiedon vlitys jrjestelmien vlill

olisi sujuvaa. Technical Framework:n kuvaamia terveydenhuollon sovelluksia kutsu-

taan aktoreiksi (actors). IHE-profiileja lytyy monia ja niist keskeisimpi ovat esi-

merkiksi: (IHE, 2016b; Oosterwijk, 2006)

Ajatettu tynkulku (scheduled workflow), jonka tavoitteena on eri toimialui-

den yhteentoiminnan takaaminen.

Potilastiedon sovittamisessa (Patient Information Reconciliation) eri teknolo-

giat (esimerkiksi RIS ja PACS) standardit saadaan sovitettua yhteen.

24

Johdonmukaisesti esitettvt kuvat (Consistent Presentation of Images) mah-

dollistavat kuvien monipuolisen kytn eri toimialueissa.

Profiili, jolla mahdollistetaan psy radiologiseen tietoon.

Profiili, jolla parannetaan potilastiedon turvallista ksittely. (IHE, 2016b;

Oosterwijk, 2006)

IHE-profiileja testataan erityisiss connectathon-tapahtumissa, joissa eri toimijat ym-

pri maailman testaavat IHE:n integrointiprofiileja heidn jrjestelmissn vuosittain.

(Oosterwijk, 2006)

3.5 REST

REpresentational State Transfer (REST) on kevyt ja yksinkertainen arkkitehtuuri web-

sovelluksille (Vitali et al., 2014). REST on arkkitehtuuri, joka mrittelee rajoitukset

niin yhtenisen kyttliittymn, suorituskyvyn, skaalautuvaisuuden kuin muunnelta-

vuudenkin puolesta. REST:ll pyritn tuottamaan mahdollisimman hyvin toimivia

web-sovelluksia. REST:lle on ominaista, ett sen arkkitehtuurista tyyli, dataa ja toi-

mintoja pidetn resursseina, joita kytetn URI:n (Uniform Resource Identifier)

kautta. Kytnnss URI toimii normaalin linkin tavoin web-sivulla. REST kytt

tyypillisesti tietoliikenneprotokollana HTTP:t ja se on suunniteltu client/server -ark-

kitehtuuriksi, jossa resurssit siirtyvt standardisoitujen rajapintojen ja protokollien

kautta. Restful taasen tarkoittaa REST:n vaatimukset tyttv palvelua. (Oracle,

2015)

Jotta web-sovellukset saataisiin toimimaan yksinkertaisesti, kevyesti ja nopeaksi, ty-

tyy sen toteuttaa seuraavat periaatteet:

Resurssien tunnistus URI:n kautta. RESTful -palvelu sislt joukon resurs-

seja, joiden perusteella tapahtuu asiakkaiden vlisen vuorovaikutuksen tunnis-

tus. Resurssit tunnistetaan URI:n perusteella.

25

Yhteninen kyttliittym. Resursseja ohjataan kytten PUT, GET, POST ja

DELETE -komentoja. PUT luo uuden resurssin, joka voidaan poistaa komen-

nolla DELETE. GET hakee resurssin nykytilan. Komennolla POST resurssille

asetetaan uusi tila.

Itsen kuvailevat viestit. Resurssit on irrotettu kuvauksesta, jotta niiden sisl-

tn voidaan kytt useammassa formaatissa. Nit ovat esimerkiksi HTML,

XML, PDF, JPEG ja pelkk teksti. Resurssin metatietoja kytetn mm. vli-

muistin hallitsemiseen, siirtovirheiden lytmiseen ja oikean esitysformaatin

lytmiseen. Samalla tapaa voidaan hoitaa mys kyttjn tunnistus ja kulun-

valvonta.

Tilalliset vuorovaikutukset hyperlinkkien kautta. Jokainen vuorovaikutus re-

sursseissa on tilaton, jolloin viestipyynnt ovat muista riippumattomia. Tiloja

voidaan vaihtaa URI:n uudelleenkirjoittamisella, evsteill ja piilotetuilla lo-

makkeen kentill. Tila voidaan upottaa osaksi vastausviesti osoittaakseen tu-

levat vuorovaikutukset. (Oracle, 2015)

26

4 FHIR-STANDARDI

Tmn luvun tarkoituksena on esitell FHIR-standardin perusteet ja sen REST-pohjai-

nen toteutustapaa. Aluksi kydn lvitse FHIR-standardin yleiskuva, jonka jlkeen

esitelln REST:n toiminnallisuus. Lopulta syvennytn FHIR:n historiaan, taustoi-

hin, toteuttamiseen ja toimintaan.

4.1 FHIR-yleiskuva

FHIR (lausutaan fire) eli Fast Health Interoperable Resources on HL7-organisaation

uusin ja kehityksess oleva standardikehys. Sille on tyypillist vahva ontologia ja tie-

don hierarkkisuus, joka saavutetaan sen ksitteet alikategorisoimalla. (Bender et al.,

2013)

FHIR on julkaissut manifestin, jossa luetellaan FHIR:n kehityksess kytettvt peri-

aatteet:

painopiste on kehittjiss

tavoitteena yhteisten skenaarioiden tukeminen

pyrkimys kytt ristiin eri alojen web-teknologioita

yhteentoimivuuden pohjalla luettavuus

sislt vapaasti saatavissa

tuki usealle toimintatavalle ja arkkitehtuurille

kytt hyvksi havaittuja hallintotapoja. (Quinn, 2014c)

4.2 FHIR:n kehittyminen

HL7 on ollut kehittmss terveydenhuollon tiedonvaihtostandardeja yli 20 vuotta.

Nyt HL7 v2, v3, RIM ja CDA:n pohjalta on lhdetty kehittmn HL7 -organisaation

uusinta FHIR-standardia, joka pyrkii korjaamaan aikaisempien versioiden heikot koh-

dat ja tarjoamaan nykyaikaista standardia. FHIR:i voidaan tulevaisuudessa kytt

27

joko jrjestelmn ainoana tiedonsiirtostandardina tai se voidaan ottaa jo ennestn

kytss olevan standardin rinnalle. (Coiera, 2015; Quinn, 2014b)

FHIR:n pmrn on yksinkertaistaa jrjestelmi integraation trkeys silmll pi-

ten. Se hydynt jo olemassa olevia loogisia ja teoreettisia malleja tarjotakseen joh-

donmukaisen, helpon toteutustavan ja luotettavan mekanismin potilastietojrjestel-

mien tiedonvaihdolle. FHIR:ss on sisnrakennettuna toiminnot HL7 RIM:lle ja

muille trkeille sisltmalleille, jolloin se mukautuu erinomaisesti aikaisempiin mal-

leihin, eik kokemusta siten vaadita esimerkiksi RIM:st tai HL7 v3:sta. (Coiera, 2015;

Quinn, 2014b)

FHIR:n kehitys on laitettu alulle heinkuussa 2011. Ensimminen luonnos nestys-

kierrokselle saatiin aikaiseksi alkusyksyst 2012. Heti pern jrjestettiin ensimmi-

nen Connectathon-tapahtuma, jossa kehittjt psivt kytnnss tutustumaan stan-

dardiin ja testaamaan sit. Vuoden 2013 syksyll jrjestettiin ensimminen nestys-

kierros eli DSTU (Draft Standard For Trial Use). (Quinn, 2014a)

4.3 Resurssiajattelu FHIR-standardissa

FHIR:ss kaikki siirrettv tietosislt on kuvattu resurssiksi. Jokainen resurssi sisl-

t yleisen mrittelyn tietotyyppeineen. Resurssi on tiedon instanssi, joka on talletettu

tai siirretty. Kytnnss resurssi koostuu metatiedot sisltvst ja ihmisen luetta-

vissa olevasta xml-muotoisesta dokumentista. (HL7, 2015a; Quinn, 2014b)

Resursseja voivat olla esimerkiksi hallinnoitava potilas, lkri, organisaatio, sijainti

tai lasku. Esimerkiksi ohjelmistoympristn liittyvi resursseja ovat taasen dokumen-

tit, viestit ja profiilit. Resurssiajattelun ulkopuolelle jvt liian yksityiskohtaiset ja

laajat kokonaisuudet, kuten sukupuoli, potilastietojrjestelmt ja yksittiset arvot.

(Quinn, 2014c)

28

4.3.1 Resurssin vaatimukset

FHIR:ll on erilaisia resursseja tiedon vaihtamiseen ja tallentamiseen niin kliinisess

kuin hallinnollisessa kyttympristss. Standardin resurssit koostuvat useammasta

kokonaisuudesta:

Sill on tiedossa oleva identiteetti (url), johon se voidaan kohdistaa.

Ohjeenmukainen mrittely tiettyn resurssityyppin.

Sislt resurssityypin kuvaamat rakenteistetut tieto-osat.

Sislt selkokielisen XHTML-muotoisen kuvauksen resurssin sisllst.

Sislt yksilillyn versioinnin, joka muuttuu sislln muuttuessa.

Resurssi on validi, jos silt lytyy edell mainitut snnt ja se on mritelty vaati-

muksissa XML- tai JSON -sntjen mukaan. Resursseja voidaan mritt mys mui-

den kuin edell mainittujen kriteerien perusteella. (HL7, 2015a)

4.3.2 Resurssin sislt (elementit)

FHIR:n resurssien elementit koostuvat seuraavista pakollisista ja valinnaisista elemen-

teist ja ominaisuuksista: (HL7, 2015a; McKenzie, 2013)

Kuvaus tietyn tyyppisest elementist. (HL7, 2015a)

Resurssit on mritelty kytten XML:n rakennetta (HL7, 2015a; McKenzie,

2013).

Laajennukset, voivat sislt valinnaista listietoa laajennuksesta. (HL7,

2015a)

Ihmiselle lukukelpoinen selostus resurssin sisllst. (HL7, 2015a)

Sisllytetyt resurssit, lisresursseja, jotka muodostavat tunnisteen ja resurssin

tilan. (HL7, 2015a)

Metadata kuvaa trke tietoa resurssista, joka ei kuitenkaan ole osa resurssin

sisltmallia. (HL7, 2015a; McKenzie, 2013)

29

Tunnisteita kytetn resurssien yhteydess. Ne mrittelevt valinnaisten toi-

mintojen kyttmist, kuten turvallisuutta, tynkulkua jne. (HL7, 2015a;

McKenzie, 2013)

Elementin nimi, tyyppi, kardinaliteetti ja mritelm. (McKenzie, 2013)

Resurssin perusrakenne koostuu kolmesta osasta. Extension-> Narrative -> De-

fined Structured Data. Perusrakenteen voi havaita kuvasta 2. (Quinn, 2014c)

Kuva 2: Perusrakenne potilas-resurssin muodostumiselle (McKenzie, 2013).

30

Edell olevassa kuvassa on resurssi eroteltu kolmeen eri osaan vrin perusteella. Ylim-

pien extension-tagien sisn on merkattu laajennuksessa mritetty viite. Punasvyt-

teisten text-tagien vliss on ihmisen luettavissa oleva tiivistelm ja alimpana on var-

sinainen resurssin sislt. Tss esimerkiss MRN, Name, Gender, Date of Birth ja

Provider -kohdat sisltvt tallennettavaa tietoa. (McKenzie, 2013) Edell mainitut

elementit tulisi olla esiteltyn esitetyss jrjestyksess (HL7, 2015a).

4.3.3 FHIR-Profiilit

FHIR:n yhden tai useamman resurssin rajoitusten ja laajennuksien mrittely kutsu-

taan profiloinniksi (kts. kuva 3). Sen avulla voidaan mritell uusia hakutermej, sa-

nomia jne. (HL7, 2015d; McKenzie, 2013)

Profiileissa on kolme eri osaa:

Metatiedot, jotka kuvaavat profiilia ja tukevat hakutoimintoja.

Rakenteet, jotka mrittelevt ja kuvaavat kuinka resursseja ja tietotyyppej

kytetn.

Laajennusmritykset, jotka kuvaavat millaisia laajennuksia rakenteissa voi-

daan kytt. (HL7, 2015d)

31

Kuva 3: Esimerkki FHIR:n profiilista (McKenzie, 2013).

4.4 Koodistojen kytt

Monet FHIR:n resurssit kyttvt koodistoja, jotka voidaan jakaa yhteen yksinkertai-

seen ja kahteen monimutkaiseen datatyyppiin. Yksinkertaisissa koodistoissa (code)

elementit sidotaan koodit sisltvn arvojoukkoon, tai johonkin muuhun ulkoiseen

joukon mrittelevn standardiin, joita tyypillisesti ovat: Mime Types, UCUM,

LOINC, SNOMED, kielikoodit jne. (HL7, 2015c; McKenzie, 2013)

32

Monimutkaisissa tyypeiss (CodeableConcept ja Coding) elementit sidotaan kytett-

vi koodattuja arvoja sisltvn listaan. Arvojoukkojen monimutkaisuuden ja koon

vuoksi kytt ei mritell skeematasolla, vaan siihen kytetn Value Set -resurssin

sntj. (HL7, 2015c; McKenzie, 2013)

4.5 Tietotyypit

FHIR mrittelee resurssielementeiss kytettvt tietotyyppijoukot (data types). Tie-

totyypit jaetaan kahteen eri kategoriaan, joista yksinkertaisiin (primitive) kuuluu 13

erilaista ja vastaavasti monimutkaisiin (complex) 18 erilaista tietotyyppi. Yksinker-

taiset tietotyypit tuodaan XML-skeemasta ja monimutkaiset ovat uudelleenkytettvi

elementtiryhmi. Tietotyypit esitetn kuvassa 4. (HL7, 2015e; Suhonen et al., 2013)

Kuva 4: Tietotyyppien yleiskuva (HL7, 2015e).

Yksinkertaisia tietotyyppej (kts. kuva 5) ovat esimerkiksi totuusarvot (boolean), ko-

konaisluvut (integer), desimaaliluvut, teksti (string) ja pivmrt (date). Aliominai-

suudet eivt ole mahdollisia, mutta laajennukset ovat sallittuja muiden resurssien ja

tietotyyppien tapaan. Tarkemmat rajoitteet taasen kuvataan FHIR-mrityksess. Yk-

sinkertaiset tietotyypit pohjautuvat w3c-skeemaan ja ISO-mritellyihin tietotyyppei-

hin. (HL7, 2015e; Suhonen et al., 2013)

33

Kuva 5: Yksinkertaiset tietotyypit (HL7, 2015e).

Vastaavasti monimutkaiset tietotyypit esitetn XML- ja lapsielementtein (kts. kuva

6). Tietotyypin kytt mritt tietotyypille nimen ja monimutkaisten tietotyyppien

elementtien arvoja ja rajoituksia voidaan sdell niiden profiloinnilla. (HL7, 2015e;

Suhonen et al., 2013)

34

Kuva 6: Monimutkaiset tietotyypit (HL7, 2015e).

4.6 FHIR-Toteutustavat

FHIR tukee nelj toteutustapaa (paradigms), joita ovat REST-rajapinnat, dokumentit,

sanomat ja palvelut. Toteutustavasta riippumatta kytettyjen resurssien sislt pysyy

samana, jolloin erilaisten toteutustapojen vlinen tiedonsiirto on suoraviivaista. Esi-

merkiksi Vastaanota laboratoriotulos sanomassa tai Paketoi tulos kotiutusdoku-

35

menttiin. Dokumentit on kokoelma yhteen kerttyj resursseja. Lisksi ne ovat yhte-

nevisi CDA:n dokumenttien kanssa, jolloin ne voidaan mys allekirjoittaa. Doku-

mentit liikkuvat ATOM-sytteen. (Quinn, 2014c)

Vastaavasti FHIR:n sanomat mukailevat HL7 v2 ja v3 sanomia. Kytnnss sanomat

toimivat resurssien (esimerkiksi ATOM-sytteen) kokoelmana (Grieve et al., 2015).

Sanomat toimivat tapahtumina, joilla voidaan ohjata esimerkiksi laboratoriomrys-

ten lhettmist. Lisksi ne toimivat asynkronisesti molempiin suuntiin tapahtumape-

rusteisesti (send lab order/ get back result). Vastaavasti palvelut toteutetaan yksinker-

taisiin resursseihin ja kokoelmiin perustuvaa SOA-periaatetta kytten. REST-rajapin-

nasta kerrotaan tarkemmin luvussa 3.5 ja 4.7. (Grieve et al., 2015; Grieve et al., 2012a;

Quinn, 2014c; Suhonen et al., 2013)

FHIR-standardi ei ole nirso kytettvlle tiedonsiirtotekniikalle ja se pystyykin kom-

munikoimaan kytten esimerkiksi HTTP:t, MLLP:t, MQ:ta, SOAP:ia tai jotain

muuta kytttapaukseen soveltuvaa tekniikkaa hyvksikytten. (Quinn, 2014a; Suho-

nen et al., 2013)

4.7 REST-interaktioiden tyypit FHIR-standardissa

Resursseja hallinnoidaan joukolla interaktioita, jotka suoritetaan palvelimella http re-

quest ja responsen avulla. Rest-rajapinta mritt FHIR-resurssit joukkona operaati-

oita (interaktioita), joita ohjataan tyypinmukaisina kokonaisuuksina. Seuraavassa on

kuvailtu edell mainitut interaktiot:

Instassitason interaktiot (instance level interactions):

o Read, lukee resurssin nykyisen tilan.

o Vread, lukee resurssin tietyn version tilan.

o Update, pivitt olemassa olevan resurssin sen id:n perusteella. Jos re-

surssia ei ole olemassa, update-komennon myt sellainen luodaan.

o Delete, poistaa resurssin.

o History, hakee yksittisen resurssin pivityshistorian.

Tyyppitason interaktiot (type level interactions).

36

o Create, luo uuden resurssin palvelimen myntmll tunnuksella (id).

o Search, etsii joukon resursseja hakukriteerien perusteella.

o History, hakee kaikkien tietyn tyyppisten resurssien pivityshistorian.

Koko jrjestelmn interaktiot (whole system interactions).

o Conformance, hakee jrjestelmn mrityksenmukaisuuslauselman.

o Transaction, pivitt, luo tai poistaa usempia resursseja kerrallan.

o History, hakee kaikkien resurssien pivityshistorian.

o Search, etsii joukon resursseja hakukriteerien perusteella koko jrjes-

telmn laajuudelta. (HL7, 2015q)

4.8 FHIR-standardin rakenteinen yhteenveto

Tutkielman luvussa 2.2 esiteltiin yhteentoimivuusstandardin arviointimalli (viiteke-

hys). Tmn aliluvun tarkoitus on esitell FHIR-standardin rakenteinen yhteenveto lu-

vussa 2.2 arviointimalliin nojautuen.

FHIR-standardista on tehty M. Suhosen, J. Mykksen, A. Miettisen ja H. Virkasen

toimesta Fast Health Interoperability Resources FHIR-standardin kuvaus ja arvi-

ointi -niminen selvitys, jossa on luotu FHIR-standardin yhteenveto arviointilomak-

keilla. FHIR-standardia voidaan tutkia rakenteisesti em. arviointilomakkeen kautta

(Evaluation forms). (Mykknen et al., 2008; Suhonen et al., 2013)

Seuraavassa kydn lvitse FHIR-standardin rakenteinen yhteenveto, joka pohjautuu

luvun 2.2 arviointimalliin. Aineistona on kytetty edell mainittua dokumenttia. (Su-

honen et al., 2013)

Perustiedot ja kohdealue (Basic information and scope of the standard)

FHIR tarjoaa tarvittavat resurssit potilastiedon vlittmiseen jrjestelmien v-

lill. Se mahdollistaa standardin vaivattomaan kytn RESTful ympristiss,

viestien vlittmiseen, kliinisen dokumentaation vlittmiseen ja SOA-arkki-

tehtuurille.

37

Kohdeyleis on pasiassa tekninen ja liiketoiminnallinen, erityisesti tervey-

denhuollon nkkulmasta.

FHIR nojautuu toimiessaan XML-, JSON-, HTTP-, ATOM-, Oauth- ja REST-

standardeihin. (Mykknen et al., 2008; Suhonen et al., 2013)

Tieto ja semantiikka (Information and semantics)

Standardi kuvaa tietomallit ja resurssit, sek niiden vlisi semanttisia yhteyk-

si.

Standardi selitt ksitteet, datatyypit, koodistot ja terminologian.

Kytettviss olevat koodistoja ovat esimerkiksi SNOMED CT, LOINC,

UCUM, ICD-10, ICD-9 USA, ATC, ISO 11073-10101 Medical Device Codes

ja DICOM. (Mykknen et al., 2008; Suhonen et al., 2013)

Toiminnot ja interaktiot (Functionality and interactions)

Standardi kuvaa kytettvt prosessit ja tynkulut tarkemmalla tasolla.

Standardin toiminnot tapahtuvat RESTful API-rajapinnan vlityksell HTTP:n

lhetys- ja vastaanottamisprotokollaa hyvksi kytten. (Mykknen et al.,

2008; Suhonen et al., 2013)

Sovellusarkkitehtuuri (Application infrastructure aspects)

Standardi pystyy jakamaan viestej, dokumentteja, resursseja RESTful API-

rajapinnan kautta. Jakamiseen kytettv yhteys voidaan luoda sek synkroni-

sesti, ett asynkronisesti.

Viestien yms. vlityksess kytetn hyvksi kohteen osoittamiseen URL-

osoitetta.

Kytetn hajautettujen jrjestelmien pohjana, ei niinkn yksittist kyttj

varten. Arkkitehtuuri mahdollistaa useiden eri tietokantojen, komponenttien ja

kyttliittymien yhtaikaisen toimimisen. (Mykknen et al., 2008; Suhonen et

al., 2013)

Tekninen nkkulma (Technical aspects)

38

Standardi siirt tietoa yms. kytten hyvksi ainoastaan XML ja JSON -tek-

nologioita. Interaktiot ja muu toiminnallisuus tapahtuu kytten REST ja

HTTP -rajapintoja hyvksikytten.

Standardia ei ole sidottu tiettyyn kyttjrjestelmn tai alustaan.

Standardia mahdollistaa ohjelmoinnin Javalla, C#:lla ja Delphill. (Mykknen

et al., 2008; Suhonen et al., 2013)

Laajennettavuus (Flexibility, accuracy, extensibility)

Standardin onnistunutta laajennettavuutta mitataan kahdella kriteerill. Onko

se FHIR-standardin vaatimusten mukainen ja tyttk se ko. standardin vaa-

timukset resursseissa ja muissa palveluissa. Sertifikaattia ei vaadita, mutta tes-

taus tapahtuu Connectathon -testaustapahtumissa.

Vaaditaan resurssituki, terminologia, datatyypit ja FHIR-standardin perusomi-

naisuudet, jotta laajennettavuus toteutuisi. Niden lisksi voidaan kytt mys

yht tai useampaan kytntnpanomallia (REST, viestit, dokumentit, palvelut

jne.).

Kaikki resurssit ja elementit ovat laajennettavissa. (Mykknen et al., 2008; Su-

honen et al., 2013)

Levinneisyys (Maturity, usage, official status)

Standardi on vapaaehtoisen ja kansainvlisen yhteisn tuote, joka on ANSI ak-

kreditoitu vastaamaan HL7-konsortion vaatimuksia.

Standardin speksit koostuvat yli 1500 eripituisesta html-sivusta. Se on mys

melko ymmrrettv mys henkilille, joilla ei ole aikasempaa HL7-standar-

dien kokemusta.

Lytyy kymmenittin projekteja, jossa standardia on kytetty. (Mykknen et

al., 2008; Suhonen et al., 2013)

Jrjestelmn elinkaareen (System lifecycle)

Standardin resurssimallit luovat perustan yksityiskohtaisille vaatimuksille.

Arkkitehtuurisesti joudutaan kartoittamaan vaatimukset standardin kyttmille

39

palvelimille ja komponenteille. Vastaavasti resurssimallien ja laajennusten

vaatimukset otettava kehityksess huomioon. Varsinainen toiminnallisuus ta-

pahtuu RESTful API-rajapintaa kytten.

Standardille on mahdollista tuottaa uusia laajennuksia, mutta taaksepin yh-

teensopivuutta ei voida viel kehittell olevassa versiossa taata. (Mykknen

et al., 2008; Suhonen et al., 2013)

Toimialuekohtaiset ominaisuudet (Domain-specific features)

Terveydenhuolto toimialueena tuo standardille omat vaatimuksensa. Standar-

din pit kyet mm. seuraaviin toimintoihin:

o shkinen potilaskertomus, diagnoosit, hoidot, viestinvlitys

o kliininen ptksentuki

o ajanvarauskalenterit

o mittaukset, analyysit, raportointi, tutkimuskytn tuomat vaatimukset

o tietoturvan toteutuminen tuo omat vaatimukset

o rakenteistetun ja rakenteistamattoman tiedon ksittely

o laskutus ja muut hallinnolliset toiminnot

o Jne.

Terveydenhuollon mukana tulee vaatimuksia mys laskutukseen ja hallintoon.

Kytettvyyden parantaminen on isossa roolissa.

Tynkulkuihin ja muuhun kuin terveydenhuollon liiketoimintaan standardin ei

tarvitse taipua. (Mykknen et al., 2008; Suhonen et al., 2013)

40

5 MILLAINEN ON FHIR-STANDARDIA HYDYN-

TV RAJAPINTAMRITTELY

Tmn luvun tarkoitus on esitell FHIR:i hydyntv rajapintamrittely ajanvaraus-

esimerkki kytten. Luvun sislt koostuu aliluvuista, joista kahdessa ensimmisess

esimerkkitapauksen perusarkkitehtuuri ja tapauksen tarkempi kuvaus. Kolmannessa ja

neljnness aliluvussa poraudutaan esimerkkin toimivan ajanvarausohjelmiston ja

ajanvarauspalvelimen tietosisltihin, tynkulkuihin ja interaktioihin. Viimeiseksi esi-

telln esimerkkitapauksessa tarvittavat resurssit.

5.1 Ajanvarauksen perusarkkitehtuuri esimerkiss

Tmn kappaleen pohjana kytetn Sote-ajanvarauksen resurssienhallintaintegeraa-

tiot: HL7 v3 SAV soveltamisohje -dokumenttia, jonka mukaan HL7 v3:sta kyttvn

ajanvarausjrjestelmn perusarkkitehtuuri voidaan jakaa kolmeen tasoon:

1. Ajanvarausohjelmisto, jota asiakas kytt shkiseen asiointiin eli tss tapauk-

sessa ajanvaraamiseen. Kyseinen palvelu kykenee kyselemn vapaita ja varattuja

aikoja, sek suorittamaan resurssien hallintaa ajanvaraustoimenpiteit hydynten.

Kyselyt tapahtuvat reaaliaikaisesti taustajrjestelmist integraatiokerrosta hyvk-

sikytten.

2. Integraatiokerros toimii pinnan alla sovittaen yhteen eri taustajrjestelmi. Kerrok-

sessa luodaan ja hallinnoidaan varaustuotteita, jotka mahdollistavat ajanvaraami-

sen. Eli kytnnss integraatiokerros toimii ajanvarausohjelmiston ja ajanvaraus-

palvelimen vliss mahdollistaen niiden toiminnan.

3. Ajanvarauspalvelin, jossa tapahtuu varsinainen resurssien ja kalentereiden hallinta.

Tm taso sislt yleens mys palveluntuottajan sisisen toiminnanohjauksen.

(THL, 2015a)

FHIR-pohjaisessa ratkaisussa voidaan kytt vastaavaa perusarkkitehtuuria kuin

SADe-ohjelman vastaavassa HL7 v3 -ajanvaraustoteutuksessa. Tss esimerkiss

41

edell mainittua perusarkkitehtuuria sovelletaan siten, ett integraatiokerros jtetn

pois.

5.2 Kytttapauksen kuvaus

Esimerkin kytttapauksena kuvaillaan tilannetta, jossa kyttj varaa ajanvarausoh-

jelmistoa hyvksikytten hammaslkriaikaa. Oletustilanteessa kalenteri nytt

vain vapaita aikoja puoleksi vuodeksi eteenpin. Saadakseen ajan kyttj aukaisee

ajanvarausohjelmiston, josta hn voi aloittaa ajan varaamisen seuraavien interaktioi-

den mukaisesti: (THL, 2015a)

1. Vapaiden hammaslkriaikojen kysely ja vastaus. Kyttj kysyy ajanvaraus-

ohjelmistoa kytten seuraavan kyselyn ajanvarauspalvelimelta: Milloin ly-

tyy vapaita aikoja hammaslkrille ensi kuussa?. Vapaata aikaa hakiessa voi-

daan kyselyss kytt erilaisia tarkentavia parametreja, kuten haetaan kaikki

alueen hammaslkrit tai pelkstn nimetty hammaslkri.

2. Ajanvarauspalvelin lhett vastauksena varattavissa olevat ajat kyselyn poh-

jalta ajanvarausohjelmistolle.

3. Ajanvarausohjelmistoa kytten kyttj valitsee ajanvarauspalvelimen lhet-

tmist ajoista sopivimman. Tmn jlkeen tieto valitusta ajasta vlittyy ajan-

varauspalvelimelle.

4. Ajanvarauspalvelin lhett vahvistuksen varatusta ajasta ajanvarausohjelmis-

tolle, josta kyttj sen nkee.

Edell selostettu kytttapaus kuvataan kuvassa 7, jossa eri interaktiot on merkitty

jrjestysnumeroin. Yhteentoimivuus on mahdollista jrjestelmien standardoitujen

rajapintojen vuoksi. Muita interaktioita olisi esimerkiksi ajan siirtminen, perumi-

nen ja jo varatun ajan tarkastaminen. (THL, 2015a)

42

Kysyy vapaita aikojahalutulle pivlle

KyttjAjanvaraus-

Palvelin

Tarjoaa listanvapaista ajoista

Valitsee sopivan ajan

Vahvistaa valitun ajan

Kytttapauskaavio ajanvaraamisesta

1

2

3

4

Kuva 7: Kyttjn (ajanvarausohjelmisto) ja ajanvarauspalvelimen kytttapauskaa-

vio ajanvaraamisesta.

5.3 Tarvittavat tietosisllt ja tynkulut

Kyttjn ajanvarausohjelmisto kytt schedule -resurssia kysyessn vapaita aikoja

ajanvarauspalvelimelta. Resurssia kytetn ajanvarausten tekemiseen FHIR-pohjai-

sessa ajanvarausjrjestelmss. Sille voidaan mritt tietyt reunaehdot ajan, tapaa-

mistavan, paikan yms. suhteen. (HL7, 2015f)

Esimerkkitapauksen ajanvarauksen kyselyss vaaditaan seuraavia tietosisltj:

Varauksen kohde, eli mit palvelua ollaan varaamassa?

Toimipiste tai sijainti, eli esimerkiksi ajanvaraukseen liittyv yksikk.

Tieto varauksen kohteena olevasta ammattilaisesta.

Ajanvarausprosessin edetess tarvitaan tieto aikaikkunasta, jolle varaus halu-

taan tehd. (HL7, 2015f; THL, 2015a)

Ajanvarauksen kyselyn vastaukseen vaaditaan seuraavat tietosisllt:

43

Varattavana olevan palvelun vapaat aikavlit halutussa aikaikkunassa.

Vapaiden aikojen sijainnit tarvittaessa, jos haettiin useammasta eri toimipis-

teest vapaita aikoja.

Ajanvaraus (appointment) -resurssin yhteydess on kuvattu yksinkertainen tynkulku

(basic work flow) aikojen varaamiseen:

1. Varattavan palvelun lytminen ja osoittaminen. Ennen ajanvarauksen teke-

mist tytyy varattava palvelu paikantaa palvelutyypin mukaisesti. Palvelutyy-

pin ja palvelun aikataulun ksittelyyn ja kuvaamiseen kytetn schedule -re-

surssia. Schedule-resurssi kytt vastaavasti slot-resurssia, joka sislt m-

ritellyn aikaikkunan.

2. Ajanvarauspalvelin tarjoaa vapaita aikoja. Pelkk vapaana oleva aika ei kui-

tenkaan takaa varausta, koska varaukseen vaikuttavat esimerkiksi varaajan

kyttoikeudet yms. Tss vaiheessa voidaan kuitenkin havaita, ettei vapaita

aikoja ole tai ajan varaaminen ei ole mahdollista, jolloin varausprosessi voi-

daan peruuttaa.

3. Kyttj valitsee sopivan ajan, jolloin ajanvarausohjelmisto vlitt tiedon

ajanvarauspalvelimelle kytten appointment- ja schedule -resursseja.

4. Ajanvarauspalvelin vastaa kyttjn ajanvarauspyyntn appointment- ja

schedule -resursseilla.

5. Jos halutaan varata uusi aika, toistetaan edell kuvailtu prosessi. (HL7, 2015f;

HL7, 2015h)

FHIR tukee kahta erilaista tynkulkua, joista ensimminen on edellisen esimerkin mu-

kainen aikaperustainen outlook-style. Tarkempaan varaamiseen voidaan kytt

monimutkaisempaa, mutta vaativampaan kyttn tarkoitettua erillist tynkulkua.

(HL7, 2015f)

44

5.4 Tarvittavat interaktiot

Tm luku kuvaa ainoastaan esimerkiss kytettv REST/HTTP -pohjaista toteutus-

tapaa. Luvussa 4.6 on esitelty mys muita FHIR-standardin toteutustapoja, joilla ajan-

varausohjelmisto olisi mahdollista tehd.

Sanomien (resurssien) kulkua voidaan kuvata sekvenssikaaviolla, kuten kuvassa 8.

Ajanvarausohjelmisto Ajanvarauspalvelin

1. Vapaiden aikojenkysely

2. Vastaus pyydetyistvapaista ajoista

3. Varauspyynt yhteenvapaaseen aikaan

4. Vastaus varauspyyntn

Kuva 8: Sekvenssikaavio sanomien kulusta.

Sekvenssikaavio kuvaa ajanvarausohjelmiston ja ajanvarauspalvelimen vlist resurs-

sien vaihdantaa. (HL7, 2015f) Vastaavasti kaikki tarvittavat loogiset interaktiot on esi-

telty luvussa 4.7.

45

1. Vapaiden aikojen kysely (discovery). Ajanvarausohjelmisto kyselee ajanva-

rauspalvelimelta vapaita aikoja kytten schedule-resurssia. Esimerkiss ajan-

varausohjelmisto lhett kyselyparametrina schedule-resurssin tyypin, jonka

perusteella lydetn oikeantyyppiset palvelut. Jos halutaan hakea pelkstn

hammaslkreit, voisi tyyppin olla hammaslkri ilmaiseva palvelutyy-

pin tunniste. Nin haettaisiin vain halutun tyyppiset palvelutuottajat. (HL7,

2015h)

Loogisia interaktioita tapahtuu tyyppitasolla (type), jossa search -interaktiolla

etsitn hakukriteereihin sopivaa resurssia eli esimerkin hammaslkri

(tyyppi schedule.type). Alemman instanssitason (instance) interaktioista ky-

tetn read-interaktiota, jolla luetaan lydetyn hammaslkrin schedule-re-

surssin sisltmn slot-resurssin sislt. (HL7, 2015q)

2. Vastaus pyydetyist vapaista ajoista. Ajanvarauspalvelin etsii kyttjn syt-

tmn schedule-resurssin tyypin ja rajausten pohjalta vapaita ja varattavissa

olevia slot-resursseja kaikista niist kalentereista (schedule), jotka vastaavat

valittua palvelutyyppi. Sopivat slot-resurssit lydettyn ajanvarauspalvelin

palauttaa ne rest-rajapintaa hyvksi kytten kyttjn ajanvarausohjelmis-

toon, josta hn voi valita sopivimman ajan. (HL7, 2015h)

3. Kun kyttj valitsee ajanvarausohjelmistossa vapaan ajan, luo ajanvarausoh-

jelmisto samalla appointment-resurssin ajanvarauspalvelimelle. Tllin luodun

resurssin statusarvo on ehdotettu eli appointment.status = proposed. Ajan-

varausohjelmisto tydent resurssia olemassa olevilla tiedoilla, eli esimer-

kiksi ajanvarauksen tyypill (appointment.type) ja osallistujilla (partici-

pant.type). (HL7, 2015f) Loogisia interaktioita tapahtuu hyvksyttess slot-

resurssin sislt, joka lhetetn rest-rajapintaa hyvksi kytten ajanvaraus-

palvelimelle. Tst syyst resurssin tila pivitetn instanssitason update-inter-

aktiolla. (HL7, 2015q)

4. Ajanvarauspalvelimen vastaus varauspyyntn. Ajanvarauspalvelin ilmoittaa

ajanvarausohjelmistolle varauksen luonnin onnistumisen ja merkkaa kyseisen

appointment-resurssin statuksen varatuksi (status=..reserved). Varauksen

onnistuttua on syntynyt uusi appointment-resurssi, joka sislt varauksen tie-

dot niin varatusta palvelusta, varauksen osallistujista, varauksen syyst kuin

46

varatusta ajastakin. Vastaavasti tuottajan schedule-resurssista on merkattu yksi

vapaa slot-resurssi varatuksi, joten kyseist slot-resurssia ei tarjota en uu-

sissa ajanvarausohjelmiston tuottamissa kyselyiss. Tss vaiheessa on mys

mahdollista luoda encounter-resurssi valmiiksi tulevaa kontaktia varten. (HL7,

2015f)

Esimerkin ajanvarausjrjestelm voidaan toteuttaa RESTful -rajapinnan kautta.

Jotta tehtvss onnistuttaisiin, vaaditaan thn monien erilaisten palveluiden ja pal-

velimien saumatonta yhteistyt. Esimerkiksi ajanvarauspalvelimen on oltava yhtey-

dess potilastietojrjestelmn. Lisksi ajanvarausohjelmiston kyttj tulee tunnistaa

viimeistn ennen sopivan ajan valintaa. Kytnnss asiakkaan tunnistaminen voitai-

siin toteuttaa SADe ajanvaraus integraatioarkkitehtuuri -dokumentissa kuvatulla ta-

valla, jossa on luotu erikseen kytnhallintapalvelut. Nm palvelut koostuisivat asi-

akkaan tunnistamisesta, valtuutuksesta, suostumuksista ja kielloista. (THL, 2015b)

Tarvittavat resurssit on esitelty seuraavassa luvussa.

5.5 Tarvittavat resurssit (FHIR)

Lhdettess kehittmn ajanvarausohjelmistoa ja ajanvarauspalvelinta FHIR-stan-

dardia kytten tarvitaan seuraavia resursseja:

Appointment-resurssi, jota kytetn ajanvarausten tekemiseen. (HL7, 2015f)

Schedule -resurssi, joka sislt ajanvarauksessa kytettvt aikavlit eli slot-

resurssit. (HL7, 2015h)

Slot-resurssi, joka sislt varattavissa olevan aikavlin. (HL7, 2015i)

Encounter-resurssi, joka tarkoittaa kynti tai kohtaamista. Esimerkiss en-

counter-resurssi syntyy kun potilas ja hammaslkri kohtaavat. (HL7, 2015l)

FHIR-standardissa olisi kytss mys AppointmentResponse -resurssi, joka on tar-

koitettu kytettvksi useiden eri jrjestelmien ajanvarausstatusten pivittmiseen.

47

AppointmentResponse -resurssia ei kuitenkaan tarvita tss tyss kytetyss esimer-

kiss, koska esimerkin ajanvaraus koostuu vain kahdesta jrjestelmst, eli ajanvaraus-

palvelimesta ja ajanvarausohjelmistosta. (HL7, 2015f)

5.5.1 1/4 Appointment-resurssi

Ajanvaraus (appointment) -resurssi tarjoaa tiedon ajanvarauksesta. Varattu aika voi

olla esimerkiksi tuleva leikkausoperaatio tai jo pidetty kokouspuhelu. (HL7, 2015f)

Ajanvarauksen appointment-resurssin sislt kuvataan luokkakaavio-diagrammilla

kuvassa 9.

Kuva 9: UML diagrammi appointment-resurssista. (HL7, 2015f)

Luokkakaavio jaetaan kuvan 9 mukaisesti itse ajanvaraustapahtumaan ja osallistujaan,

joita voi olla varattavalla tapahtumalla olla useampi. (HL7, 2015f)

Resurssin sislt kuvataan taulukossa 1.

48

Nimi Tyyppi Sislt ja kuvaus

-Appointment DomainResource Ajavaraustapahtuma.

-Identifier 0..* Identifier Resurssin id.

-Status 1..1 Code Ajanvarauksen tila: ehdotettu/ odottaa/

varattu/ saapunut/ peruttu jne.

-Type 0..* CodeableConcept Varattavan tapahtuman tyyppi.

-Reason 0..1 CodeableConcept Syy ajanvaraukselle.

-Priority 0..1 UnsignedInt Trkeysaste uudelleen jrjestely var-

ten.

-Description 0..1 String Nytt ajanvarauksen aiheen.

-Start 0..1 Instant Ajanvarauksen aloitus.

-End 0..1 Instant Ajanvarauksen pts.

-MinutesDura-

tion

0..1 PositiveInt Ajanvarauksen kesto.

-Slot 0..* Reference(Slot) Jos tarjottu, ajan tytyy tsmt start-

ja end -sisltihin.

-Comment 0..1 String Valinnainen kommentointi.

Taulukko 1: Appointment-resurssin rakenne. (HL7, 2015f)

Lisksi esitelln erillinen participant-aliresurssi (osallistuja) taulukossa 2:

49

Participant 1..* BackboneElement Ajanvaraukseen osallistujat

-Type 0..* CodeableConcept Osallistujan rooli.

-Actor 0..1 Reference() Patient | RelatedPerson | Device |

HealthcareService | location.

-Required 0..1 Code Required | optional | information-

only.

-Status 1..1 Code Accepted | declined | tentative | needs-

action.

Taulukko 2: Appointment-resurssin osana toimivan participant-aliresurssin rakenne.

(HL7, 2015f)

Appointment-resurssin koodisto (terminology):

1. Appointment.status, joka kertoo ajanvarauksen statuksen eli tilan. Status voi

olla arvoltaan: ehdotettu, odottaa, varattu, saapunut, suoritettu, peruttu tai ei

ilmaantunut paikalle (HL7, 2015f; HL7, 2015m).

2. Appointment.type, joka kertoo ajanvarauksen tyypin. Ajanvarauksen tyyppi

voi olla esimerkiksi Snomediin perustuva, jolloin eri tyyppej