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.