Päätöksentuen arkkitehtuurit ja rajapinnat (Päätöksentuen teknologia) Päätöksentukihanke, neuvottelukunnan työkokous 15.8.2006, Helsinki työpaja B, pj.

Esitys aiheesta: "Päätöksentuen arkkitehtuurit ja rajapinnat (Päätöksentuen teknologia) Päätöksentukihanke, neuvottelukunnan työkokous 15.8.2006, Helsinki työpaja B, pj."— Esityksen transkriptio:

1 Päätöksentuen arkkitehtuurit ja rajapinnat (Päätöksentuen teknologia) Päätöksentukihanke, neuvottelukunnan työkokous 15.8.2006, Helsinki työpaja B, pj. Juha Mykkänen, siht. Ilkka Kunnamo

2 Agendarunko 15.8.  10:45-12:15  työpajan tavoitteet ja osallistujat, agendan tarkennus  osallistujien lähtökohdat ja näkemykset  esillä olleita ratkaisuvaihtoehtoja ja tarvittavia tarkennuksia  arkkitehtuurikysymykset  päätöksentuen, potilastietojärjestelmän ja käyttäjän vuorovaikutus  12:15 Lounas  13:15-14:30  tietosisältö- ja tiedon muoto -kysymykset  tarvittavat tiedot  palautteet  CDA:n käyttö  koodistot  muita seikkoja  eri tavoitteiden priorisointi  jatkotoimenpiteet  14:30-15:15 Työpajatyöskentelyn purku

3 Tavoitteet, osallistujat, taustaa  Työpajan tavoitteet  kehitystarpeiden läpikäynti ja priorisointi  vielä tarkennettavien asioiden selvittäminen ja listaus  ratkaisujen tarkentaminen erityisesti toteutettavuuden ja liitettävyyden osalta  Taustaa:  päätöksentuen pilotti toteutettu (ZipIT-ojo, EBMeDS)  päätöksentuen arkkitehtuurit ja rajapinnat -selvitys (SerAPI)  taustalla mm. huhtikuussa pidetty työpaja  päätöksentukihankkeen (EBMeDS) jatkotarpeet  kansainvälinen kehitys (esim. Healthcare Services Specification Project, Decision Support Service)  Potilastietojärjestelmien ja päätöksentukikomponentin / palvelun tilanne ja suunnitelmat?

4 Lähtökohtia (05/06, mahdollista tarkentaa)  päätöksentuki potilastietojärjestelmästä erillisenä palveluna / komponenttina  periaatteessa kaikki perusosat voivat olla vaikka yhden järjestelmän sisällä tai täysin erillisiä  päätöksentukea kutsuva sovellus vastaa tietojen kokoamisesta  nykypilotointien malli, toimii jos kutsuvalla sovelluksella riittävät tiedot  myös lähellä kutsujaa oleva "asiakaskomponentti" voi koota tietoja  päätöksentuki ei itse nouda esim. arkistosta tietoja?  CDA-lomakkeiden soveltuvuuden selvittäminen s.4

5 Keskeisiä tarpeita  riittävä tehokkuus ja käytettävyys (vasteajat yms.)  personoitavuus, toistuvien huomautusten välttäminen  joustavuus ja avoimuus, joilla varmistetaan tulevaisuuden kehitys  riittävän helppo liitettävyys potilastietojärjestelmiin  jo tehdyn työn hyödyntäminen, mm. pilottitoteutus

6 Tarkennettavia ja ratkaistavia kysymyksiä  arkkitehtuuriasiat  eri osien vastuiden tarkennukset  vuorovaikutusasiat  päivityspakettien käyttö tai käyttämättömyys  tietämyksen ja tietotarpeiden dynaaminen valinta  sulkulistojen käyttö  tietosisältöasiat  mitä tietoja päätöksentuessa tarvitaan + mitä se palauttaa (erityisesti rajapinta potilastietojärjestelmään)  tiedon muoto, CDA-lomakkeiden käyttö  koodistot  huom. kaikki ratkaistavissa: oikean tason löytäminen (tärkeimmät tarpeet saavutetaan, järkevä kustannustaso ja työmäärä tavoitteena)

7 Arkkitehtuuriasiat perusosat ja niiden vastuut (potilastietojärjestelmä, päätöksentuki, koodistot) vastuiden tarkennukset

