PlugIT-kontekstinhallinta

Mika Tuomainenmika.tuomainen@savonia-amk.fi

Common Services SIG

31.8.2004

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

Sisältö

CCOW-standardi

CCOW (Clinical Context Object Workgroup)

HL7-yhdistyksen ylläpitämä standardi terveydenhuollon työpöytäintegraatioon

kehittyvä standardi

nyt versio 1.5

CCOW-arkkitehtuuri

Context Manager

Mapping Agent

Annotation Agent

CCOW

CCOW

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

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)

CCOW-standardi

Technology Neutral Context Management Architecture

Technology Specific User Interface

Windows/Browser

(Swing)

(other)

COM

Web(CORBA)

Technology Specific Component Mapping

Technology-Neutral Subject

Data Defn’s

200 pgs

15 pgs

40 pgs

30 pgs

Health Level Seven, 2001

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..

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

Miksi CCOW ei käynyt suoraan?

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

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

PlugIT-määrittelyn taustaa

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

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

PlugIT-kontekstinhallintamäärittely

PlugIT-määrittelyn tietosisältö

Määrittelee yhteisen kontekstin:

PotilassubjektiPatient.Id.NationalIdNumberhetu

KäyttäjäsubjektiUser.Id.Logongeneerinen idmappaus sovelluksissa

Custom subjectjos ei löydy standardista/määrittelystä, määritellään itseerottimena avainsana (organisaation W3C domain-nimi)

custom subject esimerkit

[plugit.fi]DateRange

[plugit.fi]DateRange.Id. [plugit.fi]StartDate

Patient.Co.[plugit.fi]Current_medications

PlugIT-määrittelyn tietosisältö

CCOW-standardin rajapinnat (ja nämäkin karsittuina versioina):

ContextManager-rajapinta: kontekstinhallintaan liittyminen ja siitä eroaminen

ContextData-rajapinta: kontekstin tiedon käsittely

PlugIT-määrittelyn rajapinnat

ContextManager

JoinCommonContext (kontekstinhallintaan liittyminen) inputs(string applicationName)outputs(long participantCoupon)

LeaveCommonContext (kontekstinhallinnasta eroaminen) inputs(long participantCoupon) outputs()

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)

PlugIT-määrittelyn rajapinnat

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)

Identifiointi

GetItemValues(98765, <”User.Id.Logon”>)

itemValue = “robs”

SetItemValues(98765,<"Patient.Id.NationalIdNumber">, <"230474-XXXX”>)

Sovellus App Kontekstinhallinta CM

JoinCommonContext(appName)

partipantCoupon = 98765

LeaveCommonContext(98765)

viestinvälitys http-viesteillä

mallina CCOW-standardin tapa muodostaa http-viestit

huomioitava

työaseman tunnistaminen web-sovelluksissa

turvallisuus

”pollaukset”

Web/http-määrittely

Erillissovellus

Http-yhteyskomponentti

Palvelutoteutus

Http-keskustelija

http

Web-erillissovellus

WWW-palvelin

http

http

Http-yhteyskomponentti

Kutsuttavan

komponentin

URL-osoite

Kutsuttava

rajapinta

Kutsuttava

metodiKutsun

parametrit

http://url.fi/cm?interface=ContextManager&method=JoinCommonContext&applicationName= . . .

HTTP Request Message

Argument Name Data Type Comment

interface string “ContextManager”

method string “JoinCommonContext”

applicationName string

http-viestien muodostaminen

työaseman ip:n välitys

tarvitaan erillinen metodi

JoinCommonContextWithIp

ei CCOW-standardissa

Työaseman tunnistaminen web-sovelluksissa

Erillissovellus

Http-yhteyskomponentti

Palvelutoteutus

Http-keskustelija

http

Web-erillissovellus

WWW-palvelin

http

http

Http-yhteyskomponentti

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

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

Turvallisuus PlugIT-määrittelyssä

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

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

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

Poikkeavuudet CCOW:sta

ContextHL7-paketti

PlugIT-kontekstihallintaan liittyviä määrityksiä ja toteutuksia

Mika Tuomainenmika.tuomainen@savonia-amk.fi

Common Services SIG

31.8.2004

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

Määritysdokumentit

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

Kontekstipalvelun referenssitoteutus

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

Kontekstipalvelua käyttävät referenssitoteutukset

kontekstipalvelinten testaussovellus

CtxtClient.exe

testaussovelluksen käyttö- ja asetusohje

CtxtClient.rtf

Kontekstipalvelun (v1.0) testauksessa käytetyt testitapaukset

Testitapaukset_ContextServer1_0_2.doc:

Kontekstipalvelinten testaus

CCOW+MinimiKontekstinhallinta.ppt:

Yleiskuvaus ja esittely: PlugIT Minimikontekstinhallinta-esitys, CCOW- ja kontekstinhallinta-esittely

WinToteutukset-2.ppt

Windows-alustalle tehtyjen referenssitoteutusten esittely

Muuta

PlugIT-kontekstinhallintaLAUSUNTOKIERROKSEN KOMMENTIT

Mika Tuomainenmika.tuomainen@savonia-amk.fi

Common Services SIG

31.8.2004

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

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

Lausuntokierros - taustaa

liittyvät PlugIT-määrityksen laajentamiseen

”pelisäännöt” laajenemiselle

HTTP-viestit

lisätietojen määrittely kontekstiin

sovellukselle mahdollisuus tiedustella kontekstipalvelimen toteuttamia tasoja

Tulleet kommentit

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?

Pelisäännöt

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

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

HTTP - content-type

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?

HTTP - POST

uusia tietoja subjekteille, mahdollisesti uusia subjekteja

tietojen nimeäminen

tietojen väliset riippuvuudet

GetItemValues- ja SetItemValues-metodien tarkennukset

UnknownItemName-poikkeuksen merkitys

Lisätietojen määrittely kontekstiin

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

Lisätiedot kontekstiin - uudet tiedot

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)

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

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] ?

