Väljaminev kiri

Lisa 1. HANKELEPINGU projekt

Poolte andmed

Tellija Siseministeeriumi infotehnoloogia- ja arenduskeskus

Registrikood 70008440

Aadress Mäealuse 2/2, 12618 Tallinn, Eesti Vabariik

Tellija esindaja

Esinduse alus Põhimäärus/volikiri

Kontaktisikud 1. Reili Kaibald, tooteomanik, e-post [email protected],

telefon 5781 0440 või tema asendaja;

2. Kaie Kasemets, tiimijuht, e-post [email protected],

telefon 5908 7152 või tema asendaja;

3. Kaija Kirch, juhataja, e-post [email protected], telefon 523

5457 või tema asendaja

Täitja OÜ/AS

Registrikood

Aadress

Täitja esindaja

Esinduse alus Põhikiri/volikiri

Kontaktisikud 1. Nimi, ametinimetus, e-post, telefon.

2. …

1. Lepingu sõlmimise alus 12.10.2023. a sõlmitud raamleping nr .3-3/3330 (riigihanke

viitenumber 264288) alusdokumendid, tellija … minikonkurss

(viitenumber 290917) ja täitja … pakkumus

2. Lepingu ese Isikut tõendavate dokumentide andmekogu liidestumine

sündmusteenusega

3. Rahastamisallikas Lepingut rahastatakse: Euroopa Parlamendi ja nõukogu

määruse (EL) 2021/241, millega luuakse taaste- ja

vastupidavusrahastu (edaspidi määrus nr 2021/241), artikli 18

lõike 1 alusel Euroopa Komisjon 05.10.2021 ning Euroopa

Nõukogu 29.10.2021 rakendusotsusega kinnitatud Eesti taaste-

ja vastupidavuskava järgne reform „Eraisikutele

sündmusteenuste ja etteaimavate teenuste väljaarendamine“;

ning Vabariigi Valitsuse 29. novembri 2021. a määrus nr 108

„Taaste- ja vastupidavuskava elluviimise korraldus ja toetuse

andmise üldtingimused“ alusel sõlmitud toetuse kasutamise

lepinguga. Toetuse kood 9S40-RR20-03123RRF.

4 Lepingu eseme täitmine 4.1 Hankelepinguga ostab tellija arendus- ja analüüsitöö tulemit, mis on kirjeldatud käesoleva

lepingu lisas 2.

4.2 Hankelepingu täitmise tähtaeg on 31.03.2026. Etappide 1 kuni 8 (lisa 2 - tehniline

kirjeldus p. 8 Projekti tulem ja etapid) täitmise tähtaeg on 31.10.2025.

4.3 Hankelepingus kokku leppimata küsimustes sh vastutus lähtutakse raamlepingus ja SMIT

töövõtulepingu üldtingimustes sätestatust, vastuolude korral lähtutakse esmalt

hankelepingus sätestatust, siis raamlepingus sätestatust ning viimaks SMIT töövõtulepingu

üldtingimustes sätestatust.

4.4 Töid teostatakse täitja asukohas. Juhul, kui töid teostatakse täitja juures, kuid hankelepingu

täitmisel esinevad raskused, on tellijal õigus nõuda, et töid tehakse tellija asukohas.

5. Garantiitingimused.

5.1.Garantiiaeg on üks aasta alates hetkest, mil tulem või töö on tellija poolt lepingu kohaselt

vastu võetud;

5.2.Täitja on kohustatud tagama garantiiajal tulemil või tööl ilmnenud puuduste tasuta

kõrvaldamise vastavalt vea prioriteetsusele järgnevalt:

5.2.1. Kui süsteem on töökeskkonnas kasutusel siis peab kriitilise vea parandama 1 tööpäeva

jooksul peale sellekohase teate edastamist tellija poolt täitjale. Kriitiliseks veaks

loetakse tarkvara arendusega seotud viga, mille tõttu: tarkvara tervikuna ei ole

võimalik kasutada; tarkvara põhifunktsionaalsus ei tööta või on oluliselt häiritud;

tarkvara lubab/teostab mitteautoriseeritud operatsioone; kahjustatud on süsteemis

olevad andmed; kasutajale või seotud infosüsteemidele/andmebaasidele väljastatakse

ebaõigeid andmeid/tulemusi. Kriitiliseks veaks loetakse sealhulgas ebamõistliku

sagedusega esinevad sarnased mittekriitilised vead;

5.2.2. Mittekriitilised vead 5 tööpäeva jooksul peale sellekohase teate edastamist tellija poolt

täitjale. Mittekriitiliseks veaks loetakse infosüsteemi toimehäiret, mis ei ole

põhjustatud riistvarast või muust tarkvarast või muust arendustööst ja mida ei saa

käsitleda kriitilise veana;

5.2.3. Veateade loetakse esitatuks, kui see on registreeritud tellija veahalduskeskkonnas ning

veahalduskeskkond on selle edastanud täitjale.

5.3.Täitja teostab garantiiaja vältel vajalikud tööd kasutades lepingukohast meeskonda.

5.4.Muud garantiikohased tingimused on sätestatud SMIT-i käsundus- ja töövõtulepingu

üldtingimustes.

6. Välisvahendite kasutamisest tulenevad nõuded

6.1.Välisvahendite kasutamise lõpptähtpäev on 30.04.2026.

6.2.Lähtuvalt rahastusallikast (välisvahendid) ning sellele kohalduvatest kohustuslikest

nõuetest, kohustuvad pooled tagama alljärgnevat:

6.2.1 Pooled kohustuvad järgima Vabariigi Valitsuse 29.11.2021 määruse nr 108 "Taaste-

ja vastupidavuskava elluviimise korraldus ja toetuse andmise üldtingimused"

