PlugIT-menetelmätulokset: Integrointiratkaisujen määrittely ja määritysten hyödyntäminen

PlugIT-menetelmätulokset: Integrointiratkaisujen määrittely ja määritysten hyödyntäminen

PlugIT loppuseminaari

31.8.2004, Kuopio

Juha Mykkänen

Kuopion yliopisto, HIS-tutkimusyksikkö

Koulutustyöpaja 2• PlugIT-menetelmätulokset terveydenhuollon

organisaatioille ja sovellusten tuottajille8:30-9 Ilmoittautuminen ja aamukahvi 9-10 Avaus, Sovellusintegraation vaiheet ja avoin integraatio10-11 Tietojärjestelmä- ja integrointitarpeiden kartoitus11-12 Tarpeista ohjelmisto- ja integrointivaatimuksiin

12-13 Lounas (omakustanteinen)

13-14.15 Integrointimäärittelyt ja niiden hyödyntäminen(kahvitauko)14-15 Testaus ja PlugIT-leimausmenettely15-16 Kokemukset menetelmäpilotista,

jatkotyö

Iltapäivän tavoitteet

• vaatimuksista ratkaisuiksi:– tekniikkariippumattomat (sisällölliset ja

periaateratkaisut)– tekniset ratkaisut ja rajapinnat– toteutukset ja toteutuskohtaiset seikat

• testaus ja leimaaminen– testaus ja testaustulokset, käyttöönotto- ja

integrointitestaus, PlugIT-leima

• kokemuksia ohjelmistotuotannon menetelmäpilotista

• jatkotyö, keskustelu

Esitykseen liittyvää materiaalia

• Terveydenhuollon sovellusintegraatioratkaisujen määrittely – integrointiprosessi– tavoitteiden ja vaatimusten määrittely (käsiteltiin aamupäivällä)– tekniikkariippumaton määrittely– tekninen määrittely– toteutuskohtaisten seikkojen kuvaus– esimerkkejä

• Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus

– toteutusten tekeminen (toinen työpaja)– määritysten mukaisuudesta varmistuminen (myöhemmin iltapäivällä)

• Component and service technology families– integrointitekniikat, erityisesti palvelupohjainen integraatio

• Ohjelmistotuotannon välineselvitys: näkökulmia terveydenhuollon ohjelmistoyrityksen välinesalkun kokoamiseen

– kehitysvälineet, integrointivälineet, palvelimet jne.• Standardien arviointi ja valinta

Integrointimenetelmän taustat

• Model-Driven Architecture (MDA): vaiheittainen tarkentaminen yleisestä mallista tarkkaan tekniseen ratkaisuun

• HL7 (Message) Development Framework: viitemallien käyttö, tietomallinnus, viestimäärittelyt

• Integrating Healthcare Enterprise: useita järjestelmiä kattavien työnkulkujen määrittelyt, käytännön testaus

• ISO RM-ODP ja 7-tasoinen yhteentoimivuusmalli: ratkaisujen kattavuus, eri näkökulmien riittävä huomiointi

• Hajautetut sovellukset, viitearkkitehtuuri• Integrointimallit (tieto, palvelu, prosessi, käyttäjä),

rajapinnat, sovittimet, avoimet tekniikat• tuettava sekä paikallisista tarpeista tai valmiista ratkaisuista

lähteviä ratkaisuja (bottom-up) että standardien käyttöönottoa ja soveltamista (top-down)

T a u sta -se lv itykse t

Nykytila nku va u s

Pilo to in ti-su u n n ite lma

- luette loin tegraatio tarpe is ta-oh jeet määr i tte lyjentek em is een-s is ä l tömäär i tte lytmäär i tte lydok umente i l le-es imerk k e jä määr i tte lyis täer i tyyppis i inin tegro in ti ti lan te is i in-mal l i ra tk a is u ja- to teutus väl ine i tä

-va lm i i ta määr i tte lyi tä-p i lo to in ti-o lemas s a olevat tek n i ik at-oma laatu- ja tuotantopros es s i

Pro je kti-su u n n ite lma

Sa ira a la ta i mu uth . o rg a n isa a tio

In te g ra a tto r i(P lu g IT)

O h je lm isto -yr itys

Toiminnankehittäminen

Integrointi-tarve

Va a timu s-mä ä r itte ly

L iittymä nmä ä ritte ly

T o te u tu s(p ilo to in ti)

Tulosten hy väksy ntäKäy ttöönotto ja

soveltaminen

1. INTEGRAATIO-VAATIMUKSET

2. TEKNIIKKARIIPPUMATONLIITTYMÄMÄÄRITTELY

3. TEKNINENLIITTYMÄMÄÄRITTELY

4. LIITTYMÄNTOTEUTUKSEN KUVAUS

m ä ä ritte lytyö

m ä ä ritte lytyö

m ä ä ritte ly jato te u tu s

- ty ön dokumentointi-arviointi- integrointiprosessinkehittäminen

-y leistäminen-menetelmänvalidointi

-s ub s tans s ios aam inen-p i lo to in tik ohde-k äytetyt tek n i ik at- laa tuvaatim uk s et

ja tko ke h itys

to te u tu stu o tte e s s a

Avo ime tin te g ro in timä ä r itte ly t

Yleiskuva

Määrittelyn ja toteutusten hallinta

Vaatimushankinta +

dokumentointi

Avoimen

integrointiratkaisun määrittely

Toteutus, pilotointi

Järjestelmäintegraatioprojektin vaiheet

Visio

Projektin käynnistystoimetProjektin käynnistystoimet

Toiminnan suunnitteluToiminnan suunnittelu

Tekninen suunnitteluTekninen suunnittelu

J ärjestelmien viimeistely/ lisäosien rakentaminen


Prosessimuutosten toteu-tus, käyttäj ien koulutus