8 Päätöksentuki, perusosat  Päätöksentuki tarvitsee:  skriptit, tietämys  päätöksentuessa tarvittava potilastieto  käynnistys ja palautteen näyttäminen (+sulkulistat)  tietojen yhteismitallistaminen (=koodistot) s.5

9 Osien vastuut ja tehtävät  Potilastietojärjestelmä / asiakassovellus  Potilastietojen noutaminen tai kokoaminen potilastietokannoista tai -varastoista. Useista lähteistä kokoaminen (ESH)?  Lähetettävien viestien kokoaminen päätöksentukipalvelun hyväksymään muotoon  Päätöksentuen kutsuminen / viestien lähettäminen oikeissa tilanteissa  Palautteiden vastaanottaminen ja käsittely / näyttäminen  Päätöksentuki  Potilastietojen vastaanottaminen  Suoritettavien päätöksentukitoimintojen valinta  Tietämyksen soveltaminen ja päätöksentukitoimintojen suorittaminen  Palautteiden tuottaminen ja lähettäminen kutsuvalle sovellukselle  Tietämyskannan vastuut  Tietämyksen säilytys ja tarjoaminen päätöksentuelle s.5

10 Asiakaskomponentti s.7

11 Vuorovaikutusasiat käynnistystilanteet päivityspakettien käyttö tai käyttämättömyys tietämyksen ja tietotarpeiden dynaaminen neuvottelu sulkulistojen käyttö

12 Päätöksentuen käynnistystilanteet  käyttötilanteita: muistutteet järjestelmän käytön yhteydessä, virtuaalinen terveystarkastus, hoitosuosituksen seuraaminen?  Käynnistyksen laukaisevat potilastietojärjestelmässä  Potilaan tietojen avaaminen  Uuden lääkkeen (tai indikaation) valinta lääkemääräystä varten  Diagnoosin valinta  Tutkimuksen tai toimenpiteen valinta  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?  onko päätöksentuen eroteltava eri tilanteet myös tietämyksen tasolla (tietämyksen metatiedoissa hoitoprosessin vaihe tai käynnistystilanne)? s.8

