Kohti kumppanuutta Viitearkkitehtuuri. KuntaIT Kohti kumppanuutta -hanke

Viitearkkitehtuuri KuntaIT Kohti kumppanuutta -hanke 7.5.2010

Viitearkkitehtuuri 2 (49) Sisällys Sisällys... 2 1. Johdanto... 3 1.1. Dokumentin tarkoitus... 3 1.2. Soveltamisalue... 3 2. Taustaa... 4 2.1. Kuntasektorin kokonaisarkkitehtuurimenetelmä ja sen hyödyntäminen... 4 2.2. Hankkeen yleiskuvaus... 5 2.3. Kohti kumppanuutta -ratkaisu... 6 3. Periaatetason arkkitehtuurilinjaukset... 7 3.1. Arkkitehtuuriperiaatteet... 7 3.2. Sidosarkkitehtuurit ja niiden hyödyntäminen... 8 3.2.1. SOA-arkkitehtuuriperiaatteet... 8 3.2.2. Terveydenhuollon kansallinen tietotekniikka-arkkitehtuuri... 10 3.2.3. Sosiaalihuollon kansallinen tietotekniikka-arkkitehtuuri... 11 3.2.4. Sähköinen asianhallinta ja arkistointi... 14 3.3. Muut yleiset sidosarkkitehtuurit ja linjaukset... 15 3.4. Tietoturva ja tietosuoja kasvatuskumppanuuden palveluissa... 16 4. Käsitteellisen tason arkkitehtuuri... 19 4.1. Kasvatuskumppanuuteen liittyvät keskeiset roolit... 19 4.2. Lapsen kasvamisen elinkaareen liittyvät palvelut... 20 4.3. Käsitteistö... 20 5. Loogisen tason arkkitehtuuri... 20 5.1. Prosessit... 20 5.2. Tietomallinnus... 20 5.2.1. ISO OID määritys... 21 5.3. Tietojärjestelmäpalveluiden looginen jäsennys... 23 5.3.1. Kuntasektorin tietojärjestelmäpalveluiden jäsennys... 23 5.3.2. Kohti kumppanuutta ratkaisun pääjäsennys... 27 5.3.3. Kasvun ja kehityksen suunnitelman hallinta... 28 5.3.4. Perhe- ja yhteisötietojen hallinta... 29 5.3.5. Tiedonluovutusvaltuuksien hallinta... 30 5.3.6. Käyttäjäviestintä... 33 5.3.7. Hakeminen kunnan palveluun... 34 5.3.8. Ajanvarausten hallinta... 34 5.3.9. Tapahtumaloki... 35 5.3.10. Sähköisen asianhallinnan liittäminen Kohti Kumppanuutta ratkaisuun... 37 5.3.11. Asiakastiedon päätietovaranto... 40 5.4. SOA-palvelut... 41 5.5. Integraatioperiaatteet... 41 5.6. Valvonta ja hallinta... 41 5.6.1. Valvonnan ja hallinnan yleiset periaatteet... 41 5.6.2. Valvonnan teknologia-arkkitehtuuri... 42

Viitearkkitehtuuri 3 (49) 5.6.3. Valvottavat kohteet... 43 5.6.4. Saatavuus, huolto- ja tukivaatimukset... 44 6. Fyysisen tason arkkitehtuuri... 44 6.1. Järjestelmien nykytila-arvio... 44 6.2. Liittymät... 44 6.3. Koodistot hyvinvointipalveluissa... 46 7. Käyttötapaukset... 47 8. Vaatimukset... 47 9. Liitteet... 48 1. Johdanto 1.1. Dokumentin tarkoitus Tässä dokumentissa kuvataan Kohti kumppanuutta -ratkaisun viitearkkitehtuuri hyödyntäen kuntasektorin kokonaisarkkitehtuurimenetelmää. Tämä kattodokumentti toimii koostedokumenttina yksityiskohtaisemmille, pääsääntöisesti liitteisiin kootuille kuvauksille. Tämä dokumentti on laajennus ja täsmennys aikaisemmin laaditulle Kohti kumppanuutta - kokonaisarkkitehtuurin yleiskuvalle (esiselvitystuotos) ja korvaa kyseisen tuotoksen. Esiselvitysvaiheessa tuotetut kuntasektorin kokonaisarkkitehtuurimenetelmän kuvauspohjan mukaiset arkkitehtuuritaulukot on liitetty Liitteeseen 9, KA-taulukot. Koska tässä olevia tietoja on tarkennettu tätä aikaisemmissa liitteissä, liitettä 9 tulee pitää suunnittelua ja toteutusta ohjaavana siltä osin, kun se ei ole ristiriidassa tämän päädokumentin ja liitteiden 1-8 kanssa. 1.2. Soveltamisalue Tämä kuvaus toimii lapsen ja nuoren palveluiden Kohti kumppanuutta - ratkaisukokonaisuuden toiminnallisen ja teknisen palveluympäristön kehittämisen viitearkkitehtuurina. Tätä kuvausta on tarkoitus hyödyntää Kohti kumppanuutta -ratkaisun toteutuksen pohjana. Tämä kuvaus on kuvattu KA-menetelmän periaatteellisella, käsitteellisellä ja loogisella tasolla. Varsinaisessa toteutuksessa tätä arkkitehtuurikuvausta tulee täsmentää tietojärjestelmän toteutuksen edellyttämällä tarkennetulla suunnitteluvaiheella.

2. Taustaa Kohti kumppanuutta Viitearkkitehtuuri 4 (49) 2.1. Kuntasektorin kokonaisarkkitehtuurimenetelmä ja sen hyödyntäminen Kuntasektorilla kokonaisarkkitehtuurilla (KA) tarkoitetaan toiminnan, tietotarpeiden, tietojärjestelmien ja teknologiaratkaisujen yhtenäistä mallintamista, kuvaamista ja suunnittelemista yhtenäisen mallin mukaisesti. Kokonaisarkkitehtuuri varmistaa eri osa-alueiden ja erityisesti toiminnan tarpeiden yhdenmukaisen huomioimisen kaikessa toiminnan ja ICT 1 -ratkaisujen kehittämisessä. Käytännössä kokonaisarkkitehtuuri koostuu jäsennyksestä, kuvauspohjista ja näiden avulla toteutetuista arkkitehtuurilinjauksista. Kokonaisarkkitehtuurin tavoitetilan avulla voidaan luoda toiminnallis-tekninen ympäristö, jossa kaikki osat sopivat toisiinsa, keskeiset komponentit toteutetaan vain kerran ja joka on hallittavissa ja muunneltavissa toiminnan muuttuvien tarpeiden mukaan. Kuntasektorin kokonaisarkkitehtuurimenetelmässä halutaan varmistaa, että teknisiä ja järjestelmäratkaisuja kehitettäessä otetaan laajasti huomioon toimivan sähköisen palveluympäristön erilaiset tarpeet - näkökulmat. Samoin kokonaisarkkitehtuurimenetelmä on haluttu jakaa käsitteellisiin tasoihin, joiden avulla parannetaan yksittäisten kuvausten jäsentymistä eri tarkkuustasoihin. Kuntasektorin kokonaisarkkitehtuurimenetelmän näkökulmat ja käsitteelliset tasot muodostavat eräänlaisen matriisin, johon yksittäisiä osakuvauksia voidaan sijoittaa. Kohti Kumppanuutta ratkaisun viitearkkitehtuurissa on kuvattu erityisesti seuraavat oranssilla merkityt osakuvaukset: 1 Suomennetaan usein tieto- ja viestintätekniikaksi (TVT)

Viitearkkitehtuuri 5 (49) Periaatteellinen taso - MIKSI Arkkitehtuuriperiaatteet Sidosarkkitehtuurit, rajaukset ja reunaehdot Tietoturvatarpeet ja -periaatteet SOA-linjaukset Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Strategia Käsitemalli Tietojärjestelmäpalvelut Teknologiapalvelut Käsitteellinen taso - MITÄ Palvelut Sidosryhmät, roolit Palvelut-käsitteet - matriisi Looginen Taso - MITEN Prosessikartta Prosessikuvaukset Prosessit-tiedot matriisi Tietomallit Loogiset tietovarannot Looginen järjestelmäjäsennys Järjestelmät-tiedot matriisi Järjestelmät-prosessit matriisi Integraatioperiaatteet (sis. liittymät) Teknologiakomponentit Valvonta- ja hallintaarkkitehtuuri Integraatioratkaisut (sis. rajapinnat) Fyysinen taso - MILLÄ Fyysiset tietovarannot Sanastot Fyys. järjestelmäsalkku Sijoituskaavio Verkkokaavio Teknologiasalkku Standardit Kuva 1. Viitearkkitehtuurissa käsitellyt kokonaisarkkitehtuurin alueet Vaaleamman keltaisesta fyysisestä järjestelmäsalkusta on kuvattu lähinnä nykyjärjestelmäsalkku sekä analyysi niiden liityntämahdollisuuksista. Käytännössä kokonaisarkkitehtuuri sisältää yllä kuvatun jäsennyksen lisäksi yksittäiset konkreettiset kuvauspohjat, joita ovat yllä olevan kuvan tekstillä varustetut laatikot. Näitä yksittäisiä kuvauksia kutsutaan myös osakuvauksiksi ja yhdessä ne muodostavat kokonaisarkkitehtuurikuvauksen joko tavoitetilasta tai nykytilasta. 2.2. Hankkeen yleiskuvaus Kohti kumppanuutta viitearkkitehtuuri ja sen perusteella toteutettava järjestelmäkokonaisuus muodostavat keskeisen osan laajempaa Kohti kumppanuutta -hanketta. Tampereen kaupungin omistama ja KuntaIT:n kehittämistoimintaan kuuluva valtakunnallinen Kohti kumppanuutta - lapsiperheiden rajattomat palvelut -hanke käynnistyi 1.12.2008. Hankkeeseen osallistuvat Tampereen lisäksi Espoon, Kuopion, Lahden, Oulun ja Salon kaupungit seutualueineen, opetusministeriö, sosiaali- ja terveysministeriö sekä valtiovarainministeriö. Kohti kumppanuutta -hanke päättyy joulukuussa 2010. Hankkeen tavoitteena on toteuttaa asiakaslähtöistä, vuorovaikutusta ja kasvatuskumppanuutta tukeva palvelu- ja asiointikokonaisuus. Palvelukokonaisuuden avulla saadaan eheytettyä sosiaali-, terveys- ja opetustoimen kesken sektoroitunutta palvelutuotantoa lapsiperheen ja kasvamisen kaaren näkökulmasta. Tämä mahdollistaa asiakkaan osallistumisen itseään koskevan palvelun toteuttamiseen ja kehittämiseen sekä luo edellytyksiä uusille prosessimaisille tavoil-

Viitearkkitehtuuri 6 (49) le tehdä yhteistyötä eri organisaatioiden välillä. Eheytetty palvelutuotanto tuo lisäksi kustannussäästöjä palvelutuotannolle ja yhtenäistää palveluprosessien toteuttamista, seurantaa ja raportointia sekä tarpeiden ennakointia. Tavoitetilassa lapsiperheiden kaikki hyvinvointipalvelut avautuvat kohderyhmälle saumattomana kokonaisuutena yhden palveluhistorian ja asiointipalvelun kautta. Tarkoituksena on kattaa palvelut syntymästä alkuopetuksen loppuun saakka: lastenneuvola päivähoito esiopetus perusopetus kouluterveydenhuolto palveluohjaus lapsiperheiden perus- ja tukipalveluihin Hankkeessa kuvataan keskeiset alle 9-vuotiaille lapsille ja heidän perheilleen suunnatut organisaatiorajat ylittävät palveluketjut ja nivelvaiheet sekä lapsen edun mukaisen tiedon kulun tarpeet. Hankkeessa myös määritellään palvelukokonaisuuden toteutukseen tarvittavat lainsäädäntöön liittyvät muutostarpeet. Kokonaisuudessa toteutetaan lapsen kasvun ja kehityksen suunnitelma, joka niveltää mm. varhaiskasvatus-, esiopetus-, oppimis- ja kuntoutussuunnitelmat toisiinsa. Palvelukokonaisuuteen sisällytetään keskeisiä lapselle tai hänen huoltajalleen sekä työntekijälle suunnattuja sähköisiä volyymipalveluja kuten hakemuksiin, ajanvarauksiin, ilmoittautumisiin, maksamiseen ja viranomaispäätöksiin liittyviä toimintoja hyödyntäen mahdollisimman paljon olemassa olevia ratkaisuja. Palvelujen toteutuksessa hyödynnetään palvelukeskeisen arkkitehtuurin mukaista (SOA) palvelualustaa sekä kuntasektorin kokonaisarkkitehtuurin periaatteita. Hankkeessa toteutetaan tekniset ja toiminnaliset peruspalvelut ko. kokonaisuudelle ja otetaan käyttöön niiden ydinosat. Toteutuksissa huomioidaan valtakunnallisesti toteutettavat integraatio- ja tukipalveluratkaisut. 2.3. Kohti kumppanuutta -ratkaisu Tässä dokumentissa ja muissa viitearkkitehtuuriin liittyvissä tuotoksissa Kohti kumppanuutta -ratkaisuksi kutsutaan hankkeen aikana kehitettävää järjestelmäkokonaisuutta, jolla toteutetaan hankkeen keskeiset tavoitteet. Kohti kumppanuutta palvelukokonaisuuden teknologinen ratkaisu toteutetaan monistettavana ja modulaarisena ratkaisukokonaisuutena, joka voidaan sovittaa ja ottaa käyttöön eri kunnissa. Kohti kumppanuutta teknologinen ratkaisu ei siis ole yksi valtakunnallinen palvelu, johon eri kunnat voivat liittyä. Kohti kumppanuutta ratkaisukokonaisuus tulee suunnitella siten, että siihen voidaan jatkossa liittää jo ensimmäisessä vaiheessa suunniteltavin periaattein kaikki lapsen ja nuoren kasvamiseen liittyvät palvelut ja erityisesti näiden tietotekniset ratkaisut.

