HANKELEPING nr 3-9/5026-1
Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Pärnu
mnt 132, 11317 Tallinn, keda esindab põhimääruse alusel direktor Margus Arm ja
Nortal AS, (edaspidi täitja), registrikood 10391131, aadress Lõõtsa tn 6, 11415 Tallinn, keda esindab
volikirja alusel Olga Golubeva,
edaspidi koos või eraldi nimetatud ka pool või pooled, sõlmisid käesoleva hankelepingu (edaspidi
leping) alljärgnevas:
1. Lepingu eesmärk ja ese
1.1. Lepingu eesmärk on tehnilises kirjelduses sätestatud tööde teostamine (edaspidi tööd).
Tööde loetelu, üleantavad tulemid ja lepingu täitmise tingimused on sätestatud tehnilises
kirjelduses.
1.2. Valminud tööde tellijale üleandmise tähtaeg on 04.09.2026. Leping kehtib kuni poolte
poolt kohustuste täitmiseni.
2. Lepingu hind
2.1. Tellija tasub lepingu alusel tellitud tööde eest kokku 29 999,00 (kakskümmend üheksa
tuhat üheksasada üheksakümmend üheksa) eurot käibemaksuta.
2.2. Täitjal on õigus esitada e-arve pärast tööde aktiga vastu võtmist. Arvel tuleb märkida
riigihanke nimetus, lepingu number ja kontaktisiku andmed.
2.3. Arve tasumiseks annab täitja minimaalselt tähtaja 21 kalendripäeva alates arve
laekumisest.
3. Üldtingimused
3.1. Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja riigihanke
alusdokumendid ning täitja riigihankes esitatud pakkumus ja pooltevahelised kirjalikud
teated, mida lepingu lisadena eraldi ei allkirjastata.
3.2. Lepingu täitmisel lähtutakse lepingu ja selle juurde kuuluvate lahutamatute osade
tingimustest.
3.3. Pooled teevad lepingu täitmiseks ja lepingu eesmärkide saavutamiseks koostööd. Pooled
kohustuvad tegema kõik vajalikud pingutused, et täita leping õigeaegselt ja vastavalt
kokkulepetele.
3.4. Pooled võivad kokkuleppel kaasata tööde kvaliteedi või tööde vastuvõtmise hindamiseks
mõlema poole poolt aktsepteeritud sõltumatu eksperdi või audiitori. Kui tellija hinnang
tööde kvaliteedile või tööde vastuvõtmisele osutub ekspertiisi tulemusel põhjendamatuks,
hüvitab tellija ekspertiisikulud. Kui ekspertiis kinnitab tellija hinnangut kvaliteedile või
tööde vastuvõtmisele, jäävad ekspertiisikulud täitja kanda.
3.5. Kui lepingu täitmisel tekivad täitja ja tellija vahel erimeelsused, lähtutakse hankelepingu
eesmärkidest esmalt tellija seisukohalt, võttes arvesse hanke alusdokumentides
määratletud eesmärki ja sisu.
1
3.6. Poolel on õigus teha teisele poolele ettepanekuid lepingu täitmise kvaliteedi tõstmiseks.
Kui pool on esitanud teisele poolele lepingu täitmisega seotud küsimuses päringu, on pool
kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma) võimalikult kiiresti,
kuid hiljemalt 3 tööpäeva jooksul, v.a juhul kui pöördumine nõuab täiendavat analüüsi või
info süstematiseerimist.
3.7. Pooltel on kohustus osa võtta töökoosolekutest tööde käigus tekkinud probleemide
lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt. Töökoosolekutel
osalemist tellija eraldi ei tasusta.
3.8. Lepingu täitmise keel on eesti keel, muuhulgas on see ka lepingu sõlmimise, tellimuste,
töökoosolekute jm suhtluse keel. Tehnilises kirjelduses sätestatud juhtudel ja tellijaga
kokkuleppel on tööde tulemid inglise keelsed.
3.9. Nõuded dokumentatsioonile ja kasutusjuhenditele tulenevad tellija poolt kodulehel
avaldatud vastavatest nõuetest.1 Nõuetest lähtutakse tehnilises kirjelduses kajastatud ja
töö iseloomust tulenevate erisustega.
4. Poolte õigused ja kohustused
4.1. Täitja kohustub:
4.1.1. teostama tööd lepingus kokkulepitud tingimustel ja ulatuses, sh tagama tööde
õigeaegse alustamise, teostamise, valmimise ja tellijale üleandmise;
4.1.2. tagama lepingu täitmiseks vajalike ressursside olemasolu, sh tagama lepingu täitmise
kõrge professionaalse taseme ning vajaliku tehnoloogia ja metoodikate väga hea
tundmise ning tehtud tööde dokumenteerimise vastavalt tellija suunistele, samuti
omama lepingu täitmiseks sobivaid keskkondi, koos kõige sinna juurde kuuluvaga, sh
kasutatava tarkvara litsentsid, või kasutama tellija olemasolevaid jagatud keskkondi;
4.1.3. tegema koostööd kolmandate osapooltega pidades silmas tellija vajadusi (nt
äritellijaga, teiste tellija arenduspartneritega jne);
4.1.4. teavitama viivitamatult tellijat lepingu täitmist takistavatest asjaoludest, mis segavad
lepingus toodud tööde teostamist ja tähtaegadest kinnipidamist või püstitatud eesmärgi
saavutamist;
4.1.5. andma tellija nõudel selgitusi teostatud tööde kohta;
4.1.6. juhinduma tellija suunistest lepingu eesmärkide saavutamisel, pöördudes selleks
vajadusel tellija poole;
4.1.7. töö käigus tuvastatud vastuolu korral teavitab täitja vastuolu esinemisest tellijale
viivitamatult;
4.1.8. arvestama, et lepingu täitmiseks võib olla vajadus muuta ja täiendada olemasolevat
koodi ning tagama protsesside ja funktsionaalsuse tervikluse pärast koodi muutmist või
täiendamist;
4.1.9. kasutama lepingu täitmisel tellija tööajahalduse ja projektijuhtimiskeskkondi, mis on
täitjale kättesaadavaks tehtud;
4.1.10. täitma kõiki tellija juures kehtivaid ja õigusaktidest tulenevaid andmekaitsealaseid ja
andmete turvalisust puudutavaid eeskirju, kui need on täitjale teatavaks tehtud;
4.1.11. teostama tööd kuni kokku lepitud tulemi üleandmise ja vastuvõtmiseni oma
ressursside arvel, kui pooled ei ole kokku leppinud teisiti;
1
https://www.tehik.ee/meist/meistnouded-arendustele/
2
4.1.12. teavitama kirjalikku taasesitamist võimaldavas vormis oma mistahes huvist, mis võib
põhjustada lepingu täitmisel huvide konflikti tekkimist;
4.1.13. viivitamata teavitama tellijat täitja vastu suunatud küberintsidendist, mis mõjutab või
võib mõjutada käesoleva lepingu täitmist, tellija infosüsteemide turvalisust või tellija
andmete konfidentsiaalsust ning esitama tellija põhjendatud nõudmisel asjakohase
küberintsidendi raporti osas, mis puudutab tellijale osutatavat teenust;
4.1.14. teostama tööd kvaliteetselt ning vastavalt valdkonna headele tavadele ja praktikale.
Tellija eeldab, et täitja on tarkvaraarenduse valdkonna professionaal, kes saab aru ning
võtab teadlikult enda kanda lepingu funktsionaalsete ja mittefunktsionaalsete nõuete
täidetavuse ja tulemuse saavutatavuse riski. Sellest tulenevalt laieneb täitjale ka selliste
tööde tegemise kohustus, mida ei ole lepingus kokku lepitud, kuid mis oma olemusest
lähtuvalt kuuluvad lepinguga seotud tööde hulka. Nimetatud tööde tegemine ei kuulu
eraldi tasustamisele ning täitja teostab kirjeldatud tööd lepingu täitmise raames.
4.2. Täitjal on õigus:
4.2.1. saada lepingu täitmise eest kokkulepitud ulatuses ja korras tasu;
4.2.2. kasutada lepingu täitmisel alltöövõtjaid, kooskõlastades alltöövõtjate kasutamise
eelnevalt tellijaga. Alltöövõtjate tegevuse ja tegevusetuse eest vastutab tellija ees täitja;
4.2.3. anda arve esitamise õiguse üle kolmandale isikule lepingu muudatust sõlmimata, kui
ta on tellijale esitanud sellekohase teate.
4.3. Tellija kohustub:
4.3.1. tasuma täitjale vastu võetud tööde teostamise eest kokkulepitud ulatuses ja korras;
4.3.2. tagama täitjale ligipääsu (sh kaugjuurdepääsu) lepingu täitmiseks oluliste tellija
hallatavate keskkondade olemasolu ja toimimise;
4.3.3. võtma aktiga vastu täitja poolt üle antud puudusteta tööd mõistliku aja jooksul või
vastavalt lepingus kokku lepitud tähtajale;
4.3.4. teavitama täitjale üle antud töödes esinevatest puudustest ja andma puuduste
kõrvaldamiseks mõistliku täiendava tähtaja, kui tähtaeg ei tulene muudest kokkulepetest.
4.4. Tellijal on õigus:
4.4.1. kontrollida jooksvalt lepingu täitmist ja anda täitjale selleks suuniseid või nõuda
täitjalt sellekohast informatsiooni;
4.4.2. keelduda osaliselt või täielikult tasu maksmisest, kui täitja ei teostanud
nõuetekohaseid töid kokku lepitud tähtajaks ja täitja poolne rikkumine ei ole objektiivselt
põhjendatud (nt on tegemist objektiivse põhjendusega, kui lepingu täitmine on viibinud
tellija või kolmanda osapoole tegevuse tõttu);
4.4.3. kaasata lepingu täitmiseks tellija poolel kolmandaid osapooli, nt teisi riigiasutusi.
Kolmanda osapoole kaasamine tellija poolt ei ole käsitletav lepingu muutmisena
riigihangete seaduse mõttes.
5. Tööde teostamise, üleandmise ja vastuvõtmise kord
5.1. Täitja annab tööd üle hiljemalt lepingus kokkulepitud tähtaegadel ja tingimustel. Koos
töödega antakse üle nõuetekohane dokumentatsioon, kommenteeritud lähtekood,
intellektuaalomandi õigused ja muu lepingus kokkulepitu.
5.2. Tööde tulemused ja vajadusel tööde teostamise käik dokumenteeritakse ning hallatakse
tellija ettenähtud keskkonnas.
3
5.3. Tarne on lepingu alusel teostatud tööde paketina üleandmine, mis on toodangusse
paigaldamiseks korrektselt konfigureeritud ja koodihalduskeskkonda lisatud. Täitja esitab
kogu tarnega seotud dokumentatsiooni, testid ja muud nõutud tulemid.
5.4. Üleantavad tööd tuleb täitja poolt enne tellijale üle andmist testida, koostada testiraportid
ja testilood.
5.5. Täitja annab tööd üle omalt poolt allkirjastatud aktiga.
5.6. Tellija võtab tööd vastu akti allkirjastamisega pärast edukat vastuvõtutestimist.
5.7. Tööd loetakse nõuetekohaselt teostatuks, kui tööd vastavad lepingu tingimustele ja tööd
on aktiga tellija poolt vastu võetud.
5.8. Tellija võib tööd vastu võtta, kui töödes esineb üksikuid ja tellija jaoks väheolulisi
pisivigasid, mis fikseeritakse aktis. Tellija poolne pisivigadega tööde vastuvõtmine ei
vabasta täitjat kohustusest vead kõrvaldada ning üle anda vigadeta tööd. Tellija määrab
mõistliku tähtaja pisivigade parandamiseks.
5.9. Tellijal on õigus keelduda tööde vastuvõtmisest kui tööd ei vasta esitatud nõuetele või
töödes esineb muid vigu.
5.10. Kui tellija esitab vastuväited töödele, peab täitja tööd parandama tellija poolt määratud
mõistliku tähtaja jooksul. Kui täitja ei ole tellija antud tähtaja jooksul kõrvaldanud
avastatud vigu, võib tellija tööd ise parandada või lasta seda teha kolmandatel isikutel ja
nõuda täitjalt selleks tehtud mõistlike kulutuste hüvitamist.
5.11. Alates teisest kordustestimisest võib tellija kordustestidega seotud kulutused (tellija
kulutatud tööaeg ja/ või tellija testimispartnerite poolt esitatud arvete alusel) täitjalt välja
nõuda või tasaarvestada.
6. Intellektuaalomand
6.1. Täitja kinnitab lepingu allkirjastamisega, et talle kuuluvad lepingu täitmiseks vajalikud
autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on vajalikud lepingu
järgsete tööde teostamiseks ja õiguste loovutamiseks tellijale ning nende suhtes ei ole
õigusi ega nõudeid kolmandatel isikutel.
6.2. Tasu intellektuaalse omandi varaliste õiguste loovutamise ja litsentsi andmise eest sisaldub
lepingu hinnas.
6.3. Täitja loovutab tellijale lepingu täitmise käigus loodud kõik mistahes vormis tööde osad,
mis puutuvad tööde teostamisse, kõik autori varalised õigused ning annab lihtlitsentsi
autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu autoriõiguste kehtivuse
ajaks ilma geograafiliste piiranguteta tööde üleandmise hetkest, loobudes sellega lepingu
alusel üle antud originaalteoste osas õiguste kasutamisest.
6.4. Täitja tagab, et isiklikud õigused on ilma täitja nõusolekuta teostatavad muuhulgas
järgnevas ulatuses:
6.4.1. tellijal on õigus tööd kasutada mis tahes eesmärgil ja viisil;
6.4.2. tellijal või tellija tellimusel kolmandatel isikutel on õigus teha üle antud töödes
muudatusi ning neid täiendada;
6.4.3. tellijal või tellija tellimusel kolmandatel isikutel on õigus teostatud töid muuta või
töödele lisada tellija või kolmandate isikute poolt loodud töid;
6.4.4. tööde üleandmisega tellijale kinnitab täitja, et tööd on üldsusele avaldamiseks valmis.
4
6.5. Täitja tagab tellijale kõik vajalikud õigused lepingu täitmise käigus loodavate tööde
kontrollimiseks, testimiseks ning süsteemi paigutamiseks ka ajal, mil tööd on
vastuvõtutestimiseks üle antud, kuid ei ole veel tellija poolt aktiga vastu võetud.
6.6. Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste)
olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal
lepingu lõppedes üle võtta täitja funktsioonid.
6.7. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete töödega seotud
intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate
või koostööpartneritega. Juhul, kui eeltoodust tekib tellijale rahaline või muu kohustus või
juhul, kui tellija on kohustatud lõpetama lepingu alusel teostatud ja vastuvõetud tööde
kasutamise, on tellijal õigus nõuda täitjalt sellega kaasneva rahalise või muu kohustuse
täitmist ja/või samaväärse töö loomist ilma täiendavat tasu nõudmata võimalikult lühikese
aja jooksul, hoidudes mistahes viivitustest tarkvara arendamises, kasutuselevõtmises ja
kasutamises tellija poolt.
6.8. Kõik tellijale kaasnevad otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal
isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest omandist tulenevaid
õigusi lepingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab täitja.
6.9. Selles alapeatükis kirjeldatud õigused ja litsentsid loetakse tellijale lõplikult üle läinuks
pärast tööde vastuvõtmist.
7. Vastutus
7.1. Pool vastutab oma lepingulise kohustuse rikkumise eest, välja arvatud juhul, kui rikkumine
on vabandatav vääramatu jõu või muu objektiivse asjaolu tõttu. Nimetatud asjaolu
esinemist peab tõendama pool, kes sellele tugineda soovib.
7.2. Pool vastutab oma lepingulise kohustuse rikkumise eest, mis tuleneb tema poolt lepingu
täitmisse kaasatud isikute tegevusest.
7.3. Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole kohustuste
rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest. Kui tellija viivitab
omapoolsete kohustuste täitmisega ja nende kohustuste mittetähtaegne täitmine ei
võimalda täitjal omapoolseid kohustusi tähtaegselt täita, pikendatakse tööde üleandmise
tähtaega vastava aja võrra. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele
tugineda soovib.
7.4. Kohustuse rikkumisel on teisel poolel õigus kasutada kõiki seadusest või lepingust
tulenevaid õiguskaitsevahendeid vastavalt võlaõigusseadusele.
7.5. Poolte rahaline koguvastutus on piiratud lepingu kogumaksumusega, kuid see piirang ei
kehti süülisel rikkumisel, sh süülisel rikkumisel seoses intellektuaalomandiõiguse või
andmekaitsealaste kohustustega.
7.6. Tasu maksmisega viivitamisel on täitjal õigus nõuda viivist võlaõigusseaduses sätestatud
määras konkreetsete tööde eest maksmisele kuuluvast tasust iga tasumisega viivitatud
kalendripäeva eest. Viivise maksimaalne määr on 25% konkreetsete tööde eest tasumisele
kuuluvast kogusummast. Viivise nõue tuleb esitada allkirjastatult.
7.7. Täitja poolse lepinguliste kohustuste rikkumisena käsitletakse eeskätt olukorda, kus üle
antud tööd ei vasta osaliselt või täielikult lepingu tingimustele, sh kokkulepitud hooldus-
või veaparandustööde tingimustele või esineb muid täitja poolseid lepingu rikkumisi.
5
7.8. Kui täitja rikub lepingulist kohustust, on tellijal õigus nõuda leppetrahvi tasumist, mille
suuruseks on kuni 200 eurot iga rikkumise või rikkumises oldud kalendripäeva eest, kuid
mitte rohkem kui 25% lepingu kogumaksumusest. Kui lepingu täitmine on kokku lepitud
etappide kaupa, siis mitte rohkem kui 25% etapi kogumaksumusest.
7.9. Juhul kui täitja poolsetest viivitustest tingitult ei ole tööde kasutuselevõtt enam realistlik
või vajalik, on tellijal õigus lepingust taganeda vastavalt võlaõigusseaduse § 116 lõikele 1
ning täitja on kohustatud tegema juba makstud osa eest tellijale tagasimakse.
7.10. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue kuni 25%
lepingu kogumaksumusest. Täitja poolse olulise lepingu rikkumise korral ei pea tellija
määrama täitjale lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud täiendavat
tähtaega ning tellijal on muu hulgas õigus leping üles öelda või lepingust taganeda.
7.11. Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses sätestatule muuhulgas:
7.11.1. mõjuva põhjuseta lepingu täitmise katkestamine või täitmisele mitte asumine;
7.11.2. valeinfo esitamine;
7.11.3. lepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse omandi
õigused) puudumine;
7.11.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine;
7.11.5. konfidentsiaalsuskohustuse rikkumine;
7.11.6. lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata jätmist;
7.11.7. tähtaegselt lepingu täitmata jätmist selliselt, et tehnilises kirjelduses sätestatud
eesmärgi täitmine ei ole enam tähtaegselt realistik ja/või täitja poolse tegevuse või
tegevusetuse tõttu ei ole võimalik enam kasutada lepingu rahastamiseks ettenähtud
vahendeid;
7.11.8. lepingujärgsete kohustuste üleandmine kolmandale isikule ilma tellija
digiallkirjastatud nõusolekuta.
7.12. Tööde vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust lepingu rikkumise
eest.
7.13. Leppetrahvi nõude kohustub tellija esitama mõistliku aja jooksul, kuid mitte hiljem kui 3
kuu jooksul alates päevast, mil tellija sai teadlikuks leppetrahvi nõude aluseks olevast
asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta täitjat selle maksmise kohustusest
enne vastava kohtuotsuse jõustumist.
7.14. Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates tellija poolt vastava nõude
esitamisest, kui leppetrahvi nõudes ei ole määratud teisiti.
7.15. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale töö teostamise eest tasumisele
kuuluvate maksetega. Tasaarvestamise korral ei rakendata leppetrahvi tasumise
kohustust.
8. Konfidentsiaalsuskohustus
8.1. Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele
ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt
poolelt lepingu alusel tellitud tööde teostamise käigus või muul viisil või juhuslikult.
8.2. Täitja peab võtma kasutusele isikuandmete ja tellija infosüsteemide kaitseks
organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid, lähtudes muuhulgas
6
kehtivatest õigusaktidest. Täitja ei tohi töödelda arenduskeskkondades reaalseid ja
isikustatud andmeid.
8.3. Kui lepingu täitmise raames osutub vajalikuks isikuandmete töötlemine, lepivad pooled
isikuandmete töötlemise tingimused kokku juhindudes isikuandmete kaitse üldmääruse2
artiklis 28 kirjeldatust.
8.4. Konfidentsiaalse informatsiooni all mõistavad pooled igasugust informatsiooni (sh
ärisaladusi, isikuandmeid, lepingute andmeid, infosüsteeme, turvasüsteemide kirjeldusi,
riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid tehnoloogiaid,
spetsifikatsioone jms), mis on saadud seoses lepingu täitmisega ja mille sattumine
kolmandate isikute kätte võib pooltele põhjustada turvariske või majanduslikku kahju või
kolmandate isikute (eelkõige tellija klientide) eraelu puutumatuse rikkumist. Kahtluse
korral eeldatakse informatsiooni konfidentsiaalsust.
8.5. Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille avalikustamise
kohustus tuleneb õigusaktidest või mille avalikustamiseks pooled on andnud nõusoleku.
8.6. Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele isikutele, kes on
tellitud tööde täitmisega otseselt seotud. Täitja kohustub tagama, et isikud, keda ta oma
kohustuste täitmisel kasutab, oleksid konfidentsiaalsuse kohustusest teadlikud ning
nõudma nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut täitmist. Vastutus
konfidentsiaalsuskohustuste täitmise eest lasub täitjal.
8.7. Pooled ei kasuta lepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni
oma huvides ega muul eesmärgil, kui tellitud tööde teostamiseks.
8.8. Konfidentsiaalsuskohustuse rikkumise korral kohustub täitja hüvitama kõik kahjud, mis
sellise rikkumise tagajärjel tellijale või kolmandale isikule tekkisid, sõltumata sellest, kas
rikkumine pandi toime lepingu kehtivuse ajal või lepinguliste kohustuste lõppemise
järgselt.
8.9. Täitja on teadlik, et leping ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe
seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud täitja
poolt ärisaladuseks.
8.10. Konfidentsiaalsuskohustus kehtib tähtajatult.
9. Lepingu kehtivus
9.1. Leping jõustub sõlmimisel.
9.2. Lepingut muudetakse pooltevahelise kirjaliku kokkuleppega lepinguga samas vormis,
arvestades riigihangete seaduses toodut.
9.3. Kui mõni lepingu tingimus peaks osutuma osaliselt või täielikult kehtetuks või täitmisele
mittepööratavaks, ei mõjuta see teiste lepingu tingimuste kehtivust ning lepingu ülejäänud
tingimused jäävad kehtima ja täitmisele pööratavaks. Sel juhul võimalusel asendatakse
kehtetu või täitmisele mittepööratav tingimus õiguslikult kehtiva tingimusega, mis on
sisult võimalikult lähedane poolte kavatsustele ja kehtetu tingimuse majanduslikule
mõjule.
9.4. Tellija võib lepingu igal ajal sõltumata põhjusest korraliselt üles öelda. Lepingu lõpetamine
vabastab pooled käesoleva lepinguga sätestatud kohustuste täitmisest. Täitja võib nõuda
2
Euroopa Parlamendi ja Nõukogu määrus nr (EL) 2016/679.
7
tasu juba tehtud ja tellijale väärtust loovate tööde eest. Täitja ei või nõuda saamata jäänud
tulu.
9.5. Tellijal on õigus leping erakorraliselt üles öelda või sellest taganeda, kui täitja on oluliselt
lepingut rikkunud või juhul, kui täitja:
9.5.1. suhtes on algatatud pankrotimenetlus;
9.5.2. pankrot on välja kuulutatud;
9.5.3. täitja varad arestitakse;
9.5.4. täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see muudab
lepingu nõuetekohase täitmise vähetõenäoliseks.
9.6. Lepingu lõppemisel mistahes alusel ja põhjusel on täitja kohustatud tellijale üle andma
kogu tööga seotud informatsiooni ja dokumentatsioon (nii digitaalselt kui paberkandjal,
samuti informatsiooni, mida ei ole salvestatud eelnimetatud infokandjatele). Üleantav info
ja dokumentatsioon peab olema süstematiseeritud. Täitja on kohustatud andma
ammendavad selgitused eelkirjeldatud informatsiooni haldamise ja kasutamise kohta,
tehes seda tellija nõudmisel kirjalikult.
10. Teadete edastamine ja kontaktisikud
10.1. Teadete edastamine toimub üldjuhul e-posti teel, lähtudes kodukorra tingimustest selle
olemasolul. E-posti teel, sh digitaalselt allkirjastatud dokumentide, saatmise korral
loetakse teade kättesaaduks kohale jõudmise teates märgitud kellaajal või e-kirjas
näidatud saatmise kellaajal.
10.2. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peab teade olema edastatud
digiallkirjastatult poole allkirjaõigusliku isiku poolt. Informatiivset teadet võib edastada ka
telefoni teel. Informatiivseks loetakse teade, millega ei kaasne õiguslikke tagajärgi.
10.3. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või kui
teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil ja
postitamisest on möödunud 5 kalendripäeva.
10.4. Tellija kontaktisik(ud) on: Reigo Päts, e-post:
[email protected] või tema asendaja;
10.5. Täitja kontaktisik(ud) on: Olga Golubeva, e-post:
[email protected] või tema
asendaja;
10.6. Kontaktisikute pädevuses on anda teisele poolele vajaliku informatsiooni ja juhiseid oma
pädevuse piires, anda nõusolek meeskonnaliikme vahetamiseks, kontrollida teostatud
lepingu kvaliteeti, anda lepingu ese üle ja võtta vastu ning allkirjastada akt.
10.7. Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult.
11. Lõppsätted
11.1. Täitjal puudub volitus tegeleda lepingu raames avalike suhetega ning anda teateid.
Lepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada,
antakse lahendamiseks Harju Maakohtule.
11.2. Lepingule kohaldub Eesti õigus.
11.3. Lepinguga reguleerimata küsimustes või olukorras, kus mõni lepingu säte on vastuolus
seadusega, lähtutakse Eesti Vabariigis kehtivast seadusandlusest.
8
12. Lisad
12.1. Lisa 1 – Tehniline kirjeldus;
12.2. Lisa 2 – Tööde üleandmise-vastuvõtmise akt;
12.3. Lisa 3 – Pakkumus.
13. Poolte allkirjad
Tellija Täitja
/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/
9
AI WM lähteülesanne
AI WM lähteülesanne ....................................................................................................... 1
1. ÜLDINFO JA TAUST ............................................................................................................... 2
1.1 Kontekst ................................................................................................................................................... 2
1.2 Peamine eesmärk ..................................................................................................................................... 2
1.3 Praegune olukord ..................................................................................................................................... 2
1.4 Projekti strateegiline suund ..................................................................................................................... 2
2. EESMÄRGID .......................................................................................................................... 3
3. SKOOP.................................................................................................................................. 5
3.1 Migreeritava mooduli valik ...................................................................................................................... 5
3.3 Skoopi kuulub........................................................................................................................................... 5
3.4 Skoobist väljas .......................................................................................................................................... 6
3.5 Dokumentatsiooninõuded (documentation-as-code) ............................................................................. 6
4. AI-FIRST ENGINEERING NÕUDED ........................................................................................... 7
4.1 Põhimõte .................................................................................................................................................. 7
4.2 Kohustuslikud AI kasutuskohad ............................................................................................................... 7
4.3 AI-first engineering mõõdikud ................................................................................................................. 7
4.4 AI tööriistade nõuded .............................................................................................................................. 8
5. TEHIK-U KESKSETE REPODE JA SKILL'IDE KASUTAMINE JA TÄIENDAMINE ............................... 8
5.1 Viited normatiivdokumentidele ............................................................................................................... 8
5.2 Täiendamise kohustus ............................................................................................................................. 8
6. ARHITEKTUURSED NÕUDED .................................................................................................. 9
6.1 Põhinõuded .............................................................................................................................................. 9
7. PROJEKTI KULGEMINE........................................................................................................... 9
8. TULEMID JA ÜLEANDMISKRITEERIUMID .............................................................................. 10
8.1 Tulemid .................................................................................................................................................. 10
8.2 Aktsepteerimiskriteeriumid ................................................................................................................... 11
9. VIITED ................................................................................................................................ 13
1. ÜLDINFO JA TAUST
1.1 Kontekst
TEHIK haldab ja arendab Eesti tervise- ja heaolu valdkonna infosüsteeme. Oluline osa
teenustest töötab täna legacy platvormil (Software AG webMethods Integration Server +
Oracle andmebaas). webMethods platvorm on end ammendanud nii tehnoloogilise elutsükli,
hooldatavuse, skaleeritavuse kui ka arenduskiiruse ja litsentsikulu mõttes.
Käesoleva lähteülesande eesmärk on ühe valitud mooduli koodi eraldamine webMethods
platvormilt ja selle re-implementeerimine iseseisva mikroteenusena, mis jätkab tööd
olemasoleva Oracle andmebaasi vastu. Projekti läbiv lähenemine on AI-first engineering
ning kohustuslik on tugineda TEHIK-u kesksetele skill'idele, taristule,
arenduspraktikatele ja koodirepositooriumidele ning neid täiendada.
1.2 Peamine eesmärk
Käesolev projekt on PoC (Proof of Concept) kahe fookusega:
1. AI-first arenduskultuuri arendamine — tekitada maksimaalne hulk
taaskasutatavaid artefakte, töövoo mustreid ja praktikaid, mis võimaldavad järgmistel
migratsiooniprojektidel käivituda oluliselt kiiremini.
2. Arenduskiiruse mõõtmine — testida ja mõõta, kui palju kiiremini on AI-first
lähenemisega võimalik WM mooduleid migreerida võrreldes traditsioonilise
lähenemisega. Mõõtmisege tegeleb TEHIK. Võrdleme varem antud hinnaguid ja
sarnaseid varem tehtud töid vastu uut AIga tehtud tööd.
PoC teenib pikaajalist strateegilist eesmärki: vabaneda Software AG webMethods
litsentsidest, eraldades äriloogika WM platvormilt iseseisvateks mikroteenusteks, mis
töötavad olemasoleva Oracle andmebaasi vastu.
1.3 Praegune olukord
Platvorm: Software AG webMethods Integration Server + Oracle andmebaas
Arhitektuur: Monolitne ESB-põhine integratsioonikiht; teenused on tihedalt seotud
webMethods runtime'i, flow services'ite ja WM-spetsiifiliste komponentidega
Andmebaas: Oracle — jääb esialgu muutmata, mikroteenused peavad töötama
olemasoleva Oracle skeemi vastu
Probleemid:
o Kõrged litsentsitasud (Software AG webMethods) — peamine motivaator
o Vendor lock-in, WM spetsialistide nappus turul
o Puudub teenuste isoleeritus — ühe mooduli muutmine mõjutab teisi
o Piiratud automaattestimine ja CI/CD võimekus
o Vananenud protokollid ja WM-spetsiifilised raamistikud
o Raskendatud monitooring ja intsidentide isoleerimine
1.4 Projekti strateegiline suund
Projekt on osa TEHIK-u laiemast moderniseerimisstrateegiast, kus webMethods platvormi
moodulid eraldatakse ükshaaval iseseisvateks mikroteenusteks. Käesolev lähteülesanne katab
ühe mooduli migreerimise, kuid lahendus peab olema musterlahenduseks (template)
järgmistele migratsioonidele.
1.5 Projekti otsustuskohad
Projektis on vähemalt kaks peamist otsustuskohta:
1. Suurimaks riskiks peetakse AI võimekust mõista WebMethodsi XML-põhist
kirjeldust/konfiguratsioone ning tuvastada selle põhjal äriloogika. Kui selline
lähenemine ei osutu mõistliku ajakulu juures toimivaks (näiteks pärast 40 töötunni
kulumist ei ole saavutatud soovitud tulemust), hinnatakse võimalust jätkata äriloogika
kirjeldamist käsitsi, et võimaldada PoC-i raames testida teisi AI-ga seotud tegevusi ja
töövõtteid.
2. Teiseks riskikohaks on lahenduse tootestamine. Võib tekkida olukord, kus enne
kasutuselevõttu on vajalik teostada täiendavaid arendusi puudujääkide
kõrvaldamiseks (nt tehniline võlg või muud ilmnenud probleemid).
Iga otsustuskoha juures on TEHIKul õigus hinnata projekti jätkamise otstarbekust ning
vajadusel otsustada PoC katkestada. Samuti jätab TEHIK endale õiguse teha analoogseid
otsuseid ka muude ootamatult ilmnevate riskide või otsustuskohtade korral.
2. EESMÄRGID
# Eesmärk Mõõdik
Valitud moodul töötab iseseisva
Teenus läbib kõik aktseptantstestid;
E1 mikroteenusena, ilma webMethods
WM komponent on välja lülitatud
runtime'ita
Andmebaasi skeemi ei muudeta;
Mikroteenus töötab olemasoleva Oracle
E2 olemasolevad andmed on
andmebaasi vastu
kättesaadavad
Kõik tarbijad töötavad ilma
Sissetulevate ja välja minevate sõnumite
E3 muudatusteta ja muudatused on
struktuurid ei tohi muutuda
tarbijatele nähtamatud
WMis saab vajadusel mooduli koodi ära
E4 kustutada kui uue teenuse Live on olnud WMi mooduli kood on kustutatud.
edukas
Dokumenteeritud AI kasutuskohtade
AI-first engineering lähenemine on
E5 kaardistus, mõõdetav mõju
rakendatud kogu arendusprotsessis
velocity'le
TEHIK-u kesksed repod, skill'id ja PR-id TEHIK-u kesksetesse
E6 arenduspraktikad on kasutatud ning repodesse, täiendatud
täiendatud dokumentatsioon
Lahendus on taaskasutatav musterlahendus Migratsiooni playbook, IaC mallid,
E7
järgmiste moodulite migratsiooniks pipeline mallid
Funktsionaalsus on säilitatud 100%
E8 Paralleelkäituse tulemuste vastavus
(funktsionaalne pariteet)
Koodi repositooriumisse on loodud
“/docs” alamkaust kuhu on kogutud
kogu antud mooduli
dokumentatsioon, nii tehniline kui ka
Kogu mooduli dokumentatsioon on loodud
äriline. Alamkaustas on kas .MD
E9 AI poolt (suurem jaolt) ja asub koodi
failid või seotud manused
repositooriumis.
Koodi repositooriumis olev
dokumentatsioon on inglise keelne.
3. SKOOP
3.1 Migreeritava mooduli valik
Moodul mis on valitud PoCi on „Digiregistratuuri saatekirja vastuste teenus“. TEHIKu
sisemises dokumentatsiooni täpsustused on kirjas „UC208 Saatekirja vastuste nimekirja
päring“
Teenuse Lühikirjeldus
Süsteem võtab vastu saatekirja vastuste nimekirja päringu, leiab enda andmebaasist vastavalt
päringus antud otsinguparameetritele huvipakkuvad saatekirja vastused ning tagastab need
väljakutsujale.
Saatekirja vastuse all ei mõelda siinkohal mitte ainult saatekirja vastuseid (dokumente tüüpi
64), vaid üldisemalt meditsiinidokumente, mis vastavad saatekirju. Täpsemalt mõeldakse
selle päringu kontekstis saatekirja vastuste all kõiki järgmist tüüpi meditsiinidokumente, mis
omavad inFulfillmentOf elemendis viidet saatekirjale, mida need vastavad:
1 - statsionaarne epikriis
2 - ambulatoorne epikriis
3 - päevaravi epikriis
4 - sünniepikriis
10 - koduõendusepikriis
34 - hambaravikaart
50 - pildiviit
64 - saatekirja vastus
94 - Kodu- ja iseseisva statsionaarse õenduse epikriis
3.3 Skoopi kuulub
1. Analüüs ja reverse engineering
o Legacy mooduli reverse engineering (webMethods flow services, Java
services, triggerid, adapters, WM-spetsiifilised konfiguratsioonid)
o Äriloogika ekstraheerimine ja dokumenteerimine WM koodist (vt p 3.5 —
dokumentatsiooninõuded)
o Oracle andmebaasi sõltuvuste kaardistamine (protseduurid, vaated, trigerid,
skeemid, mida moodul kasutab)
o Integratsioonipunktide kaardistamine ja dokumenteerimine (teised WM
teenused, välised süsteemid) (vt p 3.5)
2. Koodi eraldamine ja re-implementeerimine
o WM flow services / Java services äriloogika re-implementeerimine
mikroteenusena
o Oracle andmebaasi vastu töötava andmekihi (data access layer) loomine —
olemasolevat skeemi ei muudeta
o Sissetulevate ja välja minevate sõnumite struktuurid ei tohi muutuda —
tarbijad ei tohi vajada muudatusi
o Integratsioonikihi adapter (strangler fig pattern) üleminekuperioodiks —
liikluse suunamine WM-lt uuele teenusele
3. Testimine
o Automaattestid (unit, integration)
o Jõudlustestimine (uus teenus ainult)
o Uue ja vana süsteemi paralleelne jooksutamine testimine
4. Deployment ja operatsioonid
o CI/CD pipeline ülesseadmine
o Infrastructure as Code (IaC)
o Blue-green deployment võimekuse tagamine
o Monitooringu seadistamine
5. Dokumentatsioon
o Kogu dokumentatsioon vastavalt p 3.5 nõuetele (repos, AI-sõbralik formaat)
o Migratsiooni playbook (template järgmistele moodulitele)
o Teadmusülekanne toimub läbi dokumentatsiooni — eraldi koolitussessioone
ei nõuta
3.4 Skoobist väljas
Teiste moodulite migratsioon (välja arvatud valitud moodul)
Oracle andmebaasi skeemi muutmine või andmemigratsioon — teenus töötab
olemasoleva Oracle skeemi vastu, muudatusi Oracle poolel ei tehta
webMethods platvormi decommissioning (tehakse TEHIK-u poolt pärast kõigi
moodulite migratsiooni)
Äriprotsesside muutmine (funktsionaalne pariteet)
3.5 Dokumentatsiooninõuded (documentation-as-code)
Kogu süsteemi ja projekti dokumentatsioon peab asuma Git repos, koos lähtekoodiga, ja
olema AI-tööriistadele sobivas formaadis. Dokumentatsioon on ühtlasi peamine
teadmusülekande mehhanism — see peab olema piisavalt põhjalik ja struktureeritud, et
TEHIK-u meeskond saaks AI tööriistade abil süsteemi iseseisvalt mõista, hooldada ja edasi
arendada.
Põhimõte Kirjeldus
Documentation-as- Kogu dokumentatsioon on Markdown (.md) failides Git repos —
code mitte Confluence'is, Wiki's ega muudes välistes süsteemides
Struktureeritud Markdown, mis on masinloetav: selged pealkirjad,
AI-sõbralik formaat
tabelid, koodiplokid, PlantUML diagrammid
Dokumentatsioon asub samas repos kus lähtekood, docs/
Koodi kõrval
kataloogis
Iga WM-st ekstraheeritud äriloogika osa on eraldi .md failina
Äriloogika kaardistus
docs/business-logic/ all
Integratsioonide
Iga integratsioonipunkt on eraldi .md failina docs/integrations/ all
kaardistus
API dokumentatsioon Loodud docs/ all rakenduse API dokumentatsioon
Dokumentatsioon uueneb koos koodiga — PR-id peavad
Elav dokumentatsioon
sisaldama ka dokumentatsiooni uuendusi
Iga alamkataloog sisaldab README.md faili, mis annab ülevaate ja
Navigeeritav
viitab alamdokumentidele
Dokumentatsioon peab olema piisavalt põhjalik, et asendada
Teadmusülekanne läbi eraldi koolitussessioone. TEHIK-u meeskond peab saama AI
dokumentatsiooni tööriistade abil dokumentatsiooni põhjal süsteemi iseseisvalt
mõista ja hallata
4. AI-FIRST ENGINEERING NÕUDED
4.1 Põhimõte
Kogu arendusprotsess peab olema kavandatud ja läbi viidud AI-first põhimõttel. AI
tööriistad ja -meetodid ei ole lisand, vaid esmane tööviis igas arendusfaasis.
4.2 Kohustuslikud AI kasutuskohad
Faas AI rakendus Oodatav väljund
Äriloogika ekstraktsioon →
Legacy koodi automaatanalüüs docs/business-logic/*.md;
Reverse
(WM flow services, Java services, sõltuvusgraafid → docs/oracle-
engineering
Oracle protseduurid) dependencies/; integratsioonid →
docs/integrations/
Arhitektuuriettepanekud →
Disain AI-toetatud arhitektuurne disain
docs/architecture/
AI-toetatud WM koodi WM flow services → Java/Kotlin
Koodi migratsioon teisendamine mikroteenuse koodi genereerimine, mida
koodiks inimesed üle vaatavad
AI-toetatud koodikirjutamine Mõõdetav velocity tõus,
Arendus
(copilot, code generation) koodikvaliteedi analüüs
AI-põhine testide genereerimine Automaatselt genereeritud
Testimine
legacy süsteemi käitumise põhjal testikomplektid, katmisraportid
Automaatsed review
Code review AI-toetatud koodi ülevaatus
kommentaarid, turvaanalüüs
AI-toetatud dokumentatsiooni Ajakohane dokumentatsioon
Dokumentatsioon
genereerimine ja haldus docs/ struktuuris
AI-põhine anomaaliatuvastus ja Konfigureeritud ML-põhised
Monitooring
alerting alertid
4.3 AI-first engineering mõõdikud
Arenduspartner peab jälgima ja raporteerima:
AI adoption rate — % arendustegevustest, kus AI tööriista kasutatakse
AI-generated code ratio — % koodist, mille algseks autoriks on AI (koos
inimülevaatusega)
Time savings — mõõdetud ajasääst võrreldes traditsioonilise lähenemisega
AI toolchain — kasutatud tööriistade nimekiri ja versioonid
4.4 AI tööriistade nõuded
Kasutatud AI tööriistade valik peab olema kooskõlastatud TEHIK-uga
(andmekaitsenõuded, litsentsipoliitika)
o Ei tohi kasutada hiina mudeleid
o Lubatud on kasutada Claude Code, Cursor, Codex
o Muude asjada puhul küsida TEHIKu arhitektidelt luba
Konfidentsiaalseid andmeid (sh terviseandmeid) ei tohi saata avalikesse AI
teenustesse
o Wiki ja jira andmeid otse ei tohi saata LLM vaid ennem need tuleb exportida
ja siis saata v.a juhul kui selleks ajaks on kehtestatud majasissene ai-poliitika
kuidas agente või lasta jira ja wiki pihta
Arenduspartner peab esitama AI tööriistade kasutusplaani koos üldise riskianalüüsiga
5. TEHIK-U KESKSETE REPODE JA SKILL'IDE
KASUTAMINE JA TÄIENDAMINE
5.1 Viited normatiivdokumentidele
Kõik tehnoloogilised valikud, kvaliteedinõuded, turvanõuded ja tööriistade loend on
fikseeritud järgmistes TEHIK-u dokumentides:
TEHIK MFN (mittefunktsionaalsete nõuete raamistik) — tehnoloogiad,
kvaliteedinõuded, turvanõuded, jõudlusnõuded
TEHIK IT-profiil — lubatud tööriistade, keelte, raamistike ja taristu komponentide
loend
Arenduspartner peab neid järgima. Kõik kõrvalekalded vajavad TEHIK-u kirjalikku
kooskõlastust.
5.2 Täiendamise kohustus
Arenduspartner peab projekti käigus täiendama TEHIK-u keskseid ressursse:
1. Shared libraries — kõik üldkasutatavad komponendid (logging, auth, error handling,
health checks, Oracle connectivity utils jm) tuleb pakkida taaskasutatavaks teegiks ja
lisada TEHIK-u kesksesse reposse
2. IaC mallid — loodud infrastruktuuri kood peab olema generaliseeritud ja lisatud
mallide reposse
3. Pipeline mallid — CI/CD pipeline'i täiendused ja uued stage'id tuleb lisada
kesksetesse mallidesse
4. Dokumentatsioon — ADR-id, runbook'id, migratsiooni playbook tuleb lisada
teenuse reposse vastavalt p 3.5 struktuurile
5. AI-first playbook — projekti käigus loodud AI engineering praktikad, promptid,
workflow'd , skillid,tuleb dokumenteerida docs/ai-engineering/ alla või üldistesse AI
playbook repodesse
6. WM migratsiooni tööriistakomplekt — WM koodi analüüsi ja konverteerimise
skriptid, mallid ja juhised
6. ARHITEKTUURSED NÕUDED
6.1 Põhinõuded
Nõue Kirjeldus
Mikroteenuse
Iseseisev deployable unit, oma API, selged teenusepiirid
muster
Olemasolevad API otsad (endpoints) ei tohi muutuda. Teenuse
API tarbijad peavad töötama ilma igasuguste muudatusteta.
tagasiühilduvus Sisend/väljund formaadid, URL-id, autentimismeetodid jäävad
samaks
Teenus töötab olemasoleva Oracle skeemi vastu — andmebaasi ei
Oracle andmebaasi duplitseerita ega migreerida. Andmekiht peab olema abstraheeritud
jagamine (repository pattern), et tulevikus oleks võimalik andmebaasi
migratsioon minimaalse muudatusega
Event-driven Sündmuspõhine suhtlus teiste teenustega (kus asjakohane)
Üleminekuperioodil töötavad legacy WM teenus ja uus mikroteenus
Strangler fig
paralleelselt; liiklus suunatakse järk-järgult
Blue-green Teenuse uuendamine ilma katkestuseta; võimekus kiiresti tagasi
deployment pöörduda eelmise versiooni peale
Cloud-native Konteineripõhine, Kubernetes-ready
Zero-trust Teenustevaheline autentimine ja autoriseerimine
Andmekihi disain peab võimaldama tulevikus Oracle'ilt teisele
Tulevikukindlus
andmebaasile üle minna minimaalse refactoringuga
7. PROJEKTI KULGEMINE
Faas 1 — Käivitus:
Lepingulised ja organisatoorsed kokkulepped
Ligipääsude seadistamine (WM keskkond, Oracle, TEHIK repod)
Faas 2 — Analüüs:
Reverse engineering ja analüüs
Äriloogika ja integratsioonide dokumenteerimine docs/ struktuuri
Faas 3 — Arendus:
AI-first koodi migratsioon ja re-implementeerimine
Jooksev testimine ja code review
CI/CD pipeline ja IaC ülesseadmine
Blue-green deployment võimekuse tagamine
Jooksvad demod ja TEHIK-u tagasiside
Dokumentatsiooni pidev uuendamine koos koodiga
Faas 4 — Vastuvõtt ja testimine:
Funktsionaalne aktseptantstestimine
API ühilduvuse testimine (tarbijad töötavad muudatusteta)
Jõudlustestimine (uus teenus vs legacy WM)
Turvatestid (AI –ga, “ultrareview”)
Faas 5 — Go-live ja stabiliseerimine:
Liikluse järk-järguline suunamine uuele teenusele (blue-green deployment)
Tagasipöördumise valmisolek kogu perioodi jooksul
Monitooring ja anomaaliatuvastus
WM mooduli deaktiveerimine pärast stabiilset perioodi (TEHIK)
8. TULEMID JA ÜLEANDMISKRITEERIUMID
8.1 Tulemid
Tulemite asukoht selgub täpsemalt töökäigus kuna TEHIKu selle suunaline juhend on
valmimisel.
# Tulem Asukoht
WM mooduli reverse engineering
docs/business-logic/, docs/oracle-
T1 dokumentatsioon (äriloogika,
dependencies/
sõltuvused)
Agentide projektipõhine
T2 CLAUDE.md, AGENTS.md
instruktsioon
T3 Arhitektuurne disain (C4, ADR-id) docs/architecture/
T4 Integratsioonide kaardistus docs/integrations/
T5 Mikroteenuse lähtekood src/ — Git repo TEHIK-u organisatsioonis
Oracle andmekiht
Osa T4-st, dokumenteeritud docs/oracle-
T6 (repository/DAO pattern,
dependencies/
abstraheeritud)
API otsade dokumentatsioon
T7 docs/api/
(muutmata endpoints)
Automaattestid (unit, integration,
T8 tests/, CI/CD pipeline'is
contract, e2e, performance)
IaC + blue-green deployment
T9 infrastructure/
konfiguratsioon
T10 CI/CD pipeline TEHIK-u keskses pipeline repos
T11 HELM /helm kaustas
Monitooringu ja alerting'u
T12 infrastructure/, docs/operations/monitoring.md
konfiguratsioon
T13 Operatsiooni runbook docs/operations/runbook.md
Deployment protseduur (sh blue-
T14 docs/operations/deployment.md
green)
Migratsiooni playbook (template
T15 docs/migration/playbook.md
järgmistele WM moodulitele)
T16 AI-first engineering playbook docs/ai-engineering/,
TEHIK-u keskses repos, üldised ja
WM migratsiooni
üldkasutatavad on keskses repos, tervise
T17 tööriistakomplekt (skriptid, mallid,
valdkonna spetsiifilised on eraldatud tervise
analüüsitööriistad)
alamkausta.
Kontributsioonid TEHIK-u
T18 PR-id merged
kesksetesse repodesse
8.2 Aktsepteerimiskriteeriumid
1. Kõik legacy WM mooduli funktsionaalsed nõuded on kaetud (funktsionaalne pariteet)
2. Sissetulevate ja välja minevate sõnumite struktuurid ei ole muutunud— kõik
tarbijad töötavad ilma muudatusteta
3. Mikroteenus töötab olemasoleva Oracle andmebaasi vastu ilma
skeemimuudatusteta
4. Paralleelkäituse testimine on läbitud edukalt (≥ 99% vastavus)
5. Jõudlustestid on läbitud (p95 ≤ legacy WM teenuse p95)
6. Turvatestid on läbitud vastavalt nõuetele
7. Blue-green deployment on testitud ja töötab (sh tagasipöördumine)
8. WM mooduli on edukalt deaktiveeritud, teenus töötab iseseisvalt
9. Kogu dokumentatsioon asub repos docs/ struktuuris vastavalt p 3.5 nõuetele ja on
piisavalt põhjalik, et TEHIK-u meeskond saaks AI tööriistade abil süsteemi iseseisvalt
hallata
10. Kõik tulemid (T1–T18) on üle antud ja aktsepteeritud
9. VIITED
TEHIK üldiste skillset -ide repositoorium - https://github.com/TEHIK-EE/ai-generic-
skills
TEHIK AI kasutamise parimate praktikate repositoorium - https://github.com/TEHIK-
EE/ai-best-practices
POWER OF ATTORNEY VOLIKIRI
On the 10th of July 2025 10.07.2025
Nortal AS, registration code 10391131 (hereinafter Nortal), gives Nortal AS, registrikood 10391131 (edaspidi Nortal), annab
the following power of attorney: alljärgneva volituse:
1. Content of authorisation 1. Volituse sisu
Käesoleva volitusega Nortal annab Olga Golubeva’le,
With this power of attorney, Nortal authorises Olga Golubeva,
sünniaeg 24.03.1987, isikukood 48703240302, elukohaga
date of birth 24.03.1987, personal code 48703240302, place of
Tallinn, Eesti Vabariik („Volitatud Esindaja“) õiguse enda
residence Tallinn, Republic of Estonia (“Attorney”), to:
nimel:
1) Represent Nortal in public procurements, including, but not
1) Esindada Nortalit riigihangetel, sealhulgas, kuid mitte
limited to, sign public procurement related statements,
ainult Nortali nimel allkirjastada riigihangetega seotud
applications, deeds, acts, tender offers, and negotiate and
avaldusi, taotlusi, hanke akte ja hankepakkumisi ning
sign procurement contracts under all conditions at the sole
läbi rääkida ja sõlmida hankelepinguid kõikidel
discretion of the Attorney;
tingimustel Volitatud Esindaja omal äranägemisel;
2) Represent Nortal before all persons in relation to provision
2) Esindada Nortalit kõikide isikute ees seoses IT-teenuste
and procurement of IT services, including, but not limited
osutamise ja ostmisega, sealhulgas, kuid mitte ainult
to, negotiate and sign all IT services related contracts and
läbi rääkima ja allkirjastama kõiki IT teenustega seotud
contracts related to the procurement or sales of goods under
lepinguid ning kaupade ostu ja müügiga seotud
all conditions at the sole discretion of the Attorney;
lepinguid kõikidel tingimustel Volitatud Esindaja omal
äranägemisel.
In connection with the powers described in this power of Eelpool toodud volitustega seotuses on esindaja volitatud
attorney, the Attorney is authorized to receive and formalize all saama ja vormistama kõiki dokumente, esitama taotlusi ja
documents, submit requests and applications, conclude avaldusi, sõlmima lepinguid ja nende muudatusi, osalema
contracts and respective amendments, participate in tenders, pakkumistel, tasuma ja vastu võtma rahasummasid,
pay and receive money, sign documents on behalf of Nortal and dokumente Nortali nimel alla kirjutama ning tegema kõik
do everything else related to the powers specified in this power muu, mis on seotud käesolevas volikirjas nimetatud
of attorney. volitustega.
2. Term of the power of attorney. Specifications concerning 2. Volituse tähtaeg. Esindusõiguse erisused.
representation.
The power of attorney shall remain effective until 10th of July Volikiri kehtib kuni 10.07.2027.
2027.
Volikiri on antud edasivolitamise õiguseta.
The power of attorney has been issued without the right to
delegate the powers.
Volikiri kehtib kogu maailmas, st sellel puuduvad
The power of attorney is valid worldwide, i.e. does not have any geograafilised piirangud.
geographical restrictions.
The power of attorney shall be governed by and construed in Volikirjale kohaldub Eesti õigus.
accordance with the laws of Estonia.
/allkirjastatud digitaalselt/
/signed digitally/
Andre Krull
Andre Krull
Juhatuse liige
Member of the management board