TYÖPYÖTÄINTEGRAATION AVOIMET SOVEL- LUSRAJAPINNAT

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 6 STUDIES AND REPORTS OF THE PLUGIT PROJECT 6 Mika Tuomainen, Antti Komulainen, Juha Rannanheimo, Juha Mykkänen TYÖPYÖTÄINTEGRAATION AVOIMET SOVEL- LUSRAJAPINNAT KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijät: Mika Tuomainen (myös toim.) Antti Komulainen Juha Rannanheimo Savonia Business Savonia-ammattikorkeakoulu Juha Mykkänen HIS-tutkimusyksikkö, Tietotekniikkakeskus Kuopion yliopisto Myynti: Tietotekniikkakeskus / Kanslia Kuopion yliopisto puh. (017) tike@uku.fi ISBN (koko teos) ISBN (osa 6) ISBN (PDF) Kopijyvä Oy, Kuopio Kuopio 2004

3 Tuomainen, Mika; Komulainen, Antti; Rannanheimo, Juha; Mykkänen, Juha. Työpöytäintegraation avoimet sovellusrajapinnat. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (KOKO TEOS) ISBN (OSA 6) ISBN (PDF) TIIVISTELMÄ Potilasta hoidettaessa potilaan tietoja on tarkasteltava kokonaisvaltaisesti. Potilastiedot ovat tyypillisesti useissa järjestelmissä, jonka seurauksena käyttäjän työasemalla on usein tarpeellista olla käynnissä yhtäaikaisesti useita eri sovelluksia. Koska 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. Näin käyttäjä joutuu tekemään useita samankaltaisia toimintoja eri järjestelmiin. 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, joista tulee tehokkaampia ja paremmin työnkulkua tukevia. Tässä raportissa esitellään PlugIT-hankkeessa määriteltyjen työpöytäintegraation avointen sovellusrajapintojen taustaselvitykset, tekniikkariippumattoman määrittelyt sekä tekninen HTTPrajapintamäärittely. Työpöytäintegraatio-rajapintojen avulla voidaan toteuttaa kertakirjautuminen sekä yhteisen kontekstin jakaminen eri järjestelmien kesken. Raportin tulokset on tuotettu PlugIT-hankkeessa tutkijoiden, terveydenhuollon organisaatioiden ja ohjelmistoyritysten yhteistyössä vuosina Sen tuottamisessa on hyödynnetty hankkeen integrointiratkaisujen arviointi- ja määrittelymenetelmiä. Yleinen kymmenluokittelu UDK: Asiasanat (YSA): tiedonhallinta, tietojärjestelmät, terveydenhuolto, standardointi, systeemityö, tietoteollisuus Medical Subject Headings (MeSH): medical informatics, information systems, information management, software, health care sector, hospital information systems

4

5 ESIPUHE Tämä raportti on tehty PlugIT-hankkeessa vuosina Raportissa dokumentoidaan hankkeessa tuotettu kontekstinhallinnan määrittely, joka sisältää avoimet sovellusrajapinnat työpöytäintegraation toteuttamiseksi. Raportti on suunnattu ennen kaikkea ohjelmistojen tuottajille, jotka haluavat toteuttaa ohjelmistoihinsa PlugIT-määritysten mukaiset työpöytäintegraatio-rajapinnat joko toteuttavana tai hyödyntävänä osapuolena. Raporttia voivat hyödyntää myös järjestelmien kehittämiseen osallistuvat terveydenhuollon ja tietohallinnon ammattilaiset. Raportti sisältää taustat, jotka vaikuttivat kehitystyöhön sekä tuotetut kontekstinhallinnan määritykset. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Kiitämme hankkeeseen osallistuvien yritysten ja sairaaloiden edustajia hyvistä ideoista ja näkökulmista. Kuopiossa 30. elokuuta 2004 Tekijät

6

7 SISÄLLYS 1 JOHDANTO PlugIT-hanke Raportin sisältö TYÖPÖYTÄINTEGRAATIO Yleistä työpöytäintegraatiosta Työpöytäintegraation käsitteet TAUSTA PLUGIT-KONTEKSTINHALLINTARATKAISU Kontekstinhallintaratkaisun sisältö Kontekstinhallinnan toiminta Kontekstinhallintaan liittyminen Potilaskontekstin muutos Käyttäjäkontekstin muutos Kontekstinhallinnasta eroaminen Kokoava esimerkki Kontekstinhallintaratkaisun sessionhallinta, elinkaari ja identifiointi KONTEKSTINHALLINTARATKAISUN TIETOSISÄLTÖ Konteksti Subjektit Subjektien nimeäminen Subjektien käyttäminen PlugIT-kontekstinhallintaratkaisun subjektit KÄYTTÄJÄ-SUBJEKTI POTILAS-SUBJEKTI CUSTOM SUBJEKTIT Subjektit ja turvallisuus TEKNIIKKARIIPPUMATTOMAT RAJAPINTAMÄÄRITTELYT Rajapintojen, metodien, parametrien, poikkeuksien ja subjektien nimeäminen Rajapinnat Metodit Parametrit Poikkeukset Subjektit ContextManager-rajapinta JoinCommonContext LeaveCommonContext ContextData-rajapinta SetItemValues GetItemValues Rajapintojen käyttöesimerkki...27