Viitearkkitehtuuri 7 (49) Ensimmäisessä vaiheessa toteutetaan erityisesti tekninen ympäristö, jota tarvitaan 0-8-vuotiaan lapsen palveluketjun läpiviemiseen tehokkaasti ja turvallisesti. Tämä sisältää keskeisimmät liittymät yleisesti käytössä oleviin operatiivisiin järjestelmiin sekä keskeisimmät kunnan työntekijän ja asiakkaan sähköiset palvelut. 3. Periaatetason arkkitehtuurilinjaukset 3.1. Arkkitehtuuriperiaatteet Kohti kumppanuutta ratkaisun ja siihen liittyvien palvelujen keskeiset suunnittelun ja toteutuksen sekä jatkuvien palvelujen peruskivinä toimivat linjaukset on koottu seuraaviksi arkkitehtuuriperiaatteiksi: Nimi Prioriteetti Prioriteetti 1-5 Kuvaus SOA-periaatteiden hyödyntäminen 5 Palvelut suunnitellaan ja toteutetaan SOA-periaatteella mahdollistetaan saman tietojärjestelmän käyttö useisiin professioihin, palveluihin ja asiakkuuksiin Avoimet rajapinnat 5 Palvelukomponenttien rajapinnat ovat avoimet ja uudelleenkäytettävät Turvallinen ratkaisu 5 Järjestelmän on oltava turvallinen ja sen tietosuoja on vahva Ulkoisen raportoinnin tuki 4 Raportointiarkkitehtuurin tulee tukea ulkoista raportointiratkaisua (DW/BI-ratkaisu). Yhtenäinen käyttöliittymä 4 Samantapaiset toiminnat tulee saada koottua samankaltaiseen käyttöliittymään Tieto saataville 4 Palvelu tuottaa tarkoituksenmukaista tietoa asiantuntijoille, vanhemmille ja huoltajille lapsen kehittymisen ja oppimisen onnistumisesta koko kasvamisen kaaren ajalta myös vahvuuksista saadaan riittävästi tietoa Vanhemmuuden vahvistaminen 4 Järjestelmä tukee vanhemmuuden vahvistamista myönteisellä tiedolla Kasvamisen prosessin mukainen 4 Palveluiden lähtökohtana on asiakas ja asiakkaiden tarpeet. Ratkaisu tuottaa katkeamattoman kasvamisen näkymän Kustannustehokas palvelujen tuottaminen Joustava ja räätälöitävä, laajennettavissa 4 Päällekkäisyyksien poistaminen, tarpeettomien palvelujen poistaminen, palveluprosessien tehostaminen, asiakkaan "juoksuttaminen" vähenee 4 Ratkaisun tulee olla joustava sekä kuntien välillä että kunnan sisällä Yllä kuvatussa taulukossa arkkitehtuuriperiaatteita on listattu prioriteettiin 4 asti. Prioriteettien 2 ja 3 arkkitehtuuriperiaatteet on listattu Liitteeseen 9, KAtaulukot. Ratkaisu tulee siis suunnitella hyödyntäen SOA-periaatteita ja avoimia rajapintoja. Ratkaisuun suositellaan mahdollisuuksien mukaan käytettävän myös vapaasti lisensoitavan toteutusmallin (ks. vaatimukset) ratkaisuja, silloin kuin tämä on tarkoituksenmukaista ja mahdollista. Ratkaisu tulee toteuttaa siten, että uusien toimintojen lisenssi ja koodi on vapaasti myöhemmin koko kuntasektorin hyödynnettävissä, muokattavissa ja jatkokehitettävissä ilman lisäkorvausta. Tästä periaatteesta on kuvattu vaatimukset Liitteeseen 8, Vaatimukset.

Viitearkkitehtuuri 8 (49) 3.2. Sidosarkkitehtuurit ja niiden hyödyntäminen Kohti kumppanuutta ratkaisua ei toteuteta tyhjästä vaan siinä kootaan lähtötilanteessa hajallaan olevaa tietoa yhteen. Kohti kumppanuutta ratkaisua suunniteltaessa on otettava huomioon useita paikallisia ja kansallisia ratkaisumalleja. Seuraavaan on koottu keskeisimmät huomioitavat sidosarkkitehtuurit. Tietoarkkitehtuurin sidosratkaisuista koodistopalveluja käsitellään tarkemmin jäljempänä käsitemallin yhteydessä. 3.2.1. SOA-arkkitehtuuriperiaatteet Tampereen kaupunki on kuvannut kaupungissa hyödynnettävät keskeiset sähköisten palvelujen palvelukeskeisen arkkitehtuurin periaatteet. Tämä noudattelee yleisiä kuntasektorin SOA-arkkitehtuuriperiaatelinjauksia. Nämä tavoitetilan vaatimukset on kuvattu tarkemmin erilliseen dokumenttiin. Seuraavaan on koottu muutamia keskeisimpiä Tampereen kaupungin SOAarkkitehtuuriperiaatteita. Näitä hyviä periaatteita suositellaan hyödynnettävän myös muiden kaupunkien ratkaisuissa. Tampereen kaupunki kehittää sähköisiä palveluita palvelukeskeisen arkkitehtuurin SOA-periaatteiden mukaisesti. Tampereen SOA-periaatteiden keskiössä ovat sähköisesti saatavat palvelut, komponentit, jotka ovat näin järjestelmien toiminnan edellytys. Palvelukeskeisen arkkitehtuurin käyttö ei määrää käytettäviä standardeja teknologioita. Tämän sijaan SOA asettaa palveluille vaatimuksia. Keskeisiä vaatimuksia SOApalveluille ovat: Palveluiden pitää olla karkeustasoltaan erilaisia ja toisistaan koostettavissa Palvelulla pitää olla hyvin määritellyt ja standardeihin nojautuvat rajapinnat (rajapintaperiaatteet, erityisesti avoimet rajapinnat) Palveluiden tulee olla löyhästi kytkettyjä (integraatioperiaatteet) Palveluiden tulee olla helposti haettavissa (palvelukatalogi) Palveluiden tulee olla liiketoimintalähtöisiä (unohtamatta teknisessä ympäristössä välttämättömiä teknisiä tukipalveluita) Palveluiden tulee olla uudelleenkäytettäviä Tampereen kaupungin sähköiset palvelut pyritään toteuttamaan seuraavan teknologiapinon pohjalta:

Viitearkkitehtuuri 9 (49) Kuva 2. Tampereen kaupunki: SOA-teknologiapino SOA-teknologiapinossa jäsentely perustuu seuraavaan kerrosajatteluun: Kuva 3. Tampereen kaupunki / KuntaIT: palvelunohjauksen kerrosmalli Palvelukerrokset puolestaan ryhmittyvät luontevasti seuraavasti:

Viitearkkitehtuuri 10 (49) Kuva 4. Tampereen kaupunki / KuntaIT: palvelukerrokset Yllä olevaa kokonaisuutta tulee hyödyntää kehitettäessä Kohti kumppanuutta palveluja Tampereen kaupungissa. On huomattava, että kaikki Kohti kumppanuutta hankkeessa mukana olevat kunnat eivät ole tehneet samanlaisia SOA-periaatelinjauksia kuin Tampereen kaupunki. Kohti kumppanuutta ratkaisun komponentit tulee rakentaa siten, että ne soveltuvat mahdollisen monen kunnan tekniseen palveluympäristöön. Tärkeimmät missä tahansa kunnassa noudatettavat ratkaisuperiaatteet ovat: Uudelleenkäytettävyys Systemaattisuus Palvelevuus toiminnan näkökulmasta Yhteentoimivuus Joustavuus ja laajennettavuus 3.2.2. Terveydenhuollon kansallinen tietotekniikka-arkkitehtuuri Terveydenhuoltosektori on yksi keskeisistä osa-alueista Kohti kumppanuutta ratkaisussa. Erityisesti pyritään murtamaan terveydenhuollon ja esim. päivähoidon ja perusopetuksen raja-aitoja silloin, kun se on lapsen edun ja lainsäädännön puitteissa mahdollista. Lapsen terveydenhuoltotietoja tulee käsitellä tätä koskevan lainsäädännön sekä kansallisten arkkitehtuurilinjausten mukaisesti. Keskeisimmän terveydenhuollon kansallisen tietotekniikka-arkkitehtuurin muodostaa ns. kansallinen terveysarkisto (KanTa). Se on yhteinen nimitys terveydenhuollon uusille valtakunnallisille tietojärjestelmäpalveluille, joita ovat: eresepti ekatselu earkisto

Viitearkkitehtuuri 11 (49) Rakenteilla olevien KanTa-tietojärjestelmäpalveluiden tehtävänä on edistää hoidon jatkuvuutta ja potilasturvallisuutta sekä tehostaa terveydenhuollon palveluja. KanTa-palvelut tulevat julkisen ja yksityisen terveydenhuollon, apteekkien sekä kansalaisten käyttöön vaiheittain 1. huhtikuuta 2011 mennessä. Jatkossa terveydenhuollon tietoja voidaan järjestelmien ja terveydenhuollon toimijoiden välillä siirtää vain kansallisen palvelun kautta. Ratkaisu sisältää myös keskeiset piirteet kansallisesti keskitetystä terveydenhuollon tietojen suostumustenhallinnasta. Kohti kumppanuutta ratkaisussa tarvittava suostumustenhallinta tulee sovittaa yhteen terveydenhuollon kansallisen suostumuksenhallinnan kanssa siten, että toteutetaan mahdollisimman vähän päällekkäisiä ratkaisuja. KanTa-arkkitehtuurin dokumentit löytyvät Kanta-ratkaisun verkkosivuilta: http://www.kanta.fi/sub.html earkisto Sähköinen potilastietoarkisto (earkisto) tarjoaa terveydenhuollon organisaatioille mahdollisuuden tallentaa potilastiedot keskitettyyn arkistoon. Hoidon jatkuvuus ja laatu paranevat, kun potilaan tiedot ovat saatavilla yli organisaatiorajojen. Tämä on keskeisin Kohti kumppanuutta ratkaisussa hyödynnettävä palvelukokonaisuus siltä osin, kun potilastietoja on siirrettävä organisaatiosta toiseen. On huomattava, että yksittäisen potilastietojärjestelmän sisällä, kunnan sisäisten toimijoiden välillä tai ns. seudullisissa järjestelmissä tietoa ei välttämättä tarvitse siirtää kansallisen arkiston kautta erityisesti vielä hoidon ollessa kesken. Tällöinkin on kuitenkin huolehdittava suostumuksenhallinnasta näiden tietojen luovuttamiseen. Tätä ongelmakenttää on kuvattu tarkemmin Liitteessä 1, Kohti kumppanuutta, lakiselvitys. ekatselu ekatselu on kansalaisille tarkoitettu sähköinen palvelu, jossa he voivat internetin välityksellä katsella Reseptikeskuksessa ja sähköisessä potilastietoarkistossa olevia tietojaan. Katseluyhteyden kautta täysi-ikäinen henkilö saa halutessaan esimerkiksi yhteenvedon sähköisistä lääkemääräyksistään. eresepti eresepti on lääkärin laatima sähköinen lääkemääräys, jonka lääkäri allekirjoittaa sähköisesti ja tallentaa Reseptikeskukseen. Kun potilaan kaikki lääkemääräykset on tallennettu Reseptikeskukseen, lääkäri voi potilaan suostumuksella tarkistaa tämän kokonaislääkityksen ja ehkäistä lääkkeiden haitallisia yhteisvaikutuksia ja päällekkäisyyksiä. 3.2.3. Sosiaalihuollon kansallinen tietotekniikka-arkkitehtuuri Sosiaalihuollon kansallista tietotekniikka-arkkitehtuuria on kuvattu kansallisessa Tikesos-hankkeessa 2. Kohti kumppanuutta ratkaisussa tulee ottaa kokonaisuudessaan huomioon sosiaalihuollon kansallinen arkkitehtuuri. 2 www.tikesos.fi

Viitearkkitehtuuri 12 (49) Arkkitehtuuriin liittyvä kehittämistyö on määritelty sosiaalialan tietoteknologiahankkeen hankesuunnitelmassa vuosille 2008 2011. Työ on aloitettu vuoden 2008 alussa tietoarkkitehtuurin kuvauksella ja tietojärjestelmäarkkitehtuuria ryhdytään määrittelemään vuoden 2010 alussa. Arkkitehtuurin määrittelyssä hyödynnetään soveltuvin osin valtiohallinnon kokonaisarkkitehtuurimenetelmää, joka on kehitetty palvelemaan julkishallinnon toiminnan ja tietojärjestelmien suunnittelua. Kuntasektorin kokonaisarkkitehtuurimenetelmä on kehitetty valtionhallinnon kokonaisarkkitehtuurimenetelmän pohjalta. Kokonaisarkkitehtuurikehys kattaa neljä arkkitehtuurinäkökulmaa, joita ovat: toiminta-, tieto-, järjestelmä- ja teknologia-arkkitehtuuri. Tikesos-hankkeessa kuvataan sosiaalihuollon toimialakohtainen arkkitehtuuri yleisellä tasolla. Arkkitehtuurinäkökulmista työ keskittyy tieto- ja järjestelmäarkkitehtuurien kuvaamiseen. Toiminta- ja teknologia-arkkitehtuurien näkökulmista kuvauksia on laadittu ja laaditaan sen verran kuin tarvitaan tieto- ja järjestelmäarkkitehtuurisuunnittelun tueksi. Vuoden 2008 työssä kehittäminen ryhmiteltiin kolmeen osakokonaisuuteen: Sosiaalihuollon kansallisen arkkitehtuurin lähtökohdat ja tavoitetila Sosiaalihuollon kansallinen toiminta-arkkitehtuuri Sosiaalihuollon kansallinen tietoarkkitehtuuri Sosiaalihuollon kansallista arkkitehtuuria on saatu kuvattua eteenpäin kaikilla edellä listatuilla alueilla. Sosiaalihuollon kansallisen arkkitehtuurin lähtökohdat ja tavoitetila Arkkitehtuurin lähtökohdat ja tavoitetilan kehittämisessä on ollut kolme päätehtävää: Arkkitehtuurin reunaehtojen kuvaus. Reunaehdot muodostuvat sosiaalihuollon tiedonhallintaa ohjaavasta lainsäädännöstä, ohjeistuksesta ja strategisista linjauksista. Sosiaalihuollon arkkitehtuurin nykytilan kuvaus Tämä sisältää nykyiset asiakastietojen hallinnan käytännöt yleisellä tasolla. Kuvattuja asioita ovat muun muassa asiakirjallisen tiedon tuottaminen, niiden tallennusmuodot (manuaalinen ja sähköinen), sijainti aktiivikäytön aikana ja pitkäaikaissäilytyksessä sekä asiakirjatyypit ja niiden arkistointiin liittyvät käytännöt. Kuvauksessa kiinnitetään huomiota asiakirjojen tuottamiseen asiakastietojärjestelmistä ja manuaalisista merkinnöistä sekä tietojen luovutuksenkäytäntöihin ja suostumusten hallintaan. Tiedonhallinnan tavoitetilan kuvaus ja tiedonhallinnalle asetettavat vaatimukset.