(https://www.riigiteataja.ee/akt/120062023004) §-s 12 sätestatud

teavitamisreegleid.

6.2.2 Objektide ja avalikkusele suunatud esemete ja dokumentide märgistamisel logoga

peab Euroopa Liidu embleem koos tekstiga „Rahastanud Euroopa Liit –

NextGenerationEU“ vastama aadressil https://www.rtk.ee/toetused-ja-

taotlemine/taaste-ja-vastupidavusrahastu-rrf/rrf-teavitusreeglid kirjeldatud

juhistele;

6.2.3 Pooled võimaldavad välisvahenditest finantseeritud lepingu korral järelevalve

teostamiseks kogu vajaliku teabe ja volitatud isikutel viibida lepingu täitmises

osalevate isikute ruumides ja territooriumil, mis on rajatud välisvahendite abil või

mis on seotud toetuse kasutamisega ning teostada paikvaatlust.

7. Hankelepingu maksumus ja arveldamise kord

7.1.Hankelepingu kogumaksumus on … eurot, millele lisandub käibemaks.

7.2.Tööd antakse üle etappides, mis on toodud tehnilise kirjelduse punktis 8. Etappide 1, 5 ja 9

üle andmisel makstakse iga etapi eest 20% lepingu summast, summas … eurot. Etappide 2,

4, 7 ja 8 üle andmisel makstakse iga etapi eest 5% lepingu summast, summas … eurot.

Etappide 3 ja 6 üle andmisel makstakse 10% lepingu summast, summas … eurot.

7.3.Täitja võib korraga üle anda ühe või mitu etappi. Üleandmise- vastuvõtmise aktis

fikseeritakse täitja poolt teostatud etapi või etappide tööd.

7.4.Tellijal on õigus esitada täitjale täiendavaid arupärimisi ning selgitusi kajastatud tööde

kohta. Peale üleandmis-vastuvõtmisakti allkirjastamist, esitab täitja tellijale lepingukohase

arve. Üleandmis-vastuvõtmis akti allkirjastamise õigus on hankelepingu kontaktisikul.

7.5.Arved tuleb edastada tellijale vastavalt Eesti e-arve standardile. E-arves peab lisaks

standardis nimetatud andmetele olema toodud tellija kontaktisiku perekonnanimi,

raamhanke riigihangete registri viitenumber, raamlepingu number, minikonkursi

riigihangete registri viitenumber, hankelepingu number, hankelepingu riigihangete registri

15-kohaline viitenumber ja välisvahendite projekti toetuse kood 9S40-RR20-03123RRF. E-

arve tuleb saata e-arvete operaatori kaudu. E-arve loetakse laekunuks selle e-arvete

operaatorile laekumise kuupäevast.

7.6.Arve maksetähtaeg 21 kalendripäeva.

8. Hankelepingu kehtivus

8.1. Hankeleping jõustub alates hetkest, kui pooled on hankelepingu allkirjastanud.

8.2. Hankeleping kehtib Poolte lepinguliste kohustuste täitmiseni.

9. Lepingu lisad

9.1.Lisa 1 – täitja pakkumus;

9.2.Lisa 2 – tehniline kirjeldus;

9.3.Lisa 3 – ….

Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja minikonkursi

alusdokumendid ning täitja riigihankes esitatud pakkumus ja pooltevahelised kirjalikud teated,

mida lisadena eraldi ei allkirjastata.

Leping on koostatud ja allkirjastatud digitaalselt.

Üleandmise-vastuvõtmise akti vorm

Alus (täida need read, mis kohalduvad):

Riigihanke viitenumber: …..

Raamleping nr…., sõlmitud …. a.,

Minikonkursi/tellimuse viitenumber:….,

Hankeleping nr …., sõlmitud …. a.,

Hankelepingu osa viitenumber (riigihangete registri 15-kohaline number) …..

Välisvahenditest rahastatud projekti nr ja nimetus: ….ja „….“

Käesolevaga annab ………….. (täitja ettevõtte nimi) üle ning ……… (tellija asutuse nimi)

võtab vastu (edaspidi lepingu ese):

1. …….. (täida lepingu esemest tulenev võimalikult detailne sisu: tulemi maksumus;

arendus- või hooldusteenuste teostamise periood; arendus- või hooldustööde töötundide

maht ja maksumus; tootekood, selle kirjeldus, kogus, seerianumber, ühik- ja

kogumaksumus);

(ressursi tellimisel):

Meeskonnaliige

(roll)

Teostatud

töötunnid

periood Vastuvõetud töö Töötunni hind

km-ta

Meeskonnaliikme

teostatud töö hind

kokku km-ta

KOKKU km-ta: KOKKU km-ga:

2. ………(dokumentide loetelu).

Üleantava lepingu eseme maksumus on ………………. eurot (lisandub käibemaks).

Lepingu jääk … (tuua välja siis, kui töid antakse üle etapiti/kuude kaupa).

………………. (täitja lepingujärgse kontaktisiku nimi) kinnitab, et lepingu ese on üle antud

tähtaegselt, vastavalt lepingus sätestatud tingimustele.

…………….. (tellija lepingujärgse kontaktisiku nimi) kinnitab, et vastuvõetud lepingu ese

vastab lepingus sätestatud tingimustele ning lepingu ese on üle antud ja vastuvõetud vastavalt

lepingus sätestatud tähtajale ja tingimustele.

Käesolev üleandmise-vastuvõtmise akt on allkirjastatud digitaalselt.

Täitja: Tellija:

………………… …………………..

/asutuse nimi/ /asutuse nimi/

………………….. …………………..

/allkirjastaja nimi/ /allkirjastaja nimi/

Sündmusteenuse ITD taotlus

page 1/22

Sisukord

1 Mõisted ja lühendid ................................................................................................................... 2

2 Probleem ja vajadus .................................................................................................................. 2

3 Piirangud ja eeldused ............................................................................................................... 3

4 Komponentdiagramm ............................................................................................................... 3

5 Üldised tehnilised nõuded arendustele .................................................................................. 5

6 Arenduse etapid ........................................................................................................................ 6

7 Arenduste detailsemad nõuded ............................................................................................... 7 7.1 ETK-EKPID BE ..................................................................................................................... 7 7.2 ETK-EKPID FE ..................................................................................................................... 7

7.2.1 Nõuded ja funktsionaalsus .......................................................................................... 7 7.3 ETK-EKPID liidestus GOVSSOga ........................................................................................ 9 7.4 ETK-EKPID liidestus RRiga ITD taotluse koostamiseks ...................................................... 9

7.4.1 ETK EKPID BE – Uue andmekomplekti muutmine ................................................... 10 7.4.2 ETK-EKPID BE – Andmekomplekti elutsükkel ja staatused ..................................... 12 7.4.3 ETK-EKPID FE – Andmekomplekti täiendamine Kasutaja poolt .............................. 13 7.4.4 ETK-EKPID BE - Muudatused nimevahetusega seotud protsessis.......................... 14 7.4.5 ETK-EKPID BE - Nimevahetuse protsessi tühistamine ............................................ 15 7.4.6 ETK-EKPID BE - Nimevahetuse protsessi lõpetamine ............................................. 16

7.5 ETK-EKPID-st andmete liikumine application bufferisse ja UUSISesse. ........................... 18 7.6 UUSISe arendused ............................................................................................................. 18

7.6.1 Application bufferis andmekomplektide kuvamine .................................................... 18 7.7 Teavitustega seotud arendused ......................................................................................... 19

7.7.1 ETK-EKPID BE teavitused ........................................................................................ 19 7.7.2 UUSIS teavitused ...................................................................................................... 19 7.7.3 Teavituste tekstid ...................................................................................................... 19 7.7.4 UUSIS – E-kirjade menüüpunkti täiendamine ........................................................... 19

7.8 ETK-EKPID ja Uusis liidestus nõusolekuteenusega (RIA) ................................................. 20 7.9 ETK-EKPID ja Uusis liidestus RIA Sündmusteenuste platvormiga .................................... 20

7.9.1 ETK-EKPID BE saadetavad sõnumid: ...................................................................... 20 7.9.2 Uusise saadetavad sõnumid ..................................................................................... 21 7.9.3 Sõnumistruktuur ........................................................................................................ 21

8 Projekti tulem ja etapid ........................................................................................................... 21

Sündmusteenuse ITD taotlus

page 2/22

1 Mõisted ja lühendid

Application buffer

ETK-EKPID FE

ETK-EKPID BE

PPA menetlussüsteemi osa, kus hoitakse PPA iseteeninduskeskkonnas loodud ITD andmekomplekte.

PPA iseteeninduskeskkond, front-end

PPA iseteeninduskeskkond, back-end

GOVSSO Riigi Infosüsteemi Ameti poolt keskselt osutatav teenus, millega asutus saab oma e-teenuses ühekordse sisselogimisega autentida ID-kaardi, mobiil-ID, smart-ID ja Euroopa Liidu eID kasutaja.

ITD Isikut tõendav dokument (ID-kaart või pass)

ITDAK Isikut tõendavate dokumentide andmekogu

Kasutaja

Märgistus

Riigi infosüsteemide teenuseid kasutav isik

ETK-EKPID BE-s RR-lt saadud andmete põhjal salvestatud andmekomplekt, kuhu Kasutaja ei ole veel sellele tehtud täiendusi salvestanud.

PPA Politsei- ja piirivalveamet

RIA Riigi Infosüsteemi Amet

RR Rahvastikuregistri infosüsteem

TARA Riigi Infosüsteemi Ameti poolt pakutav autentimisteenus

Uusis PPA isikut tõendavate dokumentide taotlemise ja menetluse infosüsteem

X-tee Eesti riigi põhilisi andmebaase ühendav keskkond, mis korraldab internetipõhist andmevahetust riigiasutuste vahel ja erasektoriga

2 Probleem ja vajadus

Käesolev dokument kirjeldab ITD (isikut tõendava dokumendi) taotlemise protsessi nime

muutumisega seotud sündmusteenuste raames. Loodav lahendus peab lubama esitada Eesti

kodaniku passi ja ID-kaardi taotluse juba enne riiklikes registrites andmete muutumist.

Dokumentide taotlemise protsessis tuleb arvestada ka sellega, et kasutajal peab olema võimalik

liikuda erinevate keskkonda vahel sujuvalt (kasutades GOVSSOd) ning kasutaja peab andma nn

Sündmusteenuse ITD taotlus

page 3/22

kobarnõusoleku RIAle, et soovib teenust sündmusteenusena tarbida ning nõusoleku kehtivust

tuleb PPA süsteemi poolt kontrollida RIAle andmete edastamisel.

Kasutajaliides peab olema eestikeelne.

Arenduste raames on vaja viia olemasolev ETK-EKPID (kus toimub dokumentide taotlemine)

frontend raamistik üle Vue2lt Vue3-le. ETK-EKPID keskkonnal peavad olema liidestused RRi, RIA

ja dokumentide menetlussüsteemiga (application buffer, UUSIS). Täpsem ülevaade osapoolte

omavahelisest suhtlusest on toodud komponentjoonisel (vt. Komponentdiagramm).

Arenduste lõpus on Tellijal plaanis korraldada antud lahenduse turvatestimine kolmanda osapoole

poolt. Pakkuja ülesandeks jääb antud turvatesti leidude parandamine.

3 Piirangud ja eeldused

Käesoleva versiooni koostamise seisuga ei ole veel arendatud Nõusolekuteenuse nn

“kobarnõusoleku” lahendust (st Kasutajal on võimalus anda nõusolek oma andmete

kasutamiseks kõigile sündmusteenusega seotud osapooltele korraga) ja ei ole ka teada, millal

see valmib. Sellegipoolest on protsessikirjeldustes eeldatud, et selline “kobarnõusoleku”

funktsionaalsus on olemas.

RRi andmevahetuse spetsifikatsioon täpsustub arendustööde alguseks.

Funktsionaalsus peab arvestama ka nimevahetusega ka muudel põhjustel kui abiellumine või

lahutus.

4 Komponentdiagramm Komponentdiagrammil kirjeldatakse üldine suhtlus protsessiga seotud osapoolte vahel (pärast

tulemi teostamist.

RIA sündmusteenuse X-tee on life-events.

Sündmusteenuse ITD taotlus

page 4/22

Sündmusteenuse ITD taotlus

page 5/22

Komponentdiagrammi selgitused

1. RR edastab X-tee kaudu ETK-EKPID BE-le sõnumi nimevahetusprotsessi algatamise

kohta. ETK-EKPID BE loob esialgse andmekomplekti tulevase ITD taotluse tarvis.

2. Kasutaja, olles ennast tuvastanud läbi GOVSSO, siseneb ETK-EKPID FE keskkonda.

Makstud staatuses andmekomplekti kohta saadab ETK-EKPID BE sõnumi RIA

Sündmusteenuse platvormile (eelnevalt kontrollides Nõusolekuteenusest Kasutaja

nõusoleku kehtivust).

3. Tühistamine

3.1 RR edastab sõnumi nimevahetusprotsessi tühistamise kohta. Andmekogu ITDAK-i

alamsüsteemi Andmekomplekt saab staatuse Tühistatud.

3.2 Eelnevalt Makstud staatuses andmekomplekti puhul saadetakse Uusisest e-kirjaga

teavitus Kasutajale menetluse lõpetamise kohta. Uusisesse tehakse selle e-kirja saatmise

kohta märge e-kirjade menüüpunkti ja RIA Sündmusteenuse platvormile edastatakse

sõnum andmekomplekti tühistamise kohta (eelnevalt kontrollides Nõusolekuteenusest

Kasutaja nõusoleku kehtivust).

4. Muutmine.

4.1. RR edastab muutunud andmed (abiellumis- või lahutuskuupäev, nimevahetuse

jõustumine), andmekomplekt salvestatakse ETK-EKPID BE-s uute andmetega.

5. ETK-EKPID salvestatud andmekomplekti alusel ITD taotluse loomine

5.1. RR edastab STEEK BE-le info nimemuutuse jõustumise kohta.

5.2. ETK-EKPID BE edastab salvestatud andmekomplekti Application bufferisse, kus

andmekomplekti põhjal loob PPA ametnik ITD taotluse Uusises.

6. Edasise ITD käsitlemise käigus edastab Uusis RIA Sündmusteenuste platvormile (alati

eelnevalt kontrollides Nõusolekuteenusest Kasutaja nõusoleku kehtivust) sõnumid kui ITD

dokumendid valmivad, on kätte toimetatud või hävitatakse.

5 Üldised tehnilised nõuded arendustele

5.1 Kasutatavad tehnoloogiad

 Spring boot 3, Java 17, Java 21, PostgreSQL 15

 Vue.js 2, Vue.js 3, TypeScript

 Flask, Python 3.11

 Go

 dpyml, Python 2.7, Oracle SQL

 RRi ja RIA-ga seotud liidestused peavad olema tehtud üle x-tee, protokolliks x-tee

REST.

Täpsemad nõuded kirjeldatud dokumendis ’Lisa 2.1 - ITD_Nõuded arendusele’.

Sündmusteenuse ITD taotlus

page 6/22

ETK-EKPID – teha MetaVault liidestus. Vajalik pildi üleslaadimisel.

5.2 Töö vastuvõtmise kriteeriumid/testimine

Pakkuja peab omalt poolt korraldama kõikide projekti skoobis olevate arenduste testimise Tellija

test keskkondades. Selleks peab Pakkuja koostama iga projekti etapi kohta testimiseks töövoo

ja testraporti (sh testlood), et Tellija saaks teostada iga etapi vastuvõtuvõtmisel omalt poolt

testimise test keskkondades ning võttes aluseks testraportis kirjeldatud testlood.

Pakkuja peab tagama, et valminud etapid vastaksid Tellija etteantud tehnilistele nõuetele.

Täpsemad testimise nõuded koos automaattestimise nõuetega on kirjeldatud eraldi dokumendis

’Lisa 2.1 - ITD_Nõuded arendusele’.

6 Arenduse etapid

Tööd viiakse läbi ja arveldatakse etapiviisiliselt.

Etappide läbiviimise ajaline järjekord selgub koostöös tellija ja tööde teostaja vahel.

1. ETK-EKPID BE-i ja ETK-EKPID FE arendustööd

a. ETK-EKPID frontend raamistiku üle viimine Vue-2lt Vue3-le

b. ETK-EKPID BE nõuded ja funktsionaalsus on kirjeldatud peatükis ’ETK-EKPID

BE muutmine'

c. ETK-EKPID FE nõuded ja funktsionaalsus on kirjeldatud peatükis ‘ETK-EKPID

FE muutmine’

d. automaatsed teavitused (ETK-EKPID BE) biomeetria aegumise kohta.

2. ETK-EKPID liidestus GOVSSOga – kasutajal peab olema võimalik liikuda RRi ja PPA

keskkondade vahel sujuvalt ja selle tagamiseks on vajalik liidestus GOVSSOga. Täpsem

kirjeldus peatükis ETK-EKPID liidestus GOVSSOga.

3. ETK-EKPID liidestus RRiga ITD taotluse koostamiseks – eesmärk on tagada

dokumentide taotlemiseks vajalik andmevahetus ETK-EKPID ja RRi vahel. Täpsemad

andmekomplektid on kirjeldatud peatükis ETK-EKPID liidestus RRga ITD taotluse

koostamiseks.

4. ETK-EKPID-st andmete liikumine application bufferisse ja UUSIS-sse – eesmärk tagada

andmekomplektide liikumine ETK-EKPID-st menetlussüsteemi. Täpsem kirjeldus

peatükis ETK-EKPIDst andmete liikumine application bufferisse ja UUSISesse.

5. UUSISe ja application bufferi arendused hõlmavad järgmist (täpsem kirjeldus peatükis

UUSISe ja application bufferi arendused):

a. Andmekomplektide kuvamine (application buffer) ametnikele peale nimevahetuse

toimumist.

b. Teavitused Kaustajale (UUSIS) e-kirjade abil vajaliku info edastamine

menetlussüsteemist (puudustega taotluse kohta teadete saatmine, automaatsed

Sündmusteenuse ITD taotlus

page 7/22

teavitused, kui nimevahetuse protsess on tühistatud/pole toimunud). E-kirjade

saatmisega seotud ajaloo kuvamine vastavas menüüpunktis.

6. STE backendi loomine.

7. ETK-EKPID ja Uusise liidestus nõusolekuteenusega (RIA) – liidestus peab tagama

võimekuse kontrollida kasutaja nõusoleku kehtivust. Täpsem kirjeldus peatükis ETK-

EKPID ja Uusis liidestus nõusolekuteenusega (RIA).

8. ETK-EKPID ja UUSISe liidestus RIA Sündmusteenuste platvormiga (läbi ETK-EKPID BE),

edastamaks sinna infot sündmusteenusega seotud ITD taotluse menetluse kulgemise

kohta (vt. peatükk ETK-EKPID ja Uusis liidestus RIA Sündmusteenuste platvormiga.).

7 Arenduste detailsemad nõuded

Järgnevalt on kirjeldatud arendusetappide detailsem sisu ja nõuded.

7.1 ETK-EKPID BE

Arendused toimuvad olemasolevas keskkonnas. Välisele arendajale võimaldatakse juurdepääs

olemasolevale ETK-EKPID BE koodibaasile. Kogu olemasolev funktsionaalsus tuleb säilitada.

ETK-EKPID BE-s luuakse ja salvestatakse andmekomplektid tulevaste ITD taotluste tarvis

isikutele, kelle nimi on tulevikus muutumas tulenevalt abiellumise/lahutuse sündmusteenusest.

Andmekomplektide loomine ja käsitlemine toimub automaatselt RR-i saadetavate X-tee

sõnumite alusel. Nimemuutuse jõustumisel (abiellumise, lahutuse, nimevahetus toimudes)

luuakse andmekomplekti alusel uus ITD andmekomplekt Application bufferis, mis menetletakse

seejärel Uusises.

7.2 ETK-EKPID FE

Aluseks võetakse olemasolev ETK EKPID FE aga olemasolevad arendused on vaja viia Vue.js

2-lt versioonile Vue.js 3. Kogu olemasolev funktsionaalsus tuleb säilitada.

7.2.1 Nõuded ja funktsionaalsus

Ligipääs ja tuvastamine

Kasutaja, kelle kohta on eelnevalt ETK-EKPID BE andmebaasis salvestatud märgistus (vt. ETK-

EKPID BE – Uue andmekomplekti muutmine) saab ETK-EKPID FE keskkonda siseneda

1) järgides linki, mis kuvatakse Kasutajale RRs

2) järgides linki, mille RR saadab Kasutajale e-posti teel koos teavitusega ITD

