UNA-modulaarinen järjestelmäarkkitehtuuri

Transkriptio

1 UNA UNA-modulaarinen järjestelmäarkkitehtuuri Arkkitehtuurikuvaus UNA- arkkitehtuurikuvaus

2 Sisällysluettelo 1 Johdanto Modulaarinen arkkitehtuuri Kehittämisen strategia... 5 Kehittämisen vaiheistus... 7 Arkkitehtuuriperiaatteet... 8 Toiminta-arkkitehtuuri Tietoarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologia-arkkitehtuuri Tietoturva-arkkitehtuuri Modulaarisen järjestelmäarkkitehtuurin kuvaukset ja vaatimukset Tietojärjestelmäpalvelujen kuvaus Asiakkuudenhallinnan toiminnallisuus ytimessä Tiedonhallintaratkaisu ja masterdatan hallinta ytimessä Moduulit vyöhykkeillä Integraatioarkkitehtuuri Toimintaprosessit Toiminnalliset kuvaukset pohjana modulaarisuudelle Sosiaalihuollon geneeriset prosessit Terveydenhuollon geneerisiä prosesseja Sosiaali- ja terveyshuollon palvelujen liittymäkohtia Kerrosarkkitehtuuri ja modulaarisuus Tiedonhallinta modulaarisessa arkkitehtuurissa Dynaaminen tietomalli Tietovarannot Tietovirrat Arkkitehtuurivaatimukset Esimerkki UNA-modulaarisuuden toteuttamisesta Johdanto Esimerkki toteuttamisen vaiheistuksesta Esimerkki toteuttamisen vaiheistuksesta, asiakkuudenhallinnan ydin Esimerkki toteuttamisen vaiheistuksesta, toiminnan- ja tuotannonohjaus ydin... 37

3 LIITE: Taulukko arkkitehtuuriperiaatteista ja linjauksista Johdanto Tämä arkkitehtuuridokumentti määrittelee ja kuvaa eri näkökulmista Modulaarisen järjestelmäarkkitehtuurin UNA-kohdearkkitehtuurissa. Lisäksi se pyrkii avaamaan arkkitehtuurin muodostumista sekä hyödyntämismahdollisuuksia ja -kohteita. Vaatimusmäärittelyaineisto pitää sisällään myös erillisen Termistödokumentin, jossa arkkitehtuurikuvaukseen liittyviä käsitteitä on määritelty. UNA-hankesuunnitelmassa koko hankkeen tavoitteiksi asetettiin tuottaa organisaatio-, hallinto- ja toimittajariippumaton vaatimusmäärittely asiakaslähtöisestä ja vaikuttavien hyvinvointipalveluiden tuottamisessa edellytettävästä yhteentoimivasta sote-tietojärjestelmäkokonaisuudesta. Lisäksi hankkeessa syntyvän vaatimusmäärittelyaineiston avulla tulee voida kansalliseen tai alueelliseen yhteistyöhön pohjautuen vaiheittain kilpailuttaa tietojärjestelmäratkaisuja tai ohjata nykyisten kehittämistyötä. Hankesuunnitelmassa oli esitetty myös tiettyjä tavoitteita liittyen järjestelmän rakenteeseen, mukautettavuuteen, kerrosarkkitehtuuriin sekä päällekkäisten järjestelmätoiminnallisuuksien välttämiseen. Näihin haasteisiin on esitetty ratkaisut tämän dokumentin kappaleessa 2.1, kehittämisen strategia. Hankkeen alussa mukana olevat organisaatiot sopivat yhteisen vision, johon vaatimusmäärittely perustuu. Modulaarisen järjestelmäarkkitehtuurin osaprojektissa vision tarkennus rakentui tämän dokumentin kappaleessa 2, Modulaarinen arkkitehtuuri, esitetyn nelikentän ympärille. Käytännössä arkkitehtuurityö määritellyssä viitekehyksessä rakentui työpajatyöskentelyn, haastattelujen ja muun asiantuntijatyön ympärille. Olemassa olevien ratkaisujen osalta kerättiin ja analysoitiin järjestelmäkokonaisuuden vaiheittaiseen uudistamiseen liittyvää tietoa mm. nykyisistä tietojärjestelmäpalveluista, integraatioista ja rajapinnoista. Tällä pyrittiin mm. arvioimaan migraatiokyvykkyyttä sekä luomaan edellytykset mahdollistavalle ja yhteen toimivalle järjestelmäarkkitehtuurille. Markkinoiden kyvykkyyteen liittyen tehtävänä oli kartoittaa markkina- ja tietojärjestelmätoimittajien näkemykset sekä valmiudet toteuttaa haluttuja modulaarisia ratkaisuja kokonaisarkkitehtuurin eri osa-alueet huomioiden. Tätä varten valmisteltiin modulaarisuutta painottava tietopyyntö, joka julkaistiin HILMAssa joulukuun alussa. Toimittajavastausten- ja haastattelujen kautta osaprojektissa tuotettiin markkinoiden kyvykkyyden analyysi, jota on hyödynnetty modulaarisen järjestelmäarkkitehtuurin eri skenaario- ja ratkaisuvaihtoehtojen arvioinnissa. Tieto ja sen tuoma lisäarvo on hyödynnettävissä mm. kehittämisessä ja jatkohankkeissa. Toiminnallisten määrittelyjen, -kuvaamisen ja kehittämisen näkökulmasta lähtökohdaksi oli asetettu se, että modulaarisuuden tulee perustua toiminnallisiin määrittelyihin, jossa huomioidaan yhteisten tietojen käsittely ja päällekkäisten järjestelmätoiminnallisuuksien välttäminen. Lisäksi modulaarisuuden tulee tukea sotepalveluiden tarpeita niin, että erityisesti sosiaali- ja terveyspalveluiden tietojärjestelmien toiminnallinen yhtenäisyys lisääntyy. Modulaarisen järjestelmäarkkitehtuurin osaprojektissa tämä tarkoitti tehtävänä menetelmien kehittämistä, jotta toiminnallisia kokonaisuuksia voitiin tunnistaa, prosessien harmonisoimiseen liittyvä generalisointityö käynnistää ja kuvata ainakin osin toiminnallisten moduulien sijoittuminen arkkitehtuuriin. Hankkeessa tehdyn työn tuotoksina syntyivät aineisto ja menetelmät toimintalähtöisen modulaarisen järjestelmäarkkitehtuurin rakentumiselle, joka tukee vaiheittaista toiminnan

4 kehittämistä. Toiminnan kehittämisen vaiheistamista tuetaan tässä dokumentissa kuvatulla UNAarkktitehtuurilla. Vaiheittain kehittämisen mahdollistamiseksi nykyjärjestelmien tuottama tieto tulee yhteensovittaa modulaarisen arkkitehtuurin mukaisen ytimen tietdonhallinnan kanssa. Seuraavat vaiheet määräytyvät toiminnallisen kehittämisen mukaisilla moduuleilla, jotka osaltaan korvaavat vaiheittain nykyjärjestelmissä olevat toiminnallisuudet. Vaiheittain etenemistä on kuvattu esimerkein kappaleessa 4. Yleiset kehittämislinjaukset heijastuivat alun perin voimakkaasti kansalliseen arkkitehtuurityöhön, jossa tavoitteena oli VAKAVA-viitearkkitehtuurityön pohjalta modulaarisen tietojärjestelmäarkkitehtuurin perusperiaatteiden määrittely ja VAKAVA-arkkitehtuurin osittainen päivitys. Osaprojektissa rakennettiin UNA-kohdearkkitehtuuria JHKA- ja VAKAVA-arkkitehtuurit huomioiden. Samalla käynnistettiin kansallinen yhteistyö mm. KAJAKKI-projektin ja Apotti-hankkeen kanssa. Lopputuloksena voidaan todeta, että VAKAVAviitearkkitehtuuria on saatu tarkennettua ja kansallisen tason yhteistyön pioneerityö on tehty. On myös tunnistettu, että vastaavaa vuorovaikutusta ja yhteistyötä tullaan tarvitsemaan enenevässä määrin myös jatkossa, jotta kehittäminen mm. eri järjestelmien ja tarvittavien integraatioiden osalta on järkevää ja samansuuntaista. Suurin vastuu ohessa kuvatusta työstä oli vastuuasiantuntija Ari-Pekka Paanasella, jolla oli tukenaan nimetyt asiantuntijat (Juha Rannanheimo, Aino Virtanen) sekä organisaatioiden osaprojektiin nimetyt henkilöt. Lopputulos on nähtävissä ja toivottavasti mahdollisimman kattavasti hyödynnettävissä tämän arkkitehtuurikuvauksen ja sitä tukevan aineiston kautta. 2 Modulaarinen arkkitehtuuri Tulevaisuuden hyvinvointipalvelujen järjestelmäkokonaisuuden toteuttaminen pohjautuu toiminnallisiin tarpeisiin, kehittämislinjausta ohjaavat STM:n sote-tieto hyötykäyttöön strategia sekä VAKAVA-projektissa tehty alueellista kehittämistä ohjaava viitearkkitehtuuri. Sote-tietohyötykäyttöön strategiatyössä modulaarisuus on nähty tulevaisuuden kehittämistyön mahdollistajana: Sote-tietojärjestelmäkokonaisuudet suunnitellaan ja toteutetaan modulaarisesti siten, että tietojärjestelmäpalveluita voidaan kehittää, hankkia ja mukauttaa muuttuvan toiminnan tarpeisiin hyödyntäen markkinoilla olevaa osaamista. Yhteentoimivista osajärjestelmistä koostuva kokonaisuus takaa sen, että kehittämispolku on avoin ja kilpailutus on tehokasta ja pohjautuu käyttäjätarpeisiin. Modulaarisen järjestelmäarkkitehtuurin määrittelyssä on huomioitu seuraavat näkökulmat:

5 UNA-hankkeen modulaarisen arkkitehtuurin määrittelyissä on ollut keskeistä: Modulaarinen järjestelmäarkkitehtuuri pohjautuu yleisiin kansallisesti sovittuihin kehittämislinjauksiin Modulaarisuus perustuu toiminnallisiin määrittelyihin, joissa on huomioitu yhteisten tietojen käsittely ja päällekkäisten toimintojen järjestelmätoiminnallisuuksien välttäminen Järjestelmäkokonaisuuden uudistamisessa on huomioitu integrointi- ja migraationäkökulma olemassa oleviin ratkaisuista seuraavan sukupolven järjestelmiin Modulaarisen arkkitehtuurin mukainen tietojärjestelmäkokonaisuus muodostuu moduuleista (itsenäisistä tietojärjestelmäkomponenteista), joita voidaan käyttöönottaa tai korvata yksittäisinä kokonaisuuksina. Moduulit toteuttavat ja tarjoavat muiden käyttöön tietojärjestelmäpalveluja. Tietojärjestelmäpalvelulla tarkoitetaan ulospäin näkyvää toiminnallisuutta, joka voi sisältää oman käyttöliittymän tai olla muille moduuleille näkyvä palvelu, josta kokonaisuus muodostuu. Modulaarisuus rakentuu itsenäisistä tietojärjestelmäkomponenteista, joista kukin noudattaa mm. seuraavia periaatteita: - Tuottaa tietojärjestelmäpalvelua, joka on toiminnallisesti tehokas ja rajattu osa kokonaisratkaisua, ns. ekosysteeminen tuki. - Voidaan yhdistää muihin tietojärjestelmäkomponentteihin - Pystyy hyödyntämään muiden tietojärjestelmäkomponenttien tietosisältöjä - On tietojärjestelmäpalvelun näkökulmasta itsenäinen - On teknologialtaan ajantasainen - Omaa avoimet, mieluiten standardeihin perustuvat rajapinnat - Tietojärjestelmäkomponenteilla on käyttökohteensa ja toiminnallisuuksien vaatimusten lisäksi yhteismitallistettavia ominaisuuksia, joiden avulla komponentit pystyvät muodostamaan kokonaisuuksia (esim. MDD-vaatimusten mukaisuus) Modulaarisilla järjestelmäkokonaisuuksilla pystytään välttämään asiakaskohtaista teknistä räätälöintiä. Tämä riippuu teknisen toteutuksen kyvykkyydestä toteuttaa modulaarisuutta ja siitä, miten niiden valintaa ja toteutusta ohjataan. Kokonaisuutta arvioitaessa moduulien valinta ja niiden kyvykkyys ovat keskeisessä

