FHIR-standardin ominaisuudet ja soveltaminen
Markus Huhta
Pro gradu -tutkielma
Tietojenkäsittelytieteen laitos Tietojenkäsittelytiede
Lokakuu 2016
ITÄ-SUOMEN YLIOPISTO, Luonnontieteiden ja metsätieteiden tiedekunta, Kuopio Tietojenkäsittelytieteen laitos
Tietojenkäsittelytiede
Markus Huhta: FHIR-standardin ominaisuudet ja soveltaminen Pro gradu -tutkielma, 74 s.
Pro gradu -tutkielman ohjaaja: FT Juha Mykkänen Lokakuu 2016
Terveydenhuollon tietojärjestelmissä yhteentoimivuus on aina ollut tärkeää, eikä sen merkitys ole vähenemään päin. Yhteentoimivuus voidaan saavuttaa käyttämällä yh- teentoimivuusstandardeja, joista HL7:n standardiperhe on yksi tärkeimmistä. Tutki- musmenetelmänä sovellettiin kirjallisuuskatsausta ja systemaattista arviointia raken- teista arviointimallia hyväksi käyttäen.
HL7 versio 2 ja 3 standardit ovat käytetyimmät ko. standardiperheen standardeja ja ne saavat lähivuosina jatkoa FHIR-standardin muodossa. FHIR-standardin on tarkoitus vastata haasteeseen terveydenhuollon standardien nykyaikaistamisesta. Tutkielma va- lottaa FHIR-standardin kehityksen nykytilaa ja tarkastelee sen soveltuvuutta käytän- nön esimerkin muodossa. Tutkielman tarkoitus on vastata seuraaviin tutkimuskysy- myksiin:
1. Antaa yleiskuva FHIR-standardista ja sen suhteista aiempiin keskeisiin tervey- denhuollon tietojärjestelmien standardeihin.
2. Kuvata FHIR-standardin keskeiset ominaisuudet, kehitysvaiheineen, sekä ar- vioida FHIR-standardin soveltuvuutta terveydenhuollon standardina ja lopuksi soveltaa standardia esimerkin voimin.
Tutkielman aiheen FHIR-standardi on vasta kehitysasteella oleva standardi, joten re- levantin ja laajasti aihetta käsittelevän aineiston löytäminen oli haaste. Suurin osa ai- neistosta on kuitenkin alaa käsittelevästä kirjallisuudesta ja FHIR-kehittäjien verkko- sivuilta. Kirjallisuuskatsaus ei ole systemaattinen, vaan sitä on sovellettu palvelemaan tutkielman tarkoitusta.
Tutkielma osoittaa FHIR-standardin olevan nykyaikainen standardi, jossa on valmis- tuessaan potentiaalia tuotantokäyttöön. Tutkielma vastaa tutkimuskysymyksiin yleis- kuvan antamisen lisäksi kuvaamalla ko. standardin keskeisimmät ominaisuudet ja ke- hitysvaiheet. Standardin käyttöä tutkitaan käytännön esimerkin kautta.
Avainsanat: Yhteentoimivuus, standardit, potilastietojärjestelmät, FHIR
ACM-luokat (ACM Computing Classification System, 1998 version): Standards, Interoperability, Medical information systems, Software development
UNIVERSITY OF EASTERN FINLAND, Faculty of Science and Forestry, Kuopio School of Computing
Computer Science
Markus Huhta: Features and application of FHIR-standard Master’s Thesis, 74 p.
Supervisor of the Master’s Thesis: PhD Juha Mykkänen October 2016
Interoperability has always been an important aspect of healthcare information sys- tems. High level of interoperability can be achieved through the use of interoperability standards, of which the HL7 family of standards is among the most important. Litera- ture review and systematic evaluation of structured review models were the primary research methods in this work.
The most widely utilized standards among the HL7 family are versions 2 and 3, and they 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 examine its feasibility by means of a case study. This thesis also aims to answer the following research questions:
1. Provide an overall description of the FHIR standard and its relationships with respect 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 apply the standard through a case study.
The FHIR standard, which forms the focus of this thesis, is still in its developmental phase. 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 the study, as well as the FHIR developers’ websites. The literature review is not strictly systematic; rather it was applied to serve the purposes of this thesis.
This thesis demonstrates that FHIR is a contemporary standard that carries potential for production use once it reaches its mature release state. In addition to providing an overview and answering the research questions, this thesis also delineates the stand- ard’s central features and development phases. Finally, the standard’s 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
Esipuhe
Tämä tutkielma on tehty Itä-Suomen yliopiston Tietojenkäsittelytieteen laitokselle syksyllä 2016. Haluan kiittää seuraavia ihmisiä tämän tutkielman tuesta. Juha Myk- kästä, jonka asiantuntemus on vailla vertaansa ja joka aktiivisesti tuki tutkielman kir- joittamista. Toista graduni tarkastajaa ja viimeisten kirjoitusvirheiden löytäjää Anne Eerolaa. Vaimoani, joka tuki ja arvosti tekemääni työtä. Sekä poikaani, joka syntyi tutkielman loppumetreillä. Kavereitani, joiden vertaistuki ja aktiivisuus olivat ilmiö- mäistä. Ilman teitä tämä tutkielma olisi varmasti valmistunut aikaisemmin. Työpaik- kani tukea ja erityisesti Petteriä, joka toimii osaltaan mentorin roolissa ja oli vaikutta- massa aiheen valintaan. Lisäksi kiitän muuta perhettäni ja heitä, jotka unohdin mainita.
Lyhenneluettelo
ASTM American Society for Testing and Materials CDA Clinical Document Architecture
DICOM Digital Imaging and Communications in Medicine DMIM Domain Message Information Model
DSTU Draft Standard For Trial Use EHR Electronic Health Record
EHR-S Electronic Health Record -System
FHIR Fast Healthcare Interoperability Resources
HIMSS Healthcare Information and Management Systems Society HIS Hospital Information System
HL7 Health Level 7
HMD Hierarchical Message Description HTML Hyper-Text Markup Language HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IEEE Institute of Electrical and Electronics Engineers IHE Integrating the Healthcare Enterprise
ITS Implementation technology specification ISO International Organization for Standardization JSON JavaScript Object Notation
JPEG Joint Photographic Experts Group MIME Multipurpose Internet Mail Extension
NEMA National Electrical Manufactures Association PACS Picture Archiving and Communication System PDF Portable Document File
PHR-S Personal Health Record System PMI Project Management Institute REST Representational State Transfer RIM Reference Information Model RIS Radiology Information System RMIM Refined Message Information Model RSNA Radiological Society of North America SOA Service Oriented Architecture
SR Structured Reporting
URI Uniform Resource Indicator URL Uniform Resource Locator
WADO Web Access to DICOM Persistent Objects XML Extensible Markup Language
Sisällysluettelo
1 Johdanto ... 1
2 Menetelmät ja viitemallit ... 3
2.1 Kirjallisuuskatsauksen ja konstruktiivisen työn menetelmät ... 3
2.2 Yhteentoimivuusstandardin arviointimalli ... 6
2.3 Käsitteistö ... 9
2.3.1 Standardi ... 10
2.3.2 Yhteentoimivuus ... 10
2.3.3 Sähköiset potilastietojärjestelmät ... 11
2.3.4 Terveydenhuollon tietojärjestelmät ... 12
2.3.5 EHR ... 12
2.3.6 PHR ... 13
2.3.7 Muut keskeiset käsitteet ... 13
3 Terveydenhuollon sovellusten yhteentoimivuusstandardit ja REST ... 17
3.1 Yhteentoimivuuden ja standardien merkitys terveydenhuollossa .... 17
3.2 HL7-standardit ... 18
3.2.1 HL7 v2 sanomastandardit ... 18
3.2.2 HL7 v3 standardiperhe ... 19
3.2.3 CDA ... 20
3.3 DICOM ... 21
3.4 IHE ja IHE-profiilit ... 22
3.5 REST ... 24
4 FHIR-standardi ... 26
4.1 FHIR-yleiskuva... 26
4.2 FHIR:n kehittyminen ... 26
4.3 Resurssiajattelu FHIR-standardissa ... 27
4.3.1 Resurssin vaatimukset ... 28
4.3.2 Resurssin sisältö (elementit) ... 28
4.3.3 FHIR-Profiilit ... 30
4.4 Koodistojen käyttö ... 31
4.5 Tietotyypit ... 32
4.6 FHIR-Toteutustavat ... 34
4.7 REST-interaktioiden tyypit FHIR-standardissa... 35
4.8 FHIR-standardin rakenteinen yhteenveto... 36
5 Millainen on FHIR-standardia hyödyntävä rajapintamäärittely... 40
5.1 Ajanvarauksen perusarkkitehtuuri esimerkissä ... 40
5.2 Käyttötapauksen kuvaus ... 41
5.5.3 3/4 Slot-resurssi ... 51
5.5.4 4/4 Encounter-resurssi ... 54
6 Pohdinta ... 59
7 Yhteenveto ... 61
Viitteet ... 62
1 JOHDANTO
Terveydenhuollon tietojärjestelmissä standardien käyttäminen luo pohjan potilastieto- tietojärjestelmien yhteentoimivuudelle. Standardeja hyväksi käyttäen eri toimijoiden järjestelmät kykenevät keskustelemaan keskenään, minkä lisäksi ne tuovat moninaisia hyötyjä niin teknisestä kuin taloudellisestakin näkökulmasta. Lisäksi standardit mm.
yhdenmukaistavat tuotantoprosesseja, sekä parantavat eri mittarien luotettavuutta ja oikeudenmukaisuutta. (Mykkänen et al., 2008) Yhteentoimivuuden ja standardien merkitystä käsitellään tarkemmin luvussa 3.1.
Vaikka standardeja on käytetty eri tietojärjestelmissä vuosikymmenien ajan, ovat ne siitä huolimatta säilyttäneet ajankohtaisuuden niitä tarkastaltaessa. Tutkielman ai- heena olevan FHIR-standardi on luonteva valinta tutkittavaksi aiheeksi, johtuen sen sen tuoreesta näkökulmasta ja edeltäjiensä laajasta käytöstä. 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.
Tämä tutkielma tarkastelee yhteentoimivuusstandardeja keskittyen HL7-organisaation kehitteillä olevaan FHIR-standardiin, jonka lisäksi sivutaan myös vanhempia HL7 standardeja. Tutkielman loppupuolella selvitetään FHIR-standardin soveltuvuutta ajanvarausjärjestelmän yhteentoimivuusstandardina. Onko uusimmasta FHIR-stan- dardista korvaamaan vanhoja jo vakiintuneita standardeja?
Tutkielman tarkoitus ja selvitettäviä asioita ovat:
1. Antaa yleiskuva FHIR-standardista ja sen suhteista aiempiin keskeisiin terveyden- huollon tietojärjestelmien standardeihin.
2. Lisäksi tarkoitus on kuvata FHIR-standardin keskeiset ominaisuudet ja kehitysvai-
Tutkielman aihe on melko uusi ja kirjoitetun kirjallisuuden määrä rajallinen, joten osa aiheen aineistosta otettiin mm. koulutusmateriaaleista ja FHIR-standardin kotisivuilta löytyvästä dokumentaatiosta. Rajallinen lähdekirjallisuus korostui nimenomaan FHIR-standardia käsittelevän materiaalin suhteen. Tutkielman alustusluvun käsittele- mistä asioista löytyi runsaammin myös kirjoitettua ja julkaistua materiaali (esimerkiksi artikkelit vanhemmista standardiversioista).
Tutkielma koostuu alun johdannon jälkeen tulevista luvuista, joista toisessa luvussa selvitetään tutkielmassa käytettyjä menetelmiä ja viitemalleja. Lisäksi luvussa esitel- lään tärkeimpien käsitteiden lisäksi tutkielmassa käytettyjä tutkimusmenetelmiä.
Kolmannessa luvussa kerrataan yhteentoimivuuden ja standardien merkitystä tervey- denhuollossa. Lisäksi esitellään REST ja miten se liittyy terveydenhuollon yhteentoi- vuusstandardeihin.
Neljännessä luvussa keskitytään FHIR-standardiin aloittaen sen taustasta ja nykyisestä kehitysvaiheesta. Luku kuvaa standardin keskeisiä ominaisuuksia, kuten resurssien ja koodistojen käyttöä. Sanastot ja toteutustavat huomioidaan myös. Lopuksi suoritetaan FHIR-standardin rakenteinen yhteenveto.
Viidennessä luvussa paneudutaan FHIR:iä hyödyntäviin rajapintamäärittelyihin. Ta- pauksessa ko. standardi valjastetaan käytännön tasolla ajanvarauspalvelujen rajapinto- jen määrittelyyn rajapintojen toteutusta varten. Luvussa tarkastellaan esimerkin kautta, tarjoaako FHIR tarvittavat komponentit ajanvarausjärjestelmän toteuttamiseen.
Kuudennessa luvussa on pohdinta ja viimeisessä seitsemännessä luvussa on yhteen- veto.
2 Menetelmät ja viitemallit
Luvun tavoitteena on kuvata tutkielmassa käytettäviä menetelmiä ja viitemalleja. Me- netelmänä käytetään kirjallisuuskatsausta sekä systemaattista arviointia rakenteista ar- viointimallia hyväksi käyttäen. Näiden pohjalta luodaan luvussa 4.8 konstruktiivinen esimerkki standardin soveltamisesta. Menetelmien ja viitemallien konteksti on tervey- denhuollon tietojärjestelmissä ja yhteentoimivuuden merkityksessä erityisesti standar- dien näkökulmasta.
Tutkielmassa on käytetty kirjallisuuskatsausta relevantin tutkimustiedon etsimiseen ja sopivan tutkimusmetodin löytämiseen. Kirjallisuuskatsaus ei ole systemaattinen, vaan sitä on sovellettu palvelemaan tutkielman tarkoitusta.
2.1 Kirjallisuuskatsauksen ja konstruktiivisen työn menetelmät
Kirjallisuuskatsaus on täsmällinen ja toistettavissa oleva metodi identifioimaan, kehit- tämään ja syntetisoimaan muiden tutkijoiden, tiedemiesten ja ammatinharjoittajien kir- jallisia töitä. Kirjallisuuskatsaus voidaan toteuttaa joko systemaattisena tai ei-syste- maattisena. Katsauksessa pyritään käyttämään alkuperäisiä lähteitä, jotta tiedonlaatu säilyy hyvänä ja relevanttina. (Fink, 2009)
Kirjallisuuskatsaus koostuu Arlene Finkin mukaan (Fink, 2009) seitsemästä eri vai- heesta:
1. Tutkimuskysymysten valinta.
2. Aineiston hakeminen tietokannoista, internetistä ja muista sopivista lähteistä.
3. Valitaan hakutermit ja luodaan hakulauseet.
4. Valitaan valintakriteerit, joiden mukaan tuloksia rajataan.
5. Valitaan metodi, jonka mukaan aineistoa käydään lävitse.
Tutkielmassa ei ole laajaa systemaattista kirjallisuuskatsausta, jossa olisi määritelty hakustrategiat yms. Sen sijaan tutkielmassa mukaillaan ja sovelletaan Arlene Finkin esittämän kirjallisuuskatsauksen rakenteen seitsemää vaihetta. Kyseinen teos valittiin tarkastelun pohjaksi, koska sitä on käytetty laajasti ja se soveltuu tässä tehtävään tut- kimukseen. Tutkielma aloitettiin valitsemalla aihe ja sille sopivat tutkimuskysymyk- set, joita vasten aihetta lähdettiin tarkastelemaan eri tietolähteitä hyväksikäyttäen.
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 lähdeluet- telot. Tutkielmaa tukevaa sisältöä löytyi runsaasti myös terveydenhuollon tietohallin- non kirjallisuudesta (health informatics) ja HL7-standardeista kertovasta kirjallisuu- desta.
Lukua kaksi varten jouduin tekemään melko runsaasti hakuja laajasta käsitteistöstä johtuen. Monet käsitteistä ja määritelmistä täydentyivät tutkielman edetessä. Muuta- mien käsitteiden osalta aineistoa etsin suoraan Google scholarista ja Nelli-hakupalve- lusta. Käsitteitä etsin käyttäen käsitteen englanninkielistä nimeä tai lyhennettä.
Toisessa luvussa käsiteltiin tietojärjestelmien yhteentoimivuutta ja HL7-standardeja.
Aihealueesta löytyi runsaasti kirjallisuutta, joten jouduin tarkentamaan hakulauseita seuraavin termein: ”hl7”, ”framework”, ”health informatics” ja ”interoperability”. Tä- män luvun kontribuutio koostuu käytettävien käsitteiden ymmärtämisestä, sekä tarvit- taessa niiden yhteensovittamisesta tai vaihtoehtoisista määritelmistä sopivimman va- litsemista.
Lukua kolme varten löytyi runsaasti painettua kirjallisuutta ja artikkeleita. Käytettyä materiaalia etsittiin pääasiassa Google scholaria käyttäen. Hakusanoina käytettiin lu- vun kolme otsikoiden englanninkielisiä vastineita. Luku koostuu melko selkeistä ali- lukujen muodostamista kokonaisuuksista, joten lähdeaineiston etsiminen oli siten suo- raviivaista. Kolmannessa luvussa tarkasteltiin yhteentoimivuutta ja siihen liittyvien
standardien kirjallisuutta. Luvun kontribuutio koostuu terveydenhuollon eri standar- dien välisestä ymmärryksestä ja kyvystä hahmottaa eri standardien oikean käyttötar- koituksen oikeassa vaiheessa.
Luku neljä keskittyy FHIR-standardin käsittelemiseen. Tämän osion aineiston etsimi- nen oli haastavaa. FHIR on standardina melko tuore ja viittauksia siihen löytyi suh- teellisen vähän. Painetusta kirjallisuudesta onnistuin löytämään lyhyen selonteon stan- dardista, mutta muutoin jouduin turvautumaan muutamaan Nellistä ja Google schola- rista löydettyyn artikkeliin. FHIR-standardiin liittyvien julkaisujen ollessa melko vä- häisiä, riitti monesti hakusanaksi pelkkä ”FHIR”.
Suurin osa käytetystä aineistosta löytyi FHIR-standardin internetsivuilta, jossa oli mm.
teknisiä määrityksiä runsaasti. Lisäksi käytin google-hakukoneella ja Slidesharesta löydettyä koulutusmateriaalia hyväkseni. Yhdeksi tärkeäksi aineistoksi osoittautui Su- hosen, Mykkäsen, Miettisen ja Virkasen Fast Health Interoperability Resources – FHIR- standardin kuvaus ja arviointi -dokumentti (Suhonen et al., 2013), joka loi poh- jan tekemälleni tutkielmalle.
Luvussa oma kontribuutio kohdistuu FHIR-standardin rakenteisen yhteenvedon li- säksi (luku 4.9) FHIR-standardin yleiskuvan ymmärtämisestä ja kyvystä soveltaa sen eri ominaisuuksia määrittelytasolta sovellustasoon asti.
Viides luku keskittyi pitkälti FHIR-standardin tekniseen toteutukseen. Luvussa ei enää nojauduta niinkään teoriapohjaiseen tietoon, vaan käytetään hyväksi FHIR-standardin teknistä lähdemateriaalia. Tätä FHIR-projektisivuilta löytynyttä teknistä määrittelyä sisältävää materiaalia käytettiin aineistona FHIR:iä hyödyntävän esimerkin määritte- lyssä. Merkittävä osa lähdeaineistosta löytyi FHIR-standardin projektisivuilta.
Aineiston valintakriteereiksi valitsin FHIR:iin liittyvässä aineistossa englannin- ja suomenkielisen aineiston, joka sai olla maksimissaan viisi vuotta vanhaa materiaalia.
tuottamaa materiaalia. Suomenkielistä koulutusmateriaalia käytin pääasiassa englan- ninkielisen materiaalin tukena.
Luvuissa 5.1 ja 5.2 tarkastellaan oman kontribuution tuloksena syntynyttä ajanva- rausesimerkkiä, joka on luotu konstruktiivisesti etsimällä sopivat standardista sovel- lettavat osat. Samoin sanomia, resursseja ja tiedonvälitysratkaisuja käsittelevät alalu- vut sisältävät omaa kontribuutiota ko. asioiden ymmärtämisen ja soveltamisen osalta.
2.2 Yhteentoimivuusstandardin arviointimalli
Tutkielma mukailee Mykkäsen ja Tuomaisen viitemallia, joka jaetaan yhdeksään eri osaan. Ensimmäinen kohta käsittelee standardin perustietoja sen hyödyntämistä ajatel- len. Kohdat 2-5 kuvaavat vastaavasti standardin yksityiskohtaisempia tietoja niin tie- don soveltamisen, semantiikan, toiminnallisuuden ja vuorovaikutuksien, sovelluksen infrastruktuurisista kuin teknisistä näkökulmista. Kohtia 6 ja 7 käytetään enemmän standardin mukautuvuuden, tarkkuuden ja kypsyyden arviointiin. Kohdassa kahdek- san käsitellään standardin toiminnallisuutta sovelluksissa ja järjestelmissä. Yhdeksäs kohta ottaa kantaa terveydenhuollon toimialuekohtaisiin ominaisuuksiin. (Mykkänen et al., 2008)
Yleisesti viitekehyksen avulla tarkastellaan standardia monista yhteentoimivuuden nä- kökulmista. Sen pääasiallinen käyttötarkoitus on luoda tiivistelmä standardin tavoitel- lusta lopputuloksesta, sovellettavuudesta, laadusta ja analyysi standardin käytettävyy- destä. Lopullinen ja tarkka standardin arviointimenettely perustuu tavallisesti projek- tin vaatimuksiin, standardin määrittelyyn ja sitä tukevaan materiaaliin. (Mykkänen et al., 2008)
Viitekehyksen käyttö voidaan nähdä laadullisena kokeiluna, jonka perusteella voidaan analysoida haluttuja ominaisuuksia. Vastaavasti viitekehystä käytetään yhteenvetojen tekemiseen päämäärän, tavoitteen ja sovellettavuuden perusteella. Lisäksi huomioi- daan yhteentoimivuuden näkökulmat yksityiskohtaisemmassa analysoinnissa. Sen
päätarkoitus on ohjata projektissa käytettävien standardien käyttämiseen siten, että so- velluksen integraation myötä saavutettaisiin komponentin parempi yhteentoimivuus.
(Mykkänen et al., 2008)
Seuraavassa luettelossa esitellään viitekehyksen eri tarkastelualueet:
1. Perustiedot ja kohdealue (Scope). Kuvataan sanallisesti standardin tarkoitus, kohdealue ja käyttötarkoitus halutussa ympäristössä. Lisäksi standardia on mahdollista arvioida suhteessa eri näkökulmiin: (Mykkänen et al., 2008)
a. enterprise b. information c. computation d. engineering
e. technology. (Mykkänen et al., 2008; Mykkänen et al., 2004)
2. Tieto ja semantiikka (Information and semantics). Kuvataan tiedonsiirron ele- mentit, parametrit ja muut tiedonsiirrossa käytettävät komponentit. Standar- dissa voidaan määritellä tietosisältöihin liittyviä seikkoja neljällä eri tavalla:
a. Standardissa määritetään sallitut arvot esimerkiksi tiettyyn tietokent- tään 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 yksilöi eri objektien semanttisia yhteyksiä.
d. Standardi sisältää metatason kuvauksen käyttäen erilaisia konkreettisia rajapintoja. (Mykkänen et al., 2008; Mykkänen et al., 2004)
3. Toiminnot ja sovellusten vuorovaikutus (Functionality and interactions). Stan- dardi kuvaa prosessit ja työnkulut tarkemmalla tasolla. Tarkastellaan standar- din määrittelemää toiminnallisuutta, käyttäytymistä ja organisoitumista. Toi- minnallisuudet jaetaan neljään osaan:
d. Tieto, kuvataan aktiviteetin rakenne ja sen vaikutukset tietojenkäsitte- lyyn. (Mykkänen et al., 2008; Mykkänen et al., 2004)
4. Sovellusarkkitehtuuri (Application infrastructure aspects). Kuvataan standar- din arkkitehtuuria hajauttamisen näkökulmasta ja kuinka standardin mukaan ratkaisujen eri komponentit liittyvät toisiinsa. Yksinkertaisimmillaan arkkiteh- tuuri kuvailee kuinka tieto liikkuu kahden ohjelman, palvelun tai käyttäjän vä- lillä. Hajautettua arkkitehtuuria käyttävissä järjestelmissä edellä mainitut toi- minnot voivat toimia useiden eri tietokantojen ja palvelinkomponenttien lisäksi erillisissä käyttöliittymissä. (Mykkänen et al., 2008; Mykkänen et al., 2004) 5. Tekninen näkökulma (Technical aspects). Kuvataan standardin tekninen näkö-
kulma tarpeeksi tarkalla tasolla. Tällöin otetaan huomioon esimerkiksi käytet- tävissä olevat teknologiat ja erilaiset tekniset ympäristöt. Tekninen puoli ko- rostuu erityisesti, kun integraatioratkaisuissa käytetään alustariippumattomia rajapinta- ja tiedonsiirtotekniikoita. (Mykkänen et al., 2008; Mykkänen et al., 2004)
6. Laajennettavuus (Flexibility, accuracy, extensibility). Kuvataan standardin kyky mukautua erilaisiin käyttötarkoituksiin ja käyttöympäristöihin. Standar- dille on tyypillistä yksiselitteisyys ja tarkkuus. (Mykkänen et al., 2008; Myk- känen et al., 2004)
7. Levinneisyys (Maturity, usage, official status). Standardit voidaan luokitella niiden hyväksymisasteen perusteella viralliseksi tai teolliseksi standardiksi.
Standardi voi olla suunnattu niin kansainvälisille (esimerkiksi ISO) markki- noille kuin alueellisillekin (esimerkiksi ANSI). Standardin kehityksessä on usein mukana myös kansainvälinen yleisö. Standardin kypsyys ja käyttö voi- daan jakaa neljään päävaiheeseen:
a. Aloitus, jolloin standardia kehitetään, mutta se on epävakaa ja hauras.
b. Edistynyt, jolloin ensimmäiset testaukset ja esittelyt on tehty.
c. Nopea edistys, jolloin standardi on saanut julkisuutta kasvavin määrin.
Standardin ympärille on tällöin ilmestynyt julkaisuja ja yleisöä.
d. Valmistuminen, jolloin enemmistö on mukana kehityksessä. Yhteen- toimivuus on kasvanut vakaan version myötä. (Mykkänen et al., 2008;
Mykkänen et al., 2004)
8. Järjestelmän elinkaari (System lifecycle). Elinkaari kertoo kuinka standardin on otettava huomioon järjestelmän elinkaaren eri vaiheissa.
a. Vaatimusmäärittely. Esimerkiksi lainsäädännön vaikutus standardiin.
b. Toimialueen analysointi. Tarkastellaan kohdejärjestelmää.
c. Määrittelyt. Otetaan kantaa tekniseen määrittelyyn, käyttöliittymät, teknologiat, arkkitehtuuri jne.
d. Käyttöönoton valmistelu. Varmistetaan kohdejärjestelmän sopivuus jne.
e. Käyttöönotto ja esittely. Asennetaan järjestelmä eri ympäristöihin.
f. Ylläpito ja versiointi. Järjestelmän hallinta, migraatio ja konfigurointi- järjestelmät. (Mykkänen et al., 2008; Mykkänen 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 tietojärjestelmiin standardi vaikuttaa tai se on tarkoitettu:
a. kommunikointi ja asiakasjärjestelmät (konsultaation ja itsehoito) b. hallinnointijärjestelmät (kuva-arkistointi, materiaalin tilaus) c. suorat hoitojärjestelmät (lääkelistaukset)
d. diagnostiikkajärjestelmät (kliininen päätöksen tuki).
(Mykkänen et al., 2008; Mykkänen et al., 2004)
Tutkielman aluksi käydään terveydenhuollon standardeja läpi yleisesti kartoittaen sa- malla terveydenhuollon kenttää järjestelmäkehittäjän näkökulmasta. Tutkielma paneu- tuu luvusta neljä lähtien FHIR-standardiin, jonka jälkeen päästään rajapintamääritte- lyyn luvussa viisi. Viitemallia sovelletaan tarkemmin luvussa 4.8, jossa esitellään FHIR-standardin rakenteinen yhteenveto. (Mykkänen et al., 2008)
2.3 Käsitteistö
2.3.1 Standardi
Project Management Institute (PMI) määrittelee standardin asiakirjaksi, joka on va- kiintunut ja tunnustettu. Se tarjoaa yleiseen ja toistuvaan käyttöön soveltuvia sääntöjä, ohjeita, ominaisuuksia, toimintoja ja tuloksia. Standardia käyttämällä on tavoitteena saavuttaa optimaalisin järjestys halutussa kontekstissa. Standardi on kehitetty proses- sissa, joka perustuu yhteiseen käsitykseen, avoimuuteen ja tasapainoon. (PMI, 2014) Hyväksytyllä standardilla on runko, joka sisältää säännöt, ohjeet tai ominaisuudet yh- denmukaista ja toistuvaa käyttöä varten eri tuotteissa, prosesseissa ja palveluissa.
Luonnollisesti eri prosessit ja tuotteet käyttävät erilaisia, käyttöön sopivia standardeja.
(PMI, 2000)
Terveydenhuollon standardit ovat keskittyneet monimutkaisen terveystiedon välittä- miseen turvallisesti ja tehokkaasti eri järjestelmien välillä. Nämä standardit mahdol- listavat myös potilastietojärjestelmien laajemman käytön siten, että sama tieto on käy- tettävissä niin ammattilaisen järjestelmässä, kuin potilaan itsehoitopalvelussa. (Kalra, 2006)
2.3.2 Yhteentoimivuus
IEEE määrittelee yhteentoimivuuden kyvyksi siirtää ja käyttää tietoa kahden tai use- amman järjestelmän tai komponentin välillä. Määritelmässä korostuu tiedonvaihto (to exchange) ja siirretyn tiedon käyttö (to use). (Fridsma, 2013; IEEE, 1990) Toisaalta yhteentoimivuus voidaan määritellä tuotteen kykynä toimia yhdessä muiden järjestel- mien ja tuotteiden kanssa ilman asiakkaan erityistä ponnistelua. Standardien käyttöön- ottaminen on mahdollistanut yhteentoimivuuden, joka voidaan jakaa kolmeen eri nä- kökulmaan: (IEEE, 2014) (Benson, 2012)
1. Tekninen yhteentoimivuus (technical interoperability) tai perustava yhteentoi- mivuus (foundational), jossa tavoitteena on saada tieto liikkumaan eri järjes- telmien välillä ilman tarvetta datan kuvaamiselle (Benson, 2012; HIMMS, 2013). Tähän yhteyteen sopii myös rakenteellinen yhteentoimivuus (structu-
ral), jolloin yhteentoimivuutta tarkastellaan tiedonvaihdon rakenteen ja muo- don pohjalta. Siirrettävän tiedon täytyy olla muutettuna siirrettävään muotoon.
(HIMMS, 2013)
2. Semanttinen yhteentoimivuus (semantic interoperability) tarkoittaa merkityk- sien yhteneväisyyttä. Tämä mahdollistaa dokumenttien ja sanomien siirtämi- sen järjestelmien välillä, sekä tietojen käyttämisen. Tällä varmistetaan lähettä- vän ja vastaanottavan järjestelmän yhtenäisyys, jotta tiedon merkitys pysyy siirrettäessä samana. Semanttinen yhteentoimivuus on yleensä riippuvainen toimialueesta ja kontekstista. (Benson, 2012; HIMMS, 2013) Semanttinen yh- teentoimivuus voi parantaa järjestelmien laatua, turvallisuus- ja kustannuste- hokkuutta, jotka ovat nykyaikaisen terveydenhuollon tietojärjestelmän vaati- muksia. (En, 2015; HIMMS, 2013)
3. Prosessien yhteentoimivuus (process interoperability) on saavutettu, kun ihmi- sillä on yhteinen käsitys liiketoiminnasta, toimintaympäristöstä ja toimintapro- sesseista (Benson, 2012).
2.3.3 Sähköiset potilastietojärjestelmät
Potilastietojärjestelmien sähköistäminen on ollut pitkä tie. Paperille kirjaamisesta on onnistuttu siirtymään tietokonepohjaisiin järjestelmiin, jotka tarjoavat huomattavia etuja verrattuna paperille kirjaamiseen. Tietokoneella käytettävät järjestelmät sisältä- vät lisäksi monipuolisia ominaisuuksia tiedon keräämisestä tiedon varastointiin.
(Coiera, 2015)
Sähköisten potilastietojärjestelmien tavoitteena on laskea terveydehuollon kuluja, eh- käistä hoitovirheitä sekä parantaa hoidon laatua ja saatavuutta. Lisäksi niiden etuja ovat mm. nopea tiedonhaku järjestelmistä halutuilla kriteereillä, sekä muut teknolo- gian tuomat edut niin digitaalisessa sisällöntuottamisessa kuin suurilla kosketusnäy- töillä työskennellessäkin. (Coiera, 2015; Nelson et al., 2009)
2.3.4 Terveydenhuollon tietojärjestelmät
Mitä ovat terveydenhuollon tietojärjestelmät? Määriteltäessä terveydenhuollon tieto- järjestelmiä, löydetään helposti erilaisia tietojärjestelmien luokitteluja. Pekka Turunen ja Aapo Immonen luokittelevat tietojärjestelmiä Terveydenhuollon tietojärjestelmien luokittelu arviointia varten -artikkelissa seuraavasti: (Turunen et al., 2004)
a) Asiakkaiden oman terveytensä ylläpitoa tukevat järjestelmät.
b) Vuorovaikutusta tukevat järjestelmät. Esimerkiksi sähköinen ajanvaraus ja po- tilaskontaktin suorittaminen tietokoneen välityksellä.
c) Konsultaatiojärjestelmät. Potilaan ja hoitohenkilökunnan vuorovaikutusta tu- kevat työkalut.
d) Päätöksentekoa tukevat järjestelmät. Päätöksen tueksi tietoa tuottavat järjestel- mät.
e) Prosessia tukevat järjestelmät. Terveydenhuollon operatiivisia toiminnanoh- jausjärjestelmiä.
f) Talouteen liittyvät järjestelmät. Rahavirtaan liittyvät järjestelmät.
g) Valmisteluun liittyvät järjestelmät. Potilaan operoinnin valmisteluun liittyvät työkalut. Esimerkiksi ennen leikkausta suoritettavat tarkistuslistat.
h) Hallinnon työkalut. Esimerkiksi terveydenhuollon päättäjiä tukevat ja tilastoja kokoavat järjestelmät. (Turunen et al., 2004)
2.3.5 EHR
EHR (Electronic health record) eli sähköinen potilaskertomus on keskeinen työkalu osana potilaan hoitoa. Sen avulla potilasta hoitavat ammattilaiset kommunikoivat kes- kenään ja jakavat tietoja potilaasta ja hänelle tehdyistä tutkimuksista ja toimenpiteistä.
(Coiera, 2015)
Sähköinen potilaskertomus on suojattu ja turvallinen sovellus (kts. kuva 1), jonka avulla käyttäjä voi tarkastella, muokata ja jakaa potilaan terveystietoja. Lisäksi se on palveluntuottajan vastuulla oleva tuote, johon potilaalla ei yleensä juurikaan ole oi- keuksia. (Nelson et al., 2009)
Kuva 1: Sähköinen potilaskertomus on monipuolinen työkalu. (Coiera, 2015) 2.3.6 PHR
PHR:ssä (Personal Health Record) eli henkilökohtainen terveyskansio tukee sähköistä potilaskertomusta tarjoten potilaalle mahdollisuuden lisätä järjestelmään itseään kos- kevia tietoja. Terveyskansio voi sisältää potilaan itse kirjoittamia muistiinpanoja, ko- kemuksia ja arkipäiväisiä tietoja. Kansioon voidaan lisätä myös varsinaisia hoitoa tu- kevia tietoja, kuten tieto rokotuksista, allergioista ja mittaustuloksista. (Coiera, 2015) 2.3.7 Muut keskeiset käsitteet
Tässä aliluvussa kerrotaan muiden keskeisten käsitteiden merkitys.
2.3.7.1 Tietomallit
Tietomallien (information model) tarkoitus on kuvata käytettäviä tietojoukkoja ja mää- ritellä niiden sisältöjä ja rakennetta. Tietomallin avulla voidaan taata päätösten perus- tuvan oikeelliseen tietoon. (Coiera, 2015)
2.3.7.2 Sovellusarkkitehtuuri
Sovellusarkkitehtuuri (application architecture) on arkkitehtuurinen näkökulma, jonka pohjalta tehdään sovelluksen arkkitehtuuria koskevat päätökset, ohjeet ja tarvittavat standardit, joita tarvitaan toimivaan komponenttipohjaisen järjestelmän luomiseen.
Arkkitehtuurissa voidaan ottaa huomioon esimerkiksi tarve järjestelmän skaalautuvuu- delle ja siten otetaan jo varhaisessa vaiheessa virtualisointi mukaan sovellusarkkiteh- tuurissa. (Herzum et al., 1999)
2.3.7.3 Rajapinta
Rajapintojen käyttö on komponettipohjaisissa järjestelmissä käytettävyyden kannalta avainasemassa. Rajapinta toimii kahden eri komponentin tai komponentin ja loppu- käyttäjän välissä mahdollistaen tiedon liikkumisen molempiin suuntiin näiden välillä.
Komponentit ovat uudelleenkäytettäviä ja monesti ne muodostavat monimutkaisen ko- konaisuuden. (Mykkänen, 2007)
Rajapinta sisältää mm. seuraavia käyttötarkoituksia:
Rajapinta voidaan jakaa useaan eri komponentin kanssa.
Rajapinta mahdollistaa komponentin käyttämisen, kunhan komponentti on käyttäjän saavutettavissa.
Rajapinta mahdollistaa yhteentoimivuuden tarjoamalla sen toiminnallisuuden ja tiedot, jotta komponentin käyttäminen onnistuu.
Rajapinnan käyttäminen mahdollistaa ohjelmiston hajautetun käyttämisen.
(Mykkänen, 2007)
Koska yksi EHR-standardi ei voi tarjota terveydenhuollon järjestelmälle kaikkia sen tarvitsemia toimintoja, tarvitaan rajapintoja standardien välillä. Rajapinta mahdollistaa
kommunikoinnin kahden, tarvittaessa hyvin erilaisen tietojärjestelmän välillä. Tervey- denhuollossa tämä tarkoittaa esimerkiksi potilastiedon siirtymistä ajanvaraus- ja las- kutusjärjestelmien välillä. (Nelson et al., 2009)
2.3.7.4 Sanomarajapinnat
Järjestelmien väliset sanomat liikkuvat sanomarajapintaa käyttäen eri järjestelmien vä- lillä. Sanomarajapintojen käyttö mahdollistaa suurten moninaisten tietojoukkojen siir- tämisen eri järjestelmien välillä. HL7 v2 -standardeihin pohjautuvat sanomarajapinnat ovat maailman eniten käytettyjä rajapintoja sanomien välittämiseen terveydenhuollon järjestelmissä. (Dogac et al., 2007)
2.3.7.5 Palvelurajapinnat
Palvelurajapinnat varmistavat eri komponenttien integroitumisen osaksi järjestelmää.
Tällaisia komponentteja ovat esimerkiksi terminologiaan ja oikeuksien hallintaan liit- tyvät komponentit. (HL7, 2004)
2.3.7.6 Profiilit
Profiilit rajoittavat standardien käyttöä tarkasti määritellyn tarpeen mukaan käyttökoh- teessa tai käyttötapauksessa. Näin standardi saadaan profiilia käyttämällä tarjoamaan halutut toiminnollisuudet kohdesovelluksessa. Tämä mahdollistaa ”plug and play” - tyyppisen käytön yhteentoimivuusstandardeissa. Esimerkiksi WS-I on tällainen tekni- nen profiili, joka mahdollistaa teknisesti rajapintojen käytön. (Mykkänen, 2007) 2.3.7.7 Koodistot ja luokitukset
Luokittelun tarkoitus on jakaa asioita eri ryhmiin ja luokkiin sisältöjen perusteella.
Koodistojen tarkoitus on yksilöidä sisältöjä koodaamalla ne ihmisen ymmärtämässä muodossa, jolloin sitä voidaan käyttää helpommin tiedon siirtämiseen tietojärjestel-
2.3.7.8 Terminologiat
Terveydenhuollon yhteisellä terminologialla kyetään selittämään monimutkaiset ja kontekstiriippuvaiset asiat, vähentäen väärinymmärryksen mahdollisuutta. Kun esi- merkiksi henkilö A ja henkilö B keskustelevat potilaasta, on hyvin tärkeää, että mo- lemmat ymmärtävät toisiaan. (Hovenga et al., 2010)
3 Terveydenhuollon sovellusten yhteentoimivuusstan- dardit ja REST
Tämän luvun tavoitteena on perustella yhteentoimivuuden merkitys terveydenhuollon tietojärjestelmissä. Luvun toisena päämääränä on esitellä keskeisimpiä terveydenhuol- lon tietojärjestelmien yhteentoimivuusstandardeja.
3.1 Yhteentoimivuuden ja standardien merkitys terveydenhuollossa
Potilastietojärjestelmien yhteentoimivuus tuo organisaatiolle tehokkuutta ja taloudel- lisuutta ylläpitokustannuksien ja ihmistyövoiman vähenemisen myötä. Käytännössä yhteentoimivuuden parantuminen näkyy esimerkiksi parempana potilaiden tiedon ha- kuna, niin kliinisessä kuin hallinnollisessa työssä. Vastaavasti potilastiedon automaat- tinen siirto eri järjestelmien välillä nopeuttaa tiedon siirtymistä ehkäisten mahdollisten virhetilanteiden syntymistä. (Eichelberg et al., 2013)
Yhteentoimivuusvaatimukset ovat yleensä tärkeimpiä vaatimuksia terveydenhuollon järjestelmien vaatimusmäärittelyissä. Ammattilaiset ovat lisäksi havainneet järjestel- mien yhteentoimivuuden parantaneen potilasturvallisuutta, johtuen tuoreimmasta ja parhaasta saatavilla olevasta potilastiedosta (Bender et al., 2013). Terveydenhuollon standardit ovat yksi osatekijä parantamaan terveydenhuollon järjestelmien käytettä- vyyttä. Standardeja käyttämällä voidaan edistää turvallista ja laadukasta hoitoa. (Ben- son, 2012)
Potilastietojärjestelmät on laajalti digitalisoitu. Nykyisin potilaat liikkuvat paikkakun- nalta toiselle ja käyvät julkisen terveydenhuollon lisäksi myös yksityisissä hoitopai- koissa. Tämä on luonut tarpeen sähköiselle potilastietojärjestelmälle. Potilastiedon saatavuuden merkitys korostuu potilaan käytettäessä eri toimipaikkoja. Lisäksi poti-
Standardien käytön kautta pyritään vähentämään riskejä ja kustannuksia, parantamaan prosessien laatua, sekä lyhentämään projektien toteutusaikoja. (Bender et al., 2013;
Coiera, 2015)
3.2 HL7-standardit
HL7 on riippumaton ja voittoa tavoittelematon järjestö, joka perustettiin Yhdysval- loissa 1987. Järjestön tavoitteena on edistää tiedon keräämistä, siirtämistä ja integroi- mista eri tietojärjestelmien välillä. (Coiera, 2015; Eichelberg et al., 2013; Nelson et al., 2009) HL7 tarjoaa monipuolisen viitekehyksen ja standardiperheen terveydenhuollon tietojärjestelmien yhteensopivuutta ajatellen. HL7-standardien käyttö globaaleissa terveydenhuollon järjestelmissä on merkittävää. (Coiera, 2015; Nelson et al., 2009) Monista kehitetyistä standardeista sähköisten dokumenttien ja viestinvälityksen stan- dardit ovat käytetyimpiä kliinisissä sovelluksissa. Kyseiset standardit kuvaavat kliinis- ten dokumenttien rakenteen ja niiden väliset semanttiset suhteet. Standardeista esi- merkiksi HL7 CDA kehitettiin dokumenttien, kuvien ja erilaisten raporttien siirtämi- seen eri järjestelmien välillä. (Coiera, 2015)
Uudet tuloillaan olevat HL7 -standardit kehitetään ensin kokeilustandardina (DSTU), joissa niitä testataan ja jatkokehitetään. Vasta tämän jälkeen standardit voidaan hyväk- syä lopullisiksi standardeiksi. (Benson, 2012; HL7, 2015b)
Terveydenhuollon tietojärjestelmissä yleisimmin käytettävät HL7 -standardit ovat HL7 v2, HL7 v3 standardiperhe ja dokumenttistandardi CDA. Huomion arvoista on, että HL7 julkaisee myös muunkin tyyppisiä standardeja. Näitä ovat esimerkiksi poti- laskertomusjärjestelmissä käytettävä HL7 EHR-S FM ja henkilökohtaisissa terveys- kansiojärjestelmissä käytettävä PHR-S FM. (HL7, 2015k; HL7, 2015j)
3.2.1 HL7 v2 sanomastandardit
HL7 v2 on yksi suosituimmista terveydenhuollon tietojärjestelmissä potilastiedon vä- litykseen käytettävä yhteentoimivuusstandardi (Eichelberg et al., 2013). Esimerkiksi
Yhdysvalloissa valtaosa sairaaloista käyttää HL7 v2 -standardiin pohjautuvia potilas- tietojärjestelmiä. (Benson, 2012)
HL7 versio 2 standardeja on kehitetty yli 25 vuotta vuodesta 1988 lähtien. Standardi on kehittynyt valtavasti tuona aikana tuoden paljon uusia ominaisuuksia. Sen etuihin kuuluu monipuolisuuden ja joustavuuden ohella yhteensopivuus niin eteen- kuin taak- sepäin (Benson, 2012). HL7 version 2 standardeja on Suomessa käytetty laajasti esi- merkiksi terveyskeskusten ja sairaaloiden sisällä järjestelmien välisissä integraati- oissa. (Paakkanen, 2007)
HL7 versio 2 ei ole kuitenkaan täydellinen standardi. Se ei kata täydellisesti kaikkia käyttötilanteita eikä se tuo täydellistä yhteentoimivuutta potilastietojärjestelmien vä- lille. Sen taustalla ei ole tarpeeksi tarkasti määriteltyä tietomallia, ja sen monien kent- tien määritelmät ovat epämääräisiä. Tämän vuoksi standardi on joustava, mutta yhtei- set käytännöt on sovittava tietoa välitettävien järjestelmien kesken, jotta toimiva ko- konaisuus saataisiin aikaiseksi. Tämän ongelman ratkaisemiseksi julkaistiin HL7 ver- sio 3. (Benson, 2012; Eichelberg et al., 2013)
HL7 versio 2 standardeihin kuuluu myös suuri joukko koodistoja ja luokituksia, joita sanomapohjaisessa tiedonvälityksessä käytetään. Ne ovat omalta osaltaan merkittä- vässä roolissa järjestelmän käytettävyyttä 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 tietosisällön mallinnus, joka jätti hyvin vähän sijaa valinnaiselle ja epärakenteiselle tiedolle. Mallin tavoite oli tarjota stan-
HL7 v3 luotiin korvaamaan v2, mutta sen käyttöönotto ja käyttö on koettu vaikeaksi eri projekteissa. HL7 v3 ei ole onnistunut syrjäyttämään v2:sta, joten vanhempi stan- dardi jatkoi terveydenhuollon tietojärjestelmien tärkeimpänä yhteentoimivuusstandar- dina. (Benson, 2012)
HL7 v3 toi mukanaan rajoitetut tietomallit, joita voitiin luoda RIM-mallin pohjalta rajatuin ominaisuuksin myös tarkempiin kohdealueisiin. Näin sopivia ja rajattuja mal- leja voitiin luoda erilaisia käyttötapauksia varten. Malleilla pystyttiin takaamaan stan- dardin oikeaoppinen käyttö yhteentoimivuuden takaamiseksi. Tällaisia 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 käyttää ja ymmärtää. (Benson, 2012)
HL7 versio 3 standardi toimii viestinvälitystasolla yleensä sanomapohjaisesti XML- skeemaa hyväksikäyttäen. Mainitsemisen arvoisia teknologioita on XML:ssä käytet- tävä Implementation technology specification (ITS), joka kuvailee kuinka yksittäinen RMIM- tai HMD-mallin mukainen viesti muodostetaan XML-skeeman mukaiseen muotoon. Lisäksi HL7 versioon 3 kuuluu myös suuri joukko koodistoja ja luokituksia, joita sanomien tarkentamisessa ja toteuttamisessa käytetään. (Benson, 2012)
2000-luvulla HL7 v3:sen jälkeen esiteltiin uusi, monipuolisempi ja ketterämpi HL7 FHIR -standardi, jonka oli tarkoitus vastata nykyajan tarpeisiin (Bender et al., 2013;
Benson, 2012). Tämän tutkielman myöhemmät luvut keskittyvät FHIR-standardiin.
3.2.3 CDA
HL7 CDA on XML-pohjainen standardi, jota käytetään potilasdokumenttien semant- tiseen ja rakenteiseen määrittelyyn. CDA:n on maailman laajimmin käytetty HL7 v3:sen sovellus potilasdokumenttien välitykseen. Sen tarkoitus on kuvailla esimerkiksi potilaskertomuksen rakennetta tiivistelmä- ja muistiinpano-osioineen mahdollistaen
tiedon liikuttamisen järjestelmien välillä. Siirrettävä tieto voi myös 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, käy- tössä ja tuhottu. Dokumentin sisältö on pysyvää, kunnes se päätetään tuhota.
Ylläpidettävyys (stewardship), jolloin dokumentti on aina jonkin henkilön tai organisaation vastuulla, joka huolehtii dokumentin arkistoinnista, kopioin- nista, edelleen lähettämisestä ja lopulta tuhoamisesta.
Kokonaisuus (wholeness), jossa dokumentti on täydellinen sisältäen metatie- dot dokumentin luojasta, käyttötarkoituksesta ja ajankohdasta.
Luettavuus (human readable), jolloin ihminen pystyy lukemaan ja ymmärtä- mään dokumentin siitä huolimatta, että dokumentti olisi tietokoneen ymmärtä- mässä muodossa (XML).
Tunnistautuminen (Potential for authentication), jolloin dokumentit voidaan allekirjoittaa fyysisesti tai sähköisesti. (Benson, 2012)
HL7 CDA ei ole kaikenkattava EHR-standardi, koska se kuvailee vain osan EHR-ark- kitehtuurista. Vaikka sen varaan ei voida rakentaa kokonaista järjestelmään, on se kui- tenkin tärkeä osa EHR:ää ja on yhteentoimiva vastaavien rakenteiden EN 13606 ja openEHR kanssa. (Eichelberg et al., 2013)
3.3 DICOM
DICOM-standardia käytetään lääketieteellisten kuvien tallentamiseen ja siirtämiseen.
Siitä on tullut lääketieteellisen kuvantamisen tiedonsiirrossa ainoa tosiasiallinen stan- dardi. Standardi kuvailee tietorakenteet ja palvelut toimittajariippumattomia kuvasiir- toja varten. DICOM-standardi ja sen edeltäjää aloitettiin kehittämään vuodesta 1983.
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 kehittivät yhdessä DICOM ja ISO -järjestöt. Standar- dilla kuvataan verkkopalvelua, jolla voidaan hakea DICOM-objekteja kuten kuvia ja raportteja http:n ja https:n yli suoraan palvelimelta. Käytännössä web-palvelin ja asia- kasohjelmisto käyttävät yksilöllisiä tunnuksia turvallisen lähettämisen takaamiseksi.
Pelkän kuvan lisäksi voidaan palvelimelle lähettää mukana myös muita tietoja tai vas- taavasti taata kuvan tietosuoja lähettämällä se tarvittaessa ilman siihen liitettyä suoraa potilastietoa. (Eichelberg et al., 2013)
DICOM:in lisäosa, Structured Reporting (SR) on rakenteistettu malli, jonka perus- teella lääkärinlausunnot muokataan varsinaiselle DICOM-standardille sopivaksi.
Standardi julkaistiin vuonna 2000 varsinaisen DICOM-standardin komponentiksi, joka kattaa lääkärinlausunnot ja muun kliinisen tiedon. Malli on hyvin mukautuva pys- tyessään käsittelemään niin vapaamuotoista tekstiä, kuin myös täysin rakenneistettua tietoa koodistoineen ja sanastoineen. Pelkästä mallista ei luultavasti tule virallista EHR-standardia koskaan, johtuen sen rajatuista käyttömahdollisuuksista. Kuitenkin osana varsinaista DICOM WADO -standardia se toimii erinomaisesti. DICOM:ia ei juurikaan käytetä kuvantamisen ulkopuolella, mutta yhdessä SR-mallin kanssa siitä on tullut hyvin merkittävä kuvantamisessa käytettävä standardi kaupallisia sovelluksia myöten. (Eichelberg et al., 2013)
3.4 IHE ja IHE-profiilit
Integrating the Healthcare Enterprise (IHE) on voittoa tavoittelematon järjestö, 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 työryhmiä Euroopassa ja Japanissa. IHE:n ta- voitteena on edistää terveydenhuollon tietoresurssien integraatiota. (Eichelberg et al., 2013; Oosterwijk, 2006; Suhonen et al., 2013)
IHE ei järjestönä itse kehitä yhtään standardia vaan se valikoi ja suosittelee sopivia standardeja tiettyihin käyttötapauksiin. IHE pyrkii kehittämäänsovellusprofiileja stan- dardeista, jotka mahdollistavat yksinkertaisen järjestelmäintegroinnin. Teknisen työn tulokset julkaistaan valmiina toteuttavissa olevina paketteina, jotka julkaistaan IHE Technical Framework -julkaisuissa vuosittain. (Eichelberg et al., 2013; Suhonen et al., 2013) IHE tekee läheistä yhteistyötä myös 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 välillä. Eri- tyisesti RIS:iä (Radiology Information System), PACS:ia (Picture Archiving And Communication System) käyttävät tahot ovat tukeneet EHI:n kehitystä. Samoin monet potilastietojärjestelmä tuottajat ovat tätä kehitystä tukeneet. (Eichelberg et al., 2013;
Oosterwijk, 2006; Suhonen et al., 2013)
IHE-standardi on tekninen viitekehys, joka sisältää kokoelman määrityksiä käyttöön- otosta. yhteentoimivuudesta ja integraatio-ongelmista. (Oosterwijk, 2006) IHE-profii- lit eivät itsessään ole standardeja, vaan profiilin tarkoituksena on kertoa kuinka eri standardeja käytetään yhdessä. Eli profiililla voidaan sitoa useita palasia monesta eri standardista. Profiilia käyttäen konfliktit eri asetuksia sisältävien standardien välillä saadaan estettyä. (IHE, 2016a; Oosterwijk, 2006)
IHE käyttää IT Infrastructure Technical Framework:ia (ITI TF) kuvaamaan standar- dien tarkempaa integraatiota teknisellä tasolla, jotta tiedon välitys järjestelmien välillä olisi sujuvaa. Technical Framework:n kuvaamia terveydenhuollon sovelluksia kutsu- taan aktoreiksi (actors). IHE-profiileja löytyy monia ja niistä keskeisimpiä ovat esi- merkiksi: (IHE, 2016b; Oosterwijk, 2006)
Ajatettu työnkulku (scheduled workflow), jonka tavoitteena on eri toimialui- den yhteentoiminnan takaaminen.
Johdonmukaisesti esitettävät kuvat (Consistent Presentation of Images) mah- dollistavat kuvien monipuolisen käytön eri toimialueissa.
Profiili, jolla mahdollistetaan pääsy radiologiseen tietoon.
Profiili, jolla parannetaan potilastiedon turvallista käsittelyä. (IHE, 2016b;
Oosterwijk, 2006)
IHE-profiileja testataan erityisissä connectathon-tapahtumissa, joissa eri toimijat ym- päri maailman testaavat IHE:n integrointiprofiileja heidän järjestelmissään 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 määrittelee rajoitukset niin yhtenäisen käyttöliittymän, suorituskyvyn, skaalautuvaisuuden kuin muunnelta- vuudenkin puolesta. REST:llä pyritään tuottamaan mahdollisimman hyvin toimivia web-sovelluksia. REST:lle on ominaista, että sen arkkitehtuurista tyyliä, dataa ja toi- mintoja pidetään resursseina, joita käytetään URI:n (Uniform Resource Identifier) kautta. Käytännössä URI toimii normaalin linkin tavoin web-sivulla. REST käyttää tyypillisesti tietoliikenneprotokollana HTTP:tä ja se on suunniteltu client/server -ark- kitehtuuriksi, jossa resurssit siirtyvät standardisoitujen rajapintojen ja protokollien kautta. Restful taasen tarkoittaa REST:n vaatimukset täyttävää palvelua. (Oracle, 2015)
Jotta web-sovellukset saataisiin toimimaan yksinkertaisesti, kevyesti ja nopeaksi, täy- tyy sen toteuttaa seuraavat periaatteet:
Resurssien tunnistus URI:n kautta. RESTful -palvelu sisältää joukon resurs- seja, joiden perusteella tapahtuu asiakkaiden välisen vuorovaikutuksen tunnis- tus. Resurssit tunnistetaan URI:n perusteella.
Yhtenäinen käyttöliittymä. Resursseja ohjataan käyttäen 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.
Itseään kuvailevat viestit. Resurssit on irrotettu kuvauksesta, jotta niiden sisäl- töön voidaan käyttää useammassa formaatissa. Näitä ovat esimerkiksi HTML, XML, PDF, JPEG ja pelkkä teksti. Resurssin metatietoja käytetään mm. väli- muistin hallitsemiseen, siirtovirheiden löytämiseen ja oikean esitysformaatin löytämiseen. Samalla tapaa voidaan hoitaa myös käyttäjän tunnistus ja kulun- valvonta.
Tilalliset vuorovaikutukset hyperlinkkien kautta. Jokainen vuorovaikutus re- sursseissa on tilaton, jolloin viestipyynnöt ovat muista riippumattomia. Tiloja voidaan vaihtaa URI:n uudelleenkirjoittamisella, evästeillä ja piilotetuilla lo- makkeen kentillä. Tila voidaan upottaa osaksi vastausviestiä osoittaakseen tu- levat vuorovaikutukset. (Oracle, 2015)
4 FHIR-STANDARDI
Tämän luvun tarkoituksena on esitellä FHIR-standardin perusteet ja sen REST-pohjai- nen toteutustapaa. Aluksi käydään lävitse FHIR-standardin yleiskuva, jonka jälkeen esitellään REST:n toiminnallisuus. Lopulta syvennytään 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 käsitteet alikategorisoimalla. (Bender et al., 2013)
FHIR on julkaissut manifestin, jossa luetellaan FHIR:n kehityksessä käytettävät peri- aatteet:
painopiste on kehittäjissä
tavoitteena yhteisten skenaarioiden tukeminen pyrkimys käyttää ristiin eri alojen web-teknologioita yhteentoimivuuden pohjalla luettavuus
sisältö vapaasti saatavissa
tuki usealle toimintatavalle ja arkkitehtuurille
käyttää hyväksi havaittuja hallintotapoja. (Quinn, 2014c) 4.2 FHIR:n kehittyminen
HL7 on ollut kehittämässä terveydenhuollon tiedonvaihtostandardeja yli 20 vuotta.
Nyt HL7 v2, v3, RIM ja CDA:n pohjalta on lähdetty kehittämään HL7 -organisaation uusinta FHIR-standardia, joka pyrkii korjaamaan aikaisempien versioiden heikot koh- dat ja tarjoamaan nykyaikaista standardia. FHIR:iä voidaan tulevaisuudessa käyttää
joko järjestelmän ainoana tiedonsiirtostandardina tai se voidaan ottaa jo ennestään käytössä olevan standardin rinnalle. (Coiera, 2015; Quinn, 2014b)
FHIR:n päämääränä on yksinkertaistaa järjestelmiä integraation tärkeys silmällä pi- täen. Se hyödyntää jo olemassa olevia loogisia ja teoreettisia malleja tarjotakseen joh- donmukaisen, helpon toteutustavan ja luotettavan mekanismin potilastietojärjestel- mien tiedonvaihdolle. FHIR:ssä on sisäänrakennettuna toiminnot HL7 RIM:lle ja muille tärkeille sisältömalleille, 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 heinäkuussa 2011. Ensimmäinen luonnos äänestys- kierrokselle saatiin aikaiseksi alkusyksystä 2012. Heti perään järjestettiin ensimmäi- nen Connectathon-tapahtuma, jossa kehittäjät pääsivät käytännössä tutustumaan stan- dardiin ja testaamaan sitä. Vuoden 2013 syksyllä järjestettiin ensimmäinen äänestys- kierros eli DSTU (Draft Standard For Trial Use). (Quinn, 2014a)
4.3 Resurssiajattelu FHIR-standardissa
FHIR:ssä kaikki siirrettävä tietosisältö on kuvattu resurssiksi. Jokainen resurssi sisäl- tää yleisen määrittelyn tietotyyppeineen. Resurssi on tiedon instanssi, joka on talletettu tai siirretty. Käytännössä resurssi koostuu metatiedot sisältävästä ja ihmisen luetta- vissa olevasta xml-muotoisesta dokumentista. (HL7, 2015a; Quinn, 2014b)
Resursseja voivat olla esimerkiksi hallinnoitava potilas, lääkäri, organisaatio, sijainti tai lasku. Esimerkiksi ohjelmistoympäristöön liittyviä resursseja ovat taasen dokumen- tit, viestit ja profiilit. Resurssiajattelun ulkopuolelle jäävät liian yksityiskohtaiset ja laajat kokonaisuudet, kuten sukupuoli, potilastietojärjestelmät ja yksittäiset arvot.
(Quinn, 2014c)
4.3.1 Resurssin vaatimukset
FHIR:llä on erilaisia resursseja tiedon vaihtamiseen ja tallentamiseen niin kliinisessä kuin hallinnollisessa käyttöympäristössä. Standardin resurssit koostuvat useammasta kokonaisuudesta:
Sillä on tiedossa oleva identiteetti (url), johon se voidaan kohdistaa.
Ohjeenmukainen määrittely tiettynä resurssityyppinä.
Sisältää resurssityypin kuvaamat rakenteistetut tieto-osat.
Sisältää selkokielisen XHTML-muotoisen kuvauksen resurssin sisällöstä.
Sisältää yksilöillyn versioinnin, joka muuttuu sisällön muuttuessa.
Resurssi on validi, jos siltä löytyy edellä mainitut säännöt ja se on määritelty vaati- muksissa XML- tai JSON -sääntöjen mukaan. Resursseja voidaan määrittää myös mui- den kuin edellä mainittujen kriteerien perusteella. (HL7, 2015a)
4.3.2 Resurssin sisältö (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 määritelty käyttäen XML:n rakennetta (HL7, 2015a; McKenzie, 2013).
Laajennukset, voivat sisältää valinnaista lisätietoa laajennuksesta. (HL7, 2015a)
Ihmiselle lukukelpoinen selostus resurssin sisällöstä. (HL7, 2015a)
Sisällytetyt resurssit, lisäresursseja, jotka muodostavat tunnisteen ja resurssin tilan. (HL7, 2015a)
Metadata kuvaa tärkeää tietoa resurssista, joka ei kuitenkaan ole osa resurssin sisältömallia. (HL7, 2015a; McKenzie, 2013)
Tunnisteita käytetään resurssien yhteydessä. Ne määrittelevät valinnaisten toi- mintojen käyttämistä, kuten turvallisuutta, työnkulkua jne. (HL7, 2015a;
McKenzie, 2013)
Elementin nimi, tyyppi, kardinaliteetti ja määritelmä. (McKenzie, 2013) Resurssin perusrakenne koostuu kolmesta osasta. Extension-> Narrative -> De- fined Structured Data. Perusrakenteen voi havaita kuvasta 2. (Quinn, 2014c)
Edellä olevassa kuvassa on resurssi eroteltu kolmeen eri osaan värin perusteella. Ylim- pien extension-tagien sisään on merkattu laajennuksessa määritetty viite. Punasävyt- teisten text-tagien välissä on ihmisen luettavissa oleva tiivistelmä ja alimpana on var- sinainen resurssin sisältö. Tässä esimerkissä MRN, Name, Gender, Date of Birth ja Provider -kohdat sisältävät tallennettavaa tietoa. (McKenzie, 2013) Edellä mainitut elementit tulisi olla esiteltynä esitetyssä järjestyksessä (HL7, 2015a).
4.3.3 FHIR-Profiilit
FHIR:n yhden tai useamman resurssin rajoitusten ja laajennuksien määrittelyä kutsu- taan profiloinniksi (kts. kuva 3). Sen avulla voidaan määritellä uusia hakutermejä, sa- nomia jne. (HL7, 2015d; McKenzie, 2013)
Profiileissa on kolme eri osaa:
Metatiedot, jotka kuvaavat profiilia ja tukevat hakutoimintoja.
Rakenteet, jotka määrittelevät ja kuvaavat kuinka resursseja ja tietotyyppejä käytetään.
Laajennusmääritykset, jotka kuvaavat millaisia laajennuksia rakenteissa voi- daan käyttää. (HL7, 2015d)
Kuva 3: Esimerkki FHIR:n profiilista (McKenzie, 2013).
4.4 Koodistojen käyttö
Monet FHIR:n resurssit käyttävät koodistoja, jotka voidaan jakaa yhteen yksinkertai- seen ja kahteen monimutkaiseen datatyyppiin. Yksinkertaisissa koodistoissa (code) elementit sidotaan koodit sisältävään arvojoukkoon, tai johonkin muuhun ulkoiseen
Monimutkaisissa tyypeissä (CodeableConcept ja Coding) elementit sidotaan käytettä- viä koodattuja arvoja sisältävään listaan. Arvojoukkojen monimutkaisuuden ja koon vuoksi käyttöä ei määritellä skeematasolla, vaan siihen käytetään Value Set -resurssin sääntöjä. (HL7, 2015c; McKenzie, 2013)
4.5 Tietotyypit
FHIR määrittelee resurssielementeissä käytettävät 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 uudelleenkäytettäviä elementtiryhmiä. Tietotyypit esitetään 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 päivämäärät (date). Aliominai- suudet eivät ole mahdollisia, mutta laajennukset ovat sallittuja muiden resurssien ja tietotyyppien tapaan. Tarkemmat rajoitteet taasen kuvataan FHIR-määrityksessä. Yk- sinkertaiset tietotyypit pohjautuvat w3c-skeemaan ja ISO-määritellyihin tietotyyppei- hin. (HL7, 2015e; Suhonen et al., 2013)
Kuva 5: Yksinkertaiset tietotyypit (HL7, 2015e).
Vastaavasti monimutkaiset tietotyypit esitetään XML- ja lapsielementteinä (kts. kuva 6). Tietotyypin käyttö määrittää tietotyypille nimen ja monimutkaisten tietotyyppien elementtien arvoja ja rajoituksia voidaan säädellä niiden profiloinnilla. (HL7, 2015e;
Suhonen et al., 2013)
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 käytettyjen resurssien sisältö pysyy samana, jolloin erilaisten toteutustapojen välinen tiedonsiirto on suoraviivaista. Esi- merkiksi ”Vastaanota laboratoriotulos sanomassa” tai ”Paketoi tulos kotiutusdoku-
menttiin”. Dokumentit on kokoelma yhteen kerättyjä resursseja. Lisäksi ne ovat yhte- neväisiä CDA:n dokumenttien kanssa, jolloin ne voidaan myös allekirjoittaa. Doku- mentit liikkuvat ATOM-syötteenä. (Quinn, 2014c)
Vastaavasti FHIR:n sanomat mukailevat HL7 v2 ja v3 sanomia. Käytännössä sanomat toimivat resurssien (esimerkiksi ATOM-syötteen) kokoelmana (Grieve et al., 2015).
Sanomat toimivat tapahtumina, joilla voidaan ohjata esimerkiksi laboratoriomääräys- ten lähettämistä. Lisäksi ne toimivat asynkronisesti molempiin suuntiin tapahtumape- rusteisesti (send lab order/ get back result). Vastaavasti palvelut toteutetaan yksinker- taisiin resursseihin ja kokoelmiin perustuvaa SOA-periaatetta käyttäen. 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 käytettävälle tiedonsiirtotekniikalle ja se pystyykin kom- munikoimaan käyttäen esimerkiksi HTTP:tä, MLLP:tä, MQ:ta, SOAP:ia tai jotain muuta käyttötapaukseen soveltuvaa tekniikkaa hyväksikäyttäen. (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 määrittää 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, päivittää olemassa olevan resurssin sen id:n perusteella. Jos re-
o Create, luo uuden resurssin palvelimen myöntämällä tunnuksella (id).
o Search, etsii joukon resursseja hakukriteerien perusteella.
o History, hakee kaikkien tietyn tyyppisten resurssien päivityshistorian.
Koko järjestelmän interaktiot (whole system interactions).
o Conformance, hakee järjestelmän määrityksenmukaisuuslauselman.
o Transaction, päivittää, luo tai poistaa usempia resursseja kerrallan.
o History, hakee kaikkien resurssien päivityshistorian.
o Search, etsii joukon resursseja hakukriteerien perusteella koko järjes- telmän laajuudelta. (HL7, 2015q)
4.8 FHIR-standardin rakenteinen yhteenveto
Tutkielman luvussa 2.2 esiteltiin yhteentoimivuusstandardin arviointimalli (viiteke- hys). Tämän aliluvun tarkoitus on esitellä FHIR-standardin rakenteinen yhteenveto lu- vussa 2.2 arviointimalliin nojautuen.
FHIR-standardista on tehty M. Suhosen, J. Mykkäsen, 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). (Mykkänen et al., 2008; Suhonen et al., 2013)
Seuraavassa käydään lävitse FHIR-standardin rakenteinen yhteenveto, joka pohjautuu luvun 2.2 arviointimalliin. Aineistona on käytetty edellä mainittua dokumenttia. (Su- honen et al., 2013)
Perustiedot ja kohdealue (Basic information and scope of the standard)
FHIR tarjoaa tarvittavat resurssit potilastiedon välittämiseen järjestelmien vä- lillä. Se mahdollistaa standardin vaivattomaan käytön RESTful ympäristöissä, viestien välittämiseen, kliinisen dokumentaation välittämiseen ja SOA-arkki- tehtuurille.
Kohdeyleisö on pääasiassa tekninen ja liiketoiminnallinen, erityisesti tervey- denhuollon näkökulmasta.
FHIR nojautuu toimiessaan XML-, JSON-, HTTP-, ATOM-, Oauth- ja REST- standardeihin. (Mykkänen et al., 2008; Suhonen et al., 2013)
Tieto ja semantiikka (Information and semantics)
Standardi kuvaa tietomallit ja resurssit, sekä niiden välisiä semanttisia yhteyk- siä.
Standardi selittää käsitteet, datatyypit, koodistot ja terminologian.
Käytettävissä olevat koodistoja ovat esimerkiksi SNOMED CT, LOINC, UCUM, ICD-10, ICD-9 USA, ATC, ISO 11073-10101 Medical Device Codes ja DICOM. (Mykkänen et al., 2008; Suhonen et al., 2013)
Toiminnot ja interaktiot (Functionality and interactions)
Standardi kuvaa käytettävät prosessit ja työnkulut tarkemmalla tasolla.
Standardin toiminnot tapahtuvat RESTful API-rajapinnan välityksellä HTTP:n lähetys- ja vastaanottamisprotokollaa hyväksi käyttäen. (Mykkänen et al., 2008; Suhonen et al., 2013)
Sovellusarkkitehtuuri (Application infrastructure aspects)
Standardi pystyy jakamaan viestejä, dokumentteja, resursseja RESTful API- rajapinnan kautta. Jakamiseen käytettävä yhteys voidaan luoda sekä synkroni- sesti, että asynkronisesti.
Viestien yms. välityksessä käytetään hyväksi kohteen osoittamiseen URL- osoitetta.
Käytetään hajautettujen järjestelmien pohjana, ei niinkään yksittäistä käyttäjää varten. Arkkitehtuuri mahdollistaa useiden eri tietokantojen, komponenttien ja
Standardi siirtää tietoa yms. käyttäen hyväksi ainoastaan XML ja JSON -tek- nologioita. Interaktiot ja muu toiminnallisuus tapahtuu käyttäen REST ja HTTP -rajapintoja hyväksikäyttäen.
Standardia ei ole sidottu tiettyyn käyttöjärjestelmään tai alustaan.
Standardia mahdollistaa ohjelmoinnin Javalla, C#:lla ja Delphillä. (Mykkänen et al., 2008; Suhonen et al., 2013)
Laajennettavuus (Flexibility, accuracy, extensibility)
Standardin onnistunutta laajennettavuutta mitataan kahdella kriteerillä. Onko se FHIR-standardin vaatimusten mukainen ja täyttääkö 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. Näiden lisäksi voidaan käyttää myös yhtä tai useampaan käytäntöönpanomallia (REST, viestit, dokumentit, palvelut jne.).
Kaikki resurssit ja elementit ovat laajennettavissa. (Mykkänen et al., 2008; Su- honen et al., 2013)
Levinneisyys (Maturity, usage, official status)
Standardi on vapaaehtoisen ja kansainvälisen yhteisön tuote, joka on ANSI ak- kreditoitu vastaamaan HL7-konsortion vaatimuksia.
Standardin speksit koostuvat yli 1500 eripituisesta html-sivusta. Se on myös melko ymmärrettävää myös henkilöille, joilla ei ole aikasempaa HL7-standar- dien kokemusta.
Löytyy kymmenittäin projekteja, jossa standardia on käytetty. (Mykkänen et al., 2008; Suhonen et al., 2013)
Järjestelmän elinkaareen (System lifecycle)
Standardin resurssimallit luovat perustan yksityiskohtaisille vaatimuksille.
Arkkitehtuurisesti joudutaan kartoittamaan vaatimukset standardin käyttämille
palvelimille ja komponenteille. Vastaavasti resurssimallien ja laajennusten vaatimukset otettava kehityksessä huomioon. Varsinainen toiminnallisuus ta- pahtuu RESTful API-rajapintaa käyttäen.
Standardille on mahdollista tuottaa uusia laajennuksia, mutta taaksepäin yh- teensopivuutta ei voida vielä kehittäellä olevassa versiossa taata. (Mykkänen 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 sähköinen potilaskertomus, diagnoosit, hoidot, viestinvälitys o kliininen päätöksentuki
o ajanvarauskalenterit
o mittaukset, analyysit, raportointi, tutkimuskäytön tuomat vaatimukset o tietoturvan toteutuminen tuo omat vaatimukset
o rakenteistetun ja rakenteistamattoman tiedon käsittely o laskutus ja muut hallinnolliset toiminnot
o Jne.
Terveydenhuollon mukana tulee vaatimuksia myös laskutukseen ja hallintoon.
Käytettävyyden parantaminen on isossa roolissa.
Työnkulkuihin ja muuhun kuin terveydenhuollon liiketoimintaan standardin ei tarvitse taipua. (Mykkänen et al., 2008; Suhonen et al., 2013)
