Kontekstinhallinta Päivitetty 17.8.2007 Mika Tuomainen
Sisältö Työpöytäintegraatio CCOW standardi Miksi CCOW ei käynyt suoraan? Minimikontekstinhallinnan määrittely Tietoturvallinen kontekstinhallinta Poikkeavuudet CCOW:sta Määrittelyiden versiot Tukimateriaalit
Työpöytäintegraatio
Työpöytäintegraatio potilastiedot ovat useissa eri järjestelmissä käyttäjän työasemalla on usein tarpeellista olla käynnissä yhtäaikaisesti useita eri sovelluksia järjestelmien välillä ei ole riittävästi yhteistoiminnallisuutta lääkärin tai muun hoitohenkilökunnan täytyy erikseen kirjautua sisään kuhunkin järjestelmään ja hakea esimerkiksi potilaan tiedot erikseen joka järjestelmään käyttäjä joutuu näin tekemään useita samankaltaisia toimintoja eri järjestelmiin.
Työpöytäintegraatio työpöytäintegraation tarkoitus on tuoda apua tähän ongelmaan se määrittelee yleisen mallin työasemalla toimivien sovellusten työpöytälähtöisen visuaalisen integroinnin toteuttamiseen. työpöytäintegraation tavoitteena on helpottaa erillisten järjestelmien yhtäaikaista käyttöä ja parantaa näin käyttäjän työprosesseja sekä tehdä järjestelmien käytöstä paremmin työnkulkua tukevia
Työpöytäintegraatio keinoina kertakirjautuminen ja yhteiseen kontekstiin siirtyminen kertakirjautuminen (single sign on) käyttäjän tarvitsee kirjautua vain kerran yhteen järjestelmään. muut työpöytäintegraatioon kytketyt sovellukset kykenevät käyttämään hyväksi tätä kirjautumistietoa, näin niihin tarvitse kirjautua erikseen. yhteiseen kontekstiin siirtyminen käyttäjälle tarjotaan automaattinen tai helppo siirtyminen samaan potilaaseen tai muuhun käsiteltävänä olevaan asiaan eri järjestelmissä näin käyttäjän tarvitsee syöttää esimerkiksi potilaan tunnus ja hakea haluamansa potilaan tiedot vain yhteen järjestelmään. muut järjestelmät osaavat työpöytäintegraatiota hyödyntäen hakea saman potilaan tiedot potilastunnuksen perusteella ilman erillistä potilastunnusten syöttämistä.
Työpöytäintegraatio HUOM. tärkeää kuitenkin huomata, että työpöytäintegraatio ei poista sovelluksissa olevaa päällekkäistä tietoa MUTTA helpottaa ja tehostaa merkittävästi käyttötilanteita, joissa sama käyttäjä joutuu käyttämään useita sovelluksia samanaikaisesti helpottaa erillisten järjestelmien yhtäaikaista käyttöä käyttäjälle enemmän aikaa varsinaiseen työhön turhan toiston poistuttua mahdollisuus esimerkiksi väärän potilaan käsittelemiseen potilastunnuksen syöttövirheen johdosta pienenee ja näin voidaan varmistua, että ollaan käsittelemässä samaa potilasta eri järjestelmissä.
Työpöytäintegraation käsitteet Yhteinen konteksti (common context) muodostuu joukosta yhteisiä tietoja ja käsitteitä (entiteettejä, entities), joita eri järjestelmät voivat käsitellä samalla tavalla järjestelmien sisäisestä toteutuksesta riippumatta yhteisten entiteettien merkityksen on oltava sama kaikissa järjestelmissä esimerkiksi käyttäjän ja asiakkaan (terveydenhuollossa potilaan) tunnistetiedot myös muut mahdolliset tiedot ja käsitteet, joilla on sama merkitys eri järjestelmissä, voivat kuulua yhteiseen kontekstiin.
Työpöytäintegraation käsitteet Esim. Konteksti Potilassubjekti Nimi = Patient.Co.Name Arvo = Meikäläinen^Matti Context Item Käyttäjäsubjekti Nimi = Patient.Co.Sex Arvo = M Context Item Context Items
Työpöytäintegraation käsitteet Kontekstinhallinta (context management) käytetään usein työpöytäintegraation synonyymina kontekstinhallinta pitää sisällään tekniikat ja keinot, joilla työpöytäintegraatio voidaan toteuttaa kontekstinhallinta arkkitehtuurin muodostavat siihen kuuluvat kontekstia käsittelevät tai hyödyntävät olemassa olevat järjestelmät, koordinaattorikomponentti sekä mahdolliset agenttikomponentit
Työpöytäintegraation käsitteet Kontekstinhallinta (context management) Järjestelmä 2 Järjestelmä 1 Järjestelmä 3 Koordinaattorikomponentti Agenttikomponentti Agenttikomponentti
Työpöytäintegraation käsitteet Koordinaattori komponentti (context manager) toimii työpöydällä olevien järjestelmien näkymättömänä koordinaattorina ohjelmistokomponentti, joka ylläpitää ja koordinoi käsiteltävää kontekstia sekä yhteyksiä sovelluksiin koordinaattori komponentin avulla siihen liittyneet sovellukset voivat jakaa keskenään yhteistä kontekstia ( = yhteisen kontekstin synkronointi)
Työpöytäintegraation käsitteet Agenttikomponentit voidaan yhdistää eri sovellusten samaa entiteettiä tarkoittavat tiedot huolimatta entiteettien eri arvoista eri järjestelmissä esimerkiksi käyttäjällä voi olla eri käyttäjätunnus eri sovelluksissa. Agenttikomponentin avulla käyttäjän yhden järjestelmän käyttäjätunnuksen perusteella voidaan kontekstiin asettaa myös käyttäjän muissa sovelluksissa käyttämät erilaiset käyttäjätunnukset näin huolimatta eri käyttäjätunnuksista eri järjestelmissä, kertakirjautuminen voidaan toteuttaa
Työpöytäintegraation käsitteet Järjestelmät organisaatiossa jo olemassa olevia järjestelmiä. Koordinaattori komponenttiin liitetyt järjestelmät eivät tiedä toisistaan, ne kommunikoivat ainoastaan koordinaattorin kanssa Työpöydällä (desktop) tarkoitetaan käyttäjän yhden työaseman kuvaruudulla näkyvää käyttöliittymän työaluetta
CCOW standardi
CCOW standardi CCOW (Clinical Context Object Workgroup) kansainvälisen HL7 yhdistyksen ylläpitämä standardi terveydenhuollon työpöytäintegraatioon uusin versio määrittelystä tällä hetkellä 1.5 viisi eri versiota (1.0 1.5) Version 1.0 represent the official ANSI approved versions, last modified May 24, 1999. Version 1.1 official ANSI approved versions, posted as Feb 23, 2000. Version 1.2 official ANSI approved versions, posted as Dec 5, 2000. Version 1.3 official ANSI approved versions, posted as March 13, 2001. Version 1.4 official ANSI approved versions, posted as February 28, 2002. Version 1.5 official ANSI approved version, posted May 2004.
CCOW standardi Technology Neutral Context Management Architecture 200 pgs 40 pgs Technology Specific Component Mapping 30 pgs Technology Neutral Subject Data Defn s COM Web (CORBA) 15 pgs Technology Specific User Interface Windows/Browser (Swing) (other) Health Level Seven, 2001
CCOW standardi kuvaa roolit ja vastuut kontekstinhallintaarkkitehtuurin komponenteille määrittelee yksiselitteisen tietosisällön (kontekstin) määrittelee rajapinnat komponenttien väliseen kommunikointiin ei määrää komponenttien implementaatiota
CCOW standardi 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 CCOW CCOW Mapping Agent Context Manager Annotation Agent Morwood, 2001
CCOW ratkaisun toiminta kun yhdessä sovelluksessa vaihdetaan käyttäjää ja käsiteltävää potilasta > muut context manageriin liittyneet sovellukset vaihtavat samaan käyttäjään ja näyttävät saman potilaan tietoja taustalla monivaiheinen prosessi, jossa ensin asetetaan uusi konteksti ehdolle context manageriin sitten context manager ehdottaa uutta kontekstia kaikille context manageriin liittyneille sovelluksille sovellukset voivat joko hyväksyä tai hylätä kontekstin muutoksen jos ongelmia, niistä ilmoitetaan käyttäjälle ja käyttäjä päättää miten edetään (vaihdetaanko konteksti vai tehdäänkö jotain muuta, esim. tallennetaan tallentamattomat tiedot) jos kaikki ok, sovellukset hakevat uudet kontekstitiedot context mangerilta ja päivittävät tilansa vastaamaan uuden kontekstin sisältöä
CCOW Kontekstinhallinnan toiminta 1. Käyttäjä asettaa kontekstin käyttäen jotain integraation kytkettyä sovellusta 1) CCOW Context Manager CCOW Mapping Agent Annotation Agent Morwood, 2001
CCOW Kontekstinhallinnan toiminta 2. Sovellus ilmoittaa Context Managerille, että se haluaa asettaa kontekstin CCOW 2) Context Manager CCOW Mapping Agent Annotation Agent Morwood, 2001
CCOW Kontekstinhallinnan toiminta 3. Sovellus asettaa kontekstia identifioivan tunnisteen Context Managerille Vaiheet 1 3 = uuden kontekstin ehdottaminen CCOW 3) Context Manager CCOW Mapping Agent Annotation Agent Morwood, 2001
CCOW Kontekstinhallinnan toiminta 4. Context Manager ilmoittaa agenteille, että uusi konteksti on asetettu CCOW CCOW 4) Context Manager Mapping Agent Annotation Agent Morwood, 2001
CCOW Kontekstinhallinnan toiminta 5. Context Manager ilmoittaa muille integraatioon kytketyille sovelluksille, että konteksti on muuttunut CCOW 5) Context Manager 5) CCOW Mapping Agent Annotation Agent Morwood, 2001
CCOW Kontekstinhallinnan toiminta 6. Jokainen sovellus ilmaisee Context Managerille, onko se halukas muutokseen Vaiheet 4 6 = kartoitusvaihe = onko kaikille sovelluksille kontekstinmuutos OK CCOW 6) Context Manager 6) CCOW Mapping Agent Annotation Agent Morwood, 2001
CCOW Kontekstinhallinnan toiminta 7. Kontekstin vaihtoa ehdottaneelta sovellukselta voidaan vielä varmistaa vaihdetaanko konteksti (lähinnä tilanteessa, jossa joku sovellus ei ole halukas vaihtamaan kontekstiaan ehdotettuun) CCOW 7) Context Manager CCOW Mapping Agent Annotation Agent Morwood, 2001
CCOW Kontekstinhallinnan toiminta 8. Jokainen sovellus hakee tunnisteen Context Managerilta CCOW 8) Context Manager 8) CCOW Mapping Agent Annotation Agent Morwood, 2001
9. Kukin sovellus sopeuttaa sisäsäisen tilansa ja näyttää tiedot kontekstin mukaisesti CCOW Kontekstinhallinnan toiminta 9) 9) Vaiheet 7 9 = suoritusvaihe CCOW Context Manager CCOW Mapping Agent Annotation Agent Morwood, 2001
Miksi CCOW standardia ei hyödynnetty suoraan?
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 (ei vastausta tarjouspyyntöön)
Miksi CCOW ei käynyt suoraan? kontekstin välittäminen järjestelmien kesken ei saanut välttämättä olla automaattista, vaan kontekstin vaihtamisen haluttiin tapahtuvan käyttäjän toiminnosta tarpeet Suomessa olivat vain tietojen vienti kontekstivarastoon ja niiden haku sieltä, eikä kontekstin vaihtumiseen tarvittu näin automatiikkaa näin keskeisin vaadittava toiminnallisuus oli saavutettavissa kevyemmälläkin ratkaisulla kuin CCOWstandardin mukaisesti
Minimikontekstinhallinnan määrittely
Minimikontekstinhallinnan määrittely työpöytäintegraation soveltamiseksi Suomessa PlugIThankkeessa alettiin määritellä kevyempää ratkaisua ratkaisun pohjana käytettiin CCOW standardissa määriteltyä työpöytäintegraation toteuttamista tavoitteena oli hahmottaa minimiratkaisua, jolla CCOWtyyppinen 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
Minimikontekstinhallinnan määrittely 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
Minimikontekstinhallinnan määrittely määrittelyn avulla mahdollista toteuttaa kertakirjautuminen yhteiseen kontekstiin siirtyminen (kontekstin synkronointi) helpottaa erillisten järjestelmien yhtäaikaista käyttöä tehostaa käyttötilanteita, joissa sama käyttäjä joutuu käyttämään useita sovelluksia samanaikaisesti käyttäjälle enemmän aikaa varsinaiseen työhön turhan toiston poistuttua
Minimikontekstinhallinnan mää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
Minimikontekstinhallinta tietosisältö Nimeämiskäytäntö sama kuin CCOW standardissa Subject_label.role.Name_prefix.optional_name_suffix Subject_label: Ilmaisee subjektin, johon tieto kuuluu, esim. Patient. role: Kertoo tiedon roolin : Id, Co, An Name_prefix: Ilmaisee mitä tieto tarkoittaa, esimerkiksi Logon (= kirjautumistieto) Optional_name_suffix: Tämä ei ole pakollinen kenttä. Suffix osan avulla on mahdollista esimerkiksi erottaa eri järjestelmien käyttämät subjektit, jos niiden arvot poikkeavat toisistaan
Minimikontekstinhallinta tietosisältö Määrittelee yhteisen kontekstin (tietosisällön) Potilassubjekti nimeäminen: Patient.Id.NationalIdNumber arvo: hetu Käyttäjäsubjekti nimeäminen: User.Id.Logon arvo: geneerinen id käyttäjätunnuksen mappaus sovelluksissa
Minimikontekstinhallinta tietosisältö Custom subject jos tarvittavaa subjektia/kontekstitietoa ei löydy standardista/määrittelystä, määritellään itse erottimena avainsana (organisaation W3C domain nimi) yhteisissä kansallisissa [hl7.fi], löytyvät tulevaisuudessa kansalliselta palvelimelta custom subject esimerkit [plugit.fi]daterange, uusi subjekti Patient.Co.[plugit.fi]Current_medications, uusi tieto [plugit.fi]daterange.id. [plugit.fi]startdate, uusi subjekti ja tälle uusi tieto
Minimikontekstinhallinta tietosisältö Kontekstinhallinnan subjektikoodisto HL7 tekninen komitea hyväksyi 22.11.2006 subjektikoodiston lisättäväksi HL7 dokumenttiarkistoon. Koodiston ylläpito toteutetaan jatkossa kansallisen koodistopalvelimen kautta. Subjekteja käyttäjätunnus (User.Id.Logon) sekä potilaan henkilötunnus (Patient.Id.NationalIdNumber) on pakko käyttää toteutuksissa vastaavan nimisinä ja määrittelyssä kuvatulla tavalla. Uusien subjektikoodistoon lisättyjen kontekstitietojen ei tarvitse olla toteutettuna kontekstinhallintapalvelussa. Jos kansallisella tasolla yhteisesti sovittuja, kontekstitietoja halutaan käyttää, tulee se tehdä subjektikoodissa määritellyillä nimillä. Subjektikoodiston kaikki tiedot, joissa ei ole [hl7.fi] domain nimeä ovat peräisin CCOW standardista. [hl7.fi] domain nimellä varustetut tiedot ovat määritelty Suomessa kansallisesti käytettäviksi.
Minimikontekstinhallinta tietosisältö Kontekstinhallinnan subjektikoodisto Subjektien määrittelyyn ja nimeämiseen kannattaa hyödyntää jatkossakin seuraavia dokumentteja: Minimikontekstinhallinnan määrittelyn version 3 lukua 4 "Subjektit", dokumentti löytyy osoit teesta http://virtual.vtt.fi/virtual/hl7/cda/apirajapinnat/kh_v3.doc CCOW standardin dokumenttia "HL7 Context Management CCOW Standard: Subject Data Definitions, Version 1.5, May 2004", zippaketti saatavilla osoitteesta http://proxnet.vtt.fi/hl7/jasenet/ccow/0402ccow15.zip Näissä dokumenteissa on kuvattu, kuinka subjektit nimetään, mitä tietotyyppejä subjekteille voidaan antaa, kuinka niitä käytetään sekä mitä subjektien käytössä tulee ottaa huomioon. Uusien subjektien käyttöön liittyvät kysymykset voi ohjata HL7 tekniselle komitealle
Minimikontekstinhallinta tietosisältö Kontekstinhallinnan subjektikoodiston sisältö 22.11.2006 Tieto User.Id.Logon User.Co.Name User.Co.[hl7.fi]Role User.Co.[hl7.fi]Organization User.Co.[hl7.fi]Unit User.Co.[hl7.fi]LogonMethod Patient.Id.NationalIdNumber Patient.Co.PatientName Patient.Co.DateTimeOfBirth Patient.Co.Sex Patient.Co.[hl7.fi]Isolation Patient.Co.[hl7.fi]Infection Merkitys Käyttäjätunnus Käyttäjän nimi Käyttäjän rooli Käyttäjän organisaatio Käyttäjän toimintayksikkö Käyttäjän tunnistustapa Potilaan henkilötunnus Potilaan nimi Potilaan syntymäaika Potilaan sukupuoli Vuodeosastopotilaan eristysluokka Vuodeosastopotilaan tartuntavaara
Minimikontekstinhallinta tietosisältö Kontekstinhallinnan subjektikoodiston sisältö 22.11.2006 Tieto Merkitys Encounter.Id.VisitNumber Encounter.Id.AlternateVisitId Encounter.Co.VisitIndicator Encounter.Co.AdmitDateTime Encounter.Co.DischargeDateTime Encounter.Co.PatientClass Encounter.Co.AdmissionType Encounter.Co.AssignedPatientLocation Encounter.Co.ServicingFacility Encounter.Co.PatientType Käynnin tai hoitojakson tunniste Toissijainen käynnin/hoitojakson tunniste Tietojen kohde Sisäänkirjausaika/käyntipäivä Uloskirjausaika/lähtöpäivä Potilasluokka Tulotapa Potilaan sijainti Palvelun tuottava toimipiste Hoidon tarve
Minimikontekstinhallinta kontekstidatan tietotyypit kontekstidatan tietotyypit mukaan määrittelyihin väliversioon 2.1.1 aiemmin tietotyyppejä ei oltu määritelty tarkasti minimikontekstinhallinnan kontekstidatan arvoissa käytetään samoja HL7 rakenteisia tietotyyppejä kuin CCOW standardissakin
Minimikontekstinhallinta kontekstidatan tietotyypit HL7 rakenteiset tietotyypit, joita käytetään CCOW standardissa (HL7 version 2.4 mukaiset) Data Type Data Type Name HL7 Section Reference CX Extended composite ID with check digit 2.9.12 EI HD ID IS ST NM XPN XAD XTN DLN DT Entity Identifier Hierarchic Designator Code Value for HL7 Defined Table Coded Value For User Defined Table String Numeric Extended Person Name Extended Address Extended Phone Number Driver s License Number Date 2.9.17 2.9.21 2.9.22 2.9.23 2.9.43 2.9.28 2.9.54 2.9.51 2.9.55 2.9.13 2.9.15 TS Time Stamp 2.9.47
Minimikontekstinhallinta kontekstidatan tietotyypit HL7 rakenteisten tietotyyppien käyttö edellyttää erotinmerkkien käyttämistä tiedon eri osien erottamiseen. CCOW standardissa on mainittu sallituiksi erotinmerkeiksi ainoastaan merkit, ^ ja &. Nämä erotinmerkit on kuvattu HL7 version 2.4 dokumentissa, minimimäärittelyyn mukaan myös ~ ja \ erotinmerkit on koodattava escape sekvensseillä: aina, kun merkit ovat datana ST tietotyypissä (User.Id.Logon, Patient.Id.NationalIdNumber) silloin, kun merkit ovat muissa tietotyypeissä rakenteisen tiedon arvoina, eivät erottimina rakenteisessa tiedossa.
Minimikontekstinhallinta kontekstidatan tietotyypit Jotta rakenteisessa datassa olevat erotinmerkit eivät menisi sekaisin datassa olevien vastaavien erikoismerkkien kanssa, on datassa olevat erikoismerkit koodattava escape sekvensseillä. \H\ \N\ \F\ \S\ \T\ \R\ \E\ \Xdddd...\ \Zdddd...\ start highlighting normal text (end highlighting) field separator ( ) component separator ( ^ ) subcomponent separator ( & ) repetition separator ( ~ ) escape character ( \ ) hexadecimal data locally defined escape sequence 12 12 12 12\F\12\F\12 12^12^12 12\S\12\S\12 12&12&12 12\T\12\T\12 12~12~12 12\R\12\R\12
Minimikontekstinhallinta kontekstidatan tietotyypit User.Id.Logon ja Patient.Id.NationalIdNumber STtietotyyppejä jos otetaan kontekstitietomäärittelyjä suoraan CCOWstandardista > käytettävä niihin määriteltyjä tietotyyppejä jos määritellään omia custom subjekteja > niille on määriteltävä HL7 tietotyyppi
Minimikontekstinhallinta rajapinnat seuraavat CCOW standardin rajapinnat riisuttuina versioina: ContextManager rajapinta: kontekstinhallintaan liittyminen ja siitä eroaminen ContextData rajapinta: kontekstin tietojen käsittely
Minimikontekstinhallinta rajapinnat ContextManager CreateSession (sessioavaimen luominen) inputs(optional string applicationname, optional string hostaddress) outputs(string sessionkey) JoinCommonContext (kontekstinhallintaan liittyminen) inputs(string applicationname) outputs(long participantcoupon) LeaveCommonContext (kontekstinhallinnasta eroaminen) inputs(long participantcoupon) outputs()
ContextData Minimikontekstinhallinta rajapinnat SetItemValues (tietojen asettaminen kontekstiin) inputs (long participantcoupon, string[ ] itemnames, string[ ] itemvalues) outputs () GetItemValues (tietojen hakeminen kontekstista) inputs (long participantcoupon, string[ ] itemnames) outputs (string[ ] itemvalues)
Minimikontekstinhallinta työpöydän/sovelluksen identifiointi sovelluksen 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 managerkomponentti antaa sovellukselle sen liittyessä kontekstinhallintaan. Parametri yksilöi kontekstiin osallistuvan sovelluksen ja sovelluksen on käytettävä sitä jatkossa ollessaan yhteydessä context manageriin
Minimikontekstinhallinta työpöydän/sovelluksen identifiointi työaseman identifiointi: työaseman ip / työaseman tunnus: tarvitaan työaseman tunnistamiseen, kun context manager on palvelimella (web/http määrittely) sessioavain (versiosta 2.1.1 lähtien): tarvitaan työaseman tunnistamiseen, jos context manager on palvelimella ja työaseman ip osoitetta ei voida käyttää työasemaa yksilöivänä tunnisteena. Sessioavaimen avulla voidaan toteuttaa tarvittaessa myös useita sessioita samalta työasemalta.
Minimikontekstinhallinta rajapintojen käyttö Käyttäjä Perusjärjestelmä Kontekstipalvelin Käynnistää CreateSession(applicationName=perusjärjestelmä) sessionkey=xyz JoinCommonContext(applicationName=perusjärjestelmä, sessionkey=xyz) participantcoupon=123 Kirjautuu sisään SetItemValues(participantCoupon=123, itemnames=user.id.logon, itemvalues=käyttäjätunnus@perusjärjestelmä) Valitsee potilaan SetItemValues(participantCoupon=123, itemnames=patient.id.nationalidnumber, itemvalues=070707 0707) [Kuva: Tommi Rissanen]
Minimikontekstinhallinta web/http tekninen määrittely viestinvälitys http viesteillä (request, response) mallina CCOW standardin tapa muodostaa http viestit huomioitu työaseman tunnistaminen pollaukset
Minimikontekstinhallinta http viestien muodostaminen HTTP Request Message Argument Name Data Type Comment Interface string ContextManager Method string JoinCommonContext applicationname string Optional Parameters & merkillä erotettuja nimi arvopareja, joiden perusteella voidaan esim. identifioida työasema. hostaddress string Client's tcp/ip address sessionkey string Client's sessionkey HTTP Reply Message participantcoupon long http://url.fi/cm?interface=contextmanager&method=joincommoncontext&applicationname=... Kutsuttavan komponentin URL Kutsuttava rajapinta Kutsuttava metodi Kutsun parametrit Kutsu: http://127.0.0.1:8080/cm.psp?interface=contextmanager&method= JoinCommonContext&applicationName=LoginMaster Vastaus: participantcoupon=2500131
Minimikontekstinhallinta työaseman tunnistaminen palvelinpohjaisessa kontekstinhallinnassa työasemakohtaisen kontekstin identifiointiin käytetään joko työaseman ip osoitetta tai sessioavainta (versiosta 2.1.1 lähtien) IP osoite työasemasovelluksen ip osoite mahdollista saada sovelluksen kontekstipalvelimelle lähettämästä kutsusta web sovelluksen ip osoite välitettävä kontekstipalvelimelle aiemmin web sovelluksille JoinCommonContextWithIp, jossa työaseman ip osoite välitettiin parametrina nyt JoinCommonContext valinnaisilla parametreilla (ks. edellinen taulukko), joissa ip osoite (hostaddress) voi olla yhtenä parametrina
Minimikontekstinhallinta työaseman tunnistaminen palvelinpohjaisessa kontekstinhallinnassa sessioavain sessioavainta tarvitaan työaseman tunnistamiseen, jos context manager on palvelimella ja työaseman ip osoitetta ei voida käyttää työasemaa yksilöivänä tunnisteena (NATosoitteet) sessioavain välitetään kontekstipalvelimelle JoinCommonContext kutsussa sessionkey parametrilla määrittelyssä ei oteta kantaa kuinka sessioavain luodaan ja saadaan välitettyä eri sovelluksille, nämä on ratkaistava toteutuskohtaisesti (sessioavaimen voi luoda esim. ydinjärjestelmä ja sen vastuulla on tällöin myös sessioavaimen välittäminen sitä tarvitseville muille sovelluksille, ks. myöhemmin esimerkki sovelluksen avauksesta) sessioavaimen avulla voidaan toteuttaa tarvittaessa myös useita sessioita samalta työasemalta
Minimikontekstinhallinta työaseman tunnistaminen palvelinpohjaisessa kontekstinhallinnassa JoinCommonContext metodilla voi näin liittyä kontekstiin joko hostaddress parametrilla (ip osoite), sessionkey parametrilla tai ilman valinnaisia parametreja jos kutsussa annetaan sekä sessionkey että hostaddress, voidaan toteutuskohtaisesti valita kontekstin tunnistamiseen kumpi tahansa. jos parametria ei anneta lainkaan, yksilöidään työasema kutsusta saatavan ip osoitteen perusteella (siis lähinnä työasemasovelluksen) sessioavaimen luontia varten kontekstipalvelimeen metodi CreateSession, jota kontekstin luova sovellus (luotettu sovellus) kutsuu ennen JoinCommonContext metodia, metodin paluuarvona sessioavain
Minimikontekstinhallinta pollaukset palvelinpohjaisessa kontekstinhallinnassa Palvelinpohjaisessa ratkaisussa on otettava huomioon seuraavat kaksi web tekniikasta seuraavaa ongelmaa: Mikäli kontekstinhallintapalvelussa on ongelmia, esim. itse palvelu kaatunut, on sovelluksen osattava toimia ilman kontekstinhallintaa Mikäli kontekstinhallintaan liittyneessä sovelluksessa on ongelmia, esim. web palvelimella oleva sovellus on kaatunut, muodostuu ongelmaksi kontekstinhallintapalveluun roikkumaan jäävät turhat sovellukset ensimmäiseen ratkaisu kutsua GetItemValues metodia, jos kontekstinhallintapalvelu vastaa kutsuun, voi sovellus varmistua sen toiminnasta toisessa kontekstipalvelimeen on määriteltävä aikaleima, johon kontekstin voimassaolo perustuu
Tietoturvallinen kontekstinhallinta
Alueellinen käyttö (1) Esiin nousi tarve käyttää kontekstinhallintaa myös alueellisesti Ideana, että organisaation ulkopuolinen järjestelmä voisi liittyä organisaation sisäiseen kontekstinhallintaan Näin olisi mahdollista toteuttaa organisaation ulkopuolisen järjestelmän kertakirjautuminen ja siirtyminen yhteiseen kontekstiin organisaation sisäisten järjestelmien kanssa
Alueellinen käyttö (2) 2. pj käynnistää selaimen ja välittää selaimelle parametrit (sessioavain ja ATJ:n url) 3. 1. Perusjärjestelmä selain avaa ATJ:n ja välittää ATJ:lle sessioavaimen pj liittyy kontekstiin sessioavaimella pj asettaa kontekstin 4. ATJ liittyy kontekstipalvelimeen saamallaan sessioavaimella ATJ pyytää kontekstin kontekstipalvelimelta 6. Alueellinen järjestelmä (tai mahdollinen muu järjestelmä) ATJ näyttää kontekstin mukaiset tiedot 5. Kontekstipalvelin kontekstipalvelin palauttaa ATJ:lle kontekstin
Alueellinen käyttö (3) Alueellinen käyttö nosti esiin useita tietoturvavaatimuksia Alueellisen tarpeen myötä alettiin määritellä kontekstinhallinnan tietoturvaratkaisua Tietoturvallinen kontekstinhallinta soveltamisohje Minimikontekstinhallinnan määrittely v3 dokumentissa huomioitu tietoturva oma luku alueellisesta kontekstinhallinnasta ja sen erityisvaatimuksista
Kontekstinhallinnan turvallisuus (1) Ensimmäisissä minimikontekstinhallinnan määrittelyissä olettiin lähtökohtaisesti, että kontekstinhallintaa toteutetaan sisäverkossa, jossa paikallinen verkko ja työasemat ovat tiukasti kontrolloituja Vaatimuksia käyttäjäkontekstin asettamisen osalta Turvallisuuden ratkaisu toteutuskohtaista Uusimmassa Minimikontekstinhallinnan määrittely v3:ssa huomioitu tietoturva organisaation sisäisessä kontekstinhallinnassa ulkopuolisen järjestelmän liittämisessä kontekstinhallintaan
Kontekstinhallinnan turvallisuus (2) Kontekstipalvelimen ja siihen liittyvien järjestelmien välinen tietoturva toteutetaan kaksisuuntaisella SSL:llä Kaksisuuntaisella SLL:llä kontekstipalvelin ja siihen liittyvät järjestelmät voivat varmistaa toistensa identiteetit kontekstitiedon eheyden sekä toteuttaa tietojen salauksen Web selain (web sovellus) Web palvelin SSL Työasemasovellus SSL Kontekstipalvelin
Kontekstinhallinnan turvallisuus (3) SSL varmenteet sovelluskohtaisia Web sovelluksissa palvelinvarmenteiden käyttö yksinkertaista Työasemasovelluksien osalta varmenteiden jakelu ja hallinnointi hankalaa Voidaan kiertää esim. väliohjelmiston avulla Web selain (web sovellus) Työasemasovellus Adapteri Välitysohjelma Web palvelin 1 Server 2 Kontekstipalvelin
Kontekstinhallinnan turvallisuus, alueellinen käyttö Organisaation ulkopuolisen sovelluksen ja kontekstipalvelimen välillä käytetään myös kaksi suuntaista SSL:ää Parametrien välitys (sessioavain) selaimen välityksellä, one way SSL Organisaation sisäinen järjestelmä Selain one way SSL (https post) two way SSL Organisaation ulkopuolinen järjestelmä Kontekstipalvelin
Alueellinen tietoturva Haasteita: Järjestelmät ja niiden käyttämät tietoliikenneverkot ovat eri organisaatioiden hallinnoimia ja ylläpitämiä Tarpeita Kertakirjautuminen Saman potilaan käsittely eri järjestelmissä Ratkaisuja: Sovellusten ja kontekstipalvelimen vahva tunnistus ja salatut yhteydet kontekstinhallinnassa Sessioavaimen turvallinen välitys järjestelmien välillä Sessioavaimen on oltava vaikeasti arvattava Kontekstinhallinta ratkaisee kertakirjautumisen ja samaan potilaaseen siirtymisen
Kontekstinhallinnan osapuolet alueellisessa käytössä (1) Kontekstipalvelin Voi toimia sisä tai ulkoverkossa Tunnistaa sovellukset sertifikaateilla ja tarkistaa sovellusten oikeudet Välittää tietoja sovellusten välillä Perusjärjestelmä Toimii organisaation omassa sisäverkossa Tunnistaa käyttäjän Luo kontekstin ja liittyy siihen, asettaa käyttäjän kontekstiin Käynnistää muita järjestelmiä ja välittää niille sessioavaimen
Kontekstinhallinnan osapuolet alueellisessa käytössä (2) Ulkopuolinen järjestelmä (alueellinen järjestelmä) Toimii organisaation ulkopuolisessa verkossa Saa käynnistysparametrina sessioavaimen, jolla liittyy kontekstiin Saa kontekstista tietoonsa käyttäjätunnuksen ja käsiteltävän potilaan Voi käynnistää muita ulkopuolisia järjestelmiä ja välittää niille sessioavaimen edelleen
Kontekstinhallinnan osapuolet alueellisessa käytössä (3) Sisäinen järjestelmä Toimii organisaation sisäisessä verkossa Saa käynnistysparametrina sessioavaimen, jolla liittyy kontekstiin Saa kontekstista tietoonsa käyttäjätunnuksen ja käsiteltävän potilaan Voi käynnistää muita sisäisiä tai ulkopuolisia järjestelmiä ja välittää niille sessioavaimen edelleen
Alueellisen käytön erityisvaatimuksia (1) Alueellisen järjestelmän toiminta alueella voi olla useita kontekstipalvelimia Organisaatioilla on omia sisäisiä kontekstinhallintatarpeita Kontekstipalvelin voi olla organisaation oma tai useamman organisaation yhteinen Alueellisen järjestelmän on osattava valita oikea kontekstipalvelin sen mukaan mistä organisaatiosta sitä kutsutaan