Omatietovaranto tietomallin hallinta

Esitys aiheesta: "Omatietovaranto tietomallin hallinta"— Esityksen transkriptio:

1 Omatietovaranto tietomallin hallinta
Riikka Suvanen

2 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.

3 Toimijat Toimija Rooli THL
Vastaa kansallisista koodistoista, valmistelelee tuotantokäytössä vakioitavat PHR-koodistot Koordinoi Kanta-palvelujen kehitystyötä Osallistuu muutosten katselmointiin, tekee tarvittaessa tietosisällölle kliinisen arvioinnin Kela Ylläpitää kansallista phr-tietomallia, omistaa tietomallin Tuottaa soveltamisoppaat tietomalliin sisältyvien resurssien hyödyntämiseen Hyväksyy tietomallin 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 Tuottaa uusia tietotarpeita (-sisältöä), uusia profiileja, laajennoksia

4 Käsitteet – FHIR-standardi
Resurssi FHIR-”rakenneosa”, jolla on oma FHIR-pohjaprofiili (StructureDefinition-tietorakenne). Esim. Observation, CarePlan, Questionnaire. Pohjaprofiili on hyvin väljä, joten tarvitaan erillistä profilointia tiedon yhdenmukaistamiseksi. Profiili Rajoittaa ja täsmentää FHIR-resurssin pohjaprofiilia. Esim. Verenpainemittaus-profiili täsmentää 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. Kyselyrakenne (Questionnaire-resurssin instanssi) Määrittelee kyselyn, testin tai esitietolomakkeen rakenteen, eli kenttäryhmät, kenttien nimet, tietotyypit, toistuvuudet jne. Kyselyvastaukset (QuestionnaireResponse) noudattavat määriteltyä kyselyrakennetta. Sisäinen koodisto (ValueSet) Koodisto, jota hyödynnetään PHR-tietosisällöissä ja jota ei viedä kansalliseen koodistopalveluun. PHR-tietosisällöissä hyödynnetään myös koodistopalvelussa olevia koodistoja. ValueSettejä käytetään teknisempien koodistojen tai koodistopalvelussa olevien koodistojen alijoukkojen esittämiseen.

5 Käsitteet – Toimintaympäristö
Profiilirekisteri Palvelu ja sen selainpohjainen käyttöliittymä, jossa julkaistaan kansalliseen tietomalliin liittyvät profiilit, laajennukset, kyselyrakenteet, koodistot. Mahdollistaa tietomallin julkaistujen tai valmisteilla olevien osien tilojen seurannan ja versionhallinnan Palveluun voi rekisteröityä ja luoda omia profiileja ja laajennuksia. Palveluun lisätyt uudet tietomallin osat viedään hyväksyntäprosessiin ja niiden tilat muuttuvat prosessin mukaisesti. Kehitysympäristö(-t) (Sandbox 1 ja 2) Hiekkalaatikkokäyttöön tarkoitetut ympäristöt Kaikille avoin, profiileja ja extensioneita voi lisätä vapaasti Sandbox 1 toimii ilman rekisteröintiä Sandbox 2 on laajennettu rekisteröintimahdollisuuksilla ja auktorisointimekanismeilla. Asiakastestiympäristö Ympäristö liittymis- ja yhteentoimivuustestejä varten Ympäristöön liittyneet voivat lisätä profiileja ja extensioneita vapaasti Liittymisen ehtona valmis tai melkein valmis sovellus Tuotantoympäristö Ympäristö todellista käyttöä varten Ylläpitäjä voi lisätä AT-ympäristössä toimiviksi todetut profiilit ja extensionit. Liittymisen ehtona testattu ja sertifioitu sovellus