Asennukset, käyttöönottoAsennukset, käyttöönotto

Projektin päättäminenProjektin päättäminen

Suunnittelu-

vaihe

Toteutus-

vaihe

Toi

min

nan

jatk

uva

para

ntam

inen

Käyttäjätarpeiden määrittelyKäyttäjätarpeiden määrittely

VisioVisio

Projektin käynnistystoimetProjektin käynnistystoimet

Toiminnan suunnitteluToiminnan suunnittelu

Tekninen suunnitteluTekninen suunnittelu





Asennukset, käyttöönottoAsennukset, käyttöönotto

Projektin päättäminenProjektin päättäminen

Suunnittelu-

vaihe

Toteutus-

vaihe

Toi

min

nan

jatk

uva

para

ntam

inen

Käyttäjätarpeiden määrittelyKäyttäjätarpeiden määrittely

• Tarvelähtöisyys• Tavoittehakuisuus• Monenvälisyys• ”Oman toimen

ohella” tekeminen• PlugIT:issa

– avoin määrittely

– paikallinen tai tuotekohtainen toteutus

[Saranummi, Tolppanen: Järjestelmäintegraatio-projektin vaiheet, 2003.]

Määrittelytyön lähtökohdat

• tunnistetut (ja priorisoidut) integrointikohteet (=tarpeet)• kerätyt integrointivaatimukset (=tarkennetut tarpeet)!!!• projektin osapuolten sovellukset

– niiden nykyinen toiminnallisuus– niissä käytetyt tekniikat ja arkkitehtuurit

• standardit– sisällölliset ja toiminnalliset määritykset + viitemallit– käytettävissä olevat tekniikat (sovelluksissa käytetyt ja uudet)

• yleisiä toiminta- ja dokumentointitapoja– käytetään vain niitä dokumentteja/osioita mitä tarvitaan– perustelut valinnoille– minimitaso ja lisätasot– versionumero, pvm, tuottamiseen osallistuneet (vakiotiedot)

Määrittelyn eteneminen

[Mykkänen, Porrasmaa, Rannanheimo, Korpela: A process for specifying integration for multi-tier applications in healthcare. Int J Med Inf 2003:70(2-3):173-182.]

1 . K o hde alue e nanalyso int i

2 .So ve llus arkkite htuur intunnis tam ine n

3 . O lem as s ao le vie nso ve l lus te n te kniiko ide n

tunnis tam ine n

4 . To im innall is te nl i i t tym ie n tunnis tam ine n

5 . L ii t tym äte kniiko ide nvalinta

7 . To te utuks e s s akäyte t tävie n tuo tte ide n

valinta

6 . L ii t tym ie n m äär i t te ly

- inte gro intivaat im uks e t-o lem as s ao le vie n so ve l lus te n to im innal l is uus

- s o ve l lus arkkite htuur i- s o ve l lus te n alus ta

- to im innal l is e t inte gro intipis te e t

- s em antt is e t vaatim ukse t

to im ialans tandardit

- te knis e ts tandardit

-uude t m e to dit , työ kalutja te kniikat

- inte gro intipis te e tko hde arkkite htuur is s a

-o lem as s ao le va te knine n inf ras truktuur i

- te kniikkar i ippum attom atl i i t tym ät

-uus i s o ve l lus inf ras truktuur i- inte gro inti te kno lo giat

- te knis e t l i i t tym ät

1. INTEGRAATIO -VAATIM UKSET

2. TEKNIIKKA-RIIPPUMATON

LIITTYMÄMÄÄRITTELY

3. TEKNINENLIITTY M Ä-

M ÄÄRITTELY

Vaatimukset + toiminnan

kehittäminen

Osallistuvien sovellusten

ratkaisut

Toimialan standardit

ja viitemallit

Tekniset standardit,

työkalut

Vaiheittainen tarkennus,mallit ja ohjeistus eri vaiheisiin,

tavoitteena ratkaisun kattavuus ja tarkkuus,mutta selkeä, helppokäyttöinen

ja toistuva menettely

--SOVELTUU SEKÄ AVOIMEENETTÄ TAPAUSKOHTAISEEN

INTEGROINTIIN

Top-down ja bottom-up

• Top-down– standardit

– toimintaprosessien mallinnus

– tarkentaminen, erikoistaminen

– vaatimukset -> tekniikkariippumattomat -> tekniset määrittelyt -> toteutus

• Bottom-up– valmiit tuotteet ja ratkaisut

– valmiiden ratkaisujen hankkiminen ja tutkiminen -> toteutukset, tekniset määrittelyt?

– yleistäminen -> tekniikkariippumattomat, vaatimukset

Molemmat tavat prosessissa mukana(esim. standardit + olemassaolevat järjestelmät määrittelyn

lähtökohtina)

Uudelleenkäytettävät tuotokset• Integrointivaatimukset

– kuvata integroinnin tarkoitus ja tavoitteet riittävällä tasolla integroinnin tarkempaa määrittelyä ja toteutusta varten

– yksiselitteisiä– tuotoksia verrataan ja arvioidaan suhteessa vaatimuksiin– osa (tai kaikki) vaatimuksista tarkennetaan..

• Tekniikkariippumaton määrittely (ratkaisun periaatteet ja sisältö)– vastaa selkeästi rajattuun integrointitarpeeseen– ratkaisun sisältö ja perusperiaatteet (tiedot, toiminnot, osapuolet, vastuut,

roolit, integrointimalli)– ei sido ratkaisua yksittäiseen tekniikkaan (voidaan soveltaa monilla

tekniikoilla)• Tekninen määrittely (rajapinta)

– rajapinnan toteuttamista varten tietyllä valitulla rajapintatekniikalla, tarkka määritys

– samasta teknisestä määrittelystä toteutetut rajapinnat eri tuotteissa toimivat yhdessä

