Palautekooste: JHS 176-suositusluonnos

Transkriptio

1 Palautekooste: JHS 176-suositusluonnos Organisaatio Vastaajien määrä: 54 - yksityishenkilö - Vantaan kaupunki - Hankasalmen kunta - Maanmittauslaitos - Joensuun kaupunki - Kinnulan kunata - Mikkelin ammattikorkeakoulu/st-laitos - Lappeenrannan kaupunki - Metropolia Ammattikorkeakoulu Oy - Lahden kaupunki - Johtamisjärjestelmäosasto/Puolustusvoimat - Fujitsu Finland Oy - Päijät-Hämeen koulutuskonserni -kuntayhtymä - opetus- ja kulttuuriministeriö - Kontiolahden kunta - Puolustusvoimien palvelukeskus - Kemin kaupunki, kaupunginkanslia/ kaupunginarkisto - Tampereen kaupunki - Affecto Finland Oy - STM - Turun kaupunki, konsernihallinto, asianhallinta - Espoon kaupunki, asiakirjahallinto - Ammattikorkeakoulujen rehtorineuvosto, Arene ry - Geologian tutkimuskeskus - Kuopion kaupunki, kaupunginkanslia - Salon kaupunki, Hallintopalvelut - Poliisihallitus - Valtiokonttori - Innovaatiorahoituskeskus Tekes - Pohjois-Karjalan sairaanhoito- ja sosiaalipalvelujen ky - Helsingin kaupunki/tietokeskus - Oulun kaupunki - Triplan Oy - Yksityishenkilö - Tilastokeskus - Valtioneuvoston kanslia - Kela, Kanta-palvelut - Tulli - Yksityishenkilö - Patentti- ja rekisterihallitus - Väestörekisterikeskus - Verohallinto - Suomen Pankki (Suomen Pankin ja Finanssivalvonnan kirjaamo) - Verohallinto/Tietohallintoyksikkö - Kansallisarkisto - Helsingin kaupunki / Tietokeskus - Terveyden ja hyvinvoinnin laitos THL - yksityishenkilö - M-Files Oy - Yksityishenkilö - TYö- ja elinkeinoministeriö - Helsingin kaupunki / Kaupunginkanslia / Tietotekniikkayksikkö - Kunnallisarkistoyhdistys ry - Inspecta Sertifiointi Oy 2. Yhteyshenkilön tiedot Vastaajien määrä: 54

2 3. Yleiskommentit Vastaajien määrä: 48 - Suosituksen johdanto on jo ongelmallinen. Johdannossa todetaan, että suosituksessa kuvataan ne pakolliset vaatimukset, jotka julkishallinnon organisaatioiden tulee ottaa huomioon sähköisten asiakirjatietojen käsittelyssä, hallinnassa ja säilyttämisessä. Koska kysymys on informaatio-ohjaukseen perustuvasta suosituksesta vailla säädöspohjaa, ei suosituksessa voida asettaa pakollisia vaatimuksia. Niin ikään suosituksen johdannossa todetaan, että "JHS176-suositus toimii jatkumona arkistolaitoksen SÄHKE2-normille ja määrittää tietohallintolain pohjalta velvoittavat reunaehdot julkishallinnon tietojärjestelmille sähköisen asiakirjatiedon hallinnassa". Tietohallintolaissa ei ole säädetty, että JHS-suositukset olisivat velvoittavia, joten johdannossa oleva teksti on virheellinen. Toisaalta taas johdannon lopussa todetaan, että " JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia". Joten Johdanto-lukua on syytä yhdenmukaistaa. Virheellinen tieto: "Julkisuuslaki edellyttää, että julkisen hallinnon organisaatioiden käsittelemien julkisten asiakirjatietojen tulee olla vaivattomasti kansalaisten saatavilla". Julkisuuslaissa ei ole sidottu tiedonsaantioikeutta kansalaisuuteen, vaan julkisiin asiakirjoihin tiedonsaantioikeus on jokaisella. Samassa kappaleessa on myös suositus, jota voi olla vaikea tai mahdotonta toteuttaa ottaen huomioon muun muassa tietosuojavaatimukset: "Hallinnon läpinäkyvyyden lisäämiseksi tiedot tarjotaan mahdollisimman ajantasaisina julkaisemalla ne organisaation verkkosivuilla tai koneluettavassa muodossa avoimena datana". Avoin data on kaunis ajatus, mutta asiakirjahallinnossa hankala toteuttaa. Tässä on otettava huomioon muun muassa julkisuuslain 16.3 :ssä säädetyt vaatimukset. Suositus on laadittu asiankäsittelykeskeisenä eikä siinä ole otettu huomioon, että asiakirjoja käsitellään ja niitä tehdään osana julkisen hallinnon palvelutuotantoprosesseja, joita ei ole sovitettavissa asiankäsittelyprosessien muotoon. Tästä syystä suositusluonnosta on syytä tarkentaa siten, että se koskee vain asiakirjojen hallintaan asiankäsittelyprosesseissa. Tällaista rajausta voidaan pitää myös suosituksen puutteena. Arkistolaitoksen ajatus asiankäsittelykeskeisestä julkisesta hallinnosta voi toimia ministeriö- ja keskushallintotasoilla, mutta ei esimerkiksi kunnissa. SÄHKE-määritykset ovatkin olleet osittain käyttökelvottomia palveluja tuottavissa julkisen hallinnon organisaatioissa yliopistot mukaan lukien. - Asiantuntevasti laadittu verrattuna joihinkin aiempiin luonnoksiin. Mutta koko sisällön arvioiminen on hieman liian vaativaa. - Edelliseen lausuntokierrokseen verrattuna huomattavaa parannusta. Kieli on selkiytynyt ja kokonaisuus on helpompi hahmottaa. Selkeä luettava. Hyvä. - Kunnanjohtajan päätös-ehdotus: Kunnanhallitus toteaa, ettei kunnalla ole lausuttavaa JHS 176 suositukseen. Päätös: Kunnanhallitus hyväksyi kunnanjohtajan päätösehdotuksen. Toimenpiteet: Vastaaminen verkkolomakkeella Muutoksenhaku: Muutoksenhakukielto (valmistelua) - 1. Miksi Sähke2 ollaan siirtämässä suosituksen muotoon? 2. Tällaisen työryhmän tulisi olla laaja-alaisempi. Tietojärjestelmiä koskeva asiantuntemus tulisi olla mukana valmistelussa. 3. Luonnoksen kieliasu ei ole yhdenmukainen. 4. Palautelomakkeessa on aivan liian paljon vastattavia kohtia. Helpompi tapa olisi hoitaa kysely haastattelemalla asiantuntijaorganisaatioiden (myös muitakin kuin valtion virastoja) asiantuntijoita. - Suositus on looginen ja ymmärrettävä. Erittäin tarpeellinen. Selkeämpi kuin SÄHKE2. - JHS-suositus on hyvin laadittu ja se on ymmärrettävä, laadukas kokonaisuus. Joiltakin osin on ristiriitaisuutta päädokumentin ja liitteiden välillä. Päädokumentissa puhutaan, että metatiedot "pitää olla". Liitteessä "suositellaan niiden olevan". Tällaiset ristiriidat on syytä korjata. EU:n tulevan yleisen tietosuojavaatimuksen vaikutuksia jo tähän JHS-suositukseen kannattaisi pohtia. Asiakirjahallinnassa käsitellään henkilöitä koskevia arkaluonteisiakin tietoja. Tietosuojavaatimus tuonee mukanaan liudan vaatimuksia, joita olisi syytä ainakin ottaa huomioon jo nyt. Näitä ovat esimerkiksi henkilötietojen käsittelyn kohteena olevan henkilön oikeudet. "Tällaisia oikeuksia ovat omia henkilötietoja koskeva tiedonsaantioikeus, oikeus saada tiedot oikaistua, oikeus tulla unohdetuksi sekä oikeus tietojen

3 poistamiseen, tietojenkäsittelyn vastustamiseen ja tietojen siirtämiseen järjestelmästä toiseen." ( - Suositus vaikuttaa kattavalta ja asiantuntevalta. - Luonnos on kokonaisuudessaan kattava asikirjahallinnon ohje. Ohje on luettavuudeltaan selkeä. Ohjeesta on hyötyä, kun kehitetään asianhallintajärjestelmää ja tiedonhallintaa kokonaisuudessaan. - Kommentoimme jo aikaisemmin suositusluonnosta ja ne kommentit / muutosehdotukset näkyvät hyvin tässä versiossa. Tämä luonnos on jo mielestäni valmis hyvöäksyttäväksi. - Kävimme suositukseen liittyvät asiakirjat läpi tiedonhallinnan näkökulmasta. Suositus on tarpeellinen tulevaisuuden sähköisyyttä ajatellen myös koulutusorganisaatiossa. Näemme, että organisaation tietohallinnon ja asianhallinnan/asiakirjahallinnan yhteyden tulisi olla lähempänä toisiaan ja keskusteluyhteys näiden välillä tulisi olla aktiivisempaa kuin se tällä hetkellä on. Aikaa tämän suosituksen kommentoimiseen olisimme toivoneet enemmän, jotta em. keskusteluyhteys olisi saatu toteutettua organisaatiossamme. - (Tämä palaute on opetus- ja kulttuuriministeriön korkeakoulu- ja tiedepolitiikan osaston kokoama ja sisältää poimintoja opetus- ja kulttuuriministeriön muiden osastojen/yksiköiden näkemyksistä.) OKM asetti maaliskuussa 2013 arkistolakityöryhmän, jonka tehtävänä oli selvittää arkistolain ja -asetuksen keskeiset uudistustarpeet ja tehdä hallituksen esityksen muodossa esitys uudeksi lainsäädännöksi. Työn aikana kävi ilmeiseksi, ettei nykyinen viranomaisten tietoaineistojen käsittelyä ja tiedonhallintaa koskeva lainsäädäntö muodosta johdonmukaista kokonaisuutta. Työryhmä katsoo OKM:lle jättämässään muistiossa, että lainsäädäntöä on uudistettava sen tehtävänantoa laajemmin kokoamalla yhteen kaikki keskeiset tiedonhallintaa ja tietoaineistojen käsittelyä julkishallinnossa koskevat säädökset. Tämä ns. yleislain valmistelu on käynnistynyt ja vie vaativuutensa vuoksi pitkään. JHS 176 -suosituksen päivittäminen on ongelmallinen sekä ajallisesti että sisällöllisesti. Nyt valmisteilla oleva yleislaki määrittää, minkälaisilla välineillä asiakirjahallintaa jatkossa hoidetaan. On tarpeetonta ja toimijoille (laaja vaikuttavuus) mahdollisesti haitallista, mikäli JHS 176 päivitetään ennen lainsäädännön valmistelutyön etenemistä. Dokumentti näyttää suurelta osin perustuvan tilanteeseen ennen arkistolakiuudistusta. Jotta suositukseen voi ottaa kantaa, tulee sen sisältö arvioida uuden arkistolakikokonaisuuden näkökulmasta erityisesti huomioiden yleiseen tiedonhallinnan kehittämistarpeet. Arkistolakiuudistusta valmistellut OKM:n työryhmä katsoi, että lainsäädäntöä on uudistettava arkistolain päivitystä laajemmin kokoamalla yhteen yleislakiin kaikki keskeiset tiedonhallintaa ja tietojen käsittelyä julkishallinnossa koskevat säännökset ottaen huomioon informaation koko elinkaari. Tästä johtuen JHS 176:n päivittäminen esitetyllä tavalla on problemaattista, ja päivitys tulee lykätä ajankohtaan jolloin laajempi lainsäädännön uudistus on tehty. Tällä hetkellä käytössä oleva Sähke 2 -määräys antaa koskee asiakirjallisten tietojen käsittelyprosessien sähköistämistä ja tiedon sähköistä säilyttämistä. Sähke 2 on saanut kritiikkiä käyttäjiltä. Se on raskas ja sisältää oletuksia sellaisista asianhallintaan sisältyvistä rooleista organisaatioissa, joita ei tosiasiallisesti ole niissä olemassa. On argumentoitavissa, että Sähke 2 on olennaisesti hidastanut siirtymistä aidosti sähköiseen asianhallintaan. Sähke 2:n joistakin havaituista ongelmista päästäisiin eroon JHS 176:n uudistamisen myötä. Palautekierroksella oleva ehdotus JHS 176 -suositukselle pohjautuu samalla ajattelulle kuin Sähke 2. On varsin todennäköistä, että JHS 176 ei osoittautuisi pitkäikäiseksi. Kuitenkin sen vaikutusala on sangen laaja ja sen käyttö edellyttää järjestelmien ja ohjelmistojen päivittämistä sekä merkittävää lisäpanostuksen tarvetta organisaatioiden resursointiin ja osaamiseen, minkä taloudelliset ja toiminnalliset vaikutukset olisivat huomattavia. VTV antoi Tuloksellisuustarkastuskertomuksen Sähköisen arkistoinnin edistämisestä: VTV:n raportissa todetaan seuraavasti: Arkistolaitos on antanut yksityiskohtaisia määräyksiä (esimerkiksi SÄHKE-määräykset ja sähköisen säilyttämisen lupamenettely) sekä toteuttanut VAPA-palvelun sähköisten asiakirjojen arkistointia varten. Arkistolaitoksella on vakiintunut asema asiakirjojen elinkaarihallinnan ohjaajana, mutta asema on sen toimivaltaan nähden tulkinnanvarainen. Arkistolaitos on kokenut toimivansa toimivaltansa puitteissa, kun taas opetus- ja kulttuuriministeriö ja valtiovarainministeriö ovat katsoneet arkistolaitoksen ylittäneen toimivaltansa sähköisen asiakirjahallinnan ohjaajana. (s. 8)