6 Tietomalli teknisesti
Kaikki profiilit ja extensionit ovat StructureDefinition-rakenteita, jotka on julkaistu profiilirekisterissä. Kehittäjät voivat hakea StructureDefinitionit REST-rajapinnan kautta tai ZIPpinä sekä katsella niitä profiilirekisterin käyttöliittymän kautta. Varsinaisten PHR-ympäristöjen ja profiilirekisterin linkki on löyhä, mutta jatkossa tutkitaan mahdollisuutta tehdä automaattista synkronointia profiilirekisterin ja testiympäristöjen välillä. Vastaanotettava data validoidaan PHR-ympäristössä sijaitsevia StructureDefinitoneita vasten. Tallennettava resurssi kertoo (metatiedon avulla) mitä profiilia se noudattaa, validointi tehdään tätä profiilia vasten. Myös extensionit validoidaan. Kyselyvastaukset validoidaan kyselyrakenteita vasten. Tallennettavassa datassa esiintyvät koodit validoidaan ValueSettejä vasten.

7 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ä. Tietomalli on laajennettavissa määritellyn prosessin mukaisesti. Omatietovarantoon tallennettavan tiedon on oltava kansallisen tietomallin mukaista. Kansallinen tietomalli muodostuu määritellyn prosessin mukaan hyväksytyistä ja julkaistuista ydintiedoista: FHIR Resursseista, Profiileista Laajennoksista ja Kyselyistä Jos voimassa oleva tietomalli ei mahdollista tietyn tiedon tallentamista, voidaan tietomallia laajentaa 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 tallennettua tietoa voidaan käyttää kaikissa alustaan liitetyissä palveluissa Kansalainen antaa Omatietovarannon tarjoamassa käyttöliittymässä vahvasti tunnistautuneena sovellukselle luvan tallentaa ja käyttää Omatietovarantoon tallennettua tietoa käyttöönottaessaan sovellusta (luvituskäytäntö) Omatietovarantoon tallennettua tietoa ei voi rajata näkymästä muille vastaavia tietoja käsitteleville sovelluksille Kaikkea tietoa ei ole tarpeen tallentaa tai siirtää kansalliselle alustalle, esimerkiksi mikäli tieto ei liity kansalaisen terveyteen tai hyvinvointiin. Tekniset sovelluksen sisäiset ohjaustiedot tallennetaan aina palvelun omaan tietokantaan.

8 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 prosessin mukaan lisätä palvelualustalle kehitys- ja testiympäristöihin 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 Esityksen nimi / Tekijä

9 Omatietovaranto - tietomallin hallinnan prosessi
Muutostarve voi olla suurempi kun se kohdistuu myös Kelan ylläpitämän käsittelylogiikkaan. Muutos vaikuttaa mahdollisesti myös muihin palvelualustan toimijoihin. 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

10 Tietomallin muuttamisen prosessi – yleiskuva sovellusten kehittäjien näkökulmasta

11 Tietomallin hallinnan prosessi – tarkempi kuvaus

12 Tietomallin hallinnan prosessi – toimintojen kuvaukset 1
Elementin nimi Tyyppi Selite a.Tarvitsee muutoksen Omatietovarannon tietomalliin Start Event Hyvinvointisovelluksen kehittäjä haluaa laajentaa tai muuttaa Omatietovarannon kansallista tietomallia b.Haluaa arvion toteutettavuudesta? Gateway Halutessaan arvion tietosisällön laajennoksen tai muutoksen soveltuvuudesta osaksi Omatietovarannon sisältöä hyvinvointisovelluksen kehittäjä voi pyytää toteutettavuuden arviointia Kelalta ja HL7 PH sig:iltä. Arviointia voi pyytää missä tahansa kehitystyön vaiheessa, esim. pelkästä ideasta tai jo pitkälle kehitetystä sovelluksesta. Toteutettavuuden arviointi on aina tehtävä, mikäli muutokseen liittyy tarve lisätä/muuttaa olemassa olevaa palvelualustan toiminnallisuutta. a) toteutettavuuden arviointipyyntö lähetetään kantakehitys-postilaatikkoon (Kela vie pyynnön tiketöintijärjestelmään) b) Toteutettavuuden arviointipyyntö lisätään tiketöintijärjestelmään (JIRA) kts. erillinen ohje linkki tähän. (tämä ei vielä ole teknisesti mahdollista, toimitaan vaihtoehdon a mukaisesti kunnes kehittäjille saadaan pääsy Jiraan) Pyyntöön on lisättävä aihe (=Omatietovaranto toteutettavuuden arviointipyyntö) sekä tarvittava kuvaus ehdotetusta tietomallin muutoksesta. c.Arvioi muutoksen toteutettavuuden Task Kela ja HL7 PH sig arvioivat uuden profiilin tai laajennoksen soveltuvuutta osaksi Omatietovarannon sisältöä ja antavat palautteen hyvinvointisovelluksen kehittäjälle neljän viikon kuluessa esiarviointipyynnön tekemisestä. Kela ottaa tarvittaessa arviointiin mukaan myös Terveyden ja hyvinvoinnin laitoksen (THL), esim. kliiniseen arvioinnin tekemiseen sekä 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 Kelassa ja niiden aikatauluista tiedotetaan prosessin edetessä.