– mahdollistaa edelleen eri toteutustekniikat järjestelmissä• Lisäksi tarpeen kuvata yhdenmukaisesti tietyt toteutuskohtaiset

asiat

Tuotosten jaon tarkoitus

• Avoimet dokumentit tarkentuvat vaatimuksista kohti toteutusta, ”taaksepäin varmistus”: – samoihin vaatimuksiin voi(si) vastata useilla (tekniikkariippumattomilla)

määrittelyillä (esim. eri integrointimalleilla)– samat tekniikkariippumattomat voi tarkentaa useilla integrointitekniikoilla

toteutettaviksi (mallitason yhteensopivuus)– samat tekniset määrittelyt voi toteuttaa (siinä määritellyillä tekniikoilla)

useisiin tuotteisiin

• Toteutuskohtaiset tai yhteen pilottiin tai määrittelyprojektiin kuuluvat asiat eivät kuulu avoimiin määritysdokumentteihin– erillään projekti- ja pilotointisuunnitelmat, taustatietoihin kuuluvat

järjestelmäkuvaukset (nykytilakuvaukset) jne.

PlugIT-rajapintojen TAVOITE

Avoimet määrittelytuotoksetIntegrointivaatimusmäärittelyt

-käyty läpi aamupäivällä

Avoimet määrittelytuotoksetTekniikkariippumattomat liittymämäärittelyt

Mikä on tekniikkariippumaton liittymämäärittely + tavoite

• integrointiratkaisun kuvaus– osapuolet, yhteistoiminnan perusmalli, työnkulut– tietosisältö, toiminnot (elementit, operaatiot)– siten, että rajapinnat voidaan tarkentaa eri tekniikoilla– malli integrointiratkaisusta (~MDA PIM, IHE integration profile)

• (viimeistään) tällä tasolla päätetään, minkä tyyppistä integrointia tehdään

• Kenelle? – 1. tilaajille, toimittajille ja integraattorille ratkaisun sisällön ja

perusperiaatteiden määrittely (+ pohja tekniselle työstämiselle), – 2. hyväksyminen, standardointi viitemalli-tasolla

1 . K o hde alue e nanalys o int i

2 .So ve llus arkki te htuur intunnis tam ine n

3 . O lem as s ao le vie nso ve l lus te n te kni iko ide n

tunnis tam ine n

4 . To im innal l is te nl i i t tym ie n tunnis tam ine n



valinta


- inte gro int ivaat im uks e t-o lem as s ao le vie n so ve l lus te n to im innal l is uus


- to im innal l is e t inte gro int ipis te e t

- s em antt is e t vaat im uks e t

s tandardi t

- te knis e ts tandardi t

-uude t m e to di t , työ kalutand te kno lo giat

- inte gro int ipis te e tko hde arkki te htuur is s a


- te kno lo giar i ippum attom atl i i t tym ät

-uus i s o ve l lus inf ras truktuur i- inte gro int i te kno lo giat


1. INTEG RAATIO -VAATIM UKSET

2. TEKNIIKKA-RIIPPUMATON LIITTYMÄ-

MÄÄRITTELY


M ÄÄRITTELY

Tekniikkariippumaton määrittely: tuottaminen

1. Tarkempaan määrittelyyn otettavien integrointivaatimusten rajaus ja integrointimallin valinta.

2. Määrittelyssä hyödynnettävien standardien ja muiden ulkoisten määritysten valinta.

3. Integrointitilanteessa mukana olevien sovellusten toimintojen ja tietosisällön ja niissä käytetyn arkkitehtuurin kartoittaminen integrointia varten.

4. Integroinnissa käytettävien toiminnallisten osien (sovellusroolien, komponenttien) nimeäminen tai tarkentaminen

5. Valittujen vaatimusten tarkentaminen ja kohdistaminen nimettyihin osiin.6. Integrointitavan ja integroinnin perusratkaisuperiaatteen valinta.7. Integrointipisteen määrittely sovellusten arkkitehtuurissa ja eri osien

vastuiden määrittely, tai eri vaihtoehtojen tunnistaminen8. Sovellusten välisen vuorovaikutuksen määrittely.9. Sovellusten välisten liittymien sisällön määrittely

tekniikkariippumattomalla tasolla.10. Minimitason määrittely.11. Tarkennetut vaatimukset teknisille liittymämäärittelyille ja toteutuksille.

Kuinka perusratkaisu määritellään

• sopivin integrointimalli? – tietopohjainen – usein löysä kytkentä järjestelmien välillä, tiedon

ajantasaisuuden varmistukset– palvelupohjainen – päällekkäisyyden vähentäminen (tietojen syöttö,

ylläpito, kehitystyö), – prosessipohjainen määrittely – monenvälisyys, – käyttäjän tukeminen

• ohjelmointirajapinta, viesti-integraatio, yhteinen tietovarasto, koordinaattori, käyttöliittymä?

• keskitetty vai hajautettu ratkaisu? (vastuiden kannalta)• kahdenvälinen vai monenvälinen ratkaisu? (point-to-point vai

usean sovelluksen välinen)• tiukka vai löysä kytkentä? (viittaus tai tiedonsiirto, tietotyypit)• hajautettu vai paikallinen rajapinta? (yhden vai monen

käyttäjän)• synkroninen vai asynkroninen ratkaisu?• standardien tarjoamat integrointitavat?

Integrointiratkaisujen luokitteluja

• EAI – sovellusintegraatio, yleensä saman organisaation sisällä, tiukka kytkentä, ohjelmointirajapinnat, RPC

• B2B – kumppani-integraatio, organisaatioiden välinen, löysä kytkentä, viestit ja dokumentit, viestijonot ja -alustat

• B2C – asiakasintegraatio, käyttöliittymät, itsepalvelut

• declarative – tiedon kuvaaminen (viestin lähettäjä ja vastaanottaja)