Lisätiedot kontekstiin – nimeäminen

tietojen lisääntyessä on oltava mahdollisuus määritellä/määriteltävä tietojen väliset riippuvuudet

yhden subjektin sisäiset tiedot riippuvaiseksi subjektin Id-tunnisteesta

kun asiakassovellus vaihtaa subjektia kontekstiin kontekstipalvelimen poistettava edelliseen subjektiin liittyvät tiedot

riippuvuudet myös subjektien välillä

esim. hoitojakso-subjekti on riippuvainen potilas-subjektista

kun potilasta vaihdetaan kontekstiin hoitojakso subjekti ja sen tiedot poistettava

tietojen poistaminen ei asiakassovelluksen vastuulle

Lisätiedot kontekstiin - riippuvuudet

asiakassovelluksen asetettava tietoja hakiessaan GetItemValues-metodiin parametriksi aina myös Id-tieto

sovellus voi varmistua, että kontekstissa on haettavan subjektin tietoja

asiakassovelluksen asetettava aina muiden tietojen mukana SetItemValues-metodiin myös subjektin Id-tieto

ei yhdisty vahingossa väärään subjektiin

User Id-tunnus ongelmaksi, koska nyt määrityksen mukaan SetItemValues-metodilla ei saa asettaa User.Id.logon-tietoa

voidaan ratkaista siten, että hyväksytään User.Id.logon tiedon asetus SetItemValues-metodilla, jos Id on sama joka on jo olemassa kontekstissa

Lisätiedot kontekstiin - riippuvuudet

UnknownItemName-poikkeus

nyt poikkeus ilmenee, jos kontekstissa ei ole haettavaa tietoa

haetaan vain kahta tietoa (User ja Patient), joten OK

muodostuu kuitenkin ongelmalliseksi, jos haetaan useampia tietoja

jos yksikin tieto puuttuu, muitakaan ei palauteta

ehdotettu, että tiedon puuttuessa puuttuvaa tietoa ei palauteta, muut palautetaan

Lisätiedot kontekstiin - UnknownItemName

poistetaanko kokonaan?

muutetaan merkitystä

käytetään tarkistamaan tukeeko kontekstipalvelin tiettyä ItemName:a

poikkeus ilmenee, jos ItemName-tarkistaminen toteutettu kontekstipalvelimeen (valinnainen ominaisuus)

Lisätiedot kontekstiin - UnknownItemName

minimitason määrittely

lisätasojen määrittely

taaksepäin yhteensopivuus

asiakassovellukselle mahdollisuus kysellä, mitä tasoa kontekstipalvelin tukee

ImplementationInformation

asiakassovelluksien toteutus monimutkaistuu

Eri toteutustasot

CCOW-standardissa rajapinta ImplementationInformation

interface ImplementationInformation

{

readonly string ComponentName

readonly string RevMajorNum

readonly string RevMinorNum

readonly string PartNumber

readonly string Manufacturer

readonly string TargetOS

readonly string TargetOSRev

readonly string WhenInstalled

}

ei kuitenkaan sisällä tietoa tasoista

Eri toteutustasot

kommentointiaikaa 13.9.2004 asti

kommentit – ehdotus – käsittely - hyväksyntä

jatkossa rajapintojen kehitys jatkuu HL7-yhdistyksen puitteissa

HL7 Common Services SIG

tekninen komitea

SerAPI.

Jatkokäsittely