Omakannan omatietovaranto aka Kansallinen PHR. Konstantin Hyppönen, Kanta-palvelut, Kela HL7 Finland PH SIG -kokous

Transkriptio

1 Omakannan omatietovaranto aka Kansallinen PHR Konstantin Hyppönen, Kanta-palvelut, Kela HL7 Finland PH SIG -kokous

2 Sisällys Johdanto projektiin Omakannan omatietovarannon asema Kanta-arkkitehtuurissa Projektin tavoitteet ja aikataulu Tietosisältöjen läpikäynti Yleistä tietomallinnuksesta Fysiologiset mittaukset Itsehoitolääkitys 2

3 JOHDANTO PROJEKTIIN

4 epsos NCP Kanta-viestinvälitys Potilaan tiedonhallintapalvelu Julkiset palveluntuottajat Sairaanhoitopiirit (20) Kanta-palvelut Lääketietokanta Perus-TH (192) Reseptikeskus Lääkemääräykset Toimitukset Yksityiset palveluntuottajat (4000) Apteekit (~800) Potilastiedon arkisto Palvelutapahtumat Hoitoasiakirjat Lokit Uusimiset Lokit Vanhat asiakirjat SOTE-ammattilaiset Kelain Potilaan keskeiset terveystiedot (koosteet) Diagnoosit Riskit Muut koosteet Ruotsin epsos-yhteyspiste Yhteys suljettu pilotin jälkeen Suostumuksenhallinta ja tahdonilmaisut Suostumukset ja kiellot Tahdonilmaisut, kuten hoitotahto Kansalaiset (> ) Sosiaalihuollon palveluntuottajat Yli 18 v Kuvaarkisto Omakanta Omatietovaranto (PHR) Potilaan omat tiedot Sosiaalihuollon asiakastiedon arkisto Asiakasasiakirjat Asiakkuudet Asiat Tekniset standardit HL7 V3: CDA R2 taso 3 ja Medical Records HL7 FHIR DSTU2 (PHR) JSON, XHTML (PHR ja sh-arkisto) PDF/A (vanhat tiedot ja sh-arkisto) IHE IT-I Profiles (Kuva-arkistossa) W3C XML DSig WS Addressing, WS-I TLS, X.509 Muut kansalliset palvelut Vanhat asiakirjat Koosteiden palautus Lokit Koodistopalvelu Koodistot ja terminologiat Lomakerakenteet Apteekkirekisteri SOTE-organisaatiorekisteri KaPA Varmennepalvelut TH- ja SH-ammattilaisten rekisterit

5 Projektin tehtävänä on Suunnitella, toteuttaa ja ottaa käyttöön omia terveys- ja hyvinvointitietoja sisältävä tietoturvallinen tietovaranto ja rajapinnat Tuotantoon syksyllä 2017 Myös uusien sovellusten liittämiseen tarvittavat toiminnallisuudet Rakentaa Omakantaan integroitava kansalaisen käyttöliittymä suostumusten antamiseen ja itse tallennettujen tietojen katseluun ja poistoon Rajaus: Omakannassa ei mahdollisuutta tietojen syöttämiseen Kolmansilla osapuolilla paljon tekemistä ja vaikutusmahdollisuuksia Julkaista sovellusten kehittäjille tarkoitetut rajapinta- ja tietomäärittelyt kanta.fi sivustolla Kehittää prosessi tietomallin hallintaan 5

6 Omatietovarannon arkkitehtuuri Uusi Kanta-palvelu, eri tietovaranto tietojen säilyttämiselle. Ammattilaisten ja kansalaisten kirjaamat tiedot pysyvät loogisella tasolla erillään Tietojen integrointi samaan näkymään on mahdollista tietoja käsittelevässä sovelluksessa Uudet rajapinnat HL7 v3:n sijasta HL7 FHIR DSTU2 Vaikuttaa sekä rajapintoihin että tietosisältöihin Auktorisoinnissa OAuth 2.0, SMART on FHIR -oppaat ja Argonautprojektissa tehty työ huomioitu. Toimintatavat Pyritään julkaisemaan palvelun toteutus avoimena lähdekoodina Korostetaan avoimuutta ja yhteistyötä, myös kansainvälisesti. Sovelluskehittäjät mukaan tekemiseen heti alusta. Kehitysympäristö on auki ja ATK-päiville suunnitteilla FHIR-demo. 6