13 Kertakutsu vai päivityspaketit  Kertakutsu - (kaikki tiedot kerralla)  Lähetettävä aina kaikki ydintiedot joita saattaa tarvita, myös esim. kun valitaan uutta lääkitystä?  yksi operaatio, ExecuteDS()  kaikki (mahdollisesti) tarvittavat tiedot yhdellä kutsulla  nykypilotin malli  Päivitys (ensin peruslataus, 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  operaatiot (Init?), Execute, Update, (Clean?)  tehtävissä joko päätöksentuki-CDA-lomakkeella tai ilman niitä  Open CDA + [Kononen]-malli s.10

14 Päätöksentukipalvelun toiminta - kertakutsulla s.11

15 Päätöksentukipalvelun toiminta - päivityspaketeilla s.10

16 Päivityspaketit vai kertakutsu - vertailua  Kertakutsu  suurempi tietomassa toistuvasti siirrettävä  mahdollisesti tehottomuutta tietämyksen valinnassa?  yksinkertainen toteutus (aina samanrakenteiset paketit, ei välttämättä sessio- eikä tilanhallintaa)  Päivityspaketit  suuri tietomassa 1. kutsulla, pieni myöhemmillä  tietämyksen valinnassa voi ottaa huomioon muutokset  monimutkaisempi toteutus (erilaisten pakettien käsittely, sessionhallinta, tilallinen päätöksentukipalvelu)  käyttötilannekohtaisesti määriteltävä päivitystiedot? s.10-11

17 Vaihtoehtojen vaikutuksia Vaihtoehtojen vaikutusten kohteet TietoliikenneAsiakassovellu ksen toteutus Palvelun toteutus Vaihtoehdotkevytraskashelppovaikeahelppovaikea CDAxxx Päätöksentuen CDA (HL7) xxx Ei CDAxxx Päivityspaketitxxx Kertakutsuxxx s.22

18 Tietämyksen ja tietotarpeiden neuvottelu (päivityspakettien / kertakutsun lisäksi)?  vielä joustavampi ratkaisu: potilastietojärjestelmän ja päätöksentuen välillä ei ole lyöty lukkoon käytettäviä tietoja, vaan ne selvitetään ja voidaan valita tietotarpeiden pohjalta dynaamisesti, esim. HL7 DSS  päätöksentukipalvelu "tietämysmoduulien vartijana"  entistä monimutkaisempi protokolla, myös tiettyyn tietämykseen tarvittavien potilastietojen selvittäminen tietämyskohtaisesti, (käytettävän tietämyksen valinta), vain tarvittavien ja saatavilla olevien tietojen lähetys  mahdollistaa monentyyppiset tarpeet ja laajennukset (joustava), myös päivityspaketit  sovittava metatiedon esitysmuodoista  DSS syyskuun HL7 International -lausuntokierroksella s.22

19 HL7 DSS - toiminnot

20 Sulkulistat  erittäin tärkeää pystyä estämään toistuva "turhien" tai "ei-haluttujen" muistutusten näyttö käyttäjä- ja/tai potilaskohtaisesti  käyttäjähallinta aina ainakin potilastietojärjestelmässä  sulkulistat potilastietojärjestelmän vastuulla  palautteen mukana tietämyksen + huomautuksen tunniste, jota potilastietojärjestelmä vertaa sulkulistaan ja voi estää näyttämisen  yksinkertainen malli, vain tietämystunnisteita rajapinnoissa  suoritetaan "turhia" vertailuja tietämyksessä  sulkulistat päätöksentuen vastuulla  käyttäjä- ja potilastietoja välitetään päätöksentuelle  monimutkaisemmat rajapinnat ja päätöksentuen toteutus, käyttäjä- ja potilastunnisteiden duplikointi + sulkulistan käsittelyoperaatiot  välimuoto  parametreilla voi estää tietyn tietämyksen suorittamisen / palautteen  potilastietojärjestelmällä tallessa käyttäjä- ja potilaskohtaiset tietämys / huomautustunnisteet, jotka lähetetään kutsun mukana, päätöksentuki ei suorita/palauta niihin liittyviä muistutteita s.20

21 Tietosisältöasiat päätöksenteon kutsuissa tarvittavat tiedot päätöksentuen palautteet CDA:n käyttö koodistojen käyttö

22 Päätöksenteon kutsuissa tarvittavat tiedot  patient: potilaan perustiedot: syntymäaika, pituus, paino ym.  diagnoseList ICD-10(/ICPC), medicationList, allergyList, testList, procedureList: apuelementit, jotka sisältävät ne elementit, jotka voivat toistua useammin kuin kerran ydintietopaketissa (esim. kun potilaalla useita lääkityksiä.)  diagnoses: potilaalle tehdyt diagnoosit.  medications: lääkitykset ainesosineen, annosteluineen ym. tietoineen.  allergies: allergiat (lääkeaineille).  tests: potilaalle suoritetut/suoritettavat tutkimukset tuloksineen.  procedures: toimenpiteet.  treatmentPlan: jatkohoitosuunnitelma (tietosisältöä ei vielä määritelty) s.12

23 Vertailu: ydintietomäärittelyt vs. päätöksentuen tarvitsemat tiedot  seuraavissa ydintietojoukoissa päätöksentuen tietoja:  potilaan tunnistetiedot  ongelmatiedot ja diagnoosit  terveyteen vaikuttavat tekijät  fysiologiset mittaukset  tutkimukset  toimenpiteet  lääkehoito  preventio  jatkohoidon järjestämistä koskevat tiedot  hoitotyötiedot, toimintakyky, apuvälineet, hoitotahto? s.12-17

24 Ydintiedot / päätöksentuki kysymyksiä  hyödynnetäänkö ydintietolomakkeiden tietosisältöjä vai kootaanko "tarvittavien tietojen" paketti  vaikutus myös CDA-valintaan + koodistoihin  diagnoosien erittely (allergia, herkkyysreaktio, työper. riski, riskitauti, keinoelin, muu riski, hoidon syy, diagnoosi, toimenpidekomplikaatio, lääkeindikaatio, rokotusreaktio, jatkohoidon syy)?  diagnoosien lisätiedot (varmuus, pysyvyys, tyyppi, episodi, asettamis/poistopäiväykset, uusi/vanha)  fysiologisten mittausten koodaustavat, vain tietyt?  tutkimusten / tulosten ja toimenpiteiden rajaukset (mitä mukaan, tehdyt/suunnitellut)  ATC-luokituksen eri tasojen käyttö  CDA-lomakkeita: henkilötietolomake, diagnoosilista, fysiologiset mittaukset?, lähete/hoitopalaute, lääkityslista, laboratoriovastaus  ei CDA-lomakkeita?: terv. vaikuttavat tekijät, preventio, s.12-17

25 Päätöksentuen palautteiden tiedot  näytettävät huomautukset ja varoitukset (nykymalli)  lisäksi  tietämyksen / huomautuksen tunnisteet (esim. sulkulistat)?  linkit lisätietoihin (esim. hoitosuosituksen avaus) / lisätiedot (esim. skriptikuvaus)?  toimintojen käynnistämiseen tarvittavat tiedot (esim. lähetteen kirjoittaminen, lääkemääräys) - koodaustapa?  jos päivityspaketit  sessiotieto, jolla yhdistetään uudet tiedot aiempiin?  jos dynaaminen valinta  tietämyksen kuvailutiedot, tietämyksen tietotarpeet, tietämysmoduulien tunnisteet s.17

26 CDA:n käyttö päätöksentuessa  CDA-dokumenttien käyttö kuten potilaskertomuksessa  paljon tietoa (josta vain osa tarvitaan), näyttömuoto jne.  helppo potilastietojärjestelmälle, jos samat dokumentit kertomusta varten tehty  henkilö- ym. tietoja mukana, turvallisuusvaatimukset  CDA-dokumenttien ja päivitys-CDA:n käyttö  1: kuten edellä, mutta "erikoislomake" päivitystietoja varten  2: erikoislomake päätöksentuen kaikkia tietoja varten  hieman vähemmän tietoa, vaatii muutoksia eri osiin  ei CDA-käyttöä  sopiva rajapintakoodaus (WSDL: nykypilotti, HL7v3?, HL7 templates?)  jos kattava ja tarkka määrittely, hyvä toteutusvälinetuki  jos paljon lisäjoustavuutta, paljon käsityötä  vähiten ylimääräistä tietoa viestinvälityksessä  käyttö vastauksissa?  päätöksentuki ei palauta valmiita lähetteitä / lääkemääräyksiä...  vastauksen tietorakenne ei "dokumentti" s.17-19

27 Vaihtoehtojen vaikutuksia Vaihtoehtojen vaikutusten kohteet TietoliikenneAsiakassovellu ksen toteutus Palvelun toteutus Vaihtoehdotkevytraskashelppovaikeahelppovaikea CDAxxx Päätöksentuen CDA (HL7) xxx Ei CDAxxx Päivityspaketitxxx Kertakutsuxxx s.22

28 Koodistojen käyttö  Skripteissä tutkittavat koodit oltava lopulta samoja kuin potilastiedoissa  Joko käytetyn koodiston (+version) sopiminen tai vastaavuuksien määrittely  Potilastietojärjestelmissä/tiedoissa 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ö  Varautuminen koodistomuutoksiin?  sopiminen (vaaditaan tietty koodisto + versio)?, voidaan päivittää?  paikallinen mäppäys (potilastietojärjestelmän päässä tai päätöksentukipalvelu voi tukea joitakin vastaavuuksia)?  välitys (avoin terminologiapalvelu, esim. HL7 Common Terminology Services)? s.6

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

30 Lisäkysymyksiä 1  valtakunnallinen arkisto  jatkossa päätöksentuki (tai asiakaskomponentti) hakee tietoja valtakunnallisesta arkistosta? (esim. avohoito)  "keskeneräisten asiakirjojen" haku viitteiden avulla? (esim. sairaalahoitojakso)  myös + jatkossa: jos arkisto osaa päätöksentuen CDA:n, ei asiakassovelluksen tarvitse? asiakaskomponentti arkiston ja potilastietojärjestelmän väliin?  valtakunnallinen / paikallinen päätöksentuki  lähtökohtana ollut, että päätöksentuki toimii paikallisesti? (päätöksentuki, potilastietojärjestelmä ja tietämys?), samassa sisäverkossa jne.  tietämyksen lataaminen kansallisesti?  päätöksentukipalvelun alueellinen käyttö?  paikalliset hoitoketju- ja lähete/konsultaatiopyyntölomakkeet? s.17

31 Lisäkysymyksiä 2  käyttäjäroolit ja palveluluokitukset  lisäävät työmäärää tietämyksessä, päätöksentuessa, potilastietojärjestelmässä  vaikea sopia kattavasti, roolit järjestelmäkohtaisia tai paikallisia, palvelujen ja prosessien määrittely paikallista (potilastietojärjestelmän vastuulla)?  eristyskerrokset (esim. vientiä varten) pohdittavaksi 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) s.17