andmekomplekti muutmise võimaluse kohta.

3) Logides sisse PPA iseteenindusse (tuleb kuvada info poolelioleva nimevahetusprotsessi

kohta).

Sündmusteenuse ITD taotlus

page 8/22

Juhul 1) on Kasutaja ETK-EKPID FE keskkonda sisenedes juba eelnevalt tuvastatud GOVSSO

poolt.

Juhul 2) kuvatakse Kasutajale TARA autentimisekraan ja Kasutaja läbib standardse GOVSSO

tuvastamisprotsessi enne ligipääsu ETK-EKPID FE keskkonda.

Taotluse liigi valik

Juhul kui isikul on nimemuutuse ST märgistus, peame talle kuvama, kas ta soovib esitada

dokumendi taotlust uue nimega või olemasoleva nimega. Kui ta soovib taotlust esitada vana

nimega, siis jätkub protsess vanaviisi.

Kui ta soovib esitada taotlust uue nimega, siis järgmise valikuna kuvatakse kasutajale ITD-

taotluse liigi valiku vorm. Vorm on oma ülesehituselt ja visuaalselt identne vastava PPA

iseteeninduskeskkonna vormiga (Vali taotluse liik) – s.h. kuvatakse Kasutajale tema kehtiv

perekonnanimi.

Joonis 1 - Taotluse liigi valik

Kui kasutaja on taotluse liigi valinud (kas siis ainult ID-kaart, ainult pass või mõlemad koos)

suunab süsteem ta edasi vastava andmekomplekti loomise lehele.

Taotluse täitmine

Vormid andmekomplekti loomiseks on identsed PPA iseteeninduskeskkonna vastavate

vormidega (Täida ID-kaardi taotlus, Täida passi taotlus, Täida ID-kaardi ja passi taotlus)

järgmiste eranditega:

Väli Taotleja isikuandmed - Kuvatakse nii Kehtiv nimi kui Uus nimi – s.o. tulevane

nimi, nii, nagu see jõudis ETK-EKPID BE

andmebaasi RRst (vt Uue andmekomplekti

muutmine).

Väli Vali taotlemise põhjus - Ainult üks, kirjutuskaitstud valik – Andmed muutunud,

ebaõiged

Andmete salvestamine - Kui Kasutaja klõpsab nuppu [Jätka], salvestatakse

andmed ja kuvatakse kaart „Taotluse andmed“ ka

juhul, kui biomeetria puudub või vajab uuendamist.

Sündmusteenuse ITD taotlus

page 9/22

Joonis 2 Taotleja isikuandmed - kuvatakse nii kehtiv kui tulevane perenimi

Joonis 3 Taotlemise põhjus – ainult üks kirjutuskaitstud valik

7.3 ETK-EKPID liidestus GOVSSOga

Selleks, et kasutaja saaks mugavalt liikuda RR ja PPA keskkondade vahel tuleb PPA ETK-EKPID

liidestada GOVSSOga. Lähtuda tingimustest:

https://e-gov.github.io/GOVSSO/

https://www.ria.ee/tara-ja-govsso-liitumistingimused-ja-dokumendid-alates-1-martsist-2025

7.4 ETK-EKPID liidestus RRiga ITD taotluse koostamiseks

Peatükis kirjeldatakse ITD taotluse loomiseks vajalikku X-tee andmevahetust RR ja ETK-EKPID

vahel.

RR poolt ETK-EKPID-le edastatavate andmete kasutamisel ETK-EKPID poolt on kirjeldatud X-

tee sõnumivahetusest (eventService = NIMEVAHETUS). Kuna aga ETK-EKPID plaanitav

funktsionaalsus eeldab teavet Kasutaja tulevase nime kohta (et kuvada seda talle ITD taotlusel)

ja sündmuse (abiellumine või lahutus, nimevahetus) plaanitud kuupäeva kohta (et saata

sündmuse lähenedes Kasutajale meeldetuletus juhul kui on puudusi biomeetria osas), siis on

siinkohal vastav info sõnumitele lisatud.

Alljärgnevas tabelis ja vooskeemil on kirjeldatud eventService = NIMEVAHETUS.

eventService = NIMEVAHETUS event ETK-EKPID BE protsess

NIMEVAHETUS_PLANEERITUD Uue andmekomplekti muutmine

NIMEVAHETUS_TYHISTATUD Tühistamine

NIMEVAHETUS_PLANEERITUD Muudatus

Sündmusteenuse ITD taotlus

page 10/22

eventService = NIMEVAHETUS event ETK-EKPID BE protsess

NIMEVAHETUS_EDUKAS Lõpetamine

NB! Kirjeldatud andmevoole eelneb abiellumise sündmus, kuid eeldatavasti on lahutuse

sündmusteenuse nimevahetuse protsessi sõnumid täpselt samasugused, seetõttu ETK-EKPID

BE seisukohalt ei ole vahet, mis sündmus ITD taotluse aluseks on.

Sama funktsionaalsust saab laiendada ka muule nimevahetusele kui abiellumisest/lahutusest

tulenev, nimevahetuse protsessi sõnumitele lisatakse vajadusel ka uus eesnimi.

7.4.1 ETK EKPID BE – Uue andmekomplekti muutmine

Märgistus on eelduseks, et Kasutajal tekib võimalus sündmusteenuse raames ITD taotlemiseks.

Uus andmekomplekt luuakse RR saadetud X-tee sõnumi (eventService = NIMEVAHETUS) alusel,

kus „event“ = „NIMEVAHETUS_PLANEERITUD“.

Sündmusteenuse ITD taotlus

page 11/22

Uus andmekomplekt luuakse RR poolt saadetud X-tee nimevahetuse sõnumi alusel, kus „event“

= „NIMEVAHETUS_PLANEERITUD“.

Nime vahetamisega seotud sõnumid (eventService = NIMEVAHETUS).

Allolevas tabelis kirjeldatakse ITD taotluse loomiseks vajalikku X-tee andmevahetust RR ja PPA

rakenduse vahel. ITD taotlusega seotud sõnumid on ühised nii abielu registreerimisel kui

lahutamisel.

Sõnumid saadab RR teenus PPA ITD sündmusteenusega seotud rakendusele ETK-EKPID BE.

Sõnumi väljadega seoses võib tulla muutusi.

Sõnumi

väli

Kirjeldus Tüüp Näide Valideerimine Kohustu

slik

id Sõnumi unikaalne

identifikaator

guid 77b350ea-

a5b7-523e-

3242-

de42334cbf24

Jah

subjectCo

de

Nime muutnud

Kasutaja isikukood

isikukood EE380010857

18

Vastab Eesti

isikukoodi

standardile.

Jah

processId EAvaldus olemi väli

EAID, mis on

konverteeritud

UUID formaati.

guid 96b450fa-

2057-421b-

9737-

de42134cb814