8 7 RAJAPINTAMÄÄRITTELYT HTTP-TEKNIIKALLE Arkkitehtuuri Tekniikka Sessionhallinta Pollaukset Metodit HTTP-viesteillä HTTP GET / POST-viestit MIME-header HTTP-kutsun muodostaminen Paluuarvon muodostaminen Poikkeukset ContextManager-rajapinta JoinCommonContext JoinCommonContextWithIp LeaveCommonContext ContextData-rajapinta SetItemValues GetItemValues TURVALLISUUS TOTEUTUKSET, HYÖDYNTÄMINEN JA JATKOKEHITYS Toteutukset Muu hyödyntäminen Jatkokehitys LÄHTEET...41 Liite 1: Turvallisuus. Liite 2: Työaseman identifioimisvaihtoehdot. Liite 3: HTTP-viestien tarkennukset. Liite 4: PlugIT-kontekstinhallintaratkaisun ja CCOW-standardin keskeisimmät erot.

9 TUOMAINEN, KOMULAINEN, RANNANHEIMO, MYKKÄNEN 1 JOHDANTO 1.1 PlugIT-hanke PlugIT on vuosina toteutettu valtakunnallinen Tekes-rahoitteinen tutkimus- ja kehittämishanke, joka tuottaa avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. Hankkeen tavoitteena on tukea terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla (PlugIT 2004). Tutkimuksen sekä rajapintojen määrittelyn ovat toteuttaneet neljä Kuopion Centekin yksikköä yhteistyössä 15 ohjelmistoyrityksen, kuuden sairaanhoitopiirin (mukaan lukien kaikki yliopistolliset sairaanhoitopiirit) sekä yhden kahden kunnan terveydenhuollon kuntayhtymän kanssa. 1.2 Raportin sisältö Tämän dokumentin luvussa 2 esitellään työpöytäintegraatiota yleisesti sekä selvitetään työpöytäintegraatioon liittyvät käsitteet. Luvussa 3 esitetään taustoja, jotka ovat vaikuttaneet kontekstinhallintamäärittelyjen tuottamiseen. Luvussa 4 käydään läpi PlugIT-hankkeessa tuotetun kontekstinhallintaratkaisun perustoiminta. Luvussa 5 kuvataan PlugIT-kontekstinhallintaratkaisun tietosisältö ja sen muodostamisperiaatteet. Luvussa 6 ovat kontekstinhallinnan rajapintamäärittelyt tekniikkariippumattomina ja luvussa 7 rajapintamäärittelyt HTTP-tekniikalle. Luvussa 8 käsitellään kontekstinhallintaratkaisuun liittyviä turvallisuusnäkökohtia. Luvun 9 kerrotaan kontekstinhallintaan liittyvistä toteutuksista, kontekstinhallinnan määrittelyjen muusta hyödyntämisestä sekä rajapintojen jatkokehittämisestä. TYÖPÖYTÄINTEGRAATION AVOIMET SOVELLUSRAJAPINNAT 9