32 Jatkon tarkennukset

33 Priorisointia: suurin joustavuus / avoimuus  paljon tietämyslähteitä eri paikoista  käyttäjä voi valita ja vaikuttaa mitä tietämystä ja tietoja käytetään  tuetaan eri koodistoja / versioita  Seurauksia:  muutoksia arkkitehtuuriin  monimutkaisempi vuorovaikutusprotokolla  tiedon eri esitysmuotojen tukeminen?  HL7 DSS?  koodistojen hallinta avoimella palvelulla (ei suoraan saatavilla)?  määrittelyn ja toteutuksen työmäärän kasvaminen s.22

34 Priorisointia: helppo liitettävyys potilastietojärjestelmän kannalta  potilastietojärjestelmistä "jo löytyvien" ratkaisujen käyttö tai "helpot lisäykset"  CDA-dokumenttien hyödyntäminen, jos tekeillä  Seurauksia:  liikenteen kuorma kasvaa  jos päivityspaketit tai oma päätöksentuen CDA, joka tapauksessa lisätyötä  hyvä laajennettavuus?  TAI pieni lisätyömäärä + hyvä välinetuki  Seurauksia:  nykypilotin malli  liikenteen kuorma vähäisempi  jos päivityspaketit, lisätyötä  WSDL-välineautomaatio, jos voidaan sopia riittävän tarkasti myös tiedoista? s.23

