• Palaute koskien dokumenttia Yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuri
      • Terveyden ja hyvinvoinnin laitos THL, THL/TIPO
        Uppdaterad:
        19.4.2019
        • Yleiskommentti: Sekä toimijakenttä että järjestelmätuotteet nojautuvat joillakin tietoalueilla (kuten sote-palvelut / terveydenhuolto) vahvasti myös kansainvälisiin ratkaisuihin ja standardeihin. Lähtökohtana ei voida pitää sitä, että julkinen hallinto pystyisi määrittelemään vaatimukset, tietosisällöt ja ratkaisut esimerkiksi lääketieteen eri erikoisaloille tai sote-palvelujen tuottajien tai asiakkaiden moninaisiin tarpeisiin. Esimerkiksi sote-palvelujen keskeisin kansainvälinen SNOMED CT -terminologia sisältää yli 300 000 aktiivista käsitettä ja sote-palveluissa hyödynnettyjä HL7- ja IHE-standardeja hyödyntäviä ohjelmistotuotteita on satoja sekä Suomessa että kansainvälisesti. Näiden standardien ja ratkaisujen sisältämiä käsitteitä tai tietomalleja ei ole mahdollista eikä realistista korvata kansallisesti julkisen hallinnon lähtökohdista määritellyillä ratkaisuilla. Yleiskommentti: Markkinanäkökulma tiedonhallintaratkaisuihin puuttuu dokumentista. Dokumentti näyttää lähtevän virasto- ja viranomaislähtöisestä ajattelutavasta, jossa perusoletuksena on kunkin viranomaisen tietotarpeisiin räätälöity tietojärjestelmä. Tämä lähestymistapa ei erityisesti edistä tavoitteena olevaa horisontaalista tiedonhallintaa. Julkisten ja yksityisten palvelujen sekä kolmannen sektorin sote-kenttä on esimerkki toimialasta, jossa on välttämätöntä hyödyntää markkinoiden kyvykkyyksiä ja markkinoilla tuotteistettuja tietojärjestelmäpalveluja sekä ohjelmistotuotteita erityisesti palvelujen tuottajien ja järjestäjien toiminnassa. Markkinakyvykkyyksien hyödyntäminen myös asiakasrajapinnassa (kuluttaja) tulee mahdollistaa, esimerkkinä Kanta Omatietovaranto –Mydata ja siihen liittyvät hyvinvointisovellukset. Yleiskommentti: Nykytilasta todetaan, että yhteiskunnassamme lähes kaikki tieto on organisaatiokohtaisesti siiloutunutta, ja tulevaisuudessa tarvitaan tämän sijaan tietoekosysteemeja. Arkkitehtuurikuvaus lähettää viestin, että yhteentoimivaan ekosysteemimalliin päästäisiin tiedonhallintaa ja tietoon liittyvää hallintoa lisäämällä. Ekosysteemit syntyvät tyypillisesti kontrolloimatta, ei hallinnan lisäämisen kautta, ja tilanteissa, joissa kaikki ekosysteemissä mukana olevat toimijat hyötyvät yhteistyöstä. Kun tarkastellaan politiikka- ja ohjausvalmistelua, palvelunjärjestäjia, palveluntuottajia ja asiakkaita, avainkysymys on, mitkä ovat näiden yhteiset interssit, että ekosysteemi syntyisi. Tyypillisesti selkeä hyöty, esim. taloudellinen hyöty, ajaa kohti yhdenmukaista toimintaa ja yhteisiä tietorakenteita. Yleiskommentti: Arkkitehtuuri käsittelee vain määriteltyä, strukturoitua ja hallittua tietoa. Kuvattu arkkitehtuuri ei tarjoa juuri mitään heikosti strukturoidun massadatan hallintaan ja sen hyödyntämiseen, vaikka se on kasvavana pidetty alue. Esim. tiedon käyttö ongelman löytämiseen ja tekoäly ovat vain mainintoina mukana. Yleiskommentti: Yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuri on geneerinen ja abstrakti kuvaus, josta on paikoitellen vaikea saada otetta ilman esimerkkejä. Mistä tiedosta dokumentissa puhutaan ja millä rajauksilla. Nyt siitä ei käy ilmi koskeeko tämä kaikkea mahdollista tietoa vai ainoastaan julkisen hallinnon tietoja ja millä toimialoilla jne. Epäselväksi jäi kuka on asiakas ja missäkin tilanteessa sekä se kenen näkökulmasta tarkastellaan, kun tarkastellaan asiakasnäkökulmasta? Tämä siitäkin huolimatta, että käsitteenä asiakas on määritelty. Vaikka keskiössä on tietoarkkitehtuuri, olisiko tarpeen tunnistaa, nimetä tai kuvata jotain toiminta-arkkitehuurin elementeistä (esim. palveluja kun tietoarkkitehtuuri on haluttua kuvata palvelulähtöisesti). Epäselväksi jää, mihin tämä arkkitehtuuri sijoittuu lueteltujen sidosarkkitehtuurien kentässä. Dokumentissa ei ole kuvattu myöskään keskeistä ohjaavaa lainsäädäntöä, jonka vuoksi dokumentin mahdollinen velvoittavuus jää epäselväksi. Työssä viitataan toiseen osioon, joka kuvaa tavoitetilaa 2029, epäselväksi jää missä tämä tavoitetila on tarkoitus kuvata. Luku 1: Tuleeko kaikki olennainen esille neljästä eri näkökulmasta (Politiikka ja ohjaus, palvelunjärjestäjä ja palveluntuottaja sekä asiakas) vai puuttuuko jotain esim. tutkimus, valvonta jne.? Riittääkö yhteisen tietopohjan tarkastelu tiedon ohjaamisen, seurannan ja johtamisen tasoilla? Ainakin muut tasot tulisi ottaa huomioon ja tunnistaa riippuvuudet niihin esim. ensisijainen käyttö (asiakastyö) sitä säätelevä lainsäädäntö. Luku 1.4: Kuva 5 esittää mallin vahvasti määritellylle, strukturoidulle ja tiukasti hallitulle tiedolle. Tietoa on muunkinlaista, esim. heikosti strukturoitua massadataa,ja sen muodostuminen ei välttämättä tapahdu kuvan esittämällä tavalla. Luku 1.5: Horisontaalinen tiedonhallinta toteutuu jo mm. sote-tietoalueella kansallisten tietojärjestelmäpalvelujen kautta (Kanta), jota kautta erittäin suuri joukko toimijoita (mm. kaikki julkisen terveydenhuollon yksiköt ja apteekit, merkittävin osa yksityisten terveyspalvelujen tuottajista, enenevässä määrin sosiaalihuollon palveluntuottajat) jakavat yhteisten käsitteiden, määrittelyjen ja rajapintojen kautta määriteltyjä tietoja keskitettyjä tietovarantoja hyödyntäen. Sote-tietoalueella myös tämän laajan toimijakentän ohjaukseen säädösten (lait, asetukset, määräykset), arkkitehtuurin, yhteisten määrittelyjen sekä monipuolisten koulutus- ja tukirakenteiden kautta on toimivia malleja. Luku 1.6: Päätietoryhmät voivat tuottaa käsitteellisellä tasolla hyötyä arkkitehtuuriohjauksen ja kokonaisuuden jäsentämisen näkökulmasta. Ne eivät kuitenkaan ole riittävä keino konkreettisten tietovirtojen tai ratkaisujen määrittelemiseksi, vaan tietovirtojen ja ratkaisujen määrittelyissä on lähdettävä konkreettisista käyttötapauksista, jotka toki voivat perustua myös elämäntilanteisiin. Tarkemmat määrittelyt tietovirtojen ja rajapintojen toteuttamiseksi ovat aina kontekstisidonnaisia. Luku 1.6: Tietotuotteet ovat hyödyllinen käsite erityisesti johtamisen ja ohjauksen sekä operatiivisesta toiminnasta tietoja koostavien palvelujen näkökulmasta. Varsinaisten operatiivisten prosessien ja palvelujen tietovirtojen kuvaaminen tietotuotteina ei ole luontevaa (vaikka sinällään onkin mahdollista), koska tämä monimutkaistaa konkreettisten ratkaisujen toteuttamista. Rajapinnat ja niiden tietosisällöt käyttötapauskohtaisesti Luku 1.6: Ajatus siitä, että ”asiakas johtaa omaa toimintaansa” nojautuu positivistiseen oletukseen kansalaisen rationaalisesta ja suunnitelmallisesta toiminnasta. Hyvinvointipalvelujen ja kuluttajakäyttäytymisen tutkimuksessa on havaittu, että esimerkiksi terveyteen ja elintapoihin vaikuttavat terveyskäyttäytymisen muutokset eivät voi täysin nojautua tällaisiin oletuksiin tai ohjaukseen, vaan yksilöllä on vapaus toimia haluamallaan tavalla ja myös tiedollinen itsemääräämisoikeus. Tietojen saatavuus ja yhdistäminen on yhdistettävä motivoivien, houkuttelevien ja palkitsevien sekä todellisia tarpeita täyttävien palvelujen suunnitteluun ja toteuttamiseen, joka ei voi tapahtua vain viranomaisten kautta. Myös esimerkiksi kansainvälisten teknologiajättien kiinnostus hyvinvoinnin kuluttajamarkkinoihin ja johtavien terveysteknologiayritysten osaamisen hyödyntäminen on otettava huomioon. Nämä toimijat eivät seuraa yksittäisten valtioiden arkkitehtuuri- tai menetelmäkehikoita, mutta voivat jossain määrin perustaa toimintansa esimerkiksi kansainvälisten standardien hyödyntämiseen. Luku 1.7: On erittäin tärkeää ja kannatettavaa, että tietoarkkitehtuurissa ei yritetä tunnistaa kaikkia tietomalleja tai käyttötapauksia, ja että eri osapuolet saavat edelleen vapaasti valita, millä ja kenen ylläpitämillä järjestelmillä tietoa käytetään (kuten dokumentissa on kuvattukin). Luku 2.1.1: Tiedon tuottamisen näkökulmaa tulisi vahvistaa dokumentissa. Tietotuotteiden laatu perustuu lähtötietojen laatuun. Tietojen kokoaja, kirjaaja ja tälle annettava tuki ja palaute ovat tiedon laadun näkökulmasta avain koko ketjun toimivuuteen ja haluttujen vaikutusten saavuttamiseen. Tämä asia ei näy tiedon hallinnan syklin jäsennyksessä vielä riittävästi. Luku 2.1.2: On hyvä, että dokumentissa on rajauduttu entitettitason ja yksittäisten tiedonhallintayksiköiden tietomallien ulkopuolelle. Tarkkoja tietomalleja tarvitaan kuitenkin myös rajapinnoissa, jotta yhteentoimivuus käytännön prosesseissa ja tietotarpeissa toteutuu käytännössä. Näiden käyttötapaus- ja rajapintakohtaisten mallien tarkka määrittely on keskeinen osa esimerkiksi sote-tietoalueen yhteentoimivuuden kansallista ohjausta. Luku 2.2.1 Kuva 11: Jos tiedonhallinta perustuu verkostoihin, niin kuka tätä tietoa oikeasti hallitsee ja varmistaa tietotason yhteentoimivuuden? Onko ekosysteemi ja organisaatiokohtaisuus ainoat vaihtoehdot, kuten nyt esitetään? Tämän ekosysteemiajattelun pohjaksi kaipaisi lisää perusteluja. Onko verkostomaisessa ekosysteemimallissa riskinä, että tietoja ei jaeta, jos se ei hyödytä toimijan omaa liiketoimintaa? Luku 2.3.1Taulukko 3 Yhteistä tietopohjaa ohjaavat määritykset ja standardit: viittaukset https://yhteentoimiva.suomi.fi/fi/ sivustolle: herää kysymys miten näkyy jo olemassa olevat sosiaali- ja terveydenhuollon koodistot, luokitukset, standardit . Luku 2.3.3. Päätietoryhmät Kuva 21 Päätietoryhmät on hyvä ja selkeä, ja tietoarkkitehtuurityön kannalta hyödyllinen jäsennys. Luku 2.3.4: Kuvan 23 esittämät tietoryhmät ja niiden alalajit on ansiokas jäsennys ja siitä on hyötyä tietoarkkitehtuurityössä. Palvelutieto -> laatutieto -> pitäisikö olla myös vaikuttavuustieto? Vaikuttavuus ei nouse dokumentissa riittävästi esille tietotarpeena, vaikka vaikuttavuus on kuitenkin yksi tärkeimmistä käsitteistä kun palveluja järjestetään – tehdäänkö oikeita asioita oikeilla tavoilla. Tietolajit eivät ole ihan selviä ilman että niitä selitetään. Mitä ovat esimerkiksi Asiakastietoon sisältyvä Sosiaaliset yhteydet tai Terveys? Luku 2.4.1: Kuva 25 herättää kysymyksen, miten siinä sijoittuu tutkimustieto. Sijoittuuko se tutkimusaiheittain, esim. niin että sosiaali- ja terveydenhuollon tutkimustieto kuten THL:n väestötutkimukset kuuluvat geneeriseen sosiaali- ja terveyenhuollon tietovarantoon. Luku 2.4.3: Kuvan 29 esittämä malli vaikuttaa toimivalta tyypillisimpien erityisesti hallintoon liittyvien tietojen kannalta. Monet THL:n hoitaman substanssin kuten valtion erityispalveluiden, laboratoriotoiminnan ja väestötutkimuksen kannalta tämä ei vaikuta erityisen hyödylliseltä, kun yhteiskäyttöalueelta saadaan toimialakohtaiselle alueelle luultvasti vain rippeitä. Luku 3 Termit ja määritelmät: Määritelmien/kuvausten lähdetiedot olisi hyvä kirjata auki. Nyt määritelmät/kuvaukset tuntuvat vain tätä dokumenttia varten laadituilta, mikä sinänsä herättää kysymyksen, miksei tässä ole hyödynnetty olemassa olevia sanastoja dokumentin oman ideologian mukaisesti.
      • Työ- ja elinkeinoministeriö, Alueet ja kasvupalvelut osasto/Digitalisaatio ja tietoryhmä, Alitalo Sirpa
        Uppdaterad:
        18.4.2019
        • Kiitos mahdollisuudesta lausua asiakokonaisuudesta, jossa pureudutaan yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuriin. TEM pitää hyvänä, että tietopohjaa käsitellään dokumentissa useista eri näkökulmista tiedolla johtamisesta, palvelujen järjestämiseen, tuottamiseen ja hyvään asiakaslähtöiseen asiakaspalveluun saakka. Tietoarkkitehtuuri on keskeinen myös digitalisaation, automaation, robotiikan sekä tekoälyn hyödyntämisen näkökulmasta. Lausuttavan dokumentin ajankohtaisuutta ja luettavuutta tosin heikentää sen kytkeytyminen rauenneeseen maakuntauudistukseen, vaikka tietopohjaa koskevia huomioita ja havaintoja voidaankin pitää rakenneriippumattomina. Yksityiskohtaiset havainnot: Toivotaan, että dokumentissa olevaan kappaleeseen ”3. Termit ja määritelmät” koostetaan/kerätään keskitetysti dokumentissa esitetyt käsitteet ja niiden tarkemmat määritykset. Nyt käsitteitä ja määrityksiä on esitetty mm. kuvan ja taulukkojen yhteydessä. Käsitteitä on esitetty seuraavasti: - Kuva 1: Asiakkuus -käsite - Taulukko 1. sisältö - Taulukko 3. sisältö - Taulukko 4. sisältö Seuraaviin käsitteisiin toivotaan selvennystä ja täsmennystä, mitä listatuilla käsitteillä tässä asiayhteydessä tarkoitetaan. Vastaavasti nämä käsiteet ja niiden määritykset voisi lisätä dokumentin kappaleeseen ”3. Termit ja määritelmät”. Lista käsitteistä, joihin toivotaan täsmennystä ja tarkempia määrityksiä: - Asiakas –määritelmä (yritysrooli ei näkyvissä) - Arkkitehtuuriperiaate - Johtamisfunktiot - Tiedonhallintayksikkö - palveluajattelu vs. palvelulähtöisyys - palveluntuotantorakenne - Yksilöllinen tunnisteellinen tieto - Toimintatieto - Tapahtumatieto - Palvelutieto - Käytettävyystieto - Vaikuttavuustieto - Tietomalli - Rajapinta - Tietotuotanto - Horisontaalinen tiedonhallinta (vrt. tiedonhallinta yleisesti) - Vertikaalinen tiedonhallinta (vrt. tiedonhallinta yleisesti) - Päätietoryhmä - Tietoryhmä - Ryhmä - Looginen rekisteri - Fyysinen rekisteri - Toimintaverkosto - Tietoresurssi - Toimintaympäristö - Integraatio - Kohdealuetaso - Toiminnan kohdealue - Käsitteellinen taso - Entiteettitaso - Tietovaranto - Ekosysteemi - Tietoekosysteemi - Verkosto - Asiakaslähtöisyys - Palvelumuoto - Ihmiskeskeinen tiedonhallinta - Ydinkäsite - Tiedon verkosto-ohjaus - Tarvelähtöisyys - Alusta - Loogiset tietovarannot - Tietovirrat - Eri yhteentoimivuudet (semanttinen, rakenteellinen, syntaktinen, tekninen) - Yksilökohtainen tieto (Huom: myös dokumentin tekstiosuudessa on auki purettu käsitteiden määrityksiä ja myös ne olisi hyvä lisätä dokumentin kappaleeseen ”3. Termit ja määritelmät”.) Kappaleessa 1.6 Loogisen yhteisen tietopohjan tarve Kappaleessa ”1.6. Loogisen yhteisen tietopohjan tarve” puhutaan ihmislähtöisyydestä ja elämäntapahtumista. Mikä on tämän työn ja AuroraAI tekoäly-hankkeen välinen suhde? Onko edellä mainituilla asioilla keskinäinen riippuvuus? Jos ja kun on, miten tämä riippuvuus tullaan ottamaan jatkossa huomioon? (AuroraAI tekoäly –hankkeessa olennainen osa on ihmislähtöisyys ja elämäntapahtuma-ajattelu.) Kappale 2. Nykytila 2021 Kappaleessa ”2. Nykytila 2021” todetaan, että ”Yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuria muodostettaessa joudutaan soveltamaan kokonaisarkkitehtuuria useamman toimijan näkökulmasta, jolloin tietoarkkitehtuuria ei voida määrittää yksityiskohtaisesti vaan yleisellä tasolla.” Onko tässä vaarana se, että tietoarkkitehtuuri jää liian ylätasolle ilman tarkempaa konkreettisuutta? Toimijat, jotka jatkossa tulevat hyödyntämään dokumenttia ja siinä kuvattuja asioita tarvitsevat konkretiaa, jotta saavat asioita tehokkaammin ja paremmin edistettyä. Liian ylätasolla olevat asiat konkretisoituvat siellä ”ruohonjuuri tasolla”, kun ollaan lähellä varsinaista operatiivista tekemistä. Kuviin 13 ja 14 täydennettäväksi: Maakunnallisten kasvupalvelujen (työvoima- ja yrityspalvelujen) tiedolla johtamisen hanke: Hankkeen tavoitteena on tuottaa ministeriöiden ja virastojen, alueiden/ maakuntien, ELY-keskusten, TE-toimistojen ja palveluntuottajien käyttöön maakunnallisten kasvupalvelujen (työvoima- ja yrityspalvelujen) tiedolla johtamisen kokonaisuus sisältäen tietovaraston ja BI-raportointiratkaisun, joka mahdollistaa - palveluista saadaan johtamisen, ohjauksen ja seurannan tueksi tietoa toiminnasta, taloudesta, vaikuttavuudesta, tehokkuudesta ja laadusta - tuotettava tieto on ajantasaista, luotettavaa ja vertailukelpoista - kehittyneen data-analytiikan, automatiikan ja tekoälyn hyödyntämisen Kappale 2.3.1 Käsitteistö Kappaleessa ”2.3.1 Käsitteistö” puhutaan ylätason käsitteistöstä ja siitä, että sen tulisi perustua yhteiseen sanastoon. Tarkoitetaanko sillä mm. yhteentoimivuusalustalla olevaa sanastoa? (Julkishallinnossa tällä hetkellä on useita eri sanastoja eri paikoissa, kuten esim. Finto, YSA, YSO, JHS sanasto jne.). Tässä yhteydessä olisi hyvä tuoda esiin, että lähtökohtaisesti ei luoda uusia sanastoja vaan täydennetään ja käytetään olemassa olevia yhteisiä sanastoja. Kuva 19 ja taulukko 3: YTI-käsitteellä viitataan päättyneeseen YTI-hankkeeseen, joten voisiko sen käsitteen poistaa kuvasta ja taulukosta? Jatkossa olisi hyvä puhua yhteentoimivuusalustasta ja –menetelmästä? (Muita aiheeseen liittyviä käsitteitä mm. y-työkalu, yhteentoimivuustyökaluista, YTI-menetelmä tms.? Nämä edellä mainitut käsitteet olisi muutenkin hyvä selkeyttää nyt, kun niitä käytetään eri asiayhteyksissä ristiin.) YTI-menetelmästä puhutaan vielä toimenpide-ehdotukset –dokumentissa, metatiedon-hallinta –otsikon alla. YTI-viittaus samassa dokumentissa yhteentoimivuus –otsikon alla. Kuva 23. Tietoryhmät ja niiden tietolajit Onko kuvan sisältämän tietoryhmittelyn käyttö esimerkki vai onko sisältö jo kiinnitetty? Miten dokumentissa olevaa ryhmittelyä on tarkoitus hyödyntää vai onko se pelkkä ehdotus/esimerkki? Ympäristö- ja infrastruktuuritieto –päätietoryhmä Liikenne-tietoryhmä: Tietolajeina nyt liikennetieto, rautatiet, tieverkko, vesiliikenne. Pitäisikö tässä huomioida myös ilmailu? Sisältääkö liikennetieto myös tiedot liikennöinnistä? Mihin päätietoryhmään/tietoryhmään kuuluu liikennöintiin liittyvät liikennevälineet, jotka kattavat eri liikennemuodot: ilmailu, vesiliikenne, raideliikenne ja tieliikenne? Mihin päätietoryhmään/tietoryhmään kuuluu, esim. eri lupa, kelpoisuus ja eri kortti/lupakirja/pätevyyskirja tiedot? Nyt kuitenkin pätevyystieto on huomioitu koulutustietopäätietoryhmässä. Jos myös ajattelee eri tutkintotietoja niin pitäisikö tutkintotiedot olla ja näkyä koulutustiedoissa? Entäpä koetiedot (kokeiden kysymystiedot ja vastaustiedot ovat eri tietokokonaisuuksia, vaikka ne liittyvätkin toisiinsa)? Voiko asiakkaalla olla eri rooleja eri tilanteissa? Missä tämä roolitieto nyt näkyy? Asiakas viittaa vahvasti henkilöön, yritys asiakkaana on käsitelty eri tavoin. Sisältääkö toimialatieto-tietoryhmässä oleva kohta ”yritys- ja elinkeinotiedot” yrityksiin/yhteisöihin liittyvät perustiedot, esim. Y-tunnus, yhteystiedot jne.? Olisiko selkeämpää laittaa yritys asiakastietopäätietoryhmään ja tehdä jako ”henkilö” ja ”yritys”? Tosin yritys voi toimia myös jossakin muussa kuin ns. ”asiakas”-roolissa. Rakennettu ympäristötieto -tietoryhmä ja tieto- ja sähköverkot, sisältääkö edellä mainittu kohta viestintäverkot? Olisiko selkeämpää erottaa tieto- ja viestintäverkot omaksi kohdakseen ja sähköverkko omaksi kohdakseen? Missä kohtaa huomioidaan olosuhdetiedot, jotka sisältävät mm. säähavaintoihin, meri-havaintoihin, ilmanlaatuhavaintoihin, ennusteisiin, tiesäähän sekä ympäristötietoihin (sis. mm. melutiedot) liittyviä tietokokonaisuuksia/tietoja? Pitäisikö jossakin kohtaa huomioida myös rike- ja rikostiedot, esim. kohdassa tilanne- ja hyvinvointitiedot? Edellä mainituilla tiedoilla voi olla vaikutuksia, esim. eri lupien myöntämisiin tai peruttamiseen tms.? Tietolajit: miten ne tullaan määrittelemään, esim. työtieto, työttömyysmäärä jne.? Mistä ne muodostuvat? Miten tämä sopii yhteen Yhteentoimivuusalustalla olevaan tietomalliin? Muita huomioita: Nyt useassa kohtaa toistetaan tarkastelunäkökulmat. Onko se välttämätöntä? Raportista on tarpeen tarkistaa maakunta uudistuksen raukeamisen vaikutukset.
      • Väestorekisterikeskus, Yhteentoimivuusalusta
        Uppdaterad:
        18.4.2019
        • Selvitys luo tarpeellisia suomenkielisiä käsitteitä tiedolla johtamiseen tietoarkkitehtuurin näkökulmasta. Se on sisällöltään asiantunteva ja monipuolinen. Teksti on kuitenkin usein vaikeaselkoista ja tuntuu, että sitä pitäisi vielä tiivistää ja selkeyttää. Dokumentissa on paljon kielioppi- ja kirjoitusvirheitä, jotka hankaloittavat tekstin ymmärtämistä. Tietoarkkitehtuurityössä on tarpeellista käyttää yhteistä terminologiaa. Siksi tässä selvityksessä esitettyjä käsitteitä pitäisi yhdistää JHS 179:ssä kuvatun semanttisen yhteentoimivuuden viitekehyksessä käytettyihin käsitteisiin. Yksityiskohtaiset kommentit: Luku 1.4 kuva 3: Nuolen merkitys kuvassa epäselvä. Asiaa voisi selventää se, jos ylempänä olevissa tarkastelunäkökulmissa kuvaisi tarkemmin toimijan tietotarpeita. Erityisesti "Palvelutieto" ja nuolen suunta epäselvä tässä yhteydessä. Kaaviossa esitetyt nuolet pitäisi kuvata ylemmässä tekstissä jokaisen toimijan näkökulmasta, jotta kaavio olisi ymmärrettävä. Luku 1.6: Listasta puuttuu kuvaus ministeriöiden ja virastojen tarvitsemista tietotuotteista ja tuottamista rajapinnoista. Eri ministeriöiden tuottamat kansalliset aggregoidut vertailukelpoiset tiedot ovat tärkeitä tiedolla johtamisen välineitä. Lisäksi tiedot ovat tarpeellisia palvelunjärjestäjille oman toiminnan vertailussa muihin toimijoihin. Luku 2.1.3 kuva 10: Käsiteltävistä aiheista puuttuu soveltamisprofiilit. Soveltamisprofiilit pitäisi kytkeä tietotuotteiden tietosisällön dokumentointiin. Luku 2.3: Tiedonhallintayksikkö kuvataan vasta tässä luvussa, mutta viittauksia on jo aiemmin. Voisi lisätä myös "Termit ja määritelmät" osioon. Luku 2.3.1 kuva 19: Päätietoryhmien ja tietokomponenttien välinen suhde tulisi tarkentaa. Mitä tässä tarkoitetaan päätietoryhmien soveltamisella ja tarkentamisella? Viimeisessä kappaleessa voisi tarkentaa soveltamisprofiilin merkitystä myös tietotuotteen sisällön kuvaamisessa. Soveltamisprofiili on dokumentaatio siitä, miten yhteisiä tietomäärityksiä sovelletaan tiedon säilyttämisessä, käsittelyssä tai siirtämisessä. Soveltamisprofiilin avulla voi siis kuvata esimerkiksi rajapinnan kautta tarjottavan tietotuotteen tietosisällön. Luku 2.3.1 taulukko 3: YTI-lyhenne tarkoittaa YTI-hanketta. Parempi sana nykyään olisi Yhteentoimivuustalusta. Luku 2.3.5: Lause "Yhteentoimivuus saavutetaan eri yhteentoimivuusmenetelmien avulla" kuulostaa omituiselta. Mitä tässä yritetään sanoa? Ehdotus: Poistetaan lause tai tarkennetaan ymmärrettäväksi. Esim. Tietojärjestelmien välinen yhteentoimivuus voidaan saavuttaa erilaisten menetelmien avulla. Lause "Käsitteellinen ja semanttinen yhteentoimivuus mahdollistaa koneluettavan muodon tiedolle, joka tukee yhteentoimivuusalustaa ja tiedon hyödyntämistä." on vaikeasti tulkittavissa. Voisiko käyttää vain termiä semanttinen yhteentoimivuus tai käsitteellinen yhteentoimivuus? Miten ne mahdollistavat koneluettavan muodon tiedolle? Mikä tukee yhteentoimivuusalustaa ja tiedon hyödyntämistä? Ehdotus: Käsitteellinen yhteentoimivuus mahdollistaa koneluettavan tiedon tulkitsemisen viestin vastaanottajan toimesta. Luku 2.3.5 kuva 24: Tietoalueet on muodostettu julkisen hallinnon palveluluokituksen ylintä tasoa käyttäen (http://finto.fi/ptvl/fi/page/?uri=http://urn.fi/URN:NBN:fi:au:ptvl:). Kuvaan viitataan aiemmin "tietoryhmien ja alueiden yhteistoiminnallinen kehys". Mikä on tietoalueiden ja tietoryhmien välinen suhde? Onko tarkoitus korvata nykyinen tietoalueluokittelu tässä selvityksessä määritellyillä päätietoryhmillä? Luku 2.4.2 kuva 26: Kuvassa on esitetty soveltamisprofiilin ja tietotuotteiden välinen suhde tekstillä: ”Soveltamisprofiili on tietomääritys, jota käytetään olemassa olevan tietomallin tarkennuksena tai laajennuksena.” Ehdotus: ”Soveltamisprofiili on tietotuotteen tietomalli, joka hyödyntää tietoalueelle määriteltyä yhteistä tietopohjaa.” Lisäksi tarkennettava lause: ”Tiedon hyödyntäminen perustuu tiedonhallintayksiköiden tietotuotteisiin, jotka muodostuvat soveltamisprofiloinnin kautta hyödyntäen yhteistä tietopohjaa.” Ehdotus: ”Tiedon hyödyntäminen perustuu tiedonhallintayksiköiden tietotuotteisiin, jotka voidaan harmonisoida ja dokumentoida määrittelemällä soveltamisprofiili, jossa hyödynnetään yhteistä tietopohjaa. Tietopohja määritellään tietoalueittain tietokomponenttikirjastojen avulla.” Huom! Dokumentissa ei puhuta tietokomponenttikirjastoista. Tietokomponenttikirjastojen merkitys yhteisen tietopohjan määrittelyssä tietoalueelle on kuvattava selvityksessä. Luku 2.4.3: Mitä ontologialla tarkoitetaan tässä asiayhteydessä? Miten ontologia eroaa esim. koneluettavasta sanastosta? Lisättävä "Termit ja määritelmät" osioon. Taustaa tuntemalla voi tehdä oletuksen, että tässä tarkoitetaan SKOS ontologioita eli koneluettavia asiasanastoja. Samaan kuvaan (kuva 27) tulisi lisätä myös koodistot, jotka ovat yhteisiä sopimuksia tietosisällön arvoista ja semantiikasta. Kuva 28: Tietoryhmien ja tietolajien suhde tietokomponentteihin on epäselvä. Tarkennettava lausetta: "Tässä dokumentissa tietoryhmät ja niiden tietolajit ovat keskeisiä tietomallinnuksen tietokomponentteja, joita yhteiskäyttöiset sanastot ja käsitteet määrittävät." Miten tietoryhmät ja tietolajit muodostavat tietokomponentteja? Tarkoitetaanko tässä, että tietolajeista voidaan muodostaa tietokomponentteja? Tietokomponentit ovat tiettyyn tietoryhmään liittyviä tietokokonaisuuksia, joita voidaan uudelleenkäyttää ja tarkentaa soveltamisprofiileissa. Soveltamisprofiili kuvaa jotain tietotarvetta yksittäisen tietojärjestelmän näkökulmasta. Soveltamisprofiilin avulla voidaan kuvata esimerkiksi jokin tietotuote. Kuvassa loogisten tietomallit (soveltamisprofiilit) viitataan pelkästään tietovarantoihin. Soveltamisprofiilin avulla voidaan kuitenkin kuvata myös tietovarannosta tuotettavia tietotuotteita eli esim. rajapintojen tarjoamia tietosisältöjä. Kuva 29: Kuva näyttää olevan sovelma JHS 179 Liite 8. Kuva 2: Yhteentoimivuusmenetelmä. Menetelmään on esitetty uusia näkökulmia, mutta tietokomponenttien ja päätietoryhmien suhdetta toisiinsa ei ole kuvattu selkeästi. Mitä tarkoittaa: Päätietoryhmä -hyödyntää-> Tarkennettu tietokomponentti? Ehdotus: Tietokomponenttikirjastoja voidaan lajitella päätietoryhmiin ja tietoryhmiin. Tietokomponentit voidaan luokitella tietolajeihin. Yhdestä tietolajista voidaan muodostaa useita tietokomponentteja. Tietokomponentti on uudelleenkäytettävä luokka tai ominaisuus, joka kuvaa tietyn tietolajin tietotarpeita ja rakenteita. 2.5 Taulukoiden asettelu tekee tekstin lukemisesta ja ymmärtämisestä vaikeaa.
      • Sosiaali- ja terveysministeriö, STM OHO / DITI, Huovila Mikko
        Uppdaterad:
        18.4.2019
        • Dokumentissa on ansiokkaita jäsennyksiä tiedonhallinnan kokonaisuudesta, tiedon muodostumisesta ja käytöstä. Haasteena kuitenkin on, että dokumentin otsikko ja sisältö eivät oikein vastaa toisiaan. Dokumentti on nimetty nykytilan arkkitehtuuriksi, mutta käytännössä se on kuitenkin enemmänkin visio tulevaisuuden yhteisistä tavoista jäsentää julkisen hallinnon tietopohjaa kuin varsinainen arkkitehtuurin nykytilan kuvaus. Lukija jää myös odottamaan tarkempaa reunaehtojen kuvausta. Nyt dokumentissa ei oikein selkeästi erotu minkäluonteisesta tiedosta milloinkin puhutaan. Pääosin jää vaikutelma, että näkökulma on johtamiseen ja ohjaukseen tarvittavasta tietopohjasta, vaikka ajoittain viitataankin myös palveluissa hyödynnettävään asiakastietoon. Erityisesti sosiaali- ja terveysministeriön toimialalla on keskeistä erotella se, että mihin käyttötarkoitukseen tietoja milloinkin käytetään. Tietojen käyttö on aina sidottu sitä koskevaan käyttötarkoitukseen ja asiakastyössä tiedot ovat aina salassapidettäviä ja arkaluontoisia. Niitä ei saa käyttää lähtökohtaisesti muuhun käyttötarkoitukseen kuin vain erillisen lakisääteisen oikeuden nojalla tai toissijaisen käytön lupaviranomaisen myöntämällä luvalla. Muutosehdotukset: 1) Nimetään dokumentti vastaamaan paremmin sen sisältöä esim. "Visio julkisen hallinnon tietopohjan hyödyntämisestä" 2) Dokumenttiin olisi siis syytä tuoda esiin vahvemmin kuvausta tiedon erilaisesta luonteesta eri käyttötarkoituksista sekä kuvata paremmin tietosuojan ja muun lainsäädännön asettamia reunaehtoja.
      • Oikeuskanslerinvirasto, Apulaisoikeuskanslerin lausunto
        Uppdaterad:
        18.4.2019
        • Lausuttavana olevassa yhteisen tietopohjan hyödyntämisen tietoarkkitehtuurissa tavoiteltu tiedon mahdollisimman tehokas käyttö on kannatettava tavoite ja yhtenäiset tietomallit ja kuvaukset ovat omiaan selkeyttämään tiedon hallinnan kehittämistä. Tietoekosysteemit, joissa tietoa käytetään yhteisesti eri toimijoiden kesken, eivät kuitenkaan ole oikeudellisesti ongelmattomia. Tavoitteena oleva asiakkaan tietojen yhteinen käyttö ja tietojen siirtäminen eri viranomaisten ja toimijoiden välillä kulloisenkin tarpeen mukaan ei käsitykseni mukaan sellaisenaan vastaa yleisen tietosuoja-asetuksen yhdeksi henkilötiedon käsittelyn periaatteeksi määrittämää henkilötiedon käyttötarkoitussidonnaisuutta. Lähtökohtaisesti henkilötietoa ei voi ilman oikeuttamisperustetta käyttää muuhun kuin siihen käyttötarkoitukseen, johon se on kerätty eikä sitä saa ilman oikeuttamisperustetta siirtää toiselle henkilötiedon käsittelijälle. Voimassa oleva tietosuojalain-säädäntö asettaa näin selviä rajoituksia tavoitellulle tiedon yhteiskäytölle ja tiedon siirtämiselle toimijalta toiselle. Lausuttavana olevassa asiakirjassa arvostelu tiedon organisaatiokohtainen ja tehtäväkohtainen käyttö on näin ensisijainen henkilötietojen käsittelyn malli. Myös eduskunnan perustuslakivaliokunta on useassa eri lausunnossaan kiinnittänyt huomiota henkilötietojen käsittelyn käyttötarkoitussidonnaisuuteen. Arkaluontoisten henkilötietojen osalta perustuslakivalio-kunta on katsonut, että käyttötarkoitussidonnaisuudesta on voitu tehdä vain täsmällisiä ja vähäisiksi luonnehdittavia poikkeuksia (esim. PeVL 1/2018 vp, PeVL 53/2017 vp ja PeVL 14/2017 vp). Käyttötarkoitussidonnaisuudesta poikkeaminen henkilön suostumuksen perusteella edellyttää, että suostumus on todellinen. Jos omaksuttu arkkitehtuurimalli edellyttää suostumuksen antamista tietojen siirtoon eri viranomaisten välillä siihen, että asian saa hoidettua yksittäisessä viranomaisessa, on varsin kyseenalaista, voiko tällaista suostumusta pitää asianmukaisena. Tietoarkkitehtuurissa tulee muutenkin asiakirjassa esitettyä tarkemmin arvioida lainsäädännön asettamia reunaehtoja tiedon käyttöä suunniteltaessa. Esimerkiksi sivulla 38 osiossa 2.3.4 Tieto-ryhmät ja tietolajit todetaan: ”Lisäksi luokittelemisella pyritään tunnistamaan se tieto, joka sisältää yksilöityä ja tunnisteellista tietoa. Tällaisen tiedon hyödyntämisessä tulee aina huomioida yksilön ja sitä koskeva tietosuoja.” Yleisen tietosuoja-asetuksen tarkoittamaa henkilötietoa on kaikki henkilöön liittyvä tieto, riippumatta siitä, voidaanko henkilö tunnistaa tuon yksittäisen tiedon perusteella. Osioon liittyvässä esimerkkikuvassa on useita tietolajeja, jotka varmasti ovat henkilötietoja, vaikka niiden ei ole merkitty sisältävän yksilöityä tai tunnistettavaa tietoa. Yhteisen tietopohjan hyödyntämisen tietoarkkitehtuurin on otettava tietosuoja-asetuksen ja muun henkilön oikeuksia koskevan lainsäädännön asettamat vaatimukset huomioon kaikessa henkilötiedon käsittelyssä, ei vain silloin, kun kyseessä on dokumentissa tarkoitetulla tavalla yksilöity ja tunnisteellinen tieto. Henkilöä koskevan tiedon hyödyntäminen muuhun kuin sen alkuperäiseen käyttötarkoitukseen on toteutettava tietosuojalainsäädännön mukaisesti. Katson, että yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuria ei tule luoda niin, että asioiden käsittely viranomaisissa edellyttää Euroopan unionin yleisen tietosuoja-asetuksen määräysten tai tavoitteiden vastaista henkilötietojen yhteiskäyttöä tai tiedon muuta tuon asetuksen määräysten ja periaatteiden vastaista henkilötietojen käsittelyä. Lainsäädännön asettamat vaatimukset ja rajaukset tulee arvioida nykyistä tarkemmin.
      • Tuuli Mäkiranta-Laitinen, Kelan tietopalvelut
        Uppdaterad:
        18.4.2019
        • Yhteinen tietopohja ja käsitteistö ovat oleellisen tärkeitä yhtenäisten kansallisten tietojohtamisen ratkaisujen rakentamisessa. Tietovarantojen kehittäminen ja yhteisten luokitusten ja mallien tuottaminen ovat tämän mahdollistamiseksi välttämättömiä. Tulevaisuuden tiedolla johtaminen ja modernien teknologioiden, kuten AI:n hyödyntäminen, tulee mahdollistaa. Tämä on mahdollista vain yhteisellä tietopohjalla ja tietoarkkitehtuurityöllä. Palvelulähtöinen ajattelu, viranomaisrajat ylittävät prosessit ja asiakkaan tarpeen keskiöön tuominen ovat oleellisia menestyksen varmistavia tekijöitä uusien tietoja hyödyntävien palvelujen suunnittelussa. Tietoekosysteemit mahdollistavat uudenlaiset joustavammat toimintamallit, ja tätä kehitystä tulisikin määrätietoisesti edistää. Arkkitehtuuria kehitettäessä tulisi varmistaa eri toimijoiden saama hyöty ja heidän kokemansa arvo. Tämä edellyttää, että toimijat ja heidän tarpeensa tunnistetaan osana arkkitehtuurisuunnittelua. Erityisen hyvänä asiana tässä dokumentissa onkin se lähtökohta, että tietoarkkitehtuuria muodostetaan palveluajattelun ja tiedon tarpeen näkökulmasta. Eri tietoryhmien ja -lajien tarve olisikin myös hyvä perustella hyödyn ja arvon kautta. Tietoarkkitehtuuri on yhteisen tietopohjan suunnitelma, jossa ensin tunnistetaan kohteet ja dataelementit, jotka tulee hallita, ja tätä dokumentissa onkin nyt kuvattu. Lisäksi voisi määritellä menettelytavat ja säännöt, joilla tätä tietoa luodaan ja ylläpidetään. Molempien osalta voisi myös määritellä selkeästi yhteisten tietojen vastuualueet eri toimijoille, ottaen huomioon jo nyt olemassa olevat kansalliset tietovarannot. Vastuisiin liittyy uusia näkökulmia kuten velvoittava vs. ohjaava, tai maksuttomuus vs. maksullisuus, sillä yhteisen tietopohjan luominen vaatii merkittäviä panostuksia. Rahoitus tähän työhön tulisi varmistaa ennen laajamittaisen työn käynnistämistä, jotta turvataan työn eteneminen. Dokumentissa todetaan, että tieto ja rajapinnat avataan lähtökohtaisesti julkisesti saataville, ellei tiedon saatavuutta ole syytä erikseen rajata. Tässä yhteydessä viitataan henkilön tietosuojaan. Joissakin tapauksissa tiedonsaantioikeus voi myös perustua lakiin. Tällainen tilanne voi olla esim. kahden sidosryhmän välillä. Lisäksi samaa tietoa voidaan käsitellä sekä anonyyminä että tunnisteellisena. Myös tämä olisi hyvä ottaa huomioon tiedonsaantioikeutta kuvattaessa. Yhteisen tietoarkkitehtuurin tavoitteita olisi hyvä ottaa huomioon myös sellaisten tietoryhmien kehittämisessä, jotka eivät sisälly yhteiseen tietopohjaan. Nykyiset tiedonvälitysrajapinnat ovat organisaatio- ja toimialalähtöisiä. Niihinkin olisi hyvä laajentaa samoja toimintaperiaatteita, joita sovelletaan yhteisen tietopohjan rajapinnoissa. Tämä vähentäisi tarvetta erillisille ja päällekkäisille rajapinnoille. Kokonaisuudessaan dokumentissa kattavasti esitelty yhteinen tietopohja ja siihen liittyvä arkkitehtuuri ovat kannatettavia ajatuksia, joita tulisi viedä eteenpäin. Jatkotöissä olisi oleellista tunnistaa kansalliset toimijat, jotka voisivat omilla tietovarannoillaan, ja jo olemassa olevilla ratkaisuilla tukea muita toimijoita, ja toimia oleellisena osana tulevia tietoekosysteemejä.
      • Maa- ja metsätalousministeriö
        Uppdaterad:
        17.4.2019
        • Maa- ja metsätalousministeriö (MMM) toteaa lausuntonaan pyydetyn vastausrakenteen mukaisesti: Lausuntopyyntö oli auki lausuntopalvelussa vain kaksi viikkoa. Lausunnon antamiselle olisi varattava pidempi aika, jotta dokumentaatio olisi paremmin kommentoitavissa virastoissa. Siksi esitetään, että dokumentaatio laitetaan viralliselle lausuntokierrokselle organisaatioiden kirjaamojen kautta, jolloin se tavoittaa organisaatiot ja asiantuntijat paremmin ja tuottaa lausunnon pyytäjille paremmat valmiudet dokumentaation muuttamiseen. Dokumentissa on paljon hyvää, mutta paikoin esitystyyli on niin monimutkainen, että kokonaiskuva katoaa. Sisällysluettelo on asiallinen ja etenee loogisesti, mutta itse teksti toistelee samoja asioita hieman eri näkökulmista. Työ vaikuttaa pikemminkin tutkimusselvitykseltä kuin arkkitehtuurikuvaukselta. Näin mm. laajat taustoitukset ja lähdeviittauksien käyttö sekä tietyt väittämät, väritetyt näkemykset ja yleistykset viittaavat tähän. Samoin dokumentaatiossa käytetyt ilmaisut kuten s. 18 ”tutkimaan”, s. 13 ”vaatii”, s. 14 ”ongelmana on”, s. 35 ”tukee”, s. 47 ”osoittaa”. Epäselvyyttä lisää myös se, että dokumentin kohde lienee laajentunut siitä, mihin työtä on alun perin suunnattu. Ensisijaisesti ehdotetaan dokumentin nimen muuttamista vastaamaan sen sisältöä, esim. ”Selvitys toimintaa tukevan tietoarkkitehtuurin rakenteesta”. Ellei nimen muutos ole mahdollista, tulee sisältöä karsia ja jättää vain oleelliset tietoarkkitehtuuria koskevat seikat. Dokumentin nimeä ei muista edes 10 lukukerran jälkeen. Tarkoittaako esim. dokumentin ”yhteinen” julkishallintoa ja keitä esim. perustietovarantojen edustajia on ollut mukana sitä laatimassa? Dokumentin liitosta maakuntien viitearkkitehtuurityöhön ei kerrota missään, mutta se tulee esille hankkeista kertovassa liitteessä hankkeiden kuvauksista, esim. ”Maakunnan paikkatietoa käyttävissä palveluissa…”. Perustietovarantoihin liittyvät osuudet olisi siirrettävä perustietovarantojen viitearkkitehtuurin päivitystyöhön ja muutoinkin pitäisi tehdä laaja-alaisemmalla valmistelulla tietoarkkitehtuuriin sopiva dokumentaatio. Yksityiskohtaiset kommentit Sivu 5: Suomessa ei ole tietoministeriötä eikä muuta kansallisen tason instanssia, joka johdonmukaisesti ohjaisi tietopoliittisia valintoja, vaikka tarve tietojohtamiselle kasvaa koko ajan. Selkeällä ohjaavalle instanssille on tarvetta myös hallinnon rakenteen vuoksi. Sivu 6: ”… miten eri tarkastelunäkökulmista voidaan ymmärtää ja hallita tietoa nykytilassa 2021 ja muodostaa yhteinen näkemys, miten tavoitetilan 2029 Suomessa tietoa käsitellään ja johdetaan.” Kuitenkin dokumenteissa viitataan samanaikaisesti tietoarkkitehtuurivisioon 2021 (esim. s. 24) ja Toimenpide-ehdotukset -dokumentissa viitataan toimenpide-ehdotuksiin 2021. Nämä eivät muodosta selkeätä ja helposti ymmärrettävää kokonaisuutta siitä mikä on esityksen tavoitetila. Sivu 7: Dokumentin kohderyhmä: Tällä sisällöllä ja vaikeusasteella dokumentti tuskin saavuttaa kohdeyleisöään. Luettelosta mainittujen asiakaspalveluiden muotoilijoiden sekä julkisen sektorin tiedosta, tietojohtamisesta ja tiedon hallinnasta kiinnostuneiden kohdalla ei ole mainintaa, miten he dokumenttia voisivat käyttää. Sisältö ja kohderyhmä eivät kohtaa. Kohderyhmät mietittävä uudelleen ja nimettävä tilanteet, joissa kohderyhmä dokumenttia voi hyödyntää. Sivu 8-9: ... ”saavat vapaasti valita, millä ja kenen ylläpitämillä sovelluksilla tietoa käytetään eri johtamisfunktioissa.” Tietoarkkitehtuuri ei tee tähän rajauksia tai rajoituksia, mutta rajoituksia voi tulla teknologian tai tietojärjestelmäratkaisujen takia. Nimenomaan yhteiskäyttöisyys, yhteentoimivuus perustuu tietoon itseensä, ei käytettäviin välineisiin tai teknologiaan. Sivu 12: ”Organisaatio on huono analyysiyksikkö, koska se rajoittaa ja yksinkertaistaa kykyä tulkita, mikä on oleellista tietoperusteisen arvonluonnin kannalta.” Mikä on parempi? Luodaanko omat analyysiorganisaatiot? Ministeriöillä ei nykyisellään ainakaan ole kapasiteettia sen enempää? Sivulla 14 puhutaan elämäntapahtumista, mutta näihin kohtiin liittyy myös liiketoimintatapahtumia ja hallinnollisia tapahtumia. Kuva 3 vs. kuva 7: Kuvissa asiakas ja politiikka- ja ohjausvalmistelu eripäin. Kernaasti näkisimme asiakkaan sijoitettuna ylimmäiseksi kuvassa 7 kuten se on kuvassa 3. Sivu 18: Tietoarkkitehtuurin kuvaaminen pelkästään JHS 179 –viitekehyksen avulla ei tue yhteisesti kuvatun julkisen hallinnon tavoitetilaa tiedon yhteiskäyttöisyyden ja hyödyntämisen osalta. Millä perusteella ja miten se pitäisi kuvata. Kuvattavaan kokonaisuuteen ei kaivata lisää yhteentoimimattomia välineitä (esim. YTI IOW). Etenkin kun yhteentoimivuus on koko hankkeen tärkein tavoite. Kuva 11: kohta oikeaa tietoa oikeaan aikaan: Pitäisikö tässä näkyä myös tiedon omistajuus? Taulukko 2: Tuleeko käsittää niin, että periaatteet ovat taulukossa tärkeysjärjestyksessä? Taulukko 2. – kohta 1, ja koko MyData laajemminkin: MyData ei liity valtion virastojen toimintaan oikein mitenkään. Viranomaisella pitää olla peruste tiedon keräämiseen ja käsittelyyn. Tiedolle pitää myös määrittää säilytysaika, jonka jälkeen se poistetaan. Ei tietoa voi pääsääntöisesti järkevällä tavalla jakaa ja etenkään poistaa kansalaisen tarpeiden tai toiveiden mukaan. Taulukko 2. – kohta 2, liittyy myös kohtaan 4: Tämä on toki tavoite, ja ollut sitä myös pitkään, mutta miten tämä toteutetaan käytännössä? Aihe vaatisi oman selvityksensä konkreettisine kehitystoimenpiteineen. Taulukko 2. – kohta 5: Miten tämän periaatteen toteutumista ja kehitystä voitaisiin mitata? Tämä on syytä huomioida. Taulukko 2. – kohta 6: Yksityisten palvelujen hyödyntämisessä tulee kuitenkin aina huomioida kustannusnäkökulma. Esimerkiksi julkisin varoin kerättyä ja ylläpidettävää tietoa ei tule ostaa kolmannelta osapuolelta. Esimerkiksi aiemmin PRH:n YTJ-tietoja ostettiin MMM:n hallinnon alalla Suomen Asiakastiedolta, koska PRH ei tuolloin itse tarjonnut tarvittavia palveluja. Tällaista rakennetta tulee ehdottomasti välttää tulevaisuudessa ja toki sen eteen on KaPan myötä jo tehtykin paljon. Kuva 13: Tiedonhallintalaki hyväksyttiin eduskunnassa 19.3.2019 – dokumentti päivätty 28.3.2019 Luku 2.3.4: Luettavuutta helpottaisi käsitemalli näistä tietojen ryhmittelyistä. Ei siis koske yksin tätä alalukua. Sivulla 18 puhutaan nykytilasta 2021. Sivulla 24 kerrotaan arkkitehtuurikuvausten kattavan vision 2021. Mitä ajankohdan tilannetta dokumentaatio kuvaa? Vaikka otsikko väittää, että kyseessä on nykytila, niin kuvaus kuitenkin tekee jo joitain olettamuksia, miten kehitys menee eteenpäin muutamassa vuodessa. Dokumentin pohjan vakautta soisi parannettavan. Sivulla 20 kerrotaan ansiokkaasti siitä, että ”Keskeisintä on, että tietotuotteet palvelevat useampaa tiedon tarvitsijaa”. Kestävän rakenteen periaatteena tulisikin olla, että mahdollisimman vähillä tietotuotteilla katetaan mahdollisimman monta käyttötapausta. Useissa dokumentin kohdissa yhteentoimivuusmenetelmää kuvataan ratkaisevaksi toimintatavaksi erilaisille ongelmille. Ko. menetelmän hyödyistä ei ole vielä näyttöjä ja tällä hetkellä tapahtuva menetelmän ketterä käyttöönotto tuottaa tilanteen, jossa kerätystä datasta ei saada irti toivottua lopputulosta. Menetelmä ei ole vielä kypsä käyttöönotettavaksi ja toimiva käyttöönotto vaatii tarkempaa ymmärrystä eri tiedon tasojen (käsitteellinen/looginen), aikamääreen (suunnitteilla/toteutettu) ja toimijan (sovellus, organisaatio) osalta, jotta dataa voisi tuottaa sopivalla ja jatkossa hyödynnettävissä olevalla tavalla. Selvityksessä tulisi ottaa kantaa tähän. Luku 2.4.2 Tietovirrat: Miksi tietovirtoja kuvataan tietovarantojen välisinä (mm. kuva 26), kun KA-menetelmän mukaisesti puhutaan toimijoiden välisistä tietovirroista ja tietojärjestelmien välisistä tietovirroista? Tiedon siirron rajapintapalvelut voivat olla ja tulisikin olla samanaikaisesti sekä sisäisiä että ulkoisia. Dokumentissa on positiivista se, että siinä otettu huomioon käyttötapauskohtaiset tiedon määritykset. Yleinen ymmärrys siitä, kuinka merkittävästi käyttötapaus vaikuttaa ja on pakko huomioida toiminnassa, on jäänyt yhteentoimivuuden jalkoihin, eikä käyttötapauksen vaikutusta ole osattu ottaa huomioon mm. yhteentoimivuusalustan kehittämisessä. Tässä dokumentissa on ansiokkaasti, tosin hieman piilossa, kuvattu tätä tilannetta. Sivu 40: Tietoalueiden yhteistoiminnan kehyksen määrittämien sanastojen ja koodistojen tulee vastata tässä dokumentissa esitettyjen tietoryhmien sisältöä, jolloin johtamisen, seurannan ja ohjaamisen tietoa voidaan käsitteellisellä tasolla hyödyntää laajemmin. Miten tämä vastuutetaan? Sivulla 41 kerrotaan loogisesta tietovarannosta. Määrittely on hyvä. Sen sijaan kuva 25 siitä, mitä loogiset tietovarannot ovat, on jonkun käyttötapauksen mukainen looginen jako eikä sovi kaikkiin tilanteisiin. Kuvaotsikkoon tulisi lisätä tarkennus. Sivulla 42 mainitaan erilaisia loogisia tietovarantoja (esim. politiikka- ja ohjausvalmistelun loogiset tietovarannot). Ne ovat täysin uusia kokonaisuuksia - edes Google ei tunnista niitä. Mikä näiden laajempi tavoite on? Lisäksi kuvassa 25 on hieman eri nimeäminen. Sivu 48: Nykytilaa varten toiminnan tietotarpeita kerättiin haastatteluilla, joita pidettiin kaikkiaan kymmenen kappaletta joulukuun 2018 aikana. Ketä haastateltiin? Onko tulokset jossain laajemmin? Sivu 48: Haastattelujen perusteella koottiin havainnot kolmitasoisesti (strateginen, käsitteellinen ja looginen). Taas uusi jaottelu (strateginen, käsitteellinen ja looginen). Voisiko tietoarkkitehtuuriselvityksessä valita käsitteet ja sanaston ja pitäytyä niissä? Taulukko 7: Alueellisen ja valtakunnallisen yhteentoimivuusmenetelmien osalta keskeiseksi välineeksi nähdään suomi.fi-palvelu. Tärkeää ei ole väline, vaan semanttinen yhteentoimivuus. Loogisella tasolla tiedon kokonaisvaltainen hyödyntäminen ei vaadi tietojen yhdistämistä, vaan ohjaamista oikeisiin rekistereihin. Tiedon kokonaisvaltainen hyödyntäminen vaatii tiedon tuntemista ja yhteentoimivuutta eri tasoilla (tekninen ja semanttinen). YTI-hankkeen yhteentoimivuusalustan hyödyntäminen mahdollistaisi tiedon hankinnassa ja muodostuksessa yhteiset määritykset. Nämä tukisivat rajapintojen avulla tiedon yhteentoimivuutta ja hyödyntämistä. YTI-yhteentoimivuusalusta ei näyttäydy käyttäjälle kovinkaan kätevänä. Ennen kaikkea se on tuplatyötä JHS-179 standardiin verrattuna. Ei virastoilla ole aikaa yhtään ylimääräiseen työhön. Sivu 54, Termit ja määritelmä: Luettelosta näyttää puuttuvan dokumentin termejä (mm. palveluantaja), luettelon termejä ei ole käytetty luettelon muiden termien määrittelyssä, osa termeistä on määritelty dokumentissa muualla (mm. tietoekosysteemi), määritelmät ovat ristiriitaisia (tiedolla johtaminen on tietojohtamisen osa-alue, mutta tietojohtamisen kohdalla ei mainita tätä yhtenä osa-alueena). Lukijalle jää mielikuva, että tämä on luku kasattu vain, koska yleensä kaikissa dokumenteissa on termit ja niiden selitykset. Dokumentaatio tulee korjata terminologisesti taikka poistaa ko. luku, ellei sitä ole mahdollista korjata. Lisäksi dokumentaatiossa (vrt. JHS-suositukset, standardit) termit esitetään yleensä alussa, ei lopussa. Termi "yhteinen tietopohja" pitäisi avata ja samalla muutkin dokumentissa esiintyvät keskeiset käsitteet. Yhteentoimivuus, yhteis- ja uudelleenkäyttöisyys perustuvat juuri yhteiseen ymmärrykseen. Dokumentti sisältää paljon erilaisia vaikeita käsitteitä, jotka pitäisi avata. Tämä on keskeistä tässä kuvatun tietoarkkitehtuurin käytännön hyödyntämisen kannalta. Dokumenttia on aika vaikea seurata: Paljon yhteen toimimattomia käsitteitä ja viittauksia tulevaan tekstiin. Erityisenä haasteena on, että käsittelyn taso menee aivan laidasta laitaan yhden luvun sisällä. Teksti tarvitsisikin rakenteellista uusimista ja auki kirjoittamista. Dokumentista syntyi olo, että painopiste on ylätason tehtävissä. Käsitemallinnuksessa ja yhteentoimivuudessa ongelmat ovat usein yksityiskohdissa. Ylätaso antaa usein virheellisen kuvan yhteentoimivuuden helppoudesta. Mahdollisuuksia on, mutta niiden hyödyntäminen voi vaatia vuosien työn ja jopa lakimuutoksia. Tähän ongelmaan törmätään usein. Helpot tapaukset on jo pitkälti tunnistettu.
      • Ulkoministeriö, Tietohallinto
        Uppdaterad:
        16.4.2019
        • Ulkoministeriö kiittää mahdollisuudesta lausua asiakokonaisuudesta, joka on rakenteellisesti ja toiminnallisesti erittäin tärkeä teema luotaessa yhteistä tietoyhteiskunnan ja sen digitaalisten palvelujen perustaa. Dokumenttien osalta käsitteiden hahmottaminen vaikuttaa jossain määrin turhankin monimutkaiselta. Asiakirja on otsikoitu nimikkeellä ´Yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuri´. Otsake herättää kysymyksen, miksi kyseessä ei olisi yksikäsitteisemmin tiedon arkkitehtuuri tai viitearkkitehtuuri? Dokumentista saa sen vaikutelman, että se on ilmeisesti alun perin tarkoitettu kehitteillä olleiden maakuntien käyttöön yhteiseksi tietoarkkitehtuuriksi, mutta joka on nyt muokattu koko julkishallinnolle yhteiseksi malliperustaksi. Alkuperäinen lähtökohta on nähtävillä tekstissä, joka edellyttää ulkoministeriön näkemyksen mukaan vielä runsaasti muokkaamista ja tiivistämistä. Tämä siksi, että dokumentti vilisee toistoa, uusia vakiintumattomia ja erikoisia termejä sekä niiden variaatioita (esimerkiksi: horisontaalinen tietopohja, tilastollinen summatason tieto, informaatiotieto, tieto vertikaalisesti siiloutunutta, looginen yhteinen tietopohja, ”tarvelähtöisyys tarkoittaa sitä, että palvelutarve synnyttää tietotarpeita” jne.) ja lisäksi jo useaan otteeseen muussa dokumentaatiossa todettua asiaa. Dokumentissa oleva termiluettelo on aivan liian suppea. Termien selitykset tulisi lisäksi katselmoittaa jo olemassa olevien termiluetteloiden pohjalta. Itse sisällön osalta voi todeta, että pelkkä ihmisten hyvinvoinnin turvaaminen ei riitä kattamaan kaikkia tiedonhallinnan ja tiedon hyödyntämisen tavoitteita vaikka se luonnollisesti tärkeä asia onkin. Yhteiskunnassa ja sen toiminnassa on paljon muutakin keskeistä huomioitavaa, kuten kokonaisturvallisuuden raekntaminen, tulevaisuuden ennakointi, kansainvälinen yhteistyö ym. jotka edellyttävät tiedon käyttöä hyödykkeenä asetettujen tavoitteiden saavuttamiseksi. Sinänsä hyvä asia on että kehittämisen lähtökohdaksi on valittu tiedon hyödyntäminen. Sitähän on julkishallinto toteuttanut toiminnassaan jo pitkään ja mikäli asiaa onnistutaan edelleen parantamaan, edellytykset tietojohtamiselle ovat luonnollisesti paremmat. Tieto käsitteenä on - kuten useaan otteeseen on saatu havaita - ongelmallinen. Englannin kielellä ilmaisuvoima on tässä tapauksessa laaja-alaisempi (data, information, knowledge jne.) Tieto sisältää terminologisesti monta ulottuvuutta aina koodi- ja tunnistetasosta käsitteisiin. Koko tiedon hallinnan ketjun tulisi olla yhteentoimiva – ei riitä että pelkät käsitteet ovat yhdenmukaisia. Käsitetyöhön on ollut jo jonkin aikaa olemassa koko julkishallinnon kattava organisointi, kuten käsitemalliryhmä KMR sekä ydinsanastoryhmä YSR. Ne toki joissain taulukoissa mainitaan mutta niiden rooli jää esityksessä heppoiseksi. Jo tehty työ sekä valtiovarainministeriön ohjima YTI-hanke (yhteisen tiedon hanke) tulisi mainita jo johdannossa. Tekstidokumentti vaikuttaa lähtevän ajatuksesta, että kaikki tulisi lähteä luomaan alusta alkaen, vaikka yhteistä kaikissa julkishallinnon organisaatioissa toimivaa käsitemallia on pohdittu ja testattu jo pitkän aikaa. Se myös tarkentuu jatkuvasti kun ns. soveltamisprofiilien avulla organisaatiot voivat peilata omia käsitteitään yhteiseen käsitemalliin. Esityksen johdannossa mainitaan, että Suomen kansalliset tietovarannot ovat laadukkaita. Näin toki pääosin voi ollakin, mutta päällekkäisyyksiä on tarjolla edelleen paljon ja samaa tietoa kerätään varmuuden vuoksi useisiin kantoihin ja rekistereihin. Tietovarannoissa oleva data tulee yhtenäistää, harmonisoida – tätä tasoa ei voi unohtaa, koska käsitteiden muuttuessa myös datatasolla tapahtuu, tai pitäisi tapahtua muutoksia. Tällöin voitaisiin puhua tiedon kivijalasta datatasolla. Toki asiassa on huomioitava myös turvallisuusulottuvuus ja jatkuvan käytettävyyden vaatimus puhuttaessa ns. perustietovarannoista. Dokumentissa esitetty väite, että ei olisi olemassa yhteistä tietoa ei pidä paikkaansa. Toki tiedolla on aina primääri omistajansa, mutta jaettaessa laajalti käyetttäväksi tieto on ennen pitkää yhteistä. Juuri tähän datatasoon tulee paneutua. Se tekijä, että toimitaan verkostoissa ja hyödynnetään toisten tahojen tietoja ei ole ristiriidassa datan yhtenäistämisen kanssa. Tiedon ekosysteemimalli (JHKA 2.0) auttaa tunnistamaan missä järjestyksessä datan ja muun tiedon huolto on mahdollista ja kannattaa aloittaa. Esityksen johdannossa puhutaan yhdenmukaisen tietopolitiikan tarpeesta ja mainitaan 2018 tehty tietopoliittinen selonteko. Tämä on hyvä asia, mutta tekstissä esitetään yhteiseen tietoon aivan liian suppea näkökulma. Kaikki julkinen tieto ei ole olemassa pelkästään ihmisten hyvinvoinnin lisäämiseksi (ks. edellä), vaikka se hieno tavoite onkin. Yhteiskunnassa on runsaasti muutakin tietoa ja jokaisella organisaatiolla on omat (usein lakisääteiset) tehtävänsä, joiden perusteella tietotarpeetkin syntyvät. Eri asia on, miten yhä kompleksisemmassa maailmassa ratkotaan erilaisia ilmiöpohjaisia ongelmia. Pelkkä tieto tai tietovarannot eivät tähän riitä, vaan lisäksi edellytetään monialaista yhteiskunnallista perehtymistä ja oleellisen tiedon seulontaa. Tämä on erittäin vaativa ja vastuullinen tehtävä jota yksi organisaatio ei todellakaan pysty käsittelemään yksin. Päätöksentekokin on myös erillinen elementti tiestoarkkitehtuurissa: miten seulottu tieto mahdollisesti siihen voi vaikuttaa. Tietopolitiikka - siinä vaiheessa kun se aikanaan muodostuu - voisi ottaa kantaa tähän. Aihealueeseen kytkeytyy myös tiedon syklisyys, sillä osa tiedosta luonnollisesti vanhenee ja osa vaihtuu esimerkiksi hallitusohjelmien myötä. Jo pitkään on jo todettu että tarvitaan yhteiskäyttöistä tietoa. JHKA 2.0 -tietoarkkitehtuurissa on luotu malli, jossa tieto on tärkeä osatekijä verkottuneissa (palvelu)ekosysteemeissä. Organisaatiot ovat toisistaan riippuvaisia ja tarvitsevat toistensa tietoja ja näin on ollut jo pitkään. Jokainen organisaatio ja tiedonhallintayksikkö huoltaa sitä tietoa josta sillä on periaatteessa tietovastuu – tämä tunnistamistyö on kesken ja se tulee valmistuessaan auttamaan päällekkäisyyksien vähentämisessä. On lisäksi vaikea uskoa että kaikki tieto on yhteiskäyttöistä. On tietoa jota tarvitaan vain yhdessä organisaatiossa, ja on eri syistä rajoituksia tiedon jakamiselle tietosuojakysymyksistä tietoturvaan. Sen sijaan kaikki yhteinen ja organisaatioiden välinen tieto rajapintojen kautta hyödynnettynä on tarpeen yhdenmukaistaa, jotta on mahdollista saadaan aikaan toivottua yhteentoimivuutta. Tieto pitää arvottaa, se on aivan totta. On siis jo olemassa paljon elementtejä joita voidaan haluttaessa hyödyntää jatkotyössä: palveluarkkitehtuuri, JHKA-ekosysteemimalli, käsitemalliryhmä KMR ja ydinsanastoryhmä YSR (sekä koodisto)yhteistyö, suomi.fi-sanastot ja tietomallit, soveltamisprofiilialusta ym. Näiden kunnolla jalkauttaminen on tärkeää jatkuvuuden turvaamiseksi. Tiedonhallintalaki ja sen soveltaminen jatkossa ovat myös avainasemassa. On mm. hahmotettava kuinka tiedonhallintayksiköiden toimintaa johdetaan ja seurataan. Organisaatiot toimivat jatkossakin yhteiskunnan lakisääteisten tehtävien hoitajina. Tietohuollon kannalta tarvitaan kuitenkin yhteinen hallintamalli. Esitettäviä kysymyksiä ovat mm. mikä taho tai tahot vastaa viime kädessä yhteiskunnan tietohuollon tasosta, miten jalkautetaan yhteiset jo olemassa olevat tiedonhallinnan välineet, kuinka hoidetaan tiedon tunnistaminen, käsitetyön edistäminen jne.? Mikä on edelleen julkishallinnon yhteinen metatietomalli, mitä tiedon standardeja noudatetaan, miten päällekkäisyyksistä käytännössä eroon? Mikä taho määrittelee tiedon yhdenmukaistamisen tärkeysjärjestyksen? Ulkoministeriön näkökulmasta hahmotellussa mallissa on edellä esitettyjen kysymysten nojallakin vielä runsaasti kehitettävää. On myös syytä huomata, että kansallisen tason ohella tieto ja sen hallinta verkottuu myös kansainvälisellä tasolla. Käsillä olevat haasteet edellyttävät siten myös tarkastelun ulottamista maan rajojen ulkopuolelle ja arkkitehtuurimallien ja best practice -käytänteiden syntyessä myös muualla kuin Suomessa.
      • Haaga-Helia AMK, FT; VTM Martin Stenberg
        Uppdaterad:
        10.4.2019
        • Kaikessa tietoon liittyvässä sisällöllisessä ja arkkitehtuurillisessa sekä käytössä tuli myös huomioida kansainvälinen kehitys ja vaatimukset. Suomi voisi olla edelläkävijä monessa toimien aktiivisesti YK:n, EU:n ja Pohjoismaiden neuvostossa
      • Palaute koskien dokumenttia Sidosarkkitehtuurit ja liittyvät hankkeet
      • Terveyden ja hyvinvoinnin laitos THL, THL/TIPO
        Uppdaterad:
        19.4.2019
        • Liitteessä Sidosarkkitehtuuri (rivi 22) sosiaali- ja terveydenhuollon kokonaisarkkitehtuuria koskeva kuvaus on virheellinen. Kuvaus koskee KA:n hallintamallia ja senkin osalta vain sosiaalihuoltoa. Rivit 21 ja 23 ovat sama arkkitehtuuri. Hankkeissa on mukana tiedonhallintalain valmistelu. Vastaavalla tavalla hankkeissa tulisi olla mukana sote-tietojen toissijaisen käytön lain valmistelu (HE 159/2017 vp). Itse asiassa kumpikin laki on hyväksytty eduskunnassa ja valmistelu on päättynyt. Voisi olla hyödyllistä listata keskeiset lait omaksi välilehdekseen. Merkittävistä sidoshankkeista puuttuu Kanta-palveluita koskevat hankkeet, kuten •Kansa-hanke (Sosiaalihuollon valtakunnallisten tietojärjestelmäpalvelujen ja määrämuotoisen kirjaamisen toimeenpanohanke, https://thl.fi/fi/web/tiedonhallinta-sosiaali-ja-terveysalalla/kanta-palvelut/sosiaalihuollon-kanta-palvelut ), jossa on tehty sosiaalialan tietomäärittelyjä ja luokituksia ja sanastoja. •Sote-tietoarkkitehtuuri https://thl.fi/fi/web/tiedonhallinta-sosiaali-ja-terveysalalla/maaraykset-ja-maarittelyt/sote-tietoarkkitehtuuri •Sosmeta https://sosmeta.thl.fi/sosmeta-publish-ui •Koodistopalvelu https://thl.fi/fi/web/tiedonhallinta-sosiaali-ja-terveysalalla/koodistopalvelu ja -palvelin https://koodistopalvelu.kanta.fi/codeserver/pages/classification-list-page.xhtml •Sanastot https://thl.fi/fi/web/tiedonhallinta-sosiaali-ja-terveysalalla/maaraykset-ja-maarittelyt/sote-tietoarkkitehtuuri/sanastotyo/sanastot •Kanta-palvelujen julkaisusuunnitelma palvelujen kehittämisestä (https://www.kanta.fi/jarjestelmakehittajat/julkaisuaikataulu) •Samat lisäykset kuvaan 14.
      • Työ- ja elinkeinoministeriö, Alueet ja kasvupalvelut osasto/Digitalisaatio ja tietoryhmä, Alitalo Sirpa
        Uppdaterad:
        18.4.2019
        • Alla lisäysehdotus maakunnallisiin kasvupalveluihin liittyen: Maakunnallisten kasvupalvelujen (työvoima- ja yrityspalvelujen) tiedolla johtamisen hanke - Hanke on Merkittävä Hanke on Kansallinen Tiedot löytyy. Alueuudistus.fi -sivustolta Hankkeen kuvaus: Hankkeen tavoitteena on tuottaa ministeriöiden ja virastojen, alueiden/ maakuntien, ELY-keskusten, TE-toimistojen ja palveluntuottajien käyttöön maakunnallisten kasvupalvelujen (työvoima- ja yrityspalvelujen) tiedolla johtamisen kokonaisuus sisältäen tietovaraston ja BI-raportointiratkaisun, joka mahdollistaa - palveluista saadaan johtamisen, ohjauksen ja seurannan tueksi tietoa toiminnasta, taloudesta, vaikuttavuudesta, tehokkuudesta ja laadusta - tuotettava tieto on ajantasaista, luotettavaa ja vertailukelpoista - kehittyneen data-analytiikan, automatiikan ja tekoälyn hyödyntämisen
      • Sosiaali- ja terveysministeriö, STM OHO / DITI, Huovila Mikko
        Uppdaterad:
        18.4.2019
        • Dokumentissa on vielä viittauksia maakuntavalmisteluun. Ne hankkeet ja sidosarkkitehtuurit tulisi poistaa. Lista ei myöskään ole synkassa dokumentissa olevien sidosarkkitehtuurien kanssa. Hankkeisiin tulisi lisätä Kanta-kokonaisuus, joka puuttuu siitä kokonaan.
      • Oikeuskanslerinvirasto, Apulaisoikeuskanslerin lausunto
        Uppdaterad:
        18.4.2019
        • Minulla ei ole lausuttavaa dokumentista.
      • Tuuli Mäkiranta-Laitinen, Kelan tietopalvelut
        Uppdaterad:
        18.4.2019
        • Dokumentissa oli hyvin tunnistettu ja kuvattu yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuriin liittyvät sidoshankkeet ja -arkkitehtuurit. Näiden huomioon ottaminen ja saumaton yhteistyö eri toimijoiden välillä on oleellista yhteisten ratkaisujen rakentamisessa.
      • Maa- ja metsätalousministeriö
        Uppdaterad:
        17.4.2019
        • Hanke- ja sidosarkkitehtuurilistaukset puolustavat paikkaansa, jos ja kun alueuudistusta jatketaan. Toisaalta listaukset vanhenevat aika äkkiä, ja vähintäänkin niitä on päivitettävä ja revisioitava. Eviran kokonaisarkkitehtuuri korjataan Ruokaviraston kokonaisarkkitehtuuriksi.
      • Palaute koskien dokumenttia Toimenpide-ehdotukset
      • Terveyden ja hyvinvoinnin laitos THL, THL/TIPO
        Uppdaterad:
        19.4.2019
        • Liitteessä Toimenpide-ehdotukset jää epäselväksi, mistä luetellut nykytilan arkkitehtuurin puutteet ovat peräisin. Tiedon elikaaren kuvaamisessa voisi hyödyntää Kuntasektorin asianhallinnan viitearkkitehtuuria 1.0 (kuva 4) "Tarvitaan näkymä ja ymmärrys yhteiseen tietoon ja sitä tukevat tiedonjakelukanavat. Ei puhuta pelkästä tietoaltaasta, vaan verkostosta, jossa on eri tiedonhallintayksiköiden tietoa." -> Ymmärrys yhteisestä tiedosta täytyy hankkia, se ei tule itsestään. Sen kautta pystytään löytämään se, millaiset ratkaisut yhteiselle tiedolle kannattaa rakentaa. Tietoallas-tyyppinen ympäristö ja mahdollisuus louhia siinä olevaa tietoa voi toimia keinona hankkia ymmärystä yhteisestä tiedosta. Tiedon laatu: päästäänkö määrittelemällä laatukriteerit ja sopimalla laadusta eteenpäin tässä asiassa. Se mitä sote-tiedoissa on käytännössä huomattu, että a) tietojen laatu kehittyy, kun siihen on kannuste, joka on tyypillisesti raha (laskutukseen liittyvät tiedot ovat yleensä laadukkaita) b) haaste tiedon hyödyntämisessä muihin kuin se alkuperäiseen käyttötarkoitukseen on usein juuri tiedon laadussa, koska alkuperäinen tiedon tuottava prosessi kehittyy tyyppillisesti niin että tiedon laatu paranee ensisijaisen käytön kannalta, ja toisisijainsen käytön kannalta laatu, jolla voi olla toisenlaiset kriteerit, ei yleensä parane ns. luonnostaan osana toiminnan ja prosessin kehittymistä. Osa tiedon laadun seurannasta pitäisi voida automatisoida ts kehittää sellaisia automaatiota,jotka valvovat sisään tulevan tiedon laatua ja antavat heti lähettäjätaholle palautteen,jos joku ei kirjaudu oikein/puuttuu. Yhteisen tietopohjan simuloiminen elämäntapahtumien avulla toiminee niissä tiedoissa, jotka liittyvät suoraan tai välillisesti ihmisasiakkaaseen. Sillä tavalla ei luultavasti saada katettua koko yhteistä tietopohjaa. Asiakaslähtöisyys ja toistettavuus paranee, kun metatietojen hallintamalli on yhtenäinen, perusteellinen ja antaa selkeän kuvan mistä aihe-alue kertoo. Tämä edellyttää monen tietokannan metatietojen päivittämistä ja yhtenäistämistä. Ilmiölähtöinen tarkastelutapa tuottaa saman aihealueen ympärille relevantit mittarit. Tähän tarvitaan uudenlaista raportointimahdollisuutta ja ketterää BI -työkalua.
      • Työ- ja elinkeinoministeriö, Alueet ja kasvupalvelut osasto/Digitalisaatio ja tietoryhmä, Alitalo Sirpa
        Uppdaterad:
        18.4.2019
        • Yleisenä huomiona toimenpide-ehdotuksiin todetaan, että on tarpeen vielä varmistaa ehdotusten yhdenmukaisuus tiedonhallintalain velvoitteiden kanssa. Lisäksi toimenpidelistaus jää pistemäiseksi ja sen johdosta myös toimenpiteiden kokonaiskuva jää puutteelliseksi. Yhteentoimivuus ”Tiedon yhteiskäyttöisyys perustuu tiedon luomiseen.” –tilalle esitetään kirjausta: ”Tiedon yhteiskäyttöisyys perustuu tietotarpeisiin, niiden yhteisesti määriteltyihin syihin ja tiedon luomiseen.” Tilannekuvan tiedot ”Asiakkaan tilannetiedon ymmärtäminen on puutteellista.” huomiona todetaan, että on muitakin keskeisiä tilannetietotarpeita kuin asiakkaan. Yksilökohtainen tieto Elämäntilannetieto ja muut havaintokohdat viittaavat henkilöasiakkuuteen, asiakohdassa voisi käsitellä myös yrityksiin ja niiden liiketoimintatapahtumiin liittyviä havaintoja ja toimenpiteitä. Yhteisen tietopohjan kehittäminen 1/2 Ao. kohdan havainnot ja toimenpide-ehdotukset tulee ymmärrettävyyden vuoksi muotoilla tarkemmalle tasolle uudelleen. Erityisesti huomio kiinnittyy tapaan kiinnittää tietojen luokittelu tekniseen tiedonvälitystapaan (vrt. esim. VAHTImääritykset teknisistä siirtotavoista)
      • Väestorekisterikeskus, Yhteentoimivuusalusta
        Uppdaterad:
        18.4.2019
        • Toimenpide-ehdotuksissa on hyviä näkökulmia, mutta ehdotuksia pitäisi konkretisoida. Yksityiskohtaiset kommentit: Kalvo 8: Lause: ”Yhteisen tietopohjan ympärille rakennettua tiedon yhteentoimivuutta pitää syventää.” Ehdotus: ”Yhteisen tietopohjan ympärille rakennettua tiedon yhteentoimivuutta pitää edistää.” Lause: ”Yhteisen tietopohjan yhteentoimivuutta tulee tarkastella laajemmin asiakaslähtöistä palvelunäkökulmaa.” Ehdotus: ”Tulee muodostaa tietoalueet, jotka huolehtivat päätietoryhmien ja tietolajien määrittelystä yhteiskäyttöisiksi tietokomponenteiksi.” Lause: ” Tiedon yhteiskäyttöisyys perustuu tiedon luomiseen.” Mitä tämä tarkoittaa? Ehdotus: ”Tiedon yhteiskäyttöisyys ja yhteentoimivuus perustuu yhteisiin tietomäärityksiin.” Lause: ”Käytetään yhteisiä työvälineitä, käsitteitä ja sanastoja (YTI)” Ehdotus: ”Käytetään yhteentoimivuusvälineistöä eli Sanastot-, Koodistot- ja Tietomallit -työkaluja. ” Havaintoon ” Ei ole olemassa yhteistä tietoa, vaan tietopohja muodostuu päätiedoista ja niiden yhdistelmistä.” toimenpide-ehdotuslisäys: ”Dokumentoidaan tietotuotteet soveltamisprofiilien avulla.” Havaintoon ” Yhteentoimivuus tietopohjan ja tiedon osalta ei toteudu tällä hetkellä.” toimenpide-ehdotuslisäys: ”Määritellään yhteiskäyttöisten tietotuotteiden tietomallit ja käsitteet yhteentoimivuusalustalla.” Kalvo 10: Havaintoon ” OmaDatalle tarvitaan lisäparametri päätöksenteon tueksi” toimenpide-ehdotuslisäys: ”Muodostetaan OmaDatasta tietotuotteita, jotka dokumentoidaan yhteentoimivuusvälineistön ja soveltamisprofiilien avulla.” Kalvo 16: Tiedon käyttö ja uudelleenkäyttö edellyttävät yhteentoimivuutta ja yhteistä käsitteistöä. ”Yhteentoimivuus” -ehdotuksia ei voi sijoittaa yhteen kohtaan tiedon elinkaaressa. Tiedon luonti ja tallennus yksittäiseen käyttöön on mahdollista ilman yhteentoimivia tietorakenteita. Yhteentoimivuusongelmat ilmenevät, kun tietoa yritetään käyttää. Yhteentoimivuus tulee huomioida jo tietoa luotaessa.
      • Sosiaali- ja terveysministeriö, STM OHO / DITI, Huovila Mikko
        Uppdaterad:
        18.4.2019
        • Toimenpide-ehdotusten abstraktiotaso vaihtelee paljon. Osa kaipaisi konkretisointia. Kun kyse kuitenkin on nykytilan analyysista, niin olisiko kuitenkin dokumentaatiokokonaisuudessa syytä huomioida eri toimialojen erot ja suhteuttaa toimenpide-ehdotuksia niihin? Monia toimenpide-ehdotuksista on jo edistetty muutamilla toimialaloilla. Jonkinlainen kypsyystasoarvio voisi olla hyödyllinen kun mietitään toimenpiteiden toimeenpanoa.
      • Oikeuskanslerinvirasto, Apulaisoikeuskanslerin lausunto
        Uppdaterad:
        18.4.2019
        • Toimenpide-ehdotusten osalta viittaan edellä ”Yhteisen tietopohjan hyödyntämisen tietoarkkitehtuuri” –dokumentista henkilötietojen käsittelystä, käyttötarkoitussidonnaisuudesta ja suostumuksen käytöstä lausumaani. Yksittäisenä huomiona totean, että dokumentin sivulla 12 taulukossa ”Tietosuoja ja tunnistautuminen” neljäntenä toimenpide-ehdotuksena on ”ST I-IV tietojen turvaluokituksen vaatimuksia määrittää tarkemmin”. Eduskunta hyväksyi hallituksen esityksen eduskunnalle laiksi julkisen hallinnon tiedonhallinnasta sekä eräiksi siihen liittyviksi laeiksi 18.3.2019 (HE 284/2018 vp). Tuohon lakikokonaisuuteen sisältyy lakiesityksenä 1.2 julkisuuslakiin tehtäviä muutoksia, ja muun muassa julkisuuslain asetuksenantovaltuuksia on uudella eduskunnan hyväksymällä lailla supistettu merkittävästi. Suojaustasot I-IV ja koko suojaustasoluokittelu perustuu valtioneuvoston asetukseen tietoturvallisuudesta valtionhallinnossa (681/2010), joka kumoutuu, kun edus-kunnan 18.3.2019 hyväksymät muutokset julkisuuslakiin tulevat voimaan.
      • Tuuli Mäkiranta-Laitinen, Kelan tietopalvelut
        Uppdaterad:
        18.4.2019
        • Dokumentissa oli hyvin analysoitu toimenpiteitä eri näkökulmista. Ehdotettujen toimenpiteiden toteuttaminen vaatii merkittäviä panostuksia eri organisaatioissa. Ennen toimenpiteiden käynnistämistä tulee varmistaa riittävä ja tarpeeksi pitkäaikainen rahoitus, jotta esitetyt ja varsin kunnianhimoiset tavoitteet saadaan toteutetuksi. Satsaus tämän työn tekemiseen kuitenkin kannattaisi, sillä pitkällä aikavälillä se mahdollistaa parempien palvelujen tuottamisen, ja tehokkaammat toimintamallit eri viranomaisten välisessä tietojenvaihdossa.
      • Maa- ja metsätalousministeriö
        Uppdaterad:
        17.4.2019
        • Dokumentti väittää olevansa nykytila 2021, ja että tämän dokumentin jälkeen tuotetaan tavoitetila 2029 dokumentti. Puuttuvasta tavoitetilan kuvauksesta huolimatta dokumentissa on mukana toimenpide-ehdotukset. Lukijalle jää epämäärinen käsitys siitä, miten havainnot on muodostettu ja kenen pyrkimyksiä toimenpide-ehdotukset mukailevat. Siksi esitetään, että toimenpide-ehdotuksia ei liitettäisi tähän dokumenttiin, vaan se kuuluu tavoitetiladokumentaatioon. Mikäli dokumentin nimeksi tulee selvitys, havainnot ja analyysit voivat olla osa dokumentaatiota, mutta muutoin ne tulisi myös erottaa muuhun dokumenttiin. Havaintojen osalta tulee kertoa selkeämmin, keitä on haastateltu. Tehtävät ovat sinällään hyviä ja tarve niihin on tunnistettu myös MMM-hallinnonalalla. Resurssit ovat vain erittäin rajatut ja ymmärrys tehtävien merkityksestä substanssijohdossa varsin rajattu. Parasta olisi, jos VM ja muut ministeriöt ottaisivat vahvemman ohjaavan roolin näissä asioissa. Tehtävät pitäisi saada tulossopimuksiin, ja niitä pitäisi oikeasti seurata. Toimenpide-ehdotukset tulisi priorisoida sen mukaan, miten ja millä aikataululla ne on mahdollista toteuttaa. Kaikkia ei voida tehdä yhtä aikaa. Toimenpide-ehdotuksia tulisi myös tarkentaa, esim. mitä tarkoittaa: - Sivu 8: ”Kansallisten tietovarantojen määrittelyjen tarkentaminen loogiselta tasolta suositellaan kytkettäväksi osaksi tapausesimerkkejä esimerkiksi palvelupolkukuvausten kautta, koska palvelupolkuun liittyy paljon muitakin tietovarantoja kuin kansalliset tietovarannot.” - Sivu 8: ”Tiedon yhteiskäyttöisyys perustuu tiedon luomiseen.” - Sivu 10: ”Suunnitellaan, miten palvelunjärjestäjän ja tuottajan data on ”muunnettavissa” OmaDataksi.” - Sivu 12: Tietosuojaa ja tunnistautumista ei käsitellä lainkaan yhteisen tietopohjan hyödyntämisen tietoarkkitehtuurikuvauksessa. Mistä kyseiset havainnot ja toimenpide-ehdotukset ovat peräisin?
      • Haaga-Helia AMK, FT; VTM Martin Stenberg
        Uppdaterad:
        10.4.2019
        • Mielestäni tärkeää olisi myös Tietojohtamisen kansallisen tason johtaminen. Se voisi tapahtua parhaiten uuden ministeriön kautta, esim. Tietoyhteiskuntaministeriön, jonka vastuulle kootaan myös tietosuoja (GDPR) ja tietoturvan sekä kyber -hyökkäysten torjunminen ja hallinta. Lisäksi viranomaisyhteistyö ja sen edellyttämä rajapintojen määrittely sekä avoimen datan hyödyntämisen vaatimukset edellyttävät kansallisen tason kansallissta yhteistyötä eri viranomaisten ja julkishallinnon toimijoiden sekä yritysmaailman kanssa.