1 Päätöksentuen arkkitehtuuri ja rajapinnat Päätöksentukihanke, neuvottelukunnan työkokous 13.2.2007, Helsinki Juha Mykkänen, Marko Suhonen Kuopion yliopisto,

Esitys aiheesta: "1 Päätöksentuen arkkitehtuuri ja rajapinnat Päätöksentukihanke, neuvottelukunnan työkokous 13.2.2007, Helsinki Juha Mykkänen, Marko Suhonen Kuopion yliopisto,"— Esityksen transkriptio:

1 1 Päätöksentuen arkkitehtuuri ja rajapinnat Päätöksentukihanke, neuvottelukunnan työkokous 13.2.2007, Helsinki Juha Mykkänen, Marko Suhonen Kuopion yliopisto, HIS-tutkimusyksikkö, SerAPI-hanke

2 2 Lyhyt katsaus  arkkitehtuuri ja rajapinnat: tarpeet ja tavoitteet  aiemmin tehtyjä linjauksia  tilanne ja eteneminen

3 3 Keskeisiä tarpeita (joilla arkkitehtuurivaikutuksia) päätöksentuelle  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

4 4 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)

5 5 Arkkitehtuuri- ja rajapintatyön lähtökohdat  päätöksentuki potilastietojärjestelmiin liitettävänä palveluna / komponenttina  periaatteessa kaikki perusosat voisivat olla vaikka yhden järjestelmän sisällä tai täysin erillisiä  ensisijainen käyttö: huomautukset, muistutukset  toissijainen käyttö?: toiminnan ohjaus  HUOM! erotettava kliininen ja hallinnollinen toiminnan ohjaus  olemassa oleviin potilastietojärjestelmiin liittäminen  kansallisen potilaskertomuksen hyödyntäminen  tietosisällöt, arkkitehtuuri- ja rajapintamäärittelyt?

6 6 2006 työskentelyssä tehtyjä linjauksia  kertakutsu: kaikki päätöksentuen tarvitsemat tiedot lähetetään yhdessä kutsussa  muuttunut tietosisältö merkataan sopivalla tavalla, jotta päätöksentukea pystytään soveltamaan muuttuneisiin tietoihin  asiakaskomponentti: koodistojen sovittaminen, tietojen kokoamiseen, toistuvien huomautusten välttämiseen ja sulkulistojen soveltamiseen käytetään asiakaskomponenttia.  Web services-rajapinta (WSDL/SOAP)  ei suoraan CDA-dokumentteja rajapinnassa, laajennettavuudesta kuitenkin huolehdittava  paluuviesteissä tarvitaan päätöksentuen metadata  huomautusten tunnisteet (sulkulistoja varten), linkkejä, tietämyskuvausta, jatkotoimenpiteiden käynnistykseen tarvittavaa rakenteista tietoa jne.  koodiston ja sen version yksilöinti rajapinnassa, jolloin vastaavuuksia voi määritellä kumpaan päähän tahansa

7 7 Arkkitehtuurit ja rajapinnat - läpikäytyjä vaihtoehtoja Vaihtoehtojen vaikutusten kohteet TietoliikenneAsiakassovelluk sen toteutus Palvelun toteutus Vaihtoehdotkevytraskashelppovaikeahelppovaikea CDAxxx Päätöksentuen CDA (HL7) xxx Ei CDAxxx Päivityspaketitxxx Kertakutsuxxx

8 8 Tilanne / rajapinnat  päätöksentukikomponentin prototyyppi toteutettu aiemmin (Duodecim, ZipIT-ojo-hanke, Prowellness)  päätöksentuen arkkitehtuurit ja rajapinnat -selvitys tuotettu (SerAPI-hanke)  selvityksen pohjalta tehdyt linjaukset (työkokous 08/06)  päätöksentuen rajapintamäärittely käynnissä  tavoiteltuna tuotoksena tarkat rajapintamäärittelyt ja perusratkaisut, joilla päätöksentuki saadaan liitettyä potilastietojärjestelmiin  kansainvälisen kehityksen seuraaminen  Healthcare Services Specification Project - kansainvälinen terveydenhuollon palvelurajapintojen standardointi  Decision Support Service Functional Model: tuore HL7- kokeilustandardi  etenemässä kohti teknistä standardointia (OMG-järjestö)

9 9 Eteneminen + osallistujat  tavoitteet ja tarpeet: ollaanko päätöksentuen toiminnallisista vaatimuksista ja liitettävyyden perusrajauksista samaa mieltä?  erityishuomio jatkossa (tietämyksen laajentamisen lisäksi) tarvittavien tietosisältöjen kehittämisessä, koodistoissa ja suhteessa potilaskertomukseen?  runsaasti tarvittavia tarkennuksia  objektimallin ja rajapintojen kehittämisen yhdistäminen?  huomautukset vai työnkulun ohjaus?  huom: toiminnanohjaus ei kuulu olla päätöksentuki- komponentin vastuulla, vaan potilastieto- / toiminnanohjaus- järjestelmän, päätöksentuen palautteiden perusteella voidaan päätellä tarvittavia tehtäviä  määriteltävä selkeästi päätöksentuen rooli paikallisella tasolla tietojärjestelmäarkkitehtuurissa - lisäarvoa tuottava palvelu?  potilastietojärjestelmänäkökulma: tekniset suuntaviivat olemassa, toiminnallinen ja sisällöllinen taso tarkennettava

10 10 Kiitokset www.uta.fi/laitokset/tsph/ebmeds.htm www.centek.fi/serapi hssp-dss.wikispaces.com/ www.uku.fi/tike/his/ehp/ Ilkka Kunnamo, Jorma Komulainen, Peter Nyberg päätöksentuen arkkitehtuurit ja rajapinnat-tiimi / SerAPI: Marko Suhonen, Heli Luostarinen, Esa Paakkanen, Assi Pöyhölä

11 11 Asiakaskomponentti päätöksentuen arkkitehtuurissa

12 12 Tekninen perusarkkitehtuuri