35 Priorisointia: helppo siirtyminen nykypilotista  ei CDA:ta vaan WSDL/SOAP  vain välttämättömät laajennukset rajapintaan  tunnisteet/sulkulistat,  päivityspaketit?  tietojen kokoaminen säilyy potilastietojärjestelmällä  ei tietosisältölaajennuksia  tarkasti sovitut tiedot ja koodistot  Seurauksia  joustavuudesta ja laajennettavuudesta tinkiminen  ei suoraa CDA-standardin hyödyntämistä, liitettävyys esim. kansalliseen arkistoon työläämpää  suorituskyky varmistettava kokeilemalla ilman päivityspaketteja? (tietämyksen määrän kasvaminen) s.24

36 Priorisointia: tehokkuuden optimointi  suorituskyky  nopea tietojen haku potilastietojärjestelmistä (ei dokumentti vaan tietokanta?)  nopea tietämyksen valinta ja suoritus -> päivityspaketit, ei koodistojen vastaavuuksien selvittämistä?, skriptien suorituskyky (esivalintaehdot, ei aina suoritusta)??  nopea tiedonsiirto (mahd. vähän ylimääräistä tietoa) -> päivityspaketit + ei CDA tai päätöksentuen oma CDA  tietojen kokoaminen eri lähteistä hidastaa  käyttäjän työn tukeminen  sulkulistat mukaan  paluuarvojen laajentaminen (linkit, käynnistettävät toiminnot)  suoritettavan tietämyksen valinta? s.24

37 Eteneminen  Järjestelmät ja työnkulut, joihin sovitetaan?  Mitkä tarpeet korostuvat?  Onko vastuista selvyyttä (arkkitehtuuri)?  Tarvitaanko lisää rajapintamäärittelyä?  Miten edetään tietosisältöjen tarkennuksessa, riippuvuudet ydintieto- ja CDA-tarkennuksista?  Kansalliset ja kansainväliset yhteensopivuustarpeet?  Seuraavat askeleet?  nykymallin käyttö + tarkennus?  CDA-pohjalta uusi rajapinta (määrittely + toteutus)?  HL7 DSS-käyttö?

38 Kiitokset www.uta.fi/laitokset/tsph/ebmeds.htm www.centek.fi/serapi hssp-dss.wikispaces.com/ www.uku.fi/tike/his/ehp/ työpajaosallistujat Ilkka Kunnamo, Jorma Komulainen päätöksentuen arkkitehtuurit ja rajapinnat-tiimi / SerAPI: Marko Suhonen, Heli Luostarinen, Esa Paakkanen, Assi Pöyhölä