Omatietovaranto tietomallin hallinta 29 10 2020 Riikka Suvanen

Omatietovaranto tietomallin hallinta 29. 10. 2020 Riikka Suvanen 1

Tavoitteet • Tietomallin hallintamalli esittää kansalliseen tietomallin laajentamisen ja sen muutoksiin liittyvät periaatteet, prosessin ja toimijat vastuineen. – Toimijat tunnistavat vastuunsa. – Tietomallin ja määritysten (profiilit, resurssit, elementit ja koodistot) ylläpitoprosessi on avoin ja vastuut selkeät. – Tietomallin ja määritysten ylläpito ja kehitys on tehokasta ja joustavaa. – Määrityksissä noudatetaan yhtenäistä käsitteistöä ja nimeämiskäytäntöjä. – Määritykset eivät ole päällekkäisiä vaan täydentävät toisiaan. 2

Toimijat Toimija Rooli THL • • Kela • • • Ylläpitää kansallista phr-tietomallia, omistaa tietomallin Tuottaa soveltamisoppaat tietomalliin sisältyvien resurssien hyödyntämiseen Hyväksyy tietomallin sovelluskohtaiset laajennokset ja uudet tietosisällöt osaksi kansallista tietomallia? HL 7 PH sig • Kokoaa sovellusten toteuttajia ja heidän tarpeitaan sekä tietosisältöjen / profiilien ehdotuksia, tarkennuksia, laajennuksia ja priorisointia Arvioi Omatietovarantoon tulevat tietosisällöt ja uudet tietorakenteet Tukee ja edistää ratkaisuja, joissa tietomallia laajentamalla pyritään löytämään ratkaisuja uusiín tietotarpeisiin • • Sote-toimijat, hyvinvointipalvelujen tuottajat, tuotekehittäjät 3 Vastaa kansallisista koodistoista, valmistelelee tuotantokäytössä vakioitavat PHRkoodistot koodistopalvelun johtoryhmään Koordinoi Kanta-palvelujen kehitystyötä • Tuottaa uutta tietotarpeita (-sisältöä), uusia profiileja, laajennoksia

Käsitteet – FHIR standardi • Resurssi – FHIR-”rakenneosa”, jolla on oma FHIR-pohjaprofiili (Structure. Definitiontietorakenne). Esim. Observation, Care. Plan, Questionnaire. Pohjaprofiili on hyvin väljä, joten tarvitaan erillistä profilointia tiedon yhdenmukaistamiseksi. • Profiili – Rajoittaa FHIR-resurssin pohjaprofiilia. Esim. Verenpainemittaus-profiili rajoittaa Observation-profiilia mm. määräten mitä LOINC-koodeja ja mitä mittayksiköitä on käytettävä ja millaisessa rakenteessa mittaustulos on tuotava. • Laajennus (extension) – Jos resurssin pohjaprofiili ei tue tarvittavaa tietoa, tarvitaan laajennus. Esimerkiksi jos mittaus kohdistuu sikiöön, Observation-resurssia joudutaan laajentamaan koska se ei tue tuota tietoa.

Tietomalli teknisesti • Kaikki profiilit ja extensionit ovat Structure. Definition-rakenteita, jotka on tallennettu yhdelle FHIR(PHR)-palvelimista. • Kehittäjät voivat hakea Structure. Definitionit REST-rajapinnan kautta, lisäksi nämä on julkaistu määrittelyalustalla (käyttöliittymäsovellus, jonka tietovarantona on FHIR-palvelin). • Vastaanotettava data validoidaan näitä Structure. Definitoneita vasten. Tallennettava resurssi kertoo (metatiedon avulla) mitä profiilia se noudattaa, validointi tehdään tätä profiilia vasten. Myös extensionit validoidaan.