4 SÄHKE-määräysten vaatimukset selittyvät arkistolaitoksessa tehtyjen haastatteluiden mukaan sillä, että niiden avulla on pyritty varmistamaan sähköisen asiakirjatiedon autenttisuus, eheys ja käyttökelpoisuus sekä mahdollistamaan sähköisten arkistojen siirto arkistolaitoksen sähköisten aineistojen vastaanotto- ja säilytyspalveluun (VAPA). Ehdottomuus, jolla on pyritty sähköisesti säilytettävän aineiston täydellisyyteen, on osaltaan hidastanut sähköiseen arkistointiin siirtymistä. Arkistolaitoksen antamat määräykset ovat lähteneet sen omista tarpeista ja näkökulmista. (s. 38) Vuonna 2011 voimaan tullut tietohallintolaki (634/2011) on aiheuttanut arkistolaitoksen toimivaltaa koskevia tulkintavaikeuksia etenkin syntysähköisen aineiston arkistoinnissa, jossa tietojen hallinnan, käytettävyyden ja säilymisen varmistamiseen liittyvät toimenpiteet tulee tehdä arkistolaitoksen näkemyksen mukaan jo tiedon elinkaaren alusta lähtien. Tiukasti tulkiten arkistolaitos puuttuu tällä ohjeistuksella organisaatioiden toiminta-arkkitehtuuritasoon, joka on organisaatioiden omalla vastuulla, ja tieto- ja järjestelmäarkkitehtuureihin, jotka nekään eivät ole tietohallintolain mukaan arkistolaitoksen vastuulla. Opetus- ja kulttuuriministeriö on pitäytynyt ohjauksessaan arkistolain tiukassa tulkinnassa. Sen näkemyksen mukaan arkistolaissa on selvästi määritelty arkistolaitoksen norminantovaltuudet: oikeus määrätä ainoastaan pysyvään säilytykseen tulevasta aineistosta, arkistotiloista, pysyvästi säilytettävien asiakirjojen tallennukseen käytettävistä materiaaleista ja menetelmistä sekä rekisteröinnistä ja luetteloinnista. Arkistolaitoksen SÄHKE-määräyksen voidaan siten nykymuodossaan tulkita ylittävän arkistolaitoksen toimivallan. (s. 40) Esitetty suositus on erittäin yksityiskohtainen ja lähestyy aihepiiriään tietoteknisen implementaation näkökulmasta. VTV:n tarkastuskertomuksessa Yhteentoimivuus valtion ICT-sopimuksissa todetaan, että tietojärjestelmähankintoihin kohdistuvilla moninaisilla säädöksillä hankintojen tekemisestä on tullut vaikeaa, kankeaa ja hidasta, vaikka nopeasti kehittyvä ICT-toimiala vaatisi samaan aikaan ketteryyttä ja joustavuutta. VTV:n mukaan tarkastuksessa havaittiin, että tietojärjestelmien nykyinen ohjaus asemoi ne kuitenkin edelleen muusta toiminnasta selvästi irrallaan olevaksi tukitoiminnoksi. Tällöin jäävät hyödyntämättä tieto- ja viestintäteknologian tarjoamat mahdollisuudet suunnitella toimintaa innovatiivisesti uudelleen tuottavuuden parantamiseksi. VTV:n lausuntoa mukaillen voidaan todeta, että JHS 176 -suosituksessa käytetty tekninen kieli vaikeuttaa ICT:n ja toiminnan vuoropuhelua. Suositus näyttäytyy irrallisena saarekkeena muun toiminnan kehittämisen näkökulmasta, koska toiminnan ja prosessien tason kuvauksia joko ei ole olemassa, tai ne on laadittu muusta kuin toiminnan kehittämisen näkökulmasta. Ensin tulisi koko virastokentän yhteisellä ponnistuksena laatia tavoitetila, jossa ketteryys ja joustavuus tuodaan osaksi kehittämisen substanssia, ja tämän jälkeen voidaan lähteä laatimaan tarvittavia teknisiä suosituksia, siltä osin kuin standardointi on tarpeen. Näistä syistä JHS 176 -suosituksen päivitystä tulee lykätä eikä suosituksen mahdollista uutta valmistelutyötä tule tehdä ilman ko. tehtäväalueen kunnollista toiminnan tason kohdearkkitehtuuria. Samalla voi todeta, että ilman soveltuvaa toiminta-arkkitehtuuria ei voi yleensäkään lähteä tekemään JHS-suosituksen tyyppistä teknisen tason määrittelyä. Detaljikommentteja: JHS 176 -suositus ei voi lähtökohtaisesti olla velvoittava eli suosituksessa ei voi esittää asioita ikään kuin ne olisivat pakottavia. Tämä todetaan kohdassa Johdanto: JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia. Tämä seikka tulee korostetusti tuoda esille kohdissa joissa esitetään vaatimuksia. Vaatimusten kohdalla tulisi selkeästi kertoa, että suositusta tulee tulkita vapaaehtoisen soveltamisen näkökulmasta. Kuitenkin dokumentin alussa todetaan: Suosituksessa kuvataan ne pakolliset vaatimukset, jotka julkishallinnon organisaatioiden tulee ottaa huomioon sähköisten asiakirjatietojen käsittelyssä, hallinnassa ja säilyttämisessä. Kohdassa Soveltamisala todetaan: Julkishallinnon tietojärjestelmät pitää laatia noudattaen tässä suosituksessa kuvattuja vaatimuksia. (Sana pitää on lihavoitu ja alleviivattu alkuperäisessä dokumentissa.) Asiakirjatietojen pitkäaikaissäilytystä ja soveltuvin osin siirtämistä koskevissa (erityisesti siirtoformaatit) vaatimuksissa tulee noudattaa julkishallinnon standardisalkkua ja Kansallinen digitaalinen kirjasto -standardisalkkua. Tarkastelussa painottui erityisesti osaston ja yksiköiden käyttäjätoiminta. Asiakirjassa kuvataan ne pakolliset vaatimukset, jotka julkishallinnon organisaatioiden tulee ottaa huomioon sähköisten asiakirjatietojen käsittelyssä, hallinnassa ja säilyttämisessä. Valmisteluvaiheessa olisi perusteltua arvioida onko suositus kuitenkin ohjeistus julkishallinnon organisaatioille johtuen asiakirjan velvoittavuudesta. Asiakirja sisältää pakollisia toimenpiteitä julkisen hallinnon organisaatiolle, jonka vuoksi asiakirja ei ole pelkästään suositus (esim. s.2-3). Asiakirjan velvoittavuus tulee käydä selkeästi ilmi asiakirjan johdannosta ja tarvittaessa eri asiakohdissa. Lisäksi asiakirjassa esitettyjen toimenpiteiden suhde olemassa oleviin tietojärjestelmiin jää vielä asiakirjassa avoimeksi.

5 Esimerkiksi asiakirjan sivulla 2 esitetty JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia. Esimerkiksi sivulla 3 julkishallinnon toimijoiden pitää noudattaa tämän suosituksen pakollisia vaatimuksia ja samalla sivulla mainitaan, että organisaation tulee aina määritellä omat tarpeensa ja vaatimuksensa ja laatia hankintojen vaatimusmäärittelyt niiden pohjalta. Suosituksessa esitettyjä saa ja on suositeltavaa käyttää pohjana, mutta niitä ei tule käyttää sellaisenaan, vaan organisaation on sovellettava niitä oman toimintansa tukemiseksi (s.3). Asiakirjassa olisi hyvä ottaa vahvemmin huomioon avoimien rajapintojen määrittely asiankäsittelyjärjestelmille jo niiden luomisvaiheissa. Toimivat avoimet rajapinnat edes auttavat hyvien sähköisten asiointipalveluiden luomista sekä estävät toimittajalukkoja. Asiakirjassa esitetty listaus käytetyistä termeistä ja lyhenteistä pidetään kannatettavana. Luvun 4 alussa voisi olla lyhytselvitys siitä, miten määritelmät on tehty ja mihin ne perustuvat. Miten fi-määritelmän merkityksen voisi avata asiakirjassa? Tilasiirtymät ja asiakirjojen säilytysajat: Käyttäjätoimijoita tulee tiedottaa riittävän ajoissa päivityksistä, muutoksista sekä käyttökatkoksista, jotta tietojärjestelmien käyttäjät pystyvät sopeutumaan ja suunnittelemaan toimintaa osastoilla ja yksiköissä (s.13). Pidetään kannatettavana, että kooste ja luokitus eivät ole toisistaan riippuvaisia: yksittäisen tehtävän sisällä olevat asiat voivat kuulua useisiin eri koosteisiin ja toisaalta yksittäiseen koosteeseen kuuluvat asiat voivat kuulua useisiin eri tehtäviin. Tämä parantaa mahdollisuutta hallita tiettyihin aihepiireihin liittyviä asioita silloin, kun asiat kuuluvat useaan eri luokkaan. - Suositukset ovat erittäin tärkeitä ja on hienoa, että julkishallinnon organisaatioita kannustetaan tiedonohjaussuunnitelmien laadintaan ja samalla huolehditaan tämän JHS176-suosituksen avulla siitä, että tietojärjestelmät ovat tarpeiden mukaisia. Suosituksen lukeminen on työlästä, kun itsellä ei ole suurta tietojärjestelmien ymmärrystä. Olisi hyvä, että suositukseen liittyen voitaisiin järjestää jotakin koulutusta, jossa olisi sekä Juhdan, Arkistolaitoksen, tietojärjestelmätoimittajien sekä julkishallinnon tietohallinnon ja asiakirjahallinnon asiantuntijoiden edustus. Suosituksessa voisi joitakin asioita ehkä ilmaista konkreettisemmin tai ainakin avata asian sisältöä enemmän käytännön esimerkein. Helpottaisi, jos malliksi otettaisiin esimerkiksi joku asiakirja, joita useimmissa organisaatioissa syntyy, esim. viranhaltijapäätös ja esimerkeissä kuvattaisiin aina myös tätä viranhaltijapäätöksen kulkua. Suositukseen on vaikea tehdä muutosehdotuksia, kun sitä ei riittävän syvällisesti ja konkreettisesti täysin ymmärrä. Olisi ollut kiinnostavaa osallistua ensin johonkin esittelytilaisuuteen, jossa suositusta oltaisiin esitelty. Kiinnostavaa olisi myös saada joitakin valmiita metatietomalleja eri asioista, joko tämän tai jonkin muun suosituksen yhteydessä. JHS-suosituksessa on hyvää ainakin se, että automaattinen hävitys on nyt mahdollista. Suositusta helpottaa myös yhteistyötä tietojärjestelmätoimittajien kanssa. - Suositus on hyvin perinteisen asiankäsittelyjärjestelmäpohjainen ja pohjautuu asian käsitteelle ja asiankäsittelyn seuraamiselle, vaikka sen soveltamisalaan on sivulla 3/23 sisällytetty myös data (suosituksessa kuvattuja vaatimuksia pitää noudattaa asiakirjatiedon muodosta riippumatta. Asiakirjatieto voi olla esim. dataa). Epäselväksi jää, miten asian käsittelyvaiheita ja toimenpiteitä toteutetaan datapohjaisessa järjestelmässä? esim. rekisterissä, jossa käsitellään ja myönnetään oikeuksia hakemuskäsittelyn perusteella. Käytännön esimerkit olisivat valaisseet tätä asiaa. Tekstissä on selkeästi ilmaistu pakollisuudet ja vapaaehtoisuudet, vaikka se aiheuttaa lukijalle välillä hankaluuksia ymmärtää, onko kyse suosituksesta kokonaisuutena vaiko kuitenkin yksittäisten osioiden osalta pakollisuudesta. Erityisesti liitteessä 2 pakollisten vaatimusten kokoaminen liitteeksi on varmasti hyödyllinen käyttäjille (sekä toimittajille, että käyttäjäorganisaatioille). Suosituksen soveltajan näkökulmasta on haasteita ymmärtää ja erottaa käsittelyvaihe / toimenpide -logiikkaa. Tekstissä todetaan: "Tietojärjestelmissä käsittelyvaiheet toteutuvat toimenpiteinä" jne. Mitä tämä tarkoittaa? Esimerkiksi tehtäväluokka ole pakollinen metatieto asialle tai asiakirjalle. Oletus ilmeisesti on, että se tulee toimenpiteen kautta. Tekstin sisällä on kursiivilla ja sisennettyinä esimerkkejä. Kahdessa tällaisessa kappaleessa kuitenkin esimerkki-teksti puuttuu (luvut 6 ja 7.2.1). Mikä tarkoitus näillä kahdella kappaleella on? - Arkistolaitoksen määräysvaltaa SÄHKE-normien osalta ei tule korvata pelkällä suosituksella. kunnallishallinnossa JHS-suosituksen kyllä huomioidaan, mutta nehän ovat vain suosituksia, joita ei ole pakko noudattaa. Kyllä Arkistolaitoksen määrysvalta sähköisen asiakirjatiedon käsittelylle tulee olla edelleen