Viitearkkitehtuuri 13 (49) Tämä sisältää asiakastietojen käsittelyyn kohdistuvat vaatimukset (hyvä tiedonhallintatapa, yksityistiedon suoja, työprosessien tukeminen, sähköinen arkistointi), tietojen hyödyntämisen eri tarkoituksiin (esim. asiakastyö, hallinto, tilastointi, tiedonmuodostus ja palvelujen arvioiminen), tuotettavan tiedon sisällön, sijainnin ja omistajuuden, arkistoitavan tiedon osuuden kerätystä tiedosta, asiakirjatyypit ja niiden muodostamisen asiakirjallisista tiedoista sekä tietojen jakamisen ja luovuttamisen. Kansallisen kokonaisarkkitehtuurin lähtökohtia ja tavoitteita on käsitelty vuonna 2008 toteutetussa asiakirjallisen tiedon sähköistä hallintaa ja säilytystä koskevassa selvitystyössä. Siinä kuvattiin sosiaalihuollon nykyiset käytännöt asiakirjallisen tiedon hallinnassa ja näistä käytännöistä nousevia kehittämiskohteita. Tavoitetilan määrittelyä on jatkettu vuoden 2009 aikana. Sosiaalihuollon kansallinen toiminta-arkkitehtuuri Tämä osakokonaisuus kuvaa sosiaalihuollon keskeisiä toimintaprosesseja, joissa syntyy tietotarpeita. Tähän mennessä on kuvattu sosiaalihuollon keskeisimpien työprosessien nykyisten käytäntöjen kuvauksia yleisellä tasolla. Näissä on keskitytty yleisen tason asiointiprosesseihin ja yleisiin asiakirjatyyppeihin liittyviin prosesseihin, mutta samalla on tuotettu myös esimerkkejä tarkoista palvelukohtaisista prosesseista. Työhön on yhdistetty tarvittavien asiakirjojen ja tietotarpeiden sekä tietoprosessien kuvaaminen sekä asiakastietojärjestelmiin liittyvää arkiston käyttötapojen tarkentaminen. Sosiaalihuollon toimintaprosesseista on kuvattu vuoden 2008 loppuun mennessä päivähoidon, toimeentulotuen ja adoptioneuvonnan toimintaprosessit sekä vuoden 2009 aikana on paneuduttu lastenvalvojan tehtäviin, sosiaaliseen luototukseen ja sosiaalipäivystykseen liittyvät prosessit. Sosiaalihuollon kansallinen tietoarkkitehtuuri Sosiaalihuollon kansallisessa tietoarkkitehtuurissa on kuvattu sosiaalihuollon asiakastietoihin kohdistuvia tietotarpeita, keskeisiä tietovarantoja ja niiden sijaintia, tietojen rakenteita ja keskinäisiä suhteita sekä tiedon organisointia ja hallintaa. Tietoarkkitehtuurin määrittelyssä keskeinen tehtävä on asiakastietoihin sisältyvien ylätason käsitteiden kuvaaminen tietomallin avulla. Tietomallin määrittely on aloitettu ja sen tarkentamista jatketaan vuoden 2009 aikana. Keskeisiä kehitettyjä tietoarkkitehtuurin elementtejä ovat: Asiakastietojen päätietoryhmien määrittely Päätietoryhmien kuvaus perustuu ydintietojen ja palvelukohtaisten tietojen määrittelyihin, joista abstrahoidaan ylätason päätietoryhmien kuvaus. Asiakastietojen korkean tason tietomallin kuvaus

Viitearkkitehtuuri 14 (49) Tietomallin laatiminen aloitettiin kuvaamalla sosiaalihuollon toimijoita ja niitä koskevia ominaisuuksia koskevia tietokokonaisuuksia. Tietokokonaisuuksia määriteltiin tiiviissä yhteistyössä asiakastietojärjestelmien kehittämiskokonaisuuteen kuuluvan asiakirjarakenteiden kehittämistyön ja asiakirjojen sisällöllisen yhtenäistämistyön kanssa. Samassa yhteydessä on viimeistelty myös sosiaalihuollon sanasto asiakastietojärjestelmiä varten. Sanastoa on täydennetty lisäämällä termitietueiden lisäksi käsitekaaviot määritellyistä käsitteistä. Sanasto ilmestyi Stakesin kustantamana vuoden 2008 lopussa. Sosiaalihuollon asiakasasiakirjoja on tarkoitus käsitellä kansallisesti samalla periaatteella kuin terveydenhuollossakin. Suunnitelmissa on keskitetyn kansallisen sosiaalihuollon asiakirjojen kansallisen arkiston toteuttaminen arviolta 2012-2013 3. 3.2.4. Sähköinen asianhallinta ja arkistointi Sähköinen asianhallinta ja siihen liittyvät järjestelmät yleisesti Kaikki viranomaisen (kunta) kanssa käytävä ns. virallinen asiointi kuuluu asianhallintakokonaisuuteen, jota säätelevät erityisesti arkistolaitoksen antamat sähköisen asianhallinnan määräykset. Asianhallinta on sähköisten palvelujen kannalta erittäin tärkeää, koska viranomaisella on säilytys- ja arkistointivelvollisuus kaikkeen viranomaisasiointiin. Perinteisesti tämä on tarkoittanut merkittäviä paperiarkistoja, mutta siirryttäessä sähköiseen asiointiin, myös koko vireille pannun asian käsittelyhistoria on voitava säilyttää ja arkistoida sähköisesti hyvin tarkkojen määräysten mukaisesti. Muussa tapauksessa viranomainen (siis kunta tässä tapauksessa) joutuisi arkistoidessaan asiointitietoa tulostamaan paperille keskeiset hakemukset, lisätietopyynnöt, päätökset ja valitustiedot. Erityisesti sähköinen asianhallinta edellyttää kullekin käsiteltävälle asialle (esim. päivähoitohakemus, potilaskäynti tms.) ominaisten metatietojen liittämistä sähköiseen asiointiin koko asiointihistorian ajan. Mikäli näitä metatietoja ei ole luotettavasti ja todennettavasti käsitelty ja taltioitu asian vireillepanosta asti, kyseistä asiaa ei yleensä voida enää arkistoida sähköisesti; pahimmillaan sähköisesti toteutettu asiointihistoria joudutaan tulostamaan ja arkistoimaan paperilla. Keskeisin sähköisen asianhallinnan ja arkistoinnin määräys on Arkistolaitoksen ns. SÄHKE 2 määräys, jota tulee noudattaa Kohti Kumppanuutta ratkaisussa. Sähköisen asianhallinnan ja arkistoinnin tuomat reunaehdot Kohti Kumppanuutta ratkaisulle on määritetty tarkemmin jäljempänä palveluita ja rajapintoja koskevissa luvuissa. 3 Aikataulut ovat tässä vaiheessa hyvin alustavia ja tarkentuvat.

Viitearkkitehtuuri 15 (49) 3.3. Muut yleiset sidosarkkitehtuurit ja linjaukset Muut yleiset sidosarkkitehtuurit, jotka vaikuttavat Kohti kumppanuutta ratkaisun suunnitteluun ja toteuttamiseen on listattu Liitteeseen 9, KA-taulukot. Alle on koottu lista keskeisimmistä: Yleiset sidosarkkitehtuurit Valtasa Ohjaava Valtiotason arkkitehtuurihanke Kuntasektorin viitearkkitehtuuri Ohjaava Kuntasektorin arkkitehtuurilinjaukset Asiointitili Ohjaava Julkishallinnon kansalaisen asiointitili Vetuma Ohjaava Nykyinen kansallinen yleinen tunnistamis- ja verkkomaksamisratkaisu Virtu Ohjaava Virkamiehen tunnistaminen Katso Ohjaava Yrityksen tunnistaminen Kansalliset perustietovarannot Velvoittava Kansallisten perustietojen päälähteet Kansalais- ja yritysportaali Huomioitava Kansalliset portaalit SADe Ohjaava Sähköisen asioinnin ja demokratian vauhdittamisohjelma. JHS-suositukset Ohjaava Julkisen hallinnon tietohallinnon neuvottelukunnan suositusjärjestelmä JHS-129 Ohjaava Julkishallinnon verkkopalvelun suunnittelun ja toteuttamisen periaatteet TotIT Huomioitava Kuntien ja kaupunkien toiminnan- ja taloudenohjauksen virkamies- ja luottamushenkilöjohdon operatiivisen ja strategisen johtamisen tukeminen. Sähköisen asioinnin alusta Huomioitava Julkishallinnon yhteinen sähköisen asioinnin alusta Tiedon rakenne ja hallinta Henkilötietolaki Velvoittava Laki henkilötietojen käsittelystä ja rekisteröinnistä Laki yksityisen suojasta työelämässä Velvoittava Laki, joka kuvaa yksityisen suojan määräykset työelämässä Sähköisen viestinnän tietosuojalaki Velvoittava Laku tietosuojasta sähköisessä viestinnässä Arkistolaitos - sähköinen arkistointi Velvoittava SÄHKE 2 -normi Tiedonhallinnan yleiset JHS-suositukset Ohjaava JHS-143, 145, 146, 150, 151 OID-koodistojärjestelmä Ohjaava JHS 159 - Yksilöintitunnuksen käyttö Julkishallinnon XML-skeemojen määrittäminen Ohjaava JHS 170

Viitearkkitehtuuri 16 (49) Lasten ja nuorten palveluiden sidosarkkitehtuurit Tikesos Ohjaava THL hallinnoi, kansallinen sosiaalialan kehittämishanke. Suostumuksen hallinta KanTa Velvoittava Sosiaali- ja terveydenhuollon kansallinen sähköinen arkisto Arkistolaitos - sähköinen arkistointi Ohjaava SÄHKE 2 -normi Väestöliiton perhepalvelut verkossa Huomioitava Perheverkko, antaa erilaisia asiantuntijapalvelua perheen ja vanhemmuuden tueksi Kaste Huomioitava Sosiaali- ja terveydenhuollon kansallinen kehittämisohjelma 2008-2011 SADe - oppijan palvelukokonaisuus Huomioitava Ensimmäisen vaiheen tarkoitus oli tehdä ehdotuksia kehittämistoimenpiteiksi ja laajoiksi toteuttamishankkeiksi, joilla tavoitellaan parempaa sähköisten asiointipalveluiden saatavuutta ja löydettävyyttä kansalaisille ja yrityksille. Yhteistyöympäristö Huomioitava Hyvinvointipalvelujen palveluntuottajien ja kuntaasiakkaiden yhteistyöportaali Kansallinen koodistopalvelu Velvoittava THL koodistopalvelin. Koodistopalvelimelta jaellaan yhtenäiset sosiaali- ja terveydenhuollon sähköisten asiakastietojärjestelmien tarvitsemat koodirakenteet (Laki 159/2007). Ysteri Ohjaava Valviran sosiaali- ja terveydenhuollon palveluntuottajien rekisteri 3.4. Tietoturva ja tietosuoja kasvatuskumppanuuden palveluissa Lainsäädäntöselvitys Sosiaali- ja terveyssektorin tietojen käsittelyssä korostuu korotettu tietosuojaja tietoturvanäkökulmien ja teknisten ratkaisujen huomioiminen. Tietosuojaperiaatteet ovat pitkälti lähtöisin aluetta säätelevästä lainsäädännöstä. Kohti kumppanuutta kokonaisuuden lainsäädännöllisistä reunaehdoista on tehty erillinen selvitys, joka on liitetty Liitteeksi 1, Kohti kumppanuutta lakiselvitys. Alle on listattu lakiselvityksen keskeisiä, tietosuojaa koskevia piirteitä. Sosiaali- ja terveydenhuollossa lähtökohtana on asiakassuhteeseen liittyvien tietojen ehdoton salassapito. Asiakkaiden asemaa ja yksityisyyttä suojataan asiakirjasalaisuutta ja ammattihenkilöiden vaitiolovelvollisuutta koskevilla säännöksillä. Myös opetustoimessa oppilaiden ja heidän perheittensä yksityiselämää ja henkilökohtaisia oloja koskevat tiedot ovat salassapidettäviä. Yhteistyö huoltajien kanssa ja suostumuksen hankkiminen lapsen palveluita koskevien tietojen siirrolle on aina ensisijainen vaihtoehto. Erityisen haasteellisia ovat ne tilanteet, joissa lapsen huoltajat eivät anna suostumustaan yhteis-

