Download
p t ksentuen arkkitehtuurit ja rajapinnat p t ksentuen teknologia n.
Skip this Video
Loading SlideShow in 5 Seconds..
Päätöksentuen arkkitehtuurit ja rajapinnat (Päätöksentuen teknologia) PowerPoint Presentation
Download Presentation
Päätöksentuen arkkitehtuurit ja rajapinnat (Päätöksentuen teknologia)

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

140 Views Download Presentation
Download Presentation

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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/