10 TUOMAINEN, KOMULAINEN, RANNANHEIMO, MYKKÄNEN 2 TYÖPÖYTÄINTEGRAATIO 2.1 Yleistä työpöytäintegraatiosta Työpöytäintegraation (visual integration) tavoitteena on helpottaa erillisten järjestelmien yhtäaikaista käyttöä samalla työpöydällä. Esimerkiksi terveydenhuollon järjestelmissä käyttäjä joutuu tekemään useaan kertaan perusperiaatteiltaan samanlaisia toimintoja eri järjestelmissä. Näitä toimintoja ovat tyypillisesti järjestelmiin kirjautuminen ja sekä tietyn potilaan tietojen hakeminen. Työpöytäintegraatio helpottaa tätä tilannetta tarjoamalla keinot kertakirjautumisen ja yhteiseen kontekstiin siirtymisen toteuttamiseksi. Kertakirjautumisessa (single sign-on) käyttäjän tarvitsee kirjautua vain kerran yhteen järjestelmään. Muut integraatioon kytketyt sovellukset kykenevät käyttämään hyväksi tätä kirjautumistietoa, niin ettei niihin tarvitse kirjautua erikseen. Yhteiseen kontekstiin siirtymisen avulla 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 määrittelee yleisen mallin työasemalla toimivien sovellusten työpöytälähtöisen visuaalisen integroinnin toteuttamiseen. Kyseessä on selvityksessä Terveydenhuollon sovellusintegraatioratkaisujen määrittely (Mykkänen ym. 2004a) kuvatuista integrointimalleista käyttäjäläheinen integrointi. Työpöytäintegraation avulla käyttäjälle tarjotaan yhdenmukainen näkymä käsiteltävään tietoon huolimatta tarpeesta käsitellä tietoa useissa eri järjestelmissä. Tavoitteena on helpottaa erillisten järjestelmien yhtäaikaista käyttöä ja parantaa näin käyttäjän työprosesseja, joista tulee tehokkaampia ja paremmin työnkulkua tukevia. On tärkeää kuitenkin huomata, että työpöytäintegraatio ei poista sovelluksissa sijaitsevaa päällekkäistä tietoa. Se kuitenkin helpottaa ja tehostaa merkittävästi käyttötilanteita, joissa sama käyttäjä joutuu käyttämään useita sovelluksia samanaikaisesti. Käyttäjälle jää tällöin enemmän aikaa varsinaiseen työhönsä turhan toiston poistuttua. Myös 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ä. 2.2 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ä. Näitä ovat esimerkiksi käyttäjän ja asiakkaan (terveydenhuollossa potilaan) perustiedot. Myös muut mahdolliset tiedot ja käsitteet, joilla on sama merkitys eri järjestelmissä, voivat kuulua yhteiseen kontekstiin. Kontekstinhallintaa (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, koordinaattori-komponentti sekä mahdolliset agenttikomponentit (kuva 2.1). 10 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 6

11 TUOMAINEN, KOMULAINEN, RANNANHEIMO, MYKKÄNEN Järjestelmä 2 Järjestelmä 1 Järjestelmä 3 Koordinaattorikomponentti Agenttikomponentti Agenttikomponentti Kuva 2.1. Kontekstinhallinta-arkkitehtuuri. Koordinaattori-komponentti (context manager) toimii työpöydällä olevien järjestelmien näkymättömänä koordinaattorina. Se on 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. Tällöin puhutaan myös yhteisen kontekstin synkronoinnista. Agenttikomponenttien avulla 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. Käyttäjätunnusten täytyy olla tietysti tallennettuna etukäteen agenttikomponentille. Agenttikomponenttien käyttäminen on valinnainen lisätoiminto, jota ei välttämättä tarvitse toteuttaa kontekstinhallinta-arkkitehtuuriin. Järjestelmät ovat 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. TYÖPÖYTÄINTEGRAATION AVOIMET SOVELLUSRAJAPINNAT 11

12 TUOMAINEN, KOMULAINEN, RANNANHEIMO, MYKKÄNEN 3 TAUSTA PlugIT -hankkeen osapuolet tunnistivat jo hankkeen alkuvaiheessa kontekstinhallinnan ja sen avulla toteutettavan työpöytäintegraation yhdeksi keskeiseksi integrointimäärittelyn kohteeksi. Tehtävien määrittelyjen tavoitteeksi asetettiin soveltuvuus olemassa oleviin järjestelmiin sekä mahdollisten avointen standardien hyödyntäminen. PlugIT-hankkeessa tutkittiin aluksi Health Level Seven-yhdistyksen ylläpitämää CCOWstandardia (HL7 2004), joka on avoin standardi työpöytäintegraation toteuttamiseksi. Ensin perehdyttiin itse CCOW-standardiin, sen arkkitehtuuriin ja perusratkaisuihin ja arvioitiin standardin mahdollista toteuttamista ja käyttöönottamista. Sen jälkeen tutkittiin tarkemmin standardin mukaisia rajapintoja, joiden avulla CCOW-yhteensopivuus olisi mahdollista toteuttaa. Myös yhteen kaupalliseen sovelluskehitysohjelmistoon perehdyttiin tarkemmin. Sovelluskehitysohjelmiston avulla toteutettiin CCOW-yhteensopivia Windows-pohjaisia (ActiveX) demosovelluksia. Tämän työn tulokset on dokumentoitu opinnäytetyössä CCOW-standardi ja sen toteutus Sentillion Vergence Application SDK:lla (Komulainen, Tuomainen 2002). Lisäksi kokeiltiin toteuttaa demosovelluksia HTTP-tekniikalle. Näiden kokeilujen tarkoituksena oli selvittää, millaista CCOWyhteensopivuuden toteuttaminen sovelluksiin on. Koordinaattori-komponentista toteutettiin vielä minimiversio tavoitteena selvittää mm. komponentin toteuttamisen vaatimaa työmäärää. Käytännössä CCOW-standardin mukainen toteutus oli hankkeen osapuolten mielestä liian raskas tapa toteuttaa työpöytäintegraatiota. Lisäksi CCOW-standardin mukaisia valmiita tuotteita oli markkinoilla vain muutamia toteutuksia. Näin epävarmuustekijöiksi nousivat kontekstinhallintaympäristön hinnoittelu sekä mahdollinen riippuvaisuus ulkomaisesta toimittajasta. PlugIT -hankkeen aikana selvisi, että hankkeen eri osapuolien mielestä kontekstin välittäminen järjestelmien kesken ei saanut olla automaattista (kuten CCOW-standardissa), vaan sen haluttiin tapahtuvan käyttäjän toimesta/aloitteesta. Kontekstinhallinnan tarpeet Suomessa olivat näin vain tietojen vienti kontekstivarastoon ja niiden haku sieltä, eikä kontekstin vaihtumiseen haluttu automatiikkaa. Keskeisin kontekstinhallinnan toiminnallisuus oli näin saavutettavissa kevyemmälläkin ratkaisulla kuin CCOW-standardin mukainen tapa. Näiden tulosten perusteella PlugIT-hankkeessa alettiin määritellä kevyempää kontekstinhallintaratkaisua työpöytäintegraation toteuttamiseksi Suomessa. Ratkaisussa sovellettiin HL7:n CCOW-standardia ja määriteltiin yksinkertainen hajautettu kontekstinhallintapalvelu, johon eri tekniikoilla toteutetut tietyllä käyttäjän työasemalla sijaitsevat (esim. Windows- ja web-pohjaiset) sovellukset olisi helppo liittää. Tarkoituksena ei kuitenkaan ollut toistaa standardissa jo määriteltyjä vaatimuksia, vaan hahmottaa minimiratkaisua, jolla CCOW-tyyppinen toiminnallisuus olisi saavutettavissa. Keskeisimpänä tavoitteena oli määritellä perustoiminnallisuus, jolla käyttäjä- ja potilaskontekstin käsittely olisi toteutettavissa. PlugIT-kontekstinhallintaratkaisu yksinkertaistaa koordinaattorin toteutusta huomattavasti. Myös osallistuvien sovellusten ja koordinaattorin välinen viestintä on suoraviivaisempaa. PlugITkontekstinhallintaratkaisun keskeisimmät erot verrattuna CCOW-standardiin on lueteltu liitteessä PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 6

13 4 PLUGIT- KONTEKSTINHALLINTARATKAISU Tässä luvussa esitellään PlugIT-hankkeessa tuotettu kontekstinhallintaratkaisun perustoiminta. Kontekstinhallinnan määrittelyt ovat tässä raportissa Kontekstinhallinnan määrittely versio 2 - dokumentin (Tuomainen 2004) mukaiset. 4.1 Kontekstinhallintaratkaisun sisältö Kontekstinhallintaratkaisu muodostuu koordinaattori-komponentista ja siihen liittyneistä sovelluksista. Koordinaattori toimii työpöydällä olevien järjestelmien näkymättömänä kontekstin koordinoijana. Sen avulla siihen liittyneet sovellukset voivat jakaa keskenään yhteistä kontekstia. Kontekstinhallintaan liittyneet sovellukset ovat olemassa olevia sovelluksia (web/työasema). PlugITkontekstinhallintaratkaisu määrittelee koordinaattorin tarjoamat rajapinnat sovelluksille, rajapintojen käytön, sekä yhteisen kontekstin tietosisällön ja nimeämisen (kuva 4.1). Rajapinnat käydään tarkasti läpi tämän dokumentin luvussa 6 Tekniikkariippumattomat määrittelyt ja luvussa 7 Rajapintamäärittelyt HTTP-tekniikalle. Kontekstinhallinnan tietosisältöä ja nimeämistä käsitellään luvussa 5 Subjektit Sovellus 1 (web/työasema) Sovellus n (web/työasema) CM CD Koordinaattori Yhteinen konteksti Rajapinnat CM = ContextManager CD = ContexData Kuva 4.1. Minimitason kontekstinhallinta. 4.2 Kontekstinhallinnan toiminta Kontekstimuutosten toteuttamiseksi koordinaattorin tarvitsee toteuttaa kontekstinhallintaan liittymisessä ja siitä eroamisessa, sekä kontekstin tietosisällön käsittelyssä tarvittavat metodit. Sovelluksiin ei tarvitse toteuttaa rajapintoja, ne käsittelevät kontekstitietoja koordinaattorin tarjoamilla get/set- TYÖPÖYTÄINTEGRAATION AVOIMET SOVELLUSRAJAPINNAT 13

14 metodeilla. Koordinaattori ei näin koskaan kutsu osallistuvia sovelluksia. CCOW-standardin ilmoituksia kontekstin muutoksista tai kartoituksen tuloksista ei tarvita. CCOW-standardin kontekstinmuutosilmoitukset ja kartoitukset on kuvattu tarkemmin dokumentissa CCOW -standardi ja sen toteutus Sentillion Vergence Application SDK:lla (Komulainen, Tuomainen 2002). PlugIT-kontekstinhallintaratkaisussa kontekstiin kohdistuvat haut tapahtuvat käyttäjälähtöisesti potilaskontekstin osalta, taustalla ei ole CCOW-standardin automatiikkaa. Käytännössä tämä tarkoittaa sitä, että käyttäjä päättää, milloin sovellus hakee viimeisimmäksi käsitellyn potilaan tunnuksen kontekstista tai hakeminen perustuu välillisesti johonkin käyttäjän toimeen (esim. formloadiin). Haluttaessa potilaskonteksti voidaan hakea myös aina, kun sovellus avataan ensimmäisen kerran. Käyttäjätunnuksen osalta toimintoketju on käyttäjästä riippumaton. Järjestelmä hyödyntää käyttäjäkontekstia, kun se haluaa toteuttaa kertakirjautumisen Kontekstinhallintaan liittyminen Sovelluksen on liityttävä (Join) kontekstinhallintaan ennen kuin se voi kutsua muita kontekstinhallinnan metodeja. Missä vaiheessa sovellus omassa logiikassaan sitten liittyy kontekstinhallintaan, on ratkaistava toteutuskohtaisesti Potilaskontekstin muutos Potilaskontekstin muutos tapahtumaketju on seuraavanlainen (oletuksena, että sovellus on jo liittynyt kontekstinhallintaa): 1. Käyttäjä valitsee potilaan käyttäen jotain integraatioon kytkettyä sovellusta. 2. Sovellus asettaa (set) kontekstia identifioivan tunnisteen (potilastunniste) koordinaattorin ylläpitämään kontekstiin. 3. Käyttäjä vaihtaa toiseen sovellukseen ja klikkaa esim. "Hae viimeisin potilas" painiketta, jolloin toinen sovellus hakee kontekstista viimeisimmäksi käsitellyn potilaan. 4. Toinen sovellus sopeuttaa sisäisen tilansa ja näyttää tiedot potilaskontekstin mukaisesti (näyttää sen potilaan tiedot, jonka potilastunnuksen sai kontekstinhallinnasta) Käyttäjäkontekstin muutos Tässä on oletuksena, että on olemassa yksi luotettu sovellus, joka saa asettaa käyttäjätunnuksen kontekstiin, muut voivat vain hakea käyttäjätunnuksen kontekstista. Aihetta on käsitelty luvussa 8 Turvallisuus. Käyttäjäkontekstin muutos ei ole käyttäjän itsensä ohjaamaa, vaan hänen näkökulmastaan automaattista. Näin voidaan toteuttaa kertakirjautuminen eri sovelluksiin. Tämä tarkoittaa seuraavaa: Kun sovellusta avataan ja se liittyy kontekstinhallintaan, tarkistaa sovellus, onko kontekstinhallinnassa jo käyttäjätunnus (= käyttäjä on jo kerran kirjautunut johonkin kontekstinhallintaan kirjautumisen mahdollistavaan luotettuun sovellukseen). Jos on, hakee sovellus käyttäjätunnuksen kontekstista ja suorittaa automaattisen sisäänkirjauksen. Jos sovellusta avattaessa kontekstissa ei ole käyttäjätunnusta (= käyttäjä ei ole vielä kirjautunut kontekstinhallintaan kirjautumisen mahdollistavaan luotettuun sovellukseen), on olemassa seuraavat vaihtoehdot: 14 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 6

15 Jos sovelluksella, johon käyttäjä on kirjautumassa, on oikeus asettaa käyttäjä kontekstinhallintaan, pyydetään käyttäjää kirjautumaan, jonka jälkeen sovellus asettaa käyttäjätunnuksen kontekstiin Jos sovelluksella ei ole oikeutta asettaa käyttäjää kontekstiin, on käyttäjän kirjauduttava vain tähän sovellukseen ja käytettävä sitä ilman kontekstinhallintaa tai sitten käyttäjän on ensin kirjauduttava organisaatiossa ennalta määriteltyyn luotettuun sovellukseen. Näin käyttäjäkontekstinmuutosten tapahtumaketjusta muodostuu seuraavanlainen: 1. Käyttäjä avaa sovelluksen, joka liittyy kontekstinhallintaan. 2. Sovellus tarkistaa, onko käyttäjä jo kirjautunut kontekstinhallintaan luotetun sovelluksen välityksellä Jos käyttäjä on kirjautunut, sovellus hakee käyttäjätunnuksen kontekstista ja kirjaa käyttäjän sovellukseen Ellei käyttäjä ole kirjautunut, sovellus pyytää käyttäjää kirjautumaan. Jos kyseessä on luotettu sovellus, käyttäjäkonteksti asetetaan samalla koordinaattorin ylläpitämään kontekstiin. Jos kyseessä ei ole luotettu sovellus, kirjautuminen suoritetaan ainoastaan kyseiseen sovellukseen. 3. Vaiheet 1 ja 2 toistetaan aina, kun uusi sovellus aukaistaan. 4. Sovelluksia suljettaessa tai käyttäjän kirjautuessa ulos sovelluksesta sovellus eroaa kontekstista Kontekstinhallinnasta eroaminen Sovellusta suljettaessa tai siitä uloskirjautumisessa on huomioitava: Sovelluksen on erottava kontekstista. Kun viimeinenkin sovellus eroaa kontekstista, on kontekstinhallinnan lopetettava työpöydän yhteisen kontekstin ylläpitäminen Kokoava esimerkki Seuraavassa kokoava esimerkki kontekstinhallinnan toiminnasta (kuva 4.2). Esimerkissä kaksi järjestelmää liittyy koordinaattorin ylläpitämään kontekstiin ja sekä asettaa että hakee tietoa kontekstista. Lopuksi järjestelmät eroavat kontekstista. TYÖPÖYTÄINTEGRAATION AVOIMET SOVELLUSRAJAPINNAT 15

16 Järjestelmä 1 Koordinaattori Järjestelmä 2 1. Avaa järjestelmä 1 3. Käyttäjä A kirjautuu järjestelmään 1 2. Liity kontekstinhallintaan 4. Aseta käyttäjäkonteksti 5. Hae potilas X 6. Aseta potilaskonteksti 8. Liity kontekstinhallintaan 7. Avaa järjestelmä 2 9. Hae konteksti (käyttäjä ja potilas) Kontekstitiedot Järjestelmä 2: Kirjaa käyttäjä A ja näytä potilas X 12. Hae viimeisimmäksi käsitelty potilas 13. Hae potilaskonteksti 11. Aseta potilaskonteksti 10. Vaihda potilas Y Kontekstitiedot Näytä potilas Y 14. Eroa kontekstinhallinnasta 15. Eroa kontekstinhallinnasta Kuva 4.2. Kokoava esimerkki kontekstinhallinnan toiminnasta. 1. Aluksi käyttäjä avaa ensimmäisen järjestelmän (Järjestelmä 1) työpöydälle. 2. Järjestelmä 1 liittyy koordinaattoriin. 3. Käyttäjä kirjautuu normaalisti Järjestelmään 1 (järjestelmän on oltava luotettu sovellus). 4. Kirjautumisen jälkeen Järjestelmä 1 asettaa vaiheessa 3 saamansa käyttäjän käyttäjätunnuksen koordinaattorin ylläpitämään kontekstiin. 5. Käyttäjä hakee Järjestelmän 1 näytölle potilaan X. 6. Potilaan haun jälkeen Järjestelmä 1 asettaa potilaan X potilastunnuksen koordinaattorin ylläpitämään kontekstiin. Koordinaattorin ylläpitämässä kontekstissa on nyt käyttäjän käyttäjätunnus sekä potilaan X potilastunnus. 7. Käyttäjä avaa Järjestelmän Järjestelmä 2 liittyy koordinaattoriin. 9. Järjestelmä 2 käy avautuessaan hakemassa kontekstista kontekstitiedot. Käyttäjän käyttäjätunnuksen avulla Järjestelmä 2 kirjaa käyttäjän automaattisesti sisään. Näin toteutuu kertakirjautuminen. Lisäksi kontekstissa oli myös potilaan potilastunnus. Potilastunnuksen perusteella Järjestelmä 2 hakee vielä automaattisesti potilaan X Järjestelmän 2 näytölle. Näin potilaskonteksti on synkronoitu järjestelmien välille. 10. Käyttäjä vaihtaa Järjestelmässä 2 potilaan Y näytölle. 11. Järjestelmä 2 asettaa kontekstiin potilaan Y tunnuksen. 12. Käyttäjä päättää hakea järjestelmään 1 viimeisimmäksi käsitellyn potilaan. 13. Järjestelmä 1 käy hakemassa kontekstista potilaan Y tunnuksen ja vaihtaa näytölle tunnuksen perusteella potilaan Y näytölle. Näin potilaskonteksti on synkronoitu kahden järjestelmän välillä. 14. Järjestelmä 1 eroaa kontekstista. 15. Järjestelmä 2 eroaa kontekstista. Koordinaattori lopettaa tällöin työasemakohtaisen kontekstin ylläpitämisen. 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 6

17 4.3 Kontekstinhallintaratkaisun sessionhallinta, elinkaari ja identifiointi Koordinaattori-komponentin yhteydessä aikaväliä, jossa yksi tai useampi ohjelma on yhteydessä komponenttiin, kutsutaan sessioksi. Sessio alkaa, kun ensimmäinen ohjelma liittyy kontekstinhallintaan ja päättyy, kun viimeinen ohjelma katkaisee yhteyden kontekstinhallintaan. Sessionhallinnalla puolestaan tarkoitetaan koordinaattori-komponentin kykyä huolehtia mm. seuraavista asioista: elinkaaren hallinta (session luominen ja tuhoaminen) session identifioiminen session tilan ylläpito (esim. aktivointi, passivointi ja kontekstin säilyttäminen) komponentin oman elinkaaren hallinta (instantiointi, tuhoaminen). PlugIT-kontekstinhallintaratkaisussa kontekstiin liittyvien sovellusten identifiointi toteutetaan käyttämällä seuraavia parametreja: applicationname: sovelluksen yksilöllinen nimi. Liittyessään kontekstinhallintaan sovellus tunnistautuu koordinaattori-komponentille nimensä avulla. Sovelluksen nimellä voidaan myös konfiguroida etukäteen koordinaattorille, mitkä sovellukset voivat osallistua yhteiseen kontekstiin. Konfiguroidaanko sallitut sovellukset etukäteen, on ratkaistava toteutuskohtaisesti. participantcoupon: tunnus, jonka koordinaattori-komponentti antaa sovellukselle sen liittyessä kontekstinhallintaan. Parametri yksilöi kontekstiin osallistuvan sovelluksen ja sovelluksen on käytettävä sitä jatkossa ollessaan yhteydessä koordinaattoriin. työaseman ip: tarvitaan työasema tunnistamiseen, jos koordinaattori sijaitsee palvelimella. Parametrin käyttöä on kuvattu tämän dokumentin kappaleessa 7.3 Sessionhallinta. Parametreja käytetään seuraavasti: Kun sovellus liittyy kontekstinhallintaan, koordinaattori tunnistaa sen applicationnameparametrin avulla. Liittymisen yhteydessä koordinaattorin on annettava sovellukselle uusi participantcoupontunniste Kun sovellus taas eroaa kontekstinhallinnasta, on sen käytettävä saamaansa participantcoupontunnusta, jotta koordinaattori-komponentti voisi ylläpitää listaa kontekstinhallintaan osallistuvista sovelluksista ja lopettaa session, kun viimeinenkin sovellus on katkaissut yhteyden. participantcoupon-tunnusta käytetään sovelluksen tunnistamiseen muissakin koordinaattorin metodeissa (get/set). CCOW-standardin kontekstitunnistetta (contextcoupon) ei PlugIT-kontekstinhallintaratkaisussa tarvita, koska kontekstissa säilytetään vain tuoreinta, viimeksi asetettua kontekstia. Ehdotettua kontekstia ei tarvitse erikseen säilyttää (ehdotettu konteksti kuvattu tarkemmin dokumentissa CCOW - standardi ja sen toteutus Sentillion Vergence Application SDK:lla (Komulainen, Tuomainen 2002)). TYÖPÖYTÄINTEGRAATION AVOIMET SOVELLUSRAJAPINNAT 17

18 5 KONTEKSTINHALLINTARATKAISUN TIE- TOSISÄLTÖ 5.1 Konteksti Kontekstinhallinnan (koordinaattorin) tärkein tehtävä on säilyttää ja ylläpitää työpöytäkohtaista kontekstia, eli tietoja viimeksi valitusta potilaasta, sisäänkirjautuneesta käyttäjästä ja muista mahdollisista tiedoista, joita työpöytäintegraatiossa halutaan hyödyntää. PlugIT-kontekstinhallintaratkaisussa tärkeimmät tiedot liittyvät käyttäjään ja potilaaseen. Näiden tietojen avulla saadaan toteutettua toiminnallisuus, jossa integraatioon osallistuvat sovellukset voivat toteuttaa kertakirjautumisen (käyttäjä) ja seurata saman potilaan tietoja koordinoidusti eri ohjelmissa (potilas). Yksinkertaistettuna tämä tarkoittaa potilaan ja käyttäjän tunnuksien hakemista kontekstista sekä niiden välittämistä kontekstiin. PlugIT-kontekstinhallintaratkaisun kontekstin tietosisältö on määritelty CCOW-standardin dokumentin Subject Data Definitions (Seliger 2002b) mukaisesti tietokokonaisuuksittain, joita kutsutaan subjekteiksi (context data subject). Jokaiseen subjektiin liittyy joukko tietoja, joista jokainen muodostaa nimi-arvoparin (context item). Esimerkiksi käyttäjäsubjektista voisi löytyä seuraava tieto, joka vastaa käyttäjätunnusta: User.ID.Logon MattiM (nimiosa) (arvo). 5.2 Subjektit Subjektien nimeäminen PlugIT-kontekstinhallintaratkaisun subjektien nimeäminen ja syntaksi määritellään CCOWstandardin dokumentin Subject Data Definitions (Seliger 2002b) mukaisesti. Syntaksi on yhteinen kaikille subjektille. Kaikki subjektit nimetään seuraavan säännön mukaisesti: Subject_label.role.Name_prefix.optional_name_suffix Jokainen osa erotetaan toisistaan pisteellä ja jokaisella osalla on oma tarkoituksensa: Subject_label: Ilmaisee subjektin, johon tieto kuuluu, esim. Patient. role: Kertoo tiedon roolin. PlugIT-kontekstinhallintaratkaisussa on määritelty rooliksi ainoastaan: Id = identifier data. Tieto, jota käytetään jonkin todellisen entiteetin tunnistamiseen, esim. yksilöllinen potilastunnus. PlugIT-kontekstinhallintaratkaisun kontekstissa käsitellään ainoastaan Id-tietoja. CCOW-standardissa on määritelty myös muita tiedon rooleja (Seliger 2002b, Tuomainen 2003b). Name_prefix: Ilmaisee mitä tieto tarkoittaa, esimerkiksi Logon (= kirjautumistieto). 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 6

19 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. Suffix-osaan voidaan tätä tarkoitusta varten esimerkiksi sovelluksen nimi. CCOW-standardissa tätä käytetään mm. erottamaan saman käyttäjän eri käyttäjätunnukset eri sovelluksissa (Seliger 2002b, Tuomainen 2003b) Subjektien käyttäminen Seuraavassa käydään läpi subjektien käyttäminen PlugIT-kontekstinhallintaratkaisussa, joka noudattaa CCOW-standardia: Subjektien riippuvaisuus toisistaan: PlugIT-kontekstinhallintaratkaisun käyttäjä- ja potilassubjektit eivät ole riippuvaisia toisistaan, eikä määrittelyssä ole mukana muita subjekteja, jotka voisivat olla riippuvaisia käyttäjä- ja potilas-subjekteista. Vähintään yksi id-tieto kontekstissa: Kontekstin tietosisällölle ei ole muita rajoittavia tekijöitä kuin yhden id-tiedon pakollisuus. Kontekstin tietosisältönä on oltava siis aina vähintään yksi idtieto. Sama tieto useaan kertaan: CCOW-standardissa joillakin subjekteilla voi olla yhtä subjektin nimeä kohden useita eri arvoja. PlugIT-kontekstinhallintaratkaisussa kontekstissa on ainoastaan yksi yksikäsitteinen käyttäjän ja/tai potilaan id-tieto. Aakkoskoosta riippuvuus: Subjektin tietojen nimet ja arvot on käsiteltävä aakkoskoosta riippumattomina, ellei toisin ole erikseen mainittu. HL7 2.4 Specification: Spesifikaatiota käytetään perustana, jos mahdollista, subjektin tietojen nimeämisessä, semantiikassa ja tietojen arvojen tyypeissä. Lokalisointi: Subjektin tietojen nimet tulee esittää englanniksi riippumatta maasta, jossa niitä käytetään. Sen sijaan tietojen arvot voivat olla kyseisen maan omalla kielellä PlugIT-kontekstinhallintaratkaisun subjektit PlugIT-kontekstinhallintaratkaisun kontekstitiedoiksi on määritelty käyttäjä (User)- ja potilassubjektit (Patient). Subjektit User ja Patient on otettu CCOW-standardista ja nimetty standardin mukaisesti. Lisäksi on mahdollista määritellä custom-subjekteja omien tarpeiden mukaan. Customsubjektien määrittelysäännöt ovat CCOW-standardin mukaisia KÄYTTÄJÄ-SUBJEKTI User- eli käyttäjäsubjektia käytetään käyttäjän tunnistamiseen sovelluksessa. Ainoana identifioivana tunnuksena tällä subjektilla on käyttäjän käyttäjätunnus. Käyttäjä-subjektin avulla voidaan toteuttaa kertakirjautuminen (single sign-on). Ensimmäinen sovellus, jonka käyttäjä työpöydällään käynnistää, kysyy käyttäjältä tämän käyttäjätunnuksen, jonka perusteella sovellus sitten asettaa käyttäjätunnuksen yhteiseen kontekstiin. Tämän jälkeen avattavat ja kontekstinhallintaan liittyneet sovellukset voivat käynnistyessään käyttää hyväkseen kontekstissa olevaa käyttäjätietoa ja suorittaa kirjautumisen käyttäjän puolesta. Minimitoteutuksessa tarvitaan vain käyttäjän käyttäjätunnusta, joka on käyttäjän yksilöivä id-tieto User.Id.Logon CCOW-standardista on määritelty käyttäjä-subjektille muitakin item-tietoja (Seliger 2002b, Tuomainen 2003b). TYÖPÖYTÄINTEGRAATION AVOIMET SOVELLUSRAJAPINNAT 19

20 PlugIT-kontekstinhallintaratkaisussa on oletuksena, että kaikki järjestelmät käyttävät samaa geneeristä id-tunnusta ollessaan yhteydessä kontekstinhallintaan. Näin Id-tiedon Suffix-osa ei ole tarpeellinen (User.Id.Logon.Suffix). HL7 tietotyyppi User.Id.Logon-tiedolle on string. Etuna geneerisen id-tunnuksen käytöstä on käyttäjätunnusten mappauksen tarpeettomuus kontekstinhallinnassa. Tosin mahdollinen mappaus geneeristen id-tunnuksien ja järjestelmien omien käyttäjätunnuksien välillä jää järjestelmien omalle vastuulle (ellei geneerisen id-tunnuksen käyttö riitä). Tällainen geneerinen id-tunnus on mahdollista saada varsinkin tulevaisuudessa toimikortilta POTILAS-SUBJEKTI Patient- eli potilassubjektilla tunnistetaan potilas. Potilassubjektin avulla kontekstinhallintaan liittyneet sovellukset voivat synkronoida käyttäjälle näyttämänsä potilaan tiedot. CCOW-standardissa on määritelty potilas-subjektille useita item-tietoja (Seliger 2002b, Tuomainen 2003b). PlugIT-kontekstinhallintaratkaisussa näistä tarvitaan ainoastaan potilaan yksilöivää tunnusta, joka Suomessa on henkilöturvatunnus. Potilaan yksilöivä id-tieto on näin Patient.Id.NationalIdNumber HL7 tietotyyppi Patient.Id.NationalIdNumber-tiedolle on string CUSTOM-SUBJEKTIT Yksittäisellä organisaatiolla voi olla tarve luoda uusia subjekteja omiin käyttötarpeisiinsa, ellei niitä löydy jo valmiiksi määriteltyinä. Tällöin voidaan määritellä itse omia custom-subjekteja. Customsubjektit on määriteltävä kuten CCOW-standardissa (Seliger 2002b). Näin itse määritellyt subjektit eivät ole ristiriidassa CCOW-standardissa valmiiksi määriteltyjen subjektien kanssa. Custom-subjektien erottaminen muista subjekteista tapahtuu käyttämällä erikseen määriteltyä avainsanaa. Avainsanana käytetään custom subjektia käyttävän organisaation World Wide Web Consortium (W3C) domain-nimeä. Tällaisella tekniikalla eri organisaatioiden määrittelemät custom-subjektit voidaan tunnistaa ja erottaa toisistaan. Taulukossa 1 on esimerkkejä customsubjekteista. Taulukko 1. Esimerkkejä custom subjektien määrittelystä. Custom-subjekti [plugit.fi]daterange [plugit.fi]daterange.id [plugit.fi]startdate Selitys Oma uusi subjekti (DateRange), jota ei löydy standardista Oma uusi subjekti (DateRange) ja sille oma uusi item (tieto alkamispäivä, StartDate), Id-osa CCOW-standardin mukainen Patient.Co.[plugit.fi]Current_medications Standardisubjektiin (Patient) lisätty oma uusi item (Current_medications), Co-osa CCOW-standardin mukainen 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 6