Viitearkkitehtuuri 17 (49) työlle. Moniammatillisen yhteistyön esteinä on eri yhteyksissä noussut esille tietojen luovutussäännösten sektorikohtaisuus ja tulkinnanvaraisuus. Tietojen luovuttamista ohjaa lainsäädäntö, joka on kirjoitettu erikseen eri ammattikunnille ja hallinnonaloille. Tietosuojaan kuuluu kansalaisten yksityisyyden suojan ja oikeusturvan huomioonottaminen tietojen rekisteröinnissä ja tiedostojen suojaaminen luvattomalta ulkopuoliselta käytöltä. Tietosuoja termi ohjaa ajatukset rekisterinpitoon ja tietojen käsittelyn toiminnalliseen puoleen. Tietosuojaan kuuluu myös henkilön oikeus saada tietää itseään koskevista rekisteritiedoista. Tietosuojalla rajoitetaan ja tehdään luvanvaraiseksi yksilöistä kerättävien rekisterien ja tiedostojen ylläpitäminen ja tietojen luovuttaminen niistä. Tietosuojalla ei tarkoiteta kaikissa tilanteissa henkilötietojen salassapitoa eikä tietosuoja ole julkisuudenkaan vastakohta. Lainsäädäntöselvityksessä on käsitelty huolellisesti tietosuojaa ohjaavia yleisiä säännöksiä sekä asiakastietojen käsittelyä koskevia erityissäädöksiä. Selvityksessä käydään läpi myös henkilörekisterin käsitettä ja käyttöä yleisesti. Henkilö- ja asiakastietoja voidaan käyttää kolmesta eri näkökulmasta: 1. Tietojen käyttö rekisterinpitäjän omassa toiminnassa Asiakasta koskevien tietojen käyttö siinä toiminnassa, jota varten rekisteri on muodostettu, ei edellytä asiakkaan suostumusta. Asiakasta on informoitava siitä, mihin tarkoitukseen hänen tietojaan kerätään ja käytetään. 2. Asiakas kumppanina ja tietojen käyttäjänä Pääsääntöisesti asiakkaalla on oikeus katsoa omia tietojaan. Alaikäisen lapsen kohdalla tämä oikeus on pääsääntöisesti hänen huoltajallaan. Tämä periaate tulee täsmentää esimerkiksi lastensuojelun sijaishuollon palveluissa Asiakkaalla on myös oikeus saada pyynnöstä terveydenhuollon palvelujen antajalta tieto lokitiedoista eli kuka on käyttänyt tai kenelle on luovutettu häntä koskevia tietoja ja minkä on ollut luovutuksen peruste. Kohti kumppanuutta ratkaisussa tulee terveydenhuollon tietojen osalta soveltaa näitä säännöksiä. 3. Tietojen luovuttaminen lainsäädännön perusteella Tietoja pyytävän on selvitettävä luovuttajataholle, mitä henkilötietoja pyydetään ja mihin käyttötarkoitukseen niitä pyydetään sekä esitettävä joko rekisteröidyn suostumus tai se lainkohta, joka oikeuttaa tietojen saamiseen suostumuksesta riippumatta. Tietojen luovuttajan on arvioitava, että laissa säädetyt luovutusedellytykset täyttyvät.

Viitearkkitehtuuri 18 (49) Kohti kumppanuutta ratkaisukokonaisuudella pyritään parantamaan lasten ja nuorten palveluja saattamalla lasta koskevat olennaiset tiedot viranomaisen eri osatuottajien saataville sekä kehittämään kasvatuskumppanuutta viranomaisen ja perheyhteisöjen yhteistyönä. Nämä tavoitteet korostavat edellä tietojen luovuttamisen kehittämistä erityisesti tavan 3 mutta myös tavan 2 mukaisesti. Tapa 3 edellyttää ensisijaisesti huoltajan etukäteen antamaa suostumusta tietojen luovuttamiseen tai tarkasti määritettyjä ja tapauskohtaisesti taltioitavia tietopyyntöjä eri rekisterinpitäjien välillä. Sosiaalihuollon lainsäädännön mukaan sosiaalihuollon tietoja voidaan lainsäädännön perusteella (siis myös ilman suostumusta) luovuttaa tilanteessa, jossa tieto on tarpeen lapsen edun vuoksi tai silloin, kun tieto on tarpeen asiakkaan välttämättömien etujen ja oikeuksien turvaamiseksi eikä asiakkaalla itsellään ole edellytyksiä arvioida asian merkitystä. Näissäkin tapauksissa tietojärjestelmiin tulee jäädä selkeä merkintä tiedon luovutuksesta. Kohti kumppanuutta ratkaisussa tämä tieto taltioidaan tietopyynnöiksi, jotka liitetään luovutettuun tietoon. Tiivistetysti voidaan todeta, että sosiaalihuollossa on lainsäädännön puitteissa melko laajat oikeudet luovuttaa ja vastaanottaa salassa pidettäviä, sosiaalihuollon kannalta välttämättömiä tietoja mutta terveydenhuollossa ja opetustoimessa tietojen luovutusoikeudet ovat melko rajoittuneita ilman asiakkaan tai tässä tapauksessa huoltajan suostumusta Tietojen luovuttamista ja niitä koskevia arkkitehtuuriperiaatteita sekä ehtoja on kuvattu tarkemmin Liitteessä 1, Kohti kumppanuutta, lakiselvitys. Yleisiä tietoturvaa koskevia periaatteita Kohti kumppanuutta -ratkaisu tarjoaa viranomaisille, asiakkaille ja huoltajille roolipohjaisesti jäsennetyn pääsyn asiakasta koskeviin hyvinvointi- ja koulutuspalvelutietoihin. Ratkaisun käyttötarkoitus ja käsiteltävän tietoaineiston luonne asettavat erityisiä vaatimuksia tietoturvallisuudelle ja erityisesti tietosuojalle. Järjestelmän tarjoaman palvelun kannalta keskeisiä vaatimuksia ovat osapuolten tunnistaminen riittävällä luotettavuustasolla. Käyttäjien ja käyttöoikeuksien hallinta on tarkoituksenmukaista toteuttaa organisaatiokohtaisesti delegoituna. Lokitietojen avulla on voitava jäljittää toimenpiteet käyttäjään. Suostumusten, valtuutusten ja tietopyyntöjen hallinta tulee integroida kiinteästi kaikkiin palveluihin. Tietoaineistojen eheyden ja saatavuuden varmistamiseen riittävät tavanomaiset vahvat keinot. Luottamuksellisuuden vaatimus on tosin korostunut. Palvelussa käsitellään esim. hyvinvointipalvelujen asiakkaiden henkilö- ja palvelutietoja. Näiden luottamuksellisuus tulee ottaa huomioon suunnittelussa. Viranomaiset käyttävät järjestelmää pääasiassa normaalina työaikana (terveydenhuolto ja sosiaalipäivystys mahdollisesti myös muulloin), mutta asiakkaat ja huoltajat voivat asioida palvelussa ympäri vuorokauden. Tämä nostaa käytettävyysvaatimukset korkeaan luokkaan ja teknisesti edellyttänee monennettuja, korkean käytettävyyden teknisiä ydinratkaisuja. Palvelun tuottaminen ja

Viitearkkitehtuuri 19 (49) hallinta tulee toteuttaa hyvien käytäntöjen mukaisesti, jotta korkea palvelutaso saavutetaan. Viranomaisvaatimusten kehittymistä tulee seurata, jotta järjestelmä täyttää jatkossakin esim. sosiaalipalveluja koskevat vaatimukset. Tietoturvaperiaatteet on kuvattu yksityiskohtaisemmin Liitteen 9, KA-taulukot Tietoturvaperiaateet-taulukossa. 4. Käsitteellisen tason arkkitehtuuri 4.1. Kasvatuskumppanuuteen liittyvät keskeiset roolit Kasvatuskumppanuuden keskipisteessä on lapsi, jota kasvamisessa arkielämässä tukee hänen huoltajansa ja muu perheyhteisönsä, ja jota palveluympäristössä tukee monialainen ja monipuolinen kunnan (ja osin yksityisen sektorin) palveluntuottajakenttä. Kasvatuskumppanuuden kokonaisuuteen kuuluu hyvin monia rooleja, jotka on listattu Liitteeseen 9, KA-taulukot. Kohti kumppanuutta palveluissa palveluntuottajan rooliryhmät voidaan listata esimerkiksi lapsen kasvamisen elinkaariprosessin mukaiseen pääjärjestykseen: Lastenneuvolan roolit Varhaiskasvatuksen roolit Esiopetuksen roolit Perusopetuksen roolit Kouluterveydenhuollon roolit Terveydenhuollon roolit Nuoriso-, kulttuuri- ja vapaa-ajantyön roolit Sosiaalityön roolit Näihin rooliryhmiin sijoittuu erilaisia yksittäisiä rooleja kuten neuvolaterveydenhoitaja, lastentarhanopettaja, erityisopettaja, koulukuraattori, lääkäri, taidekasvattaja, sosiaalityöntekijä ym. Olennaisimmat roolit on listattu ja kuvattu hiukan tarkemmin Liitteessä 9, KA-taulukot. Lapsen ja hänen läheistensä keskeiset roolit ovat: Rooli Mihin palveluihin tai prosesseihin rooli liittyy Kuvaus Tehtävät ja vastuut Perheen roolit Lapsi Kaikki palvelut Kohti kumppanuutta -palvelun saaja, Huoltaja Kaikki palvelut kasvaja Ko. alaikäisen lapsen virallinen huoltaja. Ei Osallistuu vahvasti kasvatusprosessiin, välttämättä biologinen ja juridinen lapsen suostumuksenhallinta, ilmoittautumiset jne. Vanhempi Monet palvelut (määritetään palveluprosesseissa) Ko. lapsen vanhempi. Tyypillisesti biologinen isä tai äiti. Osallistuu vahvasti kasvatusprosessiin, suostumuksenhallinta, ilmoittautumiset jne. Sisarus Jotkut palvelut (määritetään palveluprosesseissa) Ko. lapsen sisko, veli tai sisko- tai velipuoli. Lapsen läheinen, kumppani. Ei varsinaisesti osallistu varsinaiseen kasvatusprosessiin. Perheen arjen kannalta esim. sisarusten palvelun sijoittamisella samoihin yksiköihin voi olla suuri merkitys. Muu sukulainen / omainen / sidosryhmä Jotkut palvelut (määritetään palveluprosesseissa) Muu lapsen sukulainen, esim. isoäiti, isoisä, setä, täti Voi mahdollisesti lapsen/huoltajien suostumuksella saada tässä roolissa rajoitetun näkymän tiettyihin rajattuihin palvelutietoihin

Viitearkkitehtuuri 20 (49) 4.2. Lapsen kasvamisen elinkaareen liittyvät palvelut Lapsen kasvamisen elinkaareen liittyvät palvelut on kuvattu Liitteessä 2, Palvelut ja ratkaisulla tuettavat prosessit. 4.3. Käsitteistö Kohti kumppanuutta ratkaisussa käsitellään koko kasvavan lapsen palvelukirjon palveluita. Näiden palveluiden toteutusta ja toimijoiden välistä yhteistyötä varten tarvitaan yhdenmukaiset käsitteet ja sanastot. Tässä projektissa on luotu perustieto- ja KKS-käsitemallit ensimmäisen vaiheen palvelutoteutuksia varten. Käsitteistöjen luonnissa on käytetty alalle määriteltyjä käsitteitä ja luotu uusia Kohti kumppanuutta hankkeelle ominaisia käsitteitä kuten yhteisö- ja perhetiedot tai lapsen kasvun ja kehityksen suunnitelma. Käsitteiden määrittelytyössä on huomioitu erityisesti Tikesos-hankkeen tietomääritykset ja kuntasektorin yleinen asiakastiedon pääjäsennys. Käsitteet ja niistä johdetut tiedot on kuvattu tarkemmin Tietomallinnusta koskevassa luvussa sekä erityisesti tätä koskevassa liitteessä. 5. Loogisen tason arkkitehtuuri 5.1. Prosessit Kohti kumppanuutta -viitearkkitehtuurin suunnittelussa tuotetut prosessikuvaukset on koottu yhteen Liitteessä 2, Palvelut ja ratkaisulla tuettavat prosessit. 5.2. Tietomallinnus Kohti kumppanuutta -viitearkkitehtuurin suunnittelussa tuotetut käsitemallit on kuvattu Liitteessä 4, Tietoarkkitehtuuri: Käsitemallin kuvaus. Tietojen hallintaan liittyviä suunnittelu- ja toteutusperiaatteita käsitellään tarkemmin Liitteessä 3, Tietoarkkitehtuuri: Käsiteväylämäärittely. Kohti kumppanuutta hankkeessa toteutetut käsitemallit sisältävät: Käsitteet Käsitteiden väliset suhteet Ominaisuudet eli käsite- ja tietokentät Näitä tietoja on kuvattu graafisesti ns. ER-kaavioilla (entity-relationship diagram). Tässä hankkeessa tietojen mallinnukseen on käytetty kolmitasoista lähestymistapaa. Tässä tavassa mallinnus aloitetaan käsitteelliseltä tasolta, josta päädytään loogisen tason mallinnuksen kautta toteutusvaiheessa tehtäviin fyysisen tason tietomalleihin. Nämä tasot kytkeytyvät suoraan KA-menetelmäkehyksen abstraktiotasoihin. Tässä suunnitteluprojektissa on keskitytty käsitteellisen ja loogisen tason tietomallinnukseen, minkä tuotoksena on syntynyt Käsitemallin kuvaus -