• imperative – toiminnon käynnistäminen tai suorittaminen (palvelun pyytäjä ja tarjoaja)

• interrogative – tiedustelu (kysyjä ja vastaaja)

Integrointipiste sovellusarkkitehtuurissa

• esimerkeissä web-pohjainen laboratoriopyyntöjen teko-sovellus (System 1) käyttää hajautettua yleistä palvelua organisaatioyksiköiden listaamiseen. Tämä palvelu (System 2) taas on toteutettu kapseloimalla perinnejärjestelmän käyttöliittymä (System 3).

R-U

u s e r in te rfa ce fra m e w o rk

w o rks ta tio n /w e b s e rve r EE

a p p lica tio ns e rve r /

e n te rp ris e EE

p e rs is te n cefra m e w o rk /re s o u rce EE

Sy stem 1

D a ta b a s e(d a ta b a s e s e rve r)

En te rp ris ea p p lica tio n (w e b /a p p lica tio n s e rve r)

W eb se rve rapp lica tion (web

se rve r)

W e b u s e r in te rfa ce(b ro w s e r)

Sin

gle

use

r d

om

ain

En

terp

rise

do

ma

in

Use rtie r

W o rksp acetie r

E nte rp risetie r

R e so urcetie r

Sy stem 2

C o m m o n s e rvice(a p p lica tio n s e rve r)

L e g a cy s ys te mw ra p p e r

(a p p lica tio n s e rve r)

Sy stem 3L e g a cy s ys te mu s e r in te rfa ce

(te rm in a l e m u la to r)

L e g a cy d a ta b a s e(d a ta b a s e s e rve r)

L e g a cys e rve r-s id ea p p lica tio n

(d a ta b a s e s e rve r) Exe

cutio

n en

viro

nmen

t (E

E)

W -E

•Esimerkissä 2 integrointiratkaisua: web-pohjainen laboratoriopyyntöjen teko-sovellus (System 1) käyttää hajautettua yleistä palvelua organisaatioyksiköiden listaamiseen. Tämä palvelu (System 2) on toteutettu kapseloimalla perinnejärjestelmän käyttöliittymä (System 3).

Sisältö – tekniikkariippumaton määrittely

1 Johdanto – dokumentin tarkoitus jne.2 Dokumentissa käytetyt tietotekniset ja terveydenhuollon käsitteet3 Rajaus – mihin vaatimuksiin vastataan, mikä on määriteltyjen

liittymien käyttötarkoitus4 Käytössä olevien järjestelmien toiminnallisuus rajaukseen liittyen

– tarvittaessa erilliseen nykytila-dokumenttiin

5 Käytössä olevien järjestelmien arkkitehtuurit ja tekniikat rajaukseen liittyen

– tarvittaessa erilliseen nykytila-dokumenttiin5.1 Järjestelmän A arkkitehtuuri ja tekniikat5.2 Järjestelmän B arkkitehtuuri ja tekniikat5.3 Muiden vastaavien järjestelmien vaikutukset (yleistettävyys)

6 Hyödynnettävien standardien ja määritysten hyväksikäyttö 7 Yhteistoiminnallisuuden arkkitehtuuri7.1 Sovellusosien yleiset nimet ja kuvaukset7.2 Integrointipisteet sovellusten arkkitehtuureissa7.3 Käsitemalli, johon integrointi perustuu, esim. luokkakaavio

(tarvittaessa)

Sisältö – tekniikkariippumaton määrittely..

8 Katetut tietoja toimintokokonaisuudet8.1 Yhteistoiminnallisuuden kuvaus (kuva kutsuista, suhteista,

järjestyksestä..)8.2 Toimintojen nimet ja kuvaukset8.3 Tietoelementtien nimet ja kuvaukset8.4 Sovellusten vastuut tietoja toimintokokonaisuuksista8.5 Virhetilanteet8.6 Minimitaso ja lisätasot9 Vaatimukset teknisille liittymille ja toteutuksille

o siltä osin kuin ovat tarkentuneet tai on tullut uusia integrointivaatimusten jälkeen

9.1 Toiminnalliset ominaisuudet9.2 Ei-toiminnalliset ominaisuudet9.3 Avoimuus, siirrettävyys ja ylläpidettävyys9.4 Suorituskyky ja käytettävyys9.5 Tietoturva ja virhetilanteet10 Määrittelyjen mukaisuuden toteaminen

Avoimet määrittelytuotoksetTekniset määrittelyt

Mikä on tekninen liittymämäärittely + tavoite

• integrointiratkaisun kuvaus siten, että eri sovelluksiin voidaan toteuttaa sama tekninen (ja toiminnallinen/sisällöllinen) ratkaisu

• tarkka, lopullinen integrointimäärittely ”tämän mukaan toteutetut toimivat yhdessä”

• täydentää valituilla liittymätekniikoilla tekniikkariippumatonta määrittelyä– sama liittymätekniikka käytössä osallistuvissa sovelluksissa (avoimia

tekniikoita esim. XML, IDL, WSDL, SOAP) – sovellukset voidaan silti toteuttaa eri tekniikoilla (Java, MS .NET, M, xx)

• osien tekniset vastuut• EI sisäisen tai tuotekohtaisen toteutuksen asioita vaan ulospäin

näkyvät tekniset liittymät• Kenelle?

– 1. integroinnin (esim. sovelluksiin sovittimien) toteuttajalle, tekniselle asiantuntijalle

– 2. hyväksyminen, tarkka tekninen standardointi

1 . K o hde alue e nanalys o int i

2 .So ve llus arkki te htuur intunnis tam ine n

3 . O lem as s ao le vie nso ve l lus te n te kni iko ide n

tunnis tam ine n

4 . To im innal l is te nl i i t tym ie n tunnis tam ine n



valinta


