Päätöksentuen integraatio - yleiskuva ja jatkokehitys? Juha Mykkänen, Marko Suhonen, SerAPI-seminaari 9.2., Kuopio

Sisältö  Jatkoa EBMeDS esitykselle (Jorma Komulainen)  Yleiskuva rajapinnoista  Keskeisiä kysymyksiä  kertakutsu vs. päivitykset / "konteksti"tiedot  potilastietojen saanti  käynnistystilanteet  tietojen koodaus  Osion tavoitteena saada kuva nykytilanteesta ja kehitystarpeista  erilaisia selvityksiä ja ratkaisumalleja esitetty (3 kpl?)  tärkeiden kysymysten esiin nostaminen  Kuinka isoja muutoksia nykyratkaisuihin tarvitaan / voidaan tehdä

Päätöksentuki  Päätöksentukipalvelu, tarvitsee:  skriptit, tietämys  päätöksentuessa tarvittava potilastieto  ks. ydintietopaketti  käynnistys ja palautteen näyttäminen

Päätöksentuki

Kys1. Miten päätöksentuki toimii?  Kertakutsu - (kaikki tiedot kerralla) alkuper.  Lähetettävä aina kaikki ydintiedot joita saattaa tarvita, myös esim. kun valitaan uutta lääkitystä?  yksi operaatio, ExecuteDS()  WSDL-rajapinta? Ydintietojen skeema määritelty WSDL- kuvauksessa - onko "tavallisia" WSDL parametreja?  Päivitys (peruslataus ja muuttuneet tiedot välitetään erikseen)  Peruslatauksella kaikki "saatavilla olevat" potilastiedot ja erikseen määritelty päätöksentuen lisätietopaketti?  Lääkärin käyttäessä muuttuneet/uudet tiedot lähetetään päätöksentukeen uudella ptuki-ydintietolomakkeellta  tehtävissä joko päätöksentuki-CDA-lomakkeella tai [toinen tapa]

Päätöksentukipalvelun toiminta - kertakutsulla AsiakassovellusPäätöksentukipalveluSkriptikantaSkriptitulkki ExecuteDS() SQL_kysely() Suoritettavat skriptit tulkkaa_skriptit() aseta_ydintiedot() suorita_skriptit() skriptien palautteet

Kertakutsu ei riitä?  Aina kaikki tiedot siirrettävä (tietomassa)?  Aina kaikki tietoihin sopivat skriptit suoritettava?  "Skriptejä voi kaiken kaikkiaan olla jopa 1000 kpl, mutta niitä suoritetaan yleensä vain muutama sata, koska niiden kerralla suoritusta rajataan skriptien metatiedoilla. Metatiedot tallennetaan tietokantaan, johon merkitään esim. että skripti Scr00014 poimitaan suoritukseen vain, jos potilasdatasta löytyy laboratoriotutkimuskoodi 2095." [Kononen]  Tiedon muuttuessa lisätään se pakettiin ja suoritetaan taas kaikki skriptit, ei vain se johon muuttunut tieto liittyy?  updateDS() - päivitysdata; suoritetaanko vain päivitystiedoille skriptit??  Pitäisi voida valita vain osa skripteistä / tietty käyttötapaus - valinta täsmäävien tietojen tai käyttökontekstin (esim. lääkkeisiin liittyvät) pohjalta  automaattisesti metatietojen perusteella?

Päätöksentukipalvelun toiminta - päivityksillä  Java-toteutus  initDS() käynnistää ja luo istunnon päätöksentukiasiakkaalle, alustaa palvelimen kieliasetuksilla ja luo valmiiksi käytettävät oliot  executeDS() tuo palvelimelle potilasdatan asiakkaalta ja käynnistää päätöksentukianalyysiin liittyvät eri vaiheet  updateDS() päivitystietojen lähettämistä varten. Kun asiakas on luonut istunnon palvelimen kanssa, palvelin osaa säilyttää lähetetyn potilasdatan istunnon ajan. Tällöin palvelimelle voidaan lähettää updateDS()-funktiolla päivitystietoja, kuten lääkärin valitsema lääke tietokannasta. Päivitysfunktio suorittaa tämän jälkeen päätöksentukianalyysin potilasdatan ja päivitystietojen avulla.  Open CDA-malli  Ensin kaikki ydintietolomakkeet + päätöksentuen oma lomake  Muuttuneet tiedot erikseen päätöksentuen omalla lomakkeella  Jos tiedonvälitys CDA-dokumentteina, samaan "sessioon" kuuluvat dokumentit liitetään toisiinsa CDAn setId:n ja yksilöidään CDA- headerin versionumeron avulla

Kys2: Potilastietojen saantivaihtoehdot  Päätöksentuessa tarvittavat ydintiedot: miten kattavat tiedot tarvitaan, käyttävä järjestelmä kokoaa  Yleistiedot potilaasta, Diagnoosilista, Lääkityslista, Allergialista, Laboratoriotutkimukset, Toimenpiteet [Kononen]  Asiakaskomponentti voi toimia välittäjänä: tiedot oikeaan muotoon, viestintä  Voiko se myös hakea eri tietovarastoista tarvittavat tiedot (ja miten ne määritellään), eri rajapinta asiakaskomponentille?  Vaihtoehdot:  Ydintietopaketti potilastietojärjestelmästä päätöksentuelle  käynnistävä järjestelmä kokoaa ja lähettää ne kutsun mukana  CDA r2 ensisijainen syötetiedon muoto, päätöksentukisovellus suodattaa skripteille  Tiedot "suoraan" tietovarastosta päätöksentuelle  päätöksentuki käy hakemassa tarvitsemansa tiedot tietovarastosta: periaatteessa mahdollistaa rajapinnat useisiin järjestelmiin  viitejärjestelmän kautta?, mahdollisesti kun kansallinen arkisto saatavilla

