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ä