13 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 Kela käsittelee ehdotetun muutoksen ja päättää toteutuksesta. Kela priorisoi hyväksytyn muutoksen ja aikatauluttaa oman työnsä. Päätös välitetään hyvinvointisovelluksen kehittäjälle tiedoksi. f.Hyväksytäänkö tehtäväksi? Hyväksyykö Kela 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 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ä? 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 Hyvinvointisovelluksen kehittäjä lisää hyvinvointisovelluksen tarvitsemat tietomallin laajennokset (esim. uuden kansalliseen pohaprofiilliin perustuvan profiilin tai profiilin laajennoksen) Kelan Sandbox-ympäristöön. Status-tiedoksi asetetaan tässä vaiheessa 'draft' ja experimental-tiedoksi 'true'. Ohjeet Sandbox-ympäristön päivittämiseen <viittaus>

14 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. a) katselmointipyyntö lähetetään kantakehitys-postilaatikkoon (Kela vie/päivittää pyynnön tiketöintijärjestelmään) b) katslmointipyyntö lisätään/päivitetään tiketöintijärjestelmään (JIRA) kts. erillinen ohje linkki tähän Pyyntöön on lisättävä aihe (=Omatietovaranto katselmointipyyntö), käyttötarkoitus, ja tiedot profiilirekisteriin tehdyistä päivityksistä. l.Katselmoi muutoksen HL7 PH sig katselmoi tietomallin laajennoksen, huomioiden samat seikat kuin toteutettavuuden arvioinnissa, ja antaa joko myönteisen tai perustellun kielteisen kannanoton. Mahdollisesti tekee muutosehdotuksia. Kannanotto annetaan 2-3 viikon kuluessa katselmointipyynnön tekemisestä. m.Katselmoi muutoksen Kela katselmoi tietomallin laajennoksen huomioiden samat seikat kuin toteutettavuuden arvioinnissa. Kela huomioi HL7 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ää viimeistään 4 viikon kuluttua katslmointipyynnön tekemisestä.

15 Tietomallin hallinnan prosessi – toimintojen kuvaukset 4
Elementin nimi Gateway Selite n.Katselmoinnin tulos? Tietomallin laajennos joko hyväksytään tai siihen esitetään tehtäväksi muutoksia ennen asiakastestaukseen etenemistä. o.Tekee tarvittavat muutokset Task Hyvinvointisovelluksen kehittäjä toteuttaa tarvittaessa katselmoinnissa esiin nousseet tarvittavat muutokset ja päivittää profiilirekisterin tiedot. p.Muuttaa statuksen profiilirekisteriin ja lisää profiilin asiakastestiin 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. q.Asiakastestaus ja sertifiointi prosessi Sub-Process Asiakastestaus- ja sertifiointi-prosessit on tarkemmin kuvattu muualla. r.Muuttaa statuksen aktiiviseksi ja vie kaikki muutokset tuotantoympäristöön 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. s.Päivitetty tietomalli on tuotantokäytössä End Event Tuotantokäyttö voi alkaa