Omatietovarannon tiedon tallentamisen ja käytön yleisperiaatteet • • • Omatietovarannon tietomalli on avoin. – Tietomalli (tietomallin ja rajapintojen kuvaukset) julkaistaan verkossa ja on kaikkien palvelunkehittäjien saatavissa. – Standardin laajennokset ovat kaikkien käytettävissä. – Kehittämiseen liittyy määritelty prosessi. – Tietomalli on laajennettavissa määritellyn prosessin mukaisesti. Omatietovarantoon tallennettavan tiedon on oltava kansallisen tietomallin mukaista. – Kansalliseen tietomalli muodostuu määritellyn prosessin mukaan hyväksytyistä ja julkaistuista ydintiedoista, FHIR Resursseista ja Profiileista – Jos tiedon tallentamiseen tarjotut resurssit eivät mahdollista tietyn tiedon tallentamista, on tarve standardi laajennokselle (extension). Kansallisen tietomallin laajennoksia tarvitaan sovelluskohtaisen tiedon tallentamiseen – Laajennus toteutetaan vain, jos ao. tarvetta ei voida täyttää nykyisellä tietomallilla. Päällekkäisiä tietoelementtejä - jotka poikkeavat esim. vain nimen osalta - ei toteuteta. – Kaikki laajennokset rekisteröidään ja julkaistaan Omatietovarantoon tallennettu tieto on kaikkien alustaan liittyvien palvelujen käytettävissä – Kansalainen antaa sovellukselle luvan tallentaa ja käyttää Omatietovarantoon tallennettua tietoa käyttöönottaessaan sovellusta (luvituskäytäntö) – Omatietovarannon käyttöön vaaditaan vahva tunnistautuminen – Käyttäjien yksilöinti on erotettava asiakkaiden yksilöinnistä (puolesta-asiointi) • Kaikkea tietoa ei ole tarpeen tallentaa tai siirtää kansalliselle alustalle. Osa tiedoista voi olla tarkoituksenmukaista tallentaa liitettävän palvelun omaan tietokantaan. • PHR: ää ei käytännössä voi käyttää sovelluskohtisena tietovarastona, jollei sovellus nojaudu yhteisen tietomallin mukaisiin rakenteisiin ja julkaistuihin laajennoksiin 6

Omatietovaranto - tietomallin hallinnan prosessi Prosessi kuvaa toimintojen kulun ja osapuolten vastuut kun hyvinvointisovelluksen kehittäjällä on tarve laajentaa Omatietovarannon tietomallia sovelluksen käyttötarpeita varten. Muutokset voivat olla pieniä, jolloin niihin ei liity Kelan ylläpitämän palvelualustan muutostarvetta. Kyseessä on tällöin usein uusi tietosisältö, jonka hyvinvointisovelluksen kehittäjä voi itsenäisesti lisätä palvelualustalle esim: • uusi profiili (FHIR profile), johon liittyen on jo olemassa kansallinen pohjaprofiili, esim. halutaan lisätä verenpainemittaus-tietoa, jolloin voidaan hyödyntää jo olemassa olevaa mittaus-pohjaprofiilia • uusi laajennos (FHIR extension) liittyen jo olemassa olevaan profiiliin, esim. verenpaine-mittaukseen halutaan lisätä mittarilaitteen merkki-tieto • uusi kyselylomake (FHIR questionnaire) • uusi Omatietovarannon sisäinen koodisto 29. 10. 2020 Esityksen nimi / Tekijä 7

Omatietovaranto - tietomallin hallinnan prosessi Muutostarve voi kohdistua myös Kelan ylläpitämän palvelualustan kansallisen tietomallin tietosisältöön tai käsittelylogiikkaan ja muutos vaikuttaa mahdollisesti myös muihin palvelualustan toimijoihin. Nämä ovat luonteeltaan suurempia muutoksia. Esimerkkejä suuremmista muutoksista: • uusi profiili, joka vaatii uutta käsittelylogiikkaa FHIR-palvelimella • muutos aktiiviseen profiiliin • uusi resurssityyppi, jota ei vielä ole kansallisessa tietomallissa • muutos jo käytössä olevaan Omatietovarannon sisäiseen koodistoon 29. 10. 2020 Esityksen nimi / Tekijä 8

Tietomallin hallinnan prosessi 29. 10. 2020 Esityksen nimi / Tekijä 9

