Vastaukset kyselyyn FHIR-toteutuksen malliprojektin ja kansallisten FHIR-profilointien osalta 5/2020

Vastaukset kyselyyn FHIR-toteutuksen malliprojektin ja kansallisten FHIR-profilointien osalta 5/2020

05/2020 vastanneet; Kansaneläkelaitos, THL, SoteDigi Oy

Kysymys 1: FHIR profiilien ja rajapintojen kehittämisessä on tehtävä valinta kommunikoinitiparadigmasta: käytetäänkö FHIR:in standardin CRUD -operaatioita vai toteutetaanko käyttötapauksen interaktiot tiukemmin paketoituina sanomapohjaisina operaatioina (kts. soveltamisoppaan operaatiot luku US Argonaut-mallin mukaisesti). Onko teillä preferenssiä näiden välillä? Mitkä ovat perusteita puolesta ja vastaan?

• Kannattaa pyrkiä mahdollisimman pitkälle tekemään rajapintoja, jotka noudattavat RESTin perus-CRUD-operaatioita, tämä yksinkertaistaa rajapintoja ja niiden toteuttamista. Jos tulee erityistarpeita, esim. monimutkaisempia käyttötapauksia, joita ei voi helposti perus-CRUD-operaatioilla toteuttaa, tällöin kannattaa ottaa käyttöön FHIR:ssa kuvattu REST-operaation määrittely (RPC-style FHIR Operation) tai jo olemassa olevien operaatioiden laajentaminen. Kannattaa myös huomioida, että FHIR operaatiot ei ole sama asia kuin ”sanomapohjaisuus” (Messaging), FHIR:ssa on Messaging paradigmaa varten oma määrittelynsä ja siellä hyödynnetään MessageHeader-resurssia (vrt. V2 MSH).
• Sanoma-bundle-pohjaisen toteutuksen puolesta puhuu aiempi runsas ajanvaraussanomien käyttö terveydenhuollon yksiköissä (joka korvautuisi vähitellen FHIR-pohjaisilla sanomilla) ja se, että sanomaan saadaan luontevammin paketoitua ”riittävän kattavat” tiedot kerralla. CRUD/REST-käyttöä taas puoltaa toteutuksen keveys.

Kysymys 2: Näettekö tarpeelliseksi /millaisista asioista näette tarpeelliseksi alkaa työstää kansallisia best practices -suosituksia? Vrt. esim NHS:n vastaava ohjeistus/suositus: https://nhsconnect.github.io/fhir-policy/index.html Miltä osin esimerkiksi oheiset brittilinjaukset olisivat mielestänne soveltuvia meillekin?

• NHS:n lista näyttää hyvältä. Jatkotyössä voisi kysyä, onko jotain kohtia siinä joista EI tarvittaisi kansallisia suosituksia tai vaatimuksia tai onko jokin siinä näkyvä vaatimus ”hankala”. Profiilien ”tasoittaisuusmalli” voisi sopia meillekin: https://nhsconnect.github.io/fhir-policy/profiling.html
• Kansallinen ohjaaminen on tarpeellista, jos halutaan että kansalliset rajapinnat noudattavat samoja tapoja eri rajapinnoissa. FHIR:n avulla saadaan määriteltyä samalle asialle hyvinkin eri näköisiä ratkaisuja johtuen sen platform-lähestymistavasta (vain pohja eri ratkaisuille). NHS ohjeistukset/suositukset varmasti hyviä kohteita yhteisesti kansallisestikin sovittaviksi (huomioitava toki, että NHS ei ole sama asia kuin vaikkapa HL7 UK). On myös päätettävä mitä tasoa halutaan ohjeistaa, kaikkia kansallisia FHIR rajapintoja, Kanta-kontekstin rajapintoja, paikallisesti käytettäviä mutta yhteisesti kansallisesti määriteltyjä rajapintoja (vastaavan tasoiset kuin nykyiset HL7 V2 sanomat). Kansallisia best practices suosituksia tai profiling guidelines ohjeita voisi työstää seuraavista:

1. • yleisohje mitä implementointioppaiden pitäisi sisältää / velvoite tuottaa implementointioppaita. Vaikka käytetään perus-CRUD-operaatioita, se ei kuitenkaan tarkoita, että ei tarvittaisi tarkempia implementointioppaita resurssien ja RESTapin käytöstä erilaisissa käyttötapauksissa
   • esimerkit ovat oleellinen osa FHIR-standardia, vaatimus esimerkkien tuottamisesta rajapintamäärittelyihin pitää olla velvoittava
   • ohjeistus miten suomalaisia koodistopalvelun koodistoja esitetään FHIR resursseissa tai FHIR tietotyypeissä, esim. miten käytännössä toteutetaan FHIR ValueSettien laajentaminen preferred ja extensible vahvuuksissa, miten rajoitetaan FHIR required ValueSetteja, tiettyjen jo etukäteen tiedossa olevien koodattujen tietojen lukkoon lyöminen kansallisiin profiileihin
   • ohjeistus miten suomalaisia yleisiä yksilöintitunnisteita esitetään FHIR resursseissa tai FHIR tietotyypeissä, tiettyjen jo etukäteen tiedossa olevien tunnistetietojen lukkoon lyöminen kansallisiin profiileihin (esim. henkilötunnus, organisaatiotunnisteet, palvelutapahtumatunniste)
   • kansallisten laajennusten määrittelyn periaatteet, yhteinen määrittelytapa, hallinta ja julkaisu
   • CRUD-operaatioilla toteutettavissa rajapinnoissa voisi olla järkevää määritellä ja sopia mitä osapuolitietoja siirtyy FHIR-resursseissa ja mitä http headerissa. Http headerin osalta voisi yrittää sopia kansallisesti yhteisen pohjan http header tiedoille (mitä tietoja ja missä muodossa sinne viedään), esim. millä tavalla oAuth-osapuolitiedot esitetään.
   • heti alkuvaiheessa olisi järkevää yhdenmukaistaa, ainakin kansallisten rajapintojen osalta, profiilien, operaatioiden jne nimeämistavat sekä palveluiden URLien muodostamis- ja nimeämissäännöt. Nämä ovat oleellinen osa FHIR määrittelyjä, sillä URLeja käytetään monen asian tunnistamiseen. Jos näihin ei kiinnitetä heti alkuvaiheessa huomioita, on riskinä että näihin tulee sekaannuksia eri toteutusten välillä. Nämä oli huomioitu viitatussa NHS FHIR Policyssa.
   • yksi perusasia on myös kansallisten profiilien versiointikäytännöt ja miten ne toteutetaan yhdenmukaisesti (major, minor, patch, tms.)
   • profiilien julkaisualusta ja julkaisutapa on myös hyvä suunnitella jo alussa, huomioiden edellä mainitut versiointikäytänteet

Kysymys 3: FHIR on pohjastandardina huomattavasti joustavampi  kuin tarkkoihin sanoma- ja asiakirjakuvauksiin perustuvat HL7 v3 määritykset. Profiloinnilla on säädettävissä, halutaanko noudattaa tiukkaa profilointia (velvoittavaa määrittelyä toteutusten ja validointien tueksi) vai löyhempää profilointia (profiilien rooli enemmän toimia esimerkkinä ja lähtöpisteenä toteutuksille) . Kumpaako lähestymistapaa preferoitte ja miksi?

• Tiukempi profilointi olisi perusteltu seuraavan kysymyksen hallinnoinnin näkökulmasta, mutta toisaalta löyhempi profilointi voisi edistää kokeilukulttuuria. Eli jonkinlaiseen kompromissiin päädytään tässä joka tapauksessa?
• Yhteentoimivuus on pystyttävä ratkaisemaan riittävän tarkasti, jos siirrettyjä tietoja on tarkoitus pystyä hyödyntämään. Tiukka profilointi tarvitaan useimmissa oikeaa yhteentoimivuutta tavoittelevissa käyttökohteissa. Yleisesti suunta on edelleen kohti myös entistä tarkemmin ilmaistua semantiikkaa (esim. SNOMED CT) joskin voi tulla myös vapausasteita tai vaihtoehtoja esim. käytettyihin koodistoihin jne.
• Tämä ei ole oikeastaan preferoitava asia. Profiloinnin tiukkuuden tarve on riippuvainen siitä, onko profiilin tarkoitus olla yleinen kansallinen pohjaprofiili vai tarkka toteutuskohtainen profiili ja siitä mitä profiililla tavoitellaan. Ei siis ole olemassa yhtä lähestymistapaa, lähestymistapa on valittava tarpeen mukaan. Yleisen kansallisen pohjaprofiilin (profiili, jossa sovittu kansalliset toteutettavat yhteiset piirteet) on oltava avoimempi, se on näin yhteensopiva eri käyttötapausten kanssa ja helpottaa varautumista tulevaisuuden muutoksiin (eteenpäin yhteensopivuus helpompaa kun ei ole poistettu kaikkea ei tarvittavaa jo alussa). Tietyn sovellusalueen profiili voi olla tiukempi ainakin pakollisuuksien ja käytettävien koodistojen suhteen mutta siinäkin kannattaa harkita tietojen turhaa poistamista eteenpäin yhteensopivuuden näkökulmasta. Implementointioppaassa on hyvä kuvata tällaisten ”turhien” tietojen merkitys ja käsittely. Mutta mentäessä lähemmäs oikeaa toteutusta, voi toteutuskohtainen profiili olla tiukempi, varsinkin jos sen pohjalta halutaan varmistua instanssien oikeellisuudesta ja tehdä tarkkaa validointia. Tähän liittyen Fire.ly:n Profiling Academyssa on hyvää pohditaan ja näkökulmia: https://simplifier.net/guide/profilingacademy/Best-practices (siellä kohta 2 Open versus closed modeling)