Viitearkkitehtuuri 21 (49) dokumentissa kuvatut käsitemallit. Fyysisen tason tietomallinnus tehdään toteutusvaiheessa ja sen kuvaamiseen suositellaan käytettävän UML-notaatiota. Fyysisen tason tietomallinnuksen yhteydessä tulee myös tarkentaa käsitteisiin liittyviä tietosisältöjä. Kohti kumppanuutta -hankkeessa käytetty käsitemalli jakautuu kahteen osaan, perustietomalliin ja hankekohtaiseen lapsen kasvun ja kehityksen suunnitelmatietoja (KKS) käsittävään käsitemalliin. Perustietojen käsitemalli sisältää mm. henkilöihin, organisaatioihin, suostumuksiin, lupiin, asiakirjoihin, yhteistietoihin ja yhteisöihin liittyvät käsitteet. KKS-tiedot koostuvat puolestaan lapsen kasvuun ja kehitykseen liittyvistä tiedoista, kuten palvelun tuottajien tiedot, erilaiset suunnitelmatiedot, mittaukset ja muut lapsen terveyden ja hyvinvoinnin edistämistä tukevat tiedot. Näiden käsitemallien luonnissa on huomioitu erityisesti Tikesos-hankkeen tietomääritykset. Tikesos-hankkeessa ja sitä edeltävässä työssä on määritetty sosiaalihuoltoon liittyviä asiakirjarakenteita ja niihin liittyviä tietokomponentteja. Tikesos-hankkeessa määriteltyjä asiakirjoja ovat mm. Päivähoidon varhaiskasvatussuunnitelma Päivähoitohakemus Päivähoitopäätös Tuloselvitys Hoitosopimus Kaikkiin hankkeessa määriteltyihin käsitteisiin voidaan liittää ISO OID - tunniste. OID-tunniste on liitetty Tietoelementti-käsitteeseen, josta muut käsitteet on erikoistettu. OID-koodien arvoja ei kuitenkaan käytetä ensimmäisessä toteutusversiossa. 5.2.1. ISO OID määritys Tietojärjestelmien välisessä kommunikoinnissa on aina ollut haasteena luotettava ja selkeä erilaisten tieto-objektien identifiointi. Tieto-objektien yksilöinnin haasteeseen on pureuduttu ns. ISO OID määrityksessä, jonka avulla kaikille tieto-objekteille voidaan antaa yksiselitteinen ja ainutlaatuinen, uniikki tunniste. OID (Object identifier) on ISO/IEC -standardilla määritelty yksilöintijärjestelmä, jota käyttämällä paitsi organisaatioille ja niiden työyksiköille, ja näihin liittyen esim. henkilöille, asiakirjoille ja laitteille voidaan antaa globaalisti yksilölliset tunnisteet. ISO OID -yksilöintijärjestelmä rakentuu numerosarjasta, jonka ylintä solmua hallinnoi ISO. Järjestelmässä ylemmän solmun omistaja antaa aina sitä alemman tason solmunumerot. Tätä yksinkertainen, hierarkkinen malli tarjoaa vahvan objektien organisaatioiden, koodistojen, henkilöiden, asiakirjojen ym. palveluun liittyvän tiedon yksilöintimekanismin. Suomessa ISO OID:n käyttöä on hahmoteltu JHS-suosituksessa JHS-159 OID -yksilöintitunnuksen soveltaminen julkishallinnossa. Kyseinen suositus luo hyvän pohjan ISO OID-yksilöintitunnuksen käytölle.

Viitearkkitehtuuri 22 (49) JHS-159:ssä on ISO OID -sovelluskohteet kuvattu seuraavasti: " ISO OID-yksilöintitunnuksen käyttö on perusteltua tapauksissa, joissa jo olemassa oleviin yksilöintikäytäntöihin tarvitaan nykyistä laajempi yksilöitävyys (esimerkiksi järjestelmän sisäinen yksilöintitunnus pitää saada yksikäsitteiseksi kansallisella tai kansainvälisellä tasolla organisaatiorajat ylittävä tiedonvaihto tai organisaation eri järjestelmien välinen tiedonvaihto). Tähän kategoriaan kuuluu myös käytössä olevien yksilöintijärjestelmien tuominen OID-rakenteeseen (esim. Y- tunnus). Joillakin toimialoilla voi olla sitova päätös tietyn yksilöintijärjestelmän käyttämisestä. Esimerkiksi terveydenhuollossa on kansallisesti sovittu ISO OID-yksilöintijärjestelmän käytöstä mm. potilasasiakirjojen yksilöintiin." Käytännössä ISO OID-yksilöintitunnus (object identifier) toteutetaan vain yhteen objektiin liitettävissä olevana pistein erotettuna numerokoodina, joka yksilöi kyseisen objektin yksikäsitteisesti ISO:lle varatussa yksilöintijärjestelmässä (ISO/IEC 8824-1, 2002). Järjestelmä on hierarkkinen siten, että numerosarjan ensimmäinen numero 1 tarkoittaa ISO:a, toinen pisteellä erotettu numero 2 tarkoittaa ISO- alaorganisaatioita (ANSI) ja seuraava solmu on maasolmu. Esimerkiksi Suomen valtion ISO OID -yksilöintitunnus on 1.2.246 (= ns. Suomen juuri). Yksilöintitunnusilta edellytettäviä vaatimuksia ovat: Yksikäsitteisyys Yksilöintitunnuksen tulee varmasti olla valitussa nimiavaruudessa, laajimmillaan maailmanlaajuisesti, yksikäsitteinen, ts. kahdella eri kohteella ei voi olla samaa yksilöintitunnuksen arvoa. Pysyvyys Kohteelle annetun yksilöintitunnuksen tulee säilyä muuttumattomana kohteen koko elinkaaren ajan, vaikka kohteen muut ominaisuustiedot muuttuisivatkin. Ainutkertaisuus Kerran annettua yksilöintitunnuksen arvoa ei anneta uudestaan toiselle kohteelle sillä alunperin yksilöidyn kohteen elinkaaren päättymisen jälkeenkään. Merkityksettömyys Nimiavaruuden tunnusgeneraattorin kohteelle antamaan yksilöintitunnukseen ei liity mitään merkitystä, eikä annetusta yksilöintitunnuksesta pyritä päättelemään mitään merkitystä. Kaikki kohteeseen liittyvät muut ominaisuudet ilmaistaan muiden ominaisuustietojen avulla. Riittävyys Valitun yksilöintitunnusten muodostamisjärjestelmän tulee tuottaa riittävä määrä yksikäsitteisiä tunnuksia. Yleensä tulisi varautua nimiavaruuteen, joka mahdollistaa yksilöintitunnusten kansallisen käytön. Yksikäsitteinen, halutun kohteen yksilöivä ISO OID-yksilöintitunnus muodostuu puusta, jonka rakenne on seuraava:

Viitearkkitehtuuri 23 (49) Yksilöintitunnuksen muodostava Puu = Juuri.Solmu.Solmu.,,,.Solmu.Lehti Juuri yksilöi puun alla olevan nimiavaruuden. Globaalisti yksikäsitteiset OIDyksilöintitunnukset lähtevät kansainvälisesti sovitusta yhteisestä juuresta. Solmu yksilöi nimiavaruuden, joka sisältää siihen liittyvien kohteiden yksilöintitunnukset. Lehti yksilöi nimiavaruuteen kuuluvan kohteen. Kohteita voivat olla: Pysyvät kohteet, kuten henkilöt, yritykset tai yhteisöt, organisaatiot tai niiden osat, toimipaikat, tuotteet, laitteet, esineet jne. Tapahtumiin liittyvät tiedot, kuten tilaukset, toimitukset, laskut, palvelutapahtumat, asiat, asiakirjat jne. Koodistot, jotka sisältävät luokituksia, sanastoja jne. Muut yksilöintiä tarvitsevat kohteet. Lehden yksilöimä kohde voi myös edustaa nimiavaruutta. Lehdestä voidaan muodostaa solmu lisäämällä sen perään piste, jonka jälkeen tulevat tässä uudessa nimiavaruudessa olevat yksilöitävät kohteet. Lähtökohtana on, että OID-tunnukset rekisteröidään OID-rekisteriin., johon viedään myös OID-tunnuksiin liittyviä attribuutteja. 5.3. Tietojärjestelmäpalveluiden looginen jäsennys 5.3.1. Kuntasektorin tietojärjestelmäpalveluiden jäsennys Kuntasektorilla on tehty laajempaa, koko kunnan sähköisen asioinnin ja tätä kautta koko sähköisen palveluympäristön tietojärjestelmäpalveluiden jäsennystä ja roolitusta. Seuraavaan on koottu sen keskeisimmät yleispiirteet. Kuntatoimijan tietojärjestelmäpalvelut ja sähköinen palveluympäristö jäsennetään soveltaen edellä kuvattua kuntasektorin kokonaisarkkitehtuurimenetelmän SOA-teknologiapinoa. Kunnan tietojärjestelmäpalvelut on jäsennetty seuraaviin tasoihin:

Viitearkkitehtuuri 24 (49) Kuva 5. Kunnan tietojärjestelmäpalveluiden kerrosmalli Ylimpänä loogisena kerroksena on käyttöliittymäkerros, jota kautta sekä kunnan työntekijät että ulkoiset asiakkaat ja toimittajat pääsevät käsiksi palveluihin. Palvelut kootaan sähköisiin palvelunäkymiin - portaaliin. Asiointia varten käyttöliittymäkerroksen läheisyyteen toteutetaan asioinnin teknisiä peruspalveluja kuvaava kerros, joka sisältää sisällönhallinnan, asiointitilin ym. teknisiä peruspalveluja. Tavoitearkkitehtuurissa tietojärjestelmäpalveluja ja tiedon liikkumista järjestelmissä ja niiden välillä voidaan ohjata palvelujen ohjauskerroksen prosessimoottorin, sääntömoottorin ja palvelukatalogin avulla. Tämä edellyttää toiminnan prosessien mallintamista prosessimoottoriin. Käytännössä palveluja ajetaan SOA-teknologiapinon mukaisesti palveluväylän läpi. Tämä toimii myös perinteiset operatiiviset järjestelmät yhdistävänä integraatiopalveluna alkuvaiheessa, kun varsinaisia SOA-palveluja ei ole vielä saatavissa. Palvelukerros muodostuu avointen rajapintojen tietojärjestelmäpalveluista. Tämä sisältää myös nykyiset operatiiviset järjestelmät, vaikka niiden liittämisessä toisiinsa on suuria rajoitteita lähtötilanteessa. Alimmaksi kerrosmallissa on kuvattu tietovarantokerros, jonne varsinainen palvelujen käsittelemä tieto taltioidaan. Edellisen kerrosmallin pohjalta päädytään alla kuvattuun kunnan yleiseen tietojärjestelmäpalveluiden jäsennykseen.

Viitearkkitehtuuri 25 (49) Käyttöliittymä Palvelunäkymät, sähköinen työpöytä, käyttäjärajapinta Kansalliset tietojärjestelmäpalvelut Asiointi Ohjaus Sähköisen asioinnin peruspalvelut Integraatiopalvelu, prosessimoottori, palvelujen ohjaus Kansalliset integraatiopalvelut Käsiteväylä, asiakasprofiili Sähköinen asianhallinta Kansalliset perustietovarannot Palvelut Ydinprosessi- / palvelualuekohtaiset palvelut Yhteiset toiminnalliset palvelut Yhteiset tekniset tukipalvelut Kuntasektorin yhteiset palvelut Perinteiset operatiiviset järjestelmät Tietovarannot Operat. kanta Operat. kanta Operat. kanta Operat. kanta MDS:t MDS:t MDS:t Kuva 6. Kunnan yleinen tietojärjestelmäpalveluiden jäsennys Tuleva sähköinen asiointi ja sähköiset palvelut rakennetaan yllä kuvatun jäsennyksen mukaisesti. Kunnan palveluympäristö liitetään integraatioratkaisun avulla ulkoisiin palveluihin, jotka jäsentyvät: Kansallisiin palveluihin (yhteisiä sekä valtionhallinnolle että kuntasektorille) o Kansalliset tietojärjestelmäpalvelut o Kansalliset integraatiopalvelut o Kansalliset perustietovarannot Kuntasektorin yhteisiin palveluihin Kunnan sisäiset tietojärjestelmäpalvelut jakautuvat seuraaviin kokonaisuuksiin: Palvelukutsukerros (korostunut tekninen tukipalvelu, joka yhdistää palvelut yhteiseen tietomalliin, asiakkaan palvelutapahtumiin ja tiedonluovutusvaltuutuksiin turvallisesti ja hallitusti) Sähköinen asianhallinta (korostunut toiminnallinen tukipalvelu, joka varmistaa sähköisten palvelujen arkistoitavuuden ja luo puitteet näiden käsittelyä koskeville prosesseille) Yhteiset toiminnalliset tietojärjestelmäpalvelut Yhteiset tekniset tietojärjestelmäpalvelut Prosessi- ja palvelualuekohtaiset (toimialakohtaiset) palvelut Yllä kuvattu käsiteväylä muodostaa turvallisen ja kokonaisvaltaisen arkkitehtuurikerroksen, jonka avulla esimerkiksi tietojen välittämistä palveluilta toisel-

Viitearkkitehtuuri 26 (49) le voidaan hallita systemaattisesti määriteltyjen tiedonluovutusvaltuuksien ja käyttöoikeuksien puitteissa käsitteiden merkitykset ja suhteet säilyttäen. Tämän keskeisenä piirteenä on kokonaisvaltainen ja yhdenmukainen käsitemalli, joka muodostaa ratkaisun ytimen. Käsiteväylä kattaa kaksi eri näkökulmaa: Varsinainen käsiteväylärajapinta, joka kuvaa loogisesti rakennettua kutsukerrosta käsitteistön mukaisiin palveluihin ja tietoihin (tämä on kuvattu alla vaaleanruskeana rajapintakerroksena). Yhtenäisten käsitteistön mukaisesti rakennetut ja verifioidut SOApalvelukokonaisuudet, komponentit, jotka nivotaan yhteen käsiteväylän kautta. Tämä jälkimmäinen kattaa siis lähinnä ohjeen suunnitella ja toteuttaa yksittäiset komponentit yhden, yhtenäisen käsitteistön mukaisesti. Liitteessä 3 kuvattu käsiteväylämäärittely kattaa molemmat yllä kuvatut näkökulmat ja alla oleva KuntaIT:n kunnan sähköisen asioinnin arkkitehtuuriin sovitettu malli puolestaan vain ensimmäisen näkökulman. Kuntaa koskeva arkistolain SÄHKE 2 määräys on niin kattava, että käytännössä lähes kaikkeen asiointitietoon tulee liittää eamsin määrittämät metatiedot. Tästä syystä sähköinen asianhallinta on nostettu keskeiseksi tietojärjestelmäpalveluksi kunnan viitearkkitehtuurissa. Tietojärjestelmäpalveluista voidaan tarkemmalla tasolla tunnistaa seuraavat yhteiset tietojärjestelmäpalvelut ja päätietovarannot:

Viitearkkitehtuuri 27 (49) Ulkoinen palvelunäkymä Julkaisunhallinta Asiointialustan tekniset peruspalvelut Palveluohjauksen säännöstö Ryhmätyötila Personointi SOA-palvelukatalogi Työntekijän sähköinen työpöytä Asioinnin perustoiminnot Prosessimoottori Kansalliset tietojärjestelmäpalvelut Suomi.fi Kela Vero Osallistumisympäristö Kilpailutusjärjestelmä Prosessin / palvelualueen A palvelut Palvelu Prosessin / palvelualueen C palvelut Palvelu ESB-integraatioväylä, integraatiopalvelu Prosessin / palvelualueen B palvelut Palvelu Prosessin / palvelualueen D palvelut Palvelu Käsiteväylä, asiakasprofiili Sähköinen asianhallinta, eams Yhteiset tekniset tukipalvelut Tunnistaminen Käyttövaltuushallinta Sähköinen allekirjoitus Hakupalvelut Aikaleimapalvelu Tapahtumaloki Yhteiset toiminnalliset palvelut Asiakkuudenhallinta Taloushallinta Hinnoittelu, maksaminen Tiedonluovutusvaltuuksien hallinta Resurssivarausten hallinta Yhteisöjen hallinta Paikkatietopalvelu Kansalliset integraatiopalvelut Vetuma Virtu Katso Valvira-varmenne Asiointitili THL-Koodistopalvelu Sähköinen asiointialusta Perustietovarannot VTJ YTJ KTJ KANTA, KANSA VAPA Maastotietokanta Palvelurajapinta Operatiivinen järjestelmä DB Palvelurajapinta Operatiivinen järjestelmä DB BI DW Asiakkaat MDS Palvelut/ tuotteet MDS Palvelurajapinta Kiinteistöt MDS Muu MDS Dokumentit MDS Kuntasektorin yhteiset palvelut Kuntarekry Ym. Kuva 7. Yhteiset tietojärjestelmäpalvelut ja päätietovarannot Yllä olevassa kuvassa on eritelty lähinnä yhteisiksi tunnistetut tietojärjestelmäpalvelut ja tietovarannot. Palvelualue- ja prosessikohtaiset tietojärjestelmäpalvelut määritellään prosesseittain näitä koskevissa kehittämisprojekteissa siten, että ne sovitetaan tähän kokonaisnäkymään. Kuvaan ei ole kuvattu ICT-palveluntuotannon edellyttämiä työvälineitä, kuten esimerkiksi palvelupyyntöjen hallintajärjestelmää, konfiguraationhallintajärjestelmää tai valvontajärjestelmiä. 5.3.2. Kohti kumppanuutta ratkaisun pääjäsennys Kohti kumppanuutta -ratkaisun pääjäsennys on esitetty alla olevassa kuvassa. Kohti kumppanuutta -toteutukseen kuuluvat sinisellä kuvattu Käsiteväylä, Kuntalaisportaaliin tehtävät käyttöliittymäportletit ja näiden portlettien käyttämät komponentit ja koostepalvelut. Tarkemmin Käsiteväylän rakennetta ja toteutusosia on käsitelty Liitteessä 3, Tietoarkkitehtuuri: Käsiteväylämäärittely.

Viitearkkitehtuuri 28 (49) Kuva 8. Toteutusosien karkea jaottelu 5.3.3. Kasvun ja kehityksen suunnitelman hallinta Lapsen kasvun ja kehityksen suunnitelmatiedot ovat lapsen kasvuun ja kehitykseen liittyviä tietoja, joiden päämääränä on tukea ja edistää lapsen hyvinvointia, terveyttä ja kehitystä. Tällaisia tietoja ovat mm. palvelun tuottajien tiedot, erilaiset suunnitelmatiedot, mittaukset, erityisruokavaliot ja terveystiedot. Keskeisiä kasvun ja kehityksen suunnitelman käyttäjiä ovat: Kustakin osapalvelusta (esim. päivähoito) vastaava kunnan vastuuhenkilö vastaa ko. osa-alueen osasuunnitelman laatimisesta Lapsen kasvun ja kehityksen suunnitelmaan ja osasuunnitelmaan annetaan luku- ja rajoitetusti muutosoikeuksia myös muille kunnan työntekijöille ja palveluntuottajille

Viitearkkitehtuuri 29 (49) Suostumuksen kautta Kunnan avaintyöntekijöille järjestetään lainsäädännön ja suostumusten puitteissa mahdollisimman laaja näkyvyys lapsen palveluihin ja suunnitelmiin Lain suoraan sallima käyttö sekä suostumusten ja tietopyyntöjen kautta tapahtuva tietojen luovuttaminen. Tietopyyntöjen toteutus ei kuulu ensimmäiseen toteutusversioon. Vanhemmat voivat itse lisätä lapsen kasvun ja kehityksen suunnitelmaan omia lasta ja hänen kasvamistaan koskevia tietoja Vanhemmilla lapsilla voi olla itsellä rajoitettu näkymä palvelusuunnitelmiin 5.3.4. Perhe- ja yhteisötietojen hallinta Kohti kumppanuutta -hankkeen ja -ratkaisun keskeisenä tavoitteena on vahvistaa lapsen kasvatuskumppanuutta paitsi viranomaisten kesken myös erityisesti lapsen ja tämän huoltajien ja kasvattajien sekä kunnan työntekijöiden välillä. Tämän vuoksi on kiinnitettävä aikaisempaa enemmän huomiota lapsen perheja yhteisötietojen hallintaan. Lapsen kasvatusympäristö on monimutkaistunut viime vuosikymmeninä merkittävästi. Lapsen kasvatuksesta ja kasvamisesta on perinteisesti huolehtinut ns. ydinperhe, jolla tarkoitetaan yleensä avio- tai avopuolisoiden, miehen ja naisen, ja heidän biologisten lastensa muodostamaa perhekokonaisuutta. Nyttemmin koko perhekäsitys on muuttunut. Puhutaan uusioperheistä, sateenkaariperheistä, laajemmista perheyhteisöistä ym. Vielä 1900-luvun alkupuolella vahvasti perheyhteisöön kuuluvat isovanhemmat ovat taas yhä vahvempi osa lapsen kasvatukseen osallistuvaa yhteisöä. Erityisesti maahanmuuttajilla perheyhteisöt ovat usein perinteisiä suomalaisia perheyhteisöjä laajempia. Huoltajuus Huoltaja tarkoittaa oikeustieteessä lapsen huoltajaa eli henkilöä, joka vastaa lapsen hoidosta, kasvatuksesta, valvonnasta ja muusta huolenpidosta. Suoraan syntymän perusteella molemmat vanhemmat ovat lapsen huoltajia, jos he lapsen syntyessä olivat avioliitossa keskenään. Jos äiti ei ollut avioliitossa, on hän yksin lapsensa huoltaja. Myös isyyden vahvistamisen jälkeen äiti pysyy lapsen yksinhuoltajana, elleivät vanhemmat sovi lapsen huollosta toisin tai tuomioistuin anna tarvittaessa päätöstä lapsen huollosta. Jos toinen vanhemmista on yksin lapsensa huoltaja ja vanhemmat menevät keskenään avioliittoon, tulevat he molemmat lapsensa huoltajiksi. Lapsen syntymän yhteydessä määräytynyttä huoltajuutta voidaan muuttaa joko tuomioistuimen tekemällä päätöksellä tai vanhempien välisellä sopimuksella lapsen huollosta, jonka sosiaaliviranomainen vahvistaa. Lapsen palveluissa huoltajalla on merkittävä rooli. Perhe- ja yhteisötietojen hallinta

Viitearkkitehtuuri 30 (49) Perhe- ja yhteisötietojen hallinnan avulla voidaan mallintaa ja hallita lapsen perheen ja muiden kasvatukseen osallistuvien läheisten (lapsen tärkeä henkilö) muodostamia verkostoja ja yhteisöjä. Lähtökohta on, että huoltajille ja iän karttuessa rajoitetusti lapselle itselleen annetaan sähköisen asioinnin kautta mahdollisuus ylläpitää perheyhteisötietoja. Vastuu perheyhteisötiedoista ja niiden ajantasaisuudesta on siis aina lapsen huoltajilla. Kunnan työntekijät eivät varsinaisesti ylläpidä perheyhteisötietoja. Yhteisöjä voidaan määrittää laajemmin koskemaan erilaisia kohteita. Samaa mekanismia voidaan hyödyntää myös esimerkiksi päivähoitoryhmien, päivähoitoryhmän vanhempien muodostaman ryhmän, koulun kerhoryhmän ym. henkilöiden muodostamisen ryhmien hallintaan. 5.3.5. Tiedonluovutusvaltuuksien hallinta Tiedonluovutusvaltuutukset jäsennetään tässä kolmeen osittain itsenäiseen toiminnalliseen kokonaisuuteen: Suostumus Valtuutus Tietopyyntö Kohti kumppanuutta ratkaisussa käsitellään palveluja, jossa tiedonluovutusten hallinta on erityisen tärkeää. Ensimmäisessä toteutusversiossa toteutetaan pelkästään tuki suostumuksille, ks. lisätietoja Käsitemallin kuvauksesta. Kohti kumppanuutta järjestelmä ei saa siirtää tietoa operatiivisista tietojärjestelmistä tai sisäisistä järjestelmistään toisiin järjestelmiin, tulosteisiin, hakuihin, raportteihin tai käyttöliittymiin, sähköiseen asiointiportaaliin, sähköiselle työpöydälle tai lapsen kasvun ja kehityksen suunnitelmaan ilman voimassa olevaa suostumusta tai hyväksyttyä tietopyyntöä. Tämä tarkistetaan ja tarvittaessa estetään käsiteväylän avulla kaikessa tiedon käsittelyssä. Mikäli viranomaisen tulee päästä esim. lasta koskevaan tietoon ilman suostumusta (esim. ns. lapsen etu lainsäädännössä), tästä tulee kuitenkin kirjata tietopyyntö, johon kirjataan peruste kyseiselle tiedon luovutukselle. Suostumus Suostumuksella tarkoitetaan asiakkaan antamaa suostumusta viranomaiselle, jolla hän sallii viranomaisen käyttää itseään koskevaa tietoa tai esim. suostuu asioinnissa käyttämään sähköisiä välineitä perinteisten keinojen sijaan. Jos käyttäjä ei ole antanut suostumusta tietojen luovutukseen viranomaiselle, niin viranomaisen tulee kunnioittaa tätä asiakkaan tahtoa. Terveydenhuoltoa ja sosiaalihuoltoa koskeva lainsäädäntö antaa kuitenkin kunnalle joissakin tapauksissa mahdollisuuden jopa velvollisuuden vaihtaa tietoa asiakkaan tai huoltajan suostumuksesta huolimatta. Suostumukset jaetaan kahteen luokkaan: Tiedonluovutusta koskevat suostumukset Toimenpidesuostumukset

Viitearkkitehtuuri 31 (49) Suostumustenhallintaan kuuluu myös käyttäjän antama suostumus sähköisen asiointikanavan käyttöön viranomaistasolla. Viranomainen voi tarkistaa suostumuksenhallintapalvelusta, onko asiakas antanut suostumuksensa asiointitilin ja sähköisen asioinnin käyttöön kyseisen viranomaisen palveluja koskien. Tarkistaminen tapahtuu käyttäen suostumuksenhallintaan toteutettua käyttöliittymää. Sähköisiä palveluita käytettäessä on varmistettava, että kyseiseen asiointiin voidaan käyttää sähköistä kanavaa ja että viranomaisella on oikeus päästä käsiksi kyseisen tietoon. Esimerkiksi valtionhallinnon asiointitilissä viranomaisen lähettäessä viestin asiointitilin kautta käyttäjälle asiointitili tarkistaa onko käyttäjä antanut suostumuksen viranomaiselle. Jos suostumusta ei ole tai käyttäjä on poistanut suostumuksen, niin asiointitili palauttaa virheilmoituksen lähettävälle järjestelmälle. Asiakas voi koska tahansa perua suostumuksensa ja tämä tulee ottaa huomioon sähköisiä palveluita kehitettäessä. On huomattava, että terveydenhuollon suostumustenhallinta toteutetaan osaksi kansallista potilastietoarkistoratkaisua KANTAaa, joka tulee ottaa huomioon kohti kumppanuutta suostumuksenhallintaratkaisua toteutettaessa. Sosiaalihuollon suostumuksenhallinnan periaatteet on kuvattu Tikesoshankkeessa omassa selvityksessään. Aivan kaikkiin palveluihin ja tietoihin ei välttämättä tarvita lainkaan suostumusta. Kunnan tulee laatia säännöstö, jossa kuvataan: tarvitaanko tähän suostumus, keneltä tarvitaan suostumus, kuinka monen ko. roolin edustajan suostumus tarvitaan. Kohti kumppanuutta toteutuksen tulee tukea mallia, jossa suostumus tarvitaan esim. molemmilta huoltajilta. Huoltajan on hyvä pystyä valtuuttamaan toinen huoltaja näissä tapauksissa myös yleisellä suostumuksella ainakin rajoitetusti edustamaan itseään näissä suostumusasioissa. Esimerkiksi päivähoidossa toinen vanhempi voisi valtuuttaa toisen vanhemman toimimaan puolestaan siten, että esimerkiksi suostumukseen: lapsesta saa ottaa päiväkodissa valokuvan päiväkotiryhmän yhteiskuvaa varten ei tarvittaisi kahden vanhemman suostumusta. Huoltajan tulee kuitenkin pystyä helposti mitätöimään tämä suostumus. Ylipäätään tämän säännöstön laatimisessa tulee olla huolellinen. Valtuutus Valtuutuksilla tarkoitetaan mahdollisuutta valtuuttaa toinen taho toimimaan puolestaan viranomaisasioinnissa. Kohti kumppanuutta palveluissa vapaaehtoisia valtuutuksia käytetään varoen. Pääsääntöisesti puolesta-asiointi koskee vain lapsen huoltajia. Jos valtuutuksia kuitenkin käytetään, kuntien sähköiset palvelut suorittavat asiointiin liittyvät valtuutusten tarkastukset tarpeen mukaan. Kohti kumppanuutta ratkaisun sähköisten palvelujen tulee kuitenkin tarkistaa perhe- ja yhteisötietojen hallintakomponentilta esimerkiksi vanhempien oikeuden toimia lastensa nimissä, huoltajien oikeuden toimia huollettavien edustajina tai vastaavat tilanteet. Jos viranomainen on todennut henkilön oikeuden toimia toisen edustajana ja edustaja on antanut suostumuksen viranomaiselle, niin viranomainen voi lähettää asiaan liittyvät viestit suoraan edustajan asiointitilille.