- inte gro int ivaat im uks e t-o lem as s ao le vie n so ve l lus te n to im innal l is uus


- to im innal l is e t inte gro int ipis te e t

- s em antt is e t vaat im uks e t

s tandardi t

- te knis e ts tandardi t

-uude t m e to di t , työ kalutand te kno lo giat

- inte gro int ipis te e tko hde arkki te htuur is s a


- te kno lo giar i ippum attom atl i i t tym ät

-uus i s o ve l lus inf ras truktuur i- inte gro int i te kno lo giat


1. INTEG RAATIO -VAATIM UKSET

2. TEKNIIKKA-RIIPPUM ATO N

LIITTYMÄMÄÄRITTELY


M ÄÄRITTELY

Tekniset määrittelyt: tuottaminen

1. Toiminnallisista määrittelyistä tai valmiista toteutuksista teknisiksi määrittelyiksi tuotettavien asioiden valinta.

2. Valittaviin tekniikoihin kohdistuvien vaatimusten tarkentaminen3. Sovelluksissa käytettyjen mahdollisten integroinnissa käytettävien tekniikoiden kartoitus.4. Käyttökelpoisten uusien tekniikoiden ja teknisten standardien kartoitus5. Aikaisemmissa projekteissa tehtyjen ratkaisujen hyödyntämistavasta päättäminen.6. Soveltuvien integrointitekniikoiden valinta ja perustelut 7. Yhteentoimivuuden perusarkkitehtuurin tarkentaminen valittujen tekniikoiden

mukaisesti8. Teknisten osien nimeäminen, esim. ”pyyntöpalvelun toteuttava DLL-kirjasto”,

”koodistopalvelun toteutus”9. Osien teknisten vastuiden määrittely 10. Kutsuttavien operaatioiden ja tietosisällön määrittely valituilla tekniikoilla11. Minimitason määrittely (tarvittaessa)12. Osien vuorovaikutuksen kuvaaminen (tarvittaessa)13. Toteutuskohtaiseksi jätettävien seikkojen määrittely ja dokumentointi, vaatimukset

toteutuksille ja niiden dokumentaatiolle14. Kokeilut (proof-of-concept) ja tarkentaminen, viittaukset toteutettuihin esimerkkeihin tai

referenssitoteutukseen

Tekniset määrittelyt - sisältö1 Johdanto – dokumentin tarkoitus jne.2 Rajaus – mihin vaatimuksiin ja toiminnallisiin määrittelyihin liittyy3 Tekniikoihin kohdistuvat vaatimukset4 Käytössä olevien järjestelmien hyödynnettävissä olevat tekniikat, perusteluiksi valituille tekniikoille4.1 Järjestelmän A tekniikat ja välineet4.2 Järjestelmän B tekniikat ja välineet4.3 Muiden järjestelmien vaikutukset, yleistys5 Hyödynnettävissä olevat tekniset standardit ja määritykset (tarvittaessa)6 Valitut tekniikat, luettelo ja perustelut valinnoille7 Integroinnin arkkitehtuuri valitulla tekniikalla: tekniset sovellusosat ja niiden vastuut, liittymät,

tietoliikenne 8 Operaatioiden ja tietosisällön tekniset määrittelyt8.1 Kaavio osien vuorovaikutuksesta, kutsusuhteista ja järjestyksistä jne.8.2 Operaatiokuvaukset valitulla tekniikalla (operation signatures)8.3 Tietokuvaukset valitulla tekniikalla (operaatioiden parametreista tai muuten siirrettävästä tiedosta,

voi olla myös yhdistettynä operaatiokuvauksiin)8.4 Virhetilanteet ja virhekoodit, toiminta virhetilanteissa8.5 Minimitaso ja lisätasot9 Toteutuskohtaiseksi jätettävät asiat: konfigurointi, siirrettävyys, mahd. liikenteen salaus jne. 10 Vaatimukset järjestelmille: palvelun tarjoava järjestelmä, palvelua käyttävä järjestelmä, alustavaatimukset,

käytettävät välinevaatimukset11 Määrittelyjen mukaisuuden toteaminen, esim. lista tarkastettavia piirteitä12 Esimerkkejä (tarvittaessa esim. palvelimen ja asiakkaan toteutuksesta), osoitteet referenssitoteutuksiin jne.

Integrointitekniikoiden valinta

• Mikä on valittu integrointimalli ja –tapa?• Miten hyödynnetään jo käytössä olevia tekniikoita ja infraa?• Mitä uusia tekniikoita halutaan / on otettavissa käyttöön?• Onko ulkoisissa määrityksissä joita halutaan käyttää teknisiä

asioita?• Halutaanko erottaa tietosisältö ja toiminnallisuus?

– voi valita myös useita integrointitekniikoita – tiedon merkkaus, operaatioiden määrittely, tietoliikenne…

– tai määritellään rajapinta, jonka kautta käsitellään erikseen viitattuja sisältöjä (PlugIT-potilasrajapinta, PlugIT-koodistorajapinta)

• Synkroninen / asynkroninen?• Ratkaisun avoimuusvaatimukset?• Tekniikoiden levinneisyydet ja kehitysnäkymät?

Käytössä olevat integroinititavat ja teknologiat

2,89

2,6

2

3,75

1,86

2,86

3,86

33,14

2,292,14

3,14

2,52,442,22

1,25

1,8

1,25

2,5

2,8

1,89 1,9

3,2

2,72,71 2,712,86

2,29

0

1

2

3

4

5

1 2 3 4 5 6 7 8 9 10 11 12 13 14

nykytila

tavoitetaso

1. Komponenttipohjainen integrointi (useamman sovelluksenkäyttämä komponentti, esim. potilaan tunnistus), nykytila 2,22 Tavoitetaso 3,75

2. Väyläpohjainen integrointi (esim. CORBA broker), nykytila 1,25 Tavoitetaso 1,86