6 kunnallisia arkistonmuodostajia velvoittava määräys. Kuntien toimintaa tämän osalta ei valvo enää arkistolaitos eikä kukaan mukaan, joten jo nyt vallalla oleva toimintatapa jatkuu eli säilytetään pysyvästi säilytettäväksi määrättyä aineistoa päämäärätehtäviin liittyvissä asiankäsittelyjärjestelmissä ja pysyvästi säilytettävien tietojen tulostaminen jossain elinkaaren vaihessa joko unohtuu tai sitä ei haluta tiedostaakaan. - Suositus vaatii vielä paljon työstämistä ennen kuin se voidaan hyväksyä. Olemme kommenteissamme nostaneet esille ennemminkin kysymyksiä kuin kommentoineet yksityiskohtaisella tasolla. Tämä johtuu siitä, että aihepiiriin paljon keskeneräisiä kysymyksiä. - Mikäli JHS 176:n on tarkoitus korvata SÄHKE2 vuoden 2015 lopussa, olisi suosituksen ollut hyvä valmistua aikaisemmin. Meille on tullut vastaan useita järjestelmiä uudistavia tarjouspyyntöjä, joissa asiakkaalle on ollut epäselvää, tehdäänkö uusi järjestelmä SÄHKE2:n vai JHS 176:n mukaisesti. Onko tarkoitus, että toimittajat voivat sertifioida ratkaisunsa JHS 176:n mukaisiksi, kuten nyt on toimittu SÄHKE2:n osalta? - STM kiittää mahdollisuudesta antaa palautetta. STM korostaa, että vaikka suositusluonnos on jossain määrin keskeneräinen niin se on hyvin tarpeellinen erityisesti SÄHKE2-normin seuraajana. - Selkeä ja käyttökelpoinen. Käytännön esimerkkejä voisi olla vielä enemmän. Suositus pitää vielä oikolukea. - Suositusluonnos on tehty hyvin. Kiitos siitä. - JHS suositus on selkeä kokonaisuus. Metatietojen määrittelyssä on hivenen vaihtelua dokumentin eri osissa. JHS suosituksessa olisi hyvä huomioida EU:n tietosuojasäännökset, sekä henkilötietojen säilyttämiseen liittyvät näkökohdat, mm. arkaluontoisten tietojen osalta. Tutkimuskäyttö, erityisesti avoimen tieteen ja tutkimuksen näkökulmasta korostaa myös koko elinkaaren aikana sähköisen aineiston saatavuutta, tallentamista, säilyttämistä ja tiedon löydettävyyden parantamista. Tämä suositus tukee myös tätä näkökulmaa. Suositus antaa kattavan kuvan myös muille organisaatioille, kuin julkishallinnolle, hallintoasioiden käsittelyprosessista ja arkistonmuodostussuunnitelmien kehittämisestä. - Kuinka ohjeella voidaan korvata määräys? Viittausten numeroinnit liitteissä olivat osittain väärin ja vaikeuttivat tarkastelua. - Johdannossa esitetyt tavoitteet ovat hyviä. Toisaalta, jos vaatimukset eivät ole velvoittavia, suosituksen tavoitteita ei saavuteta. Sitovuustaso jää epäselväksi. - Kommentit annettu yhteistyössä Poliisihallituksen, Keskusrikospoliisin, Poliisiammattikorkeakoulun, ja Länsi-Uudenmaan PL:n ja Hallinnon tietotekniikkakeskuksen kanssa. Suositus nähdään tarpeellisina. Tarve saada velvoittavaksi. Suositus vaatii jalkauttamista. Toivottavasti löytyy taho koulutuksen, JHS-cafe-tilaisuuksien (vähän kuin VAPA-infot) järjestämiseen. - Esimerkit soveltamisesta on erittäin hyödyllisiä ja niitä voisi käyttää laajemminkin selkiyttämää vaatimusten soveltamista. - Kommentoijat: Harri Eskola/tietohallintojohtaja, Maija Pylkkänen/asiakirjahallintopäälikkö Julkishallinnon toimijoita tulee kaikin keinoin kannustaa digitalisaatioon, joka julkisissa prosesseissa tarkoittaa mm. asiakirjahallinnan täyttä paperittomuutta. Kaiken normiohjauksen tulee tukea tätä päämäärää tekemällä digitaaliseen toimintaan pääsy mahdollisimman helpoksi samalla kuitenkin varmistaen asiakirjojen pysyvän säilytyksen tarpeet ja aktiiviajan asiakirjojen saatavuus. Tästä näkökulmasta kaikki toimet, jotka tuovat helpotusta nykyisen melko vaativan Sähke normin vaatimuksiin nähden, ovat erittäin tervetulleita. Digitalisaatiota edistävien toimenpiteiden tulee samalla vähentää turhia hallinnollisia esteitä ja uudistaa prosesseja. Tämä tavoite on mukana myös uudessa hallitusohjelmassa. Uusien suositusten tulisi rakentua siten, että sen avulla on mahdollista rakentaa uusia, entistä kevyempiä prosesseja ja helpottaa virastojen työtä, samalla tukien keskinäistä yhteensopivuutta. Tästä lähtökohdasta minimimäärä pakollisia asiakirjahallinnan tila/metatietoja ja niiden mahdollinen, suosituksen mukainen laajentaminen, olisi suotava lähestyminen. Tärkeää ei siis ole, että uusia toimintoja rakennettaessa joudutaan käyttämään paljon pakollisia tietorakenteita, vaan että kun käytetään tietorakenteita, ne ovat yhteensopivia normin ja muiden tietomallien kanssa. Osin tätä näkökulmaa on suosituksessa lähdetty noudattamaan, kannattanee harkita onko tarpeeksi. Suosituksen linjaus, että se koskee kaikkea, ei vain pysyvästi säilytettävää, asiakirjatietoa, on kannatettava. Sähköinen asiointi, sähköinen asianhallinta ja sähköinen arkistointi muodostavat saumattoman ketjun jolloin voidaan hyödyntää suosituksen mukaisia metatietoja koko asiakirjallisen tiedon elinkaaren ajan heti tiedon järjestelmään tallentamisesta alkaen. Jotta digitaaalisuus toteutuisi, tulee kaikki viranomaisen asiakirjallinen tieto saada hallintaan. Tämän edellyttää sitä, että suositus mahdollistaa laadukkaat, mutta samalla keveät

7 prosessit ja järjestelmät. - Pääosin perusteltu JHS -suositusluonnos. Kuitenkin suhdetta JHS 191:een ei ole määritelty. Samoin luokituksen käyttöä ei ole avattu: milloin voi käyttää tehtäväluokitusta ja/tai palveluluokitusta. Tietyt epäjohdonmukaisuudet, ja keskeneräisyys tulevat esiin etenkin liitteissä. - Suositusluonnos on Sähke2-normia selkeämpi ja paremmin käytäntöön sovellettavissa. Suositus tarvitsee muutosehdotuksissa mainittuja käsitteiden ja määritelmien tarkentamista. Hyvä, että mainitaan, että koskee myös määräajan säilytettävää aineistoa. - Tässä antamissamme kommenteissa olemme keskittyneet suositusluonnos-tekstiin, emme liitteisiin. Annetuilla kommenteilla ja ehdotuksilla on kuitenkin vaikutuksia mm. metatietoliitteeseen sekä vaatimusliitteeseen. Mikäli tietojärjestelmä on jo SÄHKE2-sertifioitu, tulisi sertifioinnin huomioiminen olla jotenkin mukana tässä suosituksessa. Mitä vaikutuksia jo myönnettyihin sertifikaatteihin tällä suosituksella on? - Kun käyttäjän roolia vähennetään, tällöin ajantasaisten TOS:n ja TOJ:n ja niiden metatietojen merkitys korostuu. Jäävätkö tietyt metatiedot, esim. nimikkeet liian yleiselle tasolle, kun ne valitaan listalta eli kuvaavatko ne riittävän hyvin esim. toimenpidettä, jotta myöhempi käyttö pystyisi niitä hyödyntämään riittävällä tarkkuustasolla (=todellisella toimenpiteellä joka tapahtui). Edelliseen liittyen voisi todeta, mikä merkitys loppujen lopuksi on näillä geneerisillä toimenpiteillä asiakirjatietojen myöhemmässä käytössä (esim. tutkimuskäytössä) on. Tämä suositus kohdistuu paljolti asiankäsittelyjärjestelmän tyyppisiin tietojärjestelmiin (=hallintoasian käsittely), muut tietojärjestelmät tullevat mukaan myöhemmin. Kun manuaaliseen diariin on merkitty toimenpiteet, onko niitä pakko merkitä yhtä uskollisesti asiankäsittelyjärjestelmiin. Eikö tehtävä, asia ja asiakirjatieto pelkästään riittäisi, jotka otettaisiin talteen myöhempää käyttöä varten. Toimeksiannot kuuluvat asiankäsittelyjärjestelmien toiminallisuuksiin, mutta niistä ei tarvinne tehdä toimenpiteitä. Mikäli asiankäsittelyjärjestelmiä halutaan tehdä käyttäjäystävällisemmiksi, niin asiaa voisi tarkastella ja selvittää tämä näkökohta huomioiden. - Suositusluonnoksen palautepyynnössä todetaan mm, että JHS 176-suosituksen uudistamistyön tarkoituksena on mm. korvata arkistolaitoksen antama SÄHKE2-määritys, jonka voi-massaolo on näillä näkymin päättymässä vuoden 2015 lopussa. Arkistolaitoksen SÄHKE2-määräyksessä sen todetaan perustuvan arkistolakiin (831/1994) sekä lakiin sähköisestä asioinnista viranomaistoiminnassa (13/2003), joiden mukaan arkistolaitoksella on oikeus antaa määräyksiä mm. asiakirjojen rekisteröinnistä ja sähköisen asioinnin kirjaamisesta, pysyvästi säilytettävistä asiakirjoista, pysyvään säilytykseen määrättyjen tietojen tallentamisen menetelmistä sekä pysyvästi säilytettävien asiakirjojen siirtämisestä arkistolaitokseen. Julkisen hallinnon tietohallinnon ohjausta koskevan lain (634/2011) 5 :n mukaan valtiovarainministeriön yhteydessä toimii julkisen hallinnon tietohallinnon neuvottelukunta (JUH-TA) joka antaa mm. julkisen hallinnon tietohallintoa koskevia suosituksia. Lain 6 :n mukaan valtiovarainministeriö voi päättää, että suositus on julkisen hallinnon tietohallinnon standardi. Lain 4 :n mukaan standardin velvoittavuudesta julkisessa hallinnossa voidaan säätää valtioneuvoston asetuksella lain 4 :n 2 momentin mukaisesti. Suosituksen johdannossa todetaan, että suosituksessa esitetyt vaatimukset eivät olisi julkisen hallinnon organisaatioille velvoittavia. Koska arkistolaitoksen SÄHKE2-määräys on nykyisen lainsäädännön perusteella viranomaisia velvoittava, ei JHS-suositus suoraan voine korvata arkistolaitoksen määräystä niistä vaatimuksista, jotka mm. ovat edellytyksenä asiakirjallisten tietojen pysyvälle sähköiselle säilyttämiselle ja arkistolaitoksen pysyvää sähköistä säilyttämistä koskevalle luvalle. Suosituksen johdannossa ja liitteessä 2 todetaan kuitenkin ristiriitaisesti, että suositus sisältäisi velvoittavat reunaehdot julkishallinnon asiakirjojen hallintaan käytetyille tietojärjestelmille sekä ne pakolliset vaatimukset, jotka julkishallinnon organisaatioiden tulee ottaa huomioon sähköisten asiakirjatietojen säilyttämisessä ja että vaatimukset on erotettu muusta tekstistä alleviivattuna. Epäselvyyttä velvoittavuuden suhteen lisää se, että alleviivatut kohdat suosituksessa on kirjoitettu esim. muotoon pitää tai saa ja ei saa sekä toisaalta on suositeltavaa. - - Valtioneuvoston kanslia antaa lausunnon koko valtioneuvoston puolesta vastatessaan valtioneuvoston ja sen ministeriöiden yhteisistä hallinto- ja palvelutehtävistä eli mm. asiakirjahallinnon ja arkistonmuodostuksen kokonaisuuteen liittyvistä tehtävistä ja hyvästä tiedonhallintatavasta - on erittäin hyvä, että uuden JHS-suosituksen tarkoituksena on kehittää sähköisten asiakirjatietojen hallintaa niin, että se tukee paremmin operatiivista toimintaa ja käyttäjälähtöisyyttä - Kun JHS-suositus sisältää pakollisia vaatimuksia, tulisi suosituksesta ilmetä vaatimusten säädöspohja - on hyvä, että pakolliset vaatimukset on kerätty omalle liitteelleen - suosituksessa sivun 2 alareunassa todetaan, että JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia, seuraavalla sivulla kuitenkin todetaan, että julkishallinnon toimijoiden pitää noudattaa suosituksen vaatimuksia

8 - 1) Ovatko TO:n tuottamat metatiedot tarkastettu ristiin JHS 191 kanssa? Esimerkiksi asiakirjan valinnaisista metatiedoista koodi ja käytetty koodisto tulisi tuottaa TOS:sta. Niitä ei ole kuitenkaan huomioitu JSH 191:ssä. Mielestämme suositusten tulisi vastata toisiaan TOS:sta tuotettavien metatietojen osalta, jotta TOS:n ja tiedonohjausjärjestelmien toteuttaminen olisi mahdollisimma yhtenäistä. 2) Toimenpiteen julkisuusluokka Metatietomallissa on määritely toimenpiteen julkisuusluokka, mutta kysymyslomakkeessa ei ole kohtaa sille. Onko toimenpiteelle tarpeellista määritellä julkisuusluokka? Voiko toimenpide olla salassa pidettävä, jos asia on julkinen? Jos metatieto on tarpeellinen, sitä on voitava tapauskohtaisesti muuttaa, joten tiedon lähteenä on oltava myös käyttäjä. 3) Suositus liitteineen on sekava ja se käytävä huolellisesti saatujen kommenttien perusteella ennen lopullista julkaisua. - Erityisen hyvää standardissa on se, että siinä on huomioitu sähköisen asioinnin ja sähköisen asiankäsittelyn vaatimuksia. Tiedonhallinnan tulisi olla ennemmin linkitettyä tieto-objektien välisiin suhteisiin perustuvaa kuin hierarkkiseen tiedon luokitteluun perustuvaa. Samaa tieto-objektia täytyy voida käsitellä useassa eri prosessissa ja sallia monenlaisia kontekstiin perustuvia luokitteluja yhdelle ja samalle tieto-objektille. Tullin näkemyksen mukaan tullin päämäärätehtäviä ei voida hoitaa dokumentti pohjaisilla asianhallintajärjestelmillä. Esimerkiksi Tullin päämäärätehtävien hoitoon tehdyt tietojärjestelmät on rakennettu komission tietomallien mukaisesti. Joissain päämääräprosesseissa käsitellään ja tuotetaan dokumenttimuotoista tietoa osana ilmoituksen tietojen käsittelyä. Näitä dokumentteja ei kuitenkaan katsota tarpeelliseksi käsitellä JHS176 mukaisen tietomallin mukaisesti vaan pääjärjestelmän tietomallia noudattaen. Näin ollen pakollinen relaatio asian, tehtävän ja asiakirjan välillä olisi keinotekoinen. - Kokemukseni vähäistä, en osaa arvioida. - Palautekierroskutsussa olisi ehdottomasti pitänyt kertoa suosituksen aiotusta laajuudesta: JHS 176-suositus on ensimmäinen JHS-suositus, josta aiotaan ohjeistavan suosituksen sijaan tehdä Tietohallintolain mahdollistava valtioneuvoston asetus. Näin suosituksesta tulee julkisen hallinnon organisaatioita sitova määräys, jonka vaatimusten toteuttaminen koko julkishallinnon laajuudessa ei ole lainkaan yksinkertaista. Palautteenantajien olisi pitänyt saada tietää tämä, jotta suositukseen ja sen kommentointiin olisi osattu suhtautua tarvittavalla vakavuudella. Näin palautteissa olisi osattu ajatella suosituksen soveltamiskelpoisuutta myös muissa kuin helposti valmisohjelmilla katettavissa JHS176-suostuksen mukaisissa järjestelmissä. Suosituksen johdanto päättyy vielä tavallisista JHS-suosituksista tuttuun lauseeseen JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia, mikä ei siis suosituksen käyttötarkoituksen huomioiden pidä lainkaan paikkansa. - Hyvää ja kannatettavaa on suosituksen pakottavuus ja velvoittavuus, jolla pystytään paremmin varmistamaan yhdenmukaiset käytännöt, edistämään järjestelmien ja määrittelyjen välistä yhteentoimivuutta. Erityisen tärkeää on, että suositus on myös järjestelmätoimittajia velvoittava. Vaatimuksiin liitetyt tapausesimerkit ovat riittävän kuvaavia. - Omasta puolestani voin sanoa suoraan, että olen aika kriittinen tätä paperia kohtaan. Musta on täysin järjetöntä asettaa suosituksia paperissa kuvatulla tasolla siellähän monessa kohtaa kuvataan tarkasti miten järjestelmän pitää toimia, ei sitä mitä halutaan saada aikaan. Käsittääkseni monet suosituksissa ovat ristiriidassa tyypillisten kaupallisten ratkaisujen perustoimintojen kuten SharePointin kanssa. Tämän tyyppisellä suosituksella luodaan pahimmillaan aika paljon räätälöintitarpeita ja käytännön seuraus on joko että julkishallinnon organisaatiot elävät ristiriidassa suosituksen kanssa tai että niille tulee paljon turhia kustannuksia räätälöinneistä ja niiden tulevaisuuden ylläpidosta. Onko paperia valmisteltaessa arvioitu esim. Minkälaisia kustannuksia toteuttamisesta aiheutuu? Miten hyvin erilaiset valmiit ratkaisut taipuvat paperin suosituksiin ilman räätälöintiä? Kaupalliset tai esim. avoimen lähdekoodin ratkaisut kuten Alfresco tms.? Onko jossain olemassa toteutuksia, jotka täyttäisivät nämä normit? Jos on, niin sitä tietysti pitäisi hyödyntää mahdollisimman paljon kustannusarviot, käytetyt ratkaisut jne. kannattaa tuoda esiin Jos ei, niin se on aika iso varoitussignaali silloinhan ollaan todennäköisesti antamassa teoreettista suositusta, jonka toteuttamisen järkevyydestä ei ole varmaa tietoa