Viitearkkitehtuuri 32 (49) Ratkaisumalliksi suositellaan siis roolipohjaista toteutustapaa, jossa henkilöt käyttävät vain omaa asiointitiliään, jonne saapuvat myös heidän mahdollisten edustettaviensa viestit. Näin valtuutukset voidaan kohdistaa palveluihin ja tietyn rajoitetun kohteen asioihin, ei kaikkeen valtuuttajaa koskevaan tietoon. Sähköisen asioinnin asiakasrajapinnan portaalin tai asiointitilin pitää jaotella edustettavien palvelut ja viestit selkeästi omiin ryhmiinsä, jotta ne eivät mene sekaisin henkilön omien viestien kanssa. Tietopyyntö Tilanteessa, jossa lainsäädäntö ei yksiselitteisesti salli tiedon luovutusta eikä asiakas tai huoltaja ole antanut etukäteen suostumusta tiedon luovuttamiseen, on tietoa erikseen pyydettävä tietopyynnöllä. Tämä voidaan tehdä silloin, kun tieto on tarpeen lapsen edun vuoksi tai silloin, kun tieto on tarpeen asiakkaan välttämättömien etujen ja oikeuksien turvaamiseksi eikä asiakkaalla itsellään ole edellytyksiä arvioida asian merkitystä. Tässä on toistaiseksi haasteena se, että lainsäädäntö tuntee vain kahdenvälisen tietopyynnön. Yhden toimijan tietopyyntöä ei voida hyväksyä kollektiivisesti myös muiden käyttöön. Muut tiedonluovutukseen liittyvät tekijät On hyvä huomata, että tiedonluovutukseen liittyy erityisesti kunnan kulttuurisektorilla erityishaasteita teosten tekijänoikeuksiin ja tätä kautta niiden hyödyntämiseen. Tiedonluovutusvaltuuksien hallinnan tulee mahdollisesti myöhemmissä vaiheissa tukea myös tämäntyyppisiä valtuuksia. Hyvinvointipalveluissa tämä voi kohdistua esimerkiksi lasten piirustusten tai muiden teosten hyödyntämiseen verkkosivustoilla ja kunnan muussa materiaalissa. Ensimmäisessä vaiheessa Kohti kumppanuutta ratkaisuun ei kuitenkaan toteuteta näihin liittyviä erityispiirteitä. Kohti-kumppanuutta ratkaisussa tiedonluovutusvaltuuksiin liittyvät ainakin seuraavat erityispiirteet: Suostumukset ja valtuutukset tulee voida automaattisesti esimerkiksi sääntökoneella liittää tiettyyn sähköiseen palveluun ja erityisesti palveluprosessiin (ennakoivuus). Tiedon luovuttaminen rekisterinpitäjältä toiselle tulee estää ilman asianmukaista suostumusta. Tällöin tulee tarjota mahdollisuutta pyytää suostumusta tai tehdä tietopyyntö ko. rekisterinpitäjälle Tietopyynnön tulee olla vuorovaikutteinen prosessi siten, että tietopyynnön tekijä saa vastauksen tietopyynnön hyväksymisestä tai hylkäyksestä Puolesta-asiointiin liittyvien valtuutusten tulee automaattisesti siirtää valtuutettu palvelu valtuutetun asiointitilille. Valtuutetun ei tule päästä valtuuttajan omalle asiointitilille kokonaisuudessaan.

Viitearkkitehtuuri 33 (49) Suostumusten ja valtuutusten tulee näkyä asiakkaan asiointitilillä, mutta viranomaisten väliset tietopyynnöt vain kunnan työntekijöiden näkymässä. 5.3.6. Käyttäjäviestintä Käyttäjäviestinnällä tarkoitetaan Kohti kumppanuutta ratkaisun kautta tehtävää systemaattista viestintäratkaisua palvelun asiakkaille, lähinnä huoltajille ja heidän nimeämilleen perheyhteisön jäsenille sekä muille kunnan työntekijäroolissa oleville käyttäjille. Käyttäjäviestintä voidaan jakaa kahteen pääosaan: Yleisiin käyttäjäviesteihin, joihin ei odoteta vastaanottajalta reagointia Vastaanottajalta toimenpidettä edellyttäviin käyttäjäviesteihin - toimenpidepyyntöihin Viestinnän perusperiaate on, että kaikki viestit tallentuvat vastaanottajan kumppanuustilille (kuntalaisen kansion tai kuntalaistilin Kohti kumppanuutta ilmentymä tai erityisratkaisu). Ns. yleisviestit voidaan ratkaisusta lähettää tämän lisäksi myös vastaanottajan määrittämään sähköpostiin. Toimenpidettä tai erityisesti luottamuksellista tietoa sisältävä viesti tallennetaan vain kumppanuustilille ja käyttäjille lähtee näistä vain yleisluontoinen ilmoitus käydä katsomassa kumppanuustililtä ko. viesti. Kumppanuustilillä tarkoitetaan Kohti kumppanuutta ratkaisussa (kaikissa ilmenemismuodoissaan kaikissa liitteissä) kuntalaisen geneeristä asiointitiliilmentymää, jota käytetään Kohti kumppanuutta ratkaisussa huoltajan tai perheenjäsenen palvelurajapintana lasta koskeviin sähköisiin palveluihin. Kohti kumppanuutta ratkaisuun ei ole tarkoituksellista toteuttaa erillistä kumppanuustiliä, vaan hyödyntää kunnan kaikissa asiointipalveluissa hyödynnettävää tiliä, jonka avulla kuntalainen pääsee omiin palvelutietoihinsa, asiointeihin (vireillepano, prosessin tila, lisätietopyynnöt ja päätökset) ja viestintäpalveluihin viranomaisen kanssa. Tästä syystä asiointitiliä ei ole määritelty kattavasti tässä dokumentissa. Kumppanuustili-käsitteeseen on kuvattu vain Kohti kumppanuutta ratkaisun tarvitsemia erityispiirteitä ko. geneerisestä asiointitilistä. Järjestelmä muistuttaa automaattisesti huoltajia ja käyttäjiä toimenpidepyyntöihin vastaamisesta ennen niille asetettua määräaikaa. Tämä on parametroitavissa toimenpidepyyntökohtaisesti. Käyttäjä pystyy normaalin sähköpostin tavoin lukemaan viestejä kumppanuustililtä sekä arkistoida ja poistaa sinne tulleita viestejä. Käyttäjä pystyy myös suorittamaan viestissä pyydetyn toimenpiteen kumppanuustilillä turvallisesti ja hallitusti. Näin esimerkiksi suostumuspyynnöt voidaan lähettää huoltajille joukkoviestinä ja kuitenkin yksittäiset suostumukset ovat aina huoltajakohtaisia. Keskitetyn viestintäratkaisun hyötyjä ovat: Viestintä on roolipohjaista. Esim. päivähoitoryhmän kaikki työntekijät (käyttövaltuuksien puitteissa) voivat nähdä, mitä viestejä ryhmän lasten

Viitearkkitehtuuri 34 (49) huoltajille on lähetetty, ketkä ovat vastanneet ja mitä on vastattu. Viestit eivät enää huku henkilökohtaisiin sähköposteihin Ratkaisu mahdollistaa keskitetyn vastausten ja toimenpiteiden seurannan. Työntekijä voi seurata, ketkä ovat vastanneet toimenpidepyyntöihin. Ratkaisu mahdollistaa viestipohjien kautta yksinkertaisen logiikan lisäämisen toimenpidepyyntöihin (esim. ilmoittautumisissa ilmoittautuneiden lukumäärän laskeminen) Ratkaisu mahdollistaa viesteissä välitettyjen toimenpiteiden liittämisen suoraan Kohti kumppanuutta järjestelmän käsittelylogiikkaan. Esim. suostumukset, kalenterivaraukset, ilmoittautumiset. Ratkaisu mahdollistaa viestinnässä riittävän tietosuojan Kaikki asiakas- ja viranomaisviestintä voidaan liittää tarvittaessa Kasvun ja kehityksen suunnitelmaan Kohti kumppanuutta ratkaisun käyttäjäviestinnän ydinperiaatteita voidaan hyödyntää myös muissa kunnan palveluissa. 5.3.7. Hakeminen kunnan palveluun Hakeminen kunnan palveluun tarkoittaa yleisesti ottaen kaikkia tilanteita, joissa kuntalainen täyttää hakemuksen tai ilmoituksen päästäkseen jonkin kunnan tarjoaman jatkuvan palvelun asiakkaaksi. Tulee huomata, että tämän lisäksi kunnissa on vaihteleva määrä erilaisia hakemuksia (esim. tonttihakemukset), jotka eivät liity tässä tarkoitettuun hakemiseen. Kohti kumppanuutta -ratkaisun näkökulmasta hakeminen kunnan palveluun tapahtuu seuraavissa tilanteissa: päivähoitoon hakeminen esiopetukseen ilmoittautuminen peruskouluun ilmoittautuminen koululaisten aamu- ja iltapäivätoimintaan hakeminen Kohti kumppanuutta -ratkaisun ensimmäisessä vaiheessa on suunniteltu toteutettavaksi päivähoitoon hakeminen. Tämä on mainituista ilmoittautumis- ja hakemismenettelyistä ainoa, jonka taustalla oleva operatiivinen järjestelmä (Effica Päivähoito) tarjoaa nykytilassa riittävät rajapinnat integraation toteuttamiseen. Liitteessä 7, Käyttötapausten kuvaus on kuvattu päivähoitoon hakemiseen liittyvät keskeiset käyttötapaukset. Kohti kumppanuutta -ratkaisun tarjoama keskeinen lisäarvo kunnan palveluiden hakemiseen on hakemuksen jättämisen helpottaminen. Huoltajan ei erikseen tarvitse täyttää esimerkiksi omia, lapsen ja perheen pohjatietoja kun ne saadaan järjestelmästä valmiina. 5.3.8. Ajanvarausten hallinta Yleisesti ottaen ajanvarauspalvelu on (keskitetty) ohjelmistopalvelu, jonka kautta on mahdollista varata aikoja palvelun taustalla oleviin järjestelmiin.

Viitearkkitehtuuri 35 (49) Ajanvarauspalvelu voi olla alueellinen ja paikallinen ja siihen voi liittyä esim. webkäyttöliittymä. Ajanvaraus on osa laajempaa resurssivarausten hallintaa. Jo ajanvarauksessa varataan tietylle aikavälille resurssi (yleensä esim. asiointikäynti, tapaaminen, liikuntapaikkavaraus tms.). Tätä voi laajentaa koskemaan myös fyysisiä esineitä ja tiloja (esim. liikuntavälineiden tai laitteiden lainaus tms.). Yleisesti ottaen resurssivarauksella tarkoitetaan tietyn varattavissa olevan resurssipoolin varaamista tietylle aikavälille tai tiettyyn ajanhetkeen. Edellä kuvattua ajanvarauksiin liittyvää problematiikkaa ja toteutusperiaatteita on käsitelty mm. SADe-ohjelmassa (Valtiovarainministeriön johdolla toteutettava Sähköisen asioinnin ja demokratian vauhdittamisohjelma) tuotetussa selvityksessä 4. Tämän esiselvityksen ja Lahden Fenix-hankkeessa tuotetun sähköisen ajanvarauspalvelun hyödynnettävyyttä Kohti kumppanuutta - hankkeessa on arvioitu Liitteessä 10, Kuntien KA-ratkaisujen hyödyntäminen. Lahden Fenix-hankkeessa toteutettu palvelu on tietyin reunaehdoin hyödynnettävissä myös Kohti kumppanuutta -ratkaisussa. Se ei kuitenkaan huomioi kaikkea ajanvarauspalvelun esiselvityksessä käsiteltyä problematiikkaa. Esiselvityksen periaatteita noudattavan ajanvarauspalvelun määrittely ja toteuttaminen on syytä nähdä Kohti kumppanuutta -ratkaisua laajempana kokonaisuutena. Näin ollen Kohti kumppanuutta -viitearkkitehtuurissa on kuvattu yleistä ajanvarauspalvelua rajatumpi toiminnallinen kokonaisuus. Tällä toiminnallisuudella voidaan tarjota Kohti kumppanuutta -ratkaisun käyttäjille auttava ajanvarausten perustoiminnallisuus ilman resurssivarauksia. Tämä perustoiminnallisuus on toteutettavissa ilman integraatiota taustalla oleviin järjestelmiin. Ajanvaraukseen liittyvä toiminnallisuus ja siihen liittyvät keskeiset käyttötapaukset on kuvattu tarkemmin Liitteessä 7, Käyttötapausten kuvaus. 5.3.9. Tapahtumaloki Tapahtumaloki taltioi järjestelmiin ja tiedon käsittelyyn liittyvät olennaiset muutokset ja käsittelyt. Mikäli käsitellään korkean tietosuojan alaista tietoa, tämän tiedon käsittely tulee kokonaisuudessaan kirjata tapahtumalokiin. Tapahtumaloki tarjoaa lokitusrajapinnan, jota kutsutaan kaikista tietoa käsittelevistä palveluista automaattisesti käsiteväylän kautta. Kaikki tietoa luovat, lukevat, muuttavat tai poistavat tapahtumat taltioidaan tapahtumalokiin. Tapahtumalokin kautta voidaan seurata, mitä tietoa missäkin tilanteessa kukakin käyttäjä on käsitellyt. Tapahtumalokiin on pääsy vain sen pääkäyttäjällä. Tapahtumaloki hyödyntää kokonaisuudessaan Kohti kumppanuutta ratkaisun käsitemallia ja esimerkiksi muutosten kohteet tallennetaan vain viittaustietoina tapahtumalokiin, jotta vältyttäisiin lain kieltämältä perusteettomalta tietojen ja rekisterien yhdistelemiseltä. Keskeisiä keskitetyn tapahtumalokin ominaisuuksia ovat: 4 http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/03_muut_asiakirjat/ajanvaraus_selvitys.pdf

Viitearkkitehtuuri 36 (49) Kattava muutosloki ja jäljitettävyys Kohti kumppanuutta -ratkaisu taltioi kaikki siihen tallennettujen tietojen ja dokumenttien käsittelyyn ja tallentamiseen sekä käyttöoikeuksien antamiseen, muuttamiseen ja poistamiseen liittyvät tapahtumat ja kirjaa tapahtumatiedot tapahtumalokiin automaattisesti. Lokitietojen muuttumattomuuden varmistaminen Ratkaisussa lokitiedot tallennetaan muualle kuin siihen tietokoneeseen ja tietovarantoon, jossa ne syntyvät. Lokitietoja säilytetään konekielisessä muodossa erillisessä tietovarannossa, johon on erilliset käyttövaltuudet. Tämä vähentää mahdollisten tietomurtojen jälkien peittelemistä. Lokitietojen seuranta ja raportointi Ratkaisuun voidaan liittää välineet määriteltyjen lokitietojen ja lokitapahtumien seurantaan ja raportointiin. Vain valtuutetuilla pääkäyttäjillä on pääsy lokitietoihin. Lokitietojen lajittelu ja näkymät Lokitietoja voi lajitella kohteen, tapahtumatyypin, tekijän ja tapahtuma-ajan mukaan. Lokitietojen salaaminen Lokitieto voidaan tarvittaessa salata. Lokitietojen käsittelyloki Korkean tietosuojatason takia lokitietojen käsittelystä pidetään erillistä salattua lokia, johon on erilliset käyttövaltuudet. Varsinaisen tapahtumalokin käsittelyyn oikeutetulla henkilöllä ei saa olla pääsyä lokitietojen käsittelylokiin. Näiden lisäksi mahdollisuuksien mukaan pyritään vielä taltioimaan käyttövaltuushallinnan lokitiedot, mikäli käyttövaltuuksienhallintaratkaisu tämän mahdollistaa: Käyttövaltuushallinnan lokitiedot Kaikista käyttövaltuuksien hallinnan toimenpiteistä tallentuu keskitettyyn tapahtumalokiin tietoa, jota voidaan käyttää käyttövaltuuksien valvonnassa. Varsinaisen tapahtumaloki ja lokitietojen käsittelylokin ns. adminkäyttötunnukset ja käyttäjät tulee siis eristää toisistaan, jotta vältytään ns. vaarallisilta työyhdistelmiltä. Lokitieto pitää kirjata ennen varsinaista palautetta käyttäjälle. Esim. tiedon hausta pitää tallentua ensin lokitieto ja sitten tämän perään tieto siirretään käyttöliittymään. Tapahtumalokin toteutukseen voidaan käyttää myös valmisohjelmistoa, joka täyttää edellä kuvatut vaatimukset ja lokia koskevat käyttötapaukset, sekä tarjoaa siihen dokumentoidun SOA-periaatteiden mukaisen rajapinnan.

Viitearkkitehtuuri 37 (49) 5.3.10. Sähköisen asianhallinnan liittäminen Kohti Kumppanuutta ratkaisuun Kohti kumppanuutta ratkaisun sähköiset asiointipalvelut tulee liittää kiinteästi osaksi kunnan sähköisen asianhallinnan ja sähköisen arkistoinnin kokonaisuutta. Mitä on viranomaisen asianhallinta Kunnan asiankäsittelykokonaisuudella tarkoitetaan toiminnallista kokonaisuutta, johon sisältyy asioiden valmisteluun, käsittelyyn ja päätöksentekoon liittyvät tehtävät sekä niihin liittyvät asiakirjat. Asiankäsittelyjärjestelmään tallennetut tai liitetyt asiakirjat yhdistyvät toimenpiteen tai käsittelyvaiheen kautta asiaan. Tiedon alkuperäisyys, eheys, luotettavuus ja käytettävyys pystytään takaamaan. Järjestelmä sisältää tai siihen on integroitu toiminnallisesti tai loogisesti toisiinsa liittyviä sovelluksia, sisäisiä tietovarantoja, palveluita tai toimistotyökaluja. Asianhallinnan kehittämisen lähtökohdaksi voidaan asettaa hyvä tiedonhallintatapa, joka on määritelty laissa viranomaisen toiminnan julkisuudesta. "Viranomaisen tulee huolehtia asiakirjojen ja tietojärjestelmien sekä niihin sisältyvien tietojen asianmukaisesta saatavuudesta, käytettävyydestä ja suojaamisesta sekä eheydestä ja muusta tietojen laatuun vaikuttavista tekijöistä. Viranomaisen tulee suunnitella asianhallintansa siten, että lainsäädännön vaatimukset otetaan huomioon." Asianhallintajärjestelmä määritellään tietojärjestelmäksi, jonka avulla organisaation (erityisesti julkishallinnollisen viranomaisen) käsittelemät asiat ja niihin liittyvät asiakirjat hallitaan ennalta määrättyjen käsittelysääntöjen mukaisesti. Järjestelmä on tarkoitettu pääasiassa asioiden ja dokumenttien hallintaan, asioiden etenemisen seurantaan, arkiston muodostamiseen sekä diaarin ylläpitoon. Järjestelmä mahdollistaa sähköisen asioinnin viraston ulkopuolelle ja siitä voidaan tehdä hakuja sekä asioihin että asiakirjoihin. Sähköisen asianhallinnan tavoitteena on, että asia voidaan käsitellä kokonaan sähköisesti tietojärjestelmän sisällä. Tietojärjestelmässä tehtävistä asioiden ja asiakirjojen käsittelyyn liittyvistä toimenpiteistä on tallennuttava kattavat merkinnät. Käsittelyprosessien suunnittelussa otetaan huomioon kirjausketjut, hyväksymismenettelyt ja prosesseihin liittyvät muut kontrollit. Monilla kunnilla on tavoitteena siirtyä hallitusti ja harkitusti yhä enemmän paperimuotoisista asiakirjoista sähköisiin. On kuitenkin huomattava, että jatkossakin kansalaisilla on oikeus asioida kunnan kanssa myös perinteisesti paperimuotoisesti. Yleensä tämä edellyttää kokonaisuutena suunniteltua, nykyaikaista asianhallinnan ratkaisua, jossa prosessien seuranta tehostuu, toimenpiteiden jäljitettävyys ja todistusvoimaisuus varmentuu, tiedot ovat ajantasaisina talletettuna vain kerran ja tietojen tarkoituksenmukainen käytettävyys kaikissa toiminnoissa on järjestetty. Sidosryhmät voivat asioida sähköisiä palveluita käyttäen. Asiakirjojen ja tietojen pitkäaikainen arkistointi sähköisenä, myös pysyvä säilytys osana kansallisarkistoa, on pystyttävä varmistamaan. Asiakirjallisen tiedon laatuvaatimukset

Viitearkkitehtuuri 38 (49) Asiakirjalliset tiedot dokumentoivat organisaation tehtäviä ja siten takaavat toiminnan jatkuvuuden ja jäljitettävyyden, siksi niiden todistusvoimaisuus on kyettävä varmistamaan. Todistusvoimaisuuden varmistamiseksi asiakirjallisten tietojen käsittelyyn ja hallintaan liittyy erityisvaatimuksia, jotka viranomaisympäristössä on määritelty lainsäädännössä. Näitä ovat tietojen laadun varmistaminen (alkuperäisyys, eheys, luotettavuus ja käytettävyys), julkisuuden ja salassapidon toteuttaminen, arkistointi ja hävittäminen. Arkistolaitos on antanut määräyksen (AL 9815/07.01.00/2008) sähköisten asiakirjallisten tietojen käsittelystä, hallinnasta ja säilyttämisestä. Tämä ns. SÄHKE-normi on päivitetty 1.1.2009. Nämä määräykset mahdollistavat asiakirjallisen tiedon tuottamisen, käsittelyn ja säilyttämisen yksinomaan sähköisessä muodossa. Näiden vaatimusten tarkoituksena on varmistaa asiankäsittelykokonaisuuden tuloksena muodostuvan sähköisen aineiston todistusvoimaisuus sekä tietojärjestelmistä tuotettavan siirtokokonaisuuden muodostuminen aineistoja siirrettäessä Arkistolaitokseen. Asiakirjahallinnan kokonaisuus muodostuu tiedonohjauksesta, asiakirjallisen tiedon käsittelystä ja hallinnasta sekä aineistojen siirron osa-alueista. eams, asiakirjallisen tiedon käsittelyprosessi, metatietomalli ja siirtorakenteet ovat kokonaisuuteen liittyvien metatietojen hallinnan välineitä. Asiakasrajapinnan sähköisiin palvelutietoihin on pystyttävä jatkossa liittämään sähköisen asianhallinnan edellyttämät metatietomääritykset. Nämä metatietomääritykset perustuvat asianhallinnan metatietomalliin, jossa asiakirjallisten tietojen elinkaarenhallintaa ohjaavien metatietojen on tallennuttava eamsin ohjaamana jo operatiivisen käsittelyn aikana. eams-ohjaus on toteutettava Arkistolaitoksen määräyksen mukaisesti. Asianhallintajärjestelmään voidaan toteuttaa myös operatiivista toimintaa tukevia metatietoja. Viranomaispäätösten ja asioiden sähköinen arkistointi edellyttää ko. eamsin määrittämien metatietojen kiistatonta tallentumista aina vireillepanosta lähtien (tyypillisesti hakemus tai ilmoitus). Alla on yleinen kaaviokuva asian muodostumisesta ja asiakirjojen sijoittumisesta asiaan:

Viitearkkitehtuuri 39 (49) Kuva 9. Asian muodostuminen Alla on vielä yleisluontoinen asian elinkaariprosessikuvaus: Aktiivivaihe Asian vireillepano Asian avaus Lopputoimenpide Väli toimenpide Oikeellisuuden toteaminen Passiivivaihe Historiallinen vaihe Tiedon muutoksien / muuttumattomuuden hallinta Kuva 10. Asian elinkaariprosessi Kuvailutieto Mitä sähköinen asianhallinta merkitsee Kohti kumppanuutta -ratkaisulle Kohti kumppanuutta ratkaisussa EI toteuteta kunnan sähköistä asianhallintaratkaisua eikä eamsin määrittelyä tai sen tarjoamia palveluita. Kohti kumppanuutta ratkaisun tietorakenteet ja palvelut tulee kuitenkin suunnitella ja toteuttaa siten, että sen avulla tehtyihin sähköisiin asiointitapahtumiin (sekä sisäiset että ulkoiset) voidaan myöhemmin liittää kun-

Viitearkkitehtuuri 40 (49) nan sähköisen asiankäsittelyn arkistonmuodostussuunnitelman (tiedonohjaussuunnitelman) eamsin mukaiset asioiden metatiedot osana laajempaa sähköisen asian- ja asiakirjahallinnan ratkaisukokonaisuutta. Tämä tarkoittaa erityisesti rakenteisia sähköisen asioinnin lomakkeita, joihin voidaan liittää myöhemmin määritettävät eams-metatiedot (ks. tietomalli edellä). On huomattava, että kyseinen vaatimus koskee myös viranomaisen tekemiä päätöksiä, lisätietopyyntöjä tms. virallisia toimenpiteitä myös sisäisissä Kohti kumppanuutta ratkaisun toiminnoissa (esim. opetussuunnitelman luominen tai päivitys). 5.3.11. Asiakastiedon päätietovaranto Asiakkaan perustiedot sisältävä perustietovaranto tarjoaa palvelurajapinnan kaikille operatiivisille järjestelmille. Tarkoitus on, että ajan myötä operatiiviset järjestelmät eivät sisällä asiakkaan perustietoja, ainoastaan asiakkaan IDtiedon ja osaavat tätä kautta hakea tarvittaessa perustiedot kunnan omasta asiakkaan perustiedon päätietovarannosta. Tarvittaessa ne pelkästään välimuistittavat tai tallentavat asiakkaan perustiedot omiin järjestelmiinsä. Yleinen periaate: Tavoitetilassa asiakkaan perustietoja suositellaan käytettävän seuraavasti: Perustietojen ydintiedot tulevat kansallisista perustietovarannoista VTJ:stä ja YTJ:stä (ja mahdollisesti esim. Tilastokeskuksesta) ajastettuina massasiirtoina Perustiedot tallennetaan kunnan omaan asiakastiedon päätietovarantoon (esim. Käsiteväylän käyttämään tietovarantoon) Samalla tallennetaan aikaleima tiedon muutoksesta tai päivityksestä Operatiiviset järjestelmät kutsuvat Käsiteväylään toteutettuja web service palveluja ja hakevat asiakkaan perustiedot tarpeen mukaan (tässä pyynnössä voi olla mukana myös tiedon ajantasaisuusvaatimus) MDS Asiakkaan perustiedot Palvelurajapinta, WS Asiakkaan perustieto Haku ajastettuna eräajona Metatiedot Jos tietoa ei löydy kunnan asiakastiedon päätietovarannosta tai se on liian vanha kyseisen prosessin vaiheeseen, Käsiteväylän palvelu hakee tiedon kertahakuna kansallisesta perustietovarannosta, esim. VTJ:stä, tallentaa sen ja palauttaa tiedon operatiiviselle järjestelmälle. Tämä on täysin läpinäkyvä operatiiviselle järjestelmälle. Operatiivisen järjestelmän kannalta asiakkaan perustiedon tarjoaa Käsiteväylän tietopalvelu. VTJ Ajantasahaku palvelurajapinnasta