Infovara kasutuselevõtu ja arendamise korra kinnitamine

KÄSKKIRI veebruar 2026 nr 9 Infovara kasutuselevõtu ja arendamise korra kinnitamine Vabariigi Valitsuse seaduse § 74 lõike 1 ning sotsiaalministri 11. oktoobri 2005. a määruse nr 105 „Ravimiameti põhimäärus“ § 7 punkti 13 alusel 1. Kinnitan Ravimiameti infovara kasutuselevõtu ja arendamise korra. 2. Arendus- ja haldusosakonna dokumendihalduse spetsialistil teha käskkiri Ravimiameti ametnikele ja töötajatele teatavaks dokumendihaldussüsteemi kaudu. Vaide käskkirjale saab esitada peadirektorile 30 päeva jooksul arvates käskkirja teatavaks tegemisest vastavalt haldusmenetluse seaduse § 71 lõikele 1 ja §-le 75. Kui ametnik või töötaja soovib käskkirja vaidlustada halduskohtus, võib ta vastavalt halduskohtumenetluse seadustiku § 7 lõikele 1 ja § 46 lõikele 1 esitada kaebuse käskkirja peale Tartu Halduskohtule või oma teenistuskoha järgi Tallinna Halduskohtule 30 päeva jooksul arvates käskkirja teatavaks tegemisest. (allkirjastatud digitaalselt) Katrin Kiisk Peadirektor Märt Roogna [email protected]  KINNITATUD Ravimiameti peadirektori veebruari 2026 käskkirjaga nr 9 INFOVARA KASUTUSELEVÕTU JA ARENDAMISE KORD SISUKORD 1. Sissejuhatus .......................................................................................................................... 1 1.1 Dokumendi eesmärk ja sihtrühm ......................................................................................... 1 1.2 Arendusprotsessi üldpõhimõtted.......................................................................................... 2 1.3 Rollide jaotus arendusprotsessis .......................................................................................... 2 1.4 Regulatsioonid ja standardid ................................................................................................ 2 1.5 Mõisted ja lühendid.............................................................................................................. 2 2. Arendusprotsessi algatamine .............................................................................................. 3 2.1 Arendusvajaduste kaardistamine ......................................................................................... 3 2.2 Arendusvajaduste algatamine ja prioriseerimine ................................................................. 3 2.3 Projekti edukuse mõõdikud.................................................................................................. 4 2.4 Rollide määramine arenduse algatamise faasis .................................................................... 4 2.5 Riskide hindamine arenduse algfaasis ................................................................................. 4 3. Nõuete kogumine ja analüüs ............................................................................................... 5 3.1 Funktsionaalsed ja mittefunktsionaalsed nõuded................................................................. 5 3.2 Muudatuste juhtimine nõuete täpsustamisel ........................................................................ 5 4. Turvalisus ja andmekaitse .................................................................................................. 5 5. Arendus ja testimine ............................................................................................................ 5 5.1 Arenduse etapid ja iteratsioonid........................................................................................... 5 5.2 Koodihalduse ja versioonikontrolli parimad tavad .............................................................. 5 5.3 Testimise liigid..................................................................................................................... 5 5.4 Tehniline dokumentatsioon.................................................................................................. 5 6. Kasutuselevõtt ja juurutamine ........................................................................................... 6 6.1 Koolitus ja kasutajatugi........................................................................................................ 6 6.2 Kasutuselevõtu protseduur ................................................................................................... 6 6.3 Hooldusnõuded .................................................................................................................... 6 7. Tarkvara pidev täiustamine ................................................................................................ 6 7.1 Jätkuarendused ..................................................................................................................... 6 7.2 Õppetunnid ........................................................................................................................... 6 1. Sissejuhatus 1.1 Dokumendi eesmärk ja sihtrühm Käesolev dokument kirjeldab IT arendusprotsessi Ravimiametis, tuues välja põhietapid, rollid ja parimad praktikad. Juhendi eesmärk on tagada protsesside selgus ja kvaliteet, aidates optimeerida tarkvaraarendust ning vähendada riske. Sihtrühmad:  Projektiomanikud ja tellijad – mõistmaks arendusprotsessi ja selle etappe.  Arendusmeeskond – jälgimaks parimaid tavasid ja standardeid.  Kasutajad ja sidusrühmad – arusaamiseks, kuidas nende vajadusi arvestatakse.  Kvaliteedijuhtimine ja audiitorid – tagamaks vastavust kvaliteedisüsteemile. 1.2 Arendusprotsessi üldpõhimõtted Arendusprotsess järgib järgmisi põhimõtteid:  Läbipaistvus – kõik etapid on dokumenteeritud ja jälgitavad.  Kasutajakesksus – lahendused vastavad tegelikele vajadustele. Arendame teenuseid, mida on mugav kasutada.  Iteratiivsus – arendus toimub etapiviisiliselt. Eelistame agiilset lähenemist (nt Scrum või Kanban), et maandada riske ja pakkuda väärtust kiiremini.  Koostöö ja kommunikatsioon – kõik sidusrühmad on kaasatud ja informeeritud.  Turvalisus ja vastavus – arvestatakse infoturbe, GDPR ja teiste regulatiivsete nõuetega.  Jätkusuutlikkus – tagatakse hooldatavus ja tulevased laiendusvõimalused. 1.3 Rollide jaotus arendusprotsessis Ravimiameti peamised rollid on:  Arendus- ja haldusosakonna juhataja  Tooteomanik  Arenduste projektijuht  Andmehaldusspetsialist  Kvaliteedijuht  Peakasutaja TEHIK peamised rollid:  Teenuste juht  IT arhitekt  Projektijuht  Testija  Rakenduste administraator  Süsteemiadministraator Arenduspartneri rollid:  Arendustiimi juht  Arendustiimi arhitekt või juhtivarendaja  Ärianalüütik  Arendajad  Testijad  DevOps insenerid 1.4 Regulatsioonid ja standardid Arendusprotsess peab vastama järgmistele standarditele ja regulatsioonidele:  Eesti infoturbestandard (E-ITS)  TEHIK arendusjuhendid  Web Content Accessibility Guidelines (WCAG). Kõik avalikud veebiteenused ja infosüsteemid peavad vastama Euroopa Liidu ja siseriiklikele ligipääsetavuse nõuetele (vähemalt tase AA).  Sotsiaalministeeriumi valitsemisala digiarenduste koordineerimise protsess  Isikuandmete kaitse üldmäärus (GDPR)  X-tee juhised 1.5 Mõisted ja lühendid Käesolevad korras kasutatakse järgmisi mõisteid:  Nõuete analüüs – protsess, mille käigus määratakse kindlaks tarkvarale esitatavad ootused.  Arhitektuur – tarkvara ja IT-süsteemide ülesehitus, sealhulgas andmevood ja integratsioonid.  Agiilne arendus – tarkvaraarenduse metoodika, mis rõhutab kiiret ja paindlikku lähenemist tarkvara loomisel.  Scrum – agiilsel mõtteviisil põhinev tootearenduse raamistik.  Kanban – agiilne projektihaldusraamistik, mida kasutatakse töövoo visualiseerimiseks.  Backlog – arendusvajaduste ja tööülesannete prioritiseeritud nimekiri.  Iteratsioon – arendusetapp, mille jooksul viiakse ellu kindel hulk funktsionaalsusi.  Testimine – protsess, mille käigus kontrollitakse, kas tarkvara vastab nõuetele ja toimib korrektselt vastavalt kasutusjuhtude kirjeldustele.  Juurutamine – tarkvara kasutuselevõtt ja üleminek tootmiskeskkonda.  Lühendid  RA – Ravimiamet  TEHIK – Tervise ja Heaolu Infosüsteemide Keskus  AHO – Ravimiameti arendus- ja haldusosakond  Wiki – Atlassian Confluence keskkond dokumenteerimiseks, info salvestamiseks ning struktueerimiseks  Jira - projektijuhtimise ja probleemide jälgimise tarkvara, mis võimaldab luua, tähtsuse järjekorda seada ja hallata ülesandeid (vead, kasutajalood jms)  Delta – dokumendihalduse süsteem  DevOps – development and operations (arendus ja käitlemine)  SLA – Service Level Agreement (teenustaseme kokkulepe)  IKT – info- ja kommunikatsioonitehnoloogia  E-ITS - Eesti infoturbestandard  GDPR – Isikuandmete kaitse üldmäärus  WCAG – Web Content Accessibility Guidelines  API – application programming interface (rakendusliides) 2. Arendusprotsessi algatamine 2.1 Arendusvajaduste kaardistamine Arendusvajaduste kaardistamine on pidev tegevus. Esmane sisend tuleb osakondadelt, kes vastutavad konkreetse valdkonna tegevuste täitmise eest. Iga arendus algab ärivajaduse vormistamisest. Selleks koostab äriüksus esmase visiooni, kus kirjeldatakse probleemi, mida soovitakse lahendada ning oodatavat kasu (nt käsitöö mahu vähenemine, kiirem menetlusaeg vms). Terviklikke arendusprojekte ja ka üksikute arendusideede teostust algatatakse vastusena äripoole või õigusaktide muutunud nõudele. Regulaarse arendusvajaduste kaardistamise käigus koostatakse ja uuendatakse asutuse IT arenduste teekaarti ja tööplaane. Uute süsteemide kasutuselevõtmise või olemasolevate rakenduste suuremahuliste arenduste vajadused koondab arendus- ja haldusosakond. 2.2 Arendusvajaduste algatamine ja prioriseerimine 2.2.1 Arendusvajaduste esitamist saab soovi korral teha iga teenistuja. Vajaduse või idee võtab vastu arendus- ja haldusosakond, üldjuhul vastava valdkonna infosüsteemi tooteomanik, kes esmase sisendinfo väljaselgitamise järel registreerib arenduspileti toote/rakenduse tööde nimekirjas. AHO viib läbi arutelu arendusvajaduse sisu ning oodatava mõju hindamiseks, sõltuvalt arendusidee spetsiifikast jätkatakse vajadusel eelanalüüsi ja/või kalkulatsioonidega. Eelanalüüsi eesmärk on välja selgitada tehniline teostatavus ja potentsiaalne lahendusvariantide valik. Prioriseerimisel arvestatakse arendusvajaduse esitajalt saadud sisendit ning hinnatakse vähemalt järgmisi põhikriteeriume: kriitilisus, mõju ning seos strateegiaga. Kriitilisuse osas hinnatakse, kas arendus on tingitud seadusemuudatusest või turvaintsidendist. Mõju hindamisel prognoositakse, kui suurt hulka kasutajaid või milliseid tööprotsesse muudatus mõjutab. Strateegilises vaates hinnatakse kas see toetab asutuse ja riigi IT arenduste teekaarti. 2.2.2 Kõrge prioriteedi ja/või suurema ulatusega initsiatiivide käivitamise puhul kaasatakse otsustusprotsessi asutuse juhtkond. Kui arendusvajadus on saanud asutuse juhtkonnas heakskiidu, kaitstakse seda Sotsiaalministeeriumi valitsemisala juhtkomisjonis, kes otsustab arendusvajaduse valitsemisala IKT arendusportfelli lisamise. 2.2.3 Kasutusel olevasse süsteemi uue omaduse või muudatuse saamiseks esitab äriteenust kasutav osakond (selle esindaja) arendusvajaduse saates selle kohta vastava e-kirja AHO vastavale tooteomanikule. Tooteomanik loob idee kirjeldamiseks Jira keskkonnas pileti, kuhu märgib idee esitajalt saadud nõuded, oodatava tulemuse kirjelduse jm parameetrid. Tekkinud arenduspilet salvestatakse toote backlog’is. Arendusvajaduse teostatavust hindab 1) tooteomanik iseseisvalt, või 2) keerukamate kasutusjuhtude korral viies idee kirjelduse arenduspartneri tiimini, et tehniline teostus kindlaks teha. Võimalusel annab arendustiim uuele ideele (kasutusloole) ka töömahu hinnangu. Seejärel saab tooteomanik anda idee esitajale tagasiside arendusvajaduse realiseerimise kohta. 2.3 Projekti edukuse mõõdikud Projekti edukuse mõõdikud tulenevad eelkõige projekti eesmärkidest. Projekti ulatus ja eesmärgid defineeritakse vastavas hankelepingus. Edukuse mõõtmiseks on võimalikud raamistikud OKR (Objectives and Key Results), SMART (Specific, Measurable, Achievable, Relevant, Time-bound), KPI (Key Performance Indicators), jt. Mõõdikud võivad sisaldada järgmisi komponente:  Projekti tähtaegade täitmine  Eelarves püsimine  Kasutajate rahulolu  Süsteemi jõudlus ja töökindlus  Nõuetele vastavus 2.4 Rollide määramine arenduse algatamise faasis Igale projektile määratakse vastutajad: projektijuht, kes vastutab protsessi läbiviimise eest, tooteomanik, kes vastutab sisuotsuste ja prioriteetide eest ning IT arhitekt, kes jälgib ja kavandab, et algatatav lahendus oleks arhitektuurselt kooskõlas ülejäänud rakenduste ning infrastruktuuriga. Arenduse algatamise faasis on osalised veel:  Initsiatiiviga seotud RA osakonna spetsialistid  RA arendus- ja haldusosakonna juhataja  RA arendustiimi liikmed  TEHIK Ravimiameti teenuste juht  Vajadusel TEHIK analüütik 2.5 Riskide hindamine arenduse algfaasis Peamised riskid arenduse algfaasis on järgmised: 1. Seosed teiste infosüsteemidega, näiteks liidesed. 2. Projekti liikmete töökoormus ja hõivatus. 3. Projekti jaoks oluliste muude liikmete ajaressurss, näiteks äriüksuste sisend. 4. Arenduspartneri ja TEHIK inimressursside olemasolu. 5. Regulatiivsed ja juriidilised nõuded. 6. Eelarvepiirangud ja finantsriskid. 3. Nõuete kogumine ja analüüs 3.1 Funktsionaalsed ja mittefunktsionaalsed nõuded RA arendusprotsess on otseselt seotud ning lähtub TEHIK arendusprotsessist, mille kirjeldus ning selle juurde kuuluvad kontrollnimekirjad on toodud wiki-s. TEHIK arendusjuhendid s.h. mittefunktsionaalsed nõuded on leitavad TEHIK välisveebist. Sõltuvalt kasutusjuhust peab analüüsi koostades olema vajadusel kaasatud ka RA õigusosakonna esindaja, finantsjuht või mõni muu vajalik roll. 3.2 Muudatuste juhtimine nõuete täpsustamisel Muudatuste juhtimisel lähtutakse TEHIK muudatuste juhtimise korrast ja protsessist, mis kehtestab reeglid kuidas muudatusi korraldama peab. See arvestab ka SLA-dega, mis vastavatele süsteemidele sõlmitud on. 4. Turvalisus ja andmekaitse Rakenduste ja andmekogude turvaklassi määramisel võetakse arvesse andmete konfidentsiaalsusklassi ja turvalisuse puudumisest tulenevat võimalikku kahju. Andmekogu andmete turvaklass on määratud vastavalt infoturbe eesmärkide käideldavuse, tervikluse ja konfidentsiaalsuse parameetrite kaudu. Kasutatavate rakenduste turvaklassi määramise protokollid on talletatud asutuse võrgukettal vastavanimelises kataloogis. 5. Arendus ja testimine 5.1 Arenduse etapid ja iteratsioonid Arendusprojekti etapid ja regulaarsed tegevused on kirjeldatud TEHIK arendusprotsessi kirjelduses. 5.2 Koodihalduse ja versioonikontrolli parimad tavad Koodi hoitakse keskses repositooriumis (nt GitLab/Bitbucket). Kasutusel on harundamise (branching) strateegia (nt GitFlow). Koodi kontroll toimub teise arendaja poolt ülevaatuse teel (Code Review). 5.3 Testimise liigid Testimine on arendusprojekti puhul üks olulisemaid kvaliteedi jälgimise ja tagamise tegevusi. Testimine sisaldab hulga alamtegevusi, millega kontrollitakse kõikide tarkvarale ja dokumentatsioonile esitatud nõuete vastavust. Testimine koosneb peamiselt kahest suuremast tasemest – staatiline ja dünaamiline. Staatilise testimise puhul vaadatakse läbi kogu arendusega seotud dokumentatsioon ja arendaja poolt üle antud kood. Dünaamiline testimine jaguneb omakorda kaheks: funktsionaalseks ja mitte-funktsionaalseks testimiseks. Funktsionaalse testimise puhul valideeritakse rakenduses mingi kindla tegevuse või funktsiooni toimimist. Mitte-funktsionaalne testimine on seotud süsteemi omaduste nõuetele vastavuse kontrolliga. 5.4 Tehniline dokumentatsioon Arendusega paralleelselt peab valmima ajakohane dokumentatsioon, kuhu kuuluvad süsteemi tehniline kirjeldus (arhitektuurne vaade, andmemudel, liideste kirjeldus) ning paigaldus- ja konfigureerimisjuhendid. Kui kasutusel on ka API-d siis lisanduvad dokumentatsioonile ka kirjeldused liideste kohta (nt Swagger). 6. Kasutuselevõtt ja juurutamine 6.1 Koolitus ja kasutajatugi Kasutusjuhendite loomine lõppkasutajale on arendustiimi ülesanne ning seda koordineerib tooteomanik. Võimalik on kasutusjuhendid luua ka arendaja poolt kuid see töötellimus peab olema eelnevalt fikseeritud. Uue infosüsteemi või olemasolevale rakendusele lisandunud funktsionaalsuse korral viib koolituse läbi TEHIK või vastav RA tooteomanik. Koolituse läbiviimine äriomanikule ehk Ravimiametis vastava rakenduse eest vastutavale isikule ja/või osakonnale tuleb tellida arenduspartnerilt. 6.2 Kasutuselevõtu protseduur Detailne kasutuselevõtu plaan koostatakse TEHIKu poolt koostöös arenduspartneri ning Ravimiameti arendustiimiga. Sisaldab see ka tagasipööramise plaani juhuks kui midagi läheb kriitiliselt valesti. Toodangukeskkonnas rakenduse või selle uuenduse kasutuselevõtu järgselt viiakse läbi ka täiendav testimine, et veenduda veakindluses. Ühe osana kasutuselevõtu plaanist määratakse ka monitooringu ehk jälgimise periood. 6.3 Hooldusnõuded SLA ehk teenustaseme kokkulepe on RA-TEHIK vaheline kokkulepe IT süsteemide halduse osas, millest mõlemad osapooled lähtuvad hooldustööde teostamisel, probleemide lahendamisel ning arendustöödes. SLA sisu koostamine ning sõlmimine TEHIK-uga on vastava tooteomaniku kohustus. Teenustaseme kokkuleppe põhiprintsiibid on esitatud TEHIK vastaval wiki lehel ning allkirjastatud kokkulepe leitav dokumendihaldussüsteemis. 7. Tarkvara pidev täiustamine 7.1 Jätkuarendused Tarkvara vigade ja arendusettepanekute haldamine toimub läbi piletisüsteemi (nt Jira), milleks peetakse tehtavate tööde nimekirja (backlog). Tooteomanikud täiendavad vajadusel nimekirja uute piletitega ning teevad regulaarset nimekirja ülevaatust seal olevaid pileteid prioriseerides. Tooteomanik suunab nimekirjast ülesandeid arendajale. 7.2 Õppetunnid Pärast iga suuremat etappi või projekti lõppu viiakse TEHIKu juhtimisel läbi retrospektiiv, mille eesmärk on teha kokkuvõte, mis läks hästi, mis halvasti ja mida järgmisel korral teisiti teha. Sõltuvalt projekti mastaabist ja kestvusest, võib sarnaseid retrospektiive läbi viia ka arendusele kestel ning seda üldjuhul iga arendustsükli ehk sprindi lõppedes. Kokkuvõte on ajaliselt lühem ning väiksema mahuga, mille fookus on sprindi jooksul saadud kogemustel ning nende baasil tehtud järeldustel.