Jah

parentProc

essID

Toimiku TKID,

mis on

konverteeritud

UUID formaati.

guid 7ab45ofa-

2ae7-0k1b-

9p27-

Ei

Sündmusteenuse ITD taotlus

page 12/22

Sõnumi

väli

Kirjeldus Tüüp Näide Valideerimine Kohustu

slik

sda2764cb9

1a

data.applic

ationType

Avalduse liik enum|string ABIELU,

LAHUTUS,

NIMEMUUTU

S

Jah

Event Nime muutmisega

seotud sündmus

enum|string NIMEVAHETU

S_PLANEERI

TUD

NIMEVAHETU

S_EDUKAS

NIMEVAHETU

S_TYHISTAT

UD

Jah

eventTime

Sõnumi sündmuse

aeg

datetime

2024-12-

20T00:00:00Z

Ei saa olla tulevikus

Jah

data.newL

astName

Uus perenimi string | null Murakas Isiku soovitud uus

perenimi. Välja ei

väärtustata, kui

perenime ei

muudeta

Ei

data.newFi

rstName

Uus eesnimi string | null Gustav Isiku soovitud uus

eesnimi. Välja ei

väärtustata, kui

eesnime ei

muudeta

Ei

data.name

ChangeSc

heduledAt

Abielu, lahutuse,

nime muutmise

registreerimise aeg

datetime

2024-12-

31T00:00:00Z

Ei saa olla

minevikus.

Isiku nimevahetuse

oodatav kuupäev

Jah

Kui ETK-EKPID BE valideerib saadud info edukalt, salvestab ETK-EKPID BE saadud andmed ja

loob isikule märgistuse. Sellest hetkest võib tuvastatud Kasutaja, kelle kohta selline märgistus

on loodud, endale ETK-EKPID FE-s luua andmekomplekti ITD taotluse automaatseks

esitamiseks tulevikus, kui nimevahetus on RRs jõustunud.

Kui valideerimine ei ole edukas, märgistust ei salvestata ja ETK-EKPID BE tagastab RR-le

veateate.

7.4.2 ETK-EKPID BE – Andmekomplekti elutsükkel ja staatused

Andmekomplektid võivad olla järgmistes staatustes:

Sündmusteenuse ITD taotlus

page 13/22

Märgistus – ETK-EKPID BE-s on RR-lt saadud andmete põhjal salvestatud andmekomplekt,

kuid Kasutaja ei ole veel sellele tehtud täiendusi salvestanud.

Maksmata – Kasutaja on täiendatud andmetega andmekomplekti salvestanud, kuid ei ole

maksnud riigilõivu.

Makstud – Kasutaja on täiendatud andmetega andmekomplekti salvestanud ja maksnud ka

riigilõivu.

Tühistatud – ETK-EKPID BE on RR-lt saanud sõnumi plaanitud nimemuutmise tühistamise

kohta.

Lõpetatud – ETK-EKPID BE on RR-lt saanud sõnumi, et nimemuutus on jõustunud. Kui

eelnev staatus oli Makstud, siis luuakse andmekomplekti põhjal UUSISes ITD-taotlus,

edasine käsitlemine UUSISes. Andmekomplekti käsitlemine ETK-EKPID BE-s on lõpetatud.

Lõpetatud ja Tühistatud staatuses andmekomplektid liiguvad UUSISesse ja kustutatakse

kindlaksmääratud ajavahemiku möödudes ETK-EKPID BE-s.

7.4.3 ETK-EKPID FE – Andmekomplekti täiendamine Kasutaja poolt

Eeltingimuseks on Kasutajale loodud märgistus (vt. ETK-EKPID BE – Uue andmekomplekti

muutmine)

Kasutaja täidab ETK-EKPID FE rakenduses ITD taotlemiseks vajalikud andmed ning selle raames

teostatakse äriprotsessi joonisel kujutatud kontrollid. Peale makse teostamist

 salvestatakse andmekomplekt staatuses Makstud

Sündmusteenuse ITD taotlus

page 14/22

 edastatakse X-tee sõnum RIA sündmusteenuste platvormile avalduse esitamise kohta,

kontrollides eelnevalt Kasutaja nõusoleku kehtivust Nõusolekuteenuses (vt. peatükk

ETK-EKPID BE saadetavad sõnumid, „event“=“ITD_AVALDUS_ESITATUD“).

 Taotlus edastatakse application buffrisse

 kasutajale saadetakse application buffrist e-kirjaga kinnitus taotluse esitamise kohta.

7.4.4 ETK-EKPID BE - Muudatused nimevahetusega seotud protsessis

Juba loodud andmekomplekti muutmine on vajalik juhul, kui muutub sündmuse (abielu või

lahutus) plaanitud kuupäev.

Varemalt loodud andmekomplekti (vt. ETK-EKPID BE – Uue andmekomplekti muutmine)

muutmise algatab ETK-EKPID BE-s RR saadetud X-tee sõnum (eventService =

NIMEVAHETUS), kus „event“ = NIMEVAHETUS_PLANEERITUD.

Vt tabel ’Nime vahetamisega seotud sõnumid (eventService = NIMEVAHETUS)’ lk. 11.

Kui ETK-EKPID BE valideerib saadud info edukalt, asendab ETK-EKPID BE andmekomplektis

muudetavad andmed uutega.

Juhul, kui

 muutus sündmuse kuupäev,

 uueks sündmuse kuupäevaks on biomeetria kehtivuse kaotanud ja

 Kasutajale ei ole veel saadetud meeldetuletust biomeetria kehtetuse kohta sündmuse

kuupäeval ja

Sündmusteenuse ITD taotlus

page 15/22

 uue sündmuse kuupäevani jäänud ajavahemik on 14 päeva või lühem

saadetakse kasutajale teavitus biomeetria kehtetuse kohta sündmuse kuupäeval (vt. ETK-

EKPID BE teavitused.)

Kui valideerimine ei ole edukas, salvestatud andmeid ei muudeta ja ETK-EKPID BE tagastab

RR-le veateate.

NB! Kui muutub plaanitud uus nimi, edastab RR sõnumi NIMEVAHETUS_TYHISTATUD ja ETK-

EKPID BE-s käivitub protsess nimevahetuse protsessi tühistamiseks. Seejärel algab

nimevahetusprotsess uuesti RR sõnumiga NIMEVAHETUS_PLANEERITUD.

7.4.5 ETK-EKPID BE - Nimevahetuse protsessi tühistamine

Nimevahetuse protsessis võib RR igal ajal edastada info, et protsess on tühistatud (nt abielu ei

toimunud, Kasutaja/Partner mõtlesid ümber nimevahetuse osas vms).

Sündmusteenuse ITD taotlus

page 16/22

Varemalt loodud andmekomplekti (vt. ETK-EKPID BE – Uue andmekomplekti muutmine)

muutmise algatab ETK-EKPID BE-s RR saadetud X-tee sõnum (eventService =

NIMEVAHETUS), kus „event“ = NIMEVAHETUS_TYHISTATUD.

Vt tabel ’Nime vahetamisega seotud sõnumid (eventService = NIMEVAHETUS)’ lk. 11.

Kui ETK-EKPID BE valideerib saadud info edukalt, saab andmekomplekt staatuse Tühistatud.

Kui andmekomplekti staatus oli eelnevalt Makstud, saadetakse Application buffrisse, kus

menetleja võtab selle menetlusse ja selle lõpetamisel saadetakse UUSISest e-meil kasutajale.

(vt. Teavituste tekstid, T1). Märge saadetud teavituse kohta kuvatakse UUSISe keskkonnas,

menüüpunktis E-kirjad > Saadetud e-kirjad (vt. UUUSIS – E-kirjade menüüpunkti täiendamine).

Kui valideerimine ei ole edukas, andmekomplekti ei tühistata ja ETK-EKPID BE tagastab RR-le

veateate.

7.4.6 ETK-EKPID BE - Nimevahetuse protsessi lõpetamine

Kui nimevahetuse sündmus on toimunud, siis RR teavitab sellest ETK-EKPID.

Sündmusteenuse ITD taotlus

page 17/22

Nimevahetusprostessi lõpetamise aluseks ETK-EKPID BE-s on RR saadetud X-tee sõnum

(eventService = NIMEVAHETUS), kus „event“ = NIMEVAHETUS_EDUKAS.

Vt tabel ’Nime vahetamisega seotud sõnumid (eventService = NIMEVAHETUS)’ lk. 11.

Kui ETK-EKPID BE valideerib saadud info edukalt, saab andmekomplekt staatuse Lõpetatud.

 Maksmata staatuse puhul protsess lõpeb. Kui Kasutaja soovib uue nimega dokumente,

saab ta neid nüüd taotleda tavapärases korras.

 Kui andmekomplekti eelmine staatus oli Makstud, siis luuakse andmekomplekti alusel

ITD taotlus Application buffer-is ja see on kättesaadav PPA ametnikule menetlemiseks

tavapärases korras (vt. Application bufferis andmekomplektide kuvamine.)

Sündmusteenuse ITD taotlus

page 18/22

Kui valideerimine ei ole edukas, tagastab ETK-EKPID BE RR-le veateate.

7.5 ETK-EKPID-st andmete liikumine application bufferisse ja UUSISesse.

Liidestuse eesmärgiks on tagada andmekomplektide liikumine ETK-EKPID-st menetlussüsteemi.

Andmekomplektide, mis ETK-EKPID BE-s on saanud Lõpetatud või Tühistatud staatuse, põhjal

luuakse ITD taotluse andmekomplekt Application bufferis, mille menetlemine Uusises toimub

seejärel samamoodi PPA iseteenindusest Application bufferisse jõudnud ITD

andmekomplektidega.

7.6 UUSISe arendused

Arendused hõlmavad muudatusi UUSISes ja application bufferis, et kuvada ametnikule

korrektselt andmekomplekte, mille alusel on võimalik luua ITD taotlused ning teavitustega

seotud arendusi.

7.6.1 Application bufferis andmekomplektide kuvamine

Eeltingimuseks on ETK-EKPID BE-s salvestatud, Lõpetatud staatuses andmekomplekt (st.

sündmusteenusega seotud protsess on jõudnud etappi, kus Kasutaja nimevahetus on jõustunud

või tühistatud ja RR on sellest ETK-EKPID BE-i teavitanud – vt ETK-EKPID BE - Nimevahetuse

protsessi lõpetamine).

Kuna nimevahetuse protsessi lõpetamisel ETK-EKPID BE-s luuakse andmekomplekt ka

Application bufferis, siis sellest hetkest on see kättesaadav menetlemiseks PPA ametnikule.

PPA ametnik näeb Application bufferisse salvestatud andmekomplekte UUSISe menüüpunktis,

Isikutuvastamine > ETK puhver.

Arenduse käigus tuleb kasutajaliideses teha järgmised täiendused:

1) Sündmusteenuse raames loodud andmekomplektid peavad olema teistest eristatavad

ikooniga mis kuvatakse nupu Isikutuvastamine kõrval (joonisel tähistatud Tegelik

ikoon kujundada kooskõlas PPA dokumendiserveri disainipõhimõtetega).