6 roolissa. Kokonaisuutta rakennettaessa on moduuleilla oltava kehittyneet testausmenetelmät, joiden kautta taataan yhteentoimivuus, luotettavuus ja pienennetään muutoksiin liittyviä riskejä. Modulaarisuuden toteuttamiseen on eri näkökulmia (järjestelmänratkaisujen käsitteellinen rakenne): - 1 moduuli = monoliittinen tietojärjestelmäpalvelu - 2 päämoduulia = bipolaarinen tietojärjestelmäpalvelu - 3 tai enemmän = keskusjärjestelmät + tuki moduulit - Vaihdettavat moduulit = Ydin ja tukijärjestelmät - Avoimet yhteensop. moduulit = Ydin ja satelliittijärjestelmät UNA-modulaarisen arkkitehtuurin lähtökohtana ovat perustaltaan vaihdettavat, avoimet ja yhteentoimivat moduulit sekä modulaarinen ydin, joka tukee järjestelmäkokonaisuuden toteuttamista. Modulaarisuuden rakentamisessa kehittämisen kohteeksi muodostuvat toiminnalliset kokonaisuudet, niiden laajuutta (ns. raekoko ) ohjaa strategiset ja toiminnalliset tarpeet. Tämä tapa toteuttaa ratkaisuja tuo mukanaan seuraavia toimintatapoja kehittämiseen ja määrittelyyn: - ketteryyden säilyttämisen kehittämishankkeissa - ketterät ja joustavat toiminnan kehittämisen menetelmät (esim. LEAN-menetelmä) - tietojärjestelmäpalvelujen, moduulien kehittämismalli - esim. SCRUM/ ketterän kehittämisen malli (vrt. entinen vesiputousmalli laajoine vaatimusmäärittelyineen) - vaatimuksia ei ole tarpeen sitoa etukäteen kovin tarkkaan, reaalinen modulaarisuus syntyy osin toteutettaessa - jokainen moduuli voidaan päivittää ja sitä voidaan kehittää itsenäisenä siten, että se ei häiritse muiden moduulien toimintaa - mahdollistaa uuden tekniikan hyödyntämisen perinteistä järjestelmäympäristöä nopeammin - sovellusarkkitehtuurin sisäinen rakenne tulee tukemaan modulaarisuutta ja moduulien käyttöä itse moduulin ulkopuolelta - tuo käyttäjälle mahdollisuuden vaikuttaa mukautuvuuden kautta moduulien toimintaan - tiedon hakumoottorit ja dynaaminen tiedon rakennemalli - mahdollistaa pienempien kokonaisuuksien hankkimisen vaiheittain toiminnallisuutta voidaan lisätä olemassa olevan päälle - lisää markkinoilla olevien potentiaalisten toimijoiden joukkoa - saadaan nopeammin näkyvää, hankintojen massiivisuus vähenee 2.1 Kehittämisen strategia UNA-hankkeessa tavoitteeksi on asetettu modulaarisen hyvinvointitietojärjestelmäkokonaisuuden kehittämisen malli. Tulevaisuuden järjestelmäkokonaisuuden pitää tukea eri sote-palveluiden osa-alueiden (sosiaalihuolto, perusterveydenhuolto ja erikoissairaanhoito) välisen yhteistyön tiivistämistä. Järjestelmäkokonaisuutta on lähdettävä tekemään modulaarisesti ja vaiheittain kehittämällä. Se poikkeaa mallista, jossa olemassa oleva järjestelmä tai järjestelmät korvataan kerralla uudella järjestelmällä. Sen sijaan, että perinteisten järjestelmien tilalle hankitaan vastaava perinteinen järjestelmäratkaisu tai niitä yritetään parannella, on syytä käyttää hyväksi ict-infrastruktuurissa ja tekniikoissa tapahtuvaa kehitystä ja siirtyä asteittain vanhentuvan teknologian varaan rakennetuista ratkaisuista modulaarisen kehittämismallin mahdollistaviin tai vähintään huomioon ottaviin ratkaisuihin.

7 Järjestelmäkokonaisuus tulee olla vaiheittain uudistettavissa nk. hallitun monitoimittajamallin mukaisesti. Nykyisestä kehittämistavasta tulee siirtyä uuteen kehittämisen tapaan, jossa toteutuu nykyaikaiset tietojärjestelmäkehityksen periaatteet: modulaarisuus, joustavuus, ketterä käyttöliittymien kehittäminen ja avoimet älykkäät rajapinnat. Modulaarisella arkkitehtuurilla haetaan järjestelmäkokonaisuuden muutosjoustavuutta vastaamaan toimintaympäristön muutoksiin. Olemassa olevien huonosti mukautettavien käyttöliittymien ja hitaasti päivitettävissä olevien toimintojen sijaan saadaan kulloiseenkin käyttötilanteeseen sopivia ja erilaisia prosessien kulkuja tukevia muunneltavia ratkaisuja. Nykyjärjestelmät rajaavat toiminnallisuutta ja prosessien variaatioita. Varsinkin terveydenhuollossa, jossa prosessit käytännössä eivät toteudu kovin määrämuotoisesti, modulaarisuuteen pohjautuvista ratkaisuista voi tunnistaa olevan oleellinen hyöty. Tämä tulee vaikuttamaan sekä toiminnan kehittämisen malleihin, rakentamistapaan että hankintamalliin. Tärkeiksi nousevat arkkitehtuuriperiaatteiden määrittely, kehittämisnäkökulman muuttaminen ja nopeasyklisempi hankintamalli. Ketterillä menetelmillä järjestelmäkokonaisuutta voidaan kehittää pilkkomalla niin, että toiminnallisesti keskeisiä osia päästään kehittämään kohdennetusti. Tietomallin dynaamisuudella haetaan tiedonhallintaan joustavuutta, jota tarvitaan nykyistä nopeammin kasvavaan käytettävissä olevan tietojen välittämiseen ja hallintaan. Pääpaino tiedonhallinnassa siirretään tiedon tallentamisesta tiedon jakamiseen ja löytämiseen. Modulaarisuuden kehittämisen strategiaksi on muodostunut ns. ydin ja vyöhykkeet. Tämä strategia toteuttaa toimintopohjaista modulaarisuutta sekä alustalähtöistä modulaarisuutta: - toimintopohjainen modulaarisuus tarkoittaa, että toiminnallisten kokonaisuuksien tunnistaminen tehdään toiminnallisista vaatimusmäärittelyistä ja määritellyn kehittämiskohteen kokoiset toiminnallisuudet lähdetään toteuttamaan yhteen moduuliin - alustalähtöinen modulaarisuus tarkoittaa, että toteutetaan ydin, tietty vakio-osa, jonka päälle kootaan moduulit. Ydin sisältää järjestelmäarkkitehtuurin keskeisimmät ominaisuudet sekä tarjoaa kattavat rajapinnat uusien toimintojen ja ominaisuuksien lisäämiselle Tämä kehittämisstrategia on joustava ja sen kulmakivenä ovat arkkitehtuuriperiaatteet ja linjaukset. Se korostaa etenemistä nykyisestä järjestelmäkehittämisestä kohti modernimpaa kehittämistä, mutta vaatii tilaajilta sitoutumista ja panostusta arkkitehtuurin hallintaan. Modulaarista järjestelmärakennetta ei tule rakentaa tai suunnitella etukäteen. Moduulijako määrittyy kulloisenkin toiminnallisen kohteen mukaan, moduulirakenne on siten toiminnan lähtökohdista rakentuva. Pienimmillään jokainen tehtävä voi olla oma moduuli, mutta moduulien raekoko määrittyy vasta linjattaessa toteutusta. Modulaarisuus toteutuu asiakkaalle toteutettavista palveluista, jotka kukin toteuttavat haluttua tehtävää (esim. sähköinen allekirjoitus). Kokonaisuus muodostuu keskenään yhteensopivista ja kyvykkäistä moduuleista, joista kootaan tilannekohtaisesti käyttötilanteen edellyttämät toiminnot.

8 KUVA ytimestä ja vyöhykkeistä Modulaarinen arkkitehtuuri lähtee rakentumaan ytimen ja sen keskeisimpien toiminnallisuuksien ja palvelujen kautta, joka voi olla ensivaiheessa asiakkuudenhallinta. Tämä lähestymistapa voidaan sovittaa (migroida) parhaiten käytössä oleviin järjestelmäpalveluihin ja tukee toiminnan kehittämistä kohti alueellisia yhdenmukaisuutta ja yhteentoimivuutta. Modulaarinen järjestelmäkokonaisuus kattaa tarvittavat tiedot ja välineet, joilla tietoa hyödynnetään alueellisesti, alueiden välillä ja kansallisista palveluista. Modulaarisuudella tuetaan käytettävyyttä ja mukautettavuutta käyttötilanteiden edellyttämissä päätelaitteissa ja roolien mukaisissa näkymissä. 2.2 Kehittämisen vaiheistus Nykyisten monoliittisten järjestelmien kannalta modulaarisuustavoite tarkoittaa nykytoiminnallisuuksien avaamista ja päällekkäisyyksien tunnistamista. Nykyisten järjestelmien ja niiden toiminnallisuuden modularisoinnin kautta on löydettävissä yleistettävissä olevia tehtäviä tai tehtäväryppäitä, yhtenäisiä toiminnallisia kokonaisuuksia yli järjestelmärajojen. Samaa toiminnallisuutta on nykyisin toteutettu päällekkäin eri järjestelmissä. UNA-modulaarisuuden kehittämisen vaiheistus alkaa ytimen rakentamisesta. Ytimen rakentaminen mahdollistaa ns. modulaarisen kehittämisen, jonka avulla voidaan nopeasti ja joustavasti tuottaa uusia

9 järjestelmäpalveluja. Modulaarisuus kehittyy olemassa olevien järjestelmien kyvykkyydestä liittyä ytimen toiminnallisuuteen. Tämä tarkoittaa kykyä välittää ja hyödyntää ytimen hallitsemia tietoja. Ytimen tiedonhallinnan toteuttamisen ansioista pystytään paloittain rakentamaan toimintoja, jotka vaiheittain korvaavat olemassa olevia ratkaisuja. Ytimen kehittämisen vaiheistuksessa tärkeitä ovat arkkitehtuuriperiaatteet, joita toteutetaan mm. järjestelmäarkkitehtuurin linjausten kautta. Näiden periaatteiden mukaan rakentuu kyky tuottaa yhteentoimivia palveluja määritellyn kehittämisstrategian mukaisesti. Nykytilanteeseen sovellettuna olemassa olevat järjestelmät eivät kaikilta osin ole kyvykkäitä ytimen toiminnallisuuksiin, minkä johdosta kehittämisstrategian toteuttamisessa pitää pystyä luomaan ratkaisuja vyöhykkeille, jotka vaiheittain korvaavat olemassa olevien järjestelmien toimintoja. 2.3 Arkkitehtuuriperiaatteet UNA-hankkeessa määriteltyä tavoitearkkitehtuuria ohjaamaan on laadittu asiakas- ja potilastietojärjestelmien kohdearkkitehtuurin toteuttamista ohjaavat arkkitehtuuriperiaatteet, -linjaukset ja vaatimukset. Arkkitehtuuriperiaatteet linjaavat pidemmän tähtäimen tavoitetilaa kohti etenemistä ja ovat pysyväluonteisia (5+ vuotta). Arkkitehtuuriperiaatteiden jaottelu tehdään kokonaisarkkitehtuurimenetelmän mukaisesti. Toimintaa ja tietoa koskevat periaatteet ovat lähtökohta, tietojärjestelmiä ja tekniikkaa koskevat periaatteet johdetaan toiminnan tarpeista. Arkkitehtuuriperiaatteet - Linjaavat pidemmän tähtäimen tavoitetilaa kohti etenemistä ja ovat pysyvä-luonteisia (5+ vuotta) Arkkitehtuurilinjaukset - Arkkitehtuurilinjaukset suhteutettava markkinoiden, teknologiakehityksen ja rajapintavalmiuksien tilanteeseen (päivityssykli n. 2-3 v.) - Arkkitehtuurilinjaukset ohjaavat käytännön toimenpiteitä Arkkitehtuurivaatimukset - Tarkennettu vaatimus tarvittavan tietojärjestelmäpalelun ominaisuudesta tai kyvykkyydestä - Arkkitehtuurivaatimukset ovat esim. hankinnan tai kehittämisen kriteerejä ja tarkennetaan vielä yksityiskohtaisesti kunkin kilpailutuksen yhteydessä. Kuva: Arkkitehtuuri periaatteiden, - linjausten ja vaatimusten suhteesta