9 Onko ylipäätänsä asiakirjahallinnon kustannustehokkuus ollut tavoitteena kun tätä paperia on tehty? Käytännössä oleellista on Valtion tasolla tehostaa julkisen sektorin toimintaa ja asiakirjahallinto on hyvä esimerkki puhtaasta tukitoiminnosta, joka pitäisi pystyä tekemään mahdollisimman pienin kustannuksin. Avainasemassa tehokkuuden suhteen on kyky käyttää valmiita ratkaisuja, joko kaupallisia tai avoimen lähdekoodin ratkaisuja. Olisi siis järkevää lähteä liikkeelle näistä ja etsiä tapa toteuttaa riittävän hyvät asiakirjahallinnon vaatimukset nojautuen mahdollisimman paljon valmiiden ratkaisujen ominaisuuksiin. /SA Yleistä: hyvää, että asetustekstissä oli asetuksen piiriin otettu myös määräajan säilytettävä aineisto. Sähköisessä ympäristössä asiakirjojen käytettävyys ja eheys taataan hyvin pitkälti samoilla keinoilla olipa kyse määräajan tai sp-aineistosta. Hyvää oli myös se, että asetus oli liitetty isoihin kansallisiin tavoitteisiin: tietojen yhteentoimivuus, avoin data sekä kokonaisarkkitehtuurit. / AJ Tekstissä mainitaan, että olennaisinta on tietojen eheys, luottamuksellisuus, saatavuus ja kiistämättömyys. Järjestelmien ja menettelyiden tulee tukea näitä vaatimuksia. JHS-suositukseen olisin kaivannut myös vaatimuksia/ohjeita siitä miten tiedon laatua valvotaan ja huolletaan viranomaisessa muutoin kuin täyttämällä JHS-asetus järjestelmän suunnitteluvaiheessa. Olisiko JHS-tekstissä voitu listata tapauksia, joissa asiakirjahallinnon tulisi olla mukana/ hoitaa/ valvoa? Vai tarvitaanko viranomaisissa lainkaan asiakirjahallinnon osaajia? / AJ Suositus koskee vain järjestelmiä, joissa on asiankäsittely: entäs muut purkit? Pitäisikös näihinkin kuitenkin viitata jotenkin ja antaa soveltuvaa ohjeistusta miten asioita pitäisi muunlaisissa järjestelmissä ratkoa./ AJ - Suositus on tarpeellinen, mutta sen velvoittava rooli jää ehkä hieman epäselväksi. Jos tämä pysyy suosituksen asteella niin kyseenalaista on kuinka laajamittaisesti sitä hyödynnetään. Fokukseksi määriteltiin operatiivisen toiminnan parempi tukeminen ja käyttäjälähtöisyys: suositus on varmasti hyödyllinen organisaatioille etenkin uusia tiedonhallintajärjestelmiä hankittaessa mutta sovellettavuus hankaloituu jos jo olemassaolevia järjestelmiä tulee muokata suosituksen mukaisesti. Tämä voi osaltaan hankaloittaa sitä, miten eri organisaatiot pystyvät noudattamaan suositusta. - Suositusluonnos sisältää lukuisan joukon pakollisia ohjelmiston toteutukseen kohdistuvia varsin yksityiskohtaisia vaatimuksia, jotka edellyttäisivät käsityksemme mukaan räätälöintejä myös yleisesti käytössä oleviin valmisohjelmistoihin (mm. Sharepoint). Suositusluonnoksen noudattaminen sellaisenaan johtaisikin verohallinnon tavoitteiden vastaisiin valmisohjelmistoräätälöinteihin. Siksi ennen suosituksen hyväksyntää pitäisi laatia selvitys suosituksen käyttöönoton vaikutuksista julkishallintoon mm.: - Selvittää siitä miten hyvin markkinoiden yleisimmät valmisohjelmistoratkaisut taipuvat suositusluonnoksessa esitettyihin pakollisiin vaatimuksiin ja mitä kustannusvaikutuksia vaatimuksien mukaisella toteutuksella olisi ratkaisun elinkaaren aikana asiakkaille. - Selvittää missä laajuudessa julkishallinnossa käytettävät ratkaisut/toteutukset kattavat jo nykyisellään suositusluonnoksessa esitetyt pakolliset vaatimukset - Laatia yhteenveto siitä millaisia kustannuksia sekä aikatauluvaikutuksia kehittämishankkeille olisi suosituksen käyttöönotosta julkishallinnossa. Toimittaja- ja kustannushallinnan näkökulmasta on lisäksi mielestämme tavoiteltavaa ettei suosituksella rajata vaatimusten mukaista markkinatarjontaa liian suppeaksi esim. muutaman toimittajan valmistuotteeseen tai pelkkiin räätälöintiratkaisuihin. - Suosituksen tavoite tulee määritellä ja sen tulisi olla selkeä sekä edetä luku luvulta sen mukaisesti. Puhutaanko suosituksessa asianhallinnasta, asiankäsittelystä vai asioiden käsittelystä jää epäselväksi. Asianhallinta ja asiankäsittely viittaavat normaalissa käytetyssä kielessä vain perinteisiin asianhallinta- ja asiankäsittelyjärjestelmiin eikä siis esim. substansseihin liittyviin asioiden käsittelyjärjestelmiin. Tämän suosituksen kohteena tulee olla myös edellä mainittuihin nk. perinteisiin asianhallinta- ja asiankäsittelyjärjestelmiin verrattavat substansseihin liittyvät asioiden käsittelyjärjestelmät esim. päivähoitojärjestelmät, lupajärjestelmät. Käsitteiden käyttö on horjuvaa kautta linjan, esim. puhutaanko asiasta, tiedosta, asiakirjoista, asiakirjallisesta tiedosta, asiakirjatiedosta. Milloin käytetään tehtävää, asiaa, toimenpidettä, asiankäsittelyprosessia, käsittelyprosessia: jää edelleen epäselväksi. Suosituksen tulee vahvistaa hallitusohjelman mukaista prosessilähtöistä ajattelutapaa asioiden käsittelyssä eikä organisaatiolähtöistä toimintaa. Mukaan tulee ottaa myös monitoimijaprosessit eikä vain julkishallinnon toimijoiden vaan muidenkin toimijoiden osallistuminen kuhunkin prosessiin. Yhdeksi lähtökohdaksi tulee tiedon avaamisen näkökulma, johon löytyy linjauksia ja perusteita VM:n sivustolla

10 olevasta linkistä Suositusteksti ei ole kovin lukijaystävällinen. Asiaa on paljon ja selkeyttämällä tekstin muotoilua ja rakennetta sen saisi luettavammaksi. Teksti täytyisi saada ytimekkääksi ja tiiviiksi keskittyen olennaisuuksiin. Kun tekstissä on korostettu pitää, on suositeltavaa, saa osat, tekstiin katoaa varsinainen vaatimus. Mitä nimenomainen vaatimus sisältää tulisi saada paremmin esille. Suosituksen (määräys) fokus tulisi kohdistaa nimenomaan julkiselle toimijalle sen operatiivisessa toiminnassa: Tee näin, älä näin. Lukujen 5 ja 6 rakenne ei ole selkeä. Luokitus on yksi metatieto, joka tulee sulauttaa lukuun Metatiedot ja niiden hallinta. Suositus tulee rakentaa siten, että yleiset, yhteiset vaatimukset on kirjattu ensin ja tämän jälkeen tapauksiin, muutoksiin liittyvät vaatimukset. Pakollisten vaatimusten nostaminen omaksi liitteekseen (Liite 2) on hyvä, mutta numeroinnissa (P1, P2 etc. )voisi mainita myös niiden numero metatietomallissa. Lisäksi niiden kohta varsinaisessa suositustekstissä löytyy paremmin, jos samaa numerointia (P1 etc) käytettäisiin myös suositustekstissä. Metatietomallissa eri metatiedot löytyvät paremmin, jos ne mainitaan sisällysluettelossakin sivunumeroviittauksin tai vähintään lopussa tulee olla aakkosjärjesteinen luettelo metatiedoista jolloin sieltä on katsottavissa miltä sivulta ko. metatieto löytyy. Suosituksessa on JHS 191 kanssa paljon päällekkäisyyttä, joka tulee karsia tässä suosituksessa. Liitteen mallissa tulisi pohtia joidenkin turhalta vaikuttavien tunnistetietojen poistamista tarpeettomana. Esimerkit voisi koota yhdeksi kokonaisuudeksi. - JHS 176:ssa on vielä terävöitettävää. Olennaista on, että keskeiset asiakirjahallinnan järjestelmille asetettavat vaatimukset ja suositukset esitetään selkeästi. Suosituksessa on pidettävä huoli siitä, ettei hukuta yksittäisiin metatietoihin, luokittamisiin tai avoimeen dataan (joka on muuten asiakirjahallinnasta erillinen teema). Pidetään kirkkaana mielessä asiakirjahallinnan keskeisimmät periaatteet, ne asiat jotka ovat staattisia ja esim. järjestelmätoteutuksista riippumattomia. - Suositusluonnosta on syytä vielä täsmentää ja selkeyttää, mutta se on myös tärkeä SÄHKE2-normin jatkaja. Yleisesti on hyvä, että asiakirjahallinnalle laaditaan yhteisiä vaatimuksia julkishallinnolle. Vaatimusten sopivuus THL:n vastuulla oleviin valtakunnallisiin terveydenhuollon ja sosiaalihuollon tietojärjestelmäpalveluihin olisi varmistettava. Tämän suositus ei saisi olla ristiriidassa myöskään JHS 191 -suosituksen kanssa. Luonnoksessa on todettu paljon hyviä periaatteita, kuten esim. että manuaalisesti täytettävät metatiedot on pyritty karismaan minimiin ja että metatietojen tarpeellisuus on arvioitava aina huolella hyödyn näkökulmasta. Tietoarkkitehtuurin tarkastelun kannalta on harmi, että kokonaisuuden tietomallia ei näytä olevan esitetty muuten kuin liitteenä 1, joka on luettelo kentistä merkityksineen. Olisi hyvä nähdä tietomalli myös kaaviona. Suosituksen tulisi tukea siirtymistä dokumentti-/ asiakirjakeskeisyydestä kohti rakenteellista tietoa. - On hyvä, että SÄHKE2-määräyksen sisältöä on tarkistettu ja se korvataan suosituksella. Suosituksen rooli herättää kuitenkin kysymyksiä. Suositus on kirjoitettu velvoittavaksi ja se sisältää "vaatimuksia" jotka "pitää" täyttää. Kuitenkin kyse on vain suosituksesta, joka ei voi suoranaisesti velvoittaa organisaatioita toimimaan sen mukaisesti. Suosituksen johdantoon olisin kaivannut vähintäänkin selvitystä siitä, miksi suosituksen vaatimuksia kannattaa noudattaa. Mitä hyötyä yksittäiselle organisaatiolle on vaatimusten noudattamisesta ja mitä riskejä niiden noudattamatta jättämisestä voi seurata. Suositus ei voi olla yhtä kuin määräys, joten jonkinlainen lukijan motivointi ja tavoitteiden kuvaus olisi paikallaan. Suosituksen käyttöönotto edellyttää koulutusta edellä mainitusta syystä. Suosituksen esitystapa on kohtalaisen selkeä, vaikkakin lähtökohta vaatimuksia sisältävänä suosituksena on ristiriitainen. Käsitemäärittelyt ovat riittäviä ja kieli pääosin ymmärrettävää. Häiritsevä yksityiskohta on puhekielisen "pitää" verbin käyttäminen "täytyy" verbin sijasta. - Hyvä että suositusluonnoksessa on käytetty esimerkkejä asioiden selkeytämiseksi ja ymmärrettävyyden lisäämiseksi Koska/Mikäli JHS-suosituksen pohjalta on tavoitteena toteuttaa tietohallintolain mukainen asetus tulisi se mainita selkeästi johdannossa sekä myös avata lyhyesti velvoittavuuden muutoksesta suhteessa "normaaliin" JHS-suositukseen