2) Taotlemise põhjus filtrisse lisada valik ANDMED MUUTUNUD - NIMEMUUDATUS. Kui

ametnik valib selle filtri väärtuse, kuvatakse ekraanil ainult sündmusteenuse raames

loodud andmekomplektid. (NB! Seda taotlemise põhjust ei lisata PPA iseteeninduse

dokumenditaotluse vormidele. Ka ETK-EKPID FE dokumenditaotluste vormidel (vt ETK-

EKPID FE – Uue andmekomplekti muutmine) kuvatakse põhjusena ANDMED

MUUTUNUD, EBAÕIGED mis asendatakse uue väärtusega andmekomplekti

salvestamisel Uusises.)

Sündmusteenuse ITD taotlus

page 19/22

7.7 Teavitustega seotud arendused

7.7.1 ETK-EKPID BE teavitused

ETK-EKPID BE peab saatma Kasutajale e-kirja teel teavitusi juhul kui 14 päeva enne plaanitud

nimevahetuse sündmust (nt. abiellumine) ei ole Kasutajal antud kehtivat biomeetriat või aegub

biomeetria kehtivus enne sündmust. Teavituse sisu täpsustub arenduste alguseks.

7.7.2 UUSIS teavitused

UUSISesse tuleb lisada e-kirja teel saadetavad teavitused juhuks, kui peale

nimevahetusprotsessi lõpetamist ETK-EKPID BE-s luuakse Application bufferisse puuduliku

biomeetriaga andmekomplekt ja PPA ametnik seda menetlema asub (vt Puuduste teatiste

täiendamine).

Makstud staatuses andmekomplekt tühistatakse ja tehakse menetluse lõpetamise otsus.

7.7.3 Teavituste tekstid

Puuduste teatiste täiendamine. Puuduste teatiste saatja on UUSIS.

Teavituse tekst Saatja

1. Teie taotluse juurest puudub foto. Kõige mugavam on foto

teha Politsei- ja Piirivalveameti teeninduses asuvas

digikioskis. Teeninduste asukohad leiate siit:

https://politsei.ee/et/asukohad/teenindused

UUSIS

2. Teie taotluse juurest puuduvad foto ja sõrmejäljed. Kõige

mugavam on foto teha ja sõrmejäljed anda Politsei- ja

Piirivalveameti teeninduses asuvas digikioskis. Teeninduste

asukohad leiate siit:

https://politsei.ee/et/asukohad/teenindused

UUSIS

3. Teie taotluse juurest puuduvad foto, sõrmejäljed ja

allkirjanäidis. Kõige mugavam on foto teha ning sõrmejäljed

ja allkirjanäidis anda Politsei- ja Piirivalveameti teeninduses

asuvas digikioskis. Teeninduste asukohad leiate siit:

https://politsei.ee/et/asukohad/teenindused

UUSIS

7.7.4 UUSIS – E-kirjade menüüpunkti täiendamine

Järgmised täiendused on vajalikud menüüpunktis E-kirjad > Saadetud e-kirjad.

Sündmusteenuse ITD taotlus

page 20/22

Võimaldada otsing isikukoodi järgi. Hetkel on võimalik Uusises e-kirjade menüüpunktis otsida

saadetud teavitusi dokumendi numbri järgi. Tuleb lisada funktsionaalsus, et saaks otsida ka

isikukoodi järgi ning siis kuvatakse vastuseks kõik teavitused, mis on süsteemi (UUSISe või

mõne teise rakenduse) poolt saadetud selle isikuga seotud dokumentide kohta.

E-kirjade loend kuvatakse ekraanile ainult juhtudel, kui

1) täidetud on väli Dokumendi number (kuvatakse ainult selle numbriga dokumendiga

seoses saadetud kirjad);

2) täidetud on väli Isikukood (kuvatakse ainult selle isikukoodiga isikule saadetud kirjad);

3) täidetud on nii väli Dokumendi number kui ka väli Isikukood (kuvatakse nii dokumendi

numbriga seoses saadetud kirjad kui ka kirjad selle isikukoodiga isikule).

ETK-EKPID BE-st saadetud e-kirjade lisamine UUSIS-e loendisse. UUSIS-es tuleb kuvada ka

ETK-EKPID BE-st ja application bufferist saadetud teavitused.

7.8 ETK-EKPID ja Uusis liidestus nõusolekuteenusega (RIA)

ETK-EKPID BE ja Uusise liidestumine nõusolekuteenusega on eelduseks ITD taotluse

menetluse seisu kohta info saatmiseks RIA Sündmusteenuste platvormile.

Sõnumite saatmise aeg ja taotluste staatuse seosed selguvad arendustööde alguseks.

Rahvastikuregistri ja PPA vaheline andmevahetus pole nõusolekuteenuse õigustega piiratud.

Rohkem infot:

https://www.ria.ee/riigi-infosusteem/inimkeskne-andmehaldus/nousolekuteenus.

7.9 ETK-EKPID ja Uusis liidestus RIA Sündmusteenuste platvormiga

RIA Sündmusteenuste platvormile tuleb PPA poolt edastada sündmusteenusega seotud ITD

taotluse menetluse seisu kohta info menetluse erinevatel etappidel (alati enne kontrollides

Kasutaja nõusoleku kehtivust nõusolekuteenuse kaudu).

Testkeskkonnas on sündmusteenuse kirjeldus nähtav järgnevalt x-tee kataloogi lingilt:

https://x-tee.ee/catalogue/ee-test/GOV/70006317/sun-life-events

7.9.1 ETK-EKPID BE saadetavad sõnumid:

1) Kasutaja on ETK-EKPID FE-s esitanud isikut tõendavate dokumentide taotluse, see on

saanud staatuse Makstud (sõnum saadetase “event” väärtusega

Sündmusteenuse ITD taotlus

page 21/22

“ITD_AVALDUS_ESITATUD”), vt ETK-EKPID FE – Andmekomplekti täiendamine

Kasutaja poolt;

2) Nimevahetusprotsess on tühistatud peale seda, kui Kasutaja poolt ETK-EKPID FE-s

esitatud taotlus sai staatuse Makstud (“event” : “ITD_AVALDUS_TYHISTATUD”) vt

ETK-EKPID BE – Nimevahetuse protsessi tühistamine.

7.9.2 Uusise saadetavad sõnumid

1) Dokumendid on PPA-s kättesaamiseks valmis (“event” : ”ITD _VALMIS”);

2) Dokumendid on taotlejale väljastatud (“event” : ”ITD_KATTE_TOIMETATUD”);

3) Taotleja ei ole ettenähtud ajavahemiku jooksul enda isikuttõendavatele dokumentidele

järele tulnud ja need on hävitatud (“event”: “ITD_HAVITATUD”).

Sõnumi struktuur täpsustub arenduste alguseks, allpool toodud näide.

7.9.3 Sõnumistruktuur Element Sisu

personCode Isikukood

processId Nimevahetusprotsessi ID

parentProcessID Abiellumise (või lahutuse) protsessi ID (kui on

olemas).

event Sõnumi sisu (saatmise põhjus), üks järgnevast:

ITD_AVALDUS_ESITATUD

ITD_AVALDUS_TYHISTATUD

ITD_VALMIS

ITD_KATTE_TOIMETATUD

ITD_HAVITATUD

eventDateTime “event”–sündmuse kuupäev ja kellaaeg

8 Projekti tulem ja etapid

Tööde järjekord on vaba ja vahetähtaegasid ei ole. Kõik etapid peavad olema Tellija poolt

testitud. Siiski on soovituslik lähtuda allolevast tööde järjekorrast.

2025. aasta oktoobri lõpuks peavad olema valmis arendused 1.- 8. etapile testkeskkonnas:

1. ETK-EKPID BE-i ja ETK-EKPID FE arendustööd - 20%

a. ETK-EKPID frontend raamistiku üle viimine Vue-2lt Vue3-le

b. ETK-EKPID BE nõuded ja funktsionaalsus on kirjeldatud peatükis ’ETK-EKPID

BE muutmine'

Sündmusteenuse ITD taotlus

page 22/22

c. ETK-EKPID FE nõuded ja funktsionaalsus on kirjeldatud peatükis ‘ETK-EKPID

FE muutmine’

d. automaatsed teavitused (ETK-EKPID BE) biomeetria aegumise kohta.

2. ETK-EKPID liidestus GOVSSOga - 5%

3. ETK-EKPID liidestus RRiga ITD taotluse koostamiseks - 10%

4. ETK-EKPID-st andmete liikumine application bufferisse ja UUSIS-sse - 5%

5. UUSISe ja application bufferi arendused - 20%

a. Andmekomplektide kuvamine (application buffer) ametnikele peale

nimevahetuse toimumist.

b. Teavitused Kaustajale (UUSIS) e-kirjade abil vajaliku info edastamine

menetlussüsteemist

6. STE backendi loomine - 10%

7. ETK-EKPID ja Uusise liidestus nõusolekuteenusega (RIA) - 5%

8. ETK-EKPID ja UUSISe liidestus RIA Sündmusteenuste platvormiga - 5%

9. November-detsember 2025 (turvatesti leidude parandused jm täiendavad arendused).

Jaanuar-märts 2026 (live ja live’i järgsed arendustööd). Live’i täpsem ajakava täpsustub

detsembris 2025 - 20%.

Lisa 2 Nõuded arendusele Väljavõte SMITi nõuetest arendusele, mis on olulised käesoleva hanke skoobist lähtuvalt.

Üldnõuded

Kohustuslik:

1. Rakendused luuakse põhimõttel, kus ühte paigaldatavasse komponenti ei panda kokku

sisult väga erinevat funktsionaalsust, vaid pigem jaotatakse vajadusel erinevate

komponentide vahel. Komponentideks jaotamine toimub sisulistest, mitte tehnilistest

funktsionaalsustest lähtudes v.a kasutajaliideste eraldamine eraldi rakendusteks. (vt.

Bounded Context)

2. Komponent peab jooksma vähemalt 2 instantsi peal, et vältida platvormi muudatuste käigus

tekkida võivaid katkestusi.

3. Rakendust ehitatakse ja pakendatakse SMIT CI/CD lahendusega (Bamboo) ning

komponendile kohandatakse automaatset staatilise koodi analüüsi vastavalt SonarQube

profiilile, mille tulemused on kättesaadavad SMIT SonarQube keskkonnast. Lähtekood

peab pull-requesti kaudu läbima SonarQube Quality Gate-i, enne koodi põhiharusse

mergeda ei saa. Täpsemalt dokumendi lõpus „Tehnoloogilise võla mõõtmine (SonarQube)“

(Rakendust ehitatakse ja pakendatakse SMIT CI/CD lahendusega (Bamboo) ning

komponendile kohandatakse automaatset staatilise koodi analüüsi vastavalt SonarQube

profiilile, mille tulemused on kättesaadavad SMIT SonarQube keskkonnast. Lähtekood ei

tohi sisaldada vigu mis on analüsaatori poolt leitud.)

4. Lähtekood on UTF-8 formaadis ning tekstilised väärtused tuleb liigutada tõlkefailidesse

