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. Komenkomen-nolla 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 monimutkaiyksinkertai-seen 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 (interaktioperaati-oita), joperaati-oita 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 arviarvi-ointilomak- 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 -testes-taustapahtumissa.
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)
5 MILLAINEN ON FHIR-STANDARDIA HYÖDYN-TÄVÄ RAJAPINTAMÄÄRITTELY
Tämän luvun tarkoitus on esitellä FHIR:iä hyödyntävä rajapintamäärittely ajanvaraus-esimerkkiä käyttäen. Luvun sisältö koostuu aliluvuista, joista kahdessa ensimmäisessä esimerkkitapauksen perusarkkitehtuuri ja tapauksen tarkempi kuvaus. Kolmannessa ja neljännessä aliluvussa poraudutaan esimerkkinä toimivan ajanvarausohjelmiston ja ajanvarauspalvelimen tietosisältöihin, työnkulkuihin ja interaktioihin. Viimeiseksi esi-tellään esimerkkitapauksessa tarvittavat resurssit.
5.1 Ajanvarauksen perusarkkitehtuuri esimerkissä
Tämän kappaleen pohjana käytetäänSote-ajanvarauksen resurssienhallintaintegeraa-tiot: HL7 v3 SAV soveltamisohje -dokumenttia, jonka mukaan HL7 v3:sta käyttävän ajanvarausjärjestelmän perusarkkitehtuuri voidaan jakaa kolmeen tasoon:
1. Ajanvarausohjelmisto, jota asiakas käyttää sähköiseen asiointiin eli tässä tapauk-sessa ajanvaraamiseen. Kyseinen palvelu kykenee kyselemään vapaita ja varattuja aikoja, sekä suorittamaan resurssien hallintaa ajanvaraustoimenpiteitä hyödyntäen.
Kyselyt tapahtuvat reaaliaikaisesti taustajärjestelmistä integraatiokerrosta hyväk-sikäyttäen.
2. Integraatiokerros toimii pinnan alla sovittaen yhteen eri taustajärjestelmiä. Kerrok-sessa luodaan ja hallinnoidaan varaustuotteita, jotka mahdollistavat ajanvaraami-sen. Eli käytännössä integraatiokerros toimii ajanvarausohjelmiston ja ajanvaraus-palvelimen välissä mahdollistaen niiden toiminnan.
3. Ajanvarauspalvelin, jossa tapahtuu varsinainen resurssien ja kalentereiden hallinta.
Tämä taso sisältää yleensä myös palveluntuottajan sisäisen toiminnanohjauksen.
(THL, 2015a)
FHIR-pohjaisessa ratkaisussa voidaan käyttää vastaavaa perusarkkitehtuuria kuin SADe-ohjelman vastaavassa HL7 v3 -ajanvaraustoteutuksessa. Tässä esimerkissä
edellä mainittua perusarkkitehtuuria sovelletaan siten, että integraatiokerros jätetään pois.
5.2 Käyttötapauksen kuvaus
Esimerkin käyttötapauksena kuvaillaan tilannetta, jossa käyttäjä varaa ajanvarausoh-jelmistoa hyväksikäyttäen hammaslääkäriaikaa. Oletustilanteessa kalenteri näyttää vain vapaita aikoja puoleksi vuodeksi eteenpäin. Saadakseen ajan käyttäjä aukaisee ajanvarausohjelmiston, josta hän voi aloittaa ajan varaamisen seuraavien interaktioi-den mukaisesti: (THL, 2015a)
1. Vapaiden hammaslääkäriaikojen kysely ja vastaus. Käyttäjä kysyy ajanvaraus-ohjelmistoa käyttäen seuraavan kyselyn ajanvarauspalvelimelta: ”Milloin löy-tyy vapaita aikoja hammaslääkärille ensi kuussa?”. Vapaata aikaa hakiessa voi-daan kyselyssä käyttää erilaisia tarkentavia parametreja, kuten haetaan kaikki alueen hammaslääkärit tai pelkästään nimetty hammaslääkäri.
2. Ajanvarauspalvelin lähettää vastauksena varattavissa olevat ajat kyselyn poh-jalta ajanvarausohjelmistolle.
3. Ajanvarausohjelmistoa käyttäen käyttäjä valitsee ajanvarauspalvelimen lähet-tämistä ajoista sopivimman. Tämän jälkeen tieto valitusta ajasta välittyy ajan-varauspalvelimelle.
4. Ajanvarauspalvelin lähettää vahvistuksen varatusta ajasta ajanvarausohjelmis-tolle, josta käyttäjä sen näkee.
Edellä selostettu käyttötapaus kuvataan kuvassa 7, jossa eri interaktiot on merkitty järjestysnumeroin. Yhteentoimivuus on mahdollista järjestelmien standardoitujen rajapintojen vuoksi. Muita interaktioita olisi esimerkiksi ajan siirtäminen, perumi-nen ja jo varatun ajan tarkastamiperumi-nen. (THL, 2015a)
Kysyy vapaita aikoja
Kuva 7: Käyttäjän (ajanvarausohjelmisto) ja ajanvarauspalvelimen käyttötapauskaa-vio ajanvaraamisesta.
5.3 Tarvittavat tietosisällöt ja työnkulut
Käyttäjän ajanvarausohjelmisto käyttää schedule -resurssia kysyessään vapaita aikoja ajanvarauspalvelimelta. Resurssia käytetään ajanvarausten tekemiseen FHIR-pohjai-sessa ajanvarausjärjestelmässä. Sille voidaan määrittää tietyt reunaehdot ajan, tapaa-mistavan, paikan yms. suhteen. (HL7, 2015f)
Esimerkkitapauksen ajanvarauksen kyselyssä vaaditaan seuraavia tietosisältöjä:
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 tietosisällöt:
Varattavana olevan palvelun vapaat aikavälit halutussa aikaikkunassa.
Vapaiden aikojen sijainnit tarvittaessa, jos haettiin useammasta eri toimipis-teestä vapaita aikoja.
Ajanvaraus (appointment) -resurssin yhteydessä on kuvattu yksinkertainen työnkulku (basic work flow) aikojen varaamiseen:
1. Varattavan palvelun löytäminen ja osoittaminen. Ennen ajanvarauksen teke-mistä täytyy varattava palvelu paikantaa palvelutyypin mukaisesti. Palvelutyy-pin ja palvelun aikataulun käsittelyyn ja kuvaamiseen käytetään schedule -re-surssia. Schedule-resurssi käyttää vastaavasti slot-resurssia, joka sisältää mää-ritellyn aikaikkunan.
2. Ajanvarauspalvelin tarjoaa vapaita aikoja. Pelkkä vapaana oleva aika ei kui-tenkaan takaa varausta, koska varaukseen vaikuttavat esimerkiksi varaajan käyttöoikeudet yms. Tässä vaiheessa voidaan kuitenkin havaita, ettei vapaita aikoja ole tai ajan varaaminen ei ole mahdollista, jolloin varausprosessi voi-daan peruuttaa.
3. Käyttäjä valitsee sopivan ajan, jolloin ajanvarausohjelmisto välittää tiedon ajanvarauspalvelimelle käyttäen appointment- ja schedule -resursseja.
4. Ajanvarauspalvelin vastaa käyttäjän ajanvarauspyyntöön appointment- ja schedule -resursseilla.
5. Jos halutaan varata uusi aika, toistetaan edellä kuvailtu prosessi. (HL7, 2015f;
HL7, 2015h)
FHIR tukee kahta erilaista työnkulkua, joista ensimmäinen on edellisen esimerkin mu-kainen aikaperustainen ”outlook-style”. Tarkempaan varaamiseen voidaan käyttää monimutkaisempaa, mutta vaativampaan käyttöön tarkoitettua erillistä työnkulkua.
(HL7, 2015f)
5.4 Tarvittavat interaktiot
Tämä luku kuvaa ainoastaan esimerkissä käytettävää REST/HTTP -pohjaista toteutus-tapaa. Luvussa 4.6 on esitelty myös muita FHIR-standardin toteutustapoja, joilla ajan-varausohjelmisto olisi mahdollista tehdä.
Sanomien (resurssien) kulkua voidaan kuvata sekvenssikaaviolla, kuten kuvassa 8.
Ajanvarausohjelmisto Ajanvarauspalvelin
1. Vapaiden aikojen kysely
2. Vastaus pyydetyistä vapaista ajoista
3. Varauspyyntö yhteen vapaaseen aikaan
4. Vastaus varauspyyntöön
Kuva 8: Sekvenssikaavio sanomien kulusta.
Sekvenssikaavio kuvaa ajanvarausohjelmiston ja ajanvarauspalvelimen välistä resurs-sien vaihdantaa. (HL7, 2015f) Vastaavasti kaikki tarvittavat loogiset interaktiot on esi-telty luvussa 4.7.
1. Vapaiden aikojen kysely (discovery). Ajanvarausohjelmisto kyselee ajanva-rauspalvelimelta vapaita aikoja käyttäen schedule-resurssia. Esimerkissä ajan-varausohjelmisto lähettää kyselyparametrina schedule-resurssin tyypin, jonka perusteella löydetään oikeantyyppiset palvelut. Jos halutaan hakea pelkästään hammaslääkäreitä, voisi tyyppinä olla hammaslääkäriä ilmaiseva
1. Vapaiden aikojen kysely (discovery). Ajanvarausohjelmisto kyselee ajanva-rauspalvelimelta vapaita aikoja käyttäen schedule-resurssia. Esimerkissä ajan-varausohjelmisto lähettää kyselyparametrina schedule-resurssin tyypin, jonka perusteella löydetään oikeantyyppiset palvelut. Jos halutaan hakea pelkästään hammaslääkäreitä, voisi tyyppinä olla hammaslääkäriä ilmaiseva