PlugIT- kontekstinhallinta

1. PlugIT-kontekstinhallinta Mika Tuomainen mika.tuomainen@savonia-amk.fi Common Services SIG 31.8.2004

2. Sisältö • Taustaa • CCOW-standardi • Miksi CCOW ei käynyt suoraan? • PlugIT-määrittelyn taustaa • PlugIT-kontekstinhallintamäärittelyn läpikäynti • Tietosisältö • Rajapinnat • Identifiointi • Web/http-määrittely • Turvallisuus • Avoimet kohdat • Poikkeavuudet CCOW:sta

3. CCOW-standardi • CCOW (Clinical Context Object Workgroup) • HL7-yhdistyksen ylläpitämä standardi terveydenhuollon työpöytäintegraatioon • kehittyvä standardi • nyt versio 1.5

4. CCOW Context Manager CCOW Annotation Agent Mapping Agent CCOW-arkkitehtuuri • arkkitehtuuri koostuu • Sovellukset: mikä tahansa web- tai Windows-pohjainen sovellus • Context Manager: koordinoi näkymättömissä integraatioon liitettyjä sovelluksia, pitää yllä kontekstia • Mapping Agent & Annotation Agent: yhdenmukaistavat eri sovellusten samaa tarkoittavia tietoja, Suomessa lähinnä käyttäjä Morwood, 2001

5. CCOW-standardi • kuvaa roolit ja vastuut komponenteille • määrittelee yksiselitteisen tietosisällön (kontekstin) • määrittelee rajapinnat komponenttien väliseen kommunikointiin • ei määrää komponenttien implementaatiota (teknologiariippumaton)

6. CCOW-standardi Technology Neutral Context Management Architecture 200 pgs Technology Specific Component Mapping 40 pgs 30 pgs COM Technology-Neutral Subject Data Defn’s Web (CORBA) Technology Specific User Interface 15 pgs Windows/Browser (Swing) Health Level Seven, 2001 (other)

7. Miksi CCOW ei käynyt suoraan? • kokonaisuudessaan CCOW-standardin mukainen toteutus koettiin liian raskaaksi tavaksi toteuttaa integraatiota  ei kotimaisia toteuttajia täydelliselle CCOW-standardin mukaiselle ratkaisulle • täydelliselle CCOW-standardin mukaiselle ratkaisulle ei ole kuin muutama ulkomaalainen tuote  epävarmuustekijänä kontekstinhallintaympäristön hinnoittelu sekä mahdollinen riippuvaisuus toimittajasta • ulkomainen toteuttaja ei kiinnostunut • P-S shp:n nimissä tarjouspyyntö Sentillionin Vergence tuotteesta • ei vastausta tarjouspyyntöön..

8. Miksi CCOW ei käynyt suoraan? • käyttäjien mielestä kontekstin välittäminen järjestelmien kesken ei saa olla automaattista, vaan se halutaan tapahtuvan käyttäjän toiminnosta • tarpeet Suomessa ovat vain tietojen vienti kontekstivarastoon ja niiden haku sieltä, eikä kontekstin vaihtumiseen tarvita automatiikkaa  keskeisin vaadittava toiminnallisuus saavutettavissa kevyemmälläkin ratkaisulla kuin CCOW-standardin mukainen

9. PlugIT-määrittelyn taustaa • työpöytäintegraation soveltamiseksi Suomessa PlugIT-hankkeessa alettiin määritellä kevyempää ratkaisua • ratkaisun pohjana käytettiin CCOW-standardissa määriteltyä työpöytäintegraation toteuttamista • tarkoitus ei kuitenkaan ollut toistaa standardissa jo määriteltyjä vaatimuksia, vaan hahmottaa minimiratkaisua, jolla CCOW-tyyppinen toiminnallisuus olisi saavutettavissa • standardista pyrittiin löytämään vain kaikkein olennaisimmat ja hyödyllisimmät osat, joilla työpöytäintegraation perustoiminnallisuus, käyttäjä- ja potilaskontekstin käsittely, voitaisiin toteuttaa