(i8n), lisaks mitte kasutada Deprecated meetodeid.

5. Rakenduse lähtekood on kirjutatud selgusega, mis võimaldab erialast ettevalmistust

omaval tarkvaraarendajal süsteemi edasi arendada. (Rakenduse lähtekood ja kommentaarid

peavad olema inglise keeles.)

6. Rakenduse lähtekoodi haldus toimib SMITi kesksete versioonihalduspõhimõtete järgi.

7. Keskkondadesse rakenduste paigaldamine on automatiseeritud SMIT CI/CD

mehhanismidega (Bamboo paigaldusplaanid).

8. Kokku ehitatatud rakendust peab saama paigaldada erinevatesse keskkondadesse, ilma et

seda peaks uuesti kokku ehitama. (Konfiguratsioon määratakse keskkonna muutujatena või

muude rakenduseväliste võimalustega (näiteks Kubernetes configmap).

9. Auditlogi tuleb markeerida ära logikirjetes, et oleks pärast otsingus eristatav.

10. Rakendustel puudub ligipääs avalikku internetti (sh klientidel). Kui on vajalik ligipääs

äriandmetele väljaspool SMIT võrku, tuleb tellida webproxy ligipääs.

11. Rakenduste sõltuvuste (maven,npm jne) allikana tuleb kasutada SMIT sisest keskset

repositooriumi (Artifactory).

12. Kõik välised sõltuvused tuleb rakenduse ehitamisprotsessikäigus läbi skaneerida

Artifactory Xray töövahendiga ja mitte kasutada kõrge kriitilisusega turvanõrkuseid

sisaldavaid teeke/komponente.

13. Kasutajaliidese sõltuvused/osad nagu JS,CSS,FONTS,GIF jms, mida kasutatakse

kasutajaliidese kuvamisel, peavad rakenduse käivitusel tulema samast allikast. (Väliste

sõltuvuste ja repode kasutamine ei ole lubatud (nagu välised cdn-id, google fonts, github

jne). Arendamisel tuleb kontrollida browseri võrguliikluse lehelt, et välisperimeetrisse ei

mindaks päringuid tegema.)

14. Väliste teenuste nagu ReCaptcha, Google Analytics jms kasutamine ei ole lubatud.

15. Rakenduse arhitektuuri koostamisel tuleks arvestada, et rakenduse koosseisu kuuluvaid

komponente peab saama uuendada iseseisvalt.

16. Rakenduse loogikakomponentide üldine sisemine arhitektuur peaks järgima MVC mustrit.

17. Rakendustevahelisi integratsioone teostatakse kokkulepitud põhimõtete järgi (võimalikud

variandid on XTEE, HTTP otse või MQ).

18. Kui loodav lahendus koosneb mitmest komponendist, on need lahus arendatavad,

pakendatavad, versioneeritavad ja paigaldatavad.

19. Rakendus on versioneeritud kasutades semantilise versioneerimise põhimõtet.

20. Toodangu keskkondades on rakendused on automaatselt monitooritud.

Testitavus

Kohustuslik:

21. Komponendil on olemas minimaalne genereeritav testandmete komplekt.

22. Test- ja toodangukeskkonnad peavad olema üksteisest lahus ning testandmed ei tohi olla

toodanguandmed (v.a juhul kui tegemist ei ole avalike andmetega - näiteks aadressid).

23. Loogikakomponendil on olemas integratsioonitestid veebiteenuste või

sõnumivahetusteenuste jaoks ning vajadusel täiendavad ühiktestid spetsiiflise äriloogika

valideerimiseks.

24. Kasutajaliidese automaattestide kirjutamine, mis simuleerivad kasutaja käitumist

põhivoogude taseme, on arendusmeeskonna otsustada.

25. Rakenduse automaattestide mahtu tuleb analüüsida CI/CD mehhanismide abil ning

tulemused peab publitseerima SMIT SonarQube keskkonnas.

26. Avaklikke teenuseid tuleb täiendavalt turvatestida.

27. Rakenduste poolt toodetavale logi väljundile tuleb kirjutada automaattestid.

Kasutajaliides

Kohustuslik:

28. Kasutajaliides tuleb täielikult eraldi arendada loogikakomponendist ning ei eelda selle

implementatsiooni olemasolu.

29. Kasutajaliides võib korraga suhelda mitme loogikakomponendiga.

30. Kasutajaliides ja loogikakomponent suhtelvad omavahel üle HTTP/WEBSOCKET

protokolli ning ainult läbi eeldefineeritud liidestuse (vahetatakse ainult andmeid).

31. Kasutajaliidese olekut hoitakse kliendi poolel.

32. Kasutajaliides vahetab loogikakomponendiga ainult andmeid, visuaalset sisu (nn. html-i

javascripti) sellest komponendist ei laeta.

33. Kasutajaliides suhtleb loogikakomponentidega üle SSL kanali (SSL termineeritakse

koormusjaoturis, kust kõik kasutaja päringud läbi lastakse).

34. Kasutajaliides on soovitav arendada õhukese kliendina.

35. Avalikud kasutajaliidesed peavad vajadusel järgima VEERA disainistandardit ning omama

WCAG tuge.

Äriloogika ja õigused

Kohustuslik:

36. Komponentide vaheline andmevahetus peab olema turvaline või kaitstud kasutades TLS-i,

mille sertifikaate verifitseeritakse. Autentimata ja/või krüpteerimata protokollide

kasutamisel rakendatakse täiendavaid konfidentsiaalsust ja terviklust tagavaid

turvameetmeid.

37. Nii sisemised kui välimised süsteemid peavad kasutaja tuvastamiseks kasutama SMIT

kesksest tuvastamise teenust (UAA).

38. Kasutajaid ja nende grupi või rollipõhiseid õiguseid tuvastatakse kesksest Active Directory

andmebaasist. Andmetepõhised õigused (ACL) asuvad rakenduse juures andmebaasis.

39. Komponendid suhtlevad omavahel ainult üle HTTP või JMS/AMPQ protokolli. Suurema

jõudluse ja sõltumatuse saavutamiseks on eelistatud sõnumivahetus.

40. Kasutaja sessiooni hoidmiseks ei kasutata mälus olevat sessiooni, vaid iga päringuga

valideeritakse päringu teostaja "tokeni" kehtivust. Tokenile vastav kasutaja info peab

asuma keskses hoidlas, mis peab välistama mitmekordse sisselogimise ja aeguma vastavalt

kokkulepitud nõutele.

41. Komponendid peavad ka omavahel saama autoriseerituna (kasutades tokenit) andmeid

vahetada analoogselt kasutajaliidesele ilma sessioone tekitamata.

42. Komponentide omavahelises integratsioonis peab iga komponent omama oma kontot, ei

tohi taaskasutada kontosid, mis on väljastatud teistele rakendustele.

43. Igal komponendil on oma andmebaas mille skeemi ja süsteemsete andmete muudatusi

hallatakse komponendiga koos, kui komponent vajab andmete salvestamise võimekust.

44. Komponendi versiooniuuendusi teostatakse reeglina ilma katkestusteta teenuse töös

(tehakse nn. instantsi haaval), andmebaasi muudatuste tegemisel tuleb tagada, et muudatus

töötaks ka eelmise komponentide versioonidega (kohustuslike väljade mitmeetapiline

sisseviimine jms)

45. Komponent käivitub ka ilma ühenduseta liidestetavate süsteemidega ehk on nn. nõrgalt

liidestatud (v.a andmebaasid)

46. Komponent töötab osaliselt edasi ka liidestuste katkestuste puhul ja taastab töö peale

katkestuste lõppemist. Stateful ühendused nagu AMPQ peavad automaatselt

taastama oma ühendused.

47. Komponendil puudub eraldi väline konfiguratsioonifail - vajalik konfiguratsioon

määratakse kas keskkonna muutujatena või kasutatakse muid platvormi pakutavaid

võimalusi (Kubernetese secrets/configmap näiteks).

48. Suurte koormuste teenindamiseks vähemuutuvate andmete puhul kasutatakse

rakendusserveris vajadusel vähemälusid mis on kesksed, kiired, kõrgkäideldavad ning ei

sõltu konkreetse rakendusserveri instantsist. Ei kasuta mitte cachede replitseerimist vaid

distributeeritud lahendust.

49. Komponendil on tööks kõik vajalikud teegid kaasa pakendatud, allolevast

operatsioonisüsteemis mingite teekide olemasolu eeldada ei tohi.

50. Komponent on olekuta ehk kõik mis vaja hoida kauem kui üks süsteemiväline päring

(request), salvestatakse kas andmebaasi või mõnda teise hoidlasse.

51. Komponent ei tohi eeldada failisüsteemi olemasolu, kus andmed säilitatakse. Mälus võib

hoida ühe päringu sees opereeritavate andmete olekuid või andmebaasist taasloodavaid

cachesid.

52. Talletamiseks mõeldud binaarfailide jaoks tuleb kasutada eraldi failide hoidmise teenust,

mis pakub vastavat veebipõhist teenust.

53. Komponentide poolt publitseeritavad REST teenused on versioneeritud, dokumenteeritud

ning veahaldust tuleb teostada HTTP veakoodidega. Teenused on peavad olema

dokumenteeritud OpenAPI spetsifikatsioonile vastavalt ning spetsifikatsioon peab olema

vajadusel eraldi kättesaadav kolmandatale osapooltele.

54. URL ei tohi sisaldada isikuandmeid või sessioonivõtit.

Andmebaas

Kohustuslik:

55. Andmebaasi ühenduse probleemide puhul tuleb andmete muutmise/lugemise

päringutele rakendada kordust (kirjutamisel vähemalt 30s), et päringud õnnestuks,

kui baasi funktsionaalsus taastub.

56. Andmebaaside vahelised integratsioonid ei ole lubatud.

57. Andmebaase komponentide integratsioonivahendina ei tohi kasutada (mitu erinevat

komponenti ühe andmebaasi poole pöörduda ei ole lubatud).

58. Andmeobjektide muutmisel tuleb luua ka migratsiooniskriptid mis teisendavad

automaatselt olemasolevad andmed uuele kujule. Migratsiooniskripte on soovitav käivitada

paigaldusprotsessi ühe osana ja mitte määrata neid käivitatavaks iga rakenduse restardiga

(see võib tekitada ebavajalikke lukke rakenduste restartimisel, kui neid on mitu instantsi)

59. Andmebaasi äriloogikat vaikimisi ei kirjutata (protseduurid ja triggerid).

60. Andmebaasi pöördutakse ainult rakenduse jaoks eraldatud süsteemsete kasutajatena.

61. Operatiiv- ja arhiivi andmebaasid on eraldi lahendused, kasutatakse kas eraldi arhiivibaase

või mõnda muud spetsiaallahendust.

62. Tekstiotsingute jaoks kasutatakse ainult täisteksti indekseid (Lucene või andmebaasi

sisemine täistekstiotsing).

63. Objektid identifitseerida registrikoodide abil.

Jõudlus

Kohustuslik:

64. Komponendi sisemised alamosad suhtlevad omavahel võimalusel sõnumivahetuse või

muude asünkroonsete meetodite abil, et välistada blokeeruvaid lõimesid ja tagada et iga

alamtöö töötab eraldi lõimes, kasutades efektiivselt virtuaalmasinate mitut

protsessorituuma - see soovitus ei kehti kui komponentide suhtlus peab toimuma ühe

kasutaja transaktsiooni sees (mitte segamini ajada andmebaasi transaktsiooniga).

Andmebaaside vahelised integratsioonid ei ole lubatud.

65. Pikalt töötavad operatsioonid tuleb viia eraldi taustaprotsessideks, mis toimivad ka mitmete

instantside puhul, ehk taustatööde info peab olema salvestatud.

66. Komponent peab peatumisel lõpetama käimasolevad protessid ning pikad taustaprotsessid

peavad pooleli jääma ja käimasolev töö tuleb tagastada tööde nimekirja (näiteks "queue").

67. Komponendis loodud protsessid peavad arvestama, et võib toimuda ootamatu rakenduse

seiskumine ning selle tulemusel peavad samuti käimasolevad tööd minema järjekorda

tagasi.

68. Jõudluse kasvamisel saab automaatselt komponentide instantside hulka tõsta

(horisontaalne skaleerimine) ning koormus jaotatakse instantside vahel laiali.

69. Komponent peaks käima minema (olema valmis esimeste päringut teenindamiseks) kuni

60 sekundi jooksul.

Monitooritavus

Kohustuslik:

70. Komponentide poolt publitseeritavad teenuste monitoorimiseks vajalik info on kättesaadav

kokkulepitud formaadis ja protokolliga - soovitavalt REST formaadis.

71. Komponenti on võimalik monitoorida APM tarkvara agendiga, mis oskab komponendi

seest kõikide lähtekoodis realiseeritud protsesside kohta statistikat (sh. kasutamise sagedus,

töötluse aeg) väljastada.

72. Komponent logib enamus tegevused erinevatel tasemetel ning suunab need "stdouti" või

sõnumitena sõnumiserverisse (auditlogi). Komponent ei tegele logifailide haldamisega.

Failihaldus

Kohustuslik:

73. Kui teenus võtab vastu faili, siis tuleb seda skaneerida ennem baasi või objektihoidlasse

salvestamist. Kasutada tuleb SMIT-i poolt pakutavat MetaVault teenust.

Logimine

Kohustuslik:

74. Erindite (Exception) kinnipüüdmisel tuleb logisse salvestada kogu stacktrace, mitte ainult

veateade.

75. Logimisel tuleb arvesse võtta Infoturbeosakonna poolt kehtestatud logimise nõudeid.

76. Rakenduse tehnilised komponendid logivad korrelatsiooni ID'd või genereerivad selle ise.

Korrelatsiooni ID'd saadetakse iga edasise päringuga kaasa.

77. Logi peab olema JSON formaadis.

1 / 2

Koostatud 14.02.2025 01:25:30 https://riigihanked.riik.ee/rhr-web/#/procurement/8442964/general-info

VASTAVUSTINGIMUSED Viitenumber: 290917 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: ITDAK liidestumine sündmusteenusega

PAKKUMUSE ESITAMINE Pakkumuse esitamisega kinnitab pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist.

Tingimusliku pakkumuse esitamine ei ole lubatud.

Küsimused ettevõtjale: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei")

2. Kinnitame, et käesolev pakkumus on jõus 3 kuud ja on esitatud tingimustel pakkujale siduv, alates pakkumuste esitamise tähtpäevast (Raadionupp valikutega "Jah/Ei")

3. Andmed lepingusse, mida kasutatakse juhul, kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. ettevõtte Nimi, reg.kood, aadress; 2. lepingu allkirjastaja nimi; 3. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vm); 4. lepingu allkirjastaja ametinimetus; 5. pakkuja kontaktisik lepingu täitmisel (nimi, ametinimetus, telefoni number ja e-posti aadress) (Suur sisestusala (max pikkus 4000 tähemärki))

