OTSUS
Vaidlustusasja number
197-25/262909
Otsuse kuupäev Vaidlustuskomisjoni liige
Vaidlustus
23.09.2025
Ulvi Reimets
Nortal AS-i vaidlustus
sihtasutuse Põhja-Eesti
Regionaalhaigla riigihankes „e-Haiguslugu“ (viitenumber 262909) Nortal AS-i pakkumuse tagasi lükkamise otsusele
Menetlusosalised Vaidlustaja, Nortal AS, esindajad vandeadvokaat Erki Fels
ja advokaat Gregor Saluveer
Hankija, sihtasutus Põhja-Eesti Regionaalhaigla, esindaja Janika Pajula
Vaidlustuse läbivaatamine Kirjalik menetlus
RESOLUTSIOON
RHS1 § 197 lg 1 p 4 ja § 198 lg 3 alusel
1. Jätta Nortal AS-i vaidlustus rahuldamata.
2. Jätta Nortal AS-i vaidlustusmenetluses kantud kulud tema enda kanda.
EDASIKAEBAMISE KORD
Otsuse peale võib esitada kaebuse halduskohtule kümne päeva jooksul otsuse avalikult teatavaks tegemisest arvates (halduskohtumenetluse seadustiku § 270 lg 1).
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 (RHS § 200 lg 4).
ASJAOLUD JA MENETLUSE KÄIK
1. 12.02.2024 avaldas sihtasutus Põhja-Eesti Regionaalhaigla (edaspidi Hankija) riigihangete registris konkurentsipõhise läbirääkimistega hankemenetlusena läbi viidava riigihanke „e- Haiguslugu“ (viitenumber 262909) (edaspidi Riigihange) hanketeate.
2. 01.09.2025 laekus Riigihangete vaidlustuskomisjonile (edaspidi vaidlustuskomisjon) Nortal AS-i (edaspidi ka Vaidlustaja) vaidlustus Hankija 22.08.2025 otsusele lükata Nortal AS-i pakkumus tagasi.
1 riigihangete seadus
3. Vaidlustuskomisjon teatas 10.09.2025 kirjaga nr 12.2-10/197 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 15.09.2025 ja neile vastamiseks kuni 18.09.2025.
Vaidlustuskomisjoni poolt määratud tähtpäevaks esitas täiendavad seisukohad Vaidlustaja, teiseks tähtpäevaks Hankija.
Vaidlustaja esitas 15.09.2025 menetluskulude välja mõistmise taotluse.
MENETLUSOSALISTE PÕHJENDUSED
4. Vaidlustaja, Nortal AS, põhjendab vaidlustust järgmiselt.
4.1. Pakkumus peab tehnilise kirjelduse (edaspidi TK) p-i 2.2.2 järgi vastama miinimumtingimustele, mis on sätestatud TK lisas 4 (edaspidi Miinimumtingimused).
Pakutava toote vastavuse tõendamiseks pidid pakkujad viima läbi pakutava toote esitluse demokeskkonnas Hankija ruumides (edaspidi Demosessioon) (dokument „Menetluskord“ p- d 7.3 ja 7.3.1).
Hankija jõudis Demosessiooni tulemusel järeldusele, et Vaidlustaja pakkumus ei vasta kahele Miinimumtingimusele - nr 30 ja 41. Vaidlustaja ei ole nõus.
Kui Hankija on teabevahetuse kaudu hanketingimusi muutnud, esineb alus hankemenetluse kehtetuks tunnistamiseks.
4.2. Pakkumus vastab Miinimumtingimusele nr 30
4.2.1. Vaidlustaja tarkvara võimaldab automaatselt täita andmebaasis olevate andmetega skoore ja vorme. Vaidlustaja demonstreeris Demosessioonil tarkvara vastavust Miinimumtingimusele nr 30 ja Hankijal ei tekkinud ühtegi küsimust. Vaidlustaja on kinnitanud vastavust.
4.3. Pakkumus vastab Miinimumtingimusele nr 41
4.3.1. Hankija põhjendab otsuses mittevastavust kokkuvõtlikult nõnda: „Pakutud tarkvara demoversiooni kasutamisel tuvastas hankija, et
. Sellisena on standardsest arvutiekraanist väiksemal
ekraanil (nt tabletil) andmetega töötamine raskendatud ning sellist lahendust ei saa lugeda dünaamiliseks kasutajaliidese disainiks.“
Hankija toob otsuses esile ka teabevahetuse, mida ta Vaidlustajaga pidas.
Hankija esitas 26.05.2025 küsimuse: „Palun esitada meile täielik loetelu nendest vaadetest/vormidest, mis vastavad Web responsive nõudmistele (miinimumtingimus 41: Kõikidel tarkvara osadel, mis on lahendatud veebirakendusena, on kasutajaliidese disain Responsive ehk dünaamiline).“
Hankija teeb sellest teabevahetusest järelduse, et Vaidlustaja on kinnitanud nõudele
4.3.2. RHAD-s ei ole täpsustatud, mida tähendab, et kasutajaliidese disain on „responsive“. Ainus täpsustus „responsive“ kasutajaliidese disaini kohta on märkus: „dünaamiline“. See tähendab, et Hankija on „responsive“ funktsionaalsuse võrdsustanud dünaamilisusega. Samas seegi ei ole sisus selge. Tegemist on järelikult määratlemata mõistega. Määratlemata mõiste sisustamine ei tohi olla meelevaldne.2 Hankijal ei ole hanketingimuste tõlgendamisel eelisõigust.3
Dünaamiline disain tähendab, et kasutajaliides arvestab ekraani suuruse muutumisega ehk liidese kasutamisega erinevatest seadmetest.4 Kuna RHAD-s ei ole dünaamilisust detailsemalt täpsustatud, tuleb seda tõlgendada kui kuva muutust kasutaja interaktsiooni korral.
Samuti saab pidada kuva dünaamiliseks, kui andmete uuendamise korral ka kuvatud andmed uuenevad.
2 RKHKo 3-3-1-59-00, p 2.
3 TlnRnKo 3-23-2608, p 14.
4 Veebis: https://www.interaction-
design.org/literature/topics/responsivedesign?srsltid=AfmBOoq1C5bna HpKWpZFzN3Ngy8NBuv3SEm3PQQ6GP2tFnWMrUed-Zj.
Vaidlustaja pakkumuses on lähtutud põhimõttest, et infosüsteem peab olema optimeeritud vastavalt töövoole ning tagama võimalikult suure kasutajaliidese ennustatavuse, et vähendada
Vaidlustaja lähenemine võimaldab tagada, et kasutatava ekraani suuruse muutudes varem tuttavad dokumendivormid ja töövood on visuaalselt järjepidevad – vähendades nii võimalikke vigu dokumenteerimisel või digitaalse töövoo läbimisel. Selline järjepidevus on kiire tempo ja suure riskiga kliinilises töös oluline, et töötajad digilahenduse ootamatu käitumise tõttu patsiente ohtu ei seaks.
Kasutajamugavus ei ole dünaamilisuse juures esmatähtis. Tähtis on just navigeeritavus ja see, et lahendust saab kasutada erinevates seadmetes. Sellele annab tõestust fakt, et kasutajamugavus on pakkumuse hindamise kriteeriumiks,5 mitte aga vastavustingimus. Seega on asjakohatu Hankija otsuses tehtud märkus, et „
“. Niisuguse kommentaari
alusel ei saa pakkumust tagasi lükata.
4.3.3. Vaidlustaja küsis teabevahetuse kaudu (Sõnumi ID 905801) Hankijalt järgmise küsimuse: „Palume täpsustada mõned miinimumtingimuste punktid. Miinimumnõue 41:
„Kõikidel tarkvara osadel, mis on lahendatud veebirakendusena, on kasutajaliidese disain responsive ehk dünaamiline.“ Palume täpsustada, kas hankija nõustub, et olukordades, kus töövoog ja kasutajakogemus eeldavad fikseeritud suurusega kuva kasutamist, vastab lahendus miinimumnõudele. Näiteks on haiglas töövooge, mis on spetsiaalselt mõeldud suure eraldusvõimega ekraanidele või kindla füüsilise asukohaga seotud seadmetele, võimaldamaks optimeeritud kasutajakogemust konkreetse töövoo spetsiifikast lähtuvalt. Sellistel juhtudel aitab fikseeritud suurusega kuva tagada olulise teabe selge esitus ja vähendab riski, et oluline jääb märkamata.“
Hankija vastas: „Hankija nõustub selles osas, et neis olukordades, kus tegu on kindla füüsilise asukohaga seotud seadmetega, on kuva fikseeritud suurusega.“
Hankija vastusest järeldub, et Miinimumtingimus nr 41 ei eelda, et igas kasutajaliidese kuvas muutuvad paigutus ja väljad. Arvestades tavapärast haigla töö korraldust, on haigla infosüsteem peamiselt kasutusel fikseeritud töökohtades, näiteks spetsialisti kabinetis asuvas arvutitöökohas või osakonna tööjaamas/arvutitöökohas. Ka suuremad ekraanid on kasutusel kindlatel fikseeritud töökohtadel, näiteks operatsiooni päevajuhi tööjaamas. Mittefikseeritud töökohti on haiglas väga vähe.
5 Vt hindamise kriteerium „Infosüsteemi kasutusmugavus“.
. Seega on Vaidlustaja pakkumus kooskõlas Hankija antud selgitustega sellest, mida Miinimumtingimus nr 41 endas eeldab.
Alusetu on Hankija järeldus, et Vaidlustaja pakkumuse veebirakenduste kasutajaliidese disain on mittedünaamiline seetõttu, . Seda ei eeldatud.
4.4. Vaidlustaja palub vaidlustuskomisjonil suunata vaidlus Rahandusministeeriumile järelevalve algatamiseks (RHS § 205 lg 1 p 1), kui vaidlustuskomisjon peaks asuma seisukohale, et RHAD eeldab seda, et
.
4.5. Vaidlustaja täiendavad seisukohad.
4.5.1. Pakkumus vastab Miinimumtingimusele nr 30
Miinimumtingimus nr 30 on sätestatud tarkvarale kui pakutavale lahendusele, mitte vormidele. Vormide ehk spetsiifilise sisuga dünaamiliste dokumentide loomine ei ole arendustöö, arendustöö on dünaamiliste dokumentide lahendus kui tööriist. Vaidlustaja pakutav lahendus võimaldab automaatselt täita andmebaasis olevate andmetega skoore ja vorme ning Hankija ei ole tuvastanud vastupidist.
Tõele ei vasta Hankija väide, et uus lahendus on alles arendamisel ja seetõttu nad ei saanud
DünDok2 platvormil tehtud andmesisestusvormidel on olemas skooringute loomise võimekus ja Vaidlustaja demonstreeris seda demosessioonil (13.05.2025 video, alates 2:45:10).
Lisaks on kogu süsteemis andmesisestuses automatiseeritud patsiendi üldandmete sisestus.
Vaidlustaja pakutav lahendus vastab seega Miinimumtingimusele nr 30 ja Vaidlustaja on seda Demosessioonil demonstreerinud. Hankija on teinud meelevaldse järelduse Vaidlustaja selgitusest, et
Vorm ei ole pakutav tarkvara, seega ei ole Miinimumtingimus nr 30
sätestatud vormidele.
Vaidlustaja tänastel klientidel on
. Oluline on, et Vaidlustaja pakutav tarkvara võimaldab täita andmebaasis olevate andmetega skoore ja vorme.
Eelnevat selgitas Vaidlustaja ka Demosessioonil (Hankija on suisa selle tekstiosa vastuses
4.5.2. Pakkumus vastab Miinimumtingimusele nr 41
4.5.2.1. Vaidlustaja lahendus on kooskõlas Hankija teabevahetuses antud selgitusega:
„Palume täpsustada, kas hankija nõustub, et olukordades, kus töövoog ja kasutajakogemus eeldavad fikseeritud suurusega kuva kasutamist, vastab lahendus miinimumnõudele nr 41.“
„Hankija nõustub selles osas, et neis olukordades, kus tegu on kindla füüsilise asukohaga seotud seadmetega, on kuva fikseeritud suurusega.“
Hankija on esitanud vastuses vaidlustusele sellest teabevahetusest meelevaldse tõlgenduse. Hankija justkui ei andnudki pakkujatele teada, et lahendus ei pea olema täies ulatuses responsive, vaid lihtsalt nentis fakti, et praegu on seadmeid, mille puhul on kuva fikseeritud suurusega.6
Vaidlustaja esitas konkreetse küsimuse: kas loetletud olukorras on vastavus olemas? Hankija vastas jaatavalt. Kui Hankijal polnud soovi selle teabevahetuse raames Miinimumtingimuse nr 41 sisu täpsustada, on ta pakkujaid eksitanud ja Riigihanke menetlus tuleb tunnistada kehtetuks.
Vaidlustaja jääb seisukohale, et kuna RHAD-s ei ole „dünaamilisust“ täpsustatud, tuleb lähtuda Hankija teabevahetuses antud selgitusest. Vaidlustaja pakkumus on selgitusega kooskõlas ja vastab seega Miinimumtingimusele nr 41.
4.5.2.2. Isegi kui Hankija poleks teabevahetuses Miinimumtingimuse nr 41 sisu täpsustanud, oleks Vaidlustaja pakkumus ikkagi vastav. Hankija vastupidised väited ei vasta tõele.
6 Hankija vastus vaidlustusele, p 2.30.
Hankija väide vastaks tõele vaid siis, kui „responsive lahendus“ oleks tunnus, mida on võimalik objektiivselt tuvastada. Kasutajaliidese dünaamilisuse puhul ei ole binaarset skaalat
- see on määratlemata mõiste, mida pole võimalik objektiivselt mõõta. Hankijal ei ole hanketingimuste tõlgendamisel eelisõigust.8
Kui Hankija soov oli, et , oleks ta pidanud
ja saanud väga lihtsasti sellise täpsustuse RHAD-s teha. Kui Hankija koostab RHAD ebapiisaval või ebaselgel viisil, ei saa selle eest karistada pakkujat.9 Hankijast on väär nõuda, et tema puuduliku töö negatiivsed tagajärjed lükataks pakkuja õlule. 10 Puudulikult koostatud RHAD eest vastutab eranditult Hankija.11
Vaidlustajale ei saa ette heita ka selgituse esitamata jätmist. Vaidlustaja esitas selgituspäringu ja sai vastuse, . Järelikult on
tingimust Hankija ise täpsustanud. Alles pärast pakkumuste esitamist on Hankija otsustanud sellest täpsustusest taanduda.
4.5.2.3. Vaidlustaja pakkumus ei ole ka vastuolus Hankija poolt viidatud ISO standarditega.
12 Vaidlustaja pakkumuses ongi kasutajaliides üles ehitatud viisil, et tuvastab kasutaja ekraani
ISO standardid ei ole RHAD osa. Hankija ei ole nendele RHAD-s viidanud, mistõttu ei saa nendest lähtuda. Läbipaistvuse põhimõte (RHS § 3 p 1) eeldab, et pakkujate kohustused peavad olema selgelt määratletud.13 RHAD mitmeti mõistetavuse korral tuleb eelistada konkurentsi laiendavat tõlgendust.14
Oluline osa Hankija vastusest keskendub nö otstarbekusele dünaamiline disain on oluline (p 2.31), kuna õendustegevus toimub arvestatavas ja kasvavas osas tahvelarvutitel (p 2.32), mille jaoks on Hankija teinud olulisi investeeringuid (p 2.33). Seetõttu pole asjakohane väide, et mittefikseeritud töökohti on haiglas vähe (p 2.34).
7 Hankija vastus vaidlustusele, p 2.20.
8 TlnRnKo 3-23-2608, p 14.
9 TrtRnKo 3-21-258, p 14.
10 VAKO 46-21/232833, p 17.
11 RKHKo 3-3-1-24-13, p-d 38—39.
12 Hankija vastus vaidlustusele, p 2.27.
13 EKo C 531/16, p 23.
14 VAKO 73-17/183856, p 15; VAKO 196-19/215947, p 18; VAKO 256-10/121397, p 10; TlnHKo 3-16-924, p 15; TlnHKo 316-277, p 11;
TlnRnKo 3-18-2338, p 27; TlnRnKo 3-09-3081, p 12.
Need argumendid, isegi kui tõesed, ei oma vaidluses määravat tähtsust. Nagu viidatud, peab Hankija suutma oma tahte selgelt ja üheselt mõistetavalt RHAD-s kirja panna.
Hankijal võib olla väga loogiline ja põhjendatud vajadus saada funktsionaalsust X, aga kui funktsionaalsust X tehnilises kirjelduses ei sisaldu, ei saa sel alusel pakkumust tagasi lükata.
5. Hankija, sihtasutuse PõhjaEesti Regionaalhaigla, vaidleb vaidlustusele vastu.
5.1. Hankija tuvastas Vaidlustaja pakkumuse kontrollimise käigus, et see ei vasta kahele Miinimumtingimusele, millest tulenevalt lükkas Hankija Vaidlustaja pakkumuse tagasi.
Hankija ei ole RHAD vastuolus RHS § 46 lg-ga 3 lubamatult muutnud ning Hankija antud selgitusi ei saa käsitada kui RHAD-s kehtestatud tingimuste täiendamist ega kitsendamist. Tegemist ongi Vaidlustaja küsimusele vastates tingimuse selgitamisega. Hankija hinnangul puudub alus järelevalvemenetluse algatamiseks või veelgi enam Riigihanke kehtetuks tunnistamiseks.
5.2. „Menetluskorra“ p 7 näeb ette pakkumuste vastavuse kontrollimise korralduse. Selleks, et Hankija saaks pakkumuste vastavust kehtestatud tingimustele sisuliselt kontrollida ja hinnata ning teha Riigihankes põhjendatud otsuse, oli pakkujatel muu hulgas kohustus viia Hankija ruumides läbi pakutava tarkvara demonstratsioon (edaspidi Demosessioon) ning anda Hankijale selgitusi ja täiendavaid andmeid (vt „Menetluskord“, p 7.2, 7.3, 7.5 esimene lause ja TK p 2.2.1.9)15. Demosessiooni eesmärgiks oli hinnata pakkumustes sisalduva info tõesust (vt TK p 3.5)16 ja saada pakkujatelt pakkumuse kohta täiendavaid selgitusi (vt TK p 3.4.2)17. See tähendab, et Demosessioonil pidi pakkuja olema suuteline esitlema pakutavat tarkvara ning tõendama kõikide RHAD-s kehtestatud Miinimumtingimuste täitmist. Vastasel juhul ei oleks Hankijal olnud võimalik kontrollida pakkumuse vastavust sisuliselt.
Tulenevalt „Menetluskorra“ p 7.5 esimesest lausest lükkab Hankija pakkumuse tagasi, kui pakkumus ei vasta RHAD-s kehtestatud tingimustele või kui pakkuja ei esita tähtajaks Hankija nõutud selgitusi või kui pakkuja selgituste põhjal ei ole võimalik üheselt hinnata pakkumuse vastavust RHAD-s esitatud tingimustele.
5.3. Vaidlustaja viis Hankija ruumides läbi oma pakutava tarkvara Demosessiooni kolmel päeval, 13.05.2025-15.05.2025, mille käigus demonstreeris oma tarkvara demoversioonis viie patsienditeekonna läbimist ning vastas Hankija esindajate küsimustele. Miinimumtingimuste täitmise kokkuvõtlik ülevaatamine toimus 14.05.2025, mil arutleti ka vaidlusaluste Miinimumtingimuste nr 30 ja nr 41 täidetavuse küsimuste üle. Demosessiooni käigus ei suutnud Vaidlustaja näidata, selgitada ega muul moel tõendada pakkumuse vastavust Miinimumtingimustele nr 30 ja nr 41.
15 Menetluskord, p 7.2: Hankijal on õigus küsida pakkujalt esitatud pakkumuse kohta täpsustavaid andmeid ja täiendavaid selgitusi. Menetluskord, p 7.3 esimene lause: Hankijal on õigus nõuda ja pakkujal on kohustus viia läbi pakutava toote põhjalik esitlus demokeskkonnas hankija ruumides kohapeal.
Menetluskord, p 7.5 esimene lause: Hankija lükkab pakkumuse tagasi, kui pakkumus ei vasta riigihanke alusdokumentides seatud nõuetele või kui pakkuja ei esita tähtajaks hankija nõutud selgitusi või kui pakkuja selgituste põhjal ei ole võimalik üheselt hinnata pakkumuse vastavust riigihanke alusdokumentides esitatud tingimustele. TK p 2.2.1.9: Pakkuja esitab pakutavas HIS-s patsienditeekondade läbimise kohta demonstratsioonvideo ning selgituste andmiseks viib läbi live demonstratsiooni.
16 TK p 3.5: Demonstratsiooni käigus hindab hankija pakkuja poolt pakkumuses sisalduva info tõesust
17 TK p 3.4.2: Täiendavate selgituste andmiseks on pakkuja kohustatud pärast pakkumuse esitamist korraldama live demonstratsiooni pakutava HIS tutvustamiseks.
Demosessioonil tõusetunud küsimustele vastuste saamiseks pöördus Hankija riigihangete registri vahendusel 26.05.2025 Vaidlustaja poole päringuga (sõnumi ID 969040), küsides täiendavaid selgitusi Miinimumtingimuse nr 41 täitmise osas. 27.05.2025 Vaidlustajalt laekunud vastus kinnitas Hankijale Vaidlustaja pakkumuse mittevastavust.
5.4. Kui pakkumusest, Demosessioonist (mille eesmärgiks on Hankija võimalus veenduda pakkumuses esitatud andmete tõesuses) ja pakkuja täiendavalt esitatud selgitustest ei nähtu, et pakkumus vastab tingimustele, siis ei ole Hankijal võimalik pakkumust vastavaks tunnistada. Praegusel juhul ei olnud Hankijal muud võimalust kui Vaidlustaja pakkumus tagasi lükata, sest see ei vastanud Riigihankes kehtestatud tingimustele. Kui Hankija oleks tunnistanud vastavaks pakkumuse, mille Miinimumtingimuste täitmises ei olnud Hankijal võimalik veenduda, oleks tegemist pakkujate lubamatu ebavõrdse kohtlemisega ning Hankija poolt RHAD-s kehtestatud nõuete leevendamisega. Leebemad Miinimumtingimused oleksid võinud võimalike pakkujate ringi laiendada. Hankijal ei olnud võimalik tunnistada vastavaks pakkumust, mis pakkumuse esitamise hetkel RHAD-s kehtestatud Miinimumtingimustele ei vastanud.
5.5. Vaidlustaja pakkumus ei vasta Miinimumtingimusele nr 30
Demosessioonil selgus, et esitluse ajal kasutusel olnud tarkvara demoversioonis olid kasutusel
Pakkumuse hindamise ja vaidluse lahendamise kontekstis on oluline, et pakkumuse esitamise hetkel Vaidlustaja pakutud tarkvaral nõutavat funktsionaalsust ei olnud ehk Hankija tuvastas õigesti, et pakkumus ei vasta RHAD-s kehtestatud tingimustele (vt 13.05.2025 Demosessiooni salvestus, alates kell 02:17:53):
Pakkumuse esitamise ega Demosessiooni toimumise hetkel Vaidlustajal
mis tähendab, et Hankijal ei olnud võimalik sisuliselt kontrollida Miinimumtingimuse nr 30 täitmist ja veenduda, et
Vaidlustaja selgitus ja lubadus, et
, ei võimalda Hankijal
lugeda seda Miinimumtingimust täidetuks ja pakkumust vastavaks. Tegemist on Miinimumtingimusega, mille täitmist pidi Hankija hindama pakkumuse põhjal pakkumuse esitamise hetkel, veendudes pakkumuses esitatud andmete õigsuses muuhulgas ka Demosessioonil. Hankija ei saa jääda lootma, et Vaidlustaja täidab Miinimumtingimuse edaspidi, arendades vajalikud funktsionaalsused välja vastavalt hilisematel läbirääkimistel kokku lepitule. See tähendaks koheselt pakkujate ebavõrdset kohtlemist, arvestades, et potentsiaalsed pakkujad võisid jätta pakkumuse esitamata just sel põhjusel, et nad ei suuda täita esitatud nõudmisi pakkumuse esitamise tähtajaks.
5.6. Vaidlustaja pakkumus ei vasta Miinimumtingimusele nr 41
5.6.1. 14.05.2025 toimunud Demosessioonil Miinimumtingimuste täitmise kokkuvõtlikul
(vt 14.05.2025 Demosessiooni salvestus, alates kell 05:36:48).
Pärast Demosessiooni pöördus Hankija teabevahetuses 26.05.2025 Vaidlustaja poole (Sõnumi ID 969040), küsides täiendavaid selgitusi Miinimumtingimuse nr 41 täitmise osas, sest Vaidlustaja ise lubatud selgitusi Hankijale ei edastanud: „Pakkumus: 525629
Hankijal on pakkujale kaks küsimust: 1) Palun esitada meile täielik loetelu nendest vaadetest/vormidest, mis vastavad Web responsive nõudmistele! (miinimumtingimus 41: Kõikidel tarkvara osadel, mis on lahendatud veebirakendusena, on kasutajaliidese disain Responsive ehk dünaamiline). //…//“
27.05.2025 Vaidlustajalt laekunud vastus kinnitas Hankijale Vaidlustaja pakkumuse mittevastavust:
See tähendab, et Vaidlustaja pakutav tarkvara
ei vasta Miinimumtingimusele nr 41.
5.6.2. Vaidlustaja viidatud veebilingil ei ole mõistet „responsive“ seletatud vaidlustuses kirjeldatud viisil. Viidatud veebilingil18 on öeldud: „Responsive design is an approach to web design in which the interface adapts to the device's layout to facilitate usability, navigation and information seeking. Responsiveness is possible thanks to media queries, allowing the design to adjust automatically to the browser space to ensure content consistency across devices, and design elements being sized in relative units (%).” Vaidlustaja on mõiste seletamisel mugavalt viidatud allikas toodud definitsiooni teise ja olulise, mõiste tähendust sisuliselt avava, lause lihtsalt välja jätnud. Vaidlustaja viidatud veebilehelt nähtub üheselt, et Web responsive oluline eeldus on, et tegevus (kohandamine) toimub automaatselt,
. Mõistel „responsive“ ehk dünaamiline on IT- valdkonnas üldteadaolev tähendus, mis on toodud ka ISO standardites19 „responsive web design“ mõiste selgituse juures.
ISO standarditest nähtuvalt on „responsive web design“ puhul oluline, et veebileht on üles ehitatud viisil, mis tuvastab kasutaja ekraani suuruse ja vastavalt sellele muudab dünaamiliselt lehe kuva. Dünaamilise muutumise korral kohandub süsteem ise vastavalt olukorrale (automaatselt, ilma välise käsuta). Mõiste „dünaamiline“ on vastand mõistele „staatiline“, millest järelduvalt viitab dünaamiliselt muutumine sellele, et muutus toimub aja jooksul automaatselt, mitte käsitsi ette antud kujul.
Hankija ei nõustu Vaidlustaja seisukohaga, mille kohaselt selleks, et saaks lugeda kasutajaliidese disaini dünaamiliseks (responsive), piisab sellest, et
Sellise lahenduse puhul ei ole tegemist täielikult
responsive ehk dünaamilise lahendusega, nagu ka Vaidlustaja on ise 14.05.2025 Hankija
18 https://www.interaction-design.org/literature/topics/responsive- design?srsltid=AfmBOoq1C5bna HpKWpZFzN3Ngy8NBuv3SEm3PQQ6GP2tFnWMrUed-Zj 19 https://www.iso.org/obp/ui#iso:std:iso-iec-ieee:24765:ed-2:v1:en:term:3.3479
esitatud küsimusele vastates möönnud (vt alates 05:36:53 Vaidlustaja selgitus: „//…//
“). RHAD-s ei sisaldu tingimust, mis võimaldaks pakkujatel pakkuda nö osalist lahendust. Esitatud Miinimumtingimust ei muuda ka Hankija poolt teabevahetuse kaudu antud vastus esitatud küsimusele (Sõnumi ID 905801).
5.6.3. Fikseeritud töökohtades, kus ekraan on standardse suurusega, ei oma responsive disain sellist tähendust kui telefonis või tahvelarvutis tarkvara kasutamisel. Viimasega tuleb järjest enam arvestada, kuna töö efektiivsuse ja kvaliteedi tõstmine eeldab personali ajakasutuse pidevat parendamist, sh raviotsuseks vajaliku informatsiooni kättesaadavust otsuse tegemise kohal ja otsuste tegemise ja selle dokumenteerimise vahelise aja lühendamist.
Oma küsimuses esitas Vaidlustaja argumendi, et haiglas on töövooge, mis on seotud ainult kindla füüsilise asukohaga seadmetega. Täna see paraku tõesti nii on, selliseid töövooge on ka Regionaalhaiglas. Ning standardses monitoris on kuva fikseeritud suurusega. Eesti haiglates on kasutusel infosüsteeme, mis ei võimalda kaasaegset töökorraldust muuhulgas seetõttu, et nendel puudub responsive disain. Hankija hinnangul on vaidlustuses segi aetud põhjus ja tagajärg. Asjaolu, et Regionaalhaiglas on praegu kasutusel protsesse, mis on seotud ainult kindla füüsilise asukohaga seadmetega ja neis on kuva fikseeritud suurusega, ei tähenda seda, et Hankija oleks selle tõdemusega muutnud riigihanke alusdokumente. Hankija sooviks on hankida kaasaegne responsive disainiga tarkvara ning vastavalt RHAD tingimustele peab tarkvara olema täies ulatuses lahendatud responsive disainiga.
5.6.4. Hankija ei nõustu Vaidlustaja arutluskäiguga, mille kohaselt on enamus haigla infosüsteemist peamiselt kasutusel fikseeritud töökohtades, millest Vaidlustaja hinnangul saab järeldada, et kasutajaliidese responsive ehk dünaamilise disaini olemasolu puhul ei ole tegemist eriti olulise tingimusega. Selliselt on hakanud Vaidlustaja Hankijale nö ette kirjutama, millistele tingimustele peaks hangitav infosüsteem vastama, mis aga ei ole lubatav. Hankija on kehtestanud tingimused, millele peab hangitava tarkvara funktsionaalsus vastama ning pakkuja ei saa pakkumust esitades nõuda, et hankija teeks tingimustele mittevastava pakkumuse osas mööndusi.
Regionaalhaigla õendusvaldkonnas töötab ligi 61% kogu haigla personalist. Õendustegevus toimub Regionaalhaiglas hetkel juba arvestatavas osas tahvelarvutitel ning selle roll on ajas kasvav. Sellega haigla tööprotsessid ei piirdu. Regionaalhaigla liigub jätkuvalt mobiilsete töökohtade suunas ning töötajate kasutuses on mobiilselt töötegemist võimaldavad nutitelefonid ja tahvelarvutid. Seega on vajadus e-Haigusloo tarkvara kasutamiseks mittefikseeritud, mobiilsetel töökohtadel täiesti arvestatav ning kasvab ajas pidevalt.
Hankija on teinud olulisi investeeringuid, soetamaks meditsiinilise personali jaoks tahvelarvutid ja nutitelefonid, mille kaudu infosüsteeme kasutatakse. Seega ei ole Hankija kui haigla arenguperspektiivi arvestades mõeldav, et uut infosüsteemi ei ole võimalik vastavalt Hankija personali vajadustele kasutada. Kui uue infosüsteemi kasutajaliidese disain ei ole responsive ehk dünaamiline ning ei oma vastavat võimekust, siis on personalile tahvelarvutite ja nutitelefonide soetamiseks tehtud investeeringud olnud asjatud, sest neid ei ole võimalik täies mahus eesmärgipäraselt kasutada.
Vaidlustuses esitatud väide, nagu oleks mittefikseeritud töökohti haiglas väga vähe, ei ole hetkel asjakohane. Pakkumuse hindamisel ei saa lähtuda sellest, kas nõutavate tingimustega lahendust hakatakse kasutama paljudel või vähestel töökohadel, sest RHAD-s on responsive
ehk dünaamilise kasutajaliidese disaini puudutav tingimus ilma täiendavate piirangute ja kitsendusteta. See tähendab, et nõue peab olema täidetud 100%, vastasel juhul oleks tegemist pakkujate ebavõrdse kohtlemisega (võimalikud pakkujad, kes otsustasid Riigihankes mitte osaleda, sest nende pakutav lahendus ei vastanud kehtestatud nõudele täies ulatuses). Miinimumtingimuse nr 41 puhul on tegemist tingimusega, millest ei saa teha mööndusi Vaidlustaja soovitud viisil.
5.7. Hankija täiendavad seisukohad.
5.7.1. Vaidlustaja pakkumus ei vasta Miinimumtingimusele nr 30
5.7.1.1. TK lisaks 4 olevatest Miinimumtingimustest tuleneb selgelt, et dokumendi vormid on tarkvara osaks20. See tähendab, et Miinimumtingimused kohalduvad ka tarkvara osaks olevatele vormidele.
Vaidluse lahendamisel on oluline, et pakkumuse vastavuse kontrollimise ajal ei vastanud pakkumus Miinimumtingimuses nr 30 kehtestatud nõudele, mille kohaselt pidi tarkvara võimaldama andmebaasis olevate andmetega automaatselt täita skoore ja vorme.
Demosessioonidel pidid pakkujad olema võimelised demonstreerima (tõendama), et nende pakutav lahendus vastab Riigihankes kehtestatud Miinimumtingimustele. Selleks oli pakkujatele ette antud 5 erinevat patsienditeekonda, mille esitlemisel pidi pakkuja olema suuteline lahenduse toimimist näitama. Vaidlustaja ei suutnud lahenduse toimimist näidata ning seda ei ole Vaidlustaja suutnud ümber lükata vaidlustuses ega ka 15.09.2025 täiendavates seisukohtades.
Vaidlustaja väidab sisuliselt, et Miinimumtingimus ei pidanudki olema pakutavas tarkvaras tervikuna täidetav. Hankija sellega ei nõustu. Riigihankes kehtestatud tingimustest ei saa mingil moel järeldada, et tingimus pidi olema täidetud vaid osaliselt või et Hankija pidi tingimuse täitmist kontrollima vaid osaliselt. Riigihanke tingimustes ei sisaldu sellist leevendavat nõuet. Isegi, kui tarkvara mingis osas oli vormide automaatne täitmine andmebaasis olevate andmetega võimalik, ei saa lugeda tingimust täidetuks, kui lahendus ei rakendunud kogu pakutavale tarkvarale. Hankijal oli õigus kontrollida lahenduse toimimist kõigis patsienditeekondade vaadetes.
20 Vt miinimumtingimus nr 29: 29. Andmesisestuseks on tarkvaras saadaval muudetavad dokumendimallid ja vormid
5.7.1.2. Vaidlustaja on oma seisukoha p-des 2.6 ja 2.7 lisanud piltidena väljavõtted pakutava tarkvara demoversioonist. Tegemist ei ole Demosessioonil Hankijale näidatud vaadetega, sh väljavõtetest ei nähtu, millal need on tehtud. Vaidlustaja seisukohast ei nähtu ning arusaamatuks jääb, kuidas on viidatud väljavõtted seotud Hankija poolt Vaidlustaja pakkumuse vastavuse kontrollimisega. Hankija hinnangul on tegemist vaidluse lahendamisse mittepuutuvate väljavõtetega ning need tuleb jätta tähelepanuta.
5.7.2. Miinimumtingimus nr 41 ei ole täidetud
5.7.2.1. Vaidlustaja on oma tõlgenduse esitamisel viidanud internetist leitavale veebilehele, samas kui Hankija tugineb ISO standardile. Jättes kõrvale tõsiasja, et nii Hankija poolt viidatud ISO standardid kui ka Vaidlustaja viidatud veebileht selgitavad mõiste „responsive“ tähendust sarnaselt, siis vaidluse korral, kummale allikale tugineda, ei saa olla kahtlust selles, et ISO standardis esitatud mõiste selgitus on võrreldes suvalise veebist leitud mõiste selgitusega usaldusväärsem.
Tõepoolest, Hankija viidatud ISO standardid ei olnud riigihanke tingimuste osaks. Samas ei tähenda see, et standardites esitatud mõiste seletust ei saa aluseks võtta hanketingimuses sisalduva vaidlusaluse mõiste „responsive“ tõlgendamisel. Riigihanke tingimuses kasutatud mõiste sisu tõlgendamiseks ei pea Hankija hinnangul olema hanke tingimustes ISO standarditele viidatud.
5.7.2.2. Kui hanketingimuse sisu on mõistetav konkreetses valdkonnas kasutusel oleva mõiste üldlevinud tähenduse kaudu, puudub vajadus hakata tingimust tõlgendama, eriti veel viisil nagu seda soovib Vaidlustaja teha. Hankija hinnangul tuleb lähtuda mõiste üldteada olevast tähendusest, mitte hakata tingimust tõlgendamise teel meelevaldselt laiendama. Laiendav tõlgendamine võib olla teatud juhtudel asjakohane ja lubatav, kuid see ei tohi viia olukorrani, kus riigihankes osalevaid pakkujaid koheldakse ebavõrdselt. Ka kohtupraktikast nähtub, et tingimuste tõlgendamisel tuleb lähtuda eelkõige mõistliku pakkuja arusaamast, kuid sugugi mitte alati ei tule tingimust tõlgendada viisil, et see võimaldaks riigihankes osaleda võimalikult paljudel pakkujatel21. Praegusel juhul on vaidlusalusel mõistel olemas Riigihankes mõistlikele pakkujatele teadaolev tähendus, mis ei ole mitmeti tõlgendatav ning sellest lähtudes tuleb vaidlusalust hanketingimust ka mõista.
VAIDLUSTUSKOMISJONI PÕHJENDUSED
6. Hankija 22.08.2025 „Riigihankes „e-Haiguslugu“ (viitenumbriga 262909) esialgsete pakkumuste vastavuse otsuses“ on otsustatud tuginedes RHS § 70 lg-le 1 ja § 114 lg-tele 1 ja 2 ning „Menetluskorra“ p-idele 6.3 ja 7.5 lükata tagasi Vaidlustaja Nortal AS-i pakkumuse, sest pakutav tarkvara ei täida Miinimumtingimusi nr 30 ja 41 (edaspidi Otsus).
Otsuse (p-id 19-21) kohaselt Hankija kontrollis ja veendus Demosessiooni käigus Nortal AS- i pakutava tarkvara funktsionaalsuste kontrollimisel, et:
1) pakutav tarkvara ei täida Miinimumtingimuste p-is 30 esitatud nõuet „Tarkvara võimaldab automaatselt täita andmebaasis olevate andmetega skoore ja vorme (Näide: Vanus, sugu)“.
21 TlnRnKo, 13.02.2024, nr 3-23-2608, p 14.
. Demosessiooni käigus ei õnnestunud pakkujal demonstreerida Miinimumtingimuse nr 30 täitmist.
Kõik nõutud funktsionaalsused pidid olema tarkvaral olemas pakkumuse tegemise hetkel ja Demosessioonil näidatavad. Kuna ka pakkuja ise on kinnitanud ning ka Demosessioonil on selgunud, et pakkumuse tegemise hetkel tarkvara ei võimaldanud automaatselt täita andmebaasis olevate andmetega skoore ja vorme, siis ei saa Miinimumtingimust nr 30 täidetuks lugeda.
2) pakutava tarkvara kõikidel osadel, mis on lahendatud veebirakendusena, ei ole kasutajaliidese disain Responsive ehk dünaamiline (ei täida Miinimumtingimuste p-is 41 esitatud nõudeid).
Hankija esitas 26.05.2025 selle kohta küsimuse (Sõnumi ID 969040): „Palun esitada meile täielik loetelu nendest vaadetest/vormidest, mis vastavad Web responsive nõudmistele! (miinimumtingimus 41: Kõikidel tarkvara osadel, mis on lahendatud veebirakendusena, on kasutajaliidese disain Responsive ehk dünaamiline).“
Vaidlustaja põhjendab Otsuse vaidlustamist sellega, et tegelikult vastab pakutav tarkvara mõlemale Otsuses viidatud Miinimumtingimusele.
7. RHS § 114 lg 2 esimene lause kohaselt lükkab hankija pakkumuse tagasi, kui see ei vasta riigihanke alusdokumentides esitatud tingimustele. Lahendades vaidlust pakkumuse tagasilükkamise otsuse üle tuleb vaidlustuskomisjonil tuvastada, kas riigihanke alusdokumentides on sätestatud tingimus(ed), millele hankija pakkumuse tagasilükkamisel tugines, ning kui jah, siis kas asjaomane pakkumus nendele tingimustele vastab.
Vaidlus on selles, kas Hankija on õigesti tuvastanud Vaidlustaja pakkumuse mittevastavuse Miinimumtingimustele nr 30 ja nr 41.
Vaidlustuskomisjon on seisukohal, et selleks, et Vaidlustaja saaks saavutada oma taotletava eesmärgi (pakkumuse tagasilükkamise otsuse kehtetuks tunnistamise), ei tohi Hankijal olla õigus üheski Otsuses toodud etteheites Vaidlustaja pakkumusele, kuna RHS § 114 lg 2 esimese lause kohaseks pakkumuse tagasilükkamise otsuseks piisab, kui Vaidlustaja pakkumuses esineb kas või üks mittevastavus Riigihanke alusdokumentidele, mis on sisuline ja mis ei ole selgitustega kõrvaldatav.
8. TK p-i 1.1.1 kohaselt Regionaalhaigla peab oma infotehnoloogilise taristu arendamisel vajalikuks lähiajal koondada Regionaalhaigla patsientide terviseandmed ühtsesse turvalisse keskkonda ning ravisuhte paremaks juhtimiseks muuta patsiendi terviseandmed uute tarkvaralahendustega tervishoiuteenuse osutamise protsessi kõigile osapooltele paremini kättesaadavaks.
TK p-i 1.1.2 kohaselt Hanke eesmärk on soetada Regionaalhaiglale kasutusõigus uuele
elektroonilisele haigla infosüsteemile (edaspidi: HIS), mis võimaldab ülalpool toodud muutusi saavutada. Hanke objektiks olev HIS ja sellega kaasnevad teenused on täpsemalt kirjeldatud peatükis "2. Hanke objekt" ja tehnilise kirjelduse lisades 1 ja 3.
TK p-is 2.2.2 on toodud HIS miinimumnõuded.
TK p-i 2.2.2.1 kohaselt pakutaval HIS-l peab olema Lisas 4 "Miinimumnõuded" toodud funktsionaalsus. Miinimumnõuded on ära toodud ka lisas 1 "Funktsionaalsed nõuded" ning märgistatud seal märkega "min". Miinimumnõuete täitmine on osa vastavustingimustest, mistõttu pakkumus tunnistatakse vastavaks üksnes juhul, kui pakutav HIS täidab kõiki miinimumnõudeid.
TK p-i 2.2.2.2 kohaselt Miinimumnõuete üle läbirääkimisi ei peeta. Hankija võib miinimumnõuetesse iga läbirääkimiste vooru järel lisada täiendavaid nõudeid vastavalt sellele, kuidas selguvad hankija eesmärkide täitmiseks vajalikud ja otstarbekad tingimused. Hankija ei ole täiendavate nõuete lisamisel piiratud, sh ei ole hankija kohustatud tagama, et täiendavate nõuete lisamise järel saavad endiselt kõik pakkujad esitada nõuetele vastava pakkumuse. Pakkuja peab arvestama, et hankija poolt täiendavate nõuete lisamine võib pakkujale kaasa tuua vajaduse pakkumusse lisada täiendavaid tooteid/mooduleid, mida pakkuja esialgu ei plaaninud pakkuda (nt olemasolevat radioloogia infosüsteemi asendav moodul jne).
TK p-i 2.2.1 kohaselt pakutav HIS peab toetama Regionaalhaiglale omaseid keerulisi patsienditeekondi. HIS sobivuse ja funktsionaalsuse hindamiseks on Regionaalhaigla koostanud 5 kõrge keerukustasemega patsiendi teekonda (vt Lisa 2 Protsessianalüüs), mis näitavad patsiendi liikumist Regionaalhaigla raviprotsessides. Nendeks teekondadeks on:
2.2.2.1.1. patsienditeekond "Mass kaelal (suuneelu vähk)"
2.2.2.1.2. patsienditeekond "Kompleksne sisehaige"
2.2.2.1.3. patsienditeekond "Äge müokardiinfarkt"
2.2.2.1.4. patsienditeekond "Raske liiklustrauma"
2.2.2.1.5. patsienditeekond "Raske sünnitusjärgne depressioon"
Riigihankes esitatud pakkumuste vastavuse kontrollimise alused on „Menetluskorra“ p-is 7.
„Menetluskorra“ p-i 7.3 kohaselt Hankijal on õigus nõuda ja pakkujal on kohustus viia läbi pakutava toote põhjalik esitlus demokeskkonnas hankija ruumides kohapeal. Hankijal on õigus esitlus salvestada ja esitada see asjasse puutuvatele kolmandatele isikutele (näiteks hanke üle järelevalvet teostavad ametiasutused).
7.3.1. Toote põhjalik esitlus sisaldab muuhulgas Tehnilises kirjelduse lisades kirjeldatud patsiendi teekondade läbimise esitlust tõendamaks pakutava toote vastavust RHD esitatud tingimustele.
7.3.2. Toote põhjalik esitlus peab võimaldama hankijal hinnata toote kasutusmugavust.
TK lisas 2 on toodud protsesside analüüs kõigi TK p-is 2.2.1 toodud patsienditeekondade kaupa.
Vaidlust pole menetlusosaliste vahel selles, et „Menetluskorra“ p-is 7.3 ette nähtud Demosessiooni eesmärgiks oli hinnata pakkumustes sisalduva info tõesust (TK p 3.5) ja saada pakkujatelt pakkumuse kohta täiendavaid selgitusi (TK p 3.4.2). Demosessioonil pidi pakkuja olema suuteline esitlema pakutavat tarkvara ning tõendama kõikide Miinimumtingimuste
täitmist. Pakkuja pidi Demosessioonil demonstreerima 5 erineva patsienditeekonna lahenduste toimimist kõikides protsessides. Demosessioonil esitatust sõltus see, kas pakkumus vastab Riigihanke alusdokumentides kehtestatud tingimustele või mitte. Pakkuja poolt peale Demosessiooni tehtud muudatused ei oma pakkumuse vastavuse kontrollimisel tähtsust.
Vaidlustaja viis Hankija ruumides läbi pakutava tarkvara Demosessiooni 13.05.2025- 15.05.2025. Hankija on vaidlustusmenetluses esitanud Demosessiooni salvestused ja kirjalikes seisukohtades väljavõtted neist. Vaidlustuskomisjon tuvastas salvestustelt, et Hankija esitatud väljavõtted on õiged.
9. Miinimumtingimus nr 30 - Tarkvara võimaldab automaatselt täita andmebaasis olevate andmetega skoore ja vorme (Näide: Vanus, sugu).
Sisuliselt tähendab Miinimumtingimus nr 30, et:
• andmebaasis olevad andmeid ei pea kasutaja käsitsi vormi või skooritabelisse sisestama;
• tarkvara suudab need väljad automaatselt täita, võttes andmed otse andmebaasist.
Vaidlustuskomisjon on seisukohal, et Miinimumtingimus nr 30 ega Riigihanke alusdokumendid ei anna alust asuda seisukohale, et see Miinimumtingimus võis olla täidetud ainult mõnes patsienditeekonnas või ainult mõnede TK lisas 2 toodud protsesside osas või et see ei kohaldu vormidele.
Vaidlustuskomisjon nõustub Vaidlustajaga, et Miinimumtingimus nr 30 on kehtestatud tarkvarale, kuid Demosessioonil pidi olema demonstreeritud see, kuidas tarkvara võimaldab kõikides patsienditeekondades ja protsessides täita andmebaasis olevate andmetega skoore ja vorme. Ja seda polnud võimalik teha vorme kasutamata. Dokumendivormide loomine on osa pakutavast tarkvarast. Seega Miinimumtingimus nr 30 kohaldub ka tarkvara osaks oleva platvormi poolt loodavatele vormidele.
9.1. Vaidlustaja vaidlustusmenetluses antud selgituste kohaselt on tema pakutava eHealth
Vaidlustuskomisjon leiab, et oluline polnud see, millist platvormi dokumendivormide loomiseks Vaidlustaja kasutas, oluline oli see, et Demosessioonil pidi Miinimumtingimuse nr 30 täitmise tõendamiseks saama automaatselt täita skoore ja vorme andmebaasis olevate andmetega (sõltumata sellest, mis platvormile need on loodud).
Kui
et Vaidlustaja seda ei teinud.
ja neid Demosessioonil demonstreerida. Salvestusest nähtub,
9.2. Hankija on pidanud Vaidlustaja pakkumust Miinimumtingimusele nr 30 mittevastavaks põhjusel, et Vaidlustaja ei suutnud Demosessioonil demonstreerida skooride ja vormide automaatset täitmist andmebaasis sisalduvate andmetega.
Hankija on kinnitanud (ja selles pole ka vaidlust), et
ja lahendada seda DünDok2 platvormi kaudu hiljem, siis, kui Hankija seda kindlasti soovib.
9.3. Demosessioonil Vaidlustaja näidatud slaid ei tõenda Miinimumtingimusele nr 30 vastavust. Ka Vaidlustaja täiendavates seisukohades esitatud väljavõtted vaadetega (mida Demosessioonil Hankijale ei näidatud) ei tõenda pakkumuse Miinimumtingimusele nr 30 vastavust - seda vastavust tuli demonstreerida Demosessioonil. Vaidlustuskomisjon nõustub Hankijaga, et oluline on, kas pakkuja suutis Miinimumtingimuste täitmist tõendada ettenähtud ajal (pakkumust esitades ja Demosessioonil pakkumuses sisalduvate andmete tõesuse kontrollimise ajal).
Vaidlustuskomisjon on seisukohal, et Hankija on õigesti järeldanud, et Demosessioonil kasutas Vaidlustaja vorme, mida ei saanud andmebaasis olevate andmetega automaatselt täita ja et tegemist on mittevastavusega Miinimumtingimusele nr 30.
10. Kuna Hankija on Vaidlustaja pakkumuse Miinimumtingimusele nr 30 mittevastavuse tõttu õigesti tagasi lükatud, ei ole asja lahendamiseks vaja hinnata, kas Vaidlustaja pakkumus ei vasta veel mõnele tingimusele. Vaidlustatud Hankija Otsus on õige, sest esineb üks mittevastavus Riigihanke alusdokumentide tingimusele.
Eeltoodust lähtuvalt jääb Vaidlustaja vaidlustus rahuldamata.
11. Vaidlustusmenetluse kulud
Lähtudes sellest, et vaidlustus jääb RHS § 197 lg 1 p-i 4 alusel rahuldamata, kuulub vaidlustusmenetluse kulude osas kohaldamisele RHS § 198 lg 3.
Hankija ei taotlenud kulude väljamõistmist. Vaidlustaja kulud jäävad tema enda kanda.
(allkirjastatud digitaalselt) Ulvi Reimets