KÄSKKIRI
nr
Lihthanke „Ehitisregistri andmehalduse raamistiku
analüüs" korraldamine, komisjoni ja vastutava
isiku nimetamine
Riigihangete seaduse § 14 lõike 1 punkti 1, § 100 ja § 101 alusel ning kooskõlas ettevõtlus- ja
infotehnoloogiaministri ning majandus- ja taristuministri 09.10.2017 käskkirjaga (registreeritud
dokumendihaldussüsteemis 03.10.2017. a) nr 1.1-1/17-199 kinnitatud „Majandus- ja
Kommunikatsiooniministeeriumi hankekorraga“:
1. Korraldada lihthange „Ehitisregistri andmehalduse raamistiku analüüs“ (riigihanke objekti kood
72222000-7 „Infosüsteemide ja tehnoloogilise strateegia retsenseerimis- ja planeerimisteenused“).
2. Määran käskkirja punktis 1 nimetatud lihthanke eest vastutavaks isikuks Majandus- ja
Kommunikatsiooniministeeriumi (edaspidi MKM) ehitusregistri talituse andmeparandustööde
projektijuhi Rasmus Kase.
3. Moodustan hankekomisjoni käskkirja punktis 1 nimetatud lihthanke korraldamiseks, sh
pakkujatel kõrvaldamise aluste kontrollimiseks ja pakkujate kvalifitseerimiseks hankepassi alusel,
pakkumuste vastavaks tunnistamiseks ja eduka pakkumuse väljaselgitamiseks ning edukal
pakkujal kõrvaldamise aluste ja kvalifitseerimise tingimustele vastavuse kontrollimiseks
hankepassis esitatud kinnitusi tõendavate dokumentide ja andmete alusel, järgmises koosseisus:
3.1. Komisjoni esimees Rasmus Kask – MKMi ehitusregistri talituse andmeparandustööde
projektijuht.
Komisjoni liikmed:
3.2. Taavi Jakobson – MKMi ehitusregistri talituse juhataja;
3.3. Kuldar Aas – MKMi digiarengu osakonna andmehalduse programmijuht.
4. Kinnitan käskkirja punktis 1 nimetatud lihthanke alusdokumendid (lisatud).
5. Valitud hankemenetluse liigi ja punktis 4 nimetatud hanke alusdokumentide peale võib esitada
vaidlustuse Rahandusministeeriumi juures asuvale riigihangete vaidlustuskomisjonile riigihangete
seaduses sätestatud korras ja tähtajal.
(allkirjastatud digitaalselt)
Ahti Kuningas
kantsler
HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD
Viitenumber:
Hankija: Majandus- ja Kommunikatsiooniministeerium (70003158)
Hange: Ehitisregistri andmehalduse raamistik
Pakkumuse maksumust hinnatakse - Ilma maksudeta
Elektroonilist oksjoni kasutatakse: ei
Jrk Nimetus Kirjeldus Tüüp/hindamismeetod Osakaal Kogus Ühik Pakkuja
nr täidetav
1 Metoodika valik ja töö tulemuste Kvaliteet / hankija hinnatav 30
saavutamiseks vajalike tegevuste
kava
2 Töö tulemused ja Tellija Kvaliteet / hankija hinnatav 30
vajaduste mõistmine
3 Riskide maandamine Kvaliteet / hankija hinnatav 10
4 Pakkumuse maksumus Pakkuja esitab Vähim on parim 30 jah
pakkumuse
maksumuse ilma
käibemaksuta.
Kokku: 100
Hindamismetoodika kirjeldus
1. Metoodika valik ja töö tulemuste saavutamiseks vajalike tegevuste kava
Vastavalt HD Hankedokument p 118.1.
2. Töö tulemused ja Tellija vajaduste mõistmine
Vastavalt HD Hankedokument p 11.8.2.
3. Riskide maandamine
Vastavalt HD Hankedokument p 11.8.3
4. Pakkumuse maksumus
Madalaima väärtusega pakkumuse maksumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim maksumus" /
"hinnatava pakkumuse maksumus" * "osakaal".
Vt HD Hankedokument p 11.8.4.
Lepingu Lisa 6 „Töö üleandmise-vastuvõtmise akt“ (vorm)
Majandus- ja Kommunikatsiooniministeeriumi
ja XXX vahel sõlmitud
Lepingu nr XXX juurde
Töö üleandmise-vastuvõtmise akt
Käesolev Töö üleandmise-vastuvõtmise akt (edaspidi akt) on koostatud XXX (edaspidi: Täitja) … poolt
ja esitatud Majandus- ja Kommunikatsiooniministeeriumi ehitisregistri talituse andmeparandustööde
projektijuhile Rasmus Kask (edaspidi: Tellija), tõendamaks, et Töövõtja andis üle Poolte vahel XXX
sõlmitud Lepingu „Ehitisregistri andmehalduse raamistiku analüüs” nr XXX alusel osutatud Töö
alljärgnevalt:
1. … (üleantava Töö nimetus, detailne kirjeldus (kas on lõpparuanne või vahearuanne ning
mida üleantav Töö hõlmab), ajavahemik, maht, täidetud tingimused, vajadusel viited
Lepingu punktidele vms).
2. Tellija on Töö osutamise tulemustega tutvunud ning kiidab Töö osutamise tulemused
heaks, millega ühtlasi loetakse Täitja poolt üle antud Töö vastuvõetuks.
Akt on aluseks Töövõtja poolt Tellijale kooskõlas Lepingu eritingimuste punktiga 3. ja üldtingimuste
punktiga 2.4 ja 2.5. arve esitamiseks summas … (summa sõnades) eurot. Akt omab digitaalselt
allkirjastatuna juriidilist jõudu ning edastatakse elektrooniliselt mõlemale Poolele.
Töövõtja Tellija
/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/
Käskkirja Lisa 1
Lihthanke „Ehitisregistri andmehalduse raamistiku analüüs“ alusdokument
Pakkujate hankemenetluselt kõrvaldamise alused, kvalifitseerimistingimused ja kvalifikatsiooni
tõendamise nõuded
1. Hankemenetluselt kõrvaldamise alused ja hankepassiga esitatav informatsioon
1.1. Hankija ei sõlmi hankelepingut ja kõrvaldab hankemenetlusest pakkuja, kellel esineb RHS § 95
lõikes 1 nimetatud kõrvaldamise alus.
1.2. Hankepass peab sisaldama:
1.2.1. pakkuja kinnitust, et pakkuja ei vasta ühelegi RHS § 95 lõikes 1 sätestatud tingimusele;
1.2.2. pakkuja kinnitust, et ta vastab kõikidele riigihanke alusdokumentides pakkuja
kvalifitseerimiseks esitatud tingimustele, ja hankija nõutud andmeid esitatud tingimustele vastamise
kohta;
1.3. Pakkuja esitab kõrvaldamise aluste puudumise ja kvalifitseerimise tingimustele vastavuse
esialgse tõendina hankepassi Euroopa Komisjoni kehtestatud standardvormil vastavalt RHS § 104
sätestatud tingimustele.
1.4. Kui pakkuja soovib tõendada enda vastavust majanduslikule ja finantsseisundile või tehnilisele ja
kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab pakkuja esitama
hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb.
1.5. Punkti 1.4. alusel esitatav hankepass peab sisaldama kinnitust, et ettevõtjal, kelle vahenditele
pakkuja tugineb, ei esine ühtegi RHS § 95 lõikes 1 sätestatud kõrvaldamise alust ja ta vastab sellele
kvalifitseerimiseks esitatud tingimusele, mille osas pakkuja teise ettevõtja vahenditele tugineb, ning
hankija nõutud andmeid esitatud tingimusele vastamise kohta.
2. Pakkuja kvalifitseerimise nõuded:
2.1. Majanduslik ja finantsseis: Netokäive on kahel viimasel riigihanke algamise ajaks lõppenud
majandusaastal (2021 ja 2022), mille kohta on kinnitatud aruanded olnud vähemalt 100 000 eurot iga
majandusaasta kohta.
2.2. Hankija kontrollib netokäibe nõude täitmist äriregistris olevate avalike andmete põhjal juhul kui
pakkuja 2021. ja 2022. aasta majandusaasta aruanded on avaldatud äriregistris. Juhul kui
majandusaasta aruanded ei ole avaldatud, siis tuleb andmed käibenõude täitmise kohta esitada
hankepassis.
2.3. Tehniline ja kutsealane pädevus: riigihanke algamisele eelneva 36 kuu jooksul on pakkuja täitnud
ja tellijale üle andnud vähemalt kaks (2) hanke objektiga sarnast tööd (veebipõhise
tarkvaralahenduse arendusteenus) ning tellija on need vastu võtnud. Hankija võtab arvesse ka varem
täidetud lepinguid, mis on täidetud kuni 60 kuu jooksul enne riigihanke alustamist.
Täidetuks loetakse leping, mille täitmise tähtaeg on saabunud ning mille kohaselt tellitud teenused
on tellijale üle antud ja tellija poolt vastu võetud. Pakkuja esitab hankepassis teabe eelnimetatud
lepingute maksumuse, kuupäevade ja teiste lepingupoolte kohta. Pakkuja esitab riigihanke
viitenumbri juhul, kui on tegemist täidetud riigihanke lepinguga.
Käskkirja lisa 2
Majandus- ja Kommunikatsiooniministeerium
Ehitisregistri andmehalduse raamistiku analüüs
Hankedokument
Lihthange
erimenetlus
Infosüsteemide ja tehnoloogilise strateegia retsenseerimis- ja planeerimisteenused
(CPV kood 72222000-7)
Tallinn 2023
SISUKORD
1. Üldandmed .......................................................................................................................... 3
2. Üldtingimused ..................................................................................................................... 3
3. Hankelepingu ese ................................................................................................................ 3
4. Pakkumuse jõusoleku tähtaeg ............................................................................................. 3
5. Pakkumuse ettevalmistamise juhend ja pakkumuse esitamine ........................................... 4
6. Pakkumuse koosseis ............................................................................................................ 5
7. Pakkumuse maksumus ........................................................................................................ 6
8. Kõikide pakkumuste tagasilükkamine ................................................................................ 6
9. Kõrvaldamise aluste kontroll ja pakkujate kvalifitseerimine .............................................. 6
10. Nõuded pakkuja meeskonnale............................................................................................. 6
11. Pakkumuste vastavuse kontrollimine .................................................................................. 7
12. Pakkumuste hindamine ja hindamiskriteeriumid ................................................................ 7
13. Hankelepingu tingimused.................................................................................................. 10
14. Lisad .................................................................................................................................. 11
1. ÜLDANDMED
1.1. Hankija: Majandus- ja Kommunikatsiooniministeerium, aadress Suur–Ameerika 1,
10122, reg nr. 70003158, e-mail:
[email protected], tel. +372 625 6342.
1.2. Hankemenetluse liik: lihthange.
1.3. Hankemenetluse teostamise viis: e-menetlus riigihangete registris.
1.4. Riigihanke läbiviimise eest vastutav ametiisik: Majandus- ja
Kommunikatsiooniministeeriumi ehitisregistri talituse andmeparandusetööde
projektijuht Rasmus Kask, tel: +372 6397623, e-post:
[email protected].
1.5. Hankelepingu esemeks oleva töö etappide tulemused moodustavad loogilise ja üksteisest
sõltuva terviku, seetõttu ei jagata hanget ühe menetluse raames osadeks.
2. ÜLDTINGIMUSED
2.1. Hankes saavad osaleda ainult pakkujad, kelle elu- või asukoht on Eestis, mõnes muus
Euroopa Liidu liikmesriigis, muus Euroopa Majanduspiirkonna lepinguriigis või Maailma
Kaubandusorganisatsiooni riigihankelepinguga ühinenud riigis.
3. HANKELEPINGU ESE
3.1. Hankija (edaspidi ka Tellija) kutsub esitama pakkumust töö „Ehitisregistri andmehalduse
raamistiku analüüs“ (hankelepingu ese) teostamiseks riigihanke alusdokumentides
(RHAD) ja nende lisades sätestatud tingimustel.
3.2. Hankelepingu eseme detailne kirjeldus, selle eesmärk ja kontseptsioon on lahti kirjutatud
hanke alusdokumendis „Tehniline kirjeldus“ (HD Lisa 1).
3.3. Hankelepingu täitmise tähtpäev on XXXX.
3.4. Pakkumuse esitamine tähendab Pakkuja nõustumist kõikides riigihanke
alusdokumentides kehtestatud hanketingimuste ja reeglitega.
3.5. Pakkumus peab vastama hanke alusdokumentides esitatud tingimustele ja tuleb esitada
kogu hanke alusdokumentides nõutud mahus.
3.6. Alternatiivsete ja/või osaliste pakkumuste esitamine ei ole lubatud.
3.7. Hankija ei kompenseeri Pakkujale pakkumuse ettevalmistamisega seotud mistahes
kulusid, sh turu-uuringu läbiviimise ettevalmistamisega seotud kulusid.
4. PAKKUMUSE JÕUSOLEKU TÄHTAEG
4.1. Pakkuja pakkumus peab olema jõus vähemalt 90 kalendripäeva. Pakkumuse jõusoleku
tähtaeg algab pakkumuse esitamise tähtpäevast.
4.2. Pakkuja esitab pakkumuses kinnituse pakkumuse jõusoleku kohta nimetatud tähtaja
jooksul.
4.3. Hankija pikendab vajadusel pakkumuste jõusoleku tähtaega kooskõlas riigihangete
seaduse (RHS) §-s 112 sätestatud reeglitega.
5. PAKKUMUSE ETTEVALMIS TAMISE JUHEND JA PAK KUMUSE
ESITAMINE
5.1. Hankemenetluses teavituste saamiseks peavad hankest huvitatud isikud Hankijale
avaldama riigihangete registri e-keskkonnas (e-RHR) oma kontaktandmed,
registreerudes hanke juurde „Hankes osalejad“ lehel. Hanke juurde registreerunud isikud
saavad automaatteavitusi hanke alusdokumendi kehtetuks tunnistamise või muutmise
kohta, samuti toimub selgituste küsimine ja nendele vastamine e-RHRkaudu.
5.2. Pakkumuse esitamisega kinnitab Pakkuja kõigi riigihanke alusdokumentides esitatud
tingimuste ülevõtmist.
5.3. Pakkumus peab vastama riigihanke alusdokumentides esitatud tingimustele ja tuleb
esitada kogu riigihanke alusdokumentides nõutud mahus.
5.4. Pakkumus ja kõik pakkumuse juurde kuuluvad dokumendid peavad olema vormistatud
eesti keeles. Kõik muukeelsed dokumendid peavad olema tõlgitud eesti keelde, kusjuures
tõlge peab vahetult järgnema originaalile. Erandiks on ingliskeelsed reklaamialased
trükised, mis võivad olla esitatud inglise keeles.
5.5. Pakkumus peab olema esitatud .pdf formaadis digitaalselt allkirjastatuna Pakkuja
seadusjärgse või volitatud esindaja poolt.
5.6. Pakkuja võtab enda kanda pakkumuse ja pakkumuse tagasivõtmise teate Hankijale
edastamise kogu riski, kaasa arvatud vääramatu jõu toime võimalus.
5.7. Pakkumused tuleb esitada hanketeates märgitud tähtajaks elektroonselt e-riigihangete
keskkonna vahendusel: https://riigihanked.riik.ee. Pakkumuse esitamise tähtaeg
märgitakse e-RHR-s hanke üldandmete lehele.
5.8. Juhul kui pakkumuse digiallkirjastamine ei ole võimalik (nt piiriülesed pakkujad) või
pakkumuse koosseisus on originaaldokumente, mida ei ole võimalik esitada
elektroonilisel kujul, esitatakse käsitsi allkirjastatud dokumendid skaneeritud koopiatena
e-RHR-i. Erinevuste esinemisel originaali ja koopia vahel loetakse õigeks ning lähtutakse
hindamisel originaaldokumentide sisust.
5.9. Pakkuja võib pakkumuse tagasi võtta enne pakkumuste esitamise tähtpäeva, esitades
Hankijale pakkumusega samas vormis sellekohase teate läbi e-RHR-i.
5.10. Küsimused hanke alusdokumentide kohta tuleb esitada e-RHRis. Küsimuste esitamiseks
peab Pakkuja end riigihanke juurde registreerima. Hankija ei vastuta nimetatud
keskkonna ja sidevahendite tehnilise toimimise eest.
5.11. Hankija vastab riigihanke alusdokumentidega seotud selgitustaotlustele kolme tööpäeva
jooksul asjakohase selgitustaotluse saamisest arvates. Hankija ei ole kohustatud
riigihanke alusdokumentidega seotud selgitustaotlusele vastama, kui selgitustaotluse
Hankijale laekumise ja pakkumuse esitamise tähtaja vahele jääb vähem kui kaks päeva
(RHS § 46 lg 2).
5.12. Pakkuja märgib pakkumuses selgelt eristataval viisil, milline teave on Pakkuja ärisaladus
ning põhjendab ärisaladuseks määramist (HD Lisa 4 vorm). Ärisaladusena ei ole lubatud
märkida pakkumuse maksumust, osamaksumusi ega muid pakkumuste hindamise
kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid (RHS § 461 lg
1). Hankija juhib tähelepanu, et eduka Pakkuja pakkumus on avalik lähtuvalt RHS § 110
lg 5, välja arvatud Pakkuja poolt õigustatult ärisaladuseks määratletud osas. Juhul kui
Pakkuja ei määratle pakkumuses arusaadavalt ärisaladust või ei põhjenda asjakohaselt,
miks on tegemist ärisaladusega, on Hankijal kohustus teabenõude laekudes pakkumus
täies ulatuses avalikustada.
6. PAKKUMUSE KOOSSEIS
6.1. Pakkumuses tuleb esitada:
6.1.1. Tööde sisuline kirjeldus, mis võtab arvesse Tehnilises kirjelduses (HD Lisa 1)
esitatud infot ja tingimusi ning mille raames esitatakse:
6.1.1.1. Metoodika ja lepingu täitmise tulemuste kirjeldus;
6.1.1.2. Tegevuste loend ja kirjeldus, sealhulgas lepingu täitmise tulemuste
saavutamiseks vajalike täiendavate tegevuste (lisaks tehnilises kirjelduses
nimetatule) kirjeldus ja põhjendus;
6.1.1.3. Tegevuste ja tööde ajakava/projektiplaan koos ligikaudse eeldatud
ajakuluga olulisemate tegevuste lõikes;
6.1.1.4. Meeskonna koosseis ja nende valiku põhjendus;
6.1.1.5. Riskide loend koos nende realiseerumise tõenäosuse, mõju ja maandamise
viisidega.
6.1.2. Pakkumuse maksumus, mis esitatakse riigihangete registri maksumuse vormil;
6.1.3. Projektis osalevate meeskonnaliikmete CV-d (HD Lisas 3 esitatud vormil), mis on
meeskonnaliikme poolt allkirjastatud;
6.1.4. Hankepass, mis esitatakse riigihangete registri etteantud vormil koos pakkumusega;
6.1.5. Vajadusel volikirjad, sh:
6.1.5.1.Juhul kui pakkumusei allkirjastab isik, kes tegutseb volikirja alusel, tuleb
lisada pakkumusele ka vastav seadusliku esindaja poolt allkirjastatud
volikiri;
6.1.5.2.Ühispakkujad peavad esitama volikirja, kus nimetavad riigihankele
pakkumuse esitamisega ning hankelepingu sõlmimise ja täitmisega seotud
toimingute tegemiseks endi seast volitatud esindaja;
6.1.6. Ühispakkumuse korral esitavad ühispakkujad kinnituse, et vastutavad Hankija ees
hankelepingu täitmise eest solidaarselt;
6.1.7. Muud kinnitused ja materjalid (vajadusel tõlked), mida Pakkuja soovib pakkumusele
lisada.
7. PAKKUMUSE MAKSUMUS
7.1. Pakkumuse maksumus peab olema esitatud eurodes ilma käibemaksuta.
7.2. Pakkumuse eeldatav maksumus käibemaksuta on 59 900 eurot.
7.3. Pakkumuse maksumus peab sisaldama kõiki töö läbiviimiseks, esitlemiseks ja üle
andmiseks (sh ettevalmistamine, läbiviimine, analüüs, intervjuud, töötoad, tõlkimine,
lähetused, tulemuste üleandmine ja esitlemine, kasutatava tarkvara litsentsid jms) vajalikke
kulusid, makse ja makseid. Hankija maksab hankelepingu täitmise käigus Töö teostajale
vastavalt hanke alusdokumentides määratud etappidele (pärast vastavas etapis teostatud töö
vastuvõtmist) ning täiendavaid makseid ei tee.
8. KÕIKIDE PAKKUMUSTE T AGASILÜKKAMINE
8.1. Hankija võib teha põhjendatud kirjaliku otsuse kõigi pakkumuste tagasilükkamise kohta
lisaks RHS § 116 lõike 1 punktis 1 sätestatule, kui:
8.1.1. hankemenetluse läbiviimise ajal on Hankijale saanud teatavaks uued asjaolud, mis
välistavad või muudavad Hankijale ebaotstarbekaks hankemenetluse lõpule viimise
hanke alusdokumentides sätestatud tingimustel.
8.2. Hankija ei kanna vastutust Pakkuja ees, kui kõigi pakkumuste tagasilükkamine on
toimunud käesolevas dokumendis sätestatud tingimustel.
9. NÕUDED PAKKUJA MEESKONNA LE
9.1. Pakkuja meeskonnas peavad olema esindatud vähemalt järgnevad eksperdid:
- projektijuht;
- strateegia ekspert;
- andmehalduse ekspert;
- tarkvaraarhitekt.
Projektijuhi rolli täitev meeskonnaliige peab olema osalenud viimase 5 aasta jooksul
projektijuhina vähemalt kahes (2) suuremahulises infotehnoloogilise
konsultatsiooniteenuse projektis (ühe projekti kogumaksumus on võrdne või ületab
hanke eeldatavat maksumust) arvates hanketeate avaldamisest e-RHRis. Projektijuht
võib kanda ka muid projektimeeskonna rolle.
Strateegia konsultandi rolli täitev meeskonnaliige peab olema osalenud viimase 5 aasta
jooksul vähemalt kahes (2) suuremahulises projektis (ühe projekti kogumaksumus on
võrdne või ületab hanke eeldatavat maksumust), mille raames analüüsiti teenuseid ja
mitme erineva sihtrühma kasutajateekondi, kasutades teenusedisaini tööriistu ja
metoodikaid.
Andmehalduse eksperdi rolli täitev meeskonnaliige peab olema osalenud viimase 5
aasta jooksul vähemalt kahes (2) suuremahulises projektis (ühe projekti kogumaksumus
on võrdne või ületab hanke eeldatavat maksumust), milles on realiseeritud andmehalduse
raamistiku kaardistamine ning tulevikuvaate välja töötamine.
Tarkvaraarhitekti rolli täitev meeskonnaliige peab olema osalenud viimase 5 aasta
jooksul vähemalt kahes (2) suuremahulises projektis (ühe projekti kogumaksumus on
võrdne või ületab hanke eeldatavat maksumust, minimaalselt 120 tundi projekti kohta)
tarkvaraarhitekti rollis, mis on tegelenud teenuste kaardistamisega ning erinevate
infosüsteemide, andmebaaside ning e-teenuste liidestamisega.
9.2. Üks meeskonnaliige võib täita kuni kahte rolli projektimeeskonnas. Pakkuja nimetab oma
meeskonnas ühe liikme projektijuhiks. Muus osas on Pakkujal meeskonna
komplekteerimisel vabad käed. Meeskonna liikmed ja nende kogemus/CV tuleb lisada
pakkumusele ette nähtud korras. CV-s tuleb välja tuua kõik andmed sellises detailsuses,
mis võimaldavad hankijal kontrollida meeskonna liikme vastavust esitatud
hanketingimustele.
9.3. Pakkumuses loetletud spetsialistide vahetamine on lubatud vaid Hankija/Tellija eelneval
kirjalikul loal. Pakkujal on õigus tööde tegemise käigus kaasata täiendavaid eksperte.
Pakkuja peab Hankijat/Tellijat informeerima kaasatud täiendavast eksperdist.
10. PAKKUMUSTE VASTAVUSE KONTROLLIMINE
10.1. Hankija kontrollib pakkumuse vastavust RHS §-s 114 sätestatud korras.
10.2. Pakkumus peab vastama kõikidele riigihanke alusdokumentides esitatud tingimustele ja
sisaldama käesoleva dokumendi alapunktis 6.1. nõutud informatsiooni.
10.3. Hankija lükkab pakkumuse tagasi, kui see ei vasta riigihanke alusdokumentides esitatud
tingimustele.
10.4. Hankija võib tunnistada pakkumuse vastavaks, kui selles ei esine sisulisi kõrvalekaldeid
riigihanke alusdokumentides esitatud tingimustest.
11. PAKKUMUSTE HINDAMINE JA HINDAMISKRITEERIU MID
11.1. Hankija hindab kõiki kvalifitseeritud pakkujaid, kelle pakkumused on vastavaks
tunnistatud.
11.2. Pakkumuste hindamisel selgitatakse majanduslikult soodsaim pakkumus välja
hindamiskriteeriumite ja nende eest antavate punktide alusel (vt punkt 11.8):
11.3. Hankekomisjon summeerib hindamiskriteeriumite alusel antud punktid. Pakkumuse
sisukriteeriumite (metoodika valik ja tulemuste saavutamiseks vajalike tegevuste kava,
Tellija vajaduste mõistmine, riskide maandamine) ja maksumuse eest antud punktid
summeeritakse.
11.4. Hankekomisjon annab punkte ühiselt, konsensuse alusel. Konsensuse mittesaavutamisel
võetakse vaidlusaluses küsimuses komisjoni liikmete hinnete aritmeetiline keskmine.
11.5. Edukaks pakkumuseks tunnistatakse pakkumus, mille punktide summa on suurim.
Hindamistäpsus on kaks kohta pärast koma.
11.6. Edukaks ei tunnistata pakkumust, mis sai vähemalt ühe hindamiskriteeriumi eest 0 punkti.
11.7. Võrdse arvu punkte kogunud pakkumuste puhul tunnistatakse edukaks pakkumus, mis sai
rohkem sisupunkte. Kui ka siis esineb pakkumustel võrdsel arvul punkte, otsustatakse
võitja liisu heitmise teel.
11.8. Hindamiskriteeriumid ja nende osakaal:
1. hindamiskriteerium – metoodika valik ja töö tulemuste saavutamiseks vajalike
tegevuste kava (kuni 30 punkti, alamkriteeriumide eest antakse võrdne arv punkte);
2. hindamiskriteerium – töö tulemused ja Tellija vajaduste mõistmine (kuni 30 punkti,
alamkriteeriumide eest antakse võrdne arv punkte);
3. hindamiskriteerium – riskide maandamine (kuni 10 punkti, alamkriteeriumide eest
antakse võrdne arv punkte);
4. hindamiskriteerium – pakkumuse maksumus (kuni 30 punkti maksimaalsed punktid
saab kõige madalama maksumusega pakkumus).
11.8.1. Metoodika valik ja töö tulemuste saavutamiseks vajalike tegevuste kava
(kuni 30 punkti)
Suurepärane Hea Rahuldav Ebapiisav
30 punkti 25 punkti 15 punkti 0 punkti
Metoodika Eesmärgipärane, Eesmärgipärane, Üldiselt Ebapiisav
sisaldab kõiki täitmata on üks (1) eesmärgipärane, „Rahuldava“
tehnilises kirjelduses kuni kaks (2) täitamata on kolm tulemuse
välja toodud eesmärki tehnilises kirjelduses (3) või enam saavutamiseks
tehnilises kirjelduses
välja toodud välja toodud
eesmärki eesmärki
Tegevuste Loendatud tegevused Loendatud tegevused Loendatud tegevused
loend ja on teostatavad, on piisavad töö on üldjoontes
kirjeldus piisavad ja tarvilikud teostamiseks. 1-2 piisavad töö
töö teostamiseks, tegevuse kirjeldus on teostamiseks.
piisavalt kirjeldatud ebaselge või Rohkem kui 2
ning põhjendatud. teostatavus või tegevuse kirjeldus on
tarvilikkus tekitab ebaselge, teostatavus
küsimusi. või tarvilikkus
tekitab küsimusi
Tegevuste ja Loogiliselt järjestatud, Loogiliselt Põhimõtteliselt töö
tööde järjestus selgelt ja arusaadavalt järjestatud ja tööde teostamist
koos põhjendatud, tööde tähtaegset teostamist võimaldav, kuid
ajakavaga tähtajalist teostamist võimaldav, kuid tööde järjestuses või
võimaldav, tööde järjestuse või ajakavas on mitmeid
optimaalne. ajakava suhtes on (rohkem kui 2)
mõningaid (kuni 2) küsitavusi.
küsitavusi
Meeskond Meeskonna kogemus Meeskonna kogemus Täitmata on üks või
ja suurus toetavad ja suurus toetavad enam meeskonnale
tulemuse saavutamist, tulemuste esitatud nõudmiste
seotud riskid saavutamist, seotud rollidest
(asendused) on riskid ei ole selgelt
maandatud maandatud
Vormistus Piisavalt detailne, Piisavalt detailne, Detailne, kuid
lakooniline, visuaalselt visuaalselt haaratav raskesti haaratav
kergesti haaratav
11.8.2. Töö tulemused ja Tellija vajaduste mõistmine (kuni 30 punkti)
Suurepärane Hea Rahuldav Ebapiisav
30 punkti 25 punkti 15 punkti 0 punkti
Tulemuste Näitab Tellija Näitab Tellija vajaduste Näitab Tellija
kirjeldus vajaduste mõistmist ja mõistmist kooskõlas vajaduste üldist
kaasa mõtlemist hanke eseme tehnilise mõistmist
kooskõlas hanke kirjeldusega. kooskõlas hanke
eseme tehnilise eseme tehnilise
kirjeldusega (vt HD kirjeldusega.
Lisa 1 – Tehniline
kirjeldus). Ebapiisav
Tulemuste Eesmärgile täielikult Eesmärgile vastav, Eesmärgile vastav „Rahuldava“
formaadi vastav, detailselt ja arusaadavalt kirjeldatud ja kasutatav, kuid tulemuse
kirjeldus arusaadavalt ja hästi kasutatav. Võiks võiks olla oluliselt saavutamiseks
kirjeldatud, selge ja olla mõnes aspektis detailsem või
hästi kasutatav detailsem või selgemini selgemini
kirjeldatud. kirjeldatud
Vormistus Piisavalt detailne, Piisavalt detailne, Detailne, kuid
lakooniline, visuaalselt haaratav raskesti haaratav
visuaalselt kergesti
haaratav
11.8.3. Riskide maandamine (kuni 10 punkti)
Suurepärane Hea Rahuldav Ebapiisav
10 punkti 7 punkti 4 punkti 0 punkti
Riskide loetelu Loetletud ainult kõik Loetletud kõik Enamik olulisi
olulised riskid olulised riskid, riske loetletud
kuid on esitatud
ka ebaolulisi
Riskide mõju Kõik hinnangud on Hinnangud on Hinnangud on
ja tõenäosus põhjendatult realistlikud ja realistlikud ja antud, kuid nende
hinnatud mõistetavad mõistetavad, võib realistlikkuses või
esineda 2-3 mõistetavuses on
küsitavust. küsitavusi
Ebapiisav
Maandamise Maandamise meetodid Maandamise Maandamise „Rahuldava“
meetodid väga hästi põhjendatud, meetodid piisavalt meetodid üldiselt tulemuse
proportsionaalsed riski põhjendatud ja kirjeldatud ja saavutamiseks
esinemise tõenäosusele, ja Pakkuja poolt põhjendatud.
Pakkuja poolt reaalselt reaalselt Esineb 3+
kasutatavad. kasutatavad. küsitavust
Esineb 1-2 meetodite
küsitavust. põhjendatuse ja
realiseeritavuse
osas.
Vormistus Piisavalt detailne, Piisavalt detailne Üldine
lakooniline
11.8.4. Pakkumuse maksumus (kuni 30 punkti)
Pakkumuse maksumuse väärtuspunktide määramisel saavutab maksimaalsed
väärtuspunktid kõige odavam (pakkumuse maksumus ilma käibemaksuta) pakkumus.
Väärtuspunktid arvutatakse järgmise valemi kohaselt: “punktimäär” = “kõige odavam
pakkumuse maksumus” / “hinnatava pakkumuse maksumus” × 30. Arvutuste tulemused
ümardatakse kahe komakoha täpsusega.
12. HANKELEPINGU TIN GIMUSED
Pakkujaga sõlmitava lepingu projekt on hankedokumendi HD Lisa 2.
13. LISAD
HD Lisa 1 – Tehniline kirjeldus
HD Lisa 2 – Lepingu projekt
HD Lisa 3 – Eksperdi ja projektijuhi CV-vorm
HD Lisa 4 – Ärisaladuse teabe esitamise vorm
HD Lisa 5 – Hindamiskriteeriumid ja hinnatavad näitajad
HD Lisa 6 - Töö üleandmise-vastuvõtmise akti vorm
HD LISA 2
HANKELEPINGU PROJEKT
Majandus- ja Kommunikatsiooniministeerium, registrikood 70003158, asukoht Suur Ameerika 1,
Tallinn 10122, mida esindab Majandus- ja Kommunikatsiooniministeeriumi hankekorra alusel kantsler
Ahti Kuningas (edaspidi tellija),
ja
…, registrikood, asukoht ……, mida esindab juhatuse liige/volituse alusel ……… (edaspidi töövõtja),
keda edaspidi nimetatakse üheskoos ka pooled ja eraldi pool,
sõlmivad käesoleva teenuse osutamise hankelepingu (edaspidi leping) alljärgnevas:
1. Üldsätted
1.1. Lepingu dokumendid koosnevad lepingu eri- ja üldtingimustest, lepingu lisadest ning lepingu
võimalikest muudatustest, milles lepitakse kokku pärast lepingule allakirjutamist.
1.2. Lepingu dokumentide prioriteetsus on järgmine: eritingimused (I), lepingu lisad (II) ja
üldtingimused (III). Vastuolude korral lepingu dokumentide vahel prevaleerib prioriteetsem
dokument.
1.3. Käesoleva lepingu allakirjutamise hetkel on lepingule lisatud:
1.3.1. Lisa 1. Riigihanke alusdokumendid, sh tehniline kirjeldus (leitavad riigihangete registris).
1.3.2. Lisa 2. Töövõtja pakkumus.
1.3.3. Lisa 3. Üleandmise-vastuvõtmise akti vorm.
1.4 Töövõtja kinnitab, et on lepingu üldtingimustega tutvunud elektroonselt Majandus- ja
Kommunikatsiooniministeeriumi veebis aadressil: https://mkm.ee/ministeerium-uudised-ja-
kontakt/ministeerium-ja-ministrid/hanketeated
2. Lepingu ese, alus ja tähtaeg
2.1. Lepingu esemeks on ehitisregistri andmehalduse raamistiku analüüs (edaspidi töö), mida
töövõtja kohustub tegema vastavalt lepingus ja lepingu lisades sätestatud tingimustele. Töö peab
vastama riigihanke alusdokumentidele ja töövõtja pakkumusele.
2.2. Leping sõlmitakse tellija korraldatud riigihanke viitenumber nr xxx tulemusena ning vastavalt
riigihanke alusdokumentidele ning töövõtja edukaks tunnistatud pakkumusele.
2.3. Töövõtja teostab punktis 2.1 nimetatud töö ja annab selle elektrooniliselt tellijale üle
üleandmise-vastuvõtmise aktiga (edaspidi akt) lisas 1 „Tehniline kirjeldus“ (edaspidi tehniline
kirjeldus) toodud 2 etapi kaupa vastavalt tehnilises kirjelduses toodud etappide tähtaegadele 6 kuu
jooksul hankelepingu sõlmimisest arvates.
2.4. Tellija vaatab töö üle 10 tööpäeva jooksul arvates vahe- ja lõpparuande esitamisest
vastatavalt tehnilise kirjelduse ptk „Töö etapid ja tähtajad“ punktidele 3. ja 4. ning teatab töövõtjale,
kui töö ei vasta lepingutingimustele. Nimetatud tähtaja jooksul kirjaliku teate mittesaatmisel loetakse
töö tellija poolt heakskiidetuks.
2.5. Töö loetakse vastuvõetuks, kui tellija on allkirjastanud sellekohase akti.
3. Tasu suurus, väljamaksmise tähtaeg ja kord
3.1. Tellija tasub töövõtjale lepingus sätestatud töö teostamise eest tasu summas kokku …. eurot,
summale lisandub käibemaks.
1
3.2. Tellija tasub tööde eest kahes etapis (vastavalt tehnilise kirjelduse ptk „Töö etapid ja tähtajad“)
pärast vastava etapi tööde vastuvõtmist üleandmise- vastuvõtmise aktiga ja selle alusel esitatud arve
saamist järgmiselt:
3.2.1. I etapi tööde eest 40% punktis 3.1 nimetatud tasust, kogusummas ……. eurot,
3.2.2. II etapi tööde eest 60% punktis 3.1 nimetatud tasust, kogusummas ……eurot.
4. Poolte volitatud esindajad
4.1. Tellija volitatud esindaja lepingu tingimuste täitmisel, täitmise kontrollimisel ja töö
vastuvõtmisel on Rasmus Kask, telefon 639 7623, e-post
[email protected] või teda asendav isik.
4.2. Töövõtja volitatud esindaja lepingu tingimuste täitmisel, täitmise kontrollimisel ja töö
üleandmisel on ……., telefon ……, e-post …..
5. Muud sätted
5.1. Töövõtja on teadlik, et leping on avalik.
5.2. Leping allkirjastatakse digitaalselt.
5.3. Poolte rahaline vastutus hankelepingu täitmisest tekkivate nõuete eest kokku on piiratud
hankelepingu kahekordse summaga (välja arvatud tahtliku rikkumise korral).
Poolte allkirjad:
Tellija Töövõtja
(allkirjastatud digitaalselt) (allkirjastatud digitaalselt)
2
HD LISA 3
CV VORM– EKSPERT/PROJEKTIJUHT
Roll hankelepingu täitmisel: ekspert/projektijuht
Ees- ja perekonnanimi:
Sünniaeg:
Haridus (märkida õppeasutuse
nimi, kraadi nimetus, tase ning
tunnistuse number, väljaandmise
aeg ):
Kogemuse kirjeldus
(vastavalt hankedokumendi
punktis 9 nõutule:
Töö nimetus:
Tellija:
Läbiviimise aeg (pp.kk.aa–
pp.kk.aa):
Roll, vastutus ja ülesanded
projektis:
Töö sisu lühikirjeldus:
Mina, allakirjutanu, olles ........... (pakkuja nimi) meeskonna liige, kinnitan CV-s esitatud andmete
õigsust ja oma valmisolekut osaleda hankelepingu täitmisel käesolevas CV-s märgitud rollis kogu
hankelepingu kehtivusaja jooksul (või perioodil: nimetada periood).
Kinnitan, et kuulun pakkuja vastutavasse projektimeeskonda ja vastan riigihanke alusdokumentides
spetsialistile esitatud tingimustele hankelepingus täidetava rolli ulatuses.
Vajadusel lisada ridu (nt kui spetsialist on osalenud rohkemates projektides ning pakkuja soovib selle
koht informatsiooni esitada). Minimaalselt tuleb esitada vormil nõutud informatsioon.
CV esitaja: Pakkuja:
/allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/
HD Lisa 4
Ärisaladuse teabe esitamise vorm
Avaldame, et riigihankele viitenumbriga ………….. meie esitatud pakkumusest on
ärisaladusega kaitstud järgmised dokumendid või teave:
Jrk nr Dokumendi nimetus (terviktekst või viide Põhjendus teabe
dokumendis sisalduvale teksti osale) ärisaladuseks määramisest
1
2
3
…
(vajadusel lisada ridasid)
Oleme teadlikud, et:
riigihangete seaduse § 461 lõige 1 kohaselt ei või pakkuja ärisaladusena märkida:
pakkumuse maksumust ega osamaksumusi;
teenuste hankelepingute puhul lisaks pakkumuse maksumusele ja
osamaksumustele muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust
iseloomustavaid numbrilisi näitajaid;
asjade hankelepingute puhul lisaks pakkumuse maksumusele ja osamaksumustele
muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid
näitajaid.
Hankedokumendi Lisa 1
EHRi andmehalduse raamistiku analüüs
Tehniline kirjeldus
Koostaja: Majandus- ja Kommunikatsiooniministeerium
Ehitisregistri talitus
Sissejuhatus
Ehitisregister (EHR, https://ehr.ee) on riiklik andmekogu, mille kaudu saab esitada ja menetleda
ehitamisega seotud dokumente (nagu ehitusluba ja -teatis, kasutusluba, energiamärgis, jne.) ning
vaadata ja hallata ehitiste (hooned ja rajatised) kohta käivat informatsiooni. Ehitisregistris on andmed
nii olemasolevate, lammutatud kui kavandatavate ehitiste kohta nende erinevates arenguetappides1.
Ehitisregistri eesmärk on pakkuda kvaliteetset informatsiooni ehitatud keskkonna kohta ning
lihtsustada ja tõhustada ehitusvaldkonna avalikke teenuseid. Nii aitame kaasa Eesti elukeskkonna
parendamisele.
Ehitisregistri andmekogu koondab menetluskeskkonnast ja muudest sisemistest (nagu
energiamärgised) ja välistest (nagu Maa-amet) allikatest kogutud informatsiooni hoonete (nagu
korter- ja individuaalelamud, tehased, koolid) ja rajatiste (nagu kaevud, väljakud, tuulikud) kohta
erinevatele kasutajagruppidele, nagu omanikud, ehitusettevõtted, notarid, pangad, kindlustusseltsid.
Niisamuti koondatakse andmeid erinevatele osapooltele (nagu riik, KOVid, ülikoolid) nii pikaajaliste
analüüside (nagu puidu kasutamine ehituses, renoveerimismahtude hindamine) kui
investeerimisotsuste (nagu taristu rajamine) ja nende tasuvusanalüüside tegemiseks. Ehitisregistri
andmed on andmelao ja infoportaali ning Eesti avaandmete teabevärava kaudu jagatud ning
täiendavateks analüüsideks alla laetavad ja masintöödeldavad. Niisamuti on võimalik omanikel
vaadata koondinfot oma ehitiste kohta Minu ehitised töölehelt. Ehitisregister sisaldab infot ka
vallasvarast ehitiste omanduse kohta.
EHRi toimimist ja arendamist suunavateks olulisemateks raamstrateegiateks on „Ehituse pikk vaade
2035“2 ja „E-ehituse visioon“ koos tausta analüüsiga3. Esimene neist toob välja ehitusvaldkonna seitse
eesmärki koos tegevustega, millest EHRi puudutavad otseselt kolm: (E3) avalik sektor on targa tellijana
eestvedajaks ja eeskujuks, (E5) lähtutakse ringmajanduse põhimõtetest ja (E6) ehitusvaldkond
edendab innovatiivseid lahendusi tootlikkuse ja kvaliteedi tõstmiseks. Viimast punkti täpsustab ja
selgitab „E-ehituse visioon“, mille kaheks keskseks arengumootoriks on EHR ja e-ehituse platvorm, ning
mis käsitleb digilahenduste vajadusi kogu ehitise elukaare ulatuses planeerimisest haldamise ja
utiliseerimiseni. Dokumendis rõhutatakse lisaks e-ehituse teenuste arendamisele alusandmete
kvaliteedi olulisust nii kättesaadavuse, usaldusväärsuse kui õigsuse osas ning ehitusvaldkonna ühtse
klassifitseerimissüsteemi vajadust. Üldjoontes on EHRi visioon otseselt seotud valdkonna
strateegiatega, kuid vajaks täiendavat täpsustamist, kuidas ja milliste tegevuste läbi EHR valdkonna
eesmärkide saavutamist toetab.
2019. aastal valmis analüüs „Ehitisregistri menetluste kaardistamine, optimeerimine ja e-ehituse
juurutamiseks kohandamine“4, mis valmistas ette EHRi 3.0 versiooni arendused. Peamine fookus on
seatud menetlusprotsessile menetleja ja taotleja vaates. Andmekvaliteedi seisukohast oluliste
arendustena on välja toodud andmete esitamise teatise ja registri paranduskande tööprotsessid, mis
võimaldavad tuvastatud andmevigu nõuetekohaselt parandada. Andmekvaliteedi tagamist (ja laiemalt
andmete haldust pole samas senini süsteemselt käsitletud, mh pole kvaliteeti hallatud andmete
1
Mõistagi vaid sellest ajast kui vastavat informatsiooni on digitaalselt käideldaval kujul kogutud.
2
https://www.mkm.ee/ehitus-ja-elamumajandus/ehitus/ehituse-pikk-vaade
3
https://eehitus.ee/vision/
4
https://eehitus.ee/timeline-post/ehitisregistri-menetluste-kaardistamine-optimeerimine-ja-e-ehituse-
juurutamiseks-kohandamine/
elutsükli ja erinevate süsteemi komponentide vahel liikumise kontekstis. Ülevaatliku ja selge kirjelduse
puudumine raskendab andmevigade tuvastamist ja parandamist.
Probleemipüstitus ja analüüsi eesmärk
Analüüsi eesmärgiks on töötada välja soovitused ja tegevusplaan registri andmehalduse raamistiku
(sh. põhimõtete, rollide, kompetentside ning seotud tööprotsesside ja halduskomponentide)
uuendamiseks ning juurutamiseks. Analüüsi koostamisel tuleb lähtuda EHRi eesmärkidest,
varasemast dokumentatsioonist (tehnilise kirjelduse Lisad 1 ja 2), riiklikest andmehalduse juhistest56,
kehtivatest õigusnormidest, ressursside mõistlikust kasutusest ning valdkonna heast tavast ja
parimatest praktikatest. Järgnevalt on punktide kaupa välja toodud analüüsi raames käsitlemist
vajavad teemad ja uurimisküsimused, millele tuleb töö käigus vastused leida. Punktid 1-4 käsitlevad
hetkeolukorra kaardistust (as-is) ja 5-6 ettepanekuid võimaliku andmehalduse raamistiku osas (to-be).
1. Andmehalduse parim praktika sarnastes andmekogudes. EHRi andmehalduse raamistiku välja
töötamiseks tuleks vaadata üle praegused andmekogude haldamise parimad praktikad ning
kitsaskohad. Olukorra kaardistamiseks tuleks läbi viia intervjuud 3-5 EHRiga sarnase andmekogu
halduriga. Järgnevalt on välja toodu käsitlemist vajavad üldised teemad:
1.1. Millistest andmehalduse standarditest ja parimatest praktikatest lähtutakse?
1.2. Millised on kasutusel oleva andmehaldusraamistiku komponendid, arhitektuur?
1.3. Milliseid tegevusi/protsesse andmete halduse, kirjelduse ja kvaliteedi tagamisel tehakse?
1.4. Millistest andmekvaliteedi reeglitest lähtutakse ning kuidas töö tulemuslikkust hinnatakse?
1.5. Kuidas arvestatakse andmehalduse ressursikulu ning kui suur see on?
1.6. Millised on peamised probleemid ja takistused ning nendest ülesaamise perspektiivsed
lahendused?
2. Andmevajaduste kaardistus. EHRi menetlejate vajadused kaardistati 2019. aastal läbi viidud
analüüsi käigus ning täiendavat teavet erinevate ehitusvaldkonna sihtrühmade vajadustest koguti
e-ehituse platvormi taustaanalüüsi käigus. Ühtlasi on teostatud EHRi analüüsi käigus erinevate
registrite andmevahetuste vajadus. Samas on mõned sihtrühmad, kes EHRi andmete kasutamisega
kokku puutuvad (sh ülikoolid, ettevõtted, kes loovad rakendusi), puudu ning pole põhimõttelist
kokkulepet, millistel alustel, kelle vajadusi silmas pidades ja kuidas andmekoosseisu muudetakse,
arvestatakse andmevajaduse ja ligipääsetavusega. Tarvis on sihtrühmade andmevajaduste
kaardistust, mis annaks selgema aluse andmekoosseisu kujundamisele ning oleks aluseks
regulaarse andmevajaduste seire protsessi välja töötamisele. Kuivõrd varasemate analüüside
käigus on juba kogutud märkimisväärselt teavet sihtrühmade ootuste kohta, siis täiendavat
uuringut ei ole otstarbekas läbi viia, vaid tuleb koondada kokku olemasolevad teadmised eelnevalt
viidatud analüüsidest ja uuringutest.
2.1. Olulisemad sihtrühmad ja nende esindajad/kontaktisikud - kes ja milliseid EHRi andmeid ning
mille jaoks kasutab (andmekasutusjuhtumid)?
2.2. Millised on praeguse andmekoosseisu kujundamise alused (tüpoloogia)?
2.3. Kuidas ja millise sagedusega oleks otstarbekas andmevajaduste teavet uuendada?
2.4. Millised on klassifikaatorite kujundamise senised põhimõtted ja praktikad?
5
https://digiriik.ee/ (andmehaldus ja avaandmed)
6
https://www.stat.ee/sites/default/files/2022-06/AH_juhis_andmekirjeldus_standard_2.0.pdf
3. Andmevoogude kaardistus. Menetlustoimingute töövood on 2019 EHRi analüüsi käigus
kaardistatud ning sellega koos on loodud hea ülevaade toimingutest teatiste ja lubade
menetlemise raames7. Samas keskendub analüüs menetluskeskkonna vaatele ning ei sisalda täit
andmevoo ahelat, mis eelneb menetlustoimingu alustamisele ega järgnevaid aspekte, nagu
automaatsed süsteemitoimingud, andmete väljastamine päringu korral või kustutamine. Lisaks on
puudu selge arusaamine andmevoogudest, mida EHR kogub või peaks koguma väljaspool
ehitusega seotud menetlustoiminguid (nt energiamärgise esitamine, tehnoseadme
energiatõhususe andmed, muud andmekorje viisid). Selleks, et oleks võimalik tagada vastutus
andmete õigsuse eest ning tuvastada andmevigade võimalikud allikad, tuleks kaardistada täielikud
andmevoogude ahelad koos vastutavate osapooltega erinevates etappides (sh. kogumine,
säilitamine, muutmine, avaldamine ja kustutamine). Kaardistuse detailsuse tasand analüüsi
raames piirneb üldise süsteemi kirjeldusega – milliseid toiminguid andmetega ette võetakse,
millistes protsessides osalevad, milliste andmehalduse tegevustega on seotud ning millised on
süsteemi osade omavahelised seosed.
3.1. Millised on andmevood EHRi süsteemi jõudmise eelselt, EHRi süsteemi sees ning süsteemist
välja jõudmise punktid järgmiste andmeliikide lõikes:
3.1.1.ehitise menetluse käigus:
3.1.1.1. sisestatud ehitise andmed;
3.1.1.2. sisestatud dokumendid;
3.1.1.3. menetlustoimingute andmed;
3.1.1.4. kasutusandmed;
3.1.1.5. loodavad metaandmed ja logid.
3.1.2. Teistest andmebaaside andmete alusel kogutavad andmeväljad.
3.1.3. Energiamärgise ja üle 70kw nimivõimsusega tehnoseadmete andmed.
3.1.4. Andmeparandustööde käigus muudetavad andmed.
3.1.5. BIM-lahenduste spetsiifilised andmed.
3.1.6. Arhiiv.
3.2. Kuidas parendada EHRi süsteemisiseseid andmevooge ning nende haldamist?
4. Andmekoosseisu halduspõhimõtete kaardistamine. EHRi andmebaasi arhitektuur ja
andmekoosseisud on hetkel kirjeldatud ajakohasena hoitavas Enterprise Architecture failis. Samas
ei ole kasutusel ühtset andmekirjelduse reeglistikku, olemasolevad sõnastikud ei ole terviklikud
ega ajakohased ning olemasolev informatsioon andmeväljade kohta on lünklik8. Koos strateegiliste
eesmärkide täpsustamisega tuleb üle vaadata praegused andmehalduse praktikad ja nende
rakendamise ulatus ning järjepidevus (sh sisuliste andmeväljade kaetus selgitavate
kommentaaridega, kohustuslike tehniliste andmeväljade olemasolu jne.). Analüüsi käigus on vaja
luua terviklik ülevaade praegustest andmehalduse põhimõtetest ning puudustest.
4.1. Milline on andmekoosseisu kirjeldamise ja haldamise hetkeseis, praktikad ja kitsaskohad?
4.2. Milline on seis sõnastikega (hulk, andmeväljade kaetus, haldus) ja vajadus andmekvaliteedi
tagamiseks?
4.3. Milline on andmekoosseisu uuendamise protsess ja sagedus?
7
https://eehitus.ee/wp-content/uploads/2019/05/MKM_PwC_EHR_l%C3%B5pparuanne.pdf
8
ca. 1/4 andmelahtritest on ilma kirjelduseta, olemasolevad kirjeldused sisaldavad triviaalset teavet või ei ole
üheselt mõistetavad.
4.4. Millised on andmehalduse praegused tööprotsessid (nii dokumentides kajastuvad kui
tegelikud praktikad)?
5. Andmekogu jaotumine andmestikeks. Hetkel on EHR liigendatud kaheks andmekoguks:
ehitisregistriks ja võrgurajatiste andmebaasiks (VRA). Samas on probleemide kaardistamise käigus
ilmnenud vajadus eristada funktsionaalselt ja sisult erinevaid andmestikke (nt energiamärgistega
seotud andmed, statistilised andmed, isikuandmed, arhiiv/logid jne). Tehniliselt on võimalik uusi
andmeid koguda ja kuvada läbi dokumentide tabelisse täiendavate dokumendiliikide lisamise,
mida praegu ka kasutatakse näiteks energiamärgiste osas. Samas tekitab juba praegu erinevate
funktsioonide kuhjumine ühte ja samasse andmestikku andmekvaliteedi reeglite täpsustamisel
probleeme. Vaja on otsustada kas, millistel alustel (sisuliselt või funktsionaalselt) ja millisteks
andmestikeks tuleks EHR funktsionaalselt liigendada, et toetada maksimaalselt andmehalduse
teostust ning tagada andmete kvaliteet.
5.1. Kas ja kuidas oleks mõistlik EHR liigendada andmestikeks?
5.2. Kas ja millised on andmekogu andmestikeks jaotamise mõjud EHRi tehnilisele baasile?
6. EHRi andmehalduse raamistiku analüüs ja soovitused. Hetkel toimib EHRi andmehaldus mitmete
eriilmeliste dokumentide alusel, mis on koostatud peaasjalikult arendusprotsesside vajadusi silmas
pidades, ja kujunenud välja igapäevase töö käigus. Vaja on olemasoleva dokumentatsiooni, välja
kujunenud praktikate kaardistamist ja võrdlust teiste registrite andmehalduse kogemustega.
Järgnev loend andmehalduse raamistiku komponentidest on esialgne ning võib täpsustuda
analüüsi käigus.
6.1. Andmehalduse raamistiku komponendid ja nende seosed. Analüüsi käigus tuleb hinnata
vajadust erinevate andmehalduse raamistiku komponentide järgi ning pakkuda välja
terviklahendus koos vastavate osade uuenemisprotsessidega. Oodatavaks tulemuseks on
üldine süsteemitasandi kirjeldus koos esialgse tegevuskavaga, mis näeks ette järk-järgult
toimuva komponentide sisustamise, kasutusele võtmise ja juurutamise protsessi.
6.1.1. Millistest andmehalduse valdkonna standarditest ja parimatest praktikatest peaks
raamistiku juures lähtuma?
6.1.2. Millised on EHRi toimimiseks vajalikud andmehalduse raamistiku komponendid?
6.1.3. Millised on komponentide vahelised seosed ja koostoime?
6.1.4. Kuidas tuleks korraldada andmehalduse raamistiku uuendamist?
6.1.5. Millised on hinnanguliselt andmehaldus raamistikuga seotud kulud (sh. tööjõud ja raha)?
6.2. Andmekirjelduse reeglid. EHRi kirjeldav dokumentatsioon vajaks viimaste arenduste järel
uuendamist. Andmemudel on EHRil olemas ning uuendamine on reglementeeritud, kuid
andmeelementide ja -kogude tasandite kirjeldamisel puuduvad selgelt määratletud
raamistikud ning andmekirjelduste kvaliteet on seetõttu ebaühtlane. Vaja on koostada
andmekirjelduse reeglid, vastavalt kokkulepitud andmekoosseis kirjeldada ning avalikustada.
Antud analüüsi raamidesse jäävad andmekirjelduse reeglite koostamine, kirjeldamise
metodoloogia ja avalikustamise kirjeldamine.
6.2.1. Milliseid andmekirjeldamise komponente EHR vajab (sh. sõnastikud, klassifikaatorid,
andmekirjeldused)?
6.2.2. Millised peaksid olema eelnevate komponentide koostamise reeglid ja vormid?
6.2.3. Milliseid tarkvaralisi lahendusi peaks EHR andmehalduse tegevusteks kasutama (sh.
kaaluda RIHAKEse kasutust)?
6.3. Andmevoogude kirjeldamise metoodika. Analüüsi käigus kaardistatud üldisele
andmevoogude kirjeldusele lisaks tuleb välja töötada detailsema kirjelduse metoodika
komponentide tasandil, mis on seostatav andmemudeliga.
6.3.1. Millise metodoloogia alusel tuleks andmevoogude kirjeldust komponentide tasandil läbi
viia?
6.3.2. Millise tarkvaralise lahenduse abil oleks kõige otstarbekam andmevoogude kirjeldust
hallata?
6.4. Ligipääsude ja piirangute alused ning haldamine. Hetkel on Andmeaidale ja
arenduskeskkondadele ligipääsude haldamine delegeeritud MKMi välistele osapooltele.
Tehnilistele keskkondadele ligipääsude haldamisega seotud tasandeid, kasutusõigusi ja
ligipääsude andmise/ära võtmise tööprotsesse tuleb täpsustada.
6.4.1. Kas ja milliste keskkondade kasutajate ligipääsude haldamine tuleks võtta MKMi tööks?
6.4.2. Millised peaksid olema tehniliste keskkondade kasutajatasandid?
6.5. Klassifikaatorite haldamine ja uuendamine. EHRi klassifikaatorid on pidevas uuenemises.
Tuleb hinnata praeguse klassifikaatorite haldamise süsteemi otstarbekust ning
parandusvõimalusi ja uuendada seotud tööprotsesse.
6.5.1. Millised peaksid olema klassifikaatorite loomise metoodikad?
6.5.2. Kuidas paremini korraldada klassifikaatorite haldamist?
6.6. Andmekvaliteedi reeglid. EHRil puuduvad selgelt sõnastatud andmekvaliteedi kriteeriumid,
mis võimaldaksid üheselt hinnata registri eesmärkide täitumist, andmeparandustööde
prioriteetsust ja parandustööde tulemuslikkust. Lähtudes strateegilistest eesmärkidest tuleb
kriteeriumid kokku leppida, kirjeldada andmekvaliteedi reeglid (sh kvaliteedi kriteeriumid,
mõõdikud ja seiremehhanismid) ning vajalikud tööprotsessid.
6.6.1. Milline peaks olema andmete ärinõuete koostamise metoodika?
6.6.2. Millised peaksid olema andmete ärinõuded?
6.6.3. Millised peaksid olema andmekvaliteedi reeglid (sh mõõdikud)?
6.6.4. Millistel metodoloogilistel alustel tuleks koostada ja hallata andmete
automaatkontrolle?
6.6.5. Millised peaksid olema andmekvaliteedi tagamiseks vajalikud tarkvaralised lahendused
(sh dashboard)?
6.7. Tööprotsessid. Andmehalduse tööprotsessid toimivad hetkel kokkulepete ja väljakujunenud
praktikate alusel, kuid vajaks parema tulemuslikkuse saavutamiseks, töövoo ja -jaotuse
optimeerimiseks ning vastutuse selgitamiseks täpsustamist. Osa andmehalduse tagamiseks
vajalikest tööprotsessidest on kirjeldatud olemasoleva arendusdokumentatsiooni raames.
Tööprotsesse tuleb kirjeldada skeem diagrammidena rollide ja töövoogude vaates, kriitilised
otsustuskohad check-list’ina. Järgneb loetelu olulisematest tööprotsessidest, mis vajavad
käsitlemist, kuid mida tuleb analüüsi tulemusena vajadusel täpsustada ja täiendada:
6.7.1. andmehalduse korraldamine ja juhtimine, sh strateegiliste eesmärkide ja andmehalduse
raamistiku uuendamine;
6.7.2. andmevoogude haldamine (sh kogumine, säilitamine, kustutamine);
6.7.3. sõnastike haldamine;
6.7.4. andmebaasi andmekoosseisu haldamine ja uuendamine;
6.7.5. andmekirjelduste haldamine ja avalikustamine;
6.7.6. klassifikaatorite haldamisega ja uuendamisega seotud tööprotsessid;
6.7.7. ligipääsude haldamine;
6.7.8. andmekvaliteedi tagamine;
6.7.9. andmekvaliteedi reeglite uuendamine;
6.7.10. andmeparandustööde teostamine;
6.7.11. automaatkontrollide haldamine;
6.7.12. ligipääsude haldamine.
6.8. Rollid ja vastutus. Hetkel on EHRi talituse liikmete vastutus määratletud peamiselt
ametijuhendites. On valdkondi ja töölõike, kus vastutus pole täpselt paika pandud ning vajaks
selgitamist. See on osa tööprotsesside kaardistamisest.
6.9. Andmete säilitamise alused. Hetkel ei ole seatud EHRi andmete säilitamisele lõpp kuupäeva,
vaid põhimääruses on viide arhiiviseadusele, mis üldsättena ei reguleeri iseseisvate
andmekogude andmete säilitamist.
6.9.1. Millise metodoloogia alusel tuleks otsustada andmete säilitamise mõistlik aeg?
6.9.2. Kuidas tagatakse säilitusaja reeglite rakendamine?
Metoodika ja meetodid
Töö teostamise metoodika pakub välja uuringu teostaja. Metoodika peab hõlmama analüüsi nii
olemasolevate andmete kui ka uuringu käigus kogutud kvalitatiivsete ja kvantitatiivsete andmete
põhjal. Lähteandmeteks on nii sissejuhatuses loetletud varasemad uuringud, analüüsid ja
juhendmaterjalid ning tellija poolt esitatav andmebaasi arendusnõuete, arhitektuuri ja haldusega
seotud dokumentatsioon. Vastavalt vajadusele korraldatakse analüüsi käigus intervjuusid (teiste
andmekogude praktikate osas 3-5 riikliku andmekogu haldajaga), töötubasid ning ümarlaudu koos
EHRi poolse töörühmaga. Töörühma koosseis kinnitatakse lähteülesande täpsustamise käigus (vt. „Töö
etapid ja tähtajad“).
Töö etapid ja tähtajad
Töö koosneb järgmistest etappidest:
1. Avakohtumine tellija ootuste, töö metoodika ja MKMi poolse töörühma koosseisu selgitamiseks
kahe nädala jooksul pärast hankelepingu sõlmimist.
2. Analüüsi täpsustatud tööplaani esitamine Tellijale ühe kuu jooksul pärast hankelepingu
sõlmimist.
2.1. vajadusel tööplaani täiendamine vastavalt Tellija tagasisidele;
2.2. tööplaani kinnitamine tellija poolt;
3. Analüüsi vahearuande esitamine Tellijaga avakoosolekul kokku lepitud tähtajal, kuid mitte hiljem
kui kolm kuud pärast hankelepingu sõlmimist. Vahearuanne annab ülevaate seni tehtud töödest
(analüüsi 1-5 punkt) ja vastavusest ajakavale.
3.1. vajadusel vahearuande täiendamine vastavalt tellija tagasisidele;
3.2. vahearuande kinnitamine tellija poolt.
4. Analüüsi lõpparuande esitamine tellijale avakohtumisel kokku lepitud tähtajal, kuid mitte hiljem
kui kuus kuud pärast hankelepingu sõlmimist vastavalt „Analüüsi väljundid“ peatükis kirjeldatud
loetelule.
4.1. vajadusel lisakohtumised lõpparuande sisu täpsustamiseks ja viimistlemiseks;
4.2. lõpparuande kinnitamine tellija poolt.
Analüüsi väljundid
Töövõtja peab esitama töö tulemina lõpparuande, mis kirjeldab analüüsi metoodikat ja tulemusi.
Aruanded (nii vahearuanne kui ka lõpparuanne) peavad olema lihtsalt loetavad, ühtse stiiliga ja
sisaldama kokkuvõtvat, peamisi järeldusi ja soovitusi sisaldavat peatükki. Lõpparuanne peab
sisaldama vähemalt järgmisi osasid:
1. Metodoloogia ja analüüsi käigus läbi viidud tegevuste kirjeldus.
2. Parimate praktikate intervjuude kokkuvõte.
3. Analüüsiküsimuste punktide 2-5 käigus teostatud kaardistuste kokkuvõte ja seosed välja
pakutava andmehalduse raamistikuga.
4. EHRi andmehalduse raamistiku, eraldiseisvate komponentide, nendevaheliste seoste ja
uuendamise protsessi tervikkirjeldus.
5. Tegevuskava (4 a perspektiivis) andmehalduse raamistiku juurutamiseks.
6. Lisad:
6.1. EHRi andmete jaotus andmestikeks koos kirjeldusega (Exceli tabelina või muus sobivas
vormis);
6.2. EHRi andmehalduse komponendid (skeemina);
6.3. Andmekirjelduse komponentide vormid (Exceli tabelina või muus sobivas vormis);
6.4. Andmete ärinõuete loetelu (Exceli tabelina või muus sobivas vormis);
6.5. Andmekvaliteedi reeglid (Exceli tabelina või muus sobivas vormis);
6.6. Andmevoogude kaardistused (skeemidena);
6.7. Tööprotsesside nimekiri ja kirjeldused (rollid, vastutajad, diagrammid ja check-list’id);
6.8. Automaatkontrollide tabeli vorm (Exceli tabelina või muus sobivas vormis).
Ajakava ja töökorraldus
1. Töövõtja juhib analüüsi koostamist ja teostab töö.
2. Analüüs tuleb teostada ja tulemused tuleb esitleda hiljemalt kuus kuud pärast lepingu sõlmimist.
3. Tellijal on õigus vajadusel edastada eduka pakkuja töödele täiendavaid suuniseid.
4. Töövõtja esitab ülevaate töö käigust, edusammudest ja tekkinud takistustest Tellija esindajale
vähemalt kord kuus.
5. Töövõtja peab olema valmis Tellija soovil asendama töölõike samaväärsetega, kui töö teostamise
käigus selgub, et vahetus aitab paremini saavutada töö eesmärke.
Tellijapoolne meeskond
Projektijuht: Rasmus Kask, EHRi andmeparandustööde projektijuht, Tellija esindaja.
Taavi Jakobson, EHRi talituse juhataja.
Tellija võib kaasata ka teisi liikmeid vastavalt vajadusele nii Tellija organisatsioonist kui ka teistest
organisatsioonidest.
Lisad
Lisa 1. EHRi andmebaasi arhitektuur (Enterprise Architect fail)
Lisa 2. EHRi andmebaasid ja nende uuendamine (juhend)
Ehitisregistri andmebaasid ja nende uuendamise juhend
V3 04.01.2023
Dokumendi eesmärk on kirjelda Ehitisregistri (EHR) ja e-ehituse infrastruktuuris olevad andmebaasid
ning nende uuendamise protsess, et tagada andmebaasides andmete kooskõla ning andmebaaside
vaheliste konfliktide vältimine.
EHR arhitektuur baseerub mikroteenuste kontseptsioonil vt. Ehitisregistri arhitektuur. Tänane EHR on
liikumas monoliitselt arhitektuurilt mikroteenuste arhitektuurile, kasutades järkjärgulisel
ümberkujundamisel baseeruvat metoodikat („Brownfield development“).
Esialgne EHR Oracle andmebaas - edaspidi EHR monoliit sisaldas kogu EHR andmestikku. Lisaks
monoliidile on kasutuses EHR „andmeaida“ Postgre andmebaas, kuhu kogutakse kõik EHR baasis
toimuvad sündmused ning EHR VRM Oracle andmebaas, kus hoitakse võrgurajatiste mooduliga
seotud andmeid. EHR monoliitbaasis hoiti 2019 aasta lõpuni lisaks eraldi skeemidena Hooneregistri ja
EHR 1 andmeid.
Vastavuses mikroteenuste kontseptsioonile võetakse EHR infrastruktuuris kasutusele uute
teenustega seotud andmebaasid ning seetõttu on oluline tagada uute ja olemasolevate
andmebaaside omavaheline kooskõla. Selle saavutamiseks rakendatakse uus roll EHR „Data
steward“, kelle vastutusel on EHR andmebaaside kooskõlas hoidmine.
EHR andmebaasi loogiline kirjeldamine ning edasiarendamine toimub Enterprise Architect tööriista
kasutades.
EHR andmebaaside loetelu
1. EHR Oracle baasid:
a. Toodang
b. Test
c. Test2
d. Test3
2. EHR PostgreSQL baasid
a. Server Toodang (10.20.41.28) baasid
i. Ehrdb skeemid
1. Dsa
2. Eehitus – ehitis, dokument, menetlus, failid
3. Geo
4. Kasutaja
5. Keycloak
6. Koodid - kooditabelid
7. Pglogical
8. Public
9. Sync
10. teavitus
ii. Ehrdb_geo skeemid
1. Ap
2. Dsa
3. Geo – aadressid, katastriüksused, kaardiotsing, ADS sync logid
4. Pglogical
5. Public
6. synk
iii. Ehrdb_kasutaja skeemid
1. Dsa
2. Geo
3. Kasutaja – isikud, kasutajad
4. Keycloak
5. Koodid
6. Pglogical
7. Public
8. Sync
iv. Postgres
v. Ylddb skeemid
1. Public
2. Yld_infoleht
3. Yld_kiirlink
4. Yld_teade
b. Server toodangXtee (10.20.41.25) baasid
i. Ehrxtee skeemid
1. Dw – ehitise kehtivad ja xtee andmed
2. Psa
3. Public
4. Xtee
ii. Postgres
c. Server ToodangAndmeait
d. Server Prelive (10.20.41.42) baasid
i. Ehrdb_geo_prelive
ii. Ehrdb_kasutaja_prelive
iii. Ehrdb_prelive
e. Server Development (10.20.43.46) baasid
i. Ehr_bimworks_test
ii. Ehr_db_model
iii. Ehr_suhtlus
iv. Ehrdb
v. Ehrdb_geo
vi. Ehrdb_geo_test *
vii. Ehrdb_kasutaja
viii. Ehrdb_kasutaja_test *
ix. Ehrdb_test *
x. Postgres
xi. Yldb
xii. Yldb_test
f. Server testXtee (10.20.43.54) baasid
i. Ehrdw
ii. Ehrxtee
iii. Ehrxtee_prelive
iv. Ehrxtee_test
v. Postgres
3. EHR Redis baasid
a. Development Redis
b. Development Redis Bit
c. Test Redis
d. Test Redis Bit
e. Prelive Redis
f. Prelive Redis Bit
g. Toodang Redis
h. Toodang Redis Bit
EHR andmebaasi analüüs ja arendamine
1. Analüüsi lähteandmeteks on SP-s paiknev EA fail EHR andmemudelid ja selles olevad
andmebaaside skeemid:
a. <Datamodel>Oracle – EHR Java rakenduse andmebaasi skeemi EHR andmetabelid,
vaated (Oracle andmebaas)
i. <Datamodel> YHR – hooneregistri andmebaasi skeem (Oracle andmebaas)
ii. <Datamodel>SHR – ehr1 rakenduse andmebaasi skeem (Oracle andmebaas)
iii. <Datamodel> YHR – hooneregistri andmebaasi skeem (Oracle andmebaas)
iv. <Datamodel>VRM – VRM e. võrgurajatiste andmebaasi skeem (Oracle
andmebaas)
v. <Datamodel> EHRGIS – EHR GIS rakenduse skeem (Oracle andmebaas),
rakendus pole enam kasutusel
vi. <Datamodel>DOGISCONTEXT – EHR kaardirakenduse (XGIS) skeem (Oracle
andmebaas)
b. Andmebaasi Andmeait (Postgre) skeemid:
i. DW - core data (tabelid)
ii. DM - datamardid andemekaevurile (materialiseeritud vaated)
iii. RVA - väljundvaated erinevatele rakendustele (tabelid, materialiseeritud
vaated)
iv. RVA_VIEW - vaated kasutajatele (andmekaevur, aruande koostaja)
v. KOV - statistika portaali andmed (tabelid, funktsioonid )
vi. PPA- politsei ja piirivalve (tabelid, funktsioonid)
vii. PSA - laadimisteks staging area (tabelid ja funktsioonid)
viii. SB - andmekaevuri sandbox (kasutaja poolt loodud abitabelid)
c. Andmebaasi Xtee (Postgre) skeem “xtee” x-tee teenuste andmetabelid ja
funktsioonid
d. Mikroteenuste andmebaasid (Postgre). Andmebaasides on iga mikroteenuse API
jaoks oma skeem.
i. Ehrdb_geo.geo – ehitiste ja KÜ aadressid, ruumikujud, geootsingute tabelid,
ads sünkronieerimise logid
ii. Ehrdb.eehitus – dokumendid, ehitise täiskirjed, menetlused, failid
iii. Ehrdb_kasutaja.kasutaja – isikud, kasutajad, rollid, õigused
iv. Ehrdb.koodid - kooditabelid
2. Füüsiliselt andmebaasis olemas olevad tabelid/veerud/vaated jm. objektid peavad olema
tähistatud EA staatusega „Implemented“.
3. EHRi andmebaasides muudatuste tegemiseks koostab arendaja/analüütik esmalt muudatuse
EA mudeli ja kooskõlastab selle EHR "Data stewardiga". Kooskõlastuse palvele lisab ta lühida
põhjenduse ja – juhul kui see on konkreetsel juhul mõistlik – viite(d) arenduse JIRA
piletile/piletitele. "Mudeli koostamisel tuleb kasutada uutel või muudetavatel elementidel EA
staatust „Proposed“, et eristada plaanitavaid muudatusi juba kasutusel olevatest objektidest.
Mudeli kohta peab olema koostatud ERD joonis, millel on kujutatud kõiki tabeleid ja view-sid,
mis on seotud käesoleva arendusega.
4. EHR „Data steward“ tellib vajalike muudatuste sisseviimise ka teistesse EHR
andmebaasidesse nagu „andmeait“ jm. koostades selleks JIRA arenduspiletid ja suunates
need hooldajatele.
5. Peale kooskõlastuse saamist tuleb koostada andmebaasi muutmiseks SQL-d ja esitada need
vastavuses EHR koodi haldamise ja tarnimise juhendile
6. Peale andmebaasi uuendamist tuleb uuendada SP-s paiknev EA faili EHR andmemudelid ning
viia muudatused staatusesse „Implemented“.
7. EA mudelit võivad samaaegselt muuta mitmed isikud ja seetõttu peab viimasena muudatusi
teinud isik ühildama oma muudatused EA faili kõige viimasesse versiooni. Selleks, et
muudatusi oleks lihtsam ühildada tuleb enne muutmist EHR „data stewardiga“ kooskõlastada
muudatuste ulatus.
Andmetabelite ja atribuutide nimetamise reeglid
1. Tabelid ja atribuudid on eesti keeles v.a. : created_by, date_created, updated_by,
date_updated, deleted_by, date_deleted
2. Kõik tabelid ja atribuudid peavad olema kommenteeritud ning kommentaarid peavad andma
ülevaate tabeli ja atribuudi eesmärgist ning vajadusel ka kasutamise reeglitest
3. Tabelite nimedes tuleb kasutada prefiksit, mis tähistab objekti, mida tabel kirjeldab näiteks:
do – dokument, eh – ehitis, ad – aadress, ak – kasutaja, kl – klassifikaator.
4. Tabeli nimetamisel tuleb lähtuda tabeli eesmärgist ja üldjuhul peaks tabeli nimi olema:
objekt_alamobjekt_seos_seose_liik. Näiteks do_doku on dokumendi objekti tabel, do_ehitis
on dokumendil olevate ehitiste tabel, do_doku_ehitis_rel on dokumendi ja dokumendi
ehitiste omavaheliste seoste tabel.
5. Juhul, kui kasutatakse vaadet (view), mis on replikeeritud koopia mõnest teisest
andmebaasist siis lisatakse tabeli nimetuse ette r_. Näiteks eehitus.r_ad_aadressid on
aadressi tabeli koopia ‘ehrdb_geo’ andmebaasist. Andmete tabel ise asub ehrdb_geo.geo
skeemis, kus toimub andmete create, update, delete operatsioonid. Aadresside kasutamiseks
ehrdb baasis on ad_aadressid tabel replikeeritud ning talle on lisatud vaade mis asub
andmebaasi vastava skeemi view-de kataloogis ehk näiteks saab ehrdb baasis kasutada
ehrdb_geo baasis asuvaid aadresse ehrdb baasi view-st eehitus.r_ad_aadressid.
Andmetabelites kasutatavad standardväljad
1. Kõikides tabelites tuleb kasutada standardvälju ja nendele määratud andmetüüpe:
a. created_by character varying(120) COLLATE pg_catalog."default" NOT NULL
DEFAULT USER,
b. date_created timestamp(6) without time zone NOT NULL DEFAULT now(),
c. updated_by character varying(120) COLLATE pg_catalog."default",
d. date_updated timestamp(6) without time zone,
e. deleted_by character varying(120) COLLATE pg_catalog."default",
f. date_deleted timestamp(6) without time zone
2. Väljad tuleb täita iga kord kui kirjega toimub vastav sündmus:
a. Date_created ja created_by kui toimub INSERT
b. Date_updated ja updated_by, kui toimub UPDATE, välja arvatud juhul kui samal ajal
täidetakse date_deleted ja deleted_by
c. Date_deleted ja deleted by, kui kirje loogiliselt kustutatakse
3. Date väärtused täita kas now() või current_timestamp
4. By väärtused täita juhul, kui on olemas kehtiv access_token siis tokenist võetud väärtustega:
ehr.firstName + ‘ ‘ + ehr.lastName + ’ ‘ + ‘(‘ + ehr.activeRole.userId + ‘)’. Juhul kui access
token puudub siis Tellijaga kokku lepitud väärtusega.
Andmetüüpide kasutamine
1. Märke sisaldavatel andmeväljadel tuleb kasutada igal pool kus võimalik Postgre tüüpi varchar
koos määratud pikkusega, mis vastab väljal kasutatavale max märkide arvule.
2. Pikkade tekstide sisestamise vajadusel tuleks kasutada manusena lisatavat faili. Ehk kasutaja
võiks pika teksti sisestamiseks üles laadida tekstifaili do_fail tabelisse.
3. Text andmetüübi kasutust tuleb vältida ning kasutada seda ainult juhul, kui selleks on tungiv
äriline vajadus ning pole võimalik kasutada manuseks lisatavat faili.
4. Timestamp välja puhul kasutada alati andmetüüpi timestamp(6) without time zone
EHR andmebaasi hooldusprotsessis tehtavad muudatused
1. EHR andmebaasi pisimuudatused, mis tehakse hooldusprotsessi käigus vigade paranduse või
pisiarenduse eesmärgil nagu välja pikkuse muudatus, uus indeks vms. tuleb kooskõlastada
EHR „Data stewardiga“. Kooskõlastamiseks saadab hooldustöö tegija (arendaja) plaanitavate
muudatuste SQL skripti, viite JIRA veapiletile, mida lisatud skript parandab, JIRA
paigalduspiletile ja vajadusel põhjenduse ning saadab selle „Data stewardile“.
2. EHR „Data steward“ kooskõlastab muudatuse ning suunab pileti arendajale tagasi. Arendaja
esitab pileti vastavuses EHR koodi haldamise ja tarnimise juhendile.
3. „Data steward“ uuendab vastavalt SQL-le SP-s paiknev EA faili EHR andmemudelid ning
vajadusel loob JIRA arenduspiletid hooldajatele muudatusega seotud ülejäänud
andmebaaside kooskõlla viimiseks.
Andmetabelitest kirjete kustutamine
1. EHRi andmetabelitest kirjete füüsiline kustutamine on üldjuhul keelatud. Erandiks on ajutised
või tehnilised andmetabelid, mille kirjed ei ole EHRi tavakasutajatele näha ja ei või mõjutada
nende tööd.
2. Kirje kustutamisel tuleb täita andmeväljad date_deleted ja deleted_by. Päringutes tuleb
arvestada, et juhul kui need väljad on täidetud siis on kirje loogiliselt kustutatud.
3. Juhul, kui andmetabelis on kasutusel oper väli siis kirje kustutamise alustamisel tuleb täita
oper = ‘D’. Kirje kustutamise lõpetamisel tuleb täita deleted_by ja date_deleted.
4. Andmevigade parandamine toimub üldjuhul koos dokumendi (registri paranduskanne, AET)
loomisega, parandatava kirje kehtivuse peatamise ja uue kirje loomisega.
5. Teatud olukordades võib olla mõistlik kirjeid siiski kustutada – näiteks dokumendid, mida
kasutaja on alustanud, kuid ei ole kunagi esitanud ja mille puhul ei ole tõenäoline, et kasutaja
seda kunagi esitaks (mitme kuu jooksul ei ole infot uuendatud) või programmkoodi poolt
loodud sisutud topeltkirjed.
Sellisel juhul peab kirje kustutamise soovija vastava plaani „Data stewardiga“ kooskõlastama,
tuues välja põhjuse, miks andmeid kustutatakse, näidates ära võimalikud kustutatavate
andmete seosed ja nende haldamise viisi ning – kui otstarbekas ja kooskõlas isikuandmete ja
riigikaitseliste asutuste andmete käitlemise regulatsioonidega – saatma talle kustutatavad
andmed tabelina.
„Data stewardi“ ülesanne on ennekõike hinnata ega see tegevus ei too kaasa kasutajatele
komplikatsioone, ei riku potentsiaalselt seotud osapoolte (kasutajad, arendajad, vastutav
töötleja) õigusi, ei riku andmebaasi konsistentsust ega too kaasa tõrkeid EHRi töös ja määrata
tingimused, kas, kuidas ja millal vastava operatsiooni läbi viimine lubada.
Oper väli andmetabelites
1. Oper välja kasutatakse dokumendiga seotud ehitise täiskirje tabelites kirjega dokumendil
toimunud operatsiooni näitamiseks. Koos oper väljaga tuleb üldjuhul täita ka andmetega
toimunud operatsioonile vastavad väljad vt. P. _Andmetabelites_kasutatavad_standardvälj
2. Ehitise täiskirje andmete kopeerimisel uuele dokumendile muudetakse oper = A. Ehitise
täiskirje kopeerimisel uuele dokumendi versioonile jäävad oper väljad samaks nagu olid
eelmisel versioonil.
3. Dokumendile kirje lisamisel oper = I
4. Dokumendil kirje muutmine muuta olemasolev oper = U
5. Dokumendilt kirje kustutamisel muuta oper = D. Juhul, kui kirje kustutamine toimub
protsessina, kus kustutamine algab, seejärel kontrollitakse kustutamise eelduseid ja
kustutamine lõppeb eelduste olemasolul siis protsessi alguses täidetakse oper = D ja
protsessi lõpus kustutamise standardväljad.
Dokumendi muudatused
V2.2 20.04.2022 Ülo Puskar Lisatud osa „EHR andmebaaside loetelu“
V2.1 23.03.2020 Taavi Jakobson Lisatud osa „Andmetabelitest kirjete kustutamine“
V2 06.11.2019 Ülo Puskar
V3 04.01.2023 Ülo Puskar Lisatud oper väljade kasutamine