7 Yhdessä tehdään Vaatimuksista ja määrittelyistä vastaa THL Vaatimukset ja määrittelyt on tuotettu yhteistyössä ODA (Omahoito ja Digitaaliset Arvopalvelut) hankkeen kanssa. Kelan Kanta-palvelut vastaa teknisestä toteutuksesta ja ylläpidosta Kela julkaisee rajapinta- ja tietomäärittelyt kehittäjille kanta.fi-sivustolla 7

8 Standardipohja: HL7 FHIR DSTU 2 Modulaarinen, uuden sukupolven standardikehikko Määrittelee sekä tietorakenteet (resurssit) että rajapinnat (REST-pohjaiset) PHR-tarpeisiin soveltuu mm. seuraavat resurssit Observation. Mittausdata mittalaitteilta ja manuaalisesti. Questionnaire, QuestionnaireResponse. Itsearviointikyselyt, riskitestit. CarePlan. Henkilökohtaiset tavoitteet. Patient. Potilaan perustiedot. Medication ja MedicationStatement. Itsehoitolääkitys. VisionPrescription, silmälasireseptit. Appointment, Slot, Schedule, ajanvaraus. DocumentReference, esim. PDF-muotoinen rakenteistamaton tieto sekä siihen liittyvä metatieto Subscription, herätteiden tilaus. 80/20-ajattelumalli, 80 % tietotarpeista ovat yhteisiä ja huomioitu FHIR-tietorakenteissa, 20 % domain-kohtaisia ja hoidetaan laajennoksilla. Laajennosten lisäksi tarvitaan profiileja ja soveltamisoppaita (StructureDefinition, ImplementationGuide) Tietomallin hallintamalli on suunnitteilla eli kuinka uusia laajennoksia saadaan joustavasti ja hallitusti mukaan. Kehittäjäystävällinen, soveltuu hyvin myös mobiilikäyttöön. Kirjastoja ja työkaluja tarjolla. Ei kuitenkaan vielä normatiivinen standardi, tuorein versio DSTU 2 (Draft Standard for Trial Use). 8

9 Ympäristöt Ympäristö Kehitysympäristö auki Asiakastestiympäristö Syksy 2016 Tuotantoympäristö Syksy 2017 Säännöt Hiekkalaatikkokäyttöön tarkoitettu ympäristö Kaikille avoin, profiileja ja extensioneita voi lisätä vapaasti Toimii ilman rekisteröintiä Jatkossa lisätään joko toinen hiekkalaatikko tai laajennetaan tämä rekisteröintimahdollisuuksilla ja auktorisointimekanismeilla. Rekisteröityjen käyttäjien resursseja ei voi poistaa + mahdollisesti muut edut. Ympäristö liittymis- ja yhteentoimivuustestejä varten Liittymisen ehtona valmis tai melkein valmis sovellus Kela lisää testausta varten tarvittavat profiilit ja extensionit Ympäristö todellista käyttöä varten Liittymisen ehtona testattu ja sertifioitu sovellus Kela lisää AT-ympäristössä toimiviksi todetut profiilit ja extensionit. 9

10 Juuri nyt työn alla FHIR-soveltamisoppaat Kansainvälinen standardi kaipaa kansallisia ohjeita Pyritään kuitenkin lähtökohtaisesti yhteentoimivuuden säilyttämiseen kv-oppaiden kanssa Tietosisältöjen mallinnus Ammattilaisten käyttöön soveltuvat tietomallit ovat osin liian monimutkaisia potilaiden käyttöön Paljon yhteensovittamista ja priorisointia Auktorisointiprotokollien ja tietoturvaominaisuuksien suunnittelu ja toteutus Paljon valmiita pohjia kv-standardeista Osallistuminen ATK-päivien FHIR-demon valmisteluun 10

11 TIETOSISÄLLÖT 11

12 Käsitteet 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 FHIR-resurssin pohjaprofiilia. Esim. Verenpainemittausprofiili rajoittaa Observation-profiilia mm. määräten mitä LOINCkoodeja 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, Observationresurssia joudutaan laajentamaan koska se ei tue tuota tietoa.

