Päätöksentuen arkkitehtuurit ja rajapinnat (Päätöksentuen teknologia)

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. 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 Agendarunko 15.8.

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) s.4 • 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

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 s.5 • Päätöksentuki tarvitsee: • skriptit, tietämys • päätöksentuessa tarvittava potilastieto • käynnistys ja palautteen näyttäminen (+sulkulistat) • tietojen yhteismitallistaminen (=koodistot)

9. Osien vastuut ja tehtävät s.5 • 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

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 s.8 • 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)?

13. Kertakutsu vai päivityspaketit s.10 • 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

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

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

16. Päivityspaketit vai kertakutsu - vertailua s.10-11 • 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?

17. Vaihtoehtojen vaikutuksia s.22

18. Tietämyksen ja tietotarpeiden neuvottelu (päivityspakettien / kertakutsun lisäksi)? s.22 • 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

19. HL7 DSS - toiminnot

20. Sulkulistat s.20 • 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

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 s.12 • 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)

23. Vertailu: ydintietomäärittelyt vs. päätöksentuen tarvitsemat tiedot s.12-17 • 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?

24. Ydintiedot / päätöksentuki kysymyksiä s.12-17 • 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,

25. Päätöksentuen palautteiden tiedot s.17 • 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

26. CDA:n käyttö päätöksentuessa s.17-19 • 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"

27. Vaihtoehtojen vaikutuksia s.22

28. Koodistojen käyttö s.6 • 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)?

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

30. Lisäkysymyksiä 1 s.17 • 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?

31. Lisäkysymyksiä 2 s.17 • 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)

32. Jatkon tarkennukset

33. Priorisointia: suurin joustavuus / avoimuus s.22 • 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

34. Priorisointia: helppo liitettävyys potilastietojärjestelmän kannalta s.23 • 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?

35. Priorisointia: helppo siirtyminen nykypilotista s.24 • 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)

36. Priorisointia: tehokkuuden optimointi s.24 • 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?

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