Asiakaskomponentti

Päätöksentuen tietojensaannin vaihtoehtoja (yhdistelmät mahdollisia)  pelkät Open CDA-lomakkeet?  päätöksentuen oma XML (DS CDA)?  esim. XSLT-muunnoksella muodostettu, päätettävä kuka muodostaa  WSDL:llä määritellyt tietorakenteet  tiedot joiden avulla voi hakea tarvittavat tiedot muualta?  lisäksi käyttökontekstitieto  erikseen tai oman XML:n avulla  vain muuttuneet päätöksentuen tiedot (uusi lääke) vai erillinen tieto kontekstista (tehdään lääkemääräystä)  määriteltävä vastuut (kutsuva sovellus, asiakaskomponentti, päätöksentuki)

Kys3. Päätöksentuen käynnistystilanteet  käyttötilanteita: muistutteet järjestelmän käytön yhteydessä, hoitosuosituksen seuraaminen, virtuaalinen terveystarkastus  Ainakin (mitä tarvitaan, mistä liikkeelle)  Potilaan tietojen avaaminen  Uuden lääkkeen valinta lääkemääräystä varten  Diagnoosin valinta  Tutkimuksen tai toimenpiteen valinta (mitä varten?)  Lähetteen tai konsultaatiopyynnön tekeminen  Manuaalinen käynnistys esim. hoitosuosituksesta  Kaikkien skriptien tai valitun skriptijoukon suoritus eräajona (ns. virtuaalinen terveystarkastus)  mitä päivitys- tai käyttökontekstitietoa eri tilanteissa?  huomautusten (paluu)formaatti jo määritelty (kontekstiriipuvainen)?

Uuden lääkkeen määrääminen tarkemmin?  potilaan valinta (perustiedot, riskitiedot päätöksentuelle)  tutkimus, diagnoosi kirjaukset (lisätiedot päätöksentuelle, ei huomautusta)  lääkemääräyksen teko (jossa lääkkeen valinta, lisätiedot päätöksentuelle)  huomautuksen näyttäminen (esim. huomautus allergiasta tai yhteisvaikutuksista)  lääkityslista tulossa eri järjestelmiin, pitäisikö sitä käyttää sellaisenaan  vain lääkitykseen liittyviä tietoja UpdateDS:ssä, muita tulossa?

Kys 4. Tietojen koodaus  Skripteissä tutkittavat koodit oltava lopulta samoja kuin potilastiedoissa  Potilastietojärjestelmissä ja tietämyksessä omia koodistoja ja niiden versioita  CDA r2 -muodossa nimetään sekä koodisto että versio  päätöksentukipalvelun "sallitut" koodistot  esim. ICD-10 / UMLS -valinta tai metatesauruksen käyttö  Skripteissä käytettävät koodit nyt kovakoodattu skripteihin?  Varautuminen koodistomuutoksiin  sopiminen (vaaditaan tietty koodisto + versio)?  paikallinen mäppäys (koodimuuttujatietokanta)?  välitys (avoin terminologiapalvelu)?  Tarvitaanko välityskerros (terminologiapalvelu) ja/tai käytetyn koodiston yksilöinti myös päätöksentuen rajapinnassa?

Koodistopalvelinten käyttö  koodistojen + versioiden  sopiminen (vaaditaan tietty koodisto + versio)?  paikallinen mäppäys (koodimuuttujatietokanta)?  välitys (avoin terminologiapalvelu)?

Lisäkysymyksiä  Eristyskerrokset (vientiä varten) pohdittavaksi laitettavia asioita, mitä saattaa joutua toteuttamaan eri tavalla eri maissa  mitä koodistoja käytetään kuhunkin käytettävään tietoon, koodistojen oltava sovitettavissa skriptit potilastiedot  huomautusten kieli  tietämyksen kuvaamiseen käytetty tapa  standardi, jolla potilastiedot siirretään  tietojoukot (kaikkialla ei lomakkeita, joissa juuri samat tiedot kuin suomessa)

Eteneminen  Tarvitaanko uusi tai tarkennettu rajapintamääritys?  mikä vaihtoehdoista on käytössä / ensisijainen pohja?  tavoitteena tarkka nimettyjen käyttötilanteiden tuki JA (päätöksentuen yksinkertaisuus VAI mahd. helppo liitettävyys potilasjärjestelmiin)?  Vai onko ensin vielä tarkennettava koko päätöksentuen arkkitehtuuria?  Hankkeiden suunnitelmat käyttöönotoista, kumppanit, tekijät?  Java/JavaScript-vertailu, kevät 06  Vientimahdollisuudet?  Decision Support Service / Healthcare Services Specification Project?  Tietämyksen liittämisen eri mallit?  skriptien vaihtoehdot, Arden, Gello, tietämysmoduulit jne.

Kiitokset erityiskiitokset: Maritta Korhonen Ilkka Kunnamo Mika Sipilä työpajaosallistujat