3. Viestipohjainen integrointi (esim. HL7 –sanomarajapinta), nykytila 2,50Tavoitetaso 2,86

4. XML-pohjainen integrointi, nykytila 2,44 Tavoitetaso 3,865. Tiedon välitys yhteisen tietoalueen tai tietokannan kautta,

nykytila 2,89 Tavoitetaso 2,716. Web service –tekniikka, nykytila 1,25 Tavoitetaso 3,007. Tietoverkon yli tapahtuva integrointi ja palvelujen käyttö,

nykytila 1,80 Tavoitetaso 3,14

8. Samaan koneeseen asennettujen sovellusten välinen integrointi, nykytila 2,80 Tavoitetaso 2,71

9. Toisen sovelluksen käyttöliittymän kutsuminen, nykytila 1,89 Tavoitetaso 2,29

10. Käyttöliittymän tarjoaminen toiselle sovellukselle, nykytila 1,90 Tavoitetaso 2,14

11. Määräajoin eräsiirtona tapahtuvat tiedonsiirrot, nykytila 3,20 Tavoitetaso 2,86

12. Ulkoiseen standardimäärittelyyn (esim. HL7) perustuva integroinnin toteutus, nykytila 2,70Tavoitetaso 3,14

13. Kahden väliseen sopimiseen perustuva integroinnin toteutus, nykytila 2,60

Tavoitetaso 2,2914. Taustarekisterien ja koodistojen käyttö API kautta,

nykytila 2,00 Tavoitetaso 2,50

system

user level

resource level

enterpriselevel

workspacelevel

• paikallinen ohjelmointirajapinta (DLL, JavaBeans…)• kevyt, yleensä yksinkertainen tapa

• sovellusten koordinointi, työpöytäintegraatio (CCOW...) • tavoitteena helpottaa erillisten järjestelmien yhtäaikaista käyttöä

• hajautettu ohjelmointirajapinta (SOAP, EJB…) • ei vielä paljoa käytössä terveydenhuollossa

• verkon yli kutsuttava palvelu (web services, ASP, JSP...)• tekniikka vasta tulossa terveydenhuoltoon

• yhteisen infrastruktuurin käyttö (CORBA, MTS…)• vaaditaan useimmiten samaa tekniikkaa (= usein raskasta ja kallista)

• sanomapohjainen integraatio (HL7, XML...) • yksittäisten tietojen siirtämistä

• tietokantatason integraatio (SQL…) • vaaditaan useimmiten samaa tekniikkaa

Liittymien määrittely eri tekniikoilla

• Yhdessä ratkaisussa käytetään usein monia tekniikoita

• Dokumentoidaan eri tekniikoilla eri tavoin, esim. (palvelupohjainen integraatio)– palvelun löytäminen

– operaatioiden määrittely

– tietosisällön (parametrien, paluuarvojen) määrittely

– tietoliikenne tai tiedon välitys

– salaus tai muut turvallisuustekniikat

– alustavaatimukset

– tarvittavat välineet

Method IsCodeValid

Interface Codeset

Käyttötarkoitus Koodiarvon olemassaolon tarkistaminen tietyssä koodistossa, sovelluksen kentässä olevan koodin oikeellisuuden varmistaminen

Param termSystem-elementti, jonkaid-attribuutissa koodiston tunnisteversion-attribuutissa tarvittaessa koodiston version tarkenneterm-elementti, jonka id-attribuutissa validoitava koodiarvo

Response value-elementti, jonka arvona 0 (ei validi koodiarvo) tai 1 (validi koodiarvo)

Kuvaus Käytetään, jos halutaan varmistua siitä, löytyykö koodiarvo koodistosta tai sen versiosta

Pakollisuus Pakollinen perustasolla ”base”.

Lisätietoja Ks. myös Code-rajapinnat (koodin voimassaolo ja paikallisuus)

Poikkeukset GeneralFailure, NotImplemented, MissingParameter, UnknownCodeSystem

Vaatimukset K2.9

Kutsu esim. <?xml version=”1.0” encoding=”UTF-8”?><request xmlns=”urn:plugit:CommonServices”> <interface>Codeset</interface> <method>IsCodeValid</method> <param> <termSystem id=”1.2.246.537.6.1.1996”/> <term id=”B15.1”/> </param></request>

Määritysten hyödyntäminen,toteutukset + toteutuksen kuvaus

Rajapinnan toteutustilanteet

• Tuoteominaisuuksien suunnittelu, ”yleinen”– pyrkimys yleiskäyttöisyyteen, toistettavuuteen– standardit, ”pilkuntarkkuus”, sertifiointi– ”meillä on tämän standardin mukaan tehty rajapinta, jos

noudatatte samaa standardia integrointi on nopeaa”– konfiguroitavuus eri ympäristöihin, eri käyttötapoihin

• Tilauksesta tehtävä, ”kahdenvälinen”– aikataulupaineet, uudet tarpeet– tunnetaan paikalliset erityisvaatimukset– johtaa oikein tehtynä ”yleinen”-tilaan, tuoteominaisuudeksi

• tunnistetaan, mitkä ratkaisut ja vaatimukset ovat ”paikallisia”

Avoimen määrityksen hyödyntäminen 1

• Sovelluksen vaatimukset ja määrityksessä kuvattu ratkaisu– integrointitilanne tai integrointitarve sovelluksen (asiakkaan) kannalta, mihin

vaatimuksiin integrointimääritys vastaa, mikä määritysversio onko määrityksessä tasoja, vaaditaanko lisäpiirteitä

• Sisällöllinen & tekniikkariippumaton tarkastelu– missä roolissa sovellus on, onko toiminnot ja tiedot joita määrityksessä

käsitellään, sovelluksen työnkulut, mikä sovelluksen osa liitetään, onko varauduttava siihen että ratkaisua ei käytetä jossain tilanteessa