4. Kas pakkujal on isikuid, kellel on volitus ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, ning kelle olemasolu ei kajastu äriregistris? Kui jah, esitab pakkuja eelpool nimetatud isikute ees- ja perekonnanime, isikukoodi ning esinduse aluse, et hankija saaks nende puhul viia läbi kõrvaldamise aluste kontrolli vastavalt RHS § 95 lg 1 p 1- 3 ja 5. (Suur sisestusala (max pikkus 4000 tähemärki))

5. Pakkuja kinnitab, et on teadlik, et ta peab esitama hankelepingu täitmise alustamise ajaks iga oma alltöövõtja nime, registrikoodi, kontaktandmed, teabe nende seaduslike esindajate kohta ning alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa. Samad andmed esitab täitja iga hankelepingu täitmisel lisanduva alltöövõtja kohta (Raadionupp valikutega "Jah/Ei")

ÄRISALADUS Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks.

Teabe ärisaladuseks määramisel lähtutakse ebaausa konkurentsi takistamise ja ärisaladuse kaitse seaduse § 5 lõikes 2 sätestatust. Pakkuja ei või ärisaladusena märkida: 1) pakkumuse maksumust ega osamaksumusi; 2) teenuste hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid; 3) asjade ja ehitustööde hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid (RHS § 46 (1)).

Küsimused ettevõtjale: 1. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki))

2. Kas ärisaladus ning selle määramise põhjendus on pakkumuses märgitud? (Raadionupp valikutega "Jah/Ei")

EL NÕUKOGU SANKTSIOON. ALLTÖÖVÕTJAD JA TARNIJAD. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis;

2 / 2

Koostatud 14.02.2025 01:25:30 https://riigihanked.riik.ee/rhr-web/#/procurement/8442964/general-info

3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. Hankija lükkab tagasi pakkumuse, mille alusel sõlmitav hankeleping oleks RSanS § 7 lg 1 alusel tühine.

Määrust kohaldatakse riigihangetele alates rahvusvahelisest piirmäärast. NÕUKOGU MÄÄRUS (EL) 2022/576, 8. aprill 2022, millega muudetakse määrust (EL) nr 833/2014, mis käsitleb piiravaid meetmeid seoses Venemaa tegevusega, mis destabiliseerib olukorda Ukrainas.

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. (Raadionupp valikutega "Jah/Ei")

SAMAVÄÄRSUS Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud.

Iga viidet, mille hankija teeb riigihanke alusdokumentides mõnele RHS-i § 88 lõikes 2 nimetatud alusele (standardile, tehnilisele tunnustusele, tehnilisele kontrollisüsteemile vms), tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. Iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule, tootmisviisile, märgisele või vastavushindamisasutuse väljastatud katsearuandele või tõendile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“ (RHS § 88 lg-d 5-6, § 89 lg 2, 114 lg-d 5-7). Hankija aktsepteerib objektiivsetel põhjustel muid asjakohaseid tõendeid, kui pakkuja tõendab hankijale vastuvõetaval viisil, et pakutav asi, teenus või ehitustöö vastab konkreetse märgise või hankija esitatud nõuetele, välja arvatud juhul, kui hankija nõutud märgis, samaväärne märgis või konkreetse või samaväärse vastavushindamisasutuse väljastatud katsearuanne või muu tõend on seaduse alusel eelduseks asja, teenuse või ehitustöö pakkumiseks turul (RHS § 114 lg 7).

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud. (Raadionupp valikutega "Jah/Ei")

VÕTMEROLLIS JAVA ARENDAJA (FULL STACK)

Pakkuja esitab võtmerolli täitja CV, kes peab vastama kõigile Java arendaja (full stack) CV vormil toodud nõuetele. Esitatud andmed peavad võimaldama hankijal kontrollida meeskonnaliikme vastavust esitatud nõuetele ja hankija kontrollib tingimuste täitmist eelkõige esitatud andmete alusel. Rolli on lubatud täita ühel isikul. Hankija eelduslik koormus rollile on täistööaeg.

Küsimused ettevõtjale: 1. Pakkuja esitab Java arendaja (full stack) CV (Vabas vormis dokument)

Koostatud 14.02.2025 01:25:52 1 / 1 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8442964/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 290917 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: ITDAK liidestumine sündmusteenusega

Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Osakaaludega Elektroonilist oksjoni kasutatakse: ei

Jrk nr

Nimetus Kirjeldus Tüüp / hindamismeetod

Osakaal Kogus Ühik Pakkuja täidetav

1 Pakkumuse kogumaksumus Pakkumuse kogumaksumus peab sisaldama kõiki tulemi saavutamiseks vajalikke kulusid

Maksumus - vähim on parim

100 jah

Kokku: 100

Hindamismetoodika kirjeldus 1.   Pakkumuse kogumaksumus

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".

1 / 1

Koostatud 14.02.2025 01:25:05 https://riigihanked.riik.ee/rhr-web/#/procurement/8442964/general-info

KÕRVALDAMISE ALUSED JA KVALIFITSEERIMISTINGIMUSED Viitenumber: 290917 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: ITDAK liidestumine sündmusteenusega

KÕRVALDAMISE ALUSED

KÕRVALDAMISE ALUSED

Hankija kontrollib edukal pakkujal vastavalt RHS § 30 toodule RHS § 95 lg 1 ja 4 kõrvaldamise aluseid enne lepingu sõlmimist. RHS § 95 lg 1 nimetatud kõrvaldamise aluste kontroll toimub riigihangete registri liidese ja EU Sanctions Map abil. Kui andmed ei ole hankijale päringute kaudu kättesaadavad, siis nõuab hankija edukalt pakkujalt enne hankelepingu sõlmimist kõikide asjakohaste andmete või dokumentide esitamist.

Kehtib: Kõik osad

Küsimused ettevõtjale: 1) Kinnitame, et meil puuduvad riigihangete seaduse § 95 lõikes 1 kirjeldatud kõrvaldamise alused ning saame aru, et kõrvaldamise aluse esinemisel kõrvaldatakse meid minikonkursilt riigihangete seaduse §-s 95 sätestatud korras. (Raadionupp valikutega "Jah/Ei") 2) Kinnitame, et meil puuduvad riigihangete seaduse § 95 lõikes 4 kirjeldatud kõrvaldamise alused ning saame aru, et kõrvaldamise aluse esinemisel kõrvaldatakse meid minikonkursilt riigihangete seaduse §-s 95 sätestatud korras. (Raadionupp valikutega "Jah/Ei")

Siseministeeriumi infotehnoloogia- ja arenduskeskus

Mäealuse 2/2, Tallinn 12618

Telefon 612 6200

E-post [email protected]

Reg. kood 70008440

www.smit.ee

27.02.2025 nr 3-17/143

Pakkumuse esitamise ettepanek minikonkursil raamlepingu nr 3-3/3330 alusel "ITDAK

liidestumine sündmusteenusega" (viitenumber 290917)

1. Üldteave

1.1. Raamleping: reg nr 3-3/3330.

1.2. Hanke eest vastutav isik: Paavo Kirsi ([email protected]).

1.3. Hanke liik: minikonkurss raamlepingu alusel, minikonkursi viitenumber 290917.

