Upload
heinz
View
25
Download
0
Embed Size (px)
DESCRIPTION
Päätöksentuen integraatio - yleiskuva ja jatkokehitys?. Juha Mykkänen, Marko Suhonen, SerAPI-seminaari 9.2., Kuopio. Sisältö. Jatkoa EBMeDS esitykselle (Jorma Komulainen) Yleiskuva rajapinnoista Keskeisiä kysymyksiä kertakutsu vs. päivitykset / "konteksti"tiedot potilastietojen saanti - PowerPoint PPT Presentation
Citation preview
Päätöksentuen integraatio - yleiskuva ja jatkokehitys?
Juha Mykkänen, Marko Suhonen,
SerAPI-seminaari 9.2., Kuopio
Sisältö
Jatkoa EBMeDS esitykselle (Jorma Komulainen) Yleiskuva rajapinnoista Keskeisiä kysymyksiä
kertakutsu vs. päivitykset / "konteksti"tiedot potilastietojen saanti käynnistystilanteet tietojen koodaus
Osion tavoitteena saada kuva nykytilanteesta ja kehitystarpeista erilaisia selvityksiä ja ratkaisumalleja esitetty (3 kpl?) tärkeiden kysymysten esiin nostaminen
Kuinka isoja muutoksia nykyratkaisuihin tarvitaan / voidaan tehdä
Päätöksentuki
Päätöksentukipalvelu, tarvitsee: skriptit, tietämys päätöksentuessa tarvittava potilastieto
ks. ydintietopaketti käynnistys ja palautteen näyttäminen
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
Päätöksentuki
EPR
Tietämys
TietämysPäätöksentuki
EHRS
Lääke
Päätöksentuki-gui
Hoitosuositukset
Skripit, logiikka tms.
Tiedot
Tiedot
Tiedot
Palaute
Tulokset
Muut
Asikaskomponentti
Lääketietokannat
Kys1. Miten päätöksentuki toimii?
Kertakutsu - (kaikki tiedot kerralla) alkuper. Lähetettävä aina kaikki ydintiedot joita saattaa tarvita, myös
esim. kun valitaan uutta lääkitystä? yksi operaatio, ExecuteDS() WSDL-rajapinta? Ydintietojen skeema määritelty WSDL-
kuvauksessa - onko "tavallisia" WSDL parametreja? Päivitys (peruslataus ja 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
tehtävissä joko päätöksentuki-CDA-lomakkeella tai [toinen tapa]
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
Päätöksentukipalvelun toiminta - kertakutsulla
Asiakassovellus Päätöksentukipalvelu Skriptikanta Skriptitulkki
ExecuteDS()SQL_kysely()
Suoritettavat skriptit
tulkkaa_skriptit()
aseta_ydintiedot()
suorita_skriptit()
suorita_skriptit()
skriptien palautteetskriptien palautteet
Kertakutsu ei riitä?
Aina kaikki tiedot siirrettävä (tietomassa)? Aina kaikki tietoihin sopivat skriptit suoritettava?
"Skriptejä voi kaiken kaikkiaan olla jopa 1000 kpl, mutta niitä suoritetaan yleensä vain muutama sata, koska niiden kerralla suoritusta rajataan skriptien metatiedoilla. Metatiedot tallennetaan tietokantaan, johon merkitään esim. että skripti Scr00014 poimitaan suoritukseen vain, jos potilasdatasta löytyy laboratoriotutkimuskoodi 2095." [Kononen]
Tiedon muuttuessa lisätään se pakettiin ja suoritetaan taas kaikki skriptit, ei vain se johon muuttunut tieto liittyy? updateDS() - päivitysdata; suoritetaanko vain päivitystiedoille
skriptit?? Pitäisi voida valita vain osa skripteistä / tietty käyttötapaus -
valinta täsmäävien tietojen tai käyttökontekstin (esim. lääkkeisiin liittyvät) pohjalta automaattisesti metatietojen perusteella?
Päätöksentukipalvelun toiminta - päivityksillä
Java-toteutus initDS() käynnistää ja luo istunnon päätöksentukiasiakkaalle, alustaa
palvelimen kieliasetuksilla ja luo valmiiksi käytettävät oliot executeDS() tuo palvelimelle potilasdatan asiakkaalta ja käynnistää
päätöksentukianalyysiin liittyvät eri vaiheet updateDS() päivitystietojen lähettämistä varten. Kun asiakas on
luonut istunnon palvelimen kanssa, palvelin osaa säilyttää lähetetyn potilasdatan istunnon ajan. Tällöin palvelimelle voidaan lähettää updateDS()-funktiolla päivitystietoja, kuten lääkärin valitsema lääke tietokannasta. Päivitysfunktio suorittaa tämän jälkeen päätöksentukianalyysin potilasdatan ja päivitystietojen avulla.
Open CDA-malli Ensin kaikki ydintietolomakkeet + päätöksentuen oma lomake Muuttuneet tiedot erikseen päätöksentuen omalla lomakkeella Jos tiedonvälitys CDA-dokumentteina, samaan "sessioon" kuuluvat
dokumentit liitetään toisiinsa CDAn setId:n ja yksilöidään CDA-headerin versionumeron avulla
Kys2: Potilastietojen saantivaihtoehdot
Päätöksentuessa tarvittavat ydintiedot: miten kattavat tiedot tarvitaan, käyttävä järjestelmä kokoaa Yleistiedot potilaasta, Diagnoosilista, Lääkityslista, Allergialista,
Laboratoriotutkimukset, Toimenpiteet [Kononen] Asiakaskomponentti voi toimia välittäjänä: tiedot oikeaan muotoon,
viestintä Voiko se myös hakea eri tietovarastoista tarvittavat tiedot (ja miten ne
määritellään), eri rajapinta asiakaskomponentille? Vaihtoehdot:
Ydintietopaketti potilastietojärjestelmästä päätöksentuelle käynnistävä järjestelmä kokoaa ja lähettää ne kutsun mukana CDA r2 ensisijainen syötetiedon muoto, päätöksentukisovellus suodattaa
skripteille
Tiedot "suoraan" tietovarastosta päätöksentuelle päätöksentuki käy hakemassa tarvitsemansa tiedot tietovarastosta:
periaatteessa mahdollistaa rajapinnat useisiin järjestelmiin viitejärjestelmän kautta?, mahdollisesti kun kansallinen arkisto saatavilla
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
Asiakaskomponentti
Päätöksentuen tietojensaannin vaihtoehtoja (yhdistelmät mahdollisia)
pelkät Open CDA-lomakkeet? päätöksentuen oma XML (DS CDA)?
esim. XSLT-muunnoksella muodostettu, päätettävä kuka muodostaa
WSDL:llä määritellyt tietorakenteet tiedot joiden avulla voi hakea tarvittavat tiedot muualta?
lisäksi käyttökontekstitieto erikseen tai oman XML:n avulla vain muuttuneet päätöksentuen tiedot (uusi lääke) vai erillinen
tieto kontekstista (tehdään lääkemääräystä)
määriteltävä vastuut (kutsuva sovellus, asiakaskomponentti, päätöksentuki)
Kys3. Päätöksentuen käynnistystilanteet
käyttötilanteita: muistutteet järjestelmän käytön yhteydessä, hoitosuosituksen seuraaminen, virtuaalinen terveystarkastus
Ainakin (mitä tarvitaan, mistä liikkeelle) Potilaan tietojen avaaminen Uuden lääkkeen valinta lääkemääräystä varten Diagnoosin valinta Tutkimuksen tai toimenpiteen valinta (mitä varten?) 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? huomautusten (paluu)formaatti jo määritelty
(kontekstiriipuvainen)?
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
Uuden lääkkeen määrääminen tarkemmin?
potilaan valinta (perustiedot, riskitiedot päätöksentuelle) tutkimus, diagnoosi kirjaukset (lisätiedot
päätöksentuelle, ei huomautusta) lääkemääräyksen teko (jossa lääkkeen valinta, lisätiedot
päätöksentuelle) huomautuksen näyttäminen (esim. huomautus
allergiasta tai yhteisvaikutuksista)
lääkityslista tulossa eri järjestelmiin, pitäisikö sitä käyttää sellaisenaan
vain lääkitykseen liittyviä tietoja UpdateDS:ssä, muita tulossa?
Kys 4. Tietojen koodaus
Skripteissä tutkittavat koodit oltava lopulta samoja kuin potilastiedoissa
Potilastietojärjestelmissä 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ö
Skripteissä käytettävät koodit nyt kovakoodattu skripteihin? Varautuminen koodistomuutoksiin
sopiminen (vaaditaan tietty koodisto + versio)? paikallinen mäppäys (koodimuuttujatietokanta)? välitys (avoin terminologiapalvelu)?
Tarvitaanko välityskerros (terminologiapalvelu) ja/tai käytetyn koodiston yksilöinti myös päätöksentuen rajapinnassa?
Tietämys
Päätöksentukea käyttäväjärjestelmä
Päätöksentuki
Potilas-tiedot
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
(koodimuuttujatietokanta)? välitys (avoin
terminologiapalvelu)?
Lisäkysymyksiä
Eristyskerrokset (vientiä varten) pohdittavaksi laitettavia 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)
Eteneminen
Tarvitaanko uusi tai tarkennettu rajapintamääritys? mikä vaihtoehdoista on käytössä / ensisijainen pohja? tavoitteena tarkka nimettyjen käyttötilanteiden tuki JA
(päätöksentuen yksinkertaisuus VAI mahd. helppo liitettävyys potilasjärjestelmiin)?
Vai onko ensin vielä tarkennettava koko päätöksentuen arkkitehtuuria?
Hankkeiden suunnitelmat käyttöönotoista, kumppanit, tekijät? Java/JavaScript-vertailu, kevät 06
Vientimahdollisuudet? Decision Support Service / Healthcare Services Specification
Project? Tietämyksen liittämisen eri mallit?
skriptien vaihtoehdot, Arden, Gello, tietämysmoduulit jne.
Kiitokset
erityiskiitokset:
Maritta Korhonen
Ilkka Kunnamo
Mika Sipilä
työpajaosallistujat