10 UNA-hankkeessa määritellyt arkkitehtuurilinjaukset toteuttavat sekä julkisen hallinnon yhteisiä arkkitehtuuriperiaatteita ( 1 JHKA), että 2 VAKAVA-viitearkkitehtuurin (alueellista kehittämistä ohjaava viitearkkitehtuuri) periaatteita. UNA-arkkitehtuuriperiaatteiden kytkökset JHKA- ja VAKAVA-periaatteisiin kuvattu liitteessä 1. Julkisen hallinnon ICT-strategian mukaisesti julkisen hallinnon kokonaisarkkitehtuurin (JHKA) avulla koordinoidaan ja kehitetään julkisen hallinnon organisaatioiden ja palveluiden välistä yhteentoimivuutta. Julkisen hallinnon kokonaisarkkitehtuuri koostuu eri hallinnon alojen kohdearkkitehtuureista, sekä niiden viitearkkitehtuureista, joilla ohjataan tietyn rajatun kokonaisuuden suunnittelua ja toteutusta yhtenäiseen rakenteeseen. TOIMINTA TIETO TIETOJÄRJESTELMÄT TEKNOLOGIA TIETOTURVA Arkkitehtuurin tulee olla strategialähtöistä Toimintatapojen tulee olla yhdenmukaiset Tieto on yhteiskäyttöistä pääomaa Tietovarannolla tulee olla tietovastuullinen Kehitä tai hanki tietojärjestelmiä toimintalähtöisesti Tietojärjestelmien tulee olla käyttäjäystävällisiä Yhtenäistä teknologiaarkkitehtuuri Käytä vakaita teknologioita Huolehdi tietoturvasta osana toimintaa Varaudu poikkeustilanteisiin Kehitä toimintamallia asiakaslähtöisesti Tietoturvallisuus huomioitava tiedon koko elinkaaren ajan Minimoi toimittajariippuvuus Hyödynnä avointa lähdekoodia Vältä päällekkäisiä ratkaisuja Varmista yhteentoimivuus Taulukko: Julkisen hallinnon yhteiset arkkitehtuuriperiaatteet Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaamaan laadittiin kuntien, sairaanhoitopiirien ja kansallisten toimijoiden yhteistyössä vuonna VAKAVAviitearkkitehtuurityötä. VAKAVA-viitearkkitehtuurin arkkitehtuuriperiaatteet ja keskeiset linjaukset ovat ohjanneet määrittelytyötä UNA-hankkeessa. TOIMINTA TIETO TIETOJÄRJESTELMÄT TEKNOLOGIA Palvelutoiminta on turvallista ja laadukasta Tietojärjestelmien tulee tukea päätöksentekoa ja palveluiden laadun varmistamista Tieto kirjataan vain kertaalleen ja hyödynnetään eri käyttötarkoituksiin Asiakastietojen saatavuus turvataan Tietojärjestelmäkokonaisuus on modulaarinen ja joustava Asiakkaan pääsy sähköisiin palveluihin ja tietoihinsa Kansainväliset ja kansalliset standardit ja yhteentoimivuuden määritykset Arkkitehtuurissa noudatetaan ja hyödynnetään kansallisia linjauksia ja tietojärjestelmäpalveluita JHKA-periaatteet: 2 VAKAVA-kohdearkkitehtuuri: 4c1184f7bbf1

11 Yhtenäiset toimintatavat, sujuvat org. rajat ylittävät palveluketjut Toimintamallit ovat tehokkaita ja vaikuttavia Taulukko: VAKAVA-arkkitehtuuriperiaatteet Tietojärjestelmät palvelevat ja helpottavat ammattilaisten työtä Tietojärjestelmien toteutuksessa hyödynnetään markkinoita Kokonaisuus hyödyntää organisaatioiden yleisiä ICTratkaisuja Vältetään päällekkäisyyttä Yhtenäiset ja yhteen toimivat tietojärjestelmät Toimivaksi osoitettu teknologia Järjestelmäkokonaisuus tukee monikanavaisuutta Seuraavassa kuvatut UNA-hankkeen arkkitehtuuriperiaatteet täsmentävät JHKA- ja VAKAVAarkkitehtuuriperiaatteita, ja ne on kohdistettu alueelliseen hyvinvointipalveluiden järjestelmien (asiakas- ja potilastietojärjestelmien) kohdearkkitehtuuriin. TOIMINTA TIETO TIETOJÄRJESTELMÄT TEKNOLOGIA TIETOTURVA Kehittämistä ohjaavana tekijänä on asiakkaan yksilöllinen palvelutarve ja siihen tuotettava joustava palveluprosessi Palveluja on voitava käyttää, mistä tahansa organisaatiosta Tiedon tallennus ja sen hyödyntäminen erotetaan toisistaan Tietovarannolla tulee olla tietovastuullinen Tietojärjestelmäkokonaisuutta kehitetään organisaatioiden toiminnallisten tarpeiden mukaisesti Järjestelmäkokonaisuus on muokattavissa ja personoitavissa joustavasti toiminnallisuuksien osalta ja käyttöliittymätasolla Modulaarisen arkkitehtuurin hallintamalli ohjaa teknologiset valintoja ja toteutuksia Hyödynnetään käyttötarkoitukseen soveltuvia teknologioita Järjestelmien käyttötavat ja toiminnallisuudet toteutetaan niihin kohdistuvat tietoturvaja tietosuoja riskit arvioiden Kaikki toiminta, jolla on merkitystä tietosuojan ja tietoturvan kannalta lokitetaan Asiakkaan näkökulmasta toimintamalli on yhtenäinen Toimintamallit tukevat asiakkaan ohjausvaihetta Tiedon (tieto ja tietomallit) omistajuus tilaajan hallinnassa Kokonaisuutta voidaan kehittää osissa toimittajariippumattomasti Avoimella arkkitehtuurilla (kuvaukset ja rajapinnat) ja standardeja hyödyntämällä mahdollistetaan avoin, laaja kehitysyhteistyö Noudatetaan yleisiä sääntöjä, ohjeita ja määräyksiä poikkeustilanteisiin varautumisesta Keskeiset yhteiset tietojärjestelmäratkaisut ja - toiminnallisuudet toteutetaan vain yhteen kertaan Modulaarisen arkkitehtuurin hallintamalli ohjaa yhteentoimivuuden ja integraatioiden toteuttamisesta

12 Integraatiomalli perustuu avoimiin standardeihin rajapintoihin, kansallisesti ja kansainvälisesti tuettuihin integraatiotapoihin Taulukko UNA-hankkeen arkkitehtuuriperiaatteet Arkkitehtuuriperiaatteita tarkentavat arkkitehtuurilinjaukset ohjaavat käytännön toimenpiteitä, ja suhteutetaan markkinoiden, teknologiakehityksen ja rajapintavalmiuksien tilanteeseen. Linjaukset vaativat näin ollen aktiivista seurantaa ja päivittämistä, jolloin tilaaja-organisaatioiden arkkitehtuurin hallintamallista on sovittava. Hallintamallilla ohjataan arkkitehtuurin kehittymistä ja tarkennetaan esimerkiksi Kantapalvelujen hyödyntämismahdollisuuksien huomiointia osana kokonaisuuden kehittämistä. UNA-hankkeen arkkitehtuurilinjaukset on kuvattu luvussa Arkkitehtuurivaatimukset johdetaan arkkitehtuurilinjauksista. 2.4 Toiminta-arkkitehtuuri Keskeiset toiminta-arkkitehtuuriin kohdistuvat kehittämislinjaukset ohjaavat järjestelmäkokonaisuuden kriittisimpien toiminnallisuuksien toteuttamista. Tähän pohjautuen voidaan muodostaa näkemys tulevaisuuden järjestelmäkokonaisuuden ydintoiminnallisuuksista. Keskeisiä toiminta-arkkitehtuuriin liittyviä linjauksia ovat seuraavat: 1. Tulevaisuuden ratkaisujen on tuettava asiakaslähtöisiä toimintaprosesseja sekä loppukäyttäjien tarvitsemia toimintoja 2. Sosiaali- ja terveydenhuollon yhteisellä asiakaspolkujen hallinnalla ja seurannalla varmistetaan toimintatapoja tukeva tiedon liikkuminen 3. Asiakaskokemus säilyy yhtenäisenä asiakkaan tarpeet huomioiden palvelun eri vaiheissa ja siirtyessä palvelusta toiseen UNA-toiminta-arkkitehtuurin periaatteet pohjautuvat UNA-toiminnallisuuden osalta tuotettuihin asiakasprosessikuvauksiin ja UNA-työpajoista johdettuihin toiminnallisuuden vaatimusmäärittelyihin. 2.5 Tietoarkkitehtuuri Keskeiset tietoarkkitehtuuriin kohdistuvat kehittämislinjaukset ohjaavat järjestelmäkokonaisuuden tiedonhallintaa. Tähän pohjautuen voidaan muodostaa näkemys tulevaisuuden järjestelmäkokonaisuuden tiedonhallinnan ratkaisujen toteuttamisesta. Keskeisiä tietoarkkitehtuuriin liittyviä linjauksia ovat seuraavat: 1. Tietoarkkitehtuuri tukee tiedon etsimistä ja löytymistä 2. Ydin vastaa keskeisten tietojen tiedonhallinnasta 3. Keskitetyt tiedonhallinnan ratkaisut huolehtivat tiedon ajantasaisesta saatavuudesta, luotettavuudesta,