1.4. Eeldatav maksumus: 350 000 eurot km-ta.

1.5. CPV kood: 72200000-7.

1.6. Menetluse teostamise viis: e-menetlus eRHR vahendusel.

1.7. Hankelepingu kestus: kuni lepinguliste kohuste täitumiseni (sh ka arve maksmise aeg).

Tööde teostamise aeg kuni 31.03.2026

1.8. Finantseerimisallikas: Euroopa Parlamendi ja nõukogu määruse (EL) 2021/241, millega

luuakse taaste- ja vastupidavusrahastu (edaspidi määrus nr 2021/241), artikli 18 lõike 1 alusel

Euroopa Komisjon 05.10.2021 ning Euroopa Nõukogu 29.10.2021 rakendusotsusega

kinnitatud Eesti taaste- ja vastupidavuskava järgne reform „Eraisikutele sündmusteenuste ja

etteaimavate teenuste väljaarendamine“; ning Vabariigi Valitsuse 29. novembri 2021. a määrus

nr 108 „Taaste- ja vastupidavuskava elluviimise korraldus ja toetuse andmise üldtingimused“

alusel sõlmitud toetuse kasutamise lepinguga. 9S40-RR20-03123RRF

1.9. Pakkumuse esitamise tähtaeg: Pakkumuse esitamise täpne kuupäev ja kellaaeg

sätestatakse hankemenetluse eest vastutava isiku poolt eRHR-s. Hanke eest vastutaval isikul on

õigus muuta pakkumuste esitamise tähtaega ning teha alusdokumentides menetluse käigus

avastatud vajalikke mittesisulisi muudatusi ning parandusi. Pakkujal on õigus vajadusel teha

ettepanek pakkumuse esitamise tähtaja pikendamiseks.

1.10. Pakkumuse jõusoleku tähtaeg: vähemalt 3 kuud alates pakkumuse esitamise

tähtpäevast.

1.11. Hankija ootus huvitatud isikutele on, et pakkujad teavitaks hankijat aegsasti RHR kaudu

riigihanke alusdokumentides avastatud vigade, ebatäpsuste ja ebaselguste parandamiseks ja/või

teeks ettepaneku pakkujate hinnangul riigihanke eseme hankimiseks seatud

ebaproportsionaalsete või põhjendamatute piirangute leevendamiseks.

2(4)

1.12. RHR üldandmetesse/hanketeate lahtris "lepingu täitmise tähtaeg" määratud kuupäev

tähendab lepingu kehtivust, mitte üksnes täitja kohustuste täitmise tähtaega ning lähtub seetõttu

nii täitja kui hankija/maksja kohustuste nõuetekohase täitmise tähtaegadest, sh hõlmatud on ka

hankija arve tasumiseks kuluv aeg. Pakkujal tuleb lepingu sõlmimise korral lähtuda enda

kohustuste tähtaegsel täitmisel lepingu projektis või tehnilises kirjelduses määratud

täitmise/lepingu eseme tarnimise tähtajast.

1.13. Pärast hankelepingu sõlmimist esitab täitja iga oma alltöövõtja nime ja registrikoodi

ning alltöövõtulepingu nimetuse, kuupäeva, numbri ja summa.

2. Minikonkursi dokumendid koosnevad käesolevast dokumendist ning järgmistest

lisadest:

2.1. Lisa 1- Hankelepingu projekt;

2.2. Lisa 2- Tehniline kirjeldus;

2.3. Lisa 2.1 - ITD_Nõuded arendusele;

2.4. Lisa 3 – Vastavustingimused (eRHR vorm);

2.5. Lisa 3.1. CV vorm – Java arendaja full-stack;

2.6. Lisa 4 - Hindamiskriteeriumid ja hinnatavad näitajad (eRHR vorm);

2.7. Lisa 5 - Kõrvaldamise alused (eRHR vorm).

3. Olelusringi kulude arvestamine

3.1. Tegemist on hankijal juba olemas ja kasutuses oleva infosüsteemi arendustöödega.

Lepingu täitmise tulemusel ei teki uut iseseisvat infosüsteemi terviklahendust, mille

käitamine eeldaks märkimisväärsete täiendavate kulutuste tekkimist nt riistvarale või

erinevatele kaudsetele kuludele vmt ning mida saaks arvesse võtta ja lahendada käesoleva

minikonkursi raames. Infosüsteemi käitamisega seotud kulutuste määr on praktikas

üldjoontes välja kujunenud (lähtuvalt sihtotstarbest, kasutusintensiivsusest jpm) ning

tulenevalt hankija asutuse struktuurist ja eelarvestamise süsteemist on infosüsteemide

ülalpidamiskulude katmine lahendatud erinevate kombineeritavate tark- ja riistvaraliste

lahendustega, mida hangitakse teiste hangete kaudu. Lisaks on planeeritud katta suur osa

võimalikest tekkivatest olelusringikuludest hankija oma ressursiga.

4. Minikonkursil osalemise tingimused

4.1. Minikonkursi dokumendid moodustavad ühtse terviku. Dokumendid tehakse täitjatele

tasuta kättesaadavaks eRHR-i keskkonna vahendusel.

4.2. Minikonkursi dokumentide sisu kohta saab hankijalt selgitusi küsida kirjalikul

pöördumisel läbi eRHR-i keskkonna teabevahetuse töölehe. Hankija vastab esitatud

küsimustele esimesel võimalusel, võttes arvesse RHS § 46 lg 1 ja konkreetse

minikonkursi pakkumuste esitamise tähtaega.

5. Pakkumuse vormistamine, esitamine ja muutmine

5.1. Pakkumus tuleb esitada elektrooniliselt eRHR-i kaudu aadressil

https://riigihanked.riik.ee.

5.2. Dokumendid vormistada PDF-vormingus või mõnes muus üldlevinud vormingus.

3(4)

5.3. Kui esitatavate dokumentide koosseisus on kolmanda osapoole poolt kirjalikult

allkirjastatud dokumente, esitada dokument skaneeritud kujul ning originaaldokument

esitada ainult juhul, kui hankijal on tekkinud kahtlus dokumendi osas.

5.4. Samaväärsuse pakkumisel peab pakutav lahendus ühtima hankija olemasolevate

süsteemidega ning toote ja/või teenuse hind peab sisaldama kõiki migreerimisega seotud

lisatasusid. Pakkumus peab vastama esitatud nõuetele või olema sellega vähemalt

samaväärne, kuid ühilduma olemasoleva lahendusega. Samaväärsust tõendavad andmed

ja dokumendid esitab pakkuja koos pakkumusega. Pakkumuse samaväärsust kontrollivad

ja hindavad hankija vastavate erialateadmistega töötajad.

6. Pakkumuste vastavuse kontrollimine

6.1. Pakkumus tunnistatakse vastavaks, kui see vastab kõikidele minikonkursi tingimustele

ning selles ei esine sisulisi kõrvalekaldumisi esitatud tingimustest.

6.2. Pakkumuses esitatud andmed peavad olema tõesed, esitatud viisil ja piisava detailsusega,

mis võimaldavad hankijal kontrollida nende vastavust riigihanke alusdokumentides

toodud tingimustele.

6.3. Hankija nõudel peab täitja pakkumuses esitatud teavet selgitama, piiritlema või

täpsustama.

6.4. Hankijal on õigus lükata pakkumus tagasi, kui see ei vasta minikonkursis esitatud

tingimustele ning juhul, kui täitja on esitanud lisatingimusi, mis ei ole kooskõlas

minikonkursi tingimustega.

6.5. Hankija lükkab pakkumuse tagasi, kui hankelepingu sõlmimine selle pakkumuse alusel

rikuks rahvusvahelist sanktsiooni rahvusvahelise sanktsiooni seaduse tähenduses

(RSansS).

6.6. Hankija võib minikonkursi käigus esitatud pakkumusi hinnata enne pakkumuste

vastavuse või pakkujate suhtes kõrvaldamise aluste puudumise kontrollimist. Sellisel

juhul kontrollib hankija pakkumuse vastavust ja kõrvaldamise aluste puudumist vaid

pakkujal, kellega ta kavatseb hankelepingu sõlmida. Kui selle pakkuja pakkumus osutub

kontrollimise tulemusena mittevastavaks või pakkuja kõrvaldatakse minikonkursilt, on

hankijal õigus teostada kirjeldatud kontrollid hindamise tulemusena paremusjärjestuses

järgmise pakkuja osas.

7. Pakkumuste hindamine, edukaks tunnistamine või tagasi lükkamine

7.1. Hankijal on õigus pakkumus tagasi lükata ja otsustada hankelepingut mitte sõlmida või

vastavalt raamlepingule minikonkurss kehtetuks tunnistada, kui:

7.1.1. pakkumus(ed) ei vasta tingimustele;

7.1.2. pakkumus(ed) ületavad eeldatavat maksumust;

7.1.3. tellija ei saa projektile rahastust.

7.2. Hankijal on õigus enne hankelepingu sõlmimist tunnistada minikonkurss omal algatusel

põhjendatud vajadusel kehtetuks, teavitades sellest pakkujaid.

7.3. Raamlepingu punktis 4.16.2 toodud hindamiskriteeriumide alusel tunnistab hankija

edukaks madalaima kogumaksumusega pakkumuse. Tulemi kogumaksumus peab

sisaldama kõiki tulemi saavutamiseks vajalikke kulusid

8. Kõrvaldamise aluste kontrollimine, eduka pakkuja äralangemine

4(4)

8.1. Hankija kontrollib pakkujal, kellega ta kavatseb hankelepingu sõlmida RHS § 95 lõikes

1 ja 4 sätestatud kõrvaldamise aluseid. Hankija ei sõlmi hankelepingut pakkujaga, kellel

esineb mõni § 95 lõikes 1 või 4 nimetatud kõrvaldamise alus.

8.2. Kui pakkuja, kellega hankija kavatseb hankelepingu sõlmida, kõrvaldatakse minikonkursilt,

nimetatud pakkuja võtab hankijast mitteolenevatel põhjustel oma pakkumuse tagasi või ei

allkirjasta hankelepingut, mida käsitletakse kui pakkumuse tagasi võtmist RHS § 119

tähenduses, hindab hankija kõiki ülejäänud minikonkursi pakkumusi uuesti ja tunnistab

soodsaimaks pakkumuse, mis on pakkumustest majanduslikult soodsaim. Hankija ei ole

kohustatud pakkumusi uuesti hindama ja võib tunnistada soodsaimaks esialgsel hindamisel

edukuselt järgmiseks osutunud pakkumuse juhul, kui soodsaimaks tunnistatud pakkumuse

äralangemine ei saa mõjutada ülejäänud pakkumuste omavahelist järjestust.

8.3. Hankija rakendab RHS § 97 ja pakkuja võib esitada koos pakkumusega või hankija nõudmisel

tõendeid heastamismeetmete kohta.

Lugupidamisega

(allkirjastatud digitaalselt)

Mart Nielsen

peadirektor

Lisa: Loetletud punktis 2.

Paavo Kirsi, [email protected]