10. PlugIT-määrittelyn taustaa • käytännössä toteutus on palvelinpohjainen tietovarasto, johon kukin kontekstinhallinnan piiriin kuuluva sovellus voi tehdä tietojen hakuja ja päivityksiä • palvelinpohjaisuuden etuna on, että kontekstinhallinta saadaan toimimaan eri tekniikoilla toteutettujen järjestelmien kesken • käyttäjälähtöisyys • ei automaattista kontekstin vaihtamista • yksinkertaistaa kontekstinhallinnan toteuttamista

11. PlugIT-kontekstinhallintamäärittely • määrittelyn avulla mahdollista toteuttaa • kertakirjautuminen • yhteiseen kontekstiin siirtyminen (kontekstin synkronointi) • käyttäjälle tarjotaan yhdenmukainen näkymä käsiteltävään tietoon huolimatta tarpeesta käsitellä tietoa useissa eri järjestelmissä • helpottaa erillisten järjestelmien yhtäaikaista käyttöä ja parantaa näin käyttäjän työprosesseja, joista tulee tehok-kaampia ja paremmin työnkulkua tukevia

12. PlugIT-kontekstinhallintamäärittely • yksinkertaistaa kontekstinhallinnan toteutusta: • osallistuvien sovellusten ei tarvitse toteuttaa rajapintoja (CCOW-standardin ContextParticipant), koska context manager ei koskaan kutsu sovelluksia • context managerin tarvitsee toteuttaa vain kontekstinhallintaan liittymisessä tarvittavat join / leave ja kontekstin tietosisällön käsittelyssä tarvittavat get/set tyyppiset metodit rajapinnassaan • kartoitusvaihetta (survey phase) ei tarvitse suorittaa, mikä yksinkertaistaa context manager komponentin toteutusta huomattavasti • context manager pitää yllä vain yhtä viimeisimmäksi asetettua kontekstia

13. PlugIT-määrittelyn tietosisältö Määrittelee yhteisen kontekstin: • Potilassubjekti • Patient.Id.NationalIdNumber • hetu • Käyttäjäsubjekti • User.Id.Logon • geneerinen id • mappaus sovelluksissa • Custom subject • jos ei löydy standardista/määrittelystä, määritellään itse • erottimena avainsana (organisaation W3C domain-nimi)

14. PlugIT-määrittelyn tietosisältö • custom subject esimerkit • [plugit.fi]DateRange • [plugit.fi]DateRange.Id. [plugit.fi]StartDate • Patient.Co.[plugit.fi]Current_medications

15. PlugIT-määrittelyn rajapinnat • CCOW-standardin rajapinnat (ja nämäkin karsittuina versioina): • ContextManager-rajapinta: kontekstinhallintaan liittyminen ja siitä eroaminen • ContextData-rajapinta: kontekstin tiedon käsittely

16. PlugIT-määrittelyn rajapinnat • ContextManager • JoinCommonContext (kontekstinhallintaan liittyminen) • inputs(string applicationName) • outputs(long participantCoupon) • LeaveCommonContext (kontekstinhallinnasta eroaminen) • inputs(long participantCoupon) • outputs()

17. PlugIT-määrittelyn rajapinnat • ContextData • setItemValues (tietojen asettaminen kontekstiin) • inputs (long participantCoupon, string[ ] itemNames, string[ ] itemValues) • outputs () • getItemValues (tietojen hakeminen kontekstista) • inputs (long participantCoupon, string[ ] itemNames) • outputs (string[ ] itemValues)

18. Identifiointi • sovelluksen/työaseman identifiointi: • applicationName: sovelluksen nimi. Sovelluksen nimen avulla sovellus tunnistautuu context manager-komponentille. Nimen avulla voidaan myös kertoa etukäteen context managerille, mitkä sovellukset voivat osallistua yhteiseen kontekstiin • participant coupon: tunnus, jonka context manager-komponentti antaa sovellukselle sen liittyessä kontekstinhallintaan. Parametri yksilöi kontekstiin osallistuvan sovelluksen ja sovelluksen on käytettävä sitä jatkossa ollessaan yhteydessä context manageriin • työaseman ip / työaseman tunnus: tarvitaan työaseman tunnistamiseen, kun context manager on palvelimella (web/http-määrittely)

