<

OTSUS

Vaidlustusasja number

204-26/311568

Otsuse kuupäev 26.10.2026

Vaidlustuskomisjoni liige Taivo Kivistik

Vaidlustus Ühispakkujate Cybernetica AS ja OÜ Quretecvaidlustus

Tervise ja Heaolu Infosüsteemide Keskuse riigihankes

„Tervisejuhtimise töölaua platvormi arendus- ja

hooldustööd“ (viitenumber 311568) hankija otsusele

tunnistada edukaks Industry62 OÜ pakkumus

Menetlusosalised

Vaidlustuse läbivaatamine

Vaidlustaja, ühispakkujad Cybernetica AS ja OÜ Quretec,

esindaja Oliver Väärtnõu

Hankija, Tervise ja Heaolu Infosüsteemide Keskus,

esindaja Katrin Keert

Kolmas isik, Industry62 OÜ

Kirjalik menetlus

RESOLUTSIOON

RHS1 § 197 lg 1 p 4 ja § 198 lg-de 3 ja 8 alusel

1. Jätta rahuldamata ühispakkujate Cybernetica AS-i ja OÜ Quretec vaidlustus Tervise

ja Heaolu Infosüsteemide Keskuse riigihankes „Tervisejuhtimise töölaua platvormi

arendus- ja hooldustööd“ (viitenumber 311568).

2. Jätta ühispakkujate Cybernetica AS-i ja OÜ Quretec menetluskulud nende endi kanda.

EDASIKAEBAMISE KORD

Halduskohtumenetluse seadustiku § 270 lg 1 alusel on vaidlustuskomisjoni otsuse peale

halduskohtule kaebuse esitamise tähtaeg kümme (10) päeva arvates vaidlustuskomisjoni otsuse

avalikult teatavaks tegemisest.

JÕUSTUMINE

Otsus jõustub pärast kohtusse pöördumise tähtaja möödumist, kui ükski menetlusosaline ei

esitanud kaebust halduskohtusse. Otsuse osalisel vaidlustamisel jõustub otsus osas, mis ei ole

seotud edasikaevatud osaga (riigihangete seaduse § 200 lg 4).

1 Riigihangete seadus.

2 (34)

ASJAOLUD JA MENETLUSE KÄIK

1. 18.06.2026 avaldas Tervise ja Heaolu Infosüsteemide Keskus (edaspidi ka Hankija)

riigihangete registris (edaspidi RHR) avatud hankemenetlusega riigihanke „Tervisejuhtimise

töölaua platvormi arendus- ja hooldustööd“ (viitenumber 311568) (edaspidi Riigihange)

hanketeate ja tegi kättesaadavaks muud riigihanke alusdokumendid (edaspidi koos nimetatult

RHAD), sh Proovitöö lähteülesande (edaspidi Lähteülesanne) ja hindamismetoodika kirjelduse

(edaspidi Hindamismetoodika).

Pakkumuste esitamise tähtpäevaks, 27.07.2026, esitasid pakkumused 7 pakkujat, teiste seas

Industry62 OÜ ning ühispakkujad Cybernetica AS ja OÜ Quretec.

2. 17.09.2026 otsusega tunnistas Hankija edukaks Industry62 OÜ pakkumuse.

3. 28.09.2026 laekus Riigihangete vaidlustuskomisjonile (edaspidi vaidlustuskomisjon)

ühispakkujate Cybernetica AS-i ja OÜ Quretec (edaspidi ka Vaidlustaja) vaidlustus Hankija

otsusele tunnistada edukaks Industry62 OÜ pakkumus.

4. Vaidlustuskomisjon teatas 05.10.2026 kirjaga nr 12.2-10/204 menetlusosalistele, et vaatab

vaidlustuse läbi esitatud dokumentide alusel kirjalikus menetluses, tegi teatavaks otsuse

avalikult teatavaks tegemise aja ning andis täiendavate seisukohtade ja dokumentide

esitamiseks aega kuni 08.10.2026 ja neile vastamiseks 13.10.2026. Vaidlustuskomisjoni

määratud esimeseks tähtpäevaks esitas täiendavad seisukohad Vaidlustaja. Teiseks tähtpäevaks

esitas täiendavad seisukohad Hankija. Kolmas isik vaidlustusmenetluses seisukohta ei esitanud.

5. Käesolevas vaidlustusasjas on Vaidlustaja ja Hankija oma menetlusdokumentides kajastanud

andmeid, mida Vaidlustaja käsitleb oma ärisaladusena. RHS ei näe ette, et kogu

vaidlustusmenetluse saaks kinniseks kuulutada, vaidlustuskomisjoni otsus tuleb üles laadida

RHR-i. Vaidlustaja ärisaladuse kaitseks on vaidlustuskomisjon koostanud käesolevast otsusest

kaks versiooni:

1) otsuse täielik versioon, millest Vaidlustaja ärisaladusi sisaldavaid osi eemaldatud

pole, tehakse teatavaks Vaidlustajale ja Hankijale;

2) otsuse versioon, millest on eemaldatud Vaidlustaja ärisaladust puudutavad osad, mis

on tähistatud märkega [Vaidlustaja ärisaladus] tehakse teatavaks Kolmandale isikule ning

laaditakse üles RHR-i.

MENETLUSOSALISTE PÕHJENDUSED

6. Vaidlustaja, ühispakkujad Cybernetica AS ja OÜ Quretec, põhjendab vaidlustust

järgmiselt.

6.1. Vastavalt Hindamismetoodikale hinnati pakkumusi hindepunktide kogusumma alusel,

mille maksimaalne võimalik arv on 100 hindepunkti ja millest on:

1) ühe töötunni hind ilma käibemaksuta – 10% hindest;

2) proovitööd – 90% hindest.

Vastavalt Hindamismetoodikale annab Hankija proovitööde eest hindepunkte eraldi proovitöö

nr 1 ja proovitöö nr 2 osas. Proovitööde eest on võimalik summeerituna saada kokku 90

hindepunkti, millest:

1) Proovitöö nr 1 eest on võimalik saada maksimaalselt 50 hindepunkti;

2) Proovitöö nr 2 eest on võimalik saada maksimaalselt 40 hindepunkti.

Kummagi proovitöö hindamiseks sätestas Hankija kriteeriumid punktide andmiseks vastavalt

Hindamismetoodikas toodud skaalale. Kriteeriumidele antud punktide tulemused

3 (34)

summeeritakse ja leitakse seeläbi proovitööle omistatud punktid.

Proovitöö hindamisel annab Hankija iga hindamiskriteeriumi eest punktid kõrgeima

punktitaseme järgi, mille kõik tingimused on täidetud.

6.2. 17.09.2026 edastas Hankija Vaidlustajale väljavõtte hankekomisjoni hindamisprotokollist

(edaspidi Protokoll), millest nähtub, et Kolmanda isiku proovitööle omistas Hankija

maksimaalsed 90 punkti. Vaidlustaja proovitööle omistas Hankija 60 punkti. Koos ühe töötunni

hinna eest antud punktidega sai Kolmanda isiku pakkumus kokku 97,46 punkti ja Vaidlustaja

pakkumus 69,11 punkti. Kolmanda isiku pakkumus tunnistati edukaks.

Hankija omistas Vaidlustaja proovitööle nr 1 20 punkti. Vaidlustaja proovitööd nr 1 on hinnatud

liiga madalalt. Kui Hankija oleks Vaidlustaja proovitööd nr 1 hinnanud maksimaalse 50

punktiga, oleks Vaidlustaja pakkumus saanud kokku 99,11 punkti ning osutunud edukaks.

Hankija on Vaidlustaja proovitöö nr 1 hindamisel tõlgendanud Hindamismetoodikat

meelevaldselt. Hindamismetoodikat õigesti kohaldades oleks Vaidlustaja proovitöö nr 1 saanud

maksimaalsed 50 punkti.

6.3. Vaidlustaja proovitööle nr 1 omistas Hankija 20 punkti järgmiste komisjoni põhjendustega:

Prototüübis on mitmed lahendused heal tasemel. Hästi olid lahendatud rollipõhine kasutamine,

andmete olekute kuvamine, infoplokkide ja detailvaadete kasutamine. Prototüübis olid esitatud

mõlema rolli töövajadusi toetavad lahendused ning rollivahetus ja seadistuste salvestamine.

Olulisemad puudused esinesid seadistatava töölaua toimivuses. Mitmed seadistamise

võimalused olid prototüübis küll visuaalselt esitatud, kuid ei olnud klikitavad ning kasutaja ei

saanud neid ise läbi teha (töölaua seadistamise alla oli toodud kaks näidet, kus on näide 1 on

algseadmed ja näide 2 on töölaua seaded muudetud, kuid kasutaja ei saanud seadistust ise läbi

mängida, mis on klikitava prototüübi eelduseks). Infoploki seadistamisel sai määrata

kuvatavaid andmeid ja nende kuvamise järjekorda, kuid puudus võimalus seadistada

andmemahtu ja info prioriteetsust. Infoplokkide ümberjärjestamine oli samuti piiratud –

lahendus võimaldas plokke üles-alla liigutada näidetena, kuid mitte läbi klikitava prototüübi

ehk terviklikku ümberpaigustamist ei olnud võimalik läbi teha. Riski-ja ohutegurid ei olnud

rollide lõikes järjepidevalt esitatud: kiirabi vaates olid need vahetult nähtavad, kuid perearsti

vaates tuli vastava info leidmiseks teha täiendav klikk (ehk tänane TJT lahendus, ikooniga

kuva). Desktop- ja tahvlivaadetes oli ruumikasutus ebaproportsionaalne ja väga õhuline, nt

tahvlivaates oli korraga nähtav vaid üks infoplokk. Seadistamiseks tuli liikuda eraldi vaatesse,

mistõttu ei olnud muudatuse mõju seadistamise hetkel töölaual nähtav. Lahendus vastas 20

punkti tasemele, sest hindamiskriteeriumites vastasid 20 punkti tasemele järgmised tükid:

seadistava töölaua terviklahendus, infoploki seadistamine, infoploki ümberjärjestamine, riski-

ohutegurite käsitlemine, desktop ja tahvli vaate teostus.

6.4. Vaidlustaja esitab vastuväited proovitöö nr 1 nende hindamiskriteeriumide lõikes, milles

Hankija tuvastas väidetavad puudused.

6.4.1. Seadistatava töölaua terviklahendus

Hankija on kriteeriumi osas kommenteerinud: Olulisemad puudused esinesid seadistatava

töölaua toimivuses. Mitmed seadistamise võimalused olid prototüübis küll visuaalselt esitatud,

kuid ei olnud klikitavad ning kasutaja ei saanud neid ise läbi teha (töölaua seadistamise alla

oli toodud kaks näidet, kus on näide 1 on algseadmed ja näide 2 on töölaua seaded muudetud,

kuid kasutaja ei saanud seadistust ise läbi mängida, mis on klikitava prototüübi eelduseks).

Hankija etteheide, et prototüübis polnud kõik seadistamise võimalused „läbi klikitavad“, on

vastuolus Hankija poolt teabevahetuses antud selgitustega.

6.4.1.1. Hindamismetoodika kohaselt antakse „Seadistatava töölaua terviklahenduse“ eest 50

punkti järgmiselt: Prototüüp võimaldab kasutajal lisada, eemaldada infoplokke, muuta

4 (34)

infoplokkide järjestust, seadistada infoplokkides kuvavat infot ning salvestada seadistused

rollipõhiselt. Kõik nimetatud tegevused on kasutajale leitavad, arusaadavad ning moodustavad

tervikliku seadistamise lahenduse ning kasutaja saab seadistamise tulemust töölaual näha.

Vaidlustaja proovitöö nr 1 täidab kõik 50 punkti taseme eeldused, arvestades RHAD-is ja

RHR-is sätestatud prototüübi eesmärki ja tasemetäpsust. Hankija on teabevahetuses kinnitanud,

et UX/UI prototüübilt ei eeldata pärisrakenduse toimimisloogikat ega kõigi harude

läbiklikitavust:

1) 07.07.2026 kell 13.412 selgitas Hankija vastuses küsimusele, et Figma prototüübilt ei

eeldata täielikku rakendusloogika toimimist samas ulatuses nagu töötavalt rakenduselt.

Konfiguratsiooni salvestamise, rakendamise, infoplokkide järjestuse muutmise ja seadistuste

kuvamise demonstreerimiseks lubati kasutada esinduslikke vaateid, olekuid, kasutajateekondi

ning vajadusel selgitavaid märkusi, ega nõutud kõigi konfiguratsioonide täielikku

realiseerimist;

2) 07.07.2026 kell 13.463 antud vastuses täpsustas Hankija sõnaselgelt seoses

infoplokkide lisamise, eemaldamise, ümberjärjestamise ja seadistamisega, et prototüübis ei pea

realiseerima tegelikku andmete salvestamise ega püsivuse tehnilist loogikat;

3) 07.07.2026 kell 13.474 antud vastuses eristas Hankija selgelt kontseptsiooni ja

kasutajateekondi hindavat esimest osa töötavat tehnilist lahendust hindavast teisest osast.

6.4.1.2. Vaidlustaja teostas lahenduse Hankija juhiste kohaselt. Prototüüp viis kasutaja läbi

selgete kasutajateekondade, kus esitati algsed ja muudetud seadistused ning nendele vastavad

töölaua tulemused. Kasutajal oli võimalik valida näidisseadistus, liikuda nupu „Salvesta“ kaudu

töölauale ja näha koheselt seadistamise tulemust (sh erinevate rollide algsete ja muudetud

töölaudade plokkide koosseise, järjestusi ning sisu seadistusi).

Selle asemel, et hinnata, kas tegevused on leitavad, arusaadavad ning moodustavad tervikliku

seadistamise lahenduse (nagu nõuab 50 punkti kriteerium), nõudis Hankija tagantjärele

täielikku ja piiramatut klikitavust ehk tehnilist täislahendust, mille Hankija oli oma selgitustega

(ID 1110855 ja ID 1112063) välistanud. Sellega rikkus Hankija RHS-i läbipaistvuse ja võrdse

kohtlemise üldpõhimõtteid, hinnates Vaidlustaja pakkumust RHAD-is sätestatust ja antud

selgitustest erinevatest kriteeriumidest lähtuvalt.

6.4.1.3. Proovitöö nr 1 raames esitatud prototüüp moodustas arusaadava ja tervikliku töölaua

seadistatavuse kontseptsiooni, kus kõik funktsionaalsused olid demonstreeritud ja tulemus

töölaual nähtav. Seetõttu on Hankija etteheited põhjendamatud ning Vaidlustaja proovitöö

vastab kõnealuse kriteeriumi osas täielikult 50 punkti tasemele.

6.4.2. Infoploki seadistamine

Hankija on kriteeriumi osas kommenteerinud järgnevalt: Infoploki seadistamisel sai määrata

kuvatavaid andmeid ja nende kuvamise järjekorda, kuid puudus võimalus seadistada

andmemahtu ja info prioriteetsust.

Hankija etteheide, nagu puudunuks prototüübis võimalus seadistada andmemahtu ja info

prioriteetsust, on väär ning tugineb prototüübi pealiskaudsele kontrollile.

6.4.2.1. Hindamismetoodika kohaselt antakse „Infoploki seadistamise“ eest 50 punkti

järgmiselt: Kasutaja saab infoploki seadistamisel määrata võimalikud kuvatavad andmed,

andmete kuvatava andmemahu ning prioriteetsena esitatava info. Kõik nimetatud seadistused

on prototüübis esitatud ja kasutaja poolt muudetud.

Vaidlustaja proovitöö nr 1 sisaldab kõiki kolme nõutud seadistust ja täidab 50 punkti saamise

2 Sõnumi ID 1110855. 3 Sõnumi ID 1112063. 4 Sõnumi ID 1112180.

5 (34)

eeldused. Diagnooside, uuringute ja protseduuride ning saatekirjade ja broneeringute

seadistusvaadetes on eraldi esitatud:

1) väli „Andmete kuvamise hulk“, mis võimaldas valida nt kõigi uuringute ja viimase

aasta uuringute vahel ning võimalust kuvada üksnes kehtivaid saatekirju ja aktiivseid

broneeringuid;

2) väli „Prioriteetsena esitatav info“, mis võimaldas valida kõigi diagnooside ning

üksnes alaliste ja kõrge riski- ja ohuteguriga diagnooside vahel, samuti pakkus võimaluse kõrge

riski- ja ohuteguriga diagnooside visuaalseks esiletõstmiseks punase värviga.

6.4.2.2. Hankija täpsustas 20.07.2026 vastuses5, et 50 punkti tasemel hinnatakse kolme

seadistust: kuvatavad andmed, kuvatav andmemaht ja prioriteetsena esitatav info. Hankija lisas,

et andmete kuvamise järjekord ei ole sellel tasemel eraldiseisev neljas kohustuslik seadistus.

Iga infoplokk ei pea toetama kõiki seadistusvõimalusi sõltumata nende asjakohasusest, kuid

lahendusest peab tervikuna olema selgelt hinnatav, kuidas kasutaja saab nimetatud kolme

seadistust muuta.

Vaidlustaja teostas lahenduse selgituste kohaselt ehk seadistused olid määratud seal, kus need

olid sisuliselt asjakohased.

6.4.2.3. Hankija on eksinud, samastades seadistuste puudumise nende demonstreerimise viisi

puudusega. Kui Hankija etteheide puudutab interaktiivsust, siis vastavalt Hankija selgitustele

(ID 1110855 ja ID 1112063) oli prototüübis lubatud kasutada esinduslikke vaateid ja selgitavaid

olekuid.

Hankija hinnang pole ka järjepidev, sest Hankija on lugenud samal põhimõttel esitatud andmete

ja järjestuse seadistamise prototüübis olemasolevaks, kuid on samas jätnud andmemahu ja

prioriteetsuse seadistused tähelepanuta.

Kuna Vaidlustaja prototüüp sisaldas kõiki kolme RHAD-is ja selgitustes nõutud seadistust ning

demonstreeris selgelt nende toimimisloogikat, vastab Vaidlustaja proovitöö nr 1 kõnealuse

kriteeriumi osas täielikult 50 punkti tasemele.

6.4.3. Infoplokkide ümberjärjestamine

Hankija on kriteeriumi osas kommenteerinud järgnevalt: Infoplokkide ümberjärjestamine oli

samuti piiratud – lahendus võimaldas plokke üles-alla liigutada näidetena, kuid mitte läbi

klikitava prototüübi ehk terviklikku ümberpaigutamist ei olnud võimalik läbi teha.

Hankija etteheide, et ümberjärjestamine oli piiratud vaid näidetega ega võimaldanud terviklikku

ümberpaigutamist läbi klikitava prototüübi on vastuolus Hankija selgituste ning

hindamismetoodikaga.

6.4.3.1. Hindamismetoodika kohaselt antakse „Infoploki ümberjärjestamise“ eest 50 punkti

järgmiselt: Infoplokkide ümberjärjestamise lahendus on esitatud kõikide töölaual kuvatavate

infoplokkide jaoks ning ümberjärjestamise tulemus on kasutajale töölaual nähtav.

Hankija selgitas 07.07.2026 küsimusele antud vastuses6, et peab olema arusaadav, kuidas

ümberjärjestamine rakendub prototüübis kuvatavatele infoplokkidele ja kuidas tulemus

kasutajatele nähtavaks muutub. Kõiki võimalikke järjestusi ei tulnud eraldi Figma vaadetena

modelleerida.

Vaidlustaja teostas ümberjärjestamise kontseptsiooni ja kasutajateekonna Hankija juhiste

kohaselt. Seadistusvaadetes olid esitatud selged ümberjärjestamise juhtvahendid (plokkide

üles-alla liigutamine) ning töölauavaated demonstreerisid muudatuse rakendumist ja

lõpptulemust töölaual.

5 Sõnumi ID 1116939. 6 Sõnumi ID 1112063.

6 (34)

6.4.3.2. Hankija heidab Vaidlustajale ette, et prototüüp ei võimaldanud terviklikku

ümberpaigutamist piiratud klikitavuse tõttu. Sellise tingimuse esitamine pakkumuste hindamise

faasis on vastuolus Hankija selgitustega (Sõnumi ID 1112063). Hankija ei tohi hindamisel

nõuda lahendust või klikitavuse astet, mille ta on RHAD-i selgitustes välistanud.

6.4.3.3. Hankija ei ole hindamisel välja toonud ega põhjendanud, milline konkreetselt nõutud

kasutajateekond või toimimisloogika jäi esitatud näidete põhjal demonstreerimata. Hankija pole

põhjendanud, milliste infoplokkide puhul polnud ümberjärjestamise lahendus hinnatav ning

kuidas rakendati hindamismetoodikas sätestatud infoplokkide hõlmatuse protsendilisi

lävendeid.

6.4.3.4. Kuna Vaidlustaja proovitöös nr 1 oli esitatud ümberjärjestamise lahendus kõikide

infoplokkide jaoks ning tulemus oli töölaual selgelt nähtav, vastab pakkumus konkreetse

kriteeriumi osas täielikult 50 punkti tasemele.

6.4.4. Riski- ja ohutegurite käsitlemine

Hankija on kriteeriumi osas kommenteerinud järgnevalt: Riski-ja ohutegurid ei olnud rollide

lõikes järjepidevalt esitatud: kiirabi vaates olid need vahetult nähtavad, kuid perearsti vaates

tuli vastava info leidmiseks teha täiendav klikk (ehk tänane TJT lahendus, ikooniga kuva).

Hankija etteheide, nagu poleks riski- ja ohutegurid olnud rollide lõikes järjepidevalt esitatud,

eirab Lähteülesande p-s 2.1.1 sätestatud eesmärki, on vastuolus Hankija enda selgitustega ning

tugineb ilmsele kaalutlusveale.

6.4.4.1. Hindamismetoodika kohaselt antakse „Riski- ja ohutegurite käsitlemise“ eest 50 punkti

järgmiselt: Lahendus võimaldab kasutajale üheselt eristatavalt kuvada patsiendi või

tervishoiutöötaja tegevust mõjutavaid riski- ja ohutegureid. Riski- ja ohutegurid on tavainfost

visuaalselt eristatud ning nähtavad ilma täiendava otsinguta/klikita.

Vaidlustaja proovitöö nr 1 täidab 50 punkti taseme eeldused järgmistel põhjustel:

1) Lähteülesande p-s 2.1.1 on nõutud: Riski- ja ohutegurid on tänases lahenduses

kättesaadavad päises oleva ikooni kaudu, kuid sealne info on vaja persoonast lähtuvalt

paremini esile tuua. Vaidlustaja teostas proovitöö lahenduse, arvestades persoonapõhist eripära

ja töövajadust:

– kiirabitöötaja rollis (kus kriitilise riskiinfo kohene märkamine on esmatähtis) on riski-

ja ohutegurid vaikimisi esiplaanil ilma ühegi lisaklikita ning tavainfost visuaalselt eristatud;

– perearsti rollis on sama info kättesaadav päisest, kuid lisaks on riski- ja ohutegurite

plokk disainitud seadistatava infoplokina. See tähendab, et perearst saab soovi korral tõsta riski-

ja ohutegurite ploki ühe klikiga oma töölauale esiplaanile;

– järjepidevus UX-disainis ei tähenda identse ja jäiga vaate kopeerimist erinevate

töövajadustega persoonadele, vaid ühtset kasutusloogikat ja võimalust kohandada töölauda

vastavalt rolli reaalsetele vajadustele.

6.4.4.2. Hankija rõhutas 20.07.2026 selgitustes7, et riski- ja ohutegurite puhul hinnatakse

eelkõige olulise info arusaadavat ja märgatavat esitamist ning rollipõhise töövajaduse toetamist.

Hankija on eksinud, „karistades“ Vaidlustajat just rollipõhise töövajaduse arvestamise ja

persoonade eristamise eest, mida lähteülesanne ja selgitus eelnimetatud küsimusele nõudsid.

Hankija on teinud kaalutlusvea ja rikkunud põhjendamiskohustust. Perearsti vaatest avanes

päisest riskiinfo hüpikaknana otse töölaual, mitte kasutajat uuele lehele või detailvaatesse viiva

suunamisena. Hankija tõi 20 punkti omistamisel välja vaid üldsõnalise etteheite ega selgitanud,

miks või kuidas eristati käesoleva lahenduse puhul 40 punkti tingimust (nähtavad ilma

detailvaatesse liikumata) ja 20 punkti tingimust (info leidmine eeldab täiendavat tegevust).

7 Sõnumi ID 1116941.

7 (34)

Kuna kiirabi vaates vastas Vaidlustaja lahendus täielikult 50 punkti tingimusele nähtav ilma

täiendava otsinguta/klikita ning perearsti vaates oli tagatud vahetu kättesaadavus ilma

detailvaatesse liikumata ja täielik töölauale seadistatavus, on lahenduse eest 20 punkti

omistamine ebaproportsionaalne ja põhjendamata.

6.4.4.3. Vaidlustaja pakkumus vastab konkreetse kriteeriumi osas täielikult 50 punkti tasemele,

sest proovitöös on esitatud riski- ja ohutegurid tavainfost selgelt eristatuna, lahendus toetab

rollipõhiseid töövajadusi ning võimaldab teabe kuvamist ilma täiendava otsingu või

detailvaatesse liikumiseta.

6.4.5. Desktop- ja tahvli vaadete teostus

Hankija on nende kriteeriumide osas kommenteerinud järgnevalt: Desktop- ja tahvlivaadetes

oli ruumikasutus ebaproportsionaalne ja väga õhuline, nt tahvlivaates oli korraga nähtav vaid

üks infoplokk. Seadistamiseks tuli liikuda eraldi vaatesse, mistõttu ei olnud muudatuse mõju

seadistamise hetkel töölaual nähtav.

Hankija etteheited, nagu oleks ruumikasutus ebaproportsionaalne ja väga õhuline ning

seadistamine toimus eraldi vaates, on vastuolus Hankija selgitustega, eiravad TEDI

disainisüsteemi nõudeid ning tuginevad kaalutlusveale ja põhjendamiskohustuse rikkumisele.

6.4.5.1. Hindamismetoodika kohaselt antakse kriteeriumide „Desktop vaadete teostus“ ja

„Tahvli vaadete teostus“ 50 punkti mõlema eest järgmiselt: Kõik prototüübis esitatud vaated on

teostatud desktop / tahvli vaatena. Kasutatud ruum võimaldab kuvada infot ülevaatlikult ning

toetab samaaegselt infoplokkide kasutamist, seadistamist kui ka töölauda puudutavaid tegevusi.

6.4.5.2. Vaidlustaja proovitöö nr 1 täidab mõlema kriteeriumi puhul 50 punkti saamise eeldused.

Lähteülesande p 2.1.1 sätestab: Proovitöö raames ei eeldata kõigi olemasolevate TJT

infoplokkide ümberdisainimist. Piisab käesolevas dokumendis nimetatud infoplokkide põhjal

lahenduse demonstreerimisest.

Lahenduse kavandamisel lähtuti olemasoleva TJT infoplokkidest, tehes täiendusi eelkõige

selleks, et näidata erinevate seadistuste mõju töölaual. Eesmärk oli esitada info kergesti

hoomatavalt ja toetada kasutaja võimalust otsustada, milline info peab olema kohe nähtav.

Selleks on lahenduses ette nähtud infoplokkide vaikimisi avatud või suletud oleku seadistamine.

Paigutuse õhulisus on seotud loetavuse ja info eristatavuse eesmärgiga ning kujundamisel on

lähtutud TEDI komponentidest ja visuaalsetest põhimõtetest. Ainuüksi suurem korraga

nähtavate plokkide arv ei võrdu parema kasutatavusega. Samas ei väida Vaidlustaja, et TEDI

kasutamine vabastaks ekraaniruumi otstarbeka kasutamise nõudest.

6.4.5.3. Hankija selgitas 07.07.2026 vastuses8, et tahvlivaade peab olema optimeeritud iPad Air

11-tollise seadme horisontaalvaatele ning desktop-vaatest täielikult erinevat kasutajaliidest ega

eraldi visuaalset keelt ei nõuta. Vaidlustaja rakendas tahvlivaadet, arvestades seadme

ekraanisuurust, puutetundlikku kasutust ja kasutajateekonna mugavust.

Eraldi seadistusvaate kasutamine on teadlik ja läbimõeldud kasutajakogemuse lahendus.

Igapäevast patsiendi töölauda ei tohi koormata pidevalt nähtavate seadistamise

juhtvahenditega. Kasutaja saab seadistused teha eraldi vaates ja liigub „Salvesta“ nupu kaudu

töölauale, kus valitud näidisseadistuse tulemus on koheselt nähtav.

Lähteülesanne ega hindamismetoodika ei sätestanud piirangut, et seadistamine peab toimuma

patsiendi töölauaga samas vaates. Seadistatava töölaua kriteerium nõuab seadistamise tulemuse

nähtavust töölaual; esitatud kasutajateekonnas on valitud näidisseadistuse tulemus pärast nupu

„Salvesta” kasutamist selgelt nähtav.

8 Sõnumi ID 1111643.

8 (34)

6.4.5.4. Hindamismetoodika kohaselt antakse 20 punkti vaid juhul, kui osa nõutud vaateid

puudub või lahendus ei võimalda infot ülevaatlikult kasutada. Vaidlustaja esitas kõik nõutud

vaated nii desktop- kui ka tahvlivaatena.

Hindamismetoodika kohaselt käsitleb 40 punkti tase olukorda, kus kõik vaated on olemas, kuid

ekraaniruumi pole kasutatud optimaalselt. Hankija on teinud kaalutlusvea, andes Vaidlustaja

proovitööle 20 punkti olukorras, kus Vaidlustaja esitas kõik vaated ning Hankija etteheide

puudutab vaid ruumikasutuse „õhulisust“, põhjendamata madalaimat taset.

6.4.5.5. Hankija on kahe eraldiseisva kriteeriumi (Desktop vaadete teostus ja Tahvli vaadete

teostus) kohta andnud vaid ühe üldsõnalise tagasiside, selgitamata, konkreetselt millise vaate

puhul ja miks takistas paigutus info ülevaatlikku kasutamist. Selline üldsõnaline hinnang rikub

riigihangete korraldamise üldpõhimõtteid ja põhjendamiskohustust.

Kuna Vaidlustaja teostas kõik nõutud vaated nii desktop- kui ka tahvlivaates, kasutasid TEDI

komponente ning tagasid seadistuste tulemuse vahetu nähtavuse töölaual, vastavad mõlemad

kriteeriumid 50 punkti tasemele.

6.5. Hankija otsus hinnata Vaidlustaja proovitööd nr 1 vaid 20 punktiga on õigusvastane, sest

Hankija põhjendused on vastuolus RHAD-i ja Hankija enda selgitustega ning tuginevad

ilmsetele kaalutlusvigadele. Vaidlustaja proovitööd nr 1 tuleb nimetatud kriteeriumide alusel

hinnata maksimaalse 50 punktiga.9

6.6. 08.10.2026 täiendas Vaidlustaja oma seisukohti.

6.6.1. Hankija väidab vastuses vaidlustusele, et Vaidlustaja samastab ekslikult kõigi võimalike

konfiguratsioonide täieliku realiseerimise ja piiratud esindusliku kasutajateekonna

demonstreerimise. Vaidlustaja sellise käsitlusega ei nõustu. Vaidlus ei seisne selles, kas

prototüüp pidi olema klikitav või kas nõutud funktsionaalsusi pidi demonstreerima –

Vaidlustaja prototüüp oli klikitav ning nõutud kasutusjuhud olid demonstreeritud.

Vaidlus puudutab seda, millises tehnilises vormis ja ulatuses pidi see demonstreerimine Hankija

vastuste (ID 1110855 ja ID 1112063) valguses toimuma. Hankija selgitused andsid pakkujatele

järgmise õiguspärase ootuse:

1) Lähteülesande p 2.2 sätestas kohustuslike tegevuste „läbimängimise“, mitte täieliku

klikitavuse igal sammul;

2) Hankija selgitus (ID 1110855) kinnitas sõnaselgelt, et:

- Figma prototüübilt ei eeldata täielikku rakendusloogikat samas ulatuses nagu töötavalt

rakenduselt.

- funktsionaalseid käitumisi tuleb demonstreerida ulatuses, mis võimaldab aru saada

kavandatavast kasutajateekonnast ja lahenduse toimimisloogikast.

- selleks võib kasutada esinduslikke vaateid, olekuid, kasutajateekondi ja vajadusel

selgitavaid märkusi.

6.6.2. Hankija selgitus andis juhise, et funktsionaalsust (sh infoplokkide konfigureerimist,

järjestamist ja rollivahetust) ei pea lahendama klikitavusega, vaid seda oli lubatud selgitada ja

demonstreerida esinduslike vaadete, olekute, kasutajateekondade ja märkuste kaudu.

Hankija poolt hindamisel kohaldatud praktika läheb nende selgitustega vastuollu, sest Hankija

alandas Vaidlustajate hindepunkte põhjusega, et teatavaid tegevusi ei saanud kasutaja ise lõpuni

läbi klikkida, eirates asjaolu, et vastav toimimisloogika ja kasutajateekond oli prototüübis siiski

esinduslike vaadete ja olekute abil selgelt ja arusaadavalt kirjeldatud.

9 Vaidlustusele oli lisatud link videole, mis näitlikustab ja selgitab täpsemalt vaidlustuses kirjeldatud asjaolusid,

sh esitatud prototüüpi, kasutajateekondi ning seadistuste toimimisloogikat.

9 (34)

6.6.3. Lähteülesande p 2.4 nõudis, et prototüüp peab olema „klikitav“. Lähteülesande p 2.2

nõudis tegevuste „läbimängimist“. Hankija ei defineerinud RHAD-is täpselt klikitavuse ulatuse

metoodikat. Kui Hankija soovis hinnata interaktiivsuse taset mitte kasutajateekonnast

arusaadavuse (mida lubasid selgitused ID 1110855 ja 1112063), vaid iga üksiku klikitava

tagajärje kaudu, pidanuks see RHAD-is olema sõnaselgelt sätestatud.

6.6.4. Mõistlik pakkuja juhindus lähteülesande lahendamisel Hankija selgitustest, milles

kinnitati, et toimimisloogika edasiandmiseks piisab esinduslikest vaadetest ja olekutest.

Hankija ei saa hindamisel nõuda kõrgemat interaktiivsuse taset kui see, mille ta on oma

vastustega teabevahetuses varasemalt piiritlenud. Vaidlustaja prototüüp täitis kõik

Lähteülesande p-des 2.2 ja 2.4 sätestatud sisulised nõuded ning oli vastavuses Hankija

selgitustes antud raamistikuga. Vaidlustaja prototüübile antud hindepunktide vähendamine

olukorras, kus loogika oli demonstreeritud ja täielikku interaktiivsust polnud selgituste kohaselt

vaja, on vastuolus RHS-is sätestatud läbipaistvuse ja võrdse kohtlemise põhimõtetega.

Asjaolu, et Hankija tõlgendas tagantjärele klikitavuse nõuet ebaselgelt ja selgitustega

vastuoluliselt, on läbiv viga, mille tõttu on Hankija alandanud Vaidlustaja proovitöö

hindepunkte järjest mitmete hindamiskriteeriumide alusel.

6.6.5. Seadistatava töölaua terviklahendus

Hankija väidab vastuses vaidlustusele, et komisjon luges hinnatavaks ainult 2 tegevust 5-st

(infoploki sisu seadistamine ja seadistuste rollipõhine salvestamine), kuna ülejäänud tegevuste

(lisamine, eemaldamine, ümberjärjestamine) puhul puudus iga konkreetse juhtvahendi puhul

eraldi läbiklikitav olek. Selline järeldus on vastuoluline, sest:

1) üheltpoolt Hankija nõustub, et seadistuste rollipõhine salvestamine oli

nõuetekohaselt demonstreeritud, ehkki Figma prototüüp tehniliselt ei võimalda

konfiguratsioone salvestada (mida Hankija kinnitas ka vastuses küsimusele ID 1112063).

Hankija käsitleb seda nõuet õigustatult TJT töölaua kontseptsiooni ja kasutajateekonna

funktsionaalsusena;

2) teisalt nõuab Hankija ülejäänud tegevuste puhul korraga, et need peavad olema Figma

prototüübis realiseeritud ehk käsitleb konkreetseid tegevusi nõuetena Figma prototüübi

funktsionaalsusele (st iga lüliti ja üles-alla nupp peavad olema eraldi klikitavad ning tooma

kaasa vahetu muudatuse).

6.6.5.1. Kui käsitleda kõiki viit hindamiskriteeriumis nimetatud tegevust samadel alustel ehk

TJT töölaua lahenduse funktsionaalsustena, mida prototüüp esinduslike vaadete ja olekute

kaudu ka demonstreerib, siis olid Vaidlustajate proovitöös kõik viis tegevust olemas ja leitavad

ning kasutaja sai seadistamise tulemust töölaual selgelt ka näha. Hankija seisukoht, et tegevus

oli olemas vaid siis, kui selle konkreetne nupp oli Figmas eraldi klikitavaks modelleeritud, on

vastuolus Hankija selgitustega ning muudaks 50 punkti saamise Figma raamistikus tehniliselt

võimatuks kõikide pakkujate jaoks (kõikide võimalike konfiguratsioonide joonistamise

mahukuse tõttu). Põhimõtteline vastuolu seisneb selles, et Hankija käsitleb hindamiskriteeriumi

samas lauses olevaid nõudeid ebajärjekindlalt: kord käsitletakse neid TJT töölaua lahenduse

funktsionaalsustena, kord aga Figma prototüübile esitatud klikitavuse ulatuse nõudena. Selline

tõlgendus muudab hindamise ettearvamatuks.

6.6.5.2. Hankija väidab vastuses, et Vaidlustaja proovitöö nr 1 ei täitnud 40 punkti ega 50 punkti

taseme eeldust, sest puudus vähemalt neli/viis hinnatavalt realiseeritud tegevust. Sellist

sõnastust ja nõuet nagu hinnatavalt realiseeritud tegevus hindamiskriteeriumides ei esine.

Hindamiskriteeriumi täpne sõnastus on: Lahendus võimaldab vähemalt nelja järgmist tegevust

[---]/ Prototüüp võimaldab kasutajal [---].

6.6.5.3. Vaidlustaja prototüüp võimaldas kõiki viit tegevust. Visuaalselt olid esitatud nii

10 (34)

näitamise-peitmise lülitid, üles-alla liigutamise nupud kui ka nende sisu valikud. Kasutajatele

demonstreeriti nende tegevuste rakendumist ja tulemust töölaual ettevalmistatud ja selgelt

arusaadavate vaadete ja olekute kaudu. Hankija väide, et tegevus on „võimaldatud“ vaid siis,

kui selle rakendamiseks vajalik nupp käivitab eraldi Figma olekumuudatuse, kujutab endast

hindamiskriteeriumide tagantjärele kitsendavat ümbersõnastamist.

6.6.5.4. Hankija viitab oma vastuses Lähteülesande p-tele 2.2 ja 2.4, väites, et nendes sätestatud

„läbimängimine“ ja „klikitavus“ tähendasid nõuet, et kasutaja peab saama iga üksikule nupule

(näiteks infoploki eemaldamise nupule) n-ö vajutada ja näha selle tulemust. RHAD ei sisalda

sellist nõuet.

Lähteülesande p 2.2 räägib tegevuste „läbimängimisest“, mis tähistab kasutusjuhtude ja

teekonna visuaalset ja loogilist esitamist. Lähteülesande p 2.4 sätestab üldise nõude, et

prototüüp peab olema „klikitav“ (mida Vaidlustaja prototüüp ka vaieldamatult oli, võimaldades

olekuid vahetada ja seadistuste tulemusi näha). Kumbki punkt ei sätesta, et klikitavus peab

olema 100% detailne iga üksiku elemendi ja lüliti/nupu tasemel. Vastupidi – Hankija selgitused

(ID 1110855 ja ID 1112063) kinnitasid, et kõiki võimalikke konfiguratsioone ei pea täielikult

realiseerima ning demonstreerimiseks võib kasutada esinduslikke vaateid ja olekuid.

6.6.6. Infoploki seadistamine

Protokolli kohaselt oli hinde alandamiseks faktiväide, et: Infoploki seadistamisel sai määrata

kuvatavaid andmeid ja nende kuvamise järjekorda, kuid puudus võimalus seadistada

andmemahtu ja info prioriteetsust.

Vastuses vaidlustusele möönab Hankija sõnaselgelt vastupidist: Vaidlustus väidab õigesti, et

andmemahu ja prioriteetsena esitatava info valikud olid seadistusvaadetes visuaalselt olemas.

Hankija ei väida vaidlustusmenetluses vastupidist.

Tegemist on vastuoluga Protokolli ja Hankija praeguse positsiooni vahel. Hankija on

vaidlustusmenetluses muutnud oma etteheite sisu: kui algselt rõhutas Hankija andmemahu

seadistamise ja info prioriteetsuse puudumist, siis nüüd möönab Hankija nende olemasolu ja

heidab ette, et need valikud ei olnud piisavalt läbiklikitavad. Vaidlustusmenetluses ei ole

lubatud hindamise aluseks olevaid faktilisi põhjendusi muuta. Kui Hankija tegelik etteheide

seisneb klikitavuse ulatuses, tuleb seda hinnata kooskõlas Hankija enda selgitustega (ID

1110855 ja 1112063), milles kinnitati, et Figma prototüübilt ei eeldata täielikku

rakendusloogikat ning demonstreerimiseks piisab esinduslikest vaadetest ja olekutest.

6.6.6.1. Vaidlustaja prototüübis olid nii andmemahu kui ka prioriteetsuse seadistamise valikud

visuaalselt olemas ning seadistuste rakendumist demonstreeriti nelja erineva näitliku

vaate/oleku kaudu, kus oli selgelt näha, kuidas valikute muutmine töölaual kuvatavat infot

mõjutab.

Hankija väide, et: Komisjoni hinnangul ei olnud puuduse tuum nende elementide visuaalne

puudumine, vaid see, et kasutaja ei saanud vastavaid valikuid ise muuta ja näha oma konkreetse

valiku rakendumist, kujutab endas taas sama olukorda, mida Vaidlustajad on eelnevates

punktides käsitlenud, st Hankija:

1) nõuab läbivat klikitavust, mille vajaduse ta enne pakkumuste esitamist antud

selgitustega ise välistas.

2) eirab prototüübis esitatud nelja erinevat näitlikku vaadet/olekut ja selgituses (ID

1110855) sätestatut, mille kohaselt tohib funktsionaalsuste näitamiseks kasutada esinduslikke

vaateid ja olekuid.

6.6.6.2. Hankija viitab vastuses 50 punkti hindamiskriteeriumi sõnastusele (vt käesoleva otsuse

p 6.4.2.1) ning väidab, et sellest tulenevalt pidi prototüübist olema selgelt hinnatav mitte üksnes

see, et nimetatud seadistused on visuaalselt kujutatud, vaid ka see, kuidas kasutaja saab neid

seadistusi ise muuta.

11 (34)

Vaidlustaja prototüübis oli selgelt hinnatav ja nähtav, kuidas kasutaja neid seadistusi muuta saab

ning kuidas need töölaual rakenduvad, sest seadistusvaadetes olid olemas vastavad valikud ja

juhised kuidas muuta ning töölaua vaadetes oli nelja näite/oleku kaudu demonstreeritud nende

valikute tulemust (ehk see, kuidas muudatus töölaual rakendub). Hankija tõlgendab tingimust

„ja kasutaja poolt muudetud“ tagantjärele viisil, nagu pidi Figma prototüüp ise sisaldama

töötava rakenduse loogikat (st kasutaja klikib seadistusnupule ning prototüüp muudab vahetult

töölaua sisu). Teisalt eirab Hankija tõsiasja, et Figma prototüübis saabki tegelikku

rakendusloogikat näidata just nimelt esinduslike vaadete ja olekute kaudu.

6.6.6.3. Vastuses vaidlustusele väidab Hankija, et Vaidlustaja esitatud diagnooside seadistus

(„märgi punasega kõrge riski- ja ohuteguritega diagnoosid“) ja uuringute valik olid vaid info

visuaalne esiletõstmine, kuid ei kujutanud endast piisavalt demonstreeritud kasutaja tehtavat

prioriteedivalikud ja selle rakendumist töölaua infosisule. Selles väites on kaks eksimust:

1) esiteks, Protokollis esitas Hankija faktiväite: seadistamise võimalus puudus. Hankija

praegune vastus aga möönab lahenduse olemasolu, kuid lisab tagantjärele uue kvalitatiivse

hinnangu – et esitatud lahendus ei vastanud Hankija sisulisele arusaamale sellest, mida

„prioriteetsena esitatav info“ tähendab. Vaidlustusmenetluses ei saa faktilist hindamisotsust

asendada sisuliselt uue kvalitatiivse hinnanguga;

2) teiseks, RHAD ei defineerinud, mida täpselt loetakse meditsiiniliselt või

disainialaselt „prioriteetseks infoks“. Hankija väide, et punase värviga esiletõstmine aitab

toetada info märgatavust, aga ei toeta prioriteedi valikut, on vaidlustusmenetluses loodud

põhjendus, mis ei ole asjakohane. Prototüübi eesmärk on näidata infoploki seadistamise ja

andmete esitamise loogikat, mitte pakkuda meditsiinilist lahendust selle kohta, milline diagnoos

peaks olema arsti jaoks igas võimalikus olukorras prioriteetne.

6.6.7. Infoplokkide ümberjärjestamine

Hankija väidab vastuses vaidlustusele: Hankija tunnistab, et ümberjärjestamise kontseptsioon

oli vaidlustajate proovitöös visuaalselt kujutatud. Puudus puudutas nõutud tegevuse

kasutajateekonda: hindaja ei saanud vastavat juhtvahendit kasutades muuta konkreetse ploki

asukohta ja näha sellest tegevusest tulenevat tulemust töölaual. Seega väidab Hankija, et ehkki

ümberjärjestamise tulemus oli proovitöös visuaalselt kujutatud, pidi töö saama 20 punkti (mille

kriteeriumiks on lahenduse esitatus alla 50% töölaual kuvatavate infoplokkide jaoks), sest

hindaja ei saanud konkreetse ploki üles-alla noolt vajutades (klikkides) näha järgnevat tulemust

otse prototüübilt. Hankija selline seisukoht on vastuoluline, Hankija selgitas teabevahetuses10,

et: Infoplokkide ümberjärjestamise puhul peab olema arusaadav, kuidas lahendus rakendub

prototüübis kuvatavatele infoplokkidele ja kuidas ümberjärjestamise tulemus kasutajale

nähtavaks muutub. See ei tähenda, et kõik võimalikud infoplokkide järjestused tuleb eraldi

Figma vaadetena läbi modelleerida.“ Hankija selgitus kinnitas, et piisab loogika

arusaadavusest ja tulemuse esitamisest esinduslike vaadete kaudu. Nõudes hindamisel iga

üksiku infoploki noole reaalset ja interaktiivset klikitavust, nõuab Hankija sadade või tuhandete

vaadete/kombinatsioonide läbijoonistamist, mis on vastuolus Hankija selgitustega.

6.6.7.1. Hindamiskriteerium kirjeldab loodava TJT töölaua funktsionaalsust ehk seda, kuidas

lahendus peab tulevikus toimima, mitte Figma prototüübile esitatud nõudeid. Vaidlustaja

prototüüp esitas ümberjärjestamise lahenduse, kus kõikide infoplokkide osas oli näidatud,

kuidas käib ümberjärjestamine ning milline on selle tulemus töölaual.

6.6.7.2. Protokollis puudus järeldus selle kohta, et Vaidlustaja lahendus hõlmas alla 50%

infoplokkidest. Hankija arvutab vastuses vaidlustusele selle näitaja tagantjärele ainult

tulenevalt sellest asjaolust, et kõik nupud ei olnud klikitavad. Kuna lahenduse kontseptsioon ja

10 Sõnumi ID 1112063.

12 (34)

valikud olid seadistusvaates visuaalselt esitatud kõikidele plokkidele ning tulemus töölaual ka

demonstreeritud, puudus Hankijal alus taandada see tulemus tasemele „alla 50%“.

6.6.7.3. Vaidlustaja prototüüp täitis täielikult 50 punkti taseme tingimused: infoplokkide

ümberjärjestamise lahendus oli seadistustes tagatud ja esitatud kõikide infoplokkide kohta ning

selle rakendumise tulemus oli töölaual ka selgelt nähtav. Hinde alandamine 20 punktile

klikitavuse puudumise tõttu on vastuolus Hankija selgitustega ning kujutab endast

hindamiskriteeriumi tagantjärele rangemaks muutmist.

6.6.8. Riski- ja ohutegurite käsitlemine

Hankija möönab vastuses vaidlustusele, et kiirabitöötaja rollivaates olid riski- ja ohutegurid

visuaalselt eristatud ja töölaual koheselt ilma täiendava klikita nähtavad. Sellega on üheselt

kinnitatud, et Vaidlustaja pakutud lahendus võimaldab nõutud funktsionaalsust täielikult.

6.6.8.1. Hankija heidab Vaidlustajale ette, et perearsti näidisvaates oli riskiinfo töölaualt

peidetud ja ligipääsetav päise ikooni kaudu, vajades täiendavat klikki. Hankija selline järeldus

on ebaõige ja vastuoluline järgmistel põhjustel:

1) prototüüp täitis täpselt Lähteülesande nõuet luua persoonapõhine lahendus.

Lähteülesande p 2.1.1 sätestas eesmärgina näidata, kuidas riski- ja ohuteguritega seotud oluline

info oleks kasutajatele paremini esile toodud „persoonast lähtuvalt“. Kiirabitöötaja persoona

puhul (kus iga sekund on kriitiline) kuvati riskiinfo otse töölaual ilma klikita ja perearsti

persoona puhul (kes teostab põhjalikumat vastuvõttu ja vajab töölaual teistsugust infotihedust)

oli arvestatud teistsuguse infovajadusega. hindepunktide vähendamine selle eest, et Vaidlustaja

tegi täpselt seda, mida lähteülesanne nõudis (st lõi persoonast sõltuva lahenduse), on väär.

2) kuna tegemist on konfigureeritava töölauaga, võimaldab Vaidlustaja lahendus ka

perearstil tõsta riski- ja ohutegurite infoploki otse töölauale esiplaanile, kus see on nähtav ilma

täiendava klikita. Seega on vastav funktsionaalne võimekus lahenduses läbivalt olemas.

Hankija ei saa lugeda funktsionaalsust puuduvaks või mittevõimaldatuks pelgalt seetõttu, et

ühes näitlikus rollivaates oli vaikeseadistus kohandatud vastavalt selle spetsiifilise persoona

vajadustele.

6.6.8.2. Vaidlustaja prototüüp vastas riski- ja ohutegurite käsitlemisel täielikult 50 punkti

tasemele. Lahendus võimaldas riski- ja ohutegurite visuaalset eristamist ja nähtavust ilma

täiendava klikita.

6.6.9. Desktop- ja tahvli vaadete teostus

Hindamismetoodika sätestab desktop- ja tahvlivaadete kriteeriumiteks erinevad tasemed:

50 punkti: Kõik vaated on teostatud, ruumikasutus on ülevaatlik ning toetab infoplokkide

samaaegset kasutamist, seadistamist ja töölauda puudutavaid tegevusi.

40 punkti: Kõik vaated on teostatud, kuid ekraaniruumi ei ole osaliselt kasutatud optimaalselt

või on info esitlus vähem ülevaatlik.

20 punkti: Vaadete lahendus ei võimalda infot ülevaatlikult kasutada.

Hankija on mõlemas kriteeriumis andnud Vaidlustaja proovitööle 20 punkti, põhjendades seda

väitega, et perearsti vaates hõivas diagnooside plokk liiga suure osa ekraanist ning kiirabi vaates

võttis riskiplokk enda alla valdava osa töölauast, jättes ülejäänud info keritavasse alasse ja

näidates tühje välju.

Vaidlustaja Hankija käsitlusega ei nõustu, sest Lähteülesande p-i 2.4 kohaselt oli prototüübis

kohustuslik kasutada TEDI disainisüsteemi, mis määratleb tekstide suuruse, vahed ja

disainielemendid. Diagnooside infoploki ulatus perearsti vaates tulenes otse kahest Hankija

seatud raamist:

1) Hankija antud konkreetse näidispatsiendi ulatuslikust diagnooside hulgast, mis pidi

prototüüpi ära mahtuma; ja

13 (34)

2) TEDI disainisüsteemist tulenevast standardsest disainist, mida pakkuja ei saanud

omavoliliselt muuta (nt kokku surumise näol).

Hankija heidab seega Vaidlustajale ette TEDI disainisüsteemi reeglite täpset järgimist ja

Hankija antud andmete täielikku esitamist.

6.6.9.1. Kiirabitöötaja vaates sisaldasid riskiploki teatud väljad kriipse (puuduvaid väärtusi)

ning teised infoplokid olid vähem koormatud. See tulenes Hankija poolt proovitööks soovitatud

näidispatsiendi andmetest ja Lähteülesande p-i 1.3.4 nõuetest, kus tuli arvestada kasutajale

antavat teavet andmete puudumise kohta. Teistsuguse patsiendiprofiili puhul saanuks vaade

teistsuguse infotiheduse. Prototüübi eesmärk oli presenteerida realistlikke andmeid TEDI

raamistikus, mitte genereerida kunstlikke andmeid üksnes ekraani visuaalseks täitmiseks.

Ekraanipinna kerimine ei saa võrduda ülevaatlikkuse puudumisega. Nii TEDI disainisüsteemis

kui ka muus veebidisainis on ekraani kerimine tavapärane võte. Asjaolu, et kriitiline info on

tõstetud esiplaanile ning muu info jäi keritavasse alasse, vastab täpselt lähteülesande

eesmärgile, milleks oli tuua oluline info esile persoonast lähtuvalt.

6.6.9.2. Hankija möönab vastuses vaidlustusele, et 40 punkti tase hõlmab olukorda, kus

ruumikasutus on mitteoptimaalne või vähem ülevaatlik, ning 20 punkti kohaldamiseks peab

lahendus olema kasutamiseks sobimatu. Hankija ei ole oma otsustes faktiliselt põhjendanud,

miks muudab infoploki suurus või kerimise vajadus lahenduse täielikult kasutuskõlbmatuks ja

mitte parimalgi juhul vähem optimaalseks.

Protokollis heitis Hankija ette, et Seadistamiseks tuli liikuda eraldi vaatesse, mistõttu ei olnud

muudatuse mõju seadistamise hetkel töölaual nähtav.

Vastuses vaidlustusele märgib aga Hankija: Eraldi seadistusvaatest naasemine ja muudatuse

mõju nähtavus pärast salvestamist ei ole iseseisvalt puudus. Kuna Hankija on kinnitanud, et

eraldi seadistusvaate kasutamine, sealt naasemine ja muudatuse nähtavus pärast salvestamist on

lubatud ning ei kujuta endast puudust, ei saa Hankija seda asjaolu kasutada lisapõhjendusena

madalama punktitaseme kohaldamiseks ei seadistamise ega vaadete teostuse kriteeriumites.

7. Hankija, Tervise ja Heaolu Infosüsteemide Keskus, vaidleb vaidlustusele vastu ja palub

jätta selle rahuldamata järgmistel põhjustel.

7.1. Vaidlustaja leiab, et tema proovitööd nr 1 oleks tulnud hinnata 50 punktiga ning tema

pakkumus oleks sellisel juhul saanud kokku 99,11 punkti.

Vaidlustuse põhiväide on, et Hankija nõudis proovitöö nr 1 hindamisel RHAD-ist ja Hankija

selgitustest rangemat klikitavuse astet ning hindas Vaidlustajate prototüüpi seetõttu ebaõigesti.

Hankija sellega ei nõustu. Komisjoni hindamisel ei nõutud täieliku rakendusloogika, tegeliku

andmete püsivuse ega kõigi võimalike konfiguratsiooniharude realiseerimist. Hinnati seda, kas

RHAD-is kohustuslikuna nimetatud kasutajategevused ja nende toimimisloogika olid klikitavas

prototüübis selliselt demonstreeritud, et kasutaja tegevuse ja selle tulemuse vaheline seos oli

hinnatav.

7.2. Klikitava prototüübi nõude sisu

Vaidlustaja põhiargument põhineb eeldusel, et Hankija nõudis hindamisel tagantjärele täielikku

ja piiramatut klikitavust. See ei vasta tegelikule hindamisalusele ega RHAD-i sisule.

Lähteülesande p-i 2.2 järgi pidi kasutaja töölaua konfigureerimisel saama lisada patsiendi

töölauale infoplokke, eemaldada infoplokke ja muuta infoplokkide järjestust. Lähteülesande

p-i 2.4 järgi pidi prototüüp olema high-fidelity ja klikitav ning sisaldama vähemalt patsiendi

töölaua põhivaadet, infoploki lisamist, infoploki eemaldamist, infoploki konfigureerimist,

infoplokkide järjestamist, rollivaate vahetamist ning vähemalt ühest infoplokist algatatud

navigeerimist detailvaatesse.

14 (34)

07.07.2026 küsimusele11 antud vastuses selgitas Hankija, et Figma prototüübilt ei eeldata

täielikku rakendusloogikat samas ulatuses nagu töötavalt rakenduselt. Funktsionaalsed

käitumised tuli siiski demonstreerida sellises ulatuses, mis võimaldab Hankijal aru saada

kavandatavast kasutajateekonnast ja lahenduse toimimisloogikast. Selleks võis kasutada

esinduslikke vaateid, olekuid, kasutajateekondi ja vajadusel selgitavaid märkusi. Kõiki

võimalikke konfiguratsioone ega rakendusloogika harusid ei pidanud täielikult realiseerima.

Samuti selgitas Hankija 07.07.2026 küsimusele12 vastates, et kõiki võimalikke infoplokkide

järjestusi ei pea eraldi Figma vaadetena modelleerima ega realiseerima tegelikku andmete

salvestamise tehnilist loogikat. Selgitused vähendasid seega nõutava tehnilise realiseerimise

ulatust, kuid ei kõrvaldanud Lähteülesande p-de 2.2 ja 2.4 nõuet, et kasutaja peab saama

kohustuslikuna nimetatud konfigureerimistoiminguid teha ning klikitav prototüüp peab neid

tegevusi sisaldama. Samuti ei muudetud selgitustega hindamismetoodika punktide andmise

tingimusi. Sellisele järeldusele ei saanud mõistlik isik Hankija vastust tõlgendades tulla.

Eristada tuleb kahte asja: (i) kõigi võimalike konfiguratsioonide ja pärisrakenduse tehnilise

loogika täielik realiseerimine, mida ei nõutud, ning (ii) vähemalt piiratud esindusliku

kasutajateekonna kaudu konkreetse kasutajategevuse ja selle tulemuse demonstreerimine, mida

RHAD nõudis. Vaidlustus samastab need kaks erinevat nõuete taset ekslikult.

7.3. Seadistatava töölaua terviklahendus

50 punkti taseme järgi peab prototüüp võimaldama kasutajal lisada ja eemaldada infoplokke,

muuta nende järjestust, seadistada infoplokkides kuvatavat infot ning salvestada seadistused

rollipõhiselt. 40 punkti tase eeldab vähemalt nelja nimetatud tegevuse olemasolu. 20 punkti tase

eeldab vähemalt kahte tegevust ning lubab, et ülejäänud tegevused puuduvad või on esitatud

ainult kontseptsiooni tasemel.

7.3.1. Vaidlustaja seadistusvaates olid visuaalselt kujutatud infoplokkide näitamise ja peitmise

lülitid, üles-alla liigutamise nupud ning infoploki sisu puudutavad valikud. Hindamisel

kontrollitud klikitavas prototüübis ei olnud need juhtvahendid kasutatavad. Klikitavad olid

näidiskonfiguratsioonide „näide 1“ ja „näide 2“ valikud, profiiliikoon ning nupud „tagasi“ ja

„salvesta“. Kasutaja sai seega valida pakkuja ettevalmistatud konfiguratsioonide vahel ja näha

nende tulemust, kuid ei saanud ise valida konkreetset infoplokki lisamiseks või eemaldamiseks

ega muuta konkreetse ploki asukohta.

Komisjon ei käsitanud puudusena seda, et prototüübis puudus tegelik andmete salvestamine või

et kõiki konfiguratsioonikombinatsioone ei olnud realiseeritud. Määrav oli asjaolu, et

kohustuslikud seadistamistegevused ei olnud üksikute kasutajategevustena hinnatavalt

demonstreeritud. Ka piiratud esinduslik teekond oleks olnud piisav, kui kasutaja tegevus oleks

viinud vastava muudatuse olekuni ja selle tulemus oleks olnud hinnatav. Puudus ei seisnenud

selles, et Figma prototüüp ei realiseerinud kõiki võimalikke konfiguratsioone või tegelikku

andmete salvestamist vaid selles, et nõutud seadistamistegevuste kasutajateekonnad jäid

üksikute tegevuste kaupa läbimängimata. Nt ei saanud kasutaja vajutada konkreetse infoploki

eemaldamise juhtvahendile ja seejärel näha selle ploki eemaldamise tulemust töölaual. Samuti

ei saanud kasutaja üles-alla juhtvahendi abil muuta konkreetse ploki asukohta. Seetõttu ei olnud

kasutaja tehtav valik ja sellele järgnev konkreetne muudatus hinnatavad nõutud tegevuste

kaupa.

7.3.2. Lähteülesande p 2.2 nõudis töölaua konfigureerimise tegevuste läbimängimist ning p 2.4

nimetas eraldi infoploki lisamise, eemaldamise, konfigureerimise ja järjestamise. RHR-is antud

selgitus lubas nende demonstreerimiseks esinduslikke vaateid ja piiratud kasutajateekondi.

Hankija hinnangul ei demonstreeritud kahe tervikliku näidiskonfiguratsiooni vahel valimine

11 Sõnumi ID 1110855. 12 Sõnumi ID 1112063.

15 (34)

piisavalt seda, kuidas kasutaja saab nõutud vastavaid üksikuid seadistamistegevusi sooritada.

Komisjon luges 20 punkti taseme ulatuses hinnatavaks infoploki sisu seadistamise ja seadistuse

rollipõhise salvestamise. Ülejäänud tegevused olid kujutatud kontseptsiooni või ettevalmistatud

näidiste tasemel. Seetõttu ei olnud täidetud 40 punkti taseme eeldus – vähemalt neli hinnatavalt

realiseeritud tegevust – ega 50 punkti taseme kõigi viie tegevuse nõue.

7.4. Infoploki seadistamine

Vaidlustaja väidab õigesti, et andmemahu ja prioriteetsena esitatava info valikud olid

seadistusvaadetes visuaalselt olemas. Komisjoni hinnangul ei olnud puuduse tuum nende

elementide visuaalne puudumine, vaid see, et kasutaja ei saanud vastavaid valikuid ise muuta

ja näha oma konkreetse valiku rakendumist.

Proovitöö nr 1 Hindamismetoodika 50 punkti taseme kirjeldus seoses infoploki seadistamisega

sätestab: Kasutaja saab infoploki seadistamisel määrata võimalikud kuvatavad andmed,

andmete kuvatava andmemahu ning prioriteetsena esitatava info. Kõik nimetatud seadistused

on prototüübis esitatud ja kasutaja poolt muudetud. Seega ei piisanud 50 punkti taseme

saavutamiseks üksnes sellest, et vastavad seadistusvõimalused olid visuaalselt kujutatud või

ettevalmistatud olekutena esitatud; prototüübist pidi olema hinnatav ka see, kuidas kasutaja

saab neid seadistusi ise muuta.

20.07.2026 küsimusele (sõnumi ID 1116939) antud vastuses selgitas Hankija täiendavalt

hindamismetoodika 50 punkti taseme tingimust seoses infoploki seadistamisega [---] 50 punkti

taseme puhul tähendab sõnastus „kõik nimetatud seadistused“, et prototüübis peavad olema

esitatud ja kasutaja poolt muudetavad selles punktitasemes nimetatud kolm seadistust:

*kuvatavad andmed;

*kuvatav andmemaht;

*prioriteetsena esitatav info.

Andmete kuvamise järjekord ei ole 50 punkti taseme juures eraldiseisev neljas kohustuslik

seadistus.[---] Sellest tulenevalt pidi prototüübist olema selgelt hinnatav mitte üksnes see, et

seadistused on visuaalselt kujutatud, vaid ka see, kuidas kasutaja saab neid seadistusi ise muuta.

7.4.1. Vaidlustaja prototüübis sai kasutaja valida ettevalmistatud näidiskonfiguratsiooni, milles

pakkuja oli vastavate väljade väärtused juba määranud. Selline lahendus demonstreeris kahte

valmisseisundit, kuid ei demonstreerinud kasutajateekonda, kus kasutaja muudab konkreetset

andmemahu või prioriteetsuse omadust ja näeb oma valiku tulemust. Seetõttu ei olnud täidetud

50 punkti taseme tingimus, nagu seda oli Hankija vastuses13 välja toodud.

Komisjon eristas seejuures andmemahu valikut ja prioriteetsuse valikut sisuliselt. Nt

diagnooside puhul esitatud valik „kõik“ või „ainult alalised ning kõrge riski- ja ohuteguritega

diagnoosid“ kirjeldas andmestiku mahu piiramist. Punase värviga esiletõstmine või

dokumendiviite/pildi kuvamine võis suurendada info märgatavust, kuid ei asendanud nõutud

kasutajapoolse prioriteedivaliku ja selle rakendumise demonstreerimist.

7.4.2. Prioriteetsuse sisulisel hindamisel lähtuti Lähteülesande p-st 1.4.2: kasutaja saab määrata,

milliseid andmeid infoplokk kuvab, millises järjekorras andmeid kuvatakse, kui palju andmeid

kuvatakse, milline info on kasutaja jaoks prioriteetne ja kuvatakse esmajärjekorras. Pakkuja

võib teha põhjendatud ettepanekuid täiendavate konfigureerimisvõimaluste kohta, kui need

toetavad kasutajavajadusi. Pakkuja võib ise pakkuda sobiva lahenduse infoploki sisu

konfigureerimiseks, lähtudes kasutaja vajadustest ning olemasolevate andmete olemusest.

Diagnooside seadistus märgi punasega kõrge riski- ja ohuteguritega diagnoosid kirjeldas

visuaalset esiletõstmist. Uuringute ja protseduuride valik “näita viidet uuringu või protseduuri

dokumendile ja kuva seotud pildid” kirjeldas kuvatava sisu ja esitlusviisi valikut. Need

lahendused võivad toetada info märgatavust, kuid hindamisel ei olnud piisavalt demonstreeritud

13 Sõnumi ID 1116939.

16 (34)

kasutaja tehtavat prioriteedivalikut ja selle rakendumist töölaua infosisule. Punase värvi

kasutamist ei käsitletud iseenesest puudusena. Samuti eristati diagnooside valikut “kõik” või

“ainult alalised ning kõrge riski-ja ohuteguritega diagnoosid” prioriteetsuse valikust: nimetatud

väli paiknes seadistusvaates andmete kuvamise hulga alla ning kirjeldas andmestiku piiramist.

Samuti andmestiku piiramine oli esindatud “saatekirjad ja broneeringute” all. Selle olemasolu

ei saa jätta tähelepanuta. Puudus oli selle kasutajapoolse muutmise ja tulemuse

demonstreerimises. Kiireloomuliste saatekirjade punaseks märkamise puhul ei nõua Hankija

pakkujalt kliinilist definitsiooni, vaid hinnatava seadistamise loogikat.

7.5. Infoplokkide ümberjärjestamine

Vaidlustuses rõhutatakse üles-alla liigutamise juhtvahendite ja erineva järjestusega töölaudade

olemasolu. Ümberjärjestamise kontseptsioon oli Vaidlustaja proovitöös visuaalselt kujutatud.

Puudus puudutas nõutud tegevuse kasutajateekonda: hindaja ei saanud vastavat juhtvahendit

kasutades muuta konkreetse ploki asukohta ja näha sellest tegevusest tulenevat tulemust

töölaual. Ettevalmistatud järjestuste vahel valimine demonstreeris tulemusi, kuid ei näidanud

konkreetse ploki ümberjärjestamise toimingut piisavalt.

7.5.1. Hankija ei nõudnud kõiki võimalikke järjestusi ega vaba lohistamise tehnilist

realiseerimist. Hinnatav oleks olnud ka piiratud ettevalmistatud teekond, kus kasutaja vajutus

kindla infoploki üles- või allanupule viib selle ploki muudetud asukohaga olekusse ning näitab

tulemuse töölaual.

Töö oleks olnud 50 punkti vääriline, kui infoplokkide ümberjärjestamise lahendus on esitatud

kõikide töölaual kuvatavate infoplokkide jaoks ning ümberjärjestamise tulemus on kasutajale

töölaual nähtav. Lähteülesande p 2.1.1 kohaselt kohustuslikud teemad prototüübis on:

prototüübis tuleb disainida vähemalt järgmised infoplokid: uuringud ja protseduurid,

saatekirjad ja broneeringud ja diagnoosid. Lisaks tuleb lahendada riski- ja ohutegurite info

edastamine tänase ikooni lahenduse parandamiseks. Lähteülesande p 2.2 ütleb, et töölaua

konfigureerimisel peab kasutaja saama lisada patsiendi töölauale infoplokke, eemaldada

infoplokke ja muuta infoplokkide järjestust. Lähteülesande p 2.4 toob loetelu veel eraldi esile

nõuded prototüübile.

7.5.2. 40 punkti väärilisel tööl oleks pidanud Vaidlustaja infoplokkide ümberjärjestamise

lahenduse esitama 80% töölaual kuvatavate infoplokkide jaoks ning ümberjärjestamise tulemus

oleks kasutajale töölaual nähtav. Seetõttu hindas Hankija tööd 20 punkti vääriliselt:

infoplokkide lahendus on esitatud alla 50% töölaual kuvatavate infoplokkide jaoks. Lahendus

oli esitatud demonstratiivsel viisil, kuid puudus klikitav prototüüp, kus proovitöö

lähteülesandest lähtuvalt kasutaja seda teha oleks saanud.

Eeltoodud täpsustus kirjeldab hindamise ajal kasutatud faktilist alust. Kuna komisjoni täpsustus

kinnitab protokollis väljendatud järeldust, on tegemist olemasoleva põhjenduse avamise, mitte

uue hindamisaluse lisamisega.

7.6. Riski- ja ohutegurite käsitlemine

50 punkti tingimus nõudis, et riski- ja ohutegurid oleksid tavainfost visuaalselt eristatud ning

nähtavad ilma täiendava otsingu või klikita. Vaidlustaja ise möönab, et kiirabitöötaja vaates olid

riskid koheselt nähtavad, kuid perearsti rollis oli sama info kättesaadav päise kaudu ning selle

nähtavale toomiseks tuli teha täiendav klikk.

Seega ei olnud 50 punkti taseme sõnaselge tingimus kogu lahenduse ulatuses täidetud.

Rollipõhine erinevus kui selline ei olnud komisjoni etteheide. Hankija ei nõudnud, et perearsti

ja kiirabitöötaja riskivaated oleksid identsed. Puudus seisnes selles, et perearsti töölaual ei olnud

riskiinfo enne täiendavat tegevust kasutajale nähtav selliselt, nagu kõrgeim punktitase nõudis.

Komisjon arvestas lisaks riskiinfo eristatavuse ja järjepidevusega. Sama riski tähendus ei olnud

rollide vahel alati üheselt tuvastatav ning värvikasutus ei andnud kõigil juhtudel üheselt

17 (34)

arusaadavat riskitähendust. Seega ei ole põhjendatud Vaidlustaja väide, et Hankija

„karistas“ rollipõhise disaini kasutamise eest. Hinnati riskiinfo märgatavust ja arusaadavust

Hindamismetoodikas sätestatud tunnuste järgi.

7.6.1. Vaidlustuses rõhutatakse, et kiirabi vaates olid riskid vahetult nähtavad ning perearsti

vaates tuli vastava info leidmiseks teha täiendav klikk (ehk tänane TJT lahendus, ikooniga

kuva). Hindamisel oli määrav, kas patsiendi või tervishoiutöötaja tegevust mõjutav riskiinfo oli

kasutajale nähtav ja üheselt eristatav või tuli selle kuvamiseks teha täiendav tegevus (nt klikk).

Lähteülesande p 2.1.1 kirjeldas olemasoleva lahenduse puudusena riski-ja ohutegurite info

kättesaadavust päises oleva ikooni kaudu, ning seadis proovitöö eesmärgiks olulise info parema

märgatavuse ja kättesaadavuse. Eesmärk on näidata, kuidas riski-ja ohuteguritega seotud

oluline info oleks kasutajale kiiremini märgatav ja kättesaadav, kui tänases lahenduses.

Pakkuja võib otsustada:

• kuvada riski- ja ohutegurid eraldi infoplokkidena;

• kuvada need olemasoleva infoploki osana;

• kasutada muud lahendust, kui see toetab paremini kasutaja vajadusi.

Seega ei nõudnud Hankija mõlemas rollis (kiirabi ja perearst) sama riski-ja ohutegurite

kuvamist, ega identset kujundust, kuid eesmärk oli info kasutajale paremini nähtavale tuua.

Hindamismetoodika 50 punkti tingimus nõuab aga riski- ja ohutegurite nähtavust ilma

täiendava otsingu ja klikita, ehk info oleks tavainfost visuaalselt eristatud ning nähtav ilma

täiendava otsingu või klikita. Kiirabi vaate vastavus sellele tingimusele ei kõrvalda perearsti

vaates tuvastatud puudust. Seetõttu ei olnud lahenduses tervikuna täidetud 50 punkti tingimus,

mis nõuab info nähtavust ilma täiendava klikita.

Perearsti diagnooside infoplokis olid nähtavad ka mõned diagnoosikoodid, mida kiirabitöötaja

vaates käsitleti riski-ja ohuteguritena. Diagnoosikoodi olemasolu loetelus ei tähendanud siiski,

et selle riskitähendus perearsti vaates oleks üheselt eristavalt esitatud. Kiirabitöötaja vaates oli

vastav teave koondatud nimetatud riski-ja ohutegurite plokki koos selgitavate nimetustega,

perearsti vaates eeldas selle teabe avamine täiendavat tegevust. Hankija hinnang puudutas seega

riskiinfo märgatavust ja eristatavust.

7.6.2. 20 punkti kirjeldus hõlmab olukorda, kus riski-ja ohutegurite info leidmine eeldab

täiendavat tegevust või nende eristamine ülejäänud infost ei ole üheti mõistetav või järjepidev.

50 punkti kirjeldus lahendusele võimaldab kasutajale üheselt eristatavalt kuvada patsiendi või

tervishoiutöötaja tegevust mõjutavaid riski-ja ohutegureid. Riski-ja ohutegurid on tavainfost

visuaalselt eristatud ning nähtavad ilma täiendava otsinguta/klikita.

40 punkti taseme kirjeldus näeb ette olukorra, kus riski- ja ohutegurid on nähtavad ilma

detailvaatesse liikumata, kuid lahendus ei käsitle kõiki nimetatud olukordi või ei ole nende

eristamine täielikult üheselt mõistetav.

Diagnooside värvikasutus kinnitas hindamisel riskiinfo eristamise ebaselgust: sama riskiga

seotud info oli rollides esitatud erinevalt ning kiirabi vaates esines diagnoos E78.0 erineva

värvitähendusega. Erinevad värvid ei ole iseenesest viga, puuduseks oli kasutaja ebaselgus

värvide tähendust üheselt tuvastada. See selgitab protokollis nimetatud riskiinfo järjepidevuse

puudust, mitte nõuet kujundada rollid identselt.

Hankija hinnangul tuleb nähtavust eristada võimalusest teave alles tegevusega nähtavale tuua

(ikoonile vajutamine): enne päise elemendi kasutamist ei olnud perearsti töölaual nähtaval nt

nakkusohtlikud haigused, mis mõjutavad ka perearsti igapäevast tööd, eelkõige ohutust.

Hüpikakna avamine oli täiendav tegevus, mis on olemasolevas TJT lahenduses. Seetõttu lähtus

komisjon 20 punkti kirjeldusest otsesõnu nimetatud asjaolust. Detailvaatesse liikumise

puudumine üksi ei tõenda riskiinfo esialgset nähtavust.

18 (34)

7.7. Desktop- ja tahvlivaadete teostus

Hankija ei ole pidanud puuduseks eraldi seadistusvaate kasutamist ega lähtunud põhimõttest,

et rohkem korraga nähtavaid infoplokke tähendab alati paremat kasutatavust. Hindamisel

arvestati seda, kas ruumikasutus võimaldas konkreetse rolli töövajaduse seisukohalt infot

ülevaatlikult kasutada.

Komisjon tuvastas muu hulgas, et perearsti desktop-vaates hõivas diagnooside plokk olulise

osa nähtavast tööalast ning muu info eeldas kerimist; tahvli horisontaalvaates oli korraga nähtav

üks infoplokk. Kiirabitöötaja desktop- ja tahvlivaates hõivas riski- ja ohutegurite plokk valdava

osa nähtavast tööalast ning järgmise infoploki sisu jäi tahvlivaates nähtavast alast välja.

Komisjoni hinnang puudutas seega mitte kujunduslikku „õhulisust“ iseenesest, vaid selle mõju

patsiendi tervikinfo ülevaatlikule kasutamisele.

7.7.1. Vaidlustuses rõhutatakse kõikide vaadete olemasolu, TEDI kasutamist ja eraldi

seadistusvaate põhjendatust. Hankija ei väida, et eraldi seadistusvaade oleks keelatud, et kõik

infoplokid pidi korraga ekraanile mahtuma või et rohkem nähtavaid plokke tähendaks alati

paremat kasutatavust. Hindamisel arvestati paigutuse mõju konkreetsete rollide töövajadustele

(Lähteülesanne p 1.3 - kasutaja persoonade kirjeldused) ja info ülevaatlikule kasutamisele.

Lähteülesande p-te 1.3.2 ja 2.3 järgi peab perearsti rollivaade toetama krooniliste haiguste

jälgimist, ennetust ja pikaajalist ravijuhtimist. P-te 1.3.3 ja 2.3 järgi peab kiirabitöötaja

rollivaade toetama kiiret olukorra hindamist ja kriitilise info leidmist. Hindamismetoodika 50

punkti kirjeldused nõuvad, et kasutatud ruum võimaldaks kuvada infot ülevaatlikult ning

toetaks infoplokkide kasutamist, seadistamist ja töölaua puudutavaid tegevusi

7.7.2. Desktop-vaates oli perearsti töölaual “näide 1” nähtav ruum suuresti hõivatud

diagnooside plokiga Desktop-vaatel on kõrvuti tervise teekond ja diagnoosid, seega ei saa jätta

muljet, et diagnoosiplokk välistas igasuguse samaaegse infoplokkide kasutamise. Puudus esines

selles, et vaated ei võimaldanud infot ülevaatlikult kasutada. See ei põhjenda üksnes tühja ruumi

või kujunduslikku õhulisusega.

Tahvli horisontaalvaates oli korraga nähtav üks infoplokk, samal ajal kui töölaud sisaldas ühes

vaates, kerimata alla poole, kahte infoplokki. Kokku oli Vaidlustaja töös esitatud 7 infoplokki,

mis annavad ülevaatlikku infot, kuid persoonast lähtuvalt jäi ravikäsitluse ülevaade hajutuks ja

selleks, et infot leida pidi kas kerima või tegema lisakliki, et nt riski-ja ohutegureid näha.

Kiirabitöötaja desktop- ja tahvlivaates hõivas riski-ja ohutegurite infoplokk valdava osa

nähtavast töölauast. Tahvlivaates jäi järgmise infoploki sisu nähtavast alast välja. Riskiinfo

vahetu nähtavus oli lahenduse tugevus, kuid ploki paigutus ja ruumikasutus piirasid samal ajal

ülevaadet töölaua ülejäänud infost. Eelkõige oli haiguste ja seisundite loetelu kõrval jäetud

ulatuslikku ruumi vähese sisu ja tühjadele veergudele.

Hankija arvestab, et 40 punkti tase hõlmab olukorda, kus kõik vaated on esitatud, kuid

ekraaniruumi ei ole osaliselt kasutatud optimaalselt või info esitlus on vähem ülevaatlik. 20

punkti taseme kohaldamiseks peab puudus olema sisuliselt kaalukam: desktop- või tahvlivaate

lahendus ei võimalda infot ülevaatlikult kasutada. Eeltoodud konkreetsete vaadete ja

tööülesannete seos selgitab komisjoni hinnangut. Eraldi seadistusvaatest naasemine ja

muudatuse mõju nähtavus pärast salvestamist ei ole iseseisvalt puudus. Määrav seadistamise

puudus on kirjeldatud eelnevates vastuse punktides.

Komisjoni hinnang ei põhinenud üksnes ruumikasutuse mitteoptimaalsusel või kujunduslikul

eelistusel, vaid sellel, et konkreetsetes vaadetes ei toetanud paigutus patsiendi töölaua info

terviklikku ja ülevaatlikku kasutamist. Seetõttu vastas puudus 20 punkti tasemele.

Ka juhul, kui vaidlustuskomisjon peaks mõne desktop- või tahvlivaate puudust käsitama 40

punkti taseme puudusena, ei tähenda see automaatselt proovitöö nr 1 punktisumma tõstmist.

Hindamismetoodika p-i 1.5 järgi peab kõrgema punktitaseme saamiseks olema täidetud kõigi

selle taseme tingimuste kogum. Seadistatava töölaua terviklahenduse osas tuvastatud puudused

välistasid juba iseseisvalt 40 ja 50 punkti taseme.

19 (34)

7.8. Vaidlustaja on esitanud vaidlustusmenetluses tõendina pärast pakkumuste hindamist

screencast-video, mis nende sõnul näitlikustab ja selgitab prototüüpi, kasutajateekondi ning

seadistuste toimimisloogikat.

Hankija ei vaidle vastu sellele, et sellist salvestist võib kasutada tõendina ulatuses, milles see

võimaldab vaidlustuskomisjonil kontrollida, mis oli pakkumuste esitamise tähtpäevaks

esitatud .fig failis objektiivselt olemas ja hinnatav. Video ei saa aga muuta hindamise objekti

ega täiendada tähtpäevaks esitatud pakkumust praegu, alles vaidlustusmenetluse ajal uute

funktsioonide, kasutajateekondade või selgitava loogikaga. Iga videos demonstreeritud asjaolu

asjakohasus sõltub seega sellest, kas sama funktsioon või kasutajateekond sisaldus juba

tähtpäevaks esitatud proovitöös.

7.9. Vaidlustus lähtub ekslikust eeldusest, et Hankija nõudis pärast pakkumuste esitamist

täielikku ja piiramatut Figma klikitavust. RHAD ja teabevahetus näitavad teistsugust nõuete

kombinatsiooni: tehnilist pärisrakenduse loogikat ega kõiki konfiguratsiooniharusid ei pidanud

realiseerima, kuid kohustuslikud kasutajategevused tuli demonstreerida klikitavas prototüübis

ulatuses, mis tegi kasutajateekonna ja toimimisloogika hinnatavaks.

7.10. Vaidlustaja prototüüp demonstreeris mitmeid lahendusi heal tasemel, samas jäid

seadistatava töölaua kesksetest tegevustest mitmed ettevalmistatud näidisolekute või

kontseptsiooni tasemele. Eelkõige ei saanud kasutaja prototüübis ise teha mitut RHAD-is

kohustuslikuna nimetatud seadistamistegevust ega jälgida oma konkreetse tegevuse tulemust.

Sellest tulenevalt ei olnud täidetud vähemalt 40 punkti taseme „Seadistatava töölaua

terviklahenduse“ tingimus, mis nõudis vähemalt nelja tegevuse olemasolu.

Lisaks ei olnud 50 punkti tasemel nõutud infoploki andmemahu ja prioriteetsuse kasutajapoolne

muutmine hinnatavalt demonstreeritud ning riski- ja ohutegurid ei olnud perearsti vaates

nähtavad ilma täiendava klikita. Need asjaolud kinnitavad eraldi, et 50 punkti tase ei olnud

täidetud.

7.11. Hindamismetoodika p-i 1.5 järgi määrab proovitöö punktitaseme kõige kõrgem tase, mille

kõik tingimused on täidetud. Vaidlustaja ei ole näidanud, et tema proovitöö nr 1 vastaks 50

punkti taseme kõigile tingimustele. Olemasoleva materjali põhjal ei ole alust lugeda täidetuks

ka 40 punkti taseme kõiki tingimusi. Seetõttu oli Vaidlustaja proovitöö nr 1 hindamine 20

punktiga kooskõlas RHAD-i ja Hindamismetoodikaga ning 17.09.2026 Industry62 OÜ

pakkumuse edukaks tunnistamise otsuse kehtetuks tunnistamiseks puudub alus.

7.12. Hankija on hindamiskriteeriume kohaldanud objektiivselt ja ühetaoliselt kõigi pakkujate

suhtes. Hankija menetluses langetatud otsuse kontrollitavuseks peab see sisaldama asjaolusid,

mille alusel on pakkumus(ed) tunnistatud edukaks või viiteid dokumendile, kus on põhjendused

edukaks tunnistamise osas toodud (RKHKo 3-3-1-4512, p 29). Seejuures on vaidluse korral

hankijal õigus otsuse põhjendusi kohtumenetluses täpsustada (RKHKo 3-20-1198, p 21).

Hankija on otsuses esitanud põhjenduse ja leiab, et see on kooskõlas nii RHAD-iga kui

Vaidlustaja pakkumusega. Olukorras, kus Hankija tuvastab pakkumuses hindamismetoodika

alakriteeriumi tingimuse täitmises puuduse, ei olnud hankijal enam kaalutlusõigust ning ta pidi

Hindamismetoodika p-i 3.3 alusel punkte vähendama. Õige ei ole Vaidlustaja seisukoht, et nt

ühe põhjenduse äralangemisel on hindamisotsus tervikuna õigusvastane.

Hankija on teinud RHS § 117 lg-ga 1 kooskõlas oleva otsuse eduka pakkuja tuvastamisel ja

pakkumuste hindamisel. Seetõttu puudub alus Hankija otsuse tühistamiseks.

7.13. 13.10.2026 esitas Hankija täiendavad seisukohad.

7.13.1. Vaidlustaja argumentatsiooni läbivaks puuduseks on kahe sisuliselt erineva küsimuse

samastamine: kas prototüübis oli kavandatav funktsionaalsus visuaalselt kujutatud ning kas

20 (34)

prototüüp võimaldas vastavat RHAD-is nõutud kasutajategevust ja selle tulemust hindamiseks

piisavas ulatuses demonstreerida. Need asjaolud ei ole samatähenduslikud.

Hankija ei ole nõudnud Figma prototüübilt töötava tarkvararakenduse tehnilist

funktsionaalsust, piiramatut konfiguratsioonide arvu ega kõigi võimalike kasutajateekondade

läbiklikitavust. Hankija hindas RHAD-is ette nähtud UX/UI kontseptsiooni ja klikitavat

prototüüpi selle järgi, kas kohustuslikud kasutajategevused ja nende toimimisloogika olid

nõutaval tasemel demonstreeritud.

Vaidlustaja käsitleb seevastu juhtvahendite visuaalset olemasolu, ettevalmistatud

näidiskonfiguratsioonide esitamist ja erinevate lõppolekute kuvamist piisavana kõigi kõrgema

punktitaseme tingimuste täitmiseks. See tõlgendus jätab tähelepanuta hindamiskriteeriumide

sõnastuse, sh nõuded selle kohta, mida kasutaja peab saama prototüübis teha, muuta ja näha.

7.13.2. Vaidlustaja täiendavates seisukohtades on etteheide, et RHAD ei määratlenud piisavalt

täpselt prototüübi klikitavuse ulatust või üksikute kasutajategevuste demonstreerimise nõudeid.

Kui seda väidet käsitada etteheitena RHAD-i tingimuste õiguspärasusele või piisavale

selgusele, siis RHAD-i vaidlustamisele kohaldub RHS § 189 lg-s 2 sätestatud tähtaeg.

Vaidlustaja ei saa edukaks tunnistamise otsuse vaidlustamise kaudu saavutada RHAD-i

tingimuste tagantjärele muutmist või nende siduva tähenduse kõrvalejätmist.

7.13.3. Hindamismetoodika p-te 1.5 ja 3.3 kohaselt peab kõrgema punktitaseme saavutamiseks

olema täidetud kõigi vastava taseme tingimuste kogum. Kui kõrgema taseme kõik tingimused

ei ole täidetud, tuleb kontrollida järgmise madalama taseme tingimusi.

Proovitöö nr 1 hindamine ei põhine üksikute positiivsete ja negatiivsete omaduste aritmeetilisel

tasaarvestamisel. Mõne lahenduselemendi hea teostus ei kompenseeri teise kohustusliku

tingimuse täitmata jätmist. Seetõttu võib juba ühe kõrgema punktitaseme kohustusliku

tingimuse täitmata jätmine välistada selle punktitaseme kohaldamise.

Nimetatud põhimõttel on käesolevas vaidluses määrav tähendus. Vaidlustaja pakkumus sai

kokku 69,11 punkti ja Kolmanda isiku pakkumus 97,46 punkti. Isegi juhul, kui Vaidlustaja

proovitöö nr 1 punktisumma oleks 20 punkti asemel 40 punkti, oleks Vaidlustaja kogutulemus

89,11 punkti ning tema pakkumus ei tõuseks eduka pakkumuse ette.

Seetõttu ei piisa Vaidlustaja soovitud tulemuse saavutamiseks üksnes sellest, et mõne

hindamiskriteeriumi osas võiks olla põhjendatud senisest kõrgem punktitase. Vaidlustaja

proovitöö 50 punkti nõude põhjendatuse hindamisel tuleb kontrollida kõigi kõrgeima

punktitaseme tingimuste täitmist. Vaidlustaja ei ole seda tõendanud ning tema proovitöö nr 1

puhul tuvastatud puudused välistavad maksimaalse punktitaseme.

7.13.4. Vaidlustaja täiendavate seisukohtade keskne väide on, et Hankija nõudis hindamisel

tagantjärele suuremat klikitavust, kui oli ette nähtud RHAD-is ja Hankija 07.07.2026 selgitustes

vastuseks küsimustele ID 1110855 ja ID 1112063. See väide pole õige.

7.13.4.1. Lähteülesande p 2.2 nõudis konkreetsete kasutusjuhtude läbimängimist ning p 2.4

sätestas prototüübi kohustusliku klikitavuse ja loetles tegevused, mida prototüüp peab

sisaldama. Nendeks olid muu hulgas infoploki lisamine, eemaldamine, konfigureerimine ja

järjestamine ning rollivaate vahetamine.

Neid nõudeid tuleb tõlgendada koostoimes. Vaidlustaja tõlgendus, mille kohaselt piisaks

funktsionaalsuse visuaalsest kirjeldamisest sõltumata sellest, kas vastav kasutajategevus on

prototüübis hinnatav, muudaks klikitavuse ja kasutusjuhtude läbimängimise kohustuslikud

nõuded olulises osas sisutühjaks.

Hankija selgitused ei kõrvaldanud nimetatud nõudeid. Nendega täpsustati, et Figma

prototüübilt ei eeldata töötava rakenduse täielikku tehnilist loogikat ning funktsionaalsuste

demonstreerimiseks võib kasutada esinduslikke vaateid, olekuid, kasutajateekondi ja vajadusel

selgitavaid märkusi. Sellest ei tulene aga, et kohustusliku kasutajategevuse pelk visuaalne

21 (34)

kujutamine või kahe ettevalmistatud lõppoleku olemasolu tõendaks automaatselt selle tegevuse

nõuetekohast demonstreerimist.

Esindusliku kasutajateekonna olemuseks on kasutajategevuse ning selle loogilise ja nähtava

tulemuse arusaadav seos. Sellise seose demonstreerimiseks ei ole vaja realiseerida kõiki

võimalikke konfiguratsioonikombinatsioone ega tegelikku andmete salvestamise loogikat.

7.13.4.2. Vaidlustaja loob vastanduse täielikult töötava rakenduse ning üksnes staatiliste olekute

kaudu kirjeldatud kontseptsiooni vahel. RHAD nägi ette kolmanda lahenduse – klikitava UX/UI

prototüübi, mis demonstreerib nõutud kasutajateekondi, kuid ei pea realiseerima töötava

rakenduse tehnilist loogikat. Just sellest lähtus Hankija hindamisel. Hankija ei pidanud

RHAD-is ette määrama iga võimaliku Figma ühenduse, olekuvahetuse või tehnilise

teostusvõtte üksikasju, sest hindamise ese oli kasutajateekonna nõuetekohane

demonstreerimine, mitte konkreetse prototüüpimistarkvara tehniline kasutusviis.

Vaidlustaja väide, et Hankija nõudis kõigi võimalike seadistusnuppude ja

konfiguratsioonikombinatsioonide eraldi realiseerimist, ei vasta tegelikule hindamisalusele.

7.13.4.3. Seadistatava töölaua terviklahenduse puhul sätestab hindamismetoodika 50 punkti

taseme eeldusena, et prototüüp võimaldab kasutajal lisada ja eemaldada infoplokke, muuta

nende järjestust, seadistada infoplokkides kuvatavat infot ning salvestada seadistused

rollipõhiselt. Kõik nimetatud tegevused peavad olema kasutajale leitavad ja arusaadavad,

moodustama tervikliku seadistamise lahenduse ning võimaldama kasutajal näha seadistamise

tulemust töölaual.

Hindamisel tuvastati, et Vaidlustaja seadistusvaates olid küll visuaalselt kujutatud infoplokkide

näitamise ja peitmise lülitid, üles-alla liigutamise juhtvahendid ning infoploki sisu puudutavad

valikud, kuid need ei võimaldanud nõutud tegevusi kasutajateekondadena läbi mängida.

Kasutajal oli võimalik valida ettevalmistatud näidiskonfiguratsioonide vahel ja näha nende

tulemust. See demonstreeris eelnevalt koostatud lõppseisundeid, kuid ei näidanud piisavalt,

kuidas kasutaja saab ise konkreetset infoplokki lisada, eemaldada või selle asukohta muuta.

7.13.4.4. Vaidlustaja argumentatsioon samastab valmiskonfiguratsiooni valimise ja töölaua

konfigureerimise. Need ei ole samatähenduslikud tegevused. Töölaua konfigureerimise keskne

omadus on kasutaja võimalus määrata, millised infoplokid kuvatakse ja millises järjestuses.

Hankija ei nõudnud kõikide võimalike konfiguratsioonide loomist. Piisav oleks olnud ka

piiratud esinduslik kasutajateekond, mille kaudu olnuks hinnatav konkreetse

seadistamistegevuse ja selle tulemuse seos.

Vaidlustaja väide, et selline nõue oleks tinginud sadade või tuhandete Figma vaadete

koostamise ning muutnud kõrgeima punktitaseme saavutamise tehniliselt võimatuks, on

põhjendamatu. Ühe konkreetse tegevuse ja sellele vastava olekumuudatuse demonstreerimine

ei eelda kõigi võimalike konfiguratsioonide modelleerimist.

7.13.4.5. Vaidlustaja leiab, et Hankija on hinnanud viit kohustuslikku tegevust ebajärjekindlalt,

kuna aktsepteeris rollipõhise salvestamise demonstreerimist, kuid pidas lisamise, eemaldamise

ja järjestamise visuaalset kujutamist ebapiisavaks.

See argument ei arvesta hinnatavate tegevuste sisulisi erinevusi. Rollipõhise salvestamise

demonstreerimine ei eelda tegelikku andmete püsivat salvestamist Figma failis. Sellest ei tulene

aga, et teiste kasutajategevuste demonstreerimiseks piisaks üksnes juhtvahendite graafilisest

olemasolust.

Hankija lähtus kõigi tegevuste puhul samast põhimõttest: lahendusest peab olema hinnatav

nõutud kasutajategevus ning selle loogiline ja nähtav tulemus. Konkreetse tegevuse

demonstreerimise viis võib sõltuda tegevuse olemusest. Hankija kasutatud väljend hinnatavalt

realiseeritud tegevus ei kujuta endast uut hindamiskriteeriumi, vaid selgitab RHAD-is nõutud

tegevuse olemasolu ja hinnatavuse kontrollimist.

22 (34)

Komisjon leidis, et nõuetekohaselt demonstreeritud tegevuste ulatus vastas 20 punkti tasemele.

Vähemalt nelja tegevuse olemasolu eeldav 40 punkti tase ega kõigi viie tegevuse olemasolu

eeldav 50 punkti tase ei olnud täidetud.

7.13.5. Seoses kriteeriumiga „Infoploki seadistamine“ väidab Vaidlustaja, et Hankija on

vaidlustusmenetluses asendanud Protokollis esitatud faktilise etteheite uue etteheitega. Väite

aluseks on, et Protokollis märgiti andmemahu ja info prioriteetsuse seadistamise võimaluse

puudumist, samas kui hankija vastuses täpsustati, et vastavad elemendid olid visuaalselt olemas,

kuid nende kasutajapoolne muutmine ei olnud nõutud ulatuses demonstreeritud.

Hankija leiab, et tegemist pole hindamisotsuse faktilise aluse muutmisega.

Protokolli tuleb käsitleda tervikuna. Selles toodi välja seadistamise piiratud toimivus, sh

asjaolu, et mitmed visuaalselt esitatud seadistusvõimalused ei olnud klikitavad ja kasutaja ei

saanud neid ise läbi teha. Seega ei olnud hindamise ese algusest peale üksnes vastava

nimetusega tekstiväljade või valikuelementide olemasolu, vaid kasutaja tegelik võimalus

nõutud seadistusi prototüübis hinnataval viisil muuta.

Hindamismetoodika 50 punkti taseme sõnastus sätestas, et kasutaja saab määrata kuvatavad

andmed, andmete kuvatava andmemahu ning prioriteetsena esitatava info ning kõik need

seadistused on prototüübis esitatud ja kasutaja poolt muudetud.

Hankija 20.07.2026 vastus küsimusele ID 1116939 täpsustas samuti, et kõrgeima punktitaseme

saavutamiseks peab prototüübist olema selgelt hinnatav, kuidas kasutaja saab muuta kõiki

kolme nimetatud seadistust.

Vaidlustaja viidatud nelja näitliku vaate või oleku olemasolu ei tõenda, et need tingimused olid

täidetud. Erinevate ettevalmistatud seisundite esitamine ei tähenda automaatselt, et kasutaja sai

vastavaid seadistusi muuta ning nende muudatuste rakendumist nõutud kasutajateekonna kaudu

hinnata. Hankija esimene vastus avas Protokollis juba kirjeldatud puuduse faktilist sisu. Sellega

ei kehtestatud uut hindamiskriteeriumi ega muudetud hindamise eset.

7.13.6. Põhjendamatu on Vaidlustaja väide, et Hankija on loonud tagantjärele uue arusaama

prioriteetsena esitatava info tähendusest.

Lähteülesande p 1.4.2 kirjeldas kasutaja võimalust määrata, milline info on tema jaoks

prioriteetne ja kuvatakse esmajärjekorras. Seetõttu tuleb eristada kuvatava andmehulga

piiramist, info visuaalset esiletõstmist ning kasutaja poolt määratava prioriteetsuse

toimimisloogika demonstreerimist. Kuigi nimetatud lahendused võivad esineda koos, ei tõenda

ühe omaduse olemasolu automaatselt teise omaduse nõuetekohast realiseerimist.

Hankija ei ole nõudnud pakkujalt meditsiinilist otsustust selle kohta, milline diagnoos peaks

igas võimalikus kliinilises olukorras olema prioriteetne. Hinnati seda, kas kasutajale oli nõutud

ulatuses demonstreeritud võimalus määrata prioriteetsena esitatav info ning näha selle valiku

mõju töölaua infosisule.

7.13.7. Infoplokkide ümberjärjestamine.

Vaidlustaja leiab, et Hankija on põhjendamatult samastanud ümberjärjestamise lahenduse

puudumise juhtvahendite piiratud klikitavusega ning kohaldanud tagantjärele infoplokkide

hõlmatuse protsendilisi lävendeid.

Hindamiskriteeriumi tuleb tõlgendada selle eesmärgist ja terviklikust sõnastusest lähtudes.

Hindamise ese ei olnud üksnes see, kas kõigi infoplokkide juures on visuaalselt kujutatud üles-

alla liigutamise nuppe, vaid see, kas esitatud on nõutud ümberjärjestamise lahendus ning kas

kasutajale on hinnatavalt nähtav ümberjärjestamise tulemus.

Vaidlustaja prototüübis olid vastavad juhtvahendid kujutatud, kuid hindamisel tuvastatud kujul

ei saanud kasutaja nende abil nõutud tegevust läbi mängida. Ettevalmistatud järjestuste vahel

valimine demonstreeris lõppolekuid, kuid ei näidanud piisavalt konkreetse infoploki

ümberjärjestamise kasutajateekonda.

Hankija 07.07.2026 vastus küsimusele (ID 1112063) ei kõrvaldanud pakkuja kohustust esitada

23 (34)

ümberjärjestamise hinnatav lahendus. Hankija ei nõudnud kõiki võimalikke järjestusi ega vaba

lohistamise tehnilist realiseerimist, vaid nõutud tegevuse ja selle tulemuse piisavat

demonstreerimist.

Hindamismetoodikas nimetatud protsendilised lävendid puudutavad infoplokke, mille suhtes

ümberjärjestamise lahendus on nõutud tasemel esitatud. Nimetatud lävendite täitmist ei saa

järeldada üksnes sellest, et kõigi infoplokkide juures on kujutatud ümberjärjestamisele viitavaid

juhtvahendeid.

Hankija vastus täpsustas selle komisjoni poolt juba tuvastatud puuduse tähendust ja seost

vastavate punktitasemetega. Vaidlustaja väide, et Hankija on kehtestanud uue hindamisaluse, ei

ole põhjendatud.

7.13.8. Riski- ja ohutegurite käsitlemine.

Vaidlustaja väitel oli 50 punkti taseme tingimus täidetud, kuna kiirabitöötaja vaates olid riski-

ja ohutegurid nähtavad ilma täiendava klikita ning perearsti vaates oli võimalik vastav

infoplokk töölauale lisada.

Vaidlustaja tõlgendus on vastuolus hindamismetoodika sõnastusega.

Kõrgeima punktitaseme tingimus nõuab riski- ja ohutegurite visuaalset eristamist tavainfost

ning nende nähtavust ilma täiendava otsingu või klikita. Nõue puudutab riskiinfo tegelikku

märgatavust esitatud lahenduses, mitte üksnes võimalust muuta tulevikus töölaua seadistust

selliselt, et riskiinfo muutuks nähtavaks.

Vaidlustaja perearsti rollivaates oli riskiinfo kättesaadav päises asuva ikooni kaudu ning selle

nähtavale toomiseks tuli teha täiendav tegevus. See asjaolu on hindamismetoodika kõrgeima

punktitaseme tingimuse seisukohalt määrav.

Asjaolu, et kiirabitöötaja vaates oli riskiinfo vahetult nähtav, ei kõrvalda teises kohustuslikus

rollivaates esinevat puudust. Samuti ei muuda hinnangut Vaidlustaja argument, et perearst saab

soovi korral vastava infoploki töölauale lisada. Võimalus saavutada nõutud nähtavus alles

täiendava seadistamise tulemusena ei ole samastatav riskiinfo nähtavusega ilma täiendava

tegevuseta.

Hankija ei ole nõudnud mõlema rolli identset kujundust ega sama infoplokkide koosseisu.

Rollipõhine lahendus peab siiski vastama kõigile kohaldatavatele hindamistingimustele.

Rollipõhisus ei kujuta endast erandit riski- ja ohutegurite märgatavuse nõudest. Ka hüpikakna

kasutamine ei kõrvalda lisakliki tegemise vajadust. Asjaolu, et hüpikaken avaneb sama töölaua

kohal ega suuna kasutajat eraldi detailvaatesse, ei tõenda 50 punkti taseme tingimuse täitmist.

Vaidlustaja käsitlus tähendaks, et piisab funktsionaalsuse olemasolust mõnes võimalikus

konfiguratsioonis, sõltumata sellest, kuidas oli riskiinfo esitatud hinnatavates rollivaadetes.

Selline tõlgendus ei ole kooskõlas hindamismetoodika sõnastuse ega proovitöö eesmärgiga

parandada riski- ja ohutegurite info märgatavust.

Hankija hinnangul välistab nimetatud puudus ka iseseisvalt Vaidlustaja proovitöö nr 1

hindamise maksimaalse 50 punktiga.

7.13.9. Desktop- ja tahvlivaadete teostus.

Hankija ei nõustu Vaidlustaja seisukohaga, et 20 punkti taseme kohaldamine oli põhjendamatu,

sest kõik nõutud vaated olid olemas, kasutati TEDI disainisüsteemi ning ekraani kerimine on

kasutajaliidestes tavapärane lahendus.

Hindamismetoodika 50 punkti taseme tingimus ei piirdu nõutud vaadete olemasolu ega TEDI

komponentide kasutamisega. Eraldi nõutakse ülevaatlikku ruumikasutust, mis toetab

infoplokkide kasutamist, seadistamist ja töölauaga seotud tegevusi.

TEDI disainisüsteemi kasutamine ei kõrvalda pakkuja kohustust koostada kasutajate

töövajadustele ja etteantud ekraanisuurusele sobiv terviklik kasutajaliides. Samuti ei tähenda

disainisüsteemi komponentide nõuetekohane kasutamine automaatselt, et infoplokkide

paigutus, suurus, proportsioonid ja infotihedus vastavad kõrgeima punktitaseme tingimustele.

24 (34)

7.13.9.1. Hankija ei ole pidanud puuduseks ekraani kerimise tehnilist võimalust ega lähtunud

seisukohast, et kõik infoplokid peaksid olema korraga tervikuna nähtavad. Hindamisel arvestati

konkreetsete vaadete paigutuse mõju vastavate töörollide vajadustele ja patsiendi terviseinfo

ülevaatlikule kasutamisele.

Perearsti desktop-vaates hõivas diagnooside infoplokk olulise osa nähtavast tööalast ning muu

patsiendiinfo kasutamine eeldas täiendavat navigeerimist. Kiirabitöötaja desktop- ja

tahvlivaadetes hõivas riski- ja ohutegurite infoplokk suure osa nähtavast tööalast, piirates

samaaegset ülevaadet ülejäänud asjakohasest infost. Tahvlivaates avaldus probleem eriti selgelt

piiratud nähtava tööala tõttu.

Komisjoni etteheide ei puudutanud üksnes kujunduslikku õhulisust, tühja ruumi olemasolu või

kerimise vajadust, vaid nende asjaolude koosmõju patsiendiinfo ülevaatlikule kasutamisele.

7.13.9.2. Vaidlustaja väitel oleks Hankija 20 punkti taseme kohaldamiseks pidanud tõendama

lahenduse täielikku kasutuskõlbmatust.

Hindamismetoodika sellist tingimust ei sisalda. 20 punkti taseme kirjeldus käsitleb olukorda,

kus desktop- või tahvlivaate lahendus ei võimalda infot ülevaatlikult kasutada. Täielik

kasutuskõlbmatus ja info ebapiisav ülevaatlikkus ei ole samatähenduslikud.

Samuti ei tulene hindamismetoodikast, et kõik ekraanipinna kasutamisega seotud puudused

peavad vastama 40 punkti tasemele. Eristada tuleb osaliselt ebaoptimaalset ruumikasutust ning

sellist paigutust, mis ei võimalda infot nõutaval määral ülevaatlikult kasutada.

Vaidlustaja viide Hankija näidisandmestikule ei muuda hinnangut. Hankija 20.07.2026

selgitustes kinnitati, et näidisandmestiku kasutamine ei olnud kohustuslik ning pakkujad võisid

andmeid kohandada või kasutada enda näidisandmeid, kui need võimaldasid nõutud

funktsionaalsusi demonstreerida.

7.13.10. Ka eraldi seadistusvaate kasutamise kohta esitatud argument ei anna alust

hindamisotsuse muutmiseks. Hankija ei ole pidanud eraldi seadistusvaadet iseseisvalt keelatud

lahenduseks. Hinnati seadistamise kasutajateekonda tervikuna, sealhulgas seda, kuidas kasutaja

saab tehtud muudatust ja selle tulemust töölaual hinnata. Eraldi seadistusvaate lubatavus ja

vastava kasutajateekonna piisavus on erinevad küsimused.

7.13.11. Hankija ei nõustu Vaidlustaja väidetega, et vastustes vaidlustusele on Hankija muutnud

Protokolli faktilisi põhjendusi, mistõttu tuleks hindamisotsus kehtetuks tunnistada.

Hankija on kogu menetluse jooksul lähtunud samast hindamismetoodikast, samast pakkumuste

esitamise tähtpäevaks esitatud prototüübist ja samadest hindamisel tuvastatud puudustest.

Protokollis käsitleti seadistatava töölaua ebapiisavat toimivust, infoplokkide seadistamist ja

ümberjärjestamist, riskiinfo nähtavust ning desktop- ja tahvlivaadete puudusi. Hankija esimene

vastus avas nimetatud asjaolude faktilist ja õiguslikku sisu üksikasjalikumalt ning seostas need

vastavate punktitasemete tingimustega. Hindamisotsuse põhjenduste täpsustamine ei ole

samastatav hindamisotsuse muutmisega.

Vaidlustaja seisukoht, mille kohaselt iga üksikasjalikum selgitus või esialgse põhjenduse

täpsem sõnastamine kujutaks endast lubamatut uut hindamist, ei ole põhjendatud.

7.13.12. Arvestada tuleb proovitöö nr 1 hindamise olemust. Proovitöö nr 1 esemeks oli UX/UI

kontseptsioon ja klikitav prototüüp, mille kaudu tuli hinnata pakkuja võimekust kavandada

kasutajavajadustest lähtuv konfigureeritav patsiendi töölaud. Selline hindamine ei ole üksnes

arvutuslik ega mehaaniline, vaid sisaldab paratamatult erialast ja hinnangulist elementi. Hankija

peab ka kvalitatiivse hindamise puhul lähtuma hindamiskriteeriumidest, hindamismetoodikast,

asjakohastest faktilistest asjaoludest ning võrdse kohtlemise ja läbipaistvuse põhimõtetest.

7.13.13. Riigikohtu 11.12.2020 otsuse nr 3-20-1198/58 põhimõtted on käesolevas vaidluses

asjakohased eeskätt selles osas, et kvalitatiivse hindamise puhul võib hankijal olla

25 (34)

hindamisruum, kuid selle kasutamine peab olema RHAD-i ja hindamismetoodika alusel

kontrollitav. Hankija hindamine on kontrollitav, sest RHAD sätestas nii proovitöö eesmärgi,

kohustuslikud kasutusjuhud, klikitava prototüübi nõuded kui ka punktitasemete tingimused.

Lähteülesande p 2.2 nõudis kasutusjuhtude läbimängimist ning p 2.4 nõudis klikitavat

prototüüpi, mis sisaldab muu hulgas infoploki lisamist, eemaldamist, konfigureerimist,

infoplokkide järjestamist ja rollivaate vahetamist. Seetõttu oli Hankijal õigus hinnata mitte

üksnes seda, kas vastavad elemendid olid prototüübis visuaalselt kujutatud, vaid ka seda, kas

nõutud kasutajategevused ja nende tulemused olid hindamiseks piisavalt demonstreeritud.

7.13.14. Vaidlustaja esitatud ekraanisalvestise puhul tuleb arvestada, et hindamise objekt oli

pakkumuste esitamise tähtpäevaks esitatud proovitöö.

Hankija ei vaidlusta ekraanisalvestise kasutamist tõendina ulatuses, milles see võimaldab

kontrollida tähtpäevaks esitatud prototüübis objektiivselt sisaldunud funktsioone ja

kasutajateekondi. Samas ei saa pärast pakkumuste esitamise tähtpäeva koostatud salvestis

muuta hindamise eset ega täiendada tähtpäevaks esitatud pakkumust uute funktsioonide,

kasutajateekondade või selliste selgitustega, mis asendavad proovitöös esitamata

lahenduselemente. Ekraanisalvestise tõenduslikku tähendust tuleb seetõttu hinnata koos

esitatud algse prototüübiga.

7.13.15. RHAD-i tingimuste objektiivset arusaadavust toetab ka asjaolu, et samade

alusdokumentide alusel esitati teisi pakkumusi, mille puhul oli Hankijal võimalik nõutud

kasutajategevusi ja nende tulemusi hindamismetoodika kohaselt hinnata. Hankija ei käsitle seda

iseseisva tõendina Vaidlustaja pakkumuse puuduste kohta, sest iga pakkumust tuleb hinnata

individuaalselt. Küll aga kinnitab see, et Vaidlustaja tõlgendus, et RHAD piirdus sisuliselt

funktsionaalsuste visuaalse kirjeldamisega, ei olnud ainuvõimalik ega tulenenud objektiivselt

RHAD-i sõnastusest. Võrdse kohtlemise põhimõte ei võimalda Hankijal tagantjärele langetada

hindamisstandardit ühe pakkuja lahenduse eripära järgi olukorras, kus RHAD-is nõutud

klikitava prototüübi ja kasutusjuhtude läbimängimise nõuded kehtisid kõigile pakkumustele.

7.13.16. Vaidlustaja argumentatsioon tugineb läbivalt eeldusele, et RHAD-is sõnaselgelt nõutud

klikitava prototüübi ja kasutajategevuste läbimängimise tingimused olid Hankija selgitustega

sisuliselt kõrvaldatud või piirdusid üksnes funktsionaalsuste visuaalse kirjeldamisega.

Selline tõlgendus ei vasta RHAD-i sisule ega antud selgitustele. Hankija ei ole nõudnud töötava

rakenduse tehnilist loogikat ega kõigi võimalike konfiguratsioonide realiseerimist, vaid

kohustuslike kasutajategevuste ja nende tulemuste piisavat demonstreerimist.

7.13.17. Vaidlustaja prototüübis jäid mitmed nõutud seadistamistegevused ettevalmistatud

näidisolekute või kontseptsiooni tasemele. Lisaks esines puudusi infoplokkide seadistamise,

ümberjärjestamise, riskiinfo märgatavuse ning desktop- ja tahvlivaadete ülevaatlikkuse osas.

Nimetatud puudused olid Protokollis välja toodud ning nende tähendust täpsustas Hankija

vaidlustusmenetluses. Hindamiskriteeriume, nende osakaale ega hindamise eset ei muudetud.

VAIDLUSTUSKOMISJONI PÕHJENDUSED

8. Vaidlustaja vaidlustab oma pakkumuses esitatud proovitöö nr 1 - UX/UI kontseptsioon ja

klikitav prototüüp hindamise 20 punktiga. Vaidlustaja on seisukohal, et tema proovitööd nr 1

oleks tulnud Hindamismetoodika kohaselt hinnata maksimumpunktidega ehk 50 punktiga.

9. Vaidlustuskomisjon on seisukohal, et proovitöö nr 1 hindamine sarnaneb olemuslikult nn

loovtöö hindamisega ning selle hindamise hinnangulisest iseloomust tulenevalt on Hankijal

proovitöö nr 1 hindamisel ulatuslik kaalutlusruum, mistõttu on Hankija hinnang

26 (34)

vaidlustuskomisjoni või kohtu poolt kontrollitav üksnes piiratud ulatuses.

10. Seoses loovtöö hindamisega on Riigikohus oma 11.12.2020 otsuse 3-20-1198 p-s 17

leidnud, et vaidlustuskomisjonil ja kohtul tuleb hankija otsuse hinnangulisele iseloomule

vaatamata hinnata, kas hindamisel arvestati asjakohaseid, täielikke ja tõendatud fakte ning

õiguse üldpõhimõtteid, samuti, kas hindamine toimus RHAD-is teatavaks tehtud

hindamiskriteeriumide kohaselt (RHS § 117 lg 1). VAKO ja kohtud ei pea sedalaadi hinnangute

kontrollimisel asendama hankija hinnanguid enda omadega ega kõrvaldama kõiki mõeldavaid

kahtlusi (vt ka kolleegiumi otsus nr 3-20-718/28, p 18). Kõrvaldada tuleb aga vähemalt olulised

kahtlused.

Riigikohus selgitas oma eelnimetatud otsuse p-s 20 ka järgmist: [---] Hindamiskomisjonile peab

jääma vabadus oma tööd korraldada, muutmata hindamiskriteeriume ega nende osakaale.

Üldjuhul tuleks lisaks sisulistele hindamiskriteeriumidele RHAD-s määrata kindlaks

hindamismetoodika (sh punktiskaala), kuid see ei pea olema ammendav, teisisõnu võib seda

pärast pakkumuste avamist kohandada konkreetsetele pakkumustele. Hankijatel ei ole

kvalitatiivse hindamise kriteeriumidesse võimalik kirja panna kõiki detaile, mis võivad

hindamisel oluliseks osutuda. Vajaduse korral võib aga jätta metoodika ka ette kindlaks

määramata ja kujundada see tervikuna alles pärast pakkumuste avamist (Euroopa Kohtu otsus

asjas nr C-6/15: Dimarso, p-d 27-31; C-252/10 P:Evropaïki Dynamiki, p 35).

Hindamismetoodika kohandamise õigus annab hankijale pakkumuste hindamisel suurema

otsustusruumi kui pakkumuste vastavuse kontrollimisel (vrd kolleegiumi otsus nr 3-19-1464/41,

p 13). Hindamismetoodika võib põhineda nii absoluutskaalal kui ka samas hankes esitatud

pakkumuste suhtelisel võrdlusel. Suhtelise hindamismetoodika puhul peab võrdlemine olema

dokumenteeritud. Ka absoluutse hindamisskaala puhul peab hankija vajaduse korral selgitama

sarnaste pakkumuste erinevat hindamist.

11. Kuigi osana pakkumuse hindamisest on proovitöö nr 1 hindamine Hindamiskriteeriumi

alusel Hankija ainupädevuses ning nagu eespool märgitud, annab see kriteerium juba

olemuslikult hindajale suure hinnanguruumi, põhinedes võrdlemisi subjektiivsetel elementidel

(vt Riigikohtu 09.08.2016 otsuse nr 3-3-1-51-16 p 16), peab vaidlustuskomisjon Riigikohtu

otsusest nr 3-20-1198 tulenevalt käesoleval juhul kontrollima, kas pakkumuste hindamisel

Hankija:

1) lähtus RHAD-is kehtestatud hindamiskriteeriumidest, nende alakriteeriumidest ning

hindamise korrast;

2) arvestas hindamisel asjakohaseid, täielikke ja tõendatud fakte.

Juhindudes Riigikohtu otsuse nr 3-20-1198 p-st 21 [---] Seejuures on piisav, kui pakkumuse

edukaks tunnistamise korraldusest või selles viidatud dokumendist nähtuvad, millistele alustele

hankija otsustused tuginevad (kolleegiumi otsus asjas nr 3-3-1-45-12, p 29). Väga üldsõnalised

põhjendused võivad olla vastuolus RHS § 117 lg-ga 1 ja § 47 lg 4 p-ga 3, vaidluse korral saab

aga hankija otsuse põhjendusi kohtumenetluses täpsustada [---] arvestab vaidlustuskomisjon

Hankija otsuse põhjendatuse kontrollimisel ka Hankija poolt vaidlustusmenetluses esitatud

põhjendusi.

12. Proovitööde, sh proovitöö nr 1, hindamise korra on Hankija kehtestanud

Hindamismetoodikas.

Hindamismetoodika p-i 1.5 kohaselt: Hindamisel komisjon hindab proovitöö nr 1 ja proovitöö

nr 2 kriteeriumid vastava skooriga, kui kõik kriteeriumites vastava punktiskoori saamiseks

nimetatud tingimused on täidetud. Kui hinnatava kriteeriumite puhul on vähemalt üks

punktiskoori saamiseks nimetatud tingimus on täitmata (st vastab madalama punktiskoori

saamise nõuetele), antakse kriteeriumite eest madalamad punktid.

Hindamismetoodika p-i 3 „Proovitöö punktide arvutamine“ alapunktides on kehtestatud

27 (34)

proovitööde hindamise kord järgmiselt:

3.1 Proovitööd hindab hankekomisjon, kes langetab iga kriteeriumi kohta otsuse

konsensuslikult, andes punktid vastavalt defineeritud skaalale.

3.2 Kriteeriumitele antud punktide tulemused summeeritakse ja leitakse seeläbi proovitööle

omistatud punktid.

3.3 Proovitöö hindamisel annab komisjon iga hindamiskriteeriumi eest punktid kõrgeima

punktitaseme järgi, mille kõik tingimused on täidetud. Vastava punktitaseme saamiseks peavad

olema täidetud kõik selle punktitaseme juures nimetatud tingimused, kui konkreetse

alamkriteeriumi juures ei ole sätestatud teisiti. Kui pakkumus ei vasta kõrgema punktitaseme

kõigile tingimustele, kontrollib komisjon järgmise madalama punktitaseme tingimustele

vastavust.

13. Hankija on kehtestanud Hindamismetoodikas proovitöö nr 1 hindamiseks nelja-astmelise

punktiskaala: 50 punkti, 40 punkti, 20 punkti ja 1 punkt. Kuna vaidlustusmenetluses ei väida

Hankija ega Vaidlustaja, et Vaidlustaja proovitöö nr 1 oleks pidanud saama 1 punkti, toob

vaidlustuskomisjon alljärgnevalt ära 50, 40 ja 20 punkti andmise alused üksnes nende nõuete

osas, mille puhul esineb vaidlus. Alljärgnev tabel ei sisalda nõudeid, millele mittevastavust

Hankija ei ole Vaidlustaja proovitööle nr 1 ette heitnud.

1. 50 punkti 40 punkti 20 punkti

• Seadistatava töölaua

terviklahendus

Prototüüp võimaldab kasutajal

lisada, eemaldada infoplokke,

muuta infoplokkide järjestust,

seadistada infoplokkides kuvavat

infot ning salvestada seadistused

rollipõhiselt. Kõik nimetatud

tegevused on kasutajale leitavad,

arusaadavad ning moodustavad

tervikliku seadistamise lahenduse

ning kasutaja saab seadistamise

tulemust töölaual näha.

• Infoploki seadistamine

Kasutaja saab infoploki

seadistamisel määrata võimalikud

kuvatavad andmed, andmete

kuvatava andmemahu ning

prioriteetsena esitatava info. Kõik

nimetatud seadistused on

prototüübis esitatud ja kasutaja

poolt muudetud

• Infoplokkide ümberjärjestamine

Infoplokkide ümberjärjestamise

lahendus on esitatud kõikide

töölaual kuvatavate infoplokkide

jaoks ning ümberjärjestamise

tulemus on kasutajale töölaual

nähtav.

• Riski- ja ohutegurite käsitlemine

Lahendus võimaldab kasutajale

üheselt eristatavalt kuvada

patsiendi või tervishoiutöötaja

tegevust mõjutavaid riski- ja

ohutegureid. Riski- ja ohutegurid

• Seadistatava töölaua

terviklahendus

Lahendus võimaldab vähemalt

nelja järgmist tegevust:

infoplokkide lisamine,

eemaldamine, järjestamine,

infoploki sisu seadistamine või

seadistuse salvestamine

rollipõhiselt. Üks nõutud tegevus

puudub või ei ole lõpuni

lahendatud.

• Infoploki seadistamine

Kasutaja saab infoploki

seadistamisel määrata vähemalt

kolm järgmist omadust: kuvatavad

andmed, andmete kuvamise

järjekord, kuvatav andmemaht või

prioriteetsena esitatav info.

• Infoplokkide ümberjärjestamine

Infoplokkide ümberjärjestamise

lahendus on esitatud 80% töölaual

kuvatavate infoplokkide jaoks ning

ümberjärjestamise tulemus on

kasutajale töölaual nähtav.

• Riski- ja ohutegurite käsitlemine

Riski- ja ohutegurid on tavainfost

visuaalselt eristatud ning nähtavad

ilma detailvaatesse liikumata, kuid

lahendus ei käsitle kõiki nimetatud

olukordi või ei ole nende

eristamine täielikult üheselt

mõistetav.

• Desktop vaadete teostus

Kõik prototüübis esitatud vaated

• Seadistatava töölaua

terviklahendus

Lahendus võimaldab vähemalt

kahte järgmist tegevust:

infoplokkide lisamine,

eemaldamine, järjestamine,

infoploki sisu seadistamine või

seadistuse salvestamine

rollipõhiselt. Ülejäänud tegevused

puuduvad või on kirjeldatud ainult

kontseptsiooni tasemel.

• Infoploki seadistamine

Kasutaja saab infoploki

seadistamisel määrata vähemalt

kaks järgmist omadust: kuvatavad

andmed, andmete kuvamise

järjekord, kuvatav andmemaht või

prioriteetsena esitatav info.

• Infoplokkide ümberjärjestamine

Infoplokkide ümberjärjestamise

lahendus on esitatud alla 50%

töölaual kuvatavate infoplokkide

jaoks.

• Riski- ja ohutegurite käsitlemine

Riski- ja ohutegurid on lahenduses

käsitletud, kuid nende leidmine

eeldab täiendavat tegevust või

nende eristamine ülejäänud infost

ei ole üheti mõistetav või

järjepidev.

• Desktop vaadete teostus

Osa prototüübis esitatud vaateid

on teostatud desktop vaatena või

desktop vaadete lahendus ei

28 (34)

on tavainfost visuaalselt eristatud

ning nähtavad ilma täiendava

otsinguta/klikita.

• Desktop vaadete teostus

Kõik prototüübis esitatud vaated

on teostatud desktop vaatena.

Kasutatud ruum võimaldab kuvada

infot ülevaatlikult ning toetab

samaaegselt infoplokkide

kasutamist, seadistamist kui ka

töölauda puudutavaid tegevusi.

• Tahvli vaate teostus

Kõik prototüübis esitatud vaated

on teostatud tahvli vaatena.

Kasutatud ruum võimaldab kuvada

infot ülevaatlikult ning toetab

samaaegselt infoplokkide

kasutamist, seadistamist kui ka

töölauda puudutavaid tegevusi.

on teostatud desktop vaatena, kuid

osa vaadetest ei ole olemasolevat

ekraaniruumi kasutatud

optimaalselt või on info esitlus

vähem ülevaatlik.

• Tahvli vaate teostus

Kõik prototüübis esitatud vaated

on teostatud tahvli vaatena, kuid

osa vaadetest ei ole olemasolevat

ekraaniruumi kasutatud

optimaalselt või on info esitlus

vähem ülevaatlik.

võimalda infot ülevaatlikult

kasutada.

• Tahvli vaate teostus

Osa prototüübis esitatud vaateid

on teostatud tahvli vaatena või

tahvli vaadete lahendus ei

võimalda infot ülevaatlikult

kasutada.

14. Vaidlustuskomisjon on seisukohal, et Hindamismetoodika p-dest 1.5 ja 3.3 tulenevalt saab

proovitööle nr 1 tervikuna anda kas 50, 40, 20 või ühe punkti. Proovitöö hindamisel annab

Hankija (komisjon) hindamiskriteeriumi eest punktid kõrgeima punktitaseme järgi, mille kõik

tingimused on täidetud. Kui vähemalt üks punktitaseme saamiseks nimetatud tingimus on

täitmata (st proovitöö vastab madalama punktitaseme saamise nõuetele), antakse proovitöö nr

1 eest punktid madalama punktitaseme järgi. Seega ei tulnud Hankijal anda proovitöö nr 1 eest

iga Hindamismetoodikas nimetatud üksiku nõude/kriteeriumi (prototüübi detailsus,

seadistatava töölaua terviklahendus, Infoploki seadistamine jt; kokku 16) kohta eraldi punkte

skaalal 50, 40, 20 või 1 ning neid punkte seejärel summeerida. Proovitööle nr 1 tuli määrata

tervikuna kõrgeim punktitase, mille kõik tingimused olid täidetud.

Vaidlustuskomisjon möönab, et Hindamismetoodikas tekitab segadust asjaolu, et sõna

„kriteerium“ kasutatakse erinevates tähendustes:

1) proovitööd nr 1 ja nr 2 eraldi võttes (Hindamismetoodika p 1.5);

2) proovitööd nr 1 ja nr 2 koos (Hindamismetoodika p 2);

3) proovitööde nr 1 ja nr 2 hinnatavad nõuded/kriteeriumid (Hindamismetoodika p-i 4

tabelid).

Siiski leiab vaidlustuskomisjon, et hindamiskriteeriumi loogikaga ei ole kooskõlas metoodika,

mille kohaselt proovitööd nr 1 tuleks hinnata eraldi kõigi 16 nõude/kriteeriumi alusel, kuna

juhul kui üksikuid nõudeid/kriteeriume hinnata erinevate punktidega (50, 40, 20 või 1 punkt),

ei saa punktide summeerimisel proovitööle nr 1 tervikuna anda kas 50 (maksimaalselt), 40, 20

punkti või ühe punkti. Seega on õige Hankija väide, et piisab ühe 50 punkti taseme tingimuse

täitmata jätmisest, et välistada proovitöö nr 1 hindamine 50 punktiga.

15. Vaidlustaja on seisukohal, et Hankija on nõudnud proovitöö nr 1 hindamisel tagantjärele

prototüübi täielikku ja piiramatut klikitavust ehk tehnilist täislahendust, mille Hankija on

hankemenetluses antud selgitustega (sõnumid ID 1112063, 1110855 ja 1112180) välistanud.

Hankija leiab, et proovitöö nr 1 hindamisel ei nõudnud komisjon täieliku rakendusloogika,

tegeliku andmete püsivuse ega kõigi võimalike konfiguratsioonide realiseerimist. Hinnati seda,

kas RHAD-is kohustuslikuna nimetatud kasutustegevused ja nende toimimisloogika olid

klikitavas prototüübis selliselt demonstreeritud, et kasutaja tegevuse ja selle tulemuse vaheline

seos oli hinnatav.

29 (34)

15.1. Lähteülesande p-i 2.2 kohaselt pidi prototüüp mh minimaalselt sisaldama järgmiste

tegevuste läbimängimist:

• töölaua konfigureerimine – kasutaja saab lisada patsiendi töölauale infoplokke,

eemaldada infoplokke, muuta infoplokkide järjestust;

• infoploki konfigureerimine – kasutaja saab valida millist infot infoplokk kuvab, määrata

info prioriteetsust, valida kuvamise detailsust (nt võib kasutaja otsustada, kas

diagnooside infoplokk kuvab ainult riski- ja ohuteguritega seotud diagnoose, või

kroonilise haigusega seotud diagnoose või aktiivseid või ajaloolisi diagnoose, või kõiki

koos).

[---]

Lähteülesande p-i 2.4 järgi prototüüp peab:

• olema high-fidelity;

• olema klikitav;

[---]

sisaldama vähemalt:

• patsiendi töölaua põhivaadet;

• infoploki lisamist;

• infoploki eemaldamist;

• infoploki konfigureerimist;

• infoplokkide järjestamist;

• rollivaate vahetamist;

o perearsti rollivaade patsiendi töölauale;

o kiirabitöötaja rollivaade patsiendi töölauale;

• vähemalt ühest infoplokist algatatud navigeerimine detailvaatesse.

Lähteülesande p-i 2.5 kohaselt

Pakkuja peab esitama proovitöö nr 1 hindamiseks:

• Figma (’.fig) faili klikitavale prototüübile;

• Lühikirjelduse lahenduse loogikast (maksimaalselt ühe A4 ulatuses.

15.2. 07.07.2026 vastas Hankija pakkuja küsimusele proovitöö nr 1 kohta (sõnumi ID 1112063)

mh: [---] Proovitöö nr 1 puhul hinnatakse UX/UI kontseptsiooni, kasutajateekondi ja high

fidelity klikitava prototüübi kaudu lahenduse loogika arusaadavust. Figma prototüübilt ei

eeldata täielikku rakendusloogika toimimist samas ulatuses nagu töötavalt rakenduselt.

Proovitöö nr 1 puhul tuleb lähtuda Proovitöö lähteülesande punktis 2.1.1 nimetatud

kohustuslikest teemadest, mille kohaselt tuleb prototüübis disainida vähemalt järgmised

olemasolevad infoplokid: uuringud ja protseduurid, saatekirjad ja broneeringud ning

diagnoosid. Lisaks tuleb lahendada riski- ja ohutegurite info esitamine. Proovitöö raames ei

eeldata kõigi olemasolevate TJT infoplokkide ümberdisainimist ega kõikide võimalike

infoplokkide kombinatsioonide läbiklikitavat realiseerimist.

Funktsionaalsed käitumised, sh infoplokkide lisamine, eemaldamine, ümberjärjestamine,

seadistamine, konfiguratsiooni salvestamine ja rakendamine ning rollivahetusel vastava rolli

seadistuste kuvamine, tuleb Proovitöö nr 1 raames demonstreerida sellises ulatuses, mis

võimaldab Hankijal aru saada kavandatavast kasutajateekonnast ja lahenduse

toimimisloogikast.

Infoplokkide ümberjärjestamise puhul peab olema arusaadav, kuidas lahendus rakendub

prototüübis kuvatavatele infoplokkidele ja kuidas ümberjärjestamise tulemus kasutajale

nähtavaks muutub. See ei tähenda, et kõik võimalikud infoplokkide järjestused tuleb eraldi

Figma vaadetena läbi modelleerida.

Rollivahetuse ja rollipõhiste seadistuste puhul peab olema arusaadav, kuidas kasutaja aktiivset

30 (34)

rolli vahetab, kuidas vastava rolli salvestatud töölaua seadistused kasutajale rakenduvad ning

kuidas erinevate rollide seadistused on kasutaja vaatest eristatavad.

Figma prototüübis ei pea realiseerima tegelikku andmete salvestamise või püsivuse tehnilist

loogikat.

[---]

15.3. 07.07.2026 on Hankija vastuseks pakkuja küsimusele [---] Palume täpsustada, millises

ulatuses eeldatakse Proovitöö nr 1 puhul Figma klikitava prototüübi funktsionaalsust ning kas

kirjeldatud käitumiste puhul piisab kasutajateekonna ja lahenduse kontseptsiooni

demonstreerimisest või oodatakse nende täielikku toimimist prototüübis (sõnumi ID 1110855)

vastanud: Hankija selgitab, et Proovitöö nr 1 puhul hinnatakse UX/UI kontseptsiooni,

kasutajateekondi ja klikitava prototüübi kaudu lahenduse loogika arusaadavust. Figma

prototüübilt ei eeldata täielikku rakendusloogika toimimist samas ulatuses nagu töötavalt

rakenduselt.

Funktsionaalsed käitumised, sh konfiguratsiooni salvestamine, rakendamine, infoplokkide

järjestuse muutmine ja seadistuste kuvamine vastavalt kasutaja valikutele, tuleb Proovitöö nr 1

raames demonstreerida sellises ulatuses, mis võimaldab Hankijal aru saada kavandatavast

kasutajateekonnast ja lahenduse toimimisloogikast. Selleks võib kasutada esinduslikke vaateid,

olekuid, kasutajateekondi ja vajadusel selgitavaid märkusi.

Hankija ei eelda Proovitöö nr 1 puhul kõikide võimalike konfiguratsioonide või

rakendusloogika harude täielikku realiseerimist Figma prototüübis.

15.4. 07.07.2026 on Hankija vastuseks pakkuja küsimusele [---] Palume täpsustada proovitöö

ootust seoses patsiendi töölaua kontseptsiooni ja klikitava prototüübiga. Hankedokumentides

on märgitud, et proovitöö raames ootab hankija kasutajavajadusest lähtuvat konfigureeritavat

patsiendi töölaua kontseptsiooni ning klikitavat prototüüpi. Soovime täpsustada, kas on

aktsepteeritav lahendus, kus pakkuja esitab prototüübis laiemat visiooni või kontseptsiooni

patsiendi töölauast, kuid arendatud kood hõlmab üksnes hanke nõuetele vastavat

funktsionaalset skoopi. Teisisõnu, kas on lubatud, et prototüüp ja teostatud arendus ei vasta

täielikult 1:1, eeldusel, et kõik hanke nõutud funktsionaalsused on arenduses ning prototüübis

nõuetekohaselt realiseeritud?(sõnumi ID 1112180) selgitanud: [---] Proovitöö nr 1 eesmärk on

hinnata kasutajavajadusest lähtuvat UX/UI kontseptsiooni, kasutajateekondi ja klikitava

prototüübi kaudu lahenduse loogika arusaadavust. Proovitöö nr 2 eesmärk on hinnata töötavat

tehnilist lahendust RHAD-is sätestatud funktsionaalses ja tehnilises skoobis.

Pakkuja võib Proovitöö nr 1 prototüübis esitada ka laiemat visiooni või kontseptsiooni

patsiendi töölauast, kui see aitab selgitada kasutajavajadust, lahenduse loogikat või edasist

arendatavust. Sellisel juhul peab prototüübis ja/või lühikirjelduses olema selgelt arusaadav,

milline osa lahendusest vastab proovitöö nõutud skoobile ning milline osa on pakkuja täiendav

visioon või ettepanek. [---] Samas peab Proovitöö nr 1 ja Proovitöö nr 2 vahel olema sisuline

kooskõla: arendatud lahendus peab olema seostatav prototüübis esitatud põhikontseptsiooni,

kasutajateekondade ja nõutud funktsionaalsustega. Täiendavad prototüübis esitatud

lahendused ei tohi asendada ega varjata RHAD-is nõutud funktsionaalsuste nõuetekohast

esitamist ja realiseerimist.

16. Vaidlustaja on seisukohal, et eeltoodud selgitustega (sõnumid ID 1112063, 1110855 ja

1112180) andis Hankija juhised, et funktsionaalsust ei pea lahendama klikitavusega, vaid seda

oli lubatud selgitada ja demonstreerida esinduslike vaadete, olekute, kasutajateekondade ja

märkuste kaudu. Vaidlustaja leiab, et Hankija on Vaidlustaja proovitöö nr 1 hindepunkte

põhjendamatult vähendanud, tuginedes väitele, et teatavaid tegevusi ei saanud kasutaja ise

lõpuni läbi klikkida, eirates asjaolu, et vastav toimimisloogika ja kasutajateekond oli

prototüübis siiski esinduslike vaadete ja olekute abil selgelt ja arusaadavalt kirjeldatud.

Hankija on seisukohal, et tema poolt teabevahetuses antud selgitused vähendasid nõutava

31 (34)

tehnilise lahenduse realiseerimise ulatust, kuid ei kõrvaldanud Lähteülesande p-de 2.2 ja 2.4

nõuet, et kasutaja peab saama kohustuslikuna nimetatud konfigureerimistoiminguid teha ning

klikitav prototüüp peab neid tegevusi sisaldama. Selgitustega ei muudetud Hindamismetoodika

punktide andmise tingimusi.

17. Vaidlustuskomisjon möönab esmalt, et Lähteülesandest ja Hankija teabevahetuses antud

selgitustest (sõnumid ID 1112063, 1110855 ja 1112180) ei tulene üheselt mõistetavalt, millises

ulatuses pidi iga Lähteülesandes nimetatud kasutajategevus olema Figma prototüübis klikitavalt

teostatav. Samas on Lähteülesande ja Hankija selgituste koostoimes võimalik kindlaks teha

nõutud demonstreerimise ulatus.

RHS § 46 lg 3 kohaselt on hankija poolt hankemenetluses antavate selgitustega keelatud

riigihanke alusdokumente muuta. Lähteülesande p-i 2.2 kohaselt pidi prototüüp sisaldama

vähemalt töölaua konfigureerimise tegevuste läbimängimist, mille hulka kuulusid infoplokkide

lisamine, eemaldamine ja nende järjestuse muutmine. Lähteülesande p-i 2.4 kohaselt pidi

prototüüp olema klikitav ning sisaldama muu hulgas infoploki lisamist, eemaldamist,

konfigureerimist ja järjestamist. Hindamiseks tuli esitada Figma fail klikitavale prototüübile.

Hankija selgitas 07.07.2026 vastustes, et Figma prototüübilt ei eeldata täielikku

rakendusloogikat samas ulatuses nagu töötavalt rakenduselt ning kõiki võimalikke infoplokkide

kombinatsioone ei tule läbiklikitavalt realiseerida. Samas tuli funktsionaalseid käitumisi, sh

infoplokkide lisamist, eemaldamist, ümberjärjestamist ja seadistamist, demonstreerida sellises

ulatuses, mis võimaldab aru saada kavandatavast kasutajateekonnast ja lahenduse

toimimisloogikast. Funktsionaalsete käitumiste demonstreerimiseks võis kasutada esinduslikke

vaateid, olekuid, kasutajateekondi ja vajadusel selgitavaid märkusi ning kõiki võimalikke

konfiguratsioone või rakendusloogika harusid ei tulnud Figma prototüübis täielikult

realiseerida.

Seega ei tulenenud RHAD-ist ega Hankija selgitustest nõuet, et prototüüp peab võimaldama

„läbi klikkida“ kõik võimalikud kasutajategevused ja nende kõikvõimalikud kombinatsioonid

või et prototüüp peab toimima valmis tarkvararakendusena. Samas ei saa nõustuda Vaidlustaja

tõlgendusega, mille kohaselt piisaks nõutud funktsionaalsuse demonstreerimiseks sellest, et

vastavad juhtvahendid ja tegevuse võimalikud lõpptulemused olid prototüübis visuaalselt

kujutatud.

18. Vaidlustuskomisjoni hinnangul tuleb eristada funktsionaalsuse kontseptuaalset kujutamist

ning nõutud kasutajategevuse demonstreerimist klikitavas prototüübis. Esimesel juhul võib

prototüübist olla nähtav, milline juhtvahend on mingi tegevuse tegemiseks kavandatud või

milline näeks välja tegevuse tulemus. Teisel juhul peab esitatud lahendusest olema piisavalt

arusaadav seos kasutaja konkreetse tegevuse ja sellele järgneva tulemuse vahel. Sellise seose

demonstreerimine ei eelda kõigi võimalike konfiguratsioonide ega töötava rakenduse tehnilise

loogika realiseerimist.

Niisugust tõlgendust toetavad ka Hankija selgitused, milles on ühelt poolt välistatud kõigi

võimalike konfiguratsioonide täieliku realiseerimise nõue, kuid teiselt poolt nõutud

funktsionaalsete käitumiste demonstreerimist ulatuses, mis võimaldab aru saada

kasutajateekonnast ja lahenduse toimimisloogikast.

19. Eeltoodust tulenevalt ei nõustu vaidlustuskomisjon Vaidlustaja väitega, et Hankija nõudis

pakkumuste hindamisel tagantjärele „täielikku ja piiramatut klikitavust“. Hankija selgitustega

enne pakkumuste esitamist välistati täieliku rakendusloogika ja kõigi võimalike

konfiguratsioonide realiseerimise nõue, kuid ei kõrvaldatud siiski Lähteülesande p-des 2.2 ja

2.4 sätestatud kasutusjuhtude läbimängimise ja klikitava prototüübi nõuet.

Konkreetse kasutajategevuse demonstreerimiseks võis piisata piiratud arvust esinduslikest

vaadetest ja olekutest, kui nende põhjal oli piisavalt arusaadav kasutaja tegevuse ja sellele

järgneva tulemuse seos. Seega ei ole kasutaja tegevuse ja selle tulemuse vahelise seose

32 (34)

hinnatavuse nõue samastatav nõudega realiseerida prototüübis kõik võimalikud

konfiguratsioonid.

20. Eeltoodust lähtudes ei ole proovitöö hindamisel määrav üksnes see, kas vastavat

funktsionaalsust tähistav juhtvahend oli prototüübis visuaalselt olemas või kas prototüüp

sisaldas enne ja pärast tegevust kujutavaid vaateid. Hinnata tuli seda, kas prototüübi, selle

olekute ja kasutajateekondade kogumis oli RHAD-i kohaselt nõutud tegevus ning selle

loogiline tulemus piisavalt demonstreeritud.

Samas ei saa üksnes konkreetse juhtvahendi mitteklikitavusest automaatselt järeldada, et vastav

funktsionaalsus oli esitatud ainult kontseptsiooni tasemel. Hankija lubas ise funktsionaalsuse

demonstreerimiseks kasutada mh esinduslikke vaateid, olekuid ja kasutajateekondi. Seetõttu

tuli hinnata, kas Vaidlustaja valitud demonstreerimisviis võimaldas nõutud tegevusest ja selle

tulemusest piisavalt aru saada.

21. Nagu vaidlustuskomisjon leidis käesoleva otsuse p-s 14, saab proovitööle nr 1 anda

kõrgeima punktitaseme punktid üksnes juhul, kui kõik selle punktitaseme tingimused on

täidetud. Kui vähemalt üks vastava punktitaseme tingimus (nõue/kriteerium) on täitmata, tuleb

kontrollida proovitöö vastavust järgmise madalama punktitaseme tingimustele. Seetõttu ei piisa

Vaidlustaja taotletava 50 punkti saamiseks sellest, kui vaidlustuskomisjon tuvastab, et Hankija

üks või mitu konkreetset etteheidet ei olnud põhjendatud. Vaidlustaja proovitööle nr 1 saab anda

50 punkti üksnes juhul, kui see vastab eranditult kõigile 50 punkti taseme

nõuetele/kriteeriumidele.

Vaidlustuskomisjon märgib, et Edukaks tunnistamise otsusest nähtuvalt muutuks pakkumuste

paremusjärjestus Vaidlustaja pakkumuse kasuks Kolmanda isiku pakkumuse ees üksnes juhul,

kui Vaidlustaja pakkumus saaks proovitöö nr 1 eest maksimaalsed 50 punkti. Proovitöö nr 1

hindamine 40 punktiga 20 punkti asemel Vaidlustaja pakkumuse asukohta paremusjärjestuses

Kolmanda isiku suhtes ei muudaks.

Seetõttu on vaidlustuse lahendamisel määrav, kas Vaidlustaja proovitöö nr 1 vastas kõigile 50

punkti taseme nõuetele/kriteeriumidele. Kui vaidlustuskomisjon tuvastab vähemalt ühe

mittevastavuse 50 punkti taseme nõuetele/kriteeriumidele, ei ole vaidlustuse lahendamiseks

vaja võtta seisukohta kõigi ülejäänud Hankija etteheidete põhjendatuse või põhjendamatuse

kohta ega selle kohta, kas proovitöö vastas 20 punkti tasemele või 40 punkti tasemele.

22. Vaidlustuskomisjon kontrollib esmalt Vaidlustaja proovitöö nr 1 vastavust 50 punkti taseme

nõudele/kriteeriumile Riski- ja ohutegurite käsitlemine. Käesoleva otsuse p-s 21 toodust

tulenevalt piisab ühe 50 punkti taseme nõude/kriteeriumi täitmata jätmisest, et välistada

proovitöö nr 1 hindamine 50 punktiga.

Hindamismetoodika kohaselt vastab lahendus 50 punkti tasemele juhul, kui: Lahendus

võimaldab kasutajale üheselt eristatavalt kuvada patsiendi või tervishoiutöötaja tegevust

mõjutavaid riski- ja ohutegureid. Riski- ja ohutegurid on tavainfost visuaalselt eristatud ning

nähtavad ilma täiendava otsinguta/klikita.

Vaidlustuskomisjonile esitatud materjalidest nähtuvalt olid Vaidlustaja proovitöös nr 1

kiirabitöötaja rollivaates riski- ja ohutegurid kasutajale vahetult nähtavad, kuid perearsti

rollivaates oli riskiinfo kättesaadav päises asuva ikooni kaudu ning selle nähtavale toomiseks

tuli kasutajal teha täiendav klikk. Selle faktilise asjaolu üle Vaidlustaja ja Hankija vahel sisulist

vaidlust ei ole.

23. Vaidlustaja leiab, et eeltoodud asjaolu ei välista proovitöö nr 1 vastavust 50 punkti tasemele.

Vaidlustaja tugineb seejuures eelkõige sellele, et Lähteülesande eesmärk oli persoonapõhine

lahendus ning kiirabitöötaja ja perearsti infovajadused on erinevad. Samuti rõhutab Vaidlustaja

töölaua seadistatavust ning asjaolu, et perearstil oli võimalik riski- ja ohutegurite infoplokk

töölauale lisada. Lisaks on Vaidlustaja välja toonud, et perearsti vaates avanes päises olevale

33 (34)

ikoonile klikkides riskiinfo hüpikaknana samal töölaual ning kasutaja ei pidanud selle

nägemiseks liikuma eraldi detailvaatesse.

Vaidlustuskomisjon nõustub Vaidlustajaga selles, et Hindamismetoodika ei nõudnud perearsti

ja kiirabitöötaja rollivaadete identset kujundust ega riski- ja ohutegurite esitamist mõlemas

rollis samas vormis. Erinevate rollide infovajadustega arvestamine ei tähenda aga, et mõne

rollivaate puhul võiks jätta täitmata Hindamismetoodikas 50 punkti taseme jaoks sõnaselgelt

kehtestatud tingimuse.

Hindamismetoodika 50 punkti taseme kirjeldus ei piirdu tingimusega, et lahendus peab

võimaldama riski- ja ohutegureid kasutajale kuvada. Eraldi on sätestatud, et riski- ja ohutegurid

peavad olema tavainfost visuaalselt eristatud ning nähtavad ilma täiendava otsinguta/klikita.

Sellest tulenevalt ei piisa 50 punkti taseme saavutamiseks üksnes sellest, et lahendus võimaldab

kasutajal töölaua seadistamise tulemusena paigutada riski- ja ohutegurite infoploki töölauale

selliselt, et see oleks edaspidi vahetult nähtav. Nõutud nähtavuse saavutamine töölaua täiendava

seadistamise tulemusena eeldab kasutajalt täiendavat tegevust ega ole seetõttu samastatav

riskiinfo nähtavusega ilma täiendava otsingu või klikita.

Eeltoodud järeldust ei muuda asjaolu, et päises olevale ikoonile klikkides avanes riskiinfo

hüpikaknana samal töölaual ning kasutaja ei pidanud liikuma eraldi detailvaatesse. 50 punkti

taseme tingimuse seisukohalt on määrav, et riskiinfo nähtavale toomiseks tuli kasutajal teha

täiendav klikk. Asjaolu, et pärast klikki avanes teave hüpikaknas, mitte eraldi detailvaates, võib

omada tähendust madalamate punktitasemete eristamisel, kuid ei täida 50 punkti taseme

sõnaselget tingimust, mille kohaselt peab riskiinfo olema nähtav ilma täiendava otsingu või

klikita.

Seetõttu leiab vaidlustuskomisjon, et asjaolu, et Vaidlustaja lahendus oli persoonapõhine ja

seadistatav ning riskiinfo avanes perearsti vaates hüpikaknana, ei anna alust lugeda täidetuks

50 punkti taseme tingimust. Kuna perearsti rollivaates ei olnud riski- ja ohutegurid nähtavad

ilma täiendava tegevuseta, ei vastanud Vaidlustaja proovitöö nr 1 nõude/kriteeriumi Riski- ja

ohutegurite käsitlemine osas 50 punkti taseme kõigile tingimustele.

24. Kuna Vaidlustaja proovitöö nr 1 ei vastanud nõude/kriteeriumi Riski- ja ohutegurite

käsitlemine osas 50 punkti taseme tingimusele, ei saanud Hankija Hindamismetoodika kohaselt

anda Vaidlustaja proovitööle nr 1 50 punkti. Vaidlustaja pakkumuse asukoht paremusjärjestuses

muutuks Kolmanda isiku suhtes üksnes juhul, kui Vaidlustaja proovitööle nr 1 tuleks omistada

50 punkti. Proovitöö nr 1 hindamine 40 punktiga 20 punkti asemel Vaidlustaja pakkumust

pingereas Kolmanda isiku pakkumusest ettepoole ei viiks. Seetõttu ei ole vaidlustuse

lahendamiseks vaja võtta seisukohta selle kohta, kas kõik ülejäänud Hankija poolt Vaidlustaja

proovitöö hindamisel välja toodud puudused olid põhjendatud, ega selle kohta, kas Vaidlustaja

proovitöö nr 1 vastas tervikuna 20 või 40 punkti tasemele.

25. Eeltoodust tulenevalt on vaidlustuskomisjon seisukohal, et Vaidlustaja proovitöö nr 1 puhul

ei ole täidetud kõik nõude/kriteeriumi Riski- ja ohutegurite käsitlemine 50 punkti taseme

tingimused, mistõttu ei saanud Hankija hinnata Vaidlustaja proovitööd nr 1 50 punktiga. Kuna

proovitöö nr 1 hindamine 40 punktiga ei muudaks pakkumuste paremusjärjestust Vaidlustaja

kasuks, võrreldes Kolmanda isiku pakkumusega, ei saa vaidlustuses esitatud asjaolud tuua

kaasa Industry62 OÜ pakkumuse edukaks tunnistamise otsuse kehtetuks tunnistamist.

Vaidlustuskomisjon on seisukohal, et Hankija hindas Vaidlustaja proovitööd nr 1 vastavalt

RHAD-is kehtestatud korrale, sh Hindamismetoodikale ning kooskõlas RHS § 117 lg-ga 1.

Seega puudub alus Hankija otsuse kehtetuks tunnistamiseks, millega tunnistati Kolmanda isiku

pakkumus Riigihankes edukaks.

26. Vaidlustusmenetluse kulud

Lähtudes sellest, et vaidlustus jääb RHS § 197 lg 1 p-i 4 alusel rahuldamata, kuuluvad

vaidlustusmenetluse kulude osas kohaldamisele RHS § 198 lg-d 3 ja 8.

34 (34)

26.1. Hankija ei taotlenud kulude väljamõistmist.

26.2. Kolmas isik ei ole vaidlustusmenetluses faktiliselt osalenud.

26.3. Vaidlustaja kulud jäävad tema enda kanda.

(allkirjastatud digitaalselt)

Taivo Kivistik