• Liittymätekniikan sovitus sovellukseen– onko jo käytetty liittymätekniikoita, niitä tukevat välineet ympäristöön, valmiit

kirjastot ja sovittimet tai itse toteuttaminen• Toteutus ja testaus

– määrityksessä toteutuskohtaiseksi jätetyt asiat, yleiset vaatimukset– valmiin kirjaston tai adapterin liittäminen sovellukseen, liittymätekniikoita tukevilla

välineillä toteutus sovellukseen tai ”matalan tason koodauksella” alusta loppuun– dokumentointi, toteutuksen kuvaus, testaus ennen käyttöönottoa, testipalvelut,

sertifiointi– kokemusten ja lisätarpeiden kerääminen myöhempiä integrointitarpeita varten– palaute määritysten tekijöille

Avoimen määrityksen hyödyntäminen 2

• Paikallinen sovitus– kallista, jos toistuvaa ja työlästä– pyrkimys kohti toisiaan täydentäviä standardeja, ”integration profiles”– aina jotain paikallisesti sovitettavaa, voidaan varautua

konfigurointimekanismeilla tuotteessa– ”vastapuolelta varmistukset”

• toteutuksen kuvaus – toteutuskohtaisuuksien vastaavuus• onko vastapuolella sertifikaatit tai testausraportit standardin mukaisuudesta

– tuoteominaisuuksien lisäksi?• paikallisten vaatimusten huomiointi, ”standardin venytys”, erotetaan

avoimesta ratkaisusta• poikkeamat määrittelystä, joudutaan sopimaan kaikkien osapuolten kanssa

• Käyttöönotto, ylläpito– testaus lopullisessa käyttöympäristössä – käyttöönotto, ohjeistus, vastuutus, koulutus– uusien versioiden, toimivuus edellisen version ratkaisujen kanssa

(regressiotestaus)– rajapintojen versiot, päivitysten ajoitukset, useiden versioiden tukeminen?

Mitä ovat Toteutuksen kuvaukset + tavoite

• Toteutuksen kuvaus –dokumenttiin– tuotekohtainen dokumentti, osa sen dokumentaatiota

• esitystapa ”vapaa mutta pakollinen”• ”kuinka tämä sovellus/komponentti asennetaan ja integroidaan, kun siinä

on määrittelyn X mukainen tekninen liittymä”• alustavaatimukset, saatavilla olevien muiden ohjelmistojen tai rajapintojen

tuki• kuinka se mukautetaan suoritusympäristöön• kuinka toteutus vastaa esitettyihin vaatimuksiin• onko toteutuskohtaisia lisäpiirteitä tai poikkeamia avoimiin määrittelyihin

• Ei (nimestä huolimatta) ole ohje, kuinka toteutus tehdään– sitä varten erillisiä soveltamisoppaita, esimerkkejä

• Kenelle?– 1. sovelluksen käyttöönottajalle ja asentajalle (ohje) – 2. asiakkaalle (tällainen ”standardi-integraatio” kuuluu

tuotteeseen), näin on ratkaistu tässä toteutuksessa toteutuskohtaiset asiat, lisäpiirteet ym.

Toteutuksen kuvaus – sisältö esim.

1 Johdanto2 Rajaus –mitkä vaatimukset, toiminnalliset määrittelyt, mitkä tekniset

liittymämäärittelyt-toteutus3 Suhteet määriteltyihin vaatimuksiin ja yleisiin liittymiin3.1 Miten toteutus vastaa integrointivaatimukset-dokumentin vaatimuksiin”määrittelyjen mukaisuuden toteaminen” kohtiin vastaaminen3.2 Miten toteutus vastaa toteutuskohtaisiksi jätettyihin vaatimuksiin (suorituskyky-

laatuvaatimusten, toteutuskohtaiset seikat)3.3 Minimitaso ja lisätasot3.4 Toteutuskohtaiset lisäykset ja laajennukset teknisiin määrittelyihin3.5 Toteutuskohtaiset poikkeamat ja rajoitteet teknisistä määrittelyistä 4 Toteutuksen asettamat vaatimukset tekniselle ympäristölle • käyttöjärjestelmäriippuvuudet, vaaditut päivityspaketit ja kirjastojen versiot,

tarvittavat palvelimet, versiot, lisenssit, siirrettävyys, jakelumekanismit5 Toteutuksen käyttöönotto5.1 Toteutuksen asennus (tarvittaessa, jos ei sovelluksen asennuksen yhteydessä)5.2 Integroinnin toteutuksen asetusten tekeminen ja konfigurointi• esim. palvelun kutsuosoite, dll-tiedoston nimen välitys, ulkoiset parametrit5.3 Ylläpito, uudet versiot6 Esimerkkejä toteutetun ratkaisun käytöstä (suositellaan), 7 Toteuttajan tukipalvelut, yhteystiedot.

Välinevalinnat

• Tuettava valittuja integrointitekniikoita ja haluttua suoritus- ja kehitysympäristöä (+ oppimiskynnys + halutut ominaisuudet + elinkaari…)

• mallinnus, toiminnanohjaus, komponenttitoteutus, sovittimet, liittymästandardit, integrointialustat, ohjelmointikielet, middleware (etäohjelmakutsu, viestijono, TP monitor, oliosanomavälitin, tietokanta), XML

• (Ainakin osin) eri välineet eri integrointitapoihin ja -malleihin• Erityispiirteitä integrointivälineissä

– Useita eri lähteitä hyödyntävälle tai eri protokollia käyttävä viestinvälitykselle (http, viestijonotuotteet ja -standardit, sähköposti, ftp, tiedostot, tietokantaliittymät, olio- ja palveluprotokollat kuten SOAP, IIOP ja COM)