13 eheydestä ja säilyttämisestä tietoturvallisesti 4. Tiedon jäsentely voidaan toteuttaa dynaamisesti 5. Tietoa voidaan etsiä erilaisilla hakupoluilla 6. Käytetään yhteisesti sovittuja valmiita tietotyyppejä Tietoarkkitehtuuri sisältää kaksi tärkeää tiedon käytettävyyteen vaikuttavaa tekijää: sopimisen tiedon rakenteesta ja sopimisen tietotyypeistä. UNA-määrittelyissä tukeudutaan kansallisesti sosiaali- ja terveydenhuollossa tehtyihin käsitemalleihin (mm. joilla pyritään kuvaamaan ymmärrettävästi toiminnan käsitteet ja niiden väliset yhteydet. Tiedon rakenne on perinteisesti määritelty hierarkkiseksi. Hierarkkinen rakenne tukee tiedon tallentamista ja tiedon sijoittamista eli hierarkkinen rakenne ilmaiseen tiedon sijaintia, ei tiedon ominaisuuksia. Hierarkkista rakennetta käytetään mm. tiedon arkistoinnissa. Tulevaisuudessa vaatimus tiedon rakenteella on palvella enemmän tiedon etsimistä ja löytymistä. Koska tiedon etsimiseen kuluva aika on pois tuottavasta työstä, muodostuu tiedon löytymisen vaatimus määrääväksi vaatimukseksi UNA- tietoarkkitehtuurissa. Perinteiset hierarkkiset tietovarastot tai kansio-rakenteet eivät yksin vaatimusta täytä. Keskitetty tiedonhallinta ei aina tarkoita, että tieto sijaitsee fyysisesti samassa paikassa. Ytimen tiedonhallinnalla tarkoitetaan tiedon hallintaa metatiedoilla tai ominaisuuksilla tai tietoon liitetyillä muilla argumenteilla riippumatta siitä, missä itse tieto sijaitsee. Todettakoon, että XDS-pohjaisella ratkaisulla hallintaan pääasiassa dokumenttien jakelua eikä se suoranaisesti tue tiedon löytymistä sisällön perusteella. UNA-modulaarisen arkkitehtuurin vaatimus tietoarkkitehtuurille on, että sen tulee tukea jatkossa tiedon etsimistä ja löytymistä erilaisilla dynaamisilla hakupoluilla. Tiedon rakenteen on oltava käyttäjän mukautettavissa sekä tietoa on voitava etsiä erilaisilla hakukriteereillä. Tulevaisuudessa erilaiset keinot käsitellä ja jäsennellä itse tietoa dynaamisesti ovat vaatimuksena. Yksi esimerkki tällaisista keinoista on tiedon sisältöön tai sen metatietoon liitettävät tagit. Näiden lisäksi tageja voidaan liittää mm. tiedon kontekstiin, attribuutteihin jne. Tiedon yhteiskäytön mahdollistamiseksi tietomallin lisäksi on sovittava tietotyypeistä. Tietotyypit ovat yksi keskeinen osa tietoarkkitehtuuria. Vaatimus tietotyyppien määrittämiselle on, että ne soveltuvat käyttötarkoitukseensa ja tietoa voidaan käsitellä kullekin tietotyypille ominaisella tavalla. Vaatimuksena UNA-arkkitehtuurissa on, että käytetään yhteisesti sovittuja valmiita tietotyyppejä. Esimerkiksi HL7 V3 sisältää valmiita, yhteisesti sovittuja erilaisia tietotyyppejä ja mm. FHIR-kehitystyö on pohjautunut RIMmallin, sanastojen ja tietotyyppien käyttöön. Dynaaminen UNA-tietoarkkitehtuuri pohjautuu: Kanta-palvelujen yhteentoiminnallisuuteen SOTE- palveluorganisaatioilta velvoitettavien rekisterinpidon lainalaisuuksiin Tiedon omistajuuteen ja hallintaan perustuvien normin ja säädösten mukaiseen läpinäkyvyyteen ja tietojen saatavuuteen

14 2.6 Tietojärjestelmäarkkitehtuuri Keskeiset tietojärjestelmäarkkitehtuurin kohdistuvat kehittämislinjaukset ohjaavat järjestelmäkokonaisuuden uudistamista, kehittämistä ja tulevia hankintoja. Tavoitteena on, että kehittämislinjauksiin pohjautuen voidaan vaiheittain kilpailuttaa tietojärjestelmäratkaisuja tai ohjata nykyisten kehittämistyötä. Keskeisiä tietojärjestelmäarkkitehtuuriin liittyviä linjauksia ovat seuraavat: 1. Tietojärjestelmäkokonaisuuden uudistaminen voidaan toteuttaa vaiheittain, jota toiminnalliset tarpeet ohjaavat 2. Modulaarisuus ratkaistaan toiminnallisiin kokonaisuuksiin pohjautuen 3. Modulaarisuus rakentuu itsenäisistä tietojärjestelmäkomponenteista, jotka voidaan käyttöönottaa tai korvata yhtenäisinä omina kokonaisuuksina 4. Muokattavilla prosesseilla ja käyttöliittymillä sekä eri laitealustoille turvataan käytettävyys sosiaali- ja terveydenhuollon moninaisiin tarpeisiin 5. Mukautettavuutta prosessien, ulkoasun tai tietomallin osalta voidaan tehdä ilman ohjelmistokehitystä, käyttäen toteutukseen kuuluvia mukautustyökaluja 6. Järjestelmäkokonaisuus toteuttaa rooli- ja tehtävätason käyttöliittymät, joissa käyttäjälle näytetään kaikki (ja vain) tarpeellinen tieto 7. Tilaajilla on oikeus tiedon ja integraatiorajapintojen vapaaseen käyttöön ja tilaaja voi luovuttaa oikeuksia 3. osapuolen hyödynnettäväksi 8. Järjestelmäpalvelut on suunniteltu toimimaan itsenäisinä, avoimina ja joustavina palveluina (=moduulit) 9. Selkeästi eroteltavilla moduuleilla vähennetään riippuvuuksia sekä helpotetaan ylläpidettävyyttä ja järjestelmäkokonaisuuden muunneltavuutta 10. Mahdollistetaan erilaisten kehitystapojen (ostettu, oma kehitys, avoin lähdekoodi) hyödyntäminen 11. Moduulit käyttävät hyödyksi keskeisiä yhteisiä ratkaisuja ja järjestelmäpalveluja 12. Rakennetaan ydin, tietty vakio-osa, johon toimintopohjaisen moduulijaottelun perusteella kootaan asiakasvarioituvat moduulit 13. Ydin sisältää järjestelmäkokonaisuuden keskeisimmät ominaisuudet ja kattavat rajapinnat uusien toimintojen ja ominaisuuksien lisäämiselle 14. Yhteentoimivuutta kuvataan vyöhykeajattelulla ja toiminnallisuuden edellyttämien tietotarpeiden reaaliaikaisuusvaatimus ja tiedon välittämisen kyvykkyys ohjaa vyöhykkeen valintaa ja käytettävää integraatiotapaa 15. Automatisoidulla testiympäristöllä varmistetaan yhteentoimivuus, luotettavuus ja pienennetään muutoksiin liittyviä riskejä 2.7 Teknologia-arkkitehtuuri

15 Keskeiset teknologia-arkkitehtuurin kohdistuvat kehittämislinjaukset ohjaavat järjestelmäkokonaisuuden tekniseen toteuttamiseen liittyviä yksityiskohtia. Tavoitteena on, että kehittämislinjauksiin pohjautuen voidaan vaiheittain kilpailuttaa tietojärjestelmäratkaisuja tai ohjata nykyisten kehittämistyötä niin, että teknologia turvaa järjestelmäkokonaisuuden toimivuuden sote-toimijoiden edellyttämällä tavalla. Keskeisiä teknologia-arkkitehtuuriin liittyviä linjauksia ovat seuraavat: 1. Järjestelmäkokonaisuuden integraatiot toteutetaan pääsääntöisesti keskitettyä integraatioratkaisua hyödyntäen 2. Järjestelmäratkaisussa hyödynnetään yleisesti käytössä olevia ja moderneja teknologioita, joiden käytöstä löytyy riittävän hyvät referenssit 3. Integraatioiden tulee mahdollistaa eri teknologioiden tai eri teknologiasukupolvien yhtaikaisen käytön 4. Kulloistenkin eri teknologiasukupolvia hyödyntävien ratkaisujen tulee olla periytyviä 2.8 Tietoturva-arkkitehtuuri Keskeiset tietoturva-arkkitehtuurin kohdistuvat kehittämislinjaukset ohjaavat järjestelmäkokonaisuuden tietoturvaan liittyviä yksityiskohtia. Tavoitteena on, että kehittämislinjauksiin pohjautuen järjestelmäkokonaisuuden tietoturva ei vaarannu missään vaiheessa. Keskeisiä tietoturva-arkkitehtuuriin liittyviä linjauksia ovat seuraavat: 1. Järjestelmäratkaisut ovat toteutettu niihin kohdistuvat tietoturva- ja tietosuojariskit arvioiden 2. Lokitiedot hallitaan keskitetyllä lokienvalvontajärjestelmällä, joka varmistaa lokitietojen eheyden 3. Järjestelmäkokonaisuus on suunniteltu jatkuvuuden ja poikkeustilanteisiin varautumisen osalta organisaation toiminnan vaatimalla tasolla

16 3 Modulaarisen järjestelmäarkkitehtuurin kuvaukset ja vaatimukset 3.1 Tietojärjestelmäpalvelujen kuvaus Tulevaisuuden tietojärjestelmäkokonaisuus toteutetaan UNA-arkkitehtuurilinjauksiin pohjautuen, jolloin järjestelmäpalveluita toteutetaan modulaarisesti joko ytimeen tai vyöhykkeille. Moduulit toteuttavat ja tarjoavat muiden käyttöön tietojärjestelmäpalveluja. Tietojärjestelmäpalvelu muodostuu itsenäisestä moduulista pienimmillään tai useamman moduulin muodostamasta toiminnallisesta kokonaisuudesta. Ydin on keskeisessä roolissa tarjoten keskeiset pääsyn asiakkaaseen/potilaaseen liittyvään ajantasaiseen tietoon riippumatta tiedon sijainnista. Ytimen keskeisinä ominaisuuksina on tunnistettu, että ydin hallinnoi kaikkea keskeistä tietoa, ja moduulien tarvitsema tiedonhallinta on saatavissa hallitusti ytimestä keskeinen tieto varastoidaan Ytimeen, joka ottaa vastaan ja antaa ulos tietoa rajapintakerroksen kautta ydin takaa tiedon eheyden ja yhdenmukaisuuden ydin vastaa rekistereistä ja kansallisista vaatimuksista ydin vastaa tiedonhallinnan tietosuojasta ja lokien keräämisestä se mahdollistaa keskeisiin tietoihin pohjautuen yksittäisten käyttöliittymien korvattavuuden se tukee hallittua rajapintojen kehittämisen mallia se tukee keskitettyä, dynaamista tietomallia Modulaarisen toteuttamisen tulee rakentua selkeään perustaan, joka tarjoaa toiminnallisesti yhteismitallisen ja kokonaisprosessien kannalta hallittavan ja selkeän kokonaisuuden. Tämän perusteella ytimessä tulisi olla seuraavat toiminnot: - Keskitetty UNA-tiedonhallintaratkaisu o Tiedon näkyvyyden ja saatavuuden hallintaratkaisu o Tukee edistyneitä tiedonhakumenetelmiä - MasterDatan hallintaratkaisu o Tiedon yhtenäistämisen hallinta o Dynaamisten tietorakenteiden hallinta - Asiakkuudenhallinnan toiminnallisuus, joka koostuu o Tieto asiakkaalle annetusta palvelulupauksesta o Palvelulupauksen ehtojen, palvelusisältöjen toteuttamiseen tarvittavat tiedot organisaatioriippumattomasti o Asiakkaiden segmentointiin ja profilointiin tarvittavat tiedot (esim. asiakkaan tarve) o Olemassa olevien asiakassuhteiden hallinta eri palveluntuottajilta o Asiakkaan kokonaissuunnitelman näkymä Asiakkuudenhallinnan toiminnallisuus ytimessä Asiakas keskiössä-ajattelu on UNA-toiminnallisten määrittelyjen lähtökohta, joka ohjaa tulevaisuuden hyvinvointijärjestelmän rakentumista.

17 Asiakkuudenhallinnan toiminnallisuus ja sen toteuttavat toimintaprosessit on mahdollista koota moduuleista, jotka toteuttavat siinä käyttötilanteessa tai asiakasprosessissa tarvittavan toiminnallisuuden. Perinteisissä asiakas- ja potilastietojärjestelmissä asiakkuudenhallinta on puutteellinen ja se rakentunut kiinteästi olemassa olevien järjestelmien sisään. Asiakkuudenhallinnan toiminnallisuus on keskeisessä roolissa kun toiminnan- ja tuotannonohjaus halutaan kytkeä saumattomaksi kokonaisuudeksi. Alla kuvattuna asiakkuudenhallinnan toiminnallisuuskartta, jossa kuvataan asiakkuudenhallinnan suhdetta toiminnan- ja tuotannonohjaukseen. Kuva: UNA-ATT osaprojektin toiminnallisuuskartta Tiedonhallintaratkaisu ytimessä Una-ytimeen tulee rakentaa tiedonhallintamalli, joka mahdollistaa laajan tietojen hallinnan tietovarastojen fyysisestä sijainnista riippumatta. Dynaaminen tiedonhallintamalli rakentuu yhteiskäyttöisistä tietomalleista, toteutuksia sitovista periaatteista ja standardeista sekä teknisistä integraatiokyvykkyyksistä (älykkäät rajapinnat). Dynaaminen tiedonhallintamalli: - mahdollistaa olemassa olevan ja uuden tiedon yhtäaikaisen käytön - tarjoaa kunkin moduulin ja järjestelmän tarvitseman tiedon riippumatta siitä, missä tieto sijaitsee

18 - hyödyntää yhteiskäyttöisiä tietomalleja - vaatii kehitettäviltä moduuleilta yhteisiin periaatteisiin sitoutumista ja toimialalla käytössä olevien standardien käyttöä Vanhat potilastietojärjestelmät (potilashallinto) Vanha asiakasrekisteri Järjestelmät ja moduulit Olemassa olevat SOTE-järjestelmät UNA:n järjestelmät ja moduulit Dynaaminen tiedonhallinta Yhteiskäyttöiset tietomallit Toteutuksia sitovat periaatteet ja toimialakohtaiset standardit Tekniset integraatiokyvykkyydet YDIN Järjestelmistä ja moduuleista eriytetyt yhteiskäyttöiset tiedot Yhteiskäyttöinen Asiakasrekisteri (CRM, asiakashallinta) Tiedonjaon ratkaisu (potilas- ja asiakasdokumentit) Kuva: Dynaaminen tiedonhallintamalli ytimessä Moduulit vyöhykkeillä

19 Toiminnallisista määrittelyistä tunnistettujen toiminnallisten kokonaisuuksien (moduulit) edellyttämät tietotarpeet ja niiden reaaliaikaisuusvaatimukset ohjaavat modulaarisessa arkkitehtuurissa vyöhykkeen valintaa ja ytimen kanssa toteutettavaa ja käytettävää integraatiotapaa. Modulaarisuuden vyöhykkeet: 1. Käyttöliittymät - ytimen päälle tehty käyttöliittymä - tarvitsee ytimen toimiakseen - ehdoton reaaliaikaisuusvaatimus - tietyn roolin mukainen tietojen kirjoitus, muokkaus tai näyttäminen 2. Prosessitason integraatio - ytimen tiedot ohjaavat toiminnallisuutta, mutta tietoja tarvitsee prosessoida - tiedon käsittelyn viiveen häivyttämiseksi tietoja voidaan prosessoida taustalla ja ennakoiden - moduulit pystyvät käyttämään hyväkseen toistensa toiminnallisuutta - tarkoittaa esim. prosessiohjattuja tietojärjestelmäpalvelujen toteuttamista monitoimittajamallilla - kytkee palvelut asiakasprosesseiksi 3. Sanoma-/tietokenttätason integraatio - Toimintalogiikkaa ja tietosisältöä on nykyisellään selkeästi ytimen ulkopuolella ja voi olla myös jatkossa - tiedon tarve ytimestä rajallista - asynkroninen sanomaintegraatio riittävä Vyöhykkeille rakentuvat moduulit sijoittuvat integraatiovaatimusten ja -kyvykkyyksien mukaan eri tasoille sen mukaan, miten toiminnalliset kehityskohteet ja -vaiheet kulloinkin edellyttävät. Esimerkkinä ytimen välittömässä läheisyydessä (vyöhyke 1) ovat moduulit, joissa on vain käyttöliittymätoiminnallisuuksien varaan rakennetut ominaisuudet. Prosessitasolla (vyöhyke 2) olevat moduulit ovat tyypillisesti rajatun prosessin tietyn vaiheen tuottavia järjestelmäpalveluja. Esimerkkinä prosessitason moduulista on ajanvaraus, joka on järjestelmäpalvelujen näkökulmasta rajattavissa oleva toiminnallisuus, joka tyypillisesti on usean erilaisen hoitoprosessien yksittäinen osa. Ajanvaraus voidaan palveluna helposti liittää osaksi hoitoprosessia. Uloimmalla vyöhykkeellä ovat moduulit, jotka pystyvät sanomatasolla kytkeytymään ytimen hallitsemiin tietoihin. Esimerkkinä uloimman moduulin järjestelmästä on laboratorion järjestelmäpalvelu, joka palvelee laboratoriotutkimuksen prosessia, mutta tarvitsee palveluun kytkeytymiseksi asiakastiedon ja tarkennettuna asiakkaan hoitoprosessin tila- ja tunnistetietoja, jota varten laboratoriotutkimus on tilattu. Nykyiset järjestelmät ovat tyypillisesti erillisjärjestelmiä ja niiden vaiheittainen kytkeminen modulaariseen arkkitehtuurin on suoraviivaisinta toteuttaa sanomatason (vyöhyke 3) integraation kautta. 3.2 Integraatioarkkitehtuuri

20 Integraatioiden keskeinen tavoite on, että kerran kirjattua tietoa käytetään hyväksi toisiaan seuraavissa asiakasprosessin vaiheissa. Lisäksi tavoitteena on helpottaa eri järjestelmien yhtäaikaista käyttöä integroimalla järjestelmät käyttäjän näkökulmasta mahdollisimman yhtenäiseksi kokonaisuudeksi. Integraatiot ovat tietosisällöltään kehittyviä ratkaisuja, jotka voivat hyödyntää olemassa olevia palveluita ja kutsua toisia palveluita. Modulaarisuuden hyöty rakentuu integraatioiden kyvykkyyteen hyödyntää kehittyneitä integraatiopalveluita ja kutsua saatavilla olevien moduulien toiminnallisuuksia. Moduulien keskinäisessä kommunikoinnissa voidaan hyödyntää keveitä mekanismeja (esim. rest-rajapintoja ja FHIR), jolloin moduulit toteuttavat yhdessä halutut toiminnot. Vyöhykkeiden moduulit voivat tehdä kyselyjä suoraan toisilleen, tai ytimeen, mutta jos tietoa tarvitsee hakea ulkoisista ratkaisuista, integraatiot kulkevat ytimen ja integraatioratkaisun kautta. Integraatioita pitää pystyä myös rakentamaan tieto-, prosessi- ja/tai sanomapohjaisina. Jo käytössä olevien järjestelmien ja uudistuvien ratkaisujen tulee toimia rinnakkain kokonaisuutena tukeutuen tarvittaessa olemassa olevaan tekniseen ympäristöön. Integraatioiden yleiset periaatteet: kerran syntyneen tiedon uudelleenkäytettävyys, yksikäsitteisyys ja muutosten yksikäsitteinen hallinta asiakasprosessin vaiheiden väliset tietovirrat palvelevat saumattoman toiminnan tavoitteita ja tavoitteita tukevia asiakaspolkuja integraatiorajapinnat pyritään toteuttamaan mahdollisimman yleisiksi ja standardien mukaisina niin, että riskit eri järjestelmien/toimijoiden keskinäisistä riippuvuuksista pystytään minimoimaan Järjestelmäkokonaisuuden integraatioiden hallinnassa hyödynnetään alueellisesti keskitettyä integraatioratkaisua. Integraatioratkaisulla turvataan integraatioiden seuranta, valvonta ja mahdolliset lokitukset, mutta ennen kaikkia tuodaan joustavuus erilaisten rajapintatekniikoiden yhteensovittamiseen. Myös mahdollisesti olemassa olevia integraatioratkaisuja voidaan hyödyntää osana kokonaisuutta. Integraatioratkaisuissa tulee olla monipuoliset, tehokkaat ja standardeja tukevat välineet, joilla modulaarisen arkkitehtuurin keskinäinen yhteensovittaminen toteutetaan. Integraatioarkkitehtuurin toteuttamiseen tarvitaan myös avoimien rajapintojen käyttöönoton tueksi automatisoidut testitapaukset ja testausvälineet. Sosiaali- ja terveydenhuollossa hyödynnetään - ja jatkossa tullaan entistä laajemmin - Kanta-palveluja tiedonjaossa. Tiedonhallinta tukeutuu laajalti myös muihin esim. kansallisen palveluväylän kautta hyödynnettäviin kansallisiin tietovarantoihin. Näin ollen alueellisen järjestelmäkokonaisuuden tarvitsee hallita myös ulkoisia integraatioita. Järjestelmäkokonaisuuden integraatiot ulkoisiin ratkaisuihin (merkattu alla olevassa kuvassa U:lla) kulkevat ytimen kautta, joka puolestaan hyödyntää keskitettyä integraatioratkaisua tiedon välittämiseen. Tämä voidaan toteuttaa keskitettyä integraatioratkaisua hyödyntämällä, mutta tietoturvariskiarvioihin ja kansallisiin palveluihin liittymisen vaatimuksiin perustuen ulkoinen tiedonsiirto (mm. kansallisten palvelujen) voidaan myös tarvittaessa eriyttää erilleen alueellisen järjestelmäkokonaisuuden sisäisestä integraatioratkaisusta. Kansallisen palveluväylän hyödyntäminen kattavasti tiedonsiirtoväylänä kansallisiin palveluihin riippuu täysin kansallisen palveluväylän toteuttamisen aikatauluista.

21 Ulkoiset sovellukset Vyöhykkeiden UNA moduulit UNA Ydin Kansallinen Palveluväylä Kansalliset ratkaisut Alueellinen keskitetty integraatioalusta U U U Mikäli UNA-järjestelmäkokonaisuuden installaatioita rakennetaan useampi kuin yksi, keskustelevat ne alkuvaiheessa toistensa kanssa alueellisten integraatioalustojen kautta (Kuva, UNA-integraatiomalli, monta UNA-järjestelmää). Myöhemmin, Kansallisen palveluväylän laajemman käyttöönoton myötä myös UNAjärjestelmäkokonaisuudet voivat hyödyntää sitä tiedonsiirtoon eri UNA-instanssien välillä.

22 Integraatioratkaisuun, integraatioihin ja rajapintoihin liittyvät tekniset vaatimukset löytyvät erikseen UNAmäärittelyistä (osiosta 6 Tekniset vaatimukset). 3.3 Toimintaprosessit UNA-hankkeen tavoittelemissa tulevaisuuden toimintaprosesseissa tulee pystyä tukemaan aina verkon yli tarjottavista palveluista totuttuihin seinien sisällä tarjottaviin palveluihin. Esimerkkejä sote-

23 toimintaympäristössä tapahtuvista viimeaikaisista muutoksista ovat mm. potilaan ja asiakkaan roolin kasvaminen, itseohjautuvuus ja palvelujen digitalisointi. Perinteisen järjestelmäkeskeisen arkkitehtuurin tilalle, UNA-hanke on tuottanut muutoksia tukevan, avoimen modulaarisen arkkitehtuurin ja vaiheittaisen kehittämisen mallin. Näin mahdollistuu uusien digitaalisten palvelujen ja tietojen yhdistäminen sote-kokonaisuuteen. UNA-ratkaisun myötä eri käyttäjäryhmille tarjotaan mahdollisuus käyttää moduulien tarjoamia palveluita käyttöliittymillään sen sijaan, että rakennettaisiin monimutkaisia integraatioita. Perinteinen malli, jossa hyvissä ajoin ennen toteutusta määritellään toiminnalliset vaatimusmäärittelyt, tulee mukautumaan uuteen kehittämisen malliin, jossa sekä sote-toiminnan että applikaatioiden kehittäjät toteuttavat vierekkäin ratkaisuja. UNA-hankkeessa määritellyt nykyisenkaltaiset toiminnalliset vaatimusmääritykset tukevat kehittämistä, mutta ovat osin myös tämän haasteen alla. UNA-hankkeessa on modulaarista järjestelmäarkkitehtuuria määritelty hankesuunnitelman mukaisesti kokonaisarkkitehtuurin näkökulmasta toimintalähtöisesti ja arkkitehtuuriperiaatteisiin pohjautuen. Toiminnallinen fokus on ollut asiakaslähtöiset hyvinvointipalvelut. Syntyneet toiminnalliset tulokset ovat kuvauksia erilaisista asiakasprosesseista ja käyttötapauksista. Toimintaa on kuvattu sekä kertomustyyppisinä tapahtumina, että mallintamalla toimintaprosesseja. Jotkin kuvaukset ovat esimerkkejä yksittäisistä tapauksista. Yleistämällä voidaan näitä kuvauksia hyödyntää mm. modulaarisen järjestelmäarkkitehtuurin suunnittelussa ja toteuttaa näin toimintalähtöistä kokonaisarkkitehtuuria (kuva x). Kuva x: Toiminnalliset kuvaukset pohjana modulaarisuudelle Abstraktiotasoa nostamalla ja toimintaa yhtenäistämällä voidaan löytää hyötyjä. Yksi suurimmista hyödyistä siirtymisellä yksittäistapauksista yleisiin, on saada aikaan malleja, jotka mukautuvat helposti yllä mainittuun nopeasti muuttuvaan toimintaympäristöön ja tekniseen kehitykseen. Käyttäjälle modulaarisuus tuo mukanaan tarpeen ymmärtää työnkulkuja ja niiden tietotarpeita sekä käyttötilanteisiin sopivia koottuja näkymiä. UNA-hankkeessa on painotettu toimintopohjaisuutta (toiminnallisten kokonaisuuksien tunnistaminen, generalisointi) sekä alustalähtöisyyttä (ydin ja käyttöliittymät). Yleistettyjen, ns. geneeristen tehtävien, niihin liittyvien metatietojen ja vaatimusten avulla pystytään siis organisaatioiden prosessit kuvaamaan ja mahdollistamaan myös toimintamallien yhdenmukaistamisen. Näiden toiminnallisten palvelujen tueksi on mahdollista kehittää itsenäisiä moduuleja. Lopullinen moduulijako syntyy kuitenkin vasta siinä vaiheessa, kun ollaan toteuttamassa ratkaisua usein ketterillä menetelmillä kulloinkin valitun toiminnan tueksi. Jos moduulit määritellään etukäteen liian kiinteästi, voidaan joutua perinteisiin toimittajakohtaisiin lukituksiin ja kokoonpanokohtaiseen jäykempään toteutukseen.

24 3.3.1 Toiminnalliset kuvaukset pohjana modulaarisuudelle UNA-hankkeen toiminnallisissa kuvauksissa on painotettu asiakasnäkökulmaa. Perinteisesti toiminnallisia kuvauksia on tehty organisaationäkökulmasta ja myös niitä on syytä käyttää modularisoinnissa. Kovin laajalti toiminnallisia kuvauksia ei ole tarpeen etukäteen tarkentaa, koska varsinainen tarkentaminen tapahtuu vaiheittain modulaarisesti ratkaisun asteittaisen kehittämisen kautta. Kun kehittämiskohde on valittu, ensimmäisiä tehtäviä on kartoittaa, miten nykyisiä toimintatapoja valitussa kehittämiskohteessa voidaan kehittää ja sen jälkeen tarkastella toimintaa prosessien ja tehtäväketjujen kautta. Oleellista on tunnistaa yhteiset tehtävät yli toimintaprosessien ja prosessirajojen. Yleistämisen kautta saadut ns. geneeriset tehtävät tulevat olemaan jatkossa pohjana modulaarisuudelle ja vaatimuksille hankintoja ja toteutusta varten. Modulaarinen prosessimallinnus, jossa tunnistetaan prosessien yhteisiä osia, tuottaa mallinnuksen edetessä seuraavia ominaisuuksia: - nopeuttaa uusien prosessien kuvaamista tarjoamalla aikaisemmin määriteltyjä prosessien osia - yhtenäistää prosessikuvauksia - mahdollistaa iteroivan määrittelyn toiminnalliset määrittelyt täydentyvät työn edetessä - päällekkäinen kuvaaminen vähenee ei määritellä samaa toiminnallisuutta useaan kertaan Sosiaalihuollon geneeriset prosessit Sosiaalihuollon yhteisesti määriteltyjä ydinprosesseja on käytetty UNA-hankeessa hyväksi kuvattaessa toiminnallisia vaatimuksia. Näitä ns. geneerisiä ydinprosesseja on syytä käyttää jatkossa toteutusvaiheessa, kun modulaarisuutta ollaan suunnittelemassa ja ottaa huomioon vaatimukset, joita kehittämiselle on UNAhankkeessa asetettu. Sosiaalihuollon valtakunnalliset määrittelyt ovat tuottaneen sosiaalihuollon yhdeksän ydinprosessia (ns. geneerisiä prosesseja) vaiheineen. Sosiaalihuollon palvelutehtävät voidaan toteuttaa näillä ydinprosesseilla, noin 1-5 ydinprosessia palvelutehtävää kohden. (Kuva x.) Kuvaus palvelutehtävistä ja ydinprosesseista löytyy mm. julkaisussa: Sosiaalihuollon asiakastietojen käsittely ja valtakunnalliset tietojärjestelmäpalvelut: Sosiaali- ja terveydenhuollon valtakunnallinen kokonaisarkkitehtuuri tavoitetila 2020 v 1.0.

25 Kuva x. Sosiaalihuollon ydinprosessit ja palvelutehtävät, joissa niitä sovelletaan (lähde THL) Hyötyinä ydinprosessien tunnistamisesta sosiaalihuollossa on kokonaiskuvan hahmottuminen sekä toiminnan yhtenäistämisen mahdollistuminen verrattuna aikaisempaan palvelutehtäväkohtaiseen tapaan kuvata prosesseja. Kuvassa x on kuvattu yksi palvelutehtävä, päihdehuolto, käyttäen viittä geneeristä ydinprosessia. Kuva x. Esimerkkinä päihdehuollon prosessit ja niiden yhteydet (lähde THL) Terveydenhuollon geneerisiä prosesseja UNA-toiminnalliset vaatimusmäärittelyt lähtevät asiakasnäkökulmasta, jolloin organisaationäkökulma on jäänyt vähemmälle huomiolle. Sekä asiakas- että organisaationäkökulmat on syytä ottaa huomioon, kun toteutetaan sosiaalihuoltoa vastaava geneeristen ydinprosessien määrittely kattavana myös

26 terveydenhuoltoon. Terveydenhuollon ydinprosessienmäärittelyä varten löytyy aineistoa ja julkaisuja jo melko runsaasti erilaisten projektien tuloksena myös valtakunnallisesti. Terveydenhuollossa on syytä käyttää myös sosiaalihuoltoa jo määriteltyjä tai jatkossa tunnistettavia yleisiä prosesseja tarpeen mukaan. Ydinprosessien myötä sinänsä monimutkaisena näyttäytyvä terveydenhuollon kokonaisuus hahmottuu selkeämmin. Yleistäminen on myös yksi keino toteuttaa JHKA:n asettamia periaatteita. Tällaisia ovat mm. yksinkertaista, yhdenmukaista toimintamallit, tee uudelleenkäytettäviä ja avoimia ratkaisuja sekä maksimoi yhteiskunnan kokonaisetu. UNA-hankkeessa generalisointia on toteutettu esimerkinomaisesti osasta terveydenhuollon toimintaa ja hankkeessa on tunnistettu alustavati muutamia ydinprosessiehdokkaita. Näistä osaa on esitelty kuvassa x. Terveydenhuollon palvelujen ja hoitojen toteuttaminen suunnitellaan tulevaisuudessa yhä enemmän uusilla sähköisillä toimintamalleilla. Toimintamalleille modulaarisuus tarkoittaa sitä, että niissä tullaan käyttämään uudelleenkäytettäviä palveluja eli ns. prosessinpätkiä. Terveydenhuollon prosessit voidaan muodostaa käyttäen näitä geneerisiä ydinprosesseja. Hoidon tarpeen/ hoidon arviointi Arvioinnin päättäminen ja Arvioinnin käynnistäminen Arvioinnin toteuttaminen tulosten julkaiseminen Suunnittelun käynnistäminen Hoidon suunnittelu Suunnittelun toteuttaminen Suunnittelun päättäminen ja tulosten julkaisu Yleinen ohjausprosessi Kartoita lähtötilanne ja suunnittele ohjaus Toteuta ohjaus Tuloksen kirjaus ja julkaiseminen Valmistele informointi/ ohjaus Informointi/ ohjaus Toteuta informointi/ ohjaus Kirjaa toteutettu informoitin/ ohjaus Pyynnön vastaanotto Palvelun/hoidon toteutus Palvelun jonoon asettaminen Palvelun ajanvaraus Palvelun toteutus Tulosten kirjaaminen ja julkaisu Palvelun suoritus (esim. tähystystutkimus) Palvelun hakupalvelu Vastaanota pyyntö Selvitä tutkimuksen tekevä palvelu Lähetä pyyntö tekevälle palvelulle Tulosten kirjaaminen ja julkaisu Valmistele hakupalvelu Hae tutkimuksen tekevä palvelu Tutkimuspalvelu Paikannuspalvelu Ota pyyntö vastaan ja valmistele tutkimus Tee tutkimus/ tähystys Kirjaa tutkimustulokset Selvitä edellytykset paikantamiseen Paikanna kohde Informoi tulos Tiedonhallinnan informaatioprosessi Tiedon etsiminen Tiedon noutaminen Tiedon käyttäminen Tiedon tuottaminen Tiedon tallentaminen Tiedon julkaiseminen Yksilöintitunnusten muodostaminen Tunnista kohteen käyttämä tunnusjärjestelmä Etsi seuraava vapaa tunnus ko. sarjasta Julkaise yksilöivä tunnus Kuva x: Esimerkkejä geneeristä terveydenhuollon prosesseista

27 Kuvassa x on muutamia esimerkkejä ydinprosesseista, joita on muodostettu analysoimalla muutamaa UNAtoiminnallista kuvausta. Analysointia ei ole tehty kattavasti koko aineistosta ja siksi esitetyt ydinprosessit ovat esimerkinomaisia. Näitä ydinprosesseja voidaan käyttää toteuttamaan toiminnassa tarvittavia tehtäviä ja tehtävistä muodostuvia toimintoketjuja eri käyttötilanteissa tarpeen mukaan. Sovellettavaksi esimerkiksi tässä dokumentissa on otettu terveydenhuollon ydintoimintaa toteuttava hoitoprosessi. Tällaiseksi prosessiksi soveltuu hyvin ns. geneerinen hoitoprosessi. Geneerisesti tätä prosessia on kuvattu mm. SerAPI-hankkeessa (Tekesin FinnWell -teknologiaohjelmaan kuuluva valtakunnallinen hanke Suomessa) sekä THL:n raportissa Terveydenhuollon toimintaprosessit: Terveydenhuollon yleiset prosessit ja niiden tarkennukset ( Tässä raportissa viitataan NI-hankkeessa (Ruotsin kansallisen tietorakenteen hanke, Nationell Informationsstruktur) kuvattua hoidon ja hoivan yleisen tason prosessimallia, kuva x. Kyseisessä prosessissa on otettu huomioon UNA-hankkeessa kantavana asiana oleva potilaan ja asiakkaan näkökulma, jossa myös kansalaiselle on kuvattu aktiivinen rooli osallistujana. Muita näkökulmia ovat olleet ammattihenkilöiden näkökulma, hallinnon, työn ohjauksen ja tutkimuksen näkökulma sekä tietojärjestelmätoimittajien ja IT-markkinoiden edustajien näkökulma. Geneerinen hoitoprosessi tulisi tässä esimerkkitapauksessa käyttämään mm. seuraavia ydinprosesseja: - yleinen ohjausprosessi ohjaa asiakkaalle/ potilaalle annettavan palvelun eri vaiheiden etenemistä ja tarkentaa palvelun edetessä palvelusuunnitelmaa/ hoitosuunnitelmaa - yleinen tiedonhallinnan informaatioprosessi - ydinprosessia kutsutaan aina, kun halutaan etsiä tai kirjata tietoa sekä julkaista tieto - hoidon tarpeen / hoidon arviointi arviointia tapahtuu ennen palvelun toteuttamista sekä prosessin kuluessa - hoidon/ palvelun suunnittelu luodaan toimintasuunnitelma ja suunnitellaan arvioinnin tuottamien tietojen pohjalta - hoidon/ palvelun toteutus ohjaa asiakkaalle/potilaalle annettavaa hoito- tai tutkimuspalveluja ottamalla pyynnön vastaan, varaamalla palvelun toteuttamiselle ajan, ohjaamalla oikean palvelun toteutukseen sekä kirjaamalla ja julkaisemalla palvelun/ hoidon tulokset - palvelun suoritus palvelun suorituksen ohjaus, aluksi selvitetään palvelu, joka toteuttaa esitetyn pyynnön ja lähetetään toimeksianto itse palvelulle sekä kirjataan ja julkaistaan tulokset - palvelun hakupalvelu palvelun suorituksen ohjaus hallitsee myös sen, mitä palvelua missäkin tilanteessa kutsutaan etsimällä palvelun/ tutkimuksen toteuttavan palvelun - tutkimuspalvelu palvelun suorituksen ohjausprosessi kutsuu löytämäänsä palvelua (tässä tapauksessa tutkimuspalvelu) - yksilöintitunnustenmuodostaminen yksilöi kaikki syntyneet palvelutapahtumat ja tiedot, jotka syntyvät prosessin aikana - informointi ja ohjaus toteuttaa ja kirjaa asiakkaalle/ potilaalle annetut informoinnit ja ohjaukset

28 Kuva x. Hoidon ja hoivan yleisen tason prosessimalli NI-hankkeessa kuvattuna (SSS 2010) Sosiaali- ja terveyshuollon palvelujen liittymäkohtia Seuraavassa on kuvattu sosiaali- ja terveydenhuollon liittymäkohdat kotipalveluiden palvelutehtävässä, jossa kotipalveluprosessin ja terveydenhuollon yleisen hoitoprosessin, tässä tapauksessa kotisairaanhoidon kesken. Kuva x: Lähde THL 3.4 Kerrosarkkitehtuuri ja modulaarisuus Nykyisten olemassa olevien järjestelmien kokonaisuus rakentuu vahvasti kerrosarkkitehtuurin kautta. Modulaarinen järjestelmäkokonaisuus ei lokeroi palveluja eri kerroksiin, vaan tekee niistä keskenään yhteensopivia, ja mukautuu muuttuviin tarpeisiin perinteistä joustavammin. Tällä tarkoitetaan sitä, että

29 tarkoituksenmukainen moduulirakenne voi sisältää toimintoja useista perinteisen kerrosarkkitehtuurin osista. Kerroksellisuus voidaan tunnistaa ja eri kerrosten kehittämistä voidaan tehdä irrallaan muista, sekä siten muun muassa vähentää teknologisia riippuvuuksia: Yhtenäinen käyttäjäkokemus kootaan eri moduuleista käyttöliittymäkerroksen mukautettavuudella, käyttöliittymät ja näkymät on mahdollista toteuttaa aina kulloiseenkin käyttötarpeeseen sopivaksi. Toiminnallisuuksien koostaminen toteutuu modulaarisuuden kautta ja moduulit pystyvät käyttämään hyväkseen toistensa toiminnallisuutta avoimesti ja hyödyntää yhteistä tietoa joustavasti. Useita moduuleita voidaan hankkia ja käyttää yhdessä toteuttamaan monimutkaisempia toimenpiteitä. Käyttäjän näkymä voidaan toteuttaa kunkin tilanteen vaatiman toiminnallisuuden ja olennaisen käytettävän tiedon yhdistelmänä. Keskitetyt tiedonhallinnan ratkaisut huolehtivat pääosin tietojen saatavuudesta ja säilyttämisestä. 3.5 Tiedonhallinta modulaarisessa arkkitehtuurissa Dynaaminen tietomalli Ytimen tiedonhallinnalta vaaditaan dynaamisten tietorakenteiden tukea, kykyä yhdistä eri järjestelmissä olevia tietoja osaksi kokonaistoiminnallisuutta, hallita tietoa erilaisilla metatiedoilla ja yhdistää eri lähteistä tulevaa tietoa. Dynaamisen tietomallin perustana on tietorakenteiden dynaaminen hallinta siten, että tietoa pystytään kokoamaan eri tietomalleista ajantasaisesti. Dynaaminen tietomalli käyttää hyödyksi älykkäitä rajapintoja. Dynaamisen tietomallin avulla saadaan aikaan tilanne, jolla voidaan yhdistää tietoja eri tietovarannoista. Tietojärjestelmän asiakastietomalli Å+å+ 1 Tietojärjestelmän asiakastietomalli 2 Tietojärjestelmän asiakastietomalli 3 Tietojärjestelmän asiakastietomalli 4 Modulaarinen asiakastietomalli Å+å+ 1 Modulaarinen asiakastietomalli 2 Modulaarinen asiakastietomalli 3 Modulaarinen asiakastietomalli 4 Dynaaminen tietomalli - tietorakenteet YDIN Asiakkuustiedot Tietovaranto

30 3.5.2 Tietovarannot UNA-arkkitehtuurissa ydin on looginen tietovaranto, joka tukee järjestelmäkokonaisuuden tiedon operatiivista yhteiskäyttöä. Looginen tietovaranto ei tarkoita, että sen sisältämät tiedot on fyysisesti keskitetty, vaan järjestelmäkokonaisuus hyödyntää kattavasti mm. kansallisia tietovarantoja. Sosiaali- ja terveydenhuollon osalta Kanta-palveluiden potilastiedon arkisto ja sosiaalihuollon asiakastiedon arkisto ovat ainoat ratkaisut säilyttää sosiaali- tai terveydenhuollon asiakastyössä syntyneitä ja syntyviä pysyvästi säilytettäviä sähköisiä asiakas- ja potilastietoja. Operatiivisena tietovarantona Kanta-palvelu toimii vähintään niiden tietojen osalta, jotka ovat vaiheistusasetukseen määriteltyjä. UNA-ytimellä tulee olla pääsy kaikkiin asiakasprosessin kannalta oleellisiin tietovarantoihin, jotka voivat olla hajautettuna. Niitä ovat keskeisimpinä julkishallinnon yhteiset tietoihin (kuten väestörekisterin ylläpitämät henkilötiedot), sosiaali- ja terveydenhuollon yhteiset tietoisiin (Kanta-palvelut, koodistot, jne.). Arkkitehtuurinäkökulmasta looginen tietovaranto kattaa yhteisesti hallinnoidun joukon tietoja, joista muodostuu looginen kokonaisuus. Keskeistä on, että tietojen hallinta on organisoitu ja kunkin tiedon osalta pääasiallinen tiedonhallinta vastuutettu yhdelle toimijalle. Arkkitehtuuriperiaatteisiin pohjautuen operatiivisen tiedon hallinnan kannalta loogisen tietovarannon tulee olla järjestelmätoimittajariippumaton. On keskeistä, että tietovarantoja hyödynnetään SOTE-johtamisen tietotarpeisiin, väestön hyvinvointitietojen ja asiakkuuksien analysointiin ja koostamiseen. Raportoinnin ja johtamisen tarpeisiin hyödynnetään tiedon toissijaisen käytön viitearkkitehtuuria. Tiedon toissijainen käyttö on erilaisiin tietovarantoihin talletetun tiedon hyödyntämistä sote-toiminnan arvioinnissa, seurannassa ja kehittämisessä sekä tutkimuksessa. Strukturoidun tiedon rinnalle on tullut vaatimus vapaamuotoisena tallennetun tiedon hyödyntämisestä tiedon toisiokäytössä prosessoimalla tietoa erilaisilla menetelmillä. Vaatimus kattavasta rakenteisuudesta tiedon tallennusvaiheessa ei enää ole välttämätön tiedon hyödyntämisen (esim. Big Data) kannalta. Strukturoimaton data saa rakenteen vasta analysointivaiheessa (schema-on-read), kun erityyppisille sisällöille haetaan yhdistäviä tekijöitä ja toistuvia malleja erilaisia algoritmeja käyttäen. Tiedon toissijaisen käytön ratkaisuissa tullaan jatkossa käyttämään eri tietokerrosten virtuaaliratkaisuja Tietovirrat Keskeiset tietovirrat kulkevat lähtökohtaisesti ytimen järjestelmäpalvelujen kautta. Modulaarisessa ratkaisussa tietovirrat eri vyöhykkeille (tieto-, prosessi- ja sanomatasolla) on mahdollista toteuttaa moduulien välillä tai ytimen kautta riippuen siitä, miten kyvykäs moduuli on tiedonvälittämiseen. Ytimen tietovaranto ja järjestelmäpalvelut synkronoivat tiedot Kanta-palveluun, mm. pysyväissäilytystä varten. Operatiivisen tiedon osalta UNA-ytimen tietovirrat tulee toteuttaa niin, että hyödynnetään Kantapalvelujen tarjoamia tietopalveluja. Päällekkäisiä tietovirtaratkaisuja ei tule toteuttaa Kanta-palvelujen tarjoamien palvelujen sijaan. Kanta-palvelut tulevat laajenemaan ja toiminnanohjauksia elementtejä ollaan kehittämässä avohoidon lääkityksen, kansalaisen omatietovarannon tietojen, toiminnallisen lähete-palaute järjestelmän osalta. Vaiheistusasetuksen mukaisten sekä edellä mainittujen tietosisältöjen lisäksi Kanta-palveluilla pyritään

31 tukemaan operatiivista ja ajantasaista tiedon saatavuutta, jolloin tietovirtojen näkökulmasta on keskeistä huomioida tiedon tallennuksen viiveettömyys ja varsinkin tiedon saatavuus hoitovastuun siirtojen yhteydessä. Teknisesti tietovirrat toteuttavat avoimiin standardeihin perustuvia dynaamisia tietomalleja. Tietovirroissa hyödynnetään yleisimpiä, viimeisimpiä ja moderneja teknologioita, kuten Kanta HL7v3, HL7 FHIR, IHE XDS & MHD, DICOMWeb ja Smart on FHIR. 3.6 Arkkitehtuurivaatimukset Arkkitehtuurivaatimukset ovat esim. hankinnan tai kehittämisen kriteerejä ja tarkennetaan vielä yksityiskohtaisesti kunkin kilpailutuksen yhteydessä. Vaatimukset kohdennetaan tarvittavan tietojärjestelmän ominaisuuksiin tai kyvykkyyteen. Yleiset arkkitehtuurivaatimukset Järjestelmäkokonaisuuden lainmukaisuus Kaikkien järjestelmäkokonaisuuden osien tulee olla toteutettu siten, että se täyttää järjestelmälle Suomen laissa asetetut tietosuoja- ja tietoturvallisuusvaatimukset sekä Suomen sosiaali- ja terveydenhuoltoa koskevaa lainsäädäntöä. Järjestelmäkokonaisuuden toimintojen on tuettava tietoaineistojen säilytyksen ja hävittämisen osalta sosiaali- ja terveydenhuollolle asetettuja säilytysaikavaatimuksia (mm. potilastieto tai käyttöloki). Järjestelmäkokonaisuus hyödyntää kattavasti kansallisia palveluita ja tietovarantoja Järjestelmäkokonaisuus hyödyntää kattavasti ja aktiivisesti kansallisia palveluita ja tietovarantoja. Päällekkäisyyttä kansallisesti keskitettävien palvelujen kanssa vältetään, mikäli se ei toiminnan kriittisyyden tai muun perustellun syyn takia tarpeen. (pohdittava, miten kriittisyys arvioidaan?) Järjestelmäkokonaisuus täyttää kansallisten palveluiden (Kanta-palvelut) hyödyntämistä koskevat vaatimukset Järjestelmäkokonaisuus kytketään KanTa- palveluihin lainsäädännön, KanTa-määritysten ja kansallisten auditointivaatimusten mukaisesti. Sosiaali- ja terveydenhuollon asiakastietojen käsittelyssä käytettävän tietojärjestelmän tulee täyttää yhteentoimivuutta, tietoturvaa ja tietosuojaa sekä toiminnallisuutta koskevat olennaiset vaatimukset (nykyisellään asiakastietolain 19 a :n mukaisesti). Kanta-palveluihin liitettävien järjestelmien tietoturvallisuuden ja yhteentoimivuuden vaatimukset on määritelty tarkemmin Kelan yhteistestauksen ja tietoturvallisuuden auditoinnin vaatimusten kautta. Kansallisiin palveluihin ja tietovarantoihin kytkeydytään ytimen palvelujen kautta Alueellisen järjestelmäkokonaisuuden ulkoiset yhteydet kansallisiin palveluihin ja tietovarantoihin toteutetaan keskitettyjen tiedonhallintapalvelujen (ytimen moduuli) kautta. Arkkitehtuuriperiaatteiden ja linjausten mukaisuus Arkkitehtuuriperiaatteet linjaavat tavoitetilaa kohti etenemistä, ja arkkitehtuurilinjaukset ohjaavat käytännön toimenpiteiden toteuttamista. Modulaarisuus Moduulit ovat itsenäisiä tietojärjestelmäkomponentteja, joita voidaan käyttöönottaa tai korvata yksittäisinä kokonaisuuksina. Moduulit toteuttavat ja tarjoavat muiden käyttöön tietojärjestelmäpalveluja. Tietojärjestelmäpalvelulla tarkoitetaan ulospäin näkyvää toiminnallisuutta, joka voi sisältää oman käyttöliittymän tai olla muille moduuleille näkyvä palvelu, josta kokonaisuus

32 muodostuu. Modulaarisuus ratkaistaan toiminnallisista kokonaisuuksista pohjautuen toiminnallisiin määrittelyihin. Tiedon kirjaaminen vain yhteen kertaan Asiakasta ja palvelua koskeva tieto kirjataan vain kerran rakenteellisessa muodossa palveluun luontevalla hetkellä. Tiedonkäsittelyn keskeytyessä kesken tallennuksen jo täytettyjen tietojen tulee säilyä ja olla käytettävissä. Avoimet rajapinnat Järjestelmäkokonaisuuteen toteutetaan kattavat avoimet ja dokumentoidut rajapinnat, joiden avulla tallennettua tietoa ja toimintoja voidaan hallitusti ja helposti kytkeä erilaisiin asiakasprosesseihin. Rajapinnoista tilaaja saa lähdekoodin, tarvittavat ohjeet ja koulutuksen rajapinnan käyttöön sekä oikeuden tehdä itse tai teettää muutostöitä vapaasti haluamallaan toimittajalla Rajapintojen dokumentointi Järjestelmän rajapinnat ovat dokumentoitu uudelleenkäytettävyyttä varten. Dokumentaatio on asiakkaan saatavissa ja hyödynnettävissä. Rajapintojen hyödyntäminen Asiakas saa käyttää järjestelmän rajapintaa ilman erilliskorvausta (tiedon siirtäminen tai palvelurajapinnan käyttäminen). Hallittava kokonaisuus Järjestelmäkokonaisuus on hallittava kokonaisuus, jonka eri osien ylläpidettävyys ja päivitettävyys voidaan hoitaa keskitetysti. Keskitetty pääsyn- ja käyttövaltuuksien hallinta Pääsyn- ja käyttövaltuuksien hallinnan osalta vyöhykkeen ratkaisut tukeutuvat keskitettyyn ratkaisuun. Integraatiot Modulaarisessa arkkitehtuurissa moduulien keskinäisessä kommunikoinnissa hyödynnetään keveitä mekanismeja (esim. rest-rajapintoja ja FHIR), jolloin moduulit toteuttavat yhdessä halutut toiminnot. Järjestelmäkokonaisuuden integraatioiden hallinnassa hyödynnetään keskitettyä integraatioratkaisua. Ytimen vaatimukset Ydin vastaa keskeisten tietojen tiedonhallinnasta Keskitetyt tiedonhallinnan ratkaisut huolehtivat tiedon ajantasaisesta saatavuudesta, luotettavuudesta, eheydestä ja säilyttämisestä tietoturvallisesti. Ydin hallinnoi keskeisiä tietoja (esim. henkilötiedot, suunnitelmat) ja tarjoaa niiden käsittelyyn tarvittavat palvelut rajapintojen kautta. Mikäli tieto ei ole säilöttynä ytimessä, ytimen tiedonhallinta sisältää tiedon, mistä tiedot löytyvät ja miten ovat käsiteltävissä. Dynaaminen tiedonhallinta Tiedon jäsentely toteutetaan dynaamisesti, joka tarkoittaa kykyä yhdistää eri lähteistä tulevaa tietoa kokonaisuudeksi, sekä hallita tietoa erilaisilla metatiedoilla. Tietorakenteiden dynaamisuus kokoaa eri tietomalleista ajantasaisesti yhteen. Tiedon avoimuus Järjestelmäkokonaisuuteen tallennettu tieto on keskitettyjen tiedonhallintapalveluista (ydin) kaikkien järjestelmäkokonaisuuteen liittyvien toiminnallisuuksien käytössä avoimien ja dokumentoitujen rajapintojen kautta. Keskeiset toiminnallisuudet ytimessä

33 Ydin sisältää järjestelmäkokonaisuuden keskeisimmät ominaisuudet ja kattavat rajapinnat uusien toimintojen ja ominaisuuksien lisäämiselle. Ydin tarjoaa moduuleille keskeiset yhteiset ratkaisut ja järjestelmäpalvelut, jotka toteutetaan järjestelmäkokonaisuuteen vain kertaalleen. Toiminnallisten moduulien vaatimukset Itsenäiset moduulit Moduulit ovat itsenäisiä, eikä yksittäisen moduulin häiriö tai pysähtyminen saa lamauttaa koko järjestelmäkokonaisuutta. Kyky hyödyntää ytimen tiedonhallintaan Moduulit käyttävät hyödyksi keskeisiä yhteisiä ratkaisuja ja järjestelmäpalveluja. Moduuleilla tulee olla kyky hyödyntää ytimen tiedonhallintaa. Integraatiot Moduulit käyttävät keskinäiseen kommunikointiinsa keveitä mekanismeja, kuten rest-rajapintoja ja voivat toteuttaa yhdessä käyttäjän tarvitsemat toiminnot.

34 4 Esimerkkejä UNA-modulaarisuuden toteuttamisesta 4.1 Johdanto Modulaarinen arkkitehtuuri ei yksistään määrittele toteutuksen tapaa seuraavan sukupolven järjestelmäratkaisuksi. Järjestelmäuudistuksen lähtökohtana tulee aina olla toiminnalliset tarpeet, joita toteutetaan organisaatioiden hallitseminen palveluprosessien kehittymisen myötä. UNA-modulaarisen arkkitehtuurin ensimmäisen toteutuksen (ns. UNA-Ydin) tulee mahdollistaa ns. UNAvyöhykkeille toteutettavat palvelut. Ytimen ensimmäisen vaiheen toteuttamisen myötä olemassa olevia järjestelmiä voidaan korvata vaiheittain ja tarvittavilta osin voidaan olemassa olevat järjestelmät päivittää ns. vyöhykkeille (kyvykkäiksi hyödyntämään ytimen hallitsemia tietoja). UNA-arkkitehtuurin toteuttamista voidaan havainnollistaa esimerkein, joilla voidaan vaiheistaa kokonaiskuvaa siirtymästä (migraatiosta). Migraation tavoitteena on kustannustehokas ja toiminnallisesti mahdollinen siirtyminen nykytilasta tulevaisuuden tietojärjestelmäratkaisuun. Esimerkeissä on jaoteltu mahdollista ratkaisun toteuttamisen vaiheistusta UNA-toiminnallisten tavoitetilakuvausten perusteella: - Yhteisiin toiminnallisuuksiin - Mastertietoihin - Potilas- ja asiakastietoihin - Asiakkuudenhallintaan - Prosessiohjaukseen - Toiminnan- ja tuotannonohjaukseen 4.2 Esimerkki toteuttamisen vaiheistuksesta Näissä esimerkeissä ytimen toteutuksen toiminnallisuudet on luokiteltu siitä lähtökohdasta, että pystytään kuvaamaan keskeisten toiminnallisuuksien toteuttamista ja ytimen rakenteen sisältöä vaiheittain. Alla luetellut keskeiset toiminnallisuudet on avattu tarkemmalle tasolle, jotta pystytään arvioimaan tarkemmin toiminnallisuuden sisältöä ja mahdollisia tehtäviä sekä niiden pohjalta rakentamisen vaiheistusta. Esimerkkien avulla voidaan luoda kuvaa erilaisten toiminnallisuuksien toteutumisen vaiheista. Tämän avulla voidaan arvioida muutoksen järjestystä, suuruutta ja mahdollisen migraation tarvetta.. (Luettelo ei ole tarkka kuvaus järjestelmänpalveluista tai niiden sisällöstä). Yhteiset toiminnallisuudet: - Pääsynhallinta - UNA-rajapinnat - Kanta-integraatiot - KAPA-palvelut - Käyttöliittymien koostaminen Mastertiedot: - Hinnastojen ja tuotteiden hallinta - Sopimusten hallinta - Materiaali- ja resurssitiedot

35 - Ostopalvelujen sopimukset - Asiakaspolkumallit Potilas/asiakastiedot - Kantatietojen koostaminen - TH-tapahtumien hallinta - SO-tapahtumien hallinta Asiakkuudenhallinta - Asiakkuuden tiedot - Asiakassegmentaatio - Suunnitelmatiedot - Hyvinvointitiedot - Tietopyynnöt Prosessiohjaus - Palvelupolunhallinta - Palveluiden ohjaaminen - Ajanvaraus - Palvelutapahtuminen hallinta - Oper. Tilannekuva, resurssointi - Kustannuseuranta Toiminnan- ja tuotannon ohjaus: - Palvelupolun ohjaus - Tuotantoprosessien ohjaus - Palvelutarpeen hallinta - Laadunvalvonta - Resurssienhallinta

36 4.2.1 Esimerkki toteuttamisen vaiheistuksesta, asiakkuudenhallinnan ydin Alla on esimerkkikuvaus yllä listattujen tietojärjestelmäpalvelujen vaiheistuksesta (asiakkuushallinta): Tämän vaihtoehdon sisällä asiakkuudenhallinnan keskeinen toiminnallisuus rakentuu ytimeen. Asiakkuudenhallinnan tehtävänä on tarkastella asiakkaan hyvinvointiin liittyviä ja siihen vaikuttavia tietoja kokonaisuutena. Asiakkuudenhallinnan toiminnallinen kokonaisuus muodostuu toiminnallisista määrittelyistä tunnistetuista osakokonaisuuksista. Osakokonaisuudet sisältävät asiakkuuteen liittyviä tietoa. Asiakkuudenhallinnan osakokonaisuuksien sisältöjä: Asiakassegmenteillä tarkoitetaan erilaisia asiakasryhmiä, joilla on samanlaiset tai yhtenevät palvelutarpeet. Asiakkaat voidaan jakaa monilla eri tavoilla segmentteihin. Asiakkuustiedonhallinta pitää sisällään erilaisia asiakkaaseen liittyviä yleisiä asiakkaan tunnistamiseen ja asiointiin liittyvien tietojen sekä asiakkaan läheisiin ja edustajiin liittyviä tietoja, suostumuksia ja kieltoja sekä valtuuttamista koskevien tietojen hallintaa. Suunnitelmien hallinnan avulla mahdollistetaan asiakkaan hyvinvointiin liittyvien suunnitelmien (esimerkiksi yhteinen palvelusuunnitelma, hoito- ja palvelusuunnitelma, asiakassuunnitelma, kuntoutussuunnitelma, jne.) tekeminen, muokkaaminen ja päivittäminen asiakkaan hyvinvointiin osallistuvien toimijoiden kesken. Hyvinvointitietojenhallinta pitää sisällään erilaisia asiakkaaseen liittyviä hyvinvoinnin tilannetietoja, tietopyyntöjä ja tietojen luovutuksia, asiakkaan informointi, asiakkuudentilan reaaliaikainen seuranta Asiakkuudenhallinnan rakentamisella ytimeen syntyy modulaarisen arkkitehtuurin mukainen järjestelmäpalvelu, joka tukee asiakas keskiössä lähtökohtaa. Tämän esimerkkiratkaisun tarkoituksena on tukea hoitoprosesseja asiakkaan näkökulmasta ja mahdollistaa helpommin rakentuvia asiakasohjautuvia palveluja. Tässä ratkaisussa olemassa olevien järjestelmien siirtymävaiheessa (migraatiossa) käsiteltävän tiedon määrä on pienempi (=asiakkuudenhallinnan tiedot kuin vastaavasti kaikki toiminnanohjaustiedot.)

37 Ytimen rakentuminen asiakkuudenhallinnan toiminnallisuuden lähtökohdista muodostaa ytimen, jossa ovat asiakkuustiedot ja asiakkaanhallinnan kannalta oleellinen toiminnallisuus. Tässä esimerkissä prosessitason integraatiokerrokselle rakentuu moduuleita, joilla tulee ketterästi rakentaa palvelupyyntöjen- ja tilaustenhallintaa. Tällaisia prosessitason integraatiokyvykkyyden ratkaisuja voisi olla esimerkiksi lähetteiden ja palautteiden hallinta.. Prosessitason integraatioon kyvykkäillä moduuleilla voidaan ketterästi ja joustavasti liittää eri palvelupyyntöjen ja tilausten hallintaan rakennettuja moduuleja toisiinsa siten, että ne tukevat erilaisia asiakasprosesseja (esimerkiksi jonkin sairaus- tai asiakasryhmäkohtaisen prosessin). Yhtälailla prosessitason integraatioon kyvykkäitä moduuleja voi rakentua tässä esimerkissä resurssienhallinnan, suunnittelun ja varaamisen toimintoihin. Alla kuva prosessitason integraatiokyvykkyyksistä asiakkuudenhallinnan ytimen omaavan tietojärjestelmäpalveluun (vyöhykkeelle 2): ESIMERKKI Käyttöliittymä + TOIMINNALLINEN KOKONAISUUS ESIMERKKI Asiakkuudenhallinta Asiakkuustiedot Tietomalli Tiedonhallinnan ratkaisu Integraatiokerros

38 4.2.2 Esimerkki toteuttamisen vaiheistuksesta, toiminnan- ja tuotannonohjauksen ydin Alla on esimerkkikuvaus yllä listattujen tietojärjestelmäpalvelujen vaiheistuksesta (toiminnanohjaus): Tämän vaihtoehdon sisällä tuotannon- ja toiminnanohjauksen toiminnallisuus rakentuu ytimeen. Toiminnanja tuotannonohjaukseen kuuluu toiminnan ja resurssien sekä palvelujen suunnittelu, seuranta ja ohjaus siten, että organisaation tai palvelukokonaisuuden tavoitteet voidaan saavuttaa luotettavasti ja turvallisesti optimikustannuksin. Toiminnanohjaus on kokonaisnimike eri tasoilla toteutuvasta ja eri kohteisiin kohdistuvasta ohjauksesta. Tuotannonohjaus on menettely, jolla palvelun toteuttaja ohjaa tuotantoaan, jotta ne pystyisivät täyttämään tilattujen tuotteiden/palveluiden toteuttamisen vaatimukset laadusta, määrästä ja toimitusajasta optimiresurssein. Tuotannonohjauksen keskeisiä piirteitä ovat resursointi, tuotantoprosessin siirtymien hallinta, työjonot, tilannekuvat sekä palvelun tehtävien hallinta esim. tarkistuslistat jne. Tuotannon- ja toiminnanohjauksen rakentuessa ytimeen muodostuu ratkaisu, jossa ytimen sisältö on toiminnallisuuksiltaan hyvin kattava ja vastaa lähes nykyisen potilastietojärjestelmätoiminnallisuuden mukaista ratkaisua. Tässä ratkaisussa siirtymävaihe(migraatio) voidaan tehdä vaiheittain ja rakentaminen voidaan tehdä yllä kuvatun vaiheistuksen mukaisesti, jolloin modulaarisuuden toteuttaminen pysyy helpommin tilaajan hallinnoimana. Toiminnallisesti ratkaisu on kattava ja mikäli rakentaminen tehdään yhdessä vaiheessa, lähestytään tilannetta, jossa nykyisten asiakas- ja potilastietojärjestelmien toteuttajien kaltaiset toimijat pystyisivät vastaamaan modulaariseen arkkitehtuurin mukaisiin toiminnallisuuksiin ns. valmisytimen mukaisella