20. Web/http-määrittely • viestinvälitys http-viesteillä • mallina CCOW-standardin tapa muodostaa http-viestit • huomioitava • työaseman tunnistaminen web-sovelluksissa • turvallisuus • ”pollaukset”

21. http-viestien muodostaminen http://url.fi/cm?interface=ContextManager&method=JoinCommonContext&applicationName= . . . Kutsuttava metodi Kutsuttavan komponentin URL-osoite Kutsun parametrit Kutsuttava rajapinta

22. Työaseman tunnistaminen web-sovelluksissa • työaseman ip:n välitys • tarvitaan erillinen metodi • JoinCommonContextWithIp • ei CCOW-standardissa

23. Turvallisuus PlugIT-määrittelyssä • tällä hetkellä turvallisuutta ei oteta huomioon sovellustasolla • liikenne salattava, kun tietoa liikutellaan verkossa (https) • ratkaistava, kuinka sovellukset voivat luottaa toisiinsa • suurin ongelma käyttäjäkontekstin asettamisessa

24. Turvallisuus PlugIT-määrittelyssä RATKAISUVAIHTOEHDOT: • käyttäjätunnuksen asetus vain luotetun sovelluksen kautta ja ei SetItemValues-metodilla  kontekstinhallintatoteutuksen tarjottava erillinen metodi käyttäjätunnuksen asetukseen • käyttäjätunnuksen asetus SetItemValues-metodilla siten, että käytetään jotain yleisesti käytettävää ratkaisua komponenttien autentikointiin ja tiedon eheyden varmistamiseen. Esimerkiksi SSL:ää käyttämällä voidaan toteuttaa eri osapuolien autentikointi, tiedon eheyden varmistaminen ja tiedon salaus • CCOW-standardin mukaisilla rajapinnoilla

25. Avoimet kohdat • Turvallisuus • Määrittelyn seuraaviin versioihin on mietittävä, löytyykö yhtä yhteistä standardiratkaisua turvallisuuden huomioimiseen vai jääkö sen toteuttaminen toteutuskohtaiseksi • Pollaukset • Huomioitava sovelluksen/palvelun kaatuminen web-ympäristössä • GetItemValues • Sovellukselle aikaleima • Laajentaminen • Lisätiedot kontekstiin (uudet tiedot ja subjektit) • http content-type

26. Poikkeavuudet CCOW:sta • osallistuvien sovellusten ei tarvitse toteuttaa rajapintoja, koska koordinaattori ei koskaan kutsu sovelluksia • koordinaattorin tarvitsee toteuttaa vain kontekstinhallintaan liittymisessä tarvittavat join / leave ja kontekstin tietosisällön käsittelyssä tarvittavat get/set tyyppiset metodit rajapinnassaan • kartoitusvaihetta (survey phase) ei tarvitse suorittaa • sovellukset eivät päivitä tilaansa automaattisesti, vaan ainoastaan käyttäjän niin halutessa

27. Poikkeavuudet CCOW:sta • palvelinpohjaiseen määritykseen on lisätty metodi JoinCommonWithIp, jota ei löydy CCOW-standardista • turvallisuutta ei ole ratkaistu CCOW-standardin mukaisella tavalla • HTTP-kutsujen muoto on text/plain, CCOW-standardissa HTTP-kutsujen muoto on applicati-on/x-www-form-urlencoded

30. ContextHL7-pakettiPlugIT-kontekstihallintaan liittyviä määrityksiä ja toteutuksia Mika Tuomainen mika.tuomainen@savonia-amk.fi Common Services SIG 31.8.2004