Kysymys 4: Ajatuksenne ja ehdotuksenne kansallisten profiilien tuottamisen toimintamallista/hallintamallista, mihin tulee erityisesti mielestänne kiinnittää huomiota?

• Hallintamallin näkökulmasta kansalliset profiilit tulee “leimata” sellaiselta taholta, joka ohjaa järjestelmiä kehittäviä toimittajia sitoutumaan yhteisiin määrityksiin. Kansallista kehittämistä (esim. hankkeita) varjostaa välillä kiire, resurssien vähyys tai joku muu tekijä, joka saattaa ohjata matalimman aidan luokse. Tällöin loppukäyttäjien näkökulmasta ratkaisu saadaan toteutettua, mutta tekninen yhteentoimivuus ei ole sellaisella tasolla, että ratkaisua voitaisiin jatkossa ilman merkittäviä muutoksia yhdistää muihin kansallisiin, “samalla standardilla” toteutettuihin ratkaisuihin.
• Profiloinnin kohteiden valintaan: 1. ne joihin löytyy aktiivisia työstäjiä ja riittävän laaja hyödyntäjäjoukko. Lisäksi: yhteensopivuus kansallisiin tietomäärittelyihin ja niiden hyödyntäminen (mm. koodistot, kansalliset modulaariset tietorakenteet, SNOMED CT käyttö). Yhteensopivuus kansainvälisen standardin ja samaa aihetta jo soveltaneiden (esim. muiden maiden profiilit) kanssa.
• On päätettävä, millainen ohjaus profiileihin kansalliselta tasolta tulee ja mille tasolle kansallinen ohjeistus asettuu: halutaanko muodostaa eri resursseista yhteinen kansallinen profiilien pohja, jota muut määriteltävät profiilit noudattavat vai annetaanko vain profiloinnin best practices/profiling guidelines, jolla ohjataan mm. tunnisteiden ja koodattujen tietojen käyttöä, tietotyyppien käyttöä, profiilien nimeämistä, versiointi jne. Hallintamallissa pitäisi vähintään huomioida:
  1. • miten valitaan kansallisesti tuotettavaksi tulevat profiilit
     • miten nämä profiilit käytännössä kehitetään yhteistyössä eri tahojen kanssa
     • miten varmistetaan, että hyödynnetään kansainvälisesti jo tehty profilointityö (FHIR kv. profiilit, muut kv. määritellyt profiilit ja laajennukset jne.)
     • millaiset hyväksymismenetelmät profiileille vaaditaan (vrt. nykyisen HL7 Finland äänestyskäytännöt)
     • profiilien muutoshallinta ja versiointi (esim. siirtymät FHIR versioiden välillä, profiileiden versiot ja niiden vaikutus niistä periytettyihin profiileihin, versiointikäytännöt)
     • miten profiilit julkaistaan
     • jos kansallisesti määriteltävien profiilien tietosisältöjä ei ole määrittelyt THL, kuka päättää mitä koodistoja tai yksittäisiä koodeja kansallisissa profiileissa on käytettävä, saadaanko tähän asiantuntemusta jostain?

Kysymys 5:  Mikä olisi profiilien työstön sopiva laajuus mielestänne. Näettekö kansallisten profiilien lisäarvon hyvänä vai pitäisikö työtä viedä enemmän esimerkiksi pohjoismaisen yhteistyön suuntaan? Vai lähemmäksi laajojen alueellisten toteutusten määrittelyitä?