– Mahdollisuus välittää tietoa kahdenvälisesti tai monenvälisesti– Tiedon muodon muunnokset, esim. ohjelmointikielen tietotyypeistä määritellyn XML-

rakenteen elementeiksi tai IDL-liittymän attribuuteiksi ja tietotyypeiksi (ja päinvastoin), dokumenttien muunto rakennemäärittelystä toiseen

– Tiedon ja metatiedon vastaavuuksien määrittely osallistuvissa järjestelmissä ja määrittelyn pohjalta tapahtuvat konversiot, erityisesti ulkoisesta (standardi‑) määrittelystä automaattisesti generoitavat sovellusosat

– Tuki tai sovittimet useille suoritusalustoille ja ohjelmointikielille tai sovelluskehittimille– Tuki useille sisällöllisille standardeille, kuten HL7, SWIFT, EDI jne.– Mahdollisuus lisätä ulkopuolisten osapuolten tekemiä sovittimia– Tuotteeseen integroidut toimintaprosessien hallinta- ja työnkulun ohjausominaisuudet

[Ohjelmistotuotannon välineselvitys – näkökulmia terveydenhuollon ohjelmistoyrityksen välinesalkun kokoamiseen]

Yhteenveto, keskustelu

Erityyppiset ratkaisut

Avoin koodistorajapinta Patologian pyyntö-komponentti

Vaatimukset Yleiset käyttö- ja ylläpitotarpeet

Paikalliset tarpeet (patologia-gastro)

Tekniikkariippumaton Mallit standardeista korostuneet

Vaatimustenhankinta osapuolilta

Tekninen Hajautetut ydinpalvelut (http + XML)

Paikallinen kirjasto (DLL, XML), komponentti

Toteutukset Referenssitoteutus, alueellinen / organisaation toteutus

Tuotetoteutus

Integrointimalli Palvelupohjainen Tieto- ja palvelupohjainen (+käyttöliittymä)

Päähyödyt Uudelleenkäyttö, vähent. päällekkäisyys, keskitetyt palvelut + tiedot

Nopea toteutus, sovellusmuutosten pieni määrä, prosessihyödyt

Muuta erityistä Standardien suora käyttö ei mahdollista, vaatii sovelluksilta mukautumista

Ei standardia, tarkka ratkaisu erikoistilanteeseen

Kokemuksia monenvälisestä integroinnista

• 9 tiimiä, 14 integrointikohdetta, eri tyyppisiä tarpeita• Integroinnin määrittely ja toteutus

– Integrointialueen tuntemus välttämätöntä ratkaisun määrittelyssä– Kiireellisimmät integrointitarpeet mukaan ensimmäiseen iteraatioon (määrittelystä toteutukseen),

uudet versiot– Määrittely ja toteutus järkevää erottaa omiksi “projekteikseen”, varsinkin avoimissa määrittelyissä

(toteutushyödyt, kilpailuetujen suojelu)– Uusien ratkaisujen ja tekniikoiden vähittäinen sisäänajo, migraatio sovelluksille ja asiakkaille,

referenssitoteutukset• Standardit ja tuotekohtaiset seikat

– Standardeilla, tekniikoilla ja välineillä vaikutuksia monille eri tasoille, mutta eri osapuolilla ei resursseja arvioida kaikkia vaikutuksia

– Top-down: Toimialakohtaisten standardien tulisi perustua yleisiin avoimiin standardeihin– Bottom-up: Ratkaisujen sitominen/kerääminen olemassa olevista sovelluksista, yleistäminen

avoimeksi (suunnittelukäytännöt, harmonisointi, standardointiprosessi)– Ratkaisujen arviointi ja sertifiointi tarpeen, ulkoinen taho– Joustavuus (heterogeenisyys) avoimilla tekniikoilla ja tiedon erottamisella toiminnallisuudesta

• Monenväliset integrointiprojektit– Osallistujilla “eri aloilta” erilaiset taidot, erilainen kieli– Johdon sitoutuminen – vaatimukset, resurssit, aikataulu– Neutraali moderaattori määrittelyssä, “konsultti” toteutuksessa– Toteutus/tilaajakohtaiset seikat (jakelu, ylläpito, omistajuus) erilleen avoimista määrityksistä

[Mykkänen, Porrasmaa, Korpela, Häkkinen, Toivanen, Tuomainen, Häyrinen, Rannanheimo. Integration Models in Health Information Systems: Experiences from the PlugIT project. Medinfo 2004].

• Integroinnin määrittely– sovelletaan eri tavoin erilaisissa integrointitilanteissa– taustaselvitys- ja analyysitarve vaihtelee ”älä jumiudu

taustoihin” (analysis paralysis)– määritykset ja standardit validoidaan toteutuksilla palaute

määrityksiin, versiointi– määrittelypohja käytettävissä myös integrointiratkaisujen

arviointiin• Määritysten hyödyntäminen

– integraation toteutuksissa tuotteisiin, sovittimien rakentamisessa

– tarjouspyynnöissä

• Seuraavaksi– testaus, määrittelyjen mukaisuus– soveltamiskokemuksia ohjelmistotuotannon menetelmistä

Yleistäminen (avoimessa määrittelyssä)

• järjestelmistä yleisnimet, ”actors”• nykyjärjestelmien ja nykytilan kuvaus erillään avoimista

määrittelyistä• tiedot ja toiminnot tarvittaessa määriteltynä erikseen• avoimien määrittelydokumenttien tasot (ks. ”Tuotosten jaon

tarkoitus”)• varsinkin ”tekniset määrittelyt” tasolla avoimien tai paljon käytettyjen

tekniikoiden valinta • määrittelyjen kommentointi monelta osapuolelta, hyväksyminen,

standardointi

Documents

PlugIT-menetelmätulokset: Integrointiratkaisujen määrittely ja määritysten hyödyntäminen