päätöksentuen arkkitehtuurit ja rajapinnat (päätöksentuen teknologia)
DESCRIPTION
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. 10:45-12:15 työpajan tavoitteet ja osallistujat, agendan tarkennus - PowerPoint PPT PresentationTRANSCRIPT
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
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
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?
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
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
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)
Arkkitehtuuriasiat
perusosat ja niiden vastuut (potilastietojärjestelmä, päätöksentuki,
koodistot)
vastuiden tarkennukset
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)
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
s.5
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
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
s.5
Asiakaskomponenttis.7
Vuorovaikutusasiat
käynnistystilanteet
päivityspakettien käyttö tai käyttämättömyys
tietämyksen ja tietotarpeiden dynaaminen neuvottelu
sulkulistojen käyttö
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)?
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
s.8
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
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
s.10
Päätöksentukipalvelun toiminta - kertakutsulla s.11
Päätöksentukipalvelun toiminta - päivityspaketeilla s.10
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
Vaihtoehtojen vaikutuksia
Vaihtoehtojen vaikutusten kohteet
Tietoliikenne Asiakassovelluksen toteutus
Palveluntoteutus
Vaihtoehdot kevyt raskas helppo vaikea helppo vaikea
CDA x x x
Päätöksentuen CDA (HL7)
x x x
Ei CDA x x x
Päivityspaketit x x x
Kertakutsu x x x
s.22
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
HL7 DSS - toiminnot
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
Tietosisältöasiat
päätöksenteon kutsuissa tarvittavat tiedot
päätöksentuen palautteet
CDA:n käyttö
koodistojen käyttö
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
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
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
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
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
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
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
Vaihtoehtojen vaikutuksia
Vaihtoehtojen vaikutusten kohteet
Tietoliikenne Asiakassovelluksen toteutus
Palveluntoteutus
Vaihtoehdot kevyt raskas helppo vaikea helppo vaikea
CDA x x x
Päätöksentuen CDA (HL7)
x x x
Ei CDA x x x
Päivityspaketit x x x
Kertakutsu x x x
s.22
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)?
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
s.6
Koodistopalvelinten käyttö
P äätöksen tukijä rjestelm än toim in taym päristö terveydenhuollon organ isaatiossa
Organisaationkoodistopalvelin
Koodistotietokanta
Valtakunnallinenkoodistopalvelin
Päätöksentukijärjestelmänkoodimuuttujatietokanta
Organisaationpäätöksentukipalvelin
päivitykset
(kopio
)Päätöksentukijärjestelmän
käyttäjä
koodistojen + versioiden sopiminen (vaaditaan tietty
koodisto + versio)? paikallinen mäppäys välitys (avoin
terminologiapalvelu)?
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
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
Jatkon tarkennukset
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
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
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
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
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ö?
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ä