13 Omatietovarannon tietosisällön 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. Prosessin mukaisesti rekisteröidyt ja julkaistut laajennokset (extension) ovat kuitenkin sallittuja. 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 sovelusta (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. Jos sovellus nojautuu täysin yhteisen tietomallin mukaisiin rakenteisiin ja julkaistuihin laajennoksiin, PHR voi olla sovelluksen ainoana tietovarantona. 13

14 Tietomalli teknisesti Kaikki profiilit ja extensionit ovat StructureDefinitionrakenteita, jotka on tallennettu yhdelle FHIR(PHR)- palvelimista. Kehittäjät voivat hakea StructureDefinitionit RESTrajapinnan kautta, lisäksi nämä on julkaistu profiilirekisterissä (kanta.fi ja tällä hetkellä myös Simplifier.net). Vastaanotettava data validoidaan julkaistuja StructureDefinitoneita vasten. Tallennettava resurssi kertoo (metatiedon avulla) mitä profiilia se noudattaa, validointi tehdään tätä profiilia vasten. Myös extensionit validoidaan.

15 Tietomallin laajentamisen käytäntö Käyttäjät (sovelluskehittäjät) voivat luoda uusia profiileita ja extensioneita jos kyseinen resurssi on otettu käyttöön kansallisessa tietomallissa ja sille on luotu kansallinen pohjaprofiili. Perusprofiiliin verrattuna kansallinen pohjaprofiili on hiukan tiukempi, mutta silti melko väljä. Esim. voidaan vaatia, että Identifier ja viittaus Patient-resurssiin ovat pakollisia. Jos joku profiili on hyväksytty osaksi kansallista tietomallia, kehittäjät eivät voi muuttaa sitä suoraan Muutostarpeet käsitellään erikseen Kehittäjät pystyvät kuitenkin käyttämään tässäkin tapauksessa tarvittaessa extensioneita, mutta ne eivät saa olla ns. Modifier Extensioneita, jotka muuttavat tietosisällön merkityksen ja vaativat kaikkien profiilia käyttävien tahojen tuen. Kehittäjät pystyvät lisäämään uusia profiileita ja laajennuksia kaikille avoimeen hiekkalaatikkoympäristöön sekä varsinaiseen liittymistä vaativaan asiakastestiympäristöön.

16 Laajemmat muutokset Jos uusi profiili vaatii uutta käsittelylogiikkaa FHIRpalvelimella, muuttaa aktiivista profiilia tai ottaa käyttöön resurssityypin jota ei ole kansallisessa tietomallissa, tarvitaan erillinen muutosprosessi. Jos tarvitaan jotain kokonaan uutta resurssityyppiä, se periaatteessa onnistuu FHIRin keinoin (Basicresurssin profilointimekanismilla) Ehdotetaan, että sellaiset tarpeet käsitellään erikseen. Voidaan esimerkiksi viedä tapaus FHIR-yhteisön tietoon ja tarvittaessa käynnistää uuden resurssityypin suunnitteluprosessi kv-tasolla.

17 Katselmointi- ja hyväksyntäprosessi Uudet profiilit ja extensionit katselmoidaan ja hyväksytään tuotantokäyttöön. Käsittelyn päätavoitteena on tietomallinnustyön tuominen muidenkin toimijoiden tietoon. Toisena tavoitteena on tietomallinnuksen laadun parantaminen ja päällekkäisyyksien välttäminen. Katselmointifoorumi: HL7 PH SIG Hyväksyminen tuotantokäyttöön: Kela, HL7- käsittelyn ja liittymistestauksen jälkeen 17

18 Tavoitteena olevia tietosisältöjä Fysiologiset mittaukset Manuaalisesti syötetyt tai mittareiden tuottamat tiedot, mobiilisovelluksen kautta (yhteys älypuhelimen ja mittalaitteen välillä esim. Bluetoothilla) Verenpaine, syke, paino, pituus, verensokeri, vyötärönympärys, PEF, lämpö Itsehoitolääkitys Ei kuitenkaan vielä integrointia muihin kansallisiin tietojärjestelmiin (Reseptikeskus tai Potilastiedon arkisto) Testien/kyselyjen tulokset Riski- ja itsearviointitestit Hyvinvointitarkastukset Esitietolomakkeiden sisällöt Muut mahdollisuudet: Mahdollisesti muut kansalaisen itse kirjaamat terveyttä koskevat tiedot, kuten veriryhmätiedot, silmälasireseptit Ajanvarauksen tiedot Rakenteistamaton tieto, esimerkiksi potilaan tallentamat skannatut potilasasiakirjat Priorisointi tehdään yhteistyössä ODA-hankkeen ja HL7-yhdistyksen PH SIG -ryhmän kanssa. Sovellusten kehittäjät ovat tervetulleita mukaan. 18

19 Nykyinen prioriteettiehdotussointi Prioriteetti 1 Fysiologiset mittaukset (vyötärönympärys, yläpaine, alapaine, syke, PEF, verensokeri, paino, pituus, lämpö) 2 Itsehoitolääkitys 3 Riskitestit 4 Oirearvio 5 Hyvinvointitarkastus 6 Elämäntavat (mm. tupakointi, päihteiden käyttö) 7 Toimintakyvyn arviot 8 Itsehoitosuunnitelma 9 Hyvinvointisuunnitelma 10 Hyvinvointiin liittyvät tiedot (liikunta, kulutetut kalorit, askeleiden määrä, ruokapäiväkirja jne) 11 Terveys/oire/tuntemuspäiväkirja 12 Tapahtumatiedot? Nämä ovat Kanta-arkistossa, mietittävä mikä on kansalaisen tallentamien ja arkistossa olevien tietojen välinen suhde 13 Diagnoosit 14 Lääkitys (muu kuin itsehoito), varsinkin tieto siitä mitä lääkkeitä potilas todellisuudessa käyttää 15 Rokotukset 16 Laboratorioarvot 17 Aiemmat leikkaukset 19

20 Alustava käsitemallihahmotelma class Class Model Toimenpide (Activ ity) Mittaus (Observ ation) PEF * Verensokeri Hyv inv ointiv almennus Tav oite (Goal) - Tavoitearvo * 0..* Tupakointi Omahoitosuunnitelma Suunnitelma (CarePlan) 0..* Henkilö (Patient) Paino Verenpaine Kyselyn v astaukset (QuestionnaireResponse) 0..* ym. Liikuntasuoritus Älykäs oirearv io (Diabetes) Kysely (Questionnaire) 1 0..* 0..* Allergiat (AllergyIntolerance) 0..* Itsehoitolääkitys (MedicationSatement) 0..* Lääkkeen otto (MedicationAdministration) Insuliiniannos Hyv inv ointitarkastus Älykäs oirearv io (Tuki- ja liikuntaelin) 0..* Rokotukset (Immunization) Herätetilaus - Herätteen tilannut järjestelmä - Mitä tietoja seurataan - Kenen tietoja seurataan Esimerkiksi ammattilaisen pyyntö täyttää hyvinvointitarkastus tai tieto siitä, että ammattilainen haluaa tiedon uusien mittausten tallennuksesta 20

21 Fysiologiset mittaukset Alustavasti mallinnettu ja läpikäyty ODA-hankkeen asiantuntijoiden kanssa: Verenpaine (systolinen ja diastolinen) Syke Pituus Paino Vyötärönympärys PEF-mittaus Lämpö Verensokerimittaus Hengitystaajuus 21

22 Itsehoitolääkitys Alustavasti mallinnettu ja läpikäyty ODA-hankkeen asiantuntijoiden kanssa: Lääkitysmerkintä (MedicationStatement) Ei ole vielä käyty läpi: Lääkkeen kuvaus (Medication) Huomoitavaa: kansallisen lääkityslistan määrittelyprojekti on alkanut Mahdollistaa kansallisen lääkityslistan huomioinnin suunnittelutyössä 22

23 Yleisiä havaintoja mallintamisesta Ammattilaiskäyttöön soveltuvat tietomallit eivät sovellu sellaisenaan PHR-tarpeisiin Ei automaagista yhteentoimivuutta, mutta päästään riittävälle tasolle Valmiita soveltuvia koodistoja ei ole aina olemassa Esimerkiksi sykkeen epäsäännöllisyyttä kuvaava koodisto (vai riittäisikö boolean?) Tai jos kansainvälinen koodisto löytyy, se voi olla turhan laaja (esim. SNOMED CT:n ruumiinosat-koodisto) Joskus kansallinen koodisto löytyy, mutta sen käyttötarkoitus on eri (esim. ENSIH - Kehon lämpötilan mittauspaikka, ensihoitokertomuksen tarpeisiin määritelty, vaikka sinänsä käy hyvin), tämä on kuitenkin pienempi murhe. Tietosisältöjen määrittelyn pohjana pitäisi olla selvitetyt käyttötarpeet. Esimerkiksi itsehoitolääkitysmerkinnän tietosisältö riippuu siitä, mitä itsehoitolääkityksen seurannalla halutaan mahdollistaa. 23

24 24 Jos ehditään, niin katsotaan MÄÄRITTELYLUONNOKSIA

25 Kiitos mielenkiinnosta! Konstantin Hyppönen IT-arkkitehti Kela, Kanta-palvelut 25