Tietomallin hallinnan prosessi – toimintojen kuvaukset 1 Elementin nimi a. Tarvitsee muutoksen Omatietovarannon tietomalliin b. Haluaa arvion toteutettavuudesta? Tyyppi Start Event Selite Hyvinvointisovelluksen kehittäjä haluaa laajentaa tai muuttaa Omatietovarannon kansallista tietomallia Gateway Halutessaan arvion tietosisällön laajennoksen tai muutoksen soveltuvuudesta osaksi Omatietovarannon sisältöä hyvinvointisovelluksen kehittäjä voi pyytää toteutettavuuden arviointia Kelalta ja HL 7 PH sig: iltä. Toteutettavuuden arviointi on aina tehtävä, mikäli muutokseen liittyy tarve lisätä/muuttaa olemassa olevaa palvelualustan toiminnallisuutta. Toteutettavuuden arviointipyyntö lähetetään kantakehitys-postilaatikkoon (kantakehitys@kanta. fi) sekä HL 7 PH sig: in yhteyshenkilölle (http: //www. hl 7. fi/). Pyyntöön on lisättävä aihe (=Omatietovaranto toteutettavuuden arviointipyyntö) sekä tietyt perustiedot, tätä varten sabluuna!!! c. Arvioi muutoksen toteutettavuuden Task Kela ja HL 7 PH sig arvioivat uuden profiilin tai laajennoksen soveltuvuutta osaksi Omatietovarannon sisältöä ja antavat palautteen hyvinvointisovelluksen kehittäjälle. Kela ottaa tarvittaessa arviointiin mukaan myös Terveyden ja hyvinvoinnin laitoksen (THL) ja sote-kokonaisarkkitehtuuri-ryhmän. Toteutettavuuden arviointiin kuuluu seuraavia asioita: - soveltuvuus FHIR-näkökulmasta - soveltuvuus terveyden ja hyvinvoinnin edistämisen näkökulmasta - muut toimijat, joilla kiinnostusta - osallistujat - mahdolliset referenssit - value setit, koodistot (kansallinen yhtenäisyys) - analyysi mahdollisista muutostarpeista palvelualustalle Esiarvioinnin kommentteja ei koosteta vaan kannanottoja ja kommentteja annetaan määräajan sisällä vapaasti. Kelan projektointia edellyttävät isommat muutostarpeet palvelualustalle käsitellään ohjausryhmässä ja niiden aikatauluista tiedotetaan prosessin edetessä. 29. 10. 2020 Esityksen nimi / Tekijä 10

Tietomallin hallinnan prosessi – toimintojen kuvaukset 2 Elementin nimi Tyyppi Selite d. Edellytetäänkö Kelan muutoksia palvelualustalle? Gateway Tarvitaanko muutoksia FHIR-palvelimen käsittelylogiikkaan? e. Tekee päätöksen palvelualustan muutosten toteuttamisesta, priorisoi ja aikatauluttaa muutostyöt Task Ohjausryhmä käsittelee ehdotetun muutoksen ja päättää toteutuksesta. Ohjausryhmä priorisoi hyväksytyn muutoksen ja aikatauluttaa Kelan työt. Ohjausryhmän päätös välitetään hyvinvointisovelluksen kehittäjälle tiedoksi. f. Hyväksytäänkö tehtäväksi? Gateway Hyväksyykö ohjausryhmä ehdotetun palvelualustan muutostyön tehtäväksi? g. Ehdotettua muutosta ei tehdä Omatietovarannon tietomalliin End Event Mikäli ehdotettu muutos ei täytä teknisiä tai alustan käyttötarkoitukseen liittyviä kriteereitä se voidaan hylätä h. Toteuttaa palvelualustalle vaadittavat muutokset Task Kela toteuttaa FHIR-palvelimen muutokset ja vie ne Sandbox- ja asiakastesti-ympäristöihin sekä päivittää profiilirekisterin tiedot. Kela tiedottaa hyvinvointisovelluksen kehittäjää muutostöiden aikataulusta. i. Haluaa koestaa muutosta PHR Sandbox-ympäristössä? Gateway Hyvinvointisovelluksen kehittäjä voi halutessaan koestaa Kelan Sandbox-ympäristössä sovelluksen toimintaa tarvittavien tietomallin muutosten jälkeen. j. Vie tietomallin laajennoksen Sandbox-ympäristöön Task Hyvinvointisovelluksen kehittäjä lisää hyvinvointisovelluksen tarvitsemat tietomallin laajennokset (esim. uuden kansalliseen pohaprofiilliin perustuvan profiilin tai profiilin laajennoksen) Kelan Sandbox-ympäristöön. Statustiedoksi asetetaan tässä vaiheessa 'draft' ja experimental-tiedoksi 'true'. Ohjeet Sandbox-ympäristön päivittämiseen <viittaus> 29. 10. 2020 Esityksen nimi / Tekijä 11

Tietomallin hallinnan prosessi – toimintojen kuvaukset 3 Elementin nimi Tyyppi Selite k. Lisää/päivittää kuvaukset profiilirekisteriin Task Hyvinvointisovelluksen kehittäjä lisää uusien tietosisältöjen kuvaukset profiilirekisteriin. Status-tiedoksi asetetaan tässä vaiheessa 'draft' ja experimental-tiedoksi 'true. Katselmoinnin edellytyksenä on, että tiedot on lisätty profiilirekisteriin. Ohjeet profiilirekisterin päivittämiseen <viittaus> Profiilirekisterin päivittämisen jälkeen hyvinvointisovelluksen kehittäjä pyytää katselmointia. Katselmointipyyntö lähetetään kantakehitys-postilaatikkoon (kantakehitys@kanta. fi) sekä HL 7 PH sig: in yhteyshenkilölle (http: //www. hl 7. fi/). Pyyntöön on lisättävä aihe (=Omatietovaranto katselmointipyyntö), käyttötarkoitus, ja tiedot profiilirekisteriin tehdyistä päivityksistä. l. Katselmoi muutoksen Task HL 7 PH sig katselmoi tietomallin laajennoksen, huomioiden samat seikat kuin toteutettavuuden arvioinnissa, ja antaa joko myönteisen tai perustellun kielteisen kannanoton. Mahdollisesti tekee muutosehdotuksia. m. Katselmoi muutoksen Task Kela katselmoi tietomallin laajennoksen huomioiden samat seikat kuin toteutettavuuden arvioinnissa. Kela huomioi HL 7 PH sig: in kannanoton, käsittelee tarvittaessa muutosta myös Terveyden ja hyvinvoinnin laitoksen (THL) ja sote-kokonaisarkkitehtuuri-ryhmän kanssa, tekee lopullisen päätöksen ja informoi katselmoinnin tuloksesta hyvinvointisovelluksen kehittäjää. 29. 10. 2020 Esityksen nimi / Tekijä 12

Tietomallin hallinnan prosessi – toimintojen kuvaukset 4 Elementin nimi Gateway Selite n. Katselmoinnin tulos? Gateway o. Tekee tarvittavat muutokset p. Muuttaa statuksen profiilirekisteriin ja lisää profiilin asiakastestiin q. Asiakastestaus ja sertifiointi prosessi r. Muuttaa statuksen aktiiviseksi ja vie kaikki muutokset tuotantoympäristöön s. Päivitetty tietomalli on tuotantokäytössä Task Tietomallin laajennos joko hyväksytään tai siihen esitetään tehtäväksi muutoksia ennen asiakastestaukseen etenemistä. Hyvinvointisovelluksen kehittäjä toteuttaa tarvittaessa katselmoinnissa esiin nousseet tarvittavat muutokset ja päivittää profiilirekisterin tiedot. Katselmoinnin hyväksymisen jälkeen Kela päivittä kuvausten statustiedot profiilirekisteriin (status = active). Lisäksi Kela lisää samoilla status-tiedoilla uudet tietosisällöt asiakastesti-ympäristöön. 29. 10. 2020 Task Sub-Process Asiakastestaus- ja sertifiointi-prosessit on tarkemmin kuvattu muualla. Task Hyväksytyn sertifioinnin jälkeen Kela vie muutokset tuotanto-ympäristöön ja päivittää status-tiedot (status = active, experimental = false) kaikkiin edeltäviin ympäristöihin ja profiilirekisteriin. End Event Tuotantokäyttö voi alkaa Esityksen nimi / Tekijä 13