11 Suosituksen "nosto" asetustasolle edellyttää että se on sisällöltään selkeä ja yksiselitteinen - Yleistasolla voimme todeta, että JHS 176 pyrkii asiakirjatiedon hallinnassa toiminnallisten näkökulmien huomioimiseen, joka on hyvä piirre ja auttaa pohtimaan vaatimusten sovittamista tietojärjestelmäkehitykseen. Operatiivisissa ja toiminnan lähtökohdista toteutetuissa järjestelmissä, joissa toteutetaan asiankäsittelyä, on tietenkin aina haaste soveltaa hallintoasiankäsittelyn pohjalta laadittua suositusta. Hyödyntäminen ja yhteentoimivuus sekä avoin data on huomioitu ja näitä näkökulmia voisi vielä tuoda suositusmuodossa vahvemmin esiin. Suosituksessa on tuotu useita valinnaisia metatieto laajennuksia, jotka ehkä tuntuvat irrallisilta (päätietoryhmä, koodisto, kooste), koska niiden hyödyntäminen on osittain tulevaisuutta ja lähtee organisaation toiminnan tarpeesta. Hyvä on muistaa, että osa metatiedosta voidaan käsitellä rakenteellisena sisältönä ja asiakirjaobjektin muodostuessa viedä myös metatiedoksi. Toiminnan tarpeen ja lakisääteisten velvoitteiden minimivaatimusten toteuttamisen rinnalla on pidettävä mielessä kustannus-hyöty näkökulmat ja käyttäjäystävällisyys, joita suosituksessa ei ehkä koskaan voi korostaa liikaa. Metatietojen laajennukset (valinnaiset ja organisaation omat sekä toivottavasti enenevässä määrin julkishallinnon yhteiset) tarvitsevat tuekseen arvojoukkoja, mikä vaatii vielä toistaiseksi organisaation oman ratkaisun (esim. metatietopalvelun tai ne tuetaan tiedonohjauksen skeemalla). Enemmässä määrin olisi muistettava arvioida prosessin kehittämistä ja tukea sitä operatiivisten järjestelmien päättelylogiikalla, joka auttaisi kaiken tämä toiminnallisen ja hallinnan metatiedon tuottamisessa mahdollisimman automaattisesti. Rakenteellisen tiedon mahdollisuuksia yhdistettynä tiedonohjauksella tuettuun ja käsittelyprosessin sisältämään sekä tuottamaan tietoon on pyrittävä korostamaan, mikä sitten mahdollistaa sujuvasti hallitun asiankäsittelyn ja siinä systemaattisesti muodostettavan asiakirjatiedon hallinnan (asiakirjatiedosta vain osa on asiakirjatiedostoja, tulevaisuudessa mahdollisesti enenevässä määrin kuvailevaa ja käsittelyprosessitietoa). Voidaan ottaa esimerkiksi hallintoelimen kokouksen päätöksenteko: esityksessä päättäjälle esitetään kaikki tiedot, päätetään, prosessissa on pöytäkirjaan liittyviä toimenpiteitä useita, joista muodostuu kaksi pöytäkirja versiota täydellinen osittain salassa pidettävä versio ja julkaistava versio. Tämän lisäksi, kun päätöstieto on rakenteistettu myös muiltakin osiltaan, saadaan siihen mukaan päätöksen raha-arvoja, paikkatietoja tai muuta vastaava ja nämä voidaan sitten välittää toimeenpanoon tai ohjelmointirajapintaan avoimelta osaltaan myös koneluettavassa muodossa. Suositus tulisi olla sellainen, että organisaatiot ymmärtävät miten sitä voidaan soveltaa ja saada toimiva ratkaisuja aikaan, ilman ristiriitaisia tulkintoja tietohallinnon ja asiakirjahallinnon välillä. - - Suosituksen tarkoituksena on käsittää asiakirjatietojen käsittely, hallinta ja säilyttäminen kokonaisuudessaan kaikissa järjestelmissä, mutta kuitenkin tekstistä ilmenee, että tarkoitetaan vain asianhallintajärjestelmää. On siis selvennettävä, mitä suositus koskee. - Suositus ei julkisen hallinnon organisaatioita velvoittava (luku 1), mutta jos sitä kuitenkin noudattaa, mitä hyötyä siitä organisaatiolle on? Toisaalta esimerkiksi luvusta 2 saa käsityksen, että julkishalinnon pitää noudattaa suosituksen pakollisia vaatimuksia. - Mihin kokonaisuuteen suositus liittyy ja miten sen noudattamista valvotaan? Suosituksen sanotaan olevan jatkumo SÄHKE2-määritykselle: täydentääkö suositus SÄHKE2:ta vai onko se SÄHKE2:n seuraaja? - Jos organisaatio noudattaa suositusta, tarvitaanko arkistolaitokselta enää erikseen seulontapäätöstä? - Osa määritelmistä on varsin erikoisia, mm. asian määritelmä: "asiakirjatietojen kokonaisuus, joka muodostuu tehtävän hoitamiseen liittyvissä käsittelyprosesseissa"? Tuo voi toki olla ilmentymä tietojärjestelmässä, muttei määritelmä. Asiakirjatiedot syntyvät asiaa käsiteltäessä, mutta ne eivät synnytä asiaa. - Suositus ei rajaa mitään tehtävää suosituksen ulkopuolelle, ilmeisesti ei kuitenkaan ole ajateltu, että tämä koskisi sosiaali- ja terveyspalveluiden järjestelmiä? - Suositusluonnosta tulisi editoida ja yhtenäistää erityisesti käsitteiden osalta ennen kommenttikierrosta. - Suositus vaatii vielä paljon hiomista ja selkeyttämistä, ennen kuin sen voi hyväksyä. - Suositus on sujuvaa tekstiä ja vaikuttaa eheältä kokonaisuudelta. Tässä esitetyt kommentit ovat enimmäkseen terminologiaan liittyviä. Varsinaisesti vaatimusten ja suositusten selkeys punnitaan tehtäessä auditointeja suositusta vasten. 4. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1-5 (5 = samaa mieltä, 1 = eri mieltä) Vastaajien määrä: 53

12 Yhteensä Keskiarvo Suositus on tarpeellinen ,28 Suositus on otettavissa käyttöön ilman tukea ja koulutusta Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla , ,04 Yhteensä ,34 5. Suositusluonnoksen hyväksyminen Vastaajien määrä: Vastustusperusteet Vastaajien määrä: 7 - Suosituksessa tulisi ottaa huomioon kattavasti julkisen hallinnon asiakirjatuotanto eikä pelkästään asiankäsittelykeskeistä asiakirjatuotantoa. Toisaalta jos suosituksen ulkopuolelle rajataan tietohallintolain ulkopuolella olevat organisaatiot, merkittävä osa julkisuuslain piiriin kuuluvista asiakirjoista jää suosituksen ulkopuolelle. Suositus on suositeltavaa palauttaa uuteen valmisteluun siten, että siinä huomioidaan asiakirjojen tuottaminen kuntien palveluprosesseissa. VM, OKM ja OM ovat esittäneet, että tiedonhallinnasta säädettäisiin oma lakinsa. Tällä on väistämättä vaikutus myös suosituksen sisältöön. Tämä valmistelu on syytä ottaa huomioon jatkovalmistelussa. - Tässä muodossa suositus ei palvele ketään. Ei käy selvästi ilmi tehdäänkö tietojärjestelmäsuositusta, kirjoitetaanko SÄHKE2 -normia uudestaan vai suositusta järjestelmien tekijöille vai järjestelmän käyttäjille? JHS 176 -suosituksen päivittäminen on ongelmallinen sekä ajallisesti että sisällöllisesti. Suunniteltu ns. yleislaki (joka kokoaa yhteen kaikki keskeiset tiedonhallintaa ja tietoaineistojen käsittelyä julkishallinnossa koskevat säädökset) määrittää, minkälaisilla välineillä asiakirjahallintaa jatkossa hoidetaan. On tarpeetonta ja toimijoille mahdollisesti haitallista (ottaen vielä huomioon asioiden laajan vaikuttavuuden), mikäli JHS 176 päivitetään ennen lainsäädännön valmistelutyön etenemistä. Lisäksi suosituksen suositusluonnetta on vaikea sovittaa yhteen itse suositustekstin vaatimus-tyyppisten ehtojen kanssa. Esitetty suositus on erittäin yksityiskohtainen ja lähestyy aihepiiriään tietoteknisen implementaation näkökulmasta. Tällöin jäävät hyödyntämättä tieto- ja viestintäteknologian tarjoamat mahdollisuudet suunnitella toimintaa innovatiivisesti uudelleen tuottavuuden parantamiseksi. Samalla on nähtävissä merkittävä riski, että suositus hankaloittaisi siirtymistä aidosti sähköiseen asianhallintaan ja lisäisi merkittävästi tietoteknisten järjestelmien kustannuksia. Näistä syistä JHS 176 -suosituksen päivitystä tulee lykätä eikä suosituksen mahdollista uutta valmistelutyötä tule tehdä ilman ko. tehtäväalueen kunnollista toiminnan tason kohdearkkitehtuuria. - Suositus ei ole veloittava määrys eikä siten sido kunnallisia arkistonmuodostajia/ kuntia, joten jatkossa

13 tietojärjestelmähankinnat eivät ole Sähke-serfikaatin mukaisia. - Mikäli suositus käsittelisi muitakin tietojärjestelmiä, kuin dokumenttipohjaisia asianhallintajärjestelmiä, olisi sille tarvetta. - JHS ei huomioi keskeistä lainsäädäntöä, esim. lakia julkisen tietohallinnon ohjauksesta (634/2011), 2, "Tätä lakia ei sovelleta Ahvenanmaan maakunnassa toimiviin maakunnan, valtion ja kunnallisiin viranomaisiin" tai arkistolakia (831/1994), 2, "Tätä lakia sovelletaan kuitenkin Ahvenanmaan maakunnassa toimiviin valtion viranomaisiin Ahvenanmaan itsehallintolain (1144/91) 30 :n 17 kohdassa säädetyin rajoituksin". Työssä ei myöskään ole huomioitu Ahvenanmaan julkisuuslakia tai arkistolakia. Samoin todettakoon, että oikeusministeriö on vahvasti ottanut kantaa sen puolesta ettei JHS:n tapaista lain kautta oikeudellisen aseman saavaa ohjeistusta anneta kommentoitavaksi ennen kuin valtionhallinto on saannut tekstin kommentoitavaan muotoon molemmilla kotimaisilla kielillä. Tämä tosiasia (ruotsinkielisen version puuttuminen) estää muun muassa Ålands landskapsregeringiä (Ahvenanmaan maakuntahallitusta) kommentoimasta ko. suositusta/määräystä. 7. Yleiset muutosehdotukset Vastaajien määrä: 24 - Olisi hyvä, jos myös pakolliset sisältömetatiedot määriteltäisiin suosituksessa, koska ne kuitenkin ovat ne metatiedot, joilla haut tehdään. Suosituksessa olisi hyvä ohjeistaa, että TOJ on voitava pakottaa asianhallintajärjestelmässä niin, ettei asiakirjan luominen ole mahdollista ilman sitä. - Julkisella hallinnolla on ollut tavoite löytää yksi yhteinen terminologia. Miksi JHS tekee omaa terminologiaa? Esimerkkinä nostamme esille termin Asia. Lienee jokin käsittelyssä oleva kokonaisuus esim. muutoksenhaku eikä asiakirjatietojen kokonaisuus. - Suosituksesta puuttuu kappale käyttöoikeuksien osalta, jos niiden periaatteita ei määritellä unohtuvat ne tietojärjestelmän vaatimusmäärittelyistäkin. Hankintojahan määrittelevät useimmin ne, jotka eivät toimi - Suosituksen tarkoitus käsittää asiakirjatietojen käsittely, hallinta ja säilyttäminen kokonaisuudessaan kaikissa järjestelmissä, mutta kuitenkin tekstistä ilmenee, että tarkoitetaan vain asianhallintajärjestelmää. On selvennettävä, mitä suositus koskee. Suositus ei velvoittava, mutta jos sitä kuitenkin noudattaa, mitä hyötyä siitä organisaatiolle on? Jos organisaatio noudattaa suositusta, tarvitaanko arkistolaitokselta enää erikseen seulontapäätöstä? Mihin kokonaisuuteen suositus liittyy, miten sen noudattamista valvotaan? Suositus ei rajaa mitään tehtävää suosituksen ulkopuolelle, ei ilmeisesti kuitenkaan ole ajateltu, että tämä koskisi sosiaali- ja terveyspalveluiden järjestelmiä, joilla on jo olemassa omat ratkaisunsa. Vaihtoehtoisten luokitusten salliminen (tehtäväluokitus ja palveluluokitus) herättää kysymyksiä ja aiheuttaa ristiriitoja. Vähintäänkin pitäisi selventää missä tilanteissa käytetään mitäkin luokitusta sekä miksi erilaisten luokitusten käyttö sallitaan. - Eri dokumenttien välillä on ollut ristiriitoja. Esim. julkisuusluokka-metatiedon pakollisuus toimenpiteellä on kuvattu liitteessä 3 pakolliseksi, mutta ei liitteessä 2. Liitteessä 3 on kuvattu useiden kenttien kohdalla, että ne eivät ole pakollisia, mutta suosituksessa ne on kuvattu pakollisiksi julkishallinnon organisaatioille (esim. suojaustaso ja turvallisuusluokka). Liitteessä 3 on mainittu sähköisesti allekirjoitettavan asiakirjan pakollisina tietoina: Tarkastaja, Aikamääre ja Kuvaus. Näitä ei mainita suositusluonnoksessa eikä Liite 2:n pakollisissa vaatimuksissa eikä Liitteen 1 Metatietomallissa - Suosituksessa puhutaan yleisesti useissa kohdissa tietojärjestelmästä, mutta aina ei tekstistä tule esille se, tarkoitetaanko ko. kohdassa tiedonohjausjärjestelmää vai asiankäsittelyjärjestelmää vai sähköistä arkistointijärjestelmää vai jotain muuta. Käsitteet, kuten asiakirjatieto, tulisi ankkuroida tiettyyn standardiin tai julkishallintoa velvoittavaan lakiin. Myös lähteet ja viittaukset puuttuvat. - Terminologian yhdenmukainen käyttö läpi suositukset. (Ks. terminologiaa koskevat kommentit) Esimerkkejä voi olla lisääkin. - Suositukseen tai sen yhteyteen toivoisi lisättäväksi kokonaiskuva asiakirjahallinnan eri kehyksistä ja ohjausmalleista. JHS 176 tulee korvaamaan Sähke 2 normin, jonka voimassaolo päättyy Suosituksessa tulisi ottaa kantaa siihen, mitä siirtymä uuteen suositukseen (myöhemmin normiin?) tarkoittaa