• Pyritään ensin kansallisiin profiileihin ja niiden yhtenäiseen hyödyntämiseen. Profiilien pilotointia varten olisi hyvä saada jokin käyttötavoiltaan laaja ratkaisu, jossa mukana monia eri sidosryhmiä/toimittajia. Näin saataisiin saman tien edistettyä yhteisiin määrityksiin sitoutumista.
• Kansallinen taso on aiemminkin osoittautunut aika toimivaksi – pystytään kokoamaan riittävän laajasti kohdetta tarvitsevia yhtäaikaisesti, riittävän samanlaiset soveltamiskohteet, mahdollisuus kytkeä esim. kansallisiin kehittämispolkuihin. Pohjoismaisella tasolla on niin erilaiset lähtökohdat eri maissa, että ainakaan ”vanhoihin rajapinta-alueisiin” ei helposti ehkä saada yhteistyötä. Joissakin uusissa aiheissa voisi olla pohjoismaiset kokeilut mahdollisia, mutta ehkä vielä proflointeja helpommin yhteisdemot, -koulutukset ja tapahtumat standardien pohjalta.
• Tämän kyselyn lähettäjä on HL7 Finland, joten työstön konteksti tässä kyselyssä lienee kansallisen tason profiilit.  Haluaako HL7 Finland ottaa roolia muusta kuin kansallisesta tai tietystä kansallisesta sovellusalue tasosta? Jos haluaa, niin pelisäännöt muiden tasojen (esim. laajojen alueellisten toteutusten määrittelyjen), profiileiden osalta on oltava selvät. Jos kansallisesti on määriteltävissä yhteiset perusprofiilit, joita kaikki muut kansallisesti käytettävät profiilit noudattavat, niin tällöin näistä perusprofiileista on nähtävissä hyötyä (ohjaa toteuttamaan tietyt perusasiat samalla tavalla eri profiileissa). Jos näitä perusprofiileja ei nähdä järkeväksi tai hyödylliseksi, HL7 Finland ohjaus voisi olla enemmän kohdassa 2 kuvattua ohjausta (best practices, profiling guidelines) sovellusaluekohtaisille kansallisille rajapinnoille. Pohjoismaista ja muutakin kansainvälistä yhteistyötä (vähintään seurantaa) kannattaa pitää yllä. Pohjoismainen yhteistyö tai sen kohteet ovat tosin vielä epäselviä. Pohjoismaisen yhteistyön voi kuitenkin nähdä myös hyvänä kokemusten vaihtofoorumina, joten siihen kannattaa osallistua myös tästä näkökulmasta. Kansainvälistä yhteistyötä voisi tässä FHIR:in kehitysvaiheessa ottaa huomioon myös siten, että osallistutaan HL7 Finlandin projekteista aktiivisesti FHIR:n kehittämiseen viemällä saatuja kokemuksia ja kehitysehdotuksia kansainväliseen FHIR-standardin kehittämiseen jo aiemmassa kuin ballot-äänestysvaiheessa (oleellinen osa FHIR-standardia).

Yleiskommentit:

• HL7 Finlandin ”Kansallisen FHIR toteutuksen malliprojektin” referenssiksi on tulossa ajanvaraus (yhdistyksessä jo tehdyn FHIR ajanvaraustyön jatkaminen). Malliprojektin esittelyssä projektin suunnitelmissa oli myös ”Projekti suunnittelee FHIR kansallisen käytön ja hyödyntämisen mallin ja tuottaa työn aikana valittavista, keskeisimmistä resursseista kansalliset FHIR-profiilit. Projekti kuvaa kansallisen mallin FHIR –pohjaprofiilien tuottamiseen ja julkaisemiseen.”. On hyvä huolehtia, ettei työ ole pelkän jo tehdyn FHIR-ajanvaraustyön jatkamista, vaan myös suunnitelmassa mainitut ”keskeisimmät kansalliset FHIR-profiilit” tulee huomioiduksi laajemmasta näkökulmasta. Esimerkiksi omahoidon ja asioinnin tietojen ja tarpeiden huomiointi laajemminkin kuin ajanvaraus, tiettyjen kaikissa sovellusalueissa käytettävien ”yleis”-resurssien (Patient, Organization, Practioner, Device..) profilointi ottamaan huomioon kansalliset erityistarpeet, profiileissa tarvittavien kansallisten laajennusten tunnistaminen ja määrittely. Yksi huomioitava tekijä voisi olla myös THL:n moduulaaristen tietosisältöjen (tietokomponenttien) määrittelytyön huomiointi, esim. kuinka modulaariset tietosisällöt istuvat FHIR resursseihin tai miten ovat sinne istutettavissa.