31. Määritysdokumentit • Minimitason kontekstihallinnan määrittely, versio 1 • Kontekstinhallinta-v1.pdf • Kontekstinhallinta-v1.doc • Kontekstihallinnan määrittely, versio 2 • Kontekstinhallinta-v2.pdf • Kontekstinhallinta-v2.doc • Suomen HL7-yhdistys pyytää lausuntoa versiosta 2

32. Kontekstipalvelun referenssitoteutus • Kontekstipalvelu (v1.0)-sovellus • CtxtServerUku.exe • perustuu PlugIT-kontekstinhallintamäärityksen versioon 1 • Kuopion yliopiston toteuttama taustamateriaali PlugIT-hankkeelle • rajattu kuuteen yhtäaikaiseen liittyvään sovellukseen • Toteutuksen kuvaus-dokumentti • CtxtServer.rtf • sisältää asennus-, asetus- ja käyttöohjeet kontekstipalvelun käyttämiseksi

33. Kontekstipalvelua käyttävät referenssitoteutukset • Kontekstipalvelun MS Visual Studio .NET –asiakassovellus • Testisovellus Testi1.exe • Toteutuksen kuvaus: Asiakassovelluksen käyttöönotto-ohje sekä toteutuskohtaisten ratkaisujen dokumentointi sovelluksen käyttöönottoa varten • Visual Studio .NET (C#) –lähdekoodi • toteutusdokumentaatio • Toteutusraportti vanhan FileMan (Musti)/RPC Broker/FixIT-asiakassovelluksen liittämisestä kontekstihallintaan • Toteutuskokemukset-Musti-FixIT.doc

34. Kontekstipalvelinten testaus • kontekstipalvelinten testaussovellus • CtxtClient.exe • testaussovelluksen käyttö- ja asetusohje • CtxtClient.rtf • Kontekstipalvelun (v1.0) testauksessa käytetyt testitapaukset • Testitapaukset_ContextServer1_0_2.doc:

35. Muuta • CCOW+MinimiKontekstinhallinta.ppt: • Yleiskuvaus ja esittely: PlugIT Minimikontekstinhallinta-esitys, CCOW- ja kontekstinhallinta-esittely • WinToteutukset-2.ppt • Windows-alustalle tehtyjen referenssitoteutusten esittely

38. PlugIT-kontekstinhallintaLAUSUNTOKIERROKSEN KOMMENTIT Mika Tuomainen mika.tuomainen@savonia-amk.fi Common Services SIG 31.8.2004

39. Lausuntokierros - taustaa • Suomen HL7-yhdistys pyytää lausuntoa PlugIT-hankkeessa kehitetystä minimikontekstinhallinnasta (määrityksen versio 2) • paketti löytyy osoitteesta: http://www.plugit.fi/ContextHL7.zip • lausuntoaika: 13.8.2004-13.9.2004 • lausuntojen käsittelyn ja mahdollisten korjauksien jälkeen kontekstinhallinnan määrittely on Suomen HL7-yhdistyksen hyväksymä (kansallinen) standardi • lausunnot toimitetaan sähköisessä muodossa HL7 yhdistyksen tekniselle komitealle • osoitteeseen timo.tarhonen@tto.fi • otsikkoon teksti PLUGITCCOW

40. Lausuntokierros - taustaa • tekninen komitea käsittelee lausunnot 16.9.2004 • lopullisessa määrittelyssä pyritään konsensukseen siten, että kaikkien lausujien kommentit otetaan huomioon ja eriävistä mielipiteistä neuvotellaan ko.mielipiteen esittäjän (lausujan) kanssa • lopulta tekninen komitea tekee hallitukselle esityksen hyväksyttävästä standardista

41. Tulleet kommentit • liittyvät PlugIT-määrityksen laajentamiseen • ”pelisäännöt” laajenemiselle • HTTP-viestit • lisätietojen määrittely kontekstiin • sovellukselle mahdollisuus tiedustella kontekstipalvelimen toteuttamia tasoja

42. Pelisäännöt • määriteltävä pelisäännöt laajentamiselle • vältytään ongelmilta, jossa useita erilaisia viritelmiä • nyt mahdollisuus vaikuttaa • kommentointi • ehdotus • käsittely • hyväksyntä • mille tasolle nyt päästään = minimitaso?

43. HTTP - content-type • nyt content-type on pelkkä text/plain  estää erikoismerkkien sisällyttämisen dataan • lisätään määritykseen content-type application/x-www-urlencoded  muutoksia palvelimen toteutukseen (tuettava kahta content-typea) • sovellus ilmoittaa hyväksyvänsä application/x-www-urlencoded-muodon accept-headerissa • viestin koodauksen määrittely

44. HTTP - content-type • viestin koodauksen määrittely (application/x-www-urlencoded) • merkit, joilla esitetään parametrien arvoja (merkit, jotka ovat yhtäkuin-merkin (=) oikealla puolella), pitäisi koodata yhteisesti sovitulla tavalla • yksi tällainen yhteinen tapa on määritelty IETF RFC 2396 standardissa, kappaleessa 2.4 (http://www.ietf.org/rfc/rfc2396.txt) • Muodostetaan tavallisista (US-ASCII) aakkosista, numeroista ja joistakin erikoismerkeistä. • ASCII-merkit ‘a’ - ‘z’, ‘A’ - ‘Z’ ja ‘0’ - ‘9’ pysyvät samana. • Tyhjä välilyönti ‘ ’ pitää konvertoida plus-merkiksi ‘+’ tai %20-merkinnällä. • Kaikki muut merkit pitää konvertoida 3-merkkiseksi stringiksi “%xy”. Tällöin merkki esitettään %-merkillä ja kahdella heksadesimaaliluvulla.(xy).

45. HTTP - POST • POST mukaan määritykseen • yleisesti POST poikkeaa GET-metodista siten, että POSTissa kutsutaan ensin palvelua ja lähetetään vasta sitten parametrit • riittääkö em. tarkkuus vai pitääkö POST-viestin muodostaminen tarkentaa?

46. Lisätietojen määrittely kontekstiin • uusia tietoja subjekteille, mahdollisesti uusia subjekteja • tietojen nimeäminen • tietojen väliset riippuvuudet • GetItemValues- ja SetItemValues-metodien tarkennukset • UnknownItemName-poikkeuksen merkitys

47. Lisätiedot kontekstiin - uudet tiedot • uusia tietoja Patient- ja User-subjekteille • nyt määrittelyssä Patient.Id.NationalIdNumber ja User.Id.Logon • tarvetta varsinkin Patient-subjektin tietojen lisäämiseksi • mahdollisesti uusia subjekteja

48. Lisätiedot kontekstiin – nimeäminen • otetaan CCOW-standardista mitä otettavissa on • CCOW-standardissa määritelty seuraavat subjektit: • Potilas (Patient) • Käyttäjä (User) • Käyntikerta (Encounter) • Tutkimuspyyntö (Observation request) • DICOM-objekti (DICOM study) • Käyttäjäkohtainen sertifikaatti (Certificate Annotation) • Käyttäjäntunnistus (Authenticate user-action)

49. Lisätiedot kontekstiin – nimeäminen • jos ei löydy standardista, määritellään itse custom subject • luotava siten, että ne eivät ole ristiriidassa jo määriteltyjen subjektien kanssa • CCOW-standardissa määriteltyjen subjektien ja custom subjektien erottamiseen avainsana • avainsanana custom subjektia käyttävän organisaation World Wide Web Consortium (W3C) domain nimi

50. Lisätiedot kontekstiin – nimeäminen • esimerkiksi • [plugit.fi]DateRange • [plugit.fi]DateRange.Id. [plugit.fi]StartDate • Patient.Co.[plugit.fi]Current_medications • jos organisaation sisäinen  [organisaatio.fi] • jos kansallisesti yhdessä hyväksytty  [hl7.fi] ?