14 niille, joilla on sähköisen arkistoinnin lupa Sähke 1 tai Sähke 2 mukaisena. JHS 176:ssa siirtotoiminnallisuus (siirto pysyvään sähköiseen arkistointiin) on pakollinen osa järjestelmäkokonaisuutta, kun Sähke 1 luvassa sitä ei vaadittu ja Sähke 2 luvissakin siitä myöhemmin luovuttiin. Epäselväksi jää, liittyykö suosituksen mukaisten järjestelmien käyttöönottoon ja pysyvään sähköiseen arkistointiin edelleen lupaprosessia ja järjestelmien sertifiointeja. Tässäkin kohdin siirtymisestä pitäisi tehdä sellainen, että hallinnollinen taakka jää minimiin. - Suositukseen tulisi ottaa mukaan myös asiakirjan sisältöä koskeva metatiedot. Tietojärjestelmiin tulisi saada myös mahdollisuus valita pakollinen TOS-integraatio, joka voitaisiin laittaa päälle esim. järjestelmän pääkäyttäjän toimesta. Mikäli tällaista ominaisuutta ei järjestelmässä ole, mahdollistuu järjestelmän käyttäminen siten, että TOJ- ohjaustiedot eivät lainkaan siirry asiakirjoille. - Suhde JHS 191:een on kirjoitettava auki. Se, milloin käytetetään kumpaa tahansa luokitusta tai molempia tulisi avata. Epäjohdonmukaisuudet, puutteet ja virheet tulisi korjata ennen suosituksen hyväksymistä - Suosituksen tarkoituksenmukaisuutta JHS-suositusten kokonaisuudessa ilman sen velvoittavuutta viranomaisia kohtaan sekä sen suhdetta arkistolaitoksen SÄHKE2-määräykseen on arvioitava uudestaan ja täsmennettävä. Tekstissä ilmaistujen erilaisten vaatimusten ja suositusten esittämistapaa on selkeytettävä. - Suosituksen kieliasu vaatii hiomista. Termien käyttö yhdenmukaiseksi mm. suosituksessa käytetty sekä asiakirjallinen tieto että asiakirjatieto, vaikka KA:ssakin on linjattu, että nykyään käytetään mieluummin jälkimmäistä. Asiankäsittelyn sijaan suositeltavampaa olisi tänä päivänä käyttää asianhallintaa ja kirjaamisesta rekisteröintiä. Suosituksessa ei mainita, koskeeko se myös rekisteröimätöntä tietoaineistoa. Suositustekstissä on vaatimuksissa ja esimerkeissä sidottu tiettyjä käyttövaltuuksia rooleihin, jotka eivät sovellu kaikille organisaatioille tai vaikeuttavat esim. kirjaamon toimintaa. Roolit tulisi kuvata suosituksessa väljemmin (erikseen määritellyin käyttöoikeuksin) tai esimerkinomaisesti. (Ks. kommentit/korjausehdotukset lukuihin 5.5 ja 6.2.) Luvussa 5.1 todetaan: Tietojärjestelmän tuottamana saa toteuttaa myös valinnaisia tai organisaation itse määrittelemiä ja tarvitsemia metatietoja. Tämä on erittäin tärkeä näkökulma, millä voidaan parantaa käytettävyyttä. Lisäksi tarvittaisiin metatietopalvelu, joka tukisi yhtenäisten metatietojen käyttöä ja semanttista yhteentoimivuutta. Suosituksessa ja sen liitteissä on usein salassapitoon liittyvien metatietojen lähteenä ainoastaan TOS. Myös käyttäjän on voitava antaa tiedot, sillä jokaisen asiakirjan salassapito punnitaan sen sisältämän tiedon perusteella, ja samaan tehtävään liittyen on täysin mahdollista laatia julkinen, ST IV tai ST III asiakirja. Jos oletuksena on (suositus luku 5.2.1), että TOS laaditaan siten, että jokaista mahdollista julkisuusluokkaa varten siihen laaditaan omat rivinsä, se paisuttaa TOS:n hallitsemattomaksi. Ainakin osassa valtioneuvoston ministeriöitä lähes kaikissa substanssitehtävissä julkisuusluokka vaihtelee täysin tietosisällön mukaisesti. Liitteen 1 (Metatietomalli, metatietokortit) osalta on tarkasteltava uudestaan tiedon lähdettä. Useissa metatiedoissa tiedon lähteenä on vain TOS tai tietojärjestelmä, mikä ei riitä. Useiden metatietojen osalta myös käyttäjän on voitava toimia vaihtoehtoisena metatiedon lähteenä. Tämä koskee esim. salassapitoa, turvallisuusluokittelua, suojaustasoa, asiasanoja, päätietoryhmää. TOS:n avulla ei voida varautua esim. suojaustason määrittelyyn, vaan käyttäjän on se viime kädessä määritettävä. Tietojärjestelmä ei voi tietää asiakirjan voimassaoloa, esim. sopimukset. Liitteen 1 (Metatietomalli) kohdalle Julkisuusluokka ei ole palautelomakkeessa kohtaa. Toimenpiteen julkisuusluokan lähteenä pitää voida toimia käyttäjän TOS:n lisäksi. Monen muunkin metatiedon lähteenä on toimittava tietojärjestelmän ja/tai TOS:n ohella käyttäjän. - 1) Suosituksen rakenne on monin paikoin epäjohdonmukainen. Esimerkiksi luvun 5.1 Tietojärjestelmän tuottamat metatiedot alalukuna on luku Tilasiirtymät. Mielestämme tilasiirtymien käsittely suosituksen tässä kohdassa vaikeuttaa suosituksen kokonaisuuden hahmottamista. 2) Suosituksessa esitetyt vaatimukset voisi numeroida. Tämä helpottaisi vaatimusten hahmottamista. 3) Suosituksessa esityt vaatimukset tulisi esittää loogisemmin ja järjestelmällisemmin esimerkiksi niin, että sitovat vaatimukset ovat ensin ja sitten suositukset. Nyt sitovat vaatimukset ja suositukset ovat tekstissä sekaisin, mikä vaikeuttaa hahmottamista. 4) Suosituksessa on liikaa toistoa. Esimerkiksi pakolliset metatiedot on esitetty suositustekstissä sekä liitteissä 1 ja 2. Mielestämme riittää, että metatiedot esitetään liitteessä 1. Tämä helpottaisi jatkossa myös suosituksen ylläpitoa. 5) Samassa vaatimuksessa saattaa olla sekä pakollinen vaatimus että suositus (esim. P7, P16). Pakolliset

15 vaatimukset ja suositukset on erotettava erillisiksi vaatimuksikseen ja suosituksiksi. 6) Samassa vaatimuksessa voi olla kaksi tai useampi asia (esim.p15). Mielestämme yhdessä vaatimuksessa tulee olla vain yksi asia. - Asiakirjahallinnon vaatimukset tietojärjestelmille on kuvattu MoReq2010 -standardissa. Otsikko tulisi muuttaa: Asiakirjahallinnan vaatimukset dokumenttipohjaisille asianhallintajärjestelmille. Perustelu: suosituksessa ei käsitellä tietojärjestelmiä yleisesti, vaan dokumenttipohjaisia asianhallintajärjestelmiä. - Suosituksen soveltamisalue tulee rajoittaa hallinnollisiin järjestelmiin, sillä vaatimusten toteuttamisessa substanssijärjestelmiin ei organisaatioilla ole käytettävissä resursseja. Ei voi pitää itsestäänselvyytenä, että aivan kaikki asiankäsittelyjärjestelmät pitää yhteentoimivuuden nimissä saada välittämään tietoja järjestelmästä toiseen. Kaikki järjestelmät eivät vain taivu tähän erityispiirteidensä, kuten prosessin monimutkaisuuden vuoksi eikä kaikkien tietojärjestelmien tietoja voi välittää edes viranomaisten kesken. JHS176 kaltaiset vaatimukset sopivat hallintolain mukaisiin järjestelmiin, jossa käsittelytarpeet pystytään saavuttamaan helposti järjestelmätoimittajien JHS176-vaatimukset huomioivalla valmisohjelmalla. Kun valmisohjelma ei kuitenkaan muun muassa työnkulkujen vuoksi riitä, on JHS176-suositusta vaikeaa noudattaa ja toteuttaa järjestelmiin. Suosituksen sitovuudella vaikeutetaan myös kustannustehokkaiden avoimen lähdekoodin ohjelmien hyödyntämistä, kun ohjelman käyttöönoton lisäksi resursseja tarvittaisiin suosituksessa säädeltyjen kansallisten vaatimusten toteuttamiseen. Koska kyse on kansallisista vaatimuksista, vaikeuttaa suositus samalla toimintaa myös kansainvälisten yhteistyövirastojen kanssa. Organisaatiossamme on esimerkkejä myös siitä, miten järjestelmä on saatu kansainväliseltä yhteistyövirastojen kehittäjiltä, eikä tällaisissa tilanteissa vain voi huomioida kansallisia tiedonhallintavelvoitteita. Näissä järjestelmissä tiedonvaihto on usein taattava kansainvälisesti, eikä kansalliseen tiedonvaihtoon ole kuin hyvin rajoitetusti tarvetta. Lisäksi järjestelmäversion päivittyessä, pitäisi aina muistaa huolehtia tiedonhallinta-komponentin soveltuvuudesta, mikäli vaatimukset olisi vain suosituksen sitovuudesta johtuen pakko jollakin keinolla saada toteutettua niille sopimattomaan kontekstiin/järjestelmään. JHS-Työryhmän olisi erittäin perusteltua rajata JHS176 vaikutusalue vain yleishallinnollisiin järjestelmiin. Lisäksi suositusta pitää saada konkreettisemmalle tasolle, jotta järjestelmäkehittäjillä olisi apuvälineitä asianhallintavaatimusten toteuttamiseen. Suositus ei toimi yksinään, jos siitä puuttuu laajat esimerkit vaatimusten käytännön toteuttamisesta. - Dokumentti vaatii oikolukua ja sujuvoittamista / SK jhs 191 ja jhs 176 suositusten välinen suhde olisi hyvä avata lukijoille. Olisiko nämä kaksi suositusta voitu jopa yhdistää samaan suositukseen. / OK Toivoisin, että suosituksessa olisi erityisesti pakollisten metatietojen osalta selkeämpi perustelu, miksi kyseinen metatieto on pakollinen. jhs 191 metatietomallissa on kuvattu metatietojen käyttöä, samoin tämän jhs 176:n metatietokorteissa, mutta perustelut pakollisuudelle eivät tule muutamaa poikkeusta lukuun ottamatta esille. Yleiset perustelut kuten Johdantokappaleessa "eheyden ja todistusvoimaisuuden varmistaminen" ovat alan ammattilaisille tuttuja perusteluja, mutta esim. millä perusteella toimenpiteen identifiointitunnus (kappaleessa 5.1) on pakollinen? Käyttö-kuvauksessa kerrotaan, että identifiointitunnus varmistaa yksilöintiä, mutta se ei kerro tai perustele, miksi toimenpide pitää yksilöidä? /OK Miksi suosituksessa vaaditaan, että tietty metatieto muodostuu tietyn lähteen tuottamana (tiedonohjaussuunnitelma / tietojärjestelmä), eikö tämä määrittele (turhaan) teknistä toteutusta? Toki nämä voivat olla esimerkkeinä tai suosituksena. Lisäksi osa vaatimuksista on ristiriidassa jhs 191:n kanssa, esim. salassapidon laskentaperuste, joka tässä jhs 176:ssa on vaadittu muodostuvan TOS:n tuottamana, kun taas jhs 191:ssä todetaan, että myös operatiivinen järjestelmä voi sen muodostaa / OK - Eniten hämmennystä aiheutti Liite 1 Metatietomalli kohta Säilytysajan pituus: "Säilytysajan pituus on suositeltavaa periyttää asialta kaikille siihen kuuluville asiakirjoille. Eli että kaikilla asian asiakirjoilla olisi sama säilytysaika - tämä näkemyksemme mukaan hankaloittaisi tiedonhallintaa huomattavasti jos asialle ja sen alla oleville asiakirjoille tulisi kaikille määritellä sama säilytysaika. Tällöinhän tiedonohjaus tapahtuisi säilytysaikavetoisesti mikä ei välttämättä tue organisaation tarpeita jolloin kysymys operatiivisen toiminnan paremmasta tukemisesta ja käyttäjälähtöisyydestä hämärtyy - tämä intressi tukee pääosin pysyvän säilytyksen näkökulmaa. Toki on huomioitava että lausemuoto on "on suositeltavaa", jolloin velvoittavuus jäänee jokaisen organisaation omaan harkintaan. - Vrt yleiskommentit - Suosituksessa olisi hyvä esittää asioiden, toimenpiteiden ja asiakirjojen väliset suhteet tietomallin muodossa (esim. SÄHKE2:n metatietomallin kuva 1). Koska kyseessä on tietojärjestelmille asetettavat vaatimukset, on kerrottava konkreettisesti kuinka asiat, toimenpiteet ja asiakirjat liitetään tiedonohjaukseen. Tässäkin toki voidaan jättää liikkumavaraa ratkaisukohtaisille toteutuksille, mutta suosituksen alkupäässä olisi hyvä esittää selkeästi, että 1) asia liittyy yhteen tehtäväluokituksen tai palveluluokituksen luokkaan ja noudattaa sen

16 mukaista tiedonohjaussuunnitelmaa, 2) tiedonohjaussuunnitelmaan kuvatut toimenpiteet kytketään osaksi tietojärjestelmän toiminnallisuuksia ja 3) asiakirjatyyppi (tai asiakirjatyypin tarkenne, jos tyyppi ei riitä) liittää talteen otetun asiakirjan tiedonohjaussuunnitelmaan ja tuo asiakirjalle TOS-metatiedot. Monen metatiedon kohdalla on suositeltavaa, että se tuotetaan asian, toimenpiteen tai asiakirjan luomisen/tallentamisen yhteydessä. Mielestäni tämän tulisi olla keskeisimpien metatietojen osalta pakollista. Näin oli SÄHKE2-määräyksessä ja tämä on yksi keskeisimmistä suomalaisen asiakirjahallinnon ominaispiirteistä. Metatiedoista saatavat hyödyt menevät muutoin osittain hukkaan ja toisaalta jos metatietoja merkitään myöhemmin, niissä saattaa herkemmin esiintyä myös virheitä. Suositus ei sisällä xml-skeemoja tms. muotovaatimuksia, lisätäänkö ne myöhemmin? Pitäisikö jokaiselle asialle, toimenpiteelle ja asiakirjalle tallentua tieto siitä, mitä TOS-versiota se noudattaa? Tehtäväluokitus tai TOS eivät ole staattisia ja saattavat muuttua useampaankin otteeseen asiankäsittelyprosessin aikana. Toki TOJ tietää mitä versiota milloinkin on noudatettu, mutta metatiedon tallentaminen asiakirjallisten tietojen yhteyteen helpottaisi mahdollista jälkikäteen tehtävää selvitystyötä. - Käsite tietojärjestelmä; käsitetäänkö tällä ainoastaan asioita/asiakirjoja käsittelevä järjestelmä vai tarkoitetaanko tai voidaanko se ulottaa koskemaan sekä tietoja tuottavia että niitä säilyttävää järjestelmää kokonaisuutena, esim. asiakastietoa käsittelevä järjestelmä (joita voi olla useita) + asiakastietovaranto = tietojärjestelmäkokonaisuus? Esimerkiksi sosiaalihuollon sähköisiä asiakasasiakirjoja ja asian tietoja koskien on suunniteltu, että osa metatiedoista tuotetaan vasta säilyttävässä päässä (asiakastietovaranto). - Tarkennukset tarpeellisia osin tekstiin. Kts. kommentit kappaleiden luvuista. - Koska/Mikäli JHS-suosituksen pohjalta on tavoitteena toteuttaa tietohallintolain mukainen asetus tulisi se mainita selkeästi johdannossa sekä myös avata lyhyesti velvoittavuuden muutoksesta suhteessa "normaaliin" JHS-suositukseen - Suosituksesta olisi käytävä ilmi, miten pakolliset ominaisuudet tulkitaan tai sovelletaan tuotepohjaisissa tietojärjestelmissä, joissa käsitellään vain lyhyen säilytysajan omaavaa asiakirjatietoa (esim. alle 10 vuotta tai 13 vuotta). Voidaanko operatiivisen järjestelmän osalta ymmärtää pakolliset vaatimukset loogisella tasolla ja toteutuksen dokumentoinnissa varmentaa nämä loogiset vaatimukset toteutuvat järjestelmässä. Vastuu on tietenkin viranomaiselle määräaikaisesti säilytettävästä asiakirjatiedosta, mutta hyvä on selkeyttää, mitä pakollisuudet käytännössä voisivat tarkoittaa. Osaan tuotepohjaisista järjestelmistä on kallista toteuttaa lisämäärityksiä, mutta useissa on ns. säilytysrakenteen hallinnan toiminnallisuuksia, joita voidaan soveltaa. - Luonnoksissa olisi hyvä olla rivinumerot, jolloin voisi kommenteissa viitata suoraan oikeaan kohtaan dokumenttia. Dokumenttiin on koottu ja selitetty hyvin suositukset ja vaatimukset dokumentin tavoitteiden kannalta, mutta dokumenttia käytettäessä voisi olla hyödyllistä pystyä helposti erottamaan mitkä vaatimukset koskevat tietojärjestelmiä kehittäviä organisaatioita ja mitkä tietojärjestelmiä käyttäviä organisaatioita. Kaikkien vaatimusten kohdalla tämä ei ole ilmeistä. Jos suositusta on tarkoitus käyttää nykyisten SÄHKE2-sertifiointien jatkumona tietojärjestelmien tuotesertifioinnissa, käyttäjäorganisaatioihin kohdistuvat vaatimukset eivät ole näiden sertifiointien kriteereitä ja ne olisi siten hyvä selkeästi erotella. Esimerkkinä kohta 7.1.2, jossa ensimmäinen vaatimuskappale kohdistunee käyttäjäorganisaatioon, toinen kappale koskee jossain määrin sekä ohjelmistotaloa että käyttäjävirastoa, ja vaatimuskappaleet 3 ja 4 pääasiassa ohjelmistotaloa. 8. Muutosehdotukset kappaleeseen 1. Johdanto Vastaajien määrä: 17 - Suosituksessa esitetyt vaatimukset eivät ole velvoittavia - vaatimukset esitetään minusta aina velvoittavina. Muotoilu on hullunkurinen ja ristiriitainen. - Johdannossa on epätasapainoa termien käytössä, kun puhutaan sekä asiakirjatiedosta että asiakirjallisesta tiedosta. Tietojen siirtäminen: "Suosituksessa on myös määritelty vaatimukset tietojen siirtämiselle muihin tietojärjestelmiin esimerkiksi säilyttämiseen ja hävittämiseen". Entä siirto muista tietojärjestelmistä? - Johdanto alkaa sillä, että kerrotaan kuvattavan pakolliset vaatimukset ja päättyy siihen, että vaatimukset eivät ole julkisen hallinnon organisaatiolle velvoittavia. Tässä on ristiriita. Yritetäänkö suosituksella puuttua myös määräajan säilytettävien asiakirjojen ohjeistukseen? Johdannossa sanotaan..."suosituksessa korostuu koko tiedon elinkaari ja se kattaa eri säilytysajan omaavat tiedot, ei yksinomaan pitkäaikaissäilytyksen piiriin kuuluva tieto." - Viimeinen kappale (s.2): suosituksessa esitetään vaatimuksia, mutta samanaikaisesti todetaan, että JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia. Tämä ongelma tosin koskee kaikkia JHS-suosituksia tällä hetkellä. Asia tietysti ratkeaisi tekemällä JHS-suosituksista asetuksia. - JHS176 SÄHKE 2:N JATKUMONA

17 Palautepyynnön saatekirjeessä todetaan näin: "JHS 176-suosituksen uudistamistyön tarkoituksena on korvata SÄHKE2-määritys, jonka voimassaolo on näillä näkymin päättymässä vuoden 2015 lopussa." Suositustekstin sivulla 1 todetaan: "JHS176-suositus toimii jatkumona arkistolaitoksen SÄHKE2-normille ja määrittää tietohallintolain pohjalta velvoittavat reunaehdot julkishallinnon tietojärjestelmille sähköisen asiakirjatiedon hallinnassa." Jälkimmäinen lause tarkoittaa ilmeisesti, että JHS176:sta suunnitellaan tietohallintolain mukaista asetusta. Jos näin on, tämä olisi hyvä tuoda esiin selkeästi. Toimeenpanon varmistamiseksi ja riittävän yhtenäisen asiakirjahallinnollisen tason saavuttamiseksi suosituksessa esitettyjen käytäntöjen toimeenpanon tueksi tarvitaan tietohallintolain mukainen asetus. Sivu 2, viimeinen kappale: "JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia". Lause viitannee JHS 136:n mukaisten teknisten kuvausmenettelyjen noudattamiseen, ei itse JHS 176:n sisältöön. Tätä kannattaa täsmentää, ettei velvoittavuudesta tule väärinkäsityksiä. - SÄHKE oli pakollinen määräys, tämä vain "suositus" joka ei ole velvoittava julkishallinnolle. Mihin se käytännössä johtaa? - Johdannon viimeinen kappale, soveltamisohje/velvotettavuus vaatimus on vaikeasti tulkittava. Jotta suosituksella saavutetaan sille asetettuja tavoitteita tiedonhallinnan kehittämisessä, tulisi selvittää onko mahdollista edellyttää näiden vaatimusten toteuttamista uusissa tietojärjestelmissä ja suositella soveltamista jos/kun vanhoihin järjestelmiin tehdään merkittävää päivitystyötä. - Suosituksen suhde JHS 191:een on määrittelemättä. - Suositus, jossa on pakollisia vaatimuksia ei ole johdonmukainen ilmaisu. Tämä ei ole normi eikä määräys, vaan suositus. Kun loppukäyttäjän rooli metatietojen antamisessa pyritään karsimaan minimiin, onko järjestelmän asiakirjatiedot riittävän todenmukaisia tutkimuksen ja muun käytön lähdeaineistona. Automaation lisääminen ei tässä tapauksessa lisää asiakirjatietojen käytettävyyttä tutkimuksen ja muun käytön lähdeaineistona vaan huonontaa sitä. - Suosituksen perusta laeissa ja asetuksissa on kerrottava tarkasti pykälätasolle. - Johdannossa on otettava selkeämmin kantaa siihen, mikä on suosituksen sitovuusaste. Onko se vain suositus vai sitooko se jotain toimijoita? - Johdanto luku pitää ehdottomasti kirjoittaa uudelleen. Sen tulee sisältää selkeä tavoite ( punainen lanka ): mitä varten suositus on ja miksi sitä tarvitaan. Suosituksen pitää tukea operatiivista toimintaa nimenomaan tietojärjestelmätoteutusten kannalta ja todeta, että sitä tarvitaan olemassa olevien ja muuttuvien vaatimusten olennaisten eroavuuksien vuoksi. Järjestelmien toiminnallisuuksien pitää turvata asiakirjatiedon käytettävyys, luotettavuus, eheys ja alkuperäisyys, joka tulee olla esitettyjen vaatimusten lähtökohta. Johdannon tulisi keskittyä asiakirjahallinnan kannalta olennaiseen. 5.kpl: pitäisi olla samansuuntainen luvun 5 alun kanssa. 8.kpl: 2.lause Ristiriita: suosituksessa esitetyt vaatimukset eivät ole velvoittavia : jos vaatimus ei velvoita, se on suositus Yksityiskohtaisempia huomioita: - 1.kpl: 2. lause kuuluva tieto -> kuuluvat tiedot - 3. kpl: 1.lause keskeiseksi kokonaisarkkitehtuurin osa-alueeksi nousee -> keskeinen kokonaisarkkitehtuurin osa-alue on tietoarkkitehtuuri. 3. kpl: 3.lause asiakirjalliset tiedot -> asiakirjatiedot 4.kpl: 1.lause asiakirjojen -> asiakirjatiedon 4.kpl: 2.lause merkittävästi erilainen valtionhallinnolle kuin muulle julkishallinnolle -> pitäisi selkiyttää, missä eroaa 6.kpl: 2.lause metatiedoista muodostuu asioille, asiakirjatiedolle ja toimenpiteisiin -> metatiedoista muodostuu asioille, toimenpiteille ja asiakirjatiedoille 7.kpl: 2.lause pyritty -> suosituksessa huomioidaan myös - JHS 176 suhdetta JHS 191:een olisi syytä selventää. JHS 191:ssä on hyvä kuva (kuva 1), joka selventää esim. käsittelyprosessin kuvauksen ja asian välistä eroa. Samanlainen kuva olisi paikallaan myös tämän suosituksen kohdalla, toki operatiivisen tietojärjestelmän näkökulmasta. Koska näissä kahdessa suosituksessa käsitellään samoja metatietoja, tulee tämän suosituksen yhteydessä selkeästi ilmaista, että JHS 191:ssä kuvatut rakenteet ja metatiedot ilmentyvät tietojärjestelmässä syntyneinä asioina, toimenpiteinä ja asiakirjoina. JHS 191:n metatiedot tallennetaan operatiivisessa järjestelmässä syntyneiden tietojen yhteyteen, jossa niitä voidaan muuttaa ja jossa ne täydentyvät järjestelmän ja käyttäjän luomilla muilla metatiedoilla. Johdannon 4. kappaletta voisi vielä avata tarkemmin - mihin lainsäädäntöön perustuu, mihin verrattuna säädöspohja on merkittävästi erilainen, missä säädöksiin perustuvia velvoitteita on tarkennettu (ilmeisesti tässä suosituksessa?). Johdannon 7. kappaleessa todetaan, että "suosituksessa on pyritty huomioimaan myös asianja asiakirjatiedon koko elinkaari". Tähän ei tulisi ainoastaan pyrkiä vaan koko elinkaari tulee huomioida. Johdannossa tulee esittää asiat selkeästi ja jämäkästi, samaa toki toivotaan koko suositukselta.

18 - Suositukses tulisi olla velvoittava kuten SÄHKE2-normi. Pakollisuus vrt. ei velvoittava epätäsmällisesti ilmaistu. Kuka jatkossa ohjaa tai valvoo vaatimusten toteutumista tai myöntää pysyvän säilyttämisen luvan pelkästään sähköisessä muodossa? - Johdantoon lisätään kappale jossa perustellaan selkeästi ja ymmärrettävällä kielellä miksi suosituksen "vaatimuksia" kannattaa noudattaa. Mitä hyötyä tiedonohjauksesta on ja mitä riskejä suosituksen noudattamatta jättämisestä voi seurata. Perustelutekstin tulee olla sellainen, että sen ymmärtää myös ei-asiakirjahallinnan ammattilainen, esimerkiksi tietohallinnosta vastaava tai kunnanjohtaja. - Johdannon viimeisessä kappaleessa todetaan (s.) "JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia". Lause asiayhteydessä kummallinen varsinkin kun edellsisessä virkkeessä todettu "vaatimukset on erotettu muusta tekstistä ja vaatimusten muoto on esitetty alleviivattuna" - Selvitettävä mahdollinen ristiriita: viimeinen kappale, viimeinen virke "JHS-suosituksessa esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia.", kun toisaalta kappaleessa 2 Soveltamisala, kappaleessa 3 todetaan: "Julkishallinnon toimijoiden pitää noudattaa tämän suosituksen pakollisia vaatimuksia." 9. Muutosehdotukset kappaleeseen 2. Soveltamisala Vastaajien määrä: 21 - Selvennettävä julkishallinnon toimijat. Pitää -verbimuoto on liian vahva tässä yhteydessä. "Julkishallinnon tietojärjestelmät, joissa toteutetaan asiankäsittelyä, pitää laatia" = Pitäisi suunnitella - Tekstissä jää hieman epäselväksi Vaatimukset -osion alla olevien 3- ja 4-kappaleiden sisältö. Toisaalta "Pitää noudattaa pakollisia vaatimuksia", mutta "tulee aina määritellä omat tarpeensa... suositeltavaa käyttää pohjana". Ehdotamme tarkennettavaksi 4-kappaletta esim. "Pakollisten vaatimusten lisäksi... tulee aina määritellä...". - Tarkoitettu julkishallinnon toimijoille, jotka noudattava arkistolakia (tai arkistolain muutoksen myötä julkisuuslakia ja niitä muutamaa muuta lakia, jotka tulevat korvaamaan arkistolain ts. asiakirjahallinntoa ohjaavat lait). - "Julkishallinnon toimijoiden pitää noudattaa tämän suosituksen pakollisia vaatimuksia". Tarkoittaako tämä, että JHS 176 on määräys eikä suositus? Koskeeko samainen vaatimus myös organisaatiolla jo olemassa olevia järjestelmiä vai pelkästään uusia hankittavia? - Vaatimukset (s.3): tämän mukaan suositus koskee julkishallinnon tietojärjestelmiä, joissa toteutetaan asiankäsittelyä. Samalla sivulla ensimmäisessä kappaleessa todetaan lisäksi soveltamisalasta; julkishallinnon toimijoille, jotka hankkivat tai kehittävät tietojärjestelmiä, joita käytetään asiakirjatiedon käsittelyyn ja hallintaan. Ilmeisesti suosituksen oletuksena on, että asiakirjallista tietoa käsittelevät järjestelmät sisältävät asiankäsittelyä. Onko kuitenkin olemassa asiakirjallista tietoa sisältäviä järjestelmiä, jotka eivät sisällä asiankäsittelyä? Huomaa tässä myös hienoinen ero JHS-191seen, jossa soveltamisalasta todetaan seuraavasti: Tiedonohjaussuunnitelmia hyödynnetään erityisesti tietojärjestelmissä, joissa käsitellään paljon eri asiakirjatyyppejä, joiden metatiedot poikkeavat toisistaan. Tällaisia ovat tyypillisesti esimerkiksi asiankäsittelyjärjestelmät. JHS-191ssä puhutaan siis soveltamisalan yhteydessä yleisesti asiakirjallisen tiedon käsittelyä sisältävistä operatiivisista järjestelmistä, mainiten esimerkkinä asiankäsittelyjärjestelmät. JHS-176ssa taas puhutaan tietojärjestelmistä, joissa toteutetaan asiankäsittelyä. Olisiko näiden kahden suosituksen välistä käsitteistöä tarvetta yhdenmukaistaa tässä yhteydessä, vai ovatko nämä hienoiset käsite-erot tarkoituksenmukaisia? Voisiko JHS-176ssakin puhua vastaavasti operatiivisista järjestelmistä, joissa asiakirjatieto syntyy, sitä käsitellään ja muokataan - Tekstissä jää paikoin epäselväksi,mitkä osat suosituksesta ovat velvoittavia. Eli mitkä ovat pakollisia vaatimuksia, joita voidaan täydentää organisaation omien tarpeiden mukaisesti. - JHS-SUOSITUSTEN KESKINÄISET SUHTEET Sivu 3, 3. kappale: koska menossa on myös rekistereitä ja tietokantoja koskeva JHS XXX Rekisteritiedon metatiedot -hanke, sen ja JHS 176:n (sekä jo valmistuneen JHS191 Tiedonohjaussuunnitelman rakenne) väliset suhteet kannattaa tuoda esille niin selkeästi kuin mahdollista. Näitä kolmea käytetään rinnakkain asiakirjahallinnan kehittämistä suunnitellessa. Koska on näin monta uutta JHS:ää samasta aihealueesta, kokonaisuus näyttäytynee tietojärjestelmien kehittämistilanteessa selkeänä vain asiakirjahallinnon ammattilaisille. TERMI "TYÖ" VS. TEHTÄVÄ Sivu 3, 4. kappale: "Asiankäsittelyllä tarkoitetaan organisaation toimintaan kuuluvien asioiden, asiakirjojen ja töiden suunnitelmallista ja yhdenmukaista hallintaa. Termin "töiden" sijaan voisi käyttää termiä "tehtävien". Jos käytetään termiä "työ", sille pitäisi tehdä käsitemäärittely luvussa 4. - "Asiankäsittelyllä tarkoitetaan päätöksentekoa ja arkistointia."

19 Sähköisen asiakirjatiedon käsittelyn tulee tapahtua ennalta määritettyjen käsittelysääntöjen ja metatieto-ohjauksen mukaisesti. Epäselväksi jää, koskeeko tämä jhs-suositus perinteisten asiankäsittelyjärjestelmien ohella esim. sosiaalihuollon asiakastietojärjestelmiä tai rakennusvalvonnon ja teknisen toimen käyttämää tietojärjestelmää tai valtakunnallisia tietojärjestelmiä, joissa yhdistyy rekisteritiedon ylläpitäminen ja päätösten kirjaaminen. - Kappale joka alkaa "Asiankäsittelyllä tarkoitetaan organisaation...". On toistoa. On myös sanastossa. "Töiden" ei aukea. Miksi ei puhuta tehtävistä? - Täsmennettävä, miten tiukasti suositus sitoo elinkaaren ylläpitovaiheessa olevia tietojärjetelmiä, joissa ei ole alunperin huomioitu tämän vaatimuksia (ovat esim. Sähke2-tasolla) - Suotavaa olisi tarkemmin avata itse tekstissä ketä suositus koskee. Nyt viitataan toiseen lakiin (tietohallintolaki), missä sanotaan, että kyseinen laki koskee valtion virastoja ja laitoksia kun ne hoitavat julkista tehtävää ja käyttävät julkista valtaa. Koskeeko JHS 176 kaikilta osin esimerkiksi valtionyhtiöitä? Arkistolaitos on 2009 julkaissut oppaan valtionhallinnon organisaatiomuutostilanteisiin ja opas rajaa mm valtionyhtiöt siirtovelvollisuuden ulkopuolelle - Suosituksessa tulisi olla tarkemmin määriteltynä, sovelletaanko suositusta jo käytössä oleviin tietojärjestelmiin. Tarkennus kohtaan: Asiankäsittelyllä tarkoitetaan organisaation toimintaan kuuluvien -vireillesaatettujen- asioiden, asiakirjojen ja töiden suunnitelmallista ja yhdenmukaista hallintaa, valmistelua, päätöksentekoa ja arkistointia ennalta määrättyjen käsittelysääntöjen mukaisesti. Tulisi määritellä tarkemmin koskeeko rakenteellista tietoa. - Onko käsite asiankäsittely määritelty liian laajasti ottaen huomioon suosituksen sisällön. Olisiko parempi vaihtoehto kertoa se, että kyse on asiankäsittelyjärjestelmille ja vastaaville suunnattu suositus, ei kaikelle asiankäsittelylle. Eikö esimerkiksi julkishallinnon keskeisten rekisterien ja tietokantojen ylläpito ole asiankäsittelyä. Voiko tätä suositusta sellaisenaan soveltaa tietokantamuotoisin rekistereihin, joihin otetaan talteen tietoja, mutta tiedot eivät kerry samalla tavalla kuin hallintoasian käsittelyvaiheet etenevät. Kannattaisi rehdisti kertoa se, että näille rekistereille ja tietokannoille luodaan myöhemmin omat suositukset, jotka paremmin todentavat ja kuvaavat niitä. Kaikkea ei tarvitse ratkaista yhdellä suosituksella. - Jos suosituksessa ilmaistu velvoite tai vaatimus perustuu lakiin tai asetukseen tai muuhun viranomaismääräykseen on viitattava tarkasti kyseiseen normiin ja sen yksittäiseen kohtaan. - Suosituksessa kuvattuja vaatimuksia pitää noudattaa asiakirjatiedon muodosta riippumatta. Asiakirjatieto voi olla esimerkiksi tekstiasiakirjoja tai koostettua tietoa, kuten kuvia, karttoja tai dataa sekä niiden kuvailevaa ja toiminnallista metatietoa. Täydennysehdotus: rakenteisen tiedon käsittely mainittava tässä yhteydessä. - Julkishallinnon toimijoiden suositellaan noudattavan tämän suosituksen vaatimuksia. - Suositusta tulisi soveltaa vain yleishallinnollisiin järjestelmiin, ei organisaatioiden substanssijärjestelmiin. Substanssiasioiden asiankäsittelytarpeet ovat usein niin monitahoiset, ettei niitä pysty toteuttamaan valmisohjelmilla, joissa JHS-suosituksen asettamat vaatimukset olisi valmiiksi huomioitu. Tässä soveltamisala-luvussa olisi luontevinta tehdä tämä rajaus. Suosituksessa: Asiakirjatieto voi olla esimerkiksi tekstiasiakirjoja tai koostettua tietoa, kuten kuvia, karttoja tai dataa sekä niiden kuvailevaa ja toiminnallista metatietoa. Miten suositusta on tarkoitus hyödyntää, mikäli on kyse rakenteellisesta asiakirjasta? Määritelläänkö metatietoarvot todella asiakirjan jokaiselle erillisellä kentälle vai vasta kuvamuotoon muutetulle asiakirjalle? (vrt. Internet-sivuilla täytettävä rakenteinen lomake, josta poimitaan tarvittavat tiedot rekisteriin, kuten henkilötunnus ja nimitiedot). - Vaatimukset: "Asiankäsittelyllä tarkoitetaan... ennalta määrättyjen käsittelysääntöjen mukaisesti." Tässä olisi hyvä viitata millaisiin ennalta määrättyihin käsittelyihin esimerkiksi viitataan (konkreettinen esimerkki havainnollistaa paremmin). - 4.kpl: 1.lause töiden -> toimintaan kuuluvien asioiden ja niiden käsittelyn sekä asiakirjojen 6. kpl: ristiriita: suosituksessa esitettyjä vaatimuksia saa ja on suositeltavaa käyttää pohjana, mutta--- organisaation on sovellettava niitä oman toiminnan tukemiseksi. Jos saa soveltaa, saa näin ollen poiketa vaatimuksista + organisaatiolähtöinen lähestymistapa - Neljännen kappaleen määritelmää asiankäsittelylle voisi muokata, erityisesti työ-sana ei tässä yhteydessä oikein toimi. - Vaatimukset -kohdan toinen "kokonaisuus" "Asiankäsittelyllä tarkoitetaan... asioiden, asiakirjojen ja töiden ==> po. tehtävien Vaatimukset -kohdan kolmas "kokonaisuus".. Jukishallinnon toimijoiden potää noudattaa tämän suosituksen pakollisia vaatimuksia ==> epäloogisuus s. 2 viimeiseen lukuun, jossa todetaan että " esitetyt vaatimukset eivät ole julkisen hallinnon organisaatioille velvoittavia 10. Muutosehdotukset kappaleeseen 3. Viittaukset Vastaajien määrä: 7

20 - Rajapintojen ja yhteentoimivuuden osalta voisi mahdollisesti soveltuvin osin viitata Julkishallinnon perustietovarantojen rajapinnat (PERA) -työryhmän tuottamiin rajapintavaatimuksiin. - Suosituksissa olisi hyvä nostaa esiin jo tunnistetut tietojärjestelmien rajapintavaatimukset Julkishallinnossa (esim. PERA- työryhmän tuottamat vaatimukset). - JHS 191:n nimi on väärin. On JHS 191 Tiedonohjaussuunnitelman rakenne. - Suosituksessa on lueteltu siihen liittyvät muut JHS-suositukset sekä standardit. Mainitsematta on luettelossa kuitenkin jätetty mm. seuraavat toistaiseksi voimassaolevat suositukset JHS 143 Asiakirjojen kuvailun ja hallinnan metatiedot ja JHS 156 Asiakirjojen ja tietojen rekisteröinti sähköisen asioinnin ja asiankäsittelyn tiedonhallinnassa sekä standardi SFS 5972 Viitemalli pitkäaikaissäilytysarkistolle (OAIS-standardin suomalainen versio). - VAHTI-ohjeistus puuttuu. - Kappale kannattaa siirtää suosituksen loppuun tai omaksi liitteeksi; muutos tekisi suosituksesta luettavamman ja sisällöllisesti selkeämmän. - JHS-ohjeiden mukaisesti tulisi viitata vain niihin lakeihin etc. joihin viitataan itse sisällössä. Tällä hetkellä on muitakin viittauksia. Yksityiskohtaisempia huomioita: Ensimmäinen otsikko: Suositustekstissä huomioidut lait, normit ja säädökset -> Suositustekstissä huomioidut normit - Kv. standardeihin tulisi lisätä Moreq2010, koska Moreqista ilmeisesti tulee käsite Kooste (Moreq-käännöksessä tosin nimeltään Kertymä (eng. Aggregation). -> ei tarvita, kun luku 6.3. Kooste poistetaan. 11. Muutosehdotukset kappaleeseen 4. Termit ja lyhenteet Vastaajien määrä: 23 - Asian kohdalla on lause, joka ei oikein tarkoita mitään: "asia on käsittelyprosessin kuvauksen yksittäinen ilmentymä". Parempi olisi esim. "asia on yhteinen ja yhdistävä nimi, joka annetaan rekisteröinnin yhteydessä hallinnossa aloitettavalle käsittelyvaiheiden sarjalle". Asiakirjan määritelmä kaipaa myös tarkennusta. Edellä olevaan asiakirjahallinnan määritelmään viitaten "asiakirjatieto; asiakirjallinen tieto; asiakirja" -kohta voisi kuulua seuraavasti: "rajattu autenttinen, luotettava, todistusvoimainen ja käyttökelpoinen tietokokonaisuus". - Julkishallinnon suosituksessa tulisi käyttää yhtenäisiä standardeista tulevia termejä ja lyhenteitä. Jos käytetään omaa terminologiaa sen tulee olla tarkoin harkittua ja selkokielistä. Julkishallinto? Mihin kuuluvat virallisia tehtäviä hoitavat organisaatiot, järjestöt, korkeakoulut jne. Termit ja terminologia tulee ottaa erityiseen tarkasteluun. - Määritelmä puuttuu kohdasta "Käyttöoikeudet, käyttövaltuudet" Ehdotus: Joidenkin termien välistä yhteyttä voisi selkeyttää kuvalla. Esim. asiakirja, toimenpide, asia, tehtäväluokka, palveluluokka. - Termit päällekkäisiä ja keskenään ristiriitaisia (vrt. asiakirjahallinta, asiakirjatieto, asiakirjallinen tieto, asia, asiankäsittely). - Onko terminologiassa eroa termien asiakirja ja dokumentti välillä? Dokumentilla on usein tarkoitettu luonnostilaista asiakirjaa. - (s.5): Termin käsittelyvaihe avauksessa ei hallintoasioiden käsittelyvaiheena mainita seurantaa/valvontaa. - Määritelmä puuttuu kohdasta "käyttöoikeudet, käyttövaltuudet". Käsitteiden välistä yhteyttäs voisi selkeyttää esim. kuvilla tai visuaalisesti. - TIEDONOHJAUSSUUNNITELMA-KÄSITE Sivu 7, käsite "tiedonohjaussuunnitelma": arkistolain uudistamisessa on nostettu esiin käsite "tiedonhallintasuunnitelma", joka olisi mainittava myös tässä. - Asiakirjatieto/asiakirjallinen tieto/asiakirja. Nyt on hajanaisuutta asiakirjatieto vs. asia/asiakirja tai asiakirjahallinnan kanssa. Joistakin vaatimuksista ei käy ilmi, onko järkevää käyttää asiakirjatieto (jos koskee asiaa/asiakirjaa/toimenpidettä metatietoineen) vai muuta termiä. Aluksi siirrytty asiakirjasta asiakirjalliseen tietoon, koska haluttu nähtävästi korostaa muoto- yms. riippumattomuutta. Sitten on suositeltu käytettävän asiakirjatieto-termiä. Suosituksessa asiakirjatieto-termiä käytetään kuvaamaan asian koko tietosisältöä mukaan lukien toimenpiteet, asiakirjat ja näiden kaikkien tasojen metatiedot. Näinkö? Voiko sitä selittää auki. Joissakin kohdin (suosituksen loppupuoli) asiakirjatieto taas näkyy olevan synonyymi asiakirjalle.