Vaidlustaja täiendav seisukoht ja menetluskulude nimekiri

Riigihangete vaidlustuskomisjon Endla 13, 10122 Tallinn [email protected] 18.09.2024 SEISUKOHT hankija ja kolmandate isikute seisukohtadele Vaidlustaja: Net Group OÜ Registrikood: 10585438 A. H. Tammsaaretee 92, 13423 Tallinn Vaidlustaja esindaja: Vandeadvokaat Keidi Kõiv Advokaadibüroo RASK Rotermanni 8, 10111 Tallinn tel: 618 0820, faks: 618 0821 e-post: [email protected] Hankija: Tervise ja Heaolu Infosüsteemide Keskus Registrikood: 70009770 Pärnu mnt 132, 11317 Tallinn Hankija kontaktisik Kerli Lubja, e-post: [email protected] Kolmas isik I: Wisercat Estonia OÜ Registrikood: 14144207 Tartu mnt 80f, 10112 Tallinn Kolmanda isiku I esindajad: Vandeadvokaat Erki Fels Vandeadvokaadi abi Gregor Saluveer Advokaadibüroo TGS Baltic e-post: [email protected] Kolmas isik II: RingIT OÜ Registrikood: 12039823 Roseni 10, 10111 Tallinn e-post: [email protected] 1/8  Kolmas isik III: AKTSIASELTS HELMES Registrikood: 10364097 Lõõtsa 6, 11415 Tallinn e-post: [email protected] Kolmanda isiku III Vandeadvokaat Kadri Matteus lepinguline esindaja: Advokaadibüroo Matteus OÜ Maakri 30, Tallinn 10145 e-post: [email protected] 1. ASJAOLUD 1.1. Vaidlustuskomisjoni menetluses on Net Group OÜ (edaspidi vaidlustaja) vaidlustus Tervise ja Heaolu Infosüsteemide keskuse (edaspidi hankija) poolt riigihangete registris avaldatud riigihanke „Sotsiaalkaitse valdkonna teenuste arendus- ja hooldustööd“ (viitenumber 280265) tehtud otsustele. 1.2. Vaidlustuskomisjoni 13.09.2024 teatisega määrati asjas kirjalik menetlus ning osapooltele tähtaeg 18.09.2024 täiendavate selgituste ja dokumentide, sh menetluskulude taotluste esitamiseks ning nimetatud kuupäeval laekunud seisukohtadele vastamiseks kuni 23.09.2024. 1.3. Käesolevaga esitab vaidlustaja omapoolsed seisukohad hankija ja kolmanda isiku I 12.09.2024 seisukohtadele ning esitab taotluse menetluskulude väljamõistmiseks. 2. VAIDLUSTUSE SEISUKOHAD 2.1. Vaidlustaja tutvunud hankija ja kolmanda isiku I seisukohtadega nendega ei nõustu. Vaidlustaja hinnangul on hankija esitanud ka vastuolulisi seisukohti. 2.2. Enne sisuliste seisukohtade esitamist peab vaidlustaja vajalikuks viidata, et hankija on enda seisukohas omistanud vaidlustajale mitu väiteid, milliseid vaidlustaja ei ole tegelikkuses esitanud. Näiteks: (a) punktis 1.10.2 väidab hankija, et vaidlustaja seisukohad põhinevad väitel, et pakkujal puudus alternatiiv ja ainuvõimalik viis lahenduse loomiseks oli Zeebe pakutav klienditeek. Sellist väidet vaidlustaja esitanud ei ole. Vaidlustaja on vaidlustuse punktis 2.5 selgitanud, et TEHIKu tehnoloogilisest profiilist lähtuvalt on Zeebe integratsiooni võimalused eelistatult AMQP, REST ning aktsepteeritavana GraphQL, gRPC ning SOAP, samuti on vaidlustaja punktis 2.7 selgitanud, et Zeebe kasutab enda toimimises väga kindlaid tehnoloogiaid. Kumbki nimetatud selgitustest ei väida hankija poolt esitatut. (b) punktis 1.10.4 väidab hankija, et vaidlustaja on esitanud väite, et gRPC protokolli kasutamine on vältimatu. Sellist väidet vaidlustaja esitanud ei ole. Vaidlustaja on punktis 2.8 selgitanud, et hankija on ise enda vastuses kinnitanud, et Zeebe töövoohaldussüsteem, millise hankija on ise TEHIK IT profiili järgi määranud aktsepteeritavaks rakenduseks, on võimalik kasutada eeskätt gPRC protokolliga, samuti on vaidlustaja punktis 2.15 selgitanud, et hankija on enda vastustes jaatanud, et on teadlik, et Zeebe klienditeek kasutabki sisemiselt gRPC protokolli. Kumbki nimetatud selgitustest ei väida hankija poolt esitatut. 2.3. Eeltooduga püüab vaidlustaja omistada vaidlustajale väiteid, mida vaidlustaja ei ole esitanud ning milline käitumine menetluses on lubamatu. Pool peab kasutama oma menetlusõiguseid heauskselt ning hankija käesoleval hetkel sellist kohustust eirab. 2.4. Liikudes aga edasi sisuliste väidete juurde, siis ei nõustu vaidlustaja ka muus osas hankija ega ka kolmanda isiku I seisukohtadega. 2/8  A. Vaidlustaja on kasutanud proovitöö teostamisel tellija tehnoloogiaid 2.5. Hankija on enda vastuses kinnitanud ja rõhutanud, et protsessi juhtimine oli proovitöö kohaselt ette nähtud vaid ja üksnes vaid Zeebe töövoojuhtimise mootoriga.1 Lisaks on hankija enda vastuses ka kinnitanud, et gRPC oli üks hankija poolt kinnitatud ja riigihanke alusdokumentides välja toodud klientiteegi alternatiiv,2 nii nagu ka vaidlustaja seda vaidlustuses selgitab. Selle üle pooltel vaidlust ei ole. Vaidlustaja hinnangul ühtivad seega hankija seisukohad selgitustega, millised vaidlustaja esitas vaidlustuses, s.o. et proovitöö hindamismetoodika nägi ette nõude kasutada (a) kas hankija poolt riigihanke alusdokumentides kirjeldatud tehnoloogiaid või (b) nende mittekasutamise korral esitada põhjendused, miks selliseid tehnoloogiaid ei kasutatud ning kasutati miskit muud, mis oli riigihanke alusdokumentides nimetamata. 2.6. Sellele vaatamata on hankija käesolevas vaidluses asunud siiski väitma, et tegelikult oli riigihanke alusdokumentides esitatud hoopis nõue, et teatavate lahenduste puhul oli sellele tuginemine lubatav üksnes TEHIK arhitekti kooskõlastuse saamisel ning püüdnud tervikus vältida enda poolt hindamismetoodikas kasutatavate sõnaosade „tellija tehnoloogia“, „teisi tehnoloogiaid“, „aktsepteeritav tehnoloogia“ ja „alternatiivne tehnoloogia“ avamist ja selgitamist. Vaidlustaja hinnangul ei ole see aga kohane ning sellise käsitlusega püüab hankija väljuda vaidlusalusest küsimusest. Nimelt on hankija sätestanud riigihanke alusdokumentides omal valikul kasutatava tehnoloogiaga seonduvalt 4 erinevat mõistet ja seda erinevates kontekstides. Nüüd aga püüab hankija need vaidlustuse käigus koondada kaheks. See ei ole korrektne kahel põhjusel. 2.7. Esiteks nägi vaidlustaja hinnangul riigihanke alusdokument siiski ette väga konkreetselt tellija poolt eelistatud ja aktsepteeritud tehnoloogiad (ehk teisisõnu tellija tehnoloogiad), millele kogumis mistahes muu tõlgenduse andmine pole võimalik. Lisaks Tellija tehnoloogiale oli sätestatud ka alternatiivne tehnoloogia (ehk teisisõnu teine tehnoloogia) millise kasutamine hinnastati hindamismetoodika kohaselt hindepunktiga 1 ning milline ei olnud hankija poolt riigihanke alusdokumentides välja toodud „tellija tehnoloogia“ – ehk see ei olnud ei eelistatud ega aktsepteeritav tehnoloogia. 2.8. Teiseks ei näinud riigihanke alusdokumendid ette mistahes TEHIK arhitekti poole pöördumise ja kinnitamise protsessi/korda (s.h kus ja kellele kinnitada), mida pakkumuse koostamise ajal teostada. Seda seetõttu, et IT-Profiili (mis oli TK lisa 2) dokumendi puhul on tegemist Sotsiaalministeeriumi valitsemisala riist- ja tarkvara ning e-teenuste üldine haldamise ja arendamise infotehnoloogilise profiiliga, mis omab enim rolli siiski hankelepingu täitmise ajal. Nimetatud kinnitab Tehnilise kirjelduse punkt 8.3 – Täitja kohustub tööde teostamisel järgima tellija arendusjuhiseid (TK lisad 2- 6). 2.9. Nimetatut kinnitab ka hankija ise enda vastuse punktis 1.11.1, milles selgitab, et „Seega ei ole võimalik gRPC protokolli kasutada üheski loodavas IT lahenduses enne, kui see on TEHIKu arhitekti nõusoleku saanud“. Loodav IT lahendus ei ole aga sama, mis proovitöö. IT lahendus luuakse alles hankelepingu täitmise käigus, mitte aga proovitöö teostamisel. 2.10. Tehniline proovitöö sellist hankija poolt väidetavat nõuet (arhitektiga kooskõlastamiseks vastavalt IT profiilile) aga ei anna ning ei viita IT profiilile tervikus tegelikult üldse (!). 2.11. Ei raam- ega ka hankeleping ei sätesta pakkujatele kohustust järgida hilisemate arenduste korral proovitöö lahendusest, vaid proovitöö eesmärgiks on testida pakkujate võimekust hankija konkreetse ülesande lahendamisel. Seda hankija aga teinud ei ole, vaid on pakkujate hindamisel ja ka vaidlustusmenetluses asunud lähtuma nõuetest, milliseid ise riigihankes kehtestanud ei olnud. Sellega püüab hankija enda kehtestatud nõudeid kitsendada ja tõlgendada kontekstis, milliseid ei olnud tegelikult sätestanud. See ei ole aga lubatav ja õige. 2.12. Eelnevast jääb vaidlustaja enda vaidlustuses esitatud seisukoha juurde, et gRPC protokolli tuleb käsitleda tellija tehnoloogiana, vaidlustaja on arvestanud proovitöö koostamisel hankija tehnoloogiatega ning sellest johtuvalt on vaidlustaja pakkumusele omistatud puuduseid, mida 1 Hankija vastuse punktis 1.6, 1.10.1, 2 Hankija vastuse punkt 1.10.3 3/8  seal tegelikkuses ei esine ning mille tõttu on vaidlustajale määratud vähem hindepunkte kui hindamismetoodika ette nägi. B. Vaidlustaja on README failis esitanud ka põhjendused 2.13. Vastuolulisis väiteid esitab hankija ka põhjendustega seonduvalt. Nimelt, kuigi hankija on enda poolt teabevahetuses esitatud vastuses selgesõnaliselt märkinud, et „Kuigi nüüd riigihanke sõnumites nimetatud põhjus ("Zeebe klienditeek kasutab gRPC protokolli sisemiselt") on piisav põhjus, ei ole see põhjendus esitatud proovitöö osana ning seda ei saa arvestada kriteeriumi täitmise osas.“ Vaidlustaja hinnangul on sellise vastusega andnud hankija väga selge sõnumi, et tegemist on piisava põhjendusega hindamiskriteeriumi punkti 6 mõttes. Sellele vaatamata on hankija aga enda vastuse punktis 1.12.5 asunud väitma, et tegelikult hankija sellist piisavust ei ole kinnitanud. Tegemist on vastuolulise seisukohaga. 2.14. Nimelt, kui vaadelda hankija vastuse seotust hankija seisukoha punktiga 1.10.3, milles hankija kinnitab, et kui pakkuja soovis kasutusele võtta just Zeebe pakutava klienditeegi (ehk teisisõnu kolmanda osapoole tarkvara, mis lihtsustab suhtlust hankija poolt kohustuslikuna määratud töövoojuhtimise mootori Zeebe ja pakkuja loodud teenuse vahel), mis oli üks võimalik alternatiiv, siis tuli pakkujal arvestada, et nimetatu kasutab integratsiooniks gPRC protokolli. Antud vastus jaatab vaidlustaja hinnangul, et Zeebe poolt gPRC protokolli kasutamine on teadatuntud tõde, milline arusaam ühtib ka tegelikkuses hankija poolt antud vastusega sellest, et „Zeebe klienditeek kasutab gRPC protokolli sisemiselt“ on piisav põhjendus. 2.15. Eelnevast on vaidlustaja hinnangul selline hankija heitlik seisukohtade muutus ebasobiv ega tekita hankija käitumise suhtes ka usaldusväärsust. 2.16. Vaidlustaja jääb varasemalt avaldatud juurde, et isegi kui asuda seisukohale, et põhjendamine oli vajalik, siis ka seda on vaidlustaja tegelikult teinud. Proovitöö sisus on kirjalikult põhjendatud ja selgitatud, et kasutatud on gRPC protokolli ning miks ei kasutatud protsessimudelites otseühendust asünkroonse sõnumivahetusega (AQMP mitte-kasutamine) ning selgitatud sünkroonse suhtluse kasutamist läbi Hankija poolt ettekirjutatud teegi (gRPC kasutuse põhjendus). Korrates antud selgituse veelkord üle, siis „Protsessimudelite disainimisel on eelistatud nö puhtaid/müravabasid ja tänu sellele abstraktsemaid ja hoomatavamaid mudeleid. Kuigi BPM notatsioon võimaldab detailselt defineerida ka asünkroonset sõnumivahetust ning sõnumite korreleerimist, on otsustatud seda käsitleda kui mudelite äriperspektiivi kontekstis ebavajalikku sisevaadet ning selle asemel on see loogika viidud käesolevasse teenusesse.“ 2.17. Lause selgitab otseselt, miks ei ühendata protsessimudeleid AMQP-ga RabbitMQ külge, vaid tehakse päringuid läbi äriprotsesside mootori teenuse ehk kasutab kliendi etteantud teeki, mis omakorda kasutab gRPC-d. Täiendavalt selgitades siis kaalus vaidlustaja AMQP kasutamist ehk lõimida asünkroonne sõnumivahetus otse protesssimudelitesse, kuid otsustas lihtsamini jälgitava ja tegelikkust paremini peegeldava protsessimudeli kasuks, mis ei ole risustatud käitamise nüanssidega ega modelleeriks ekslikult äriprotsessi samme asünkroonsena vaid seetõtu, et see on vajalik tehnoloogiliste piirangute tõttu. Proovitöös liigutati selle käitamisloogika ning protsessimudelitega suhtlus Java teenusesse ehk viimane peab suhtlema Zeebe'iga protsesside käivitamiseks ning tööde läbiviimiseks. Nüüd tõepoolest - selles Java teenuses on gRPC protokolli kasutamine vältimatu, sest Zeebe'il puuduvad alternatiivsed liidesed (nt REST) protsessimudelitega vajalikul moel suhtlemiseks. 2.18. Hankija küll püüab väita, et selline liides on olemas, kuid oma selgituste juures jätab hankija täielikult märkimata selle, mida hankija oli ise proovitöös nõuetena kehtestanud. Nimelt, kuigi hankija püüab väita, et Zeebe puhul on kasutatav ka REST klienditeek, siis tegelikkuses proovitööks vajalikul moel protsessimudelitega suhtlemiseks on olemas AINULT gRPC liides. See omakorda tähendab, et kui serveril on olemas ainult gRPC liides, siis saab klientsüsteem sellega suhelda AINULT üle gRPC, olenemata klienditeegi kasutamisest või mittekasutamisest. Ja sellisel juhul ei saa me ikkagi rääkida gRPC-st kui alternatiivsest lahendusest. 2.19. Hankija väiteid ei lükka ümber ka tema poolt esitatud link, sest sellelt lingilt nähtubki just ülal kirjeldatu (vt allolev väljavõte ning kollane ruut). REST liidesel on äärmiselt piiratud "cluster" ja "user task" halduse võimekusega, st selle viimane versioon 8.5 võimaldab täna üksnes järgmist: Võimaldab Zeebe gateway klastri topoloogiat Link REST liidesele: pärida (Orange GET märge jooniselt) https://docs.camunda.io/docs/apis-tools/zeebe- api-rest/specifications/get-cluster-topology/ 4/8  Võimaldab mudelis „User task“ tüüpi töid Link REST liidesele: teostatud märkida (Roheline POST märge https://docs.camunda.io/docs/apis-tools/zeebe- joonisel) api-rest/specifications/complete-a-user-task/ Võimaldab mudelis „User task“ tüüpi töid Link REST liidesele: kasutajatele määrata (Roheline POST märge https://docs.camunda.io/docs/apis-tools/zeebe- joonisel) api-rest/specifications/assign-a-user-task/ Võimaldab mudelis „User task“ tüüpi töid Link REST liidesele: muuta (Kollane PATCH märge joonisel) https://docs.camunda.io/docs/apis-tools/zeebe- api-rest/specifications/update-a-user-task/ Võimaldab mudelis „User task“ tüüpi töid Link REST liidesele: kasutajate määramisel tühistada (Punane DEL https://docs.camunda.io/docs/apis-tools/zeebe- märge joonisel) api-rest/specifications/unassign-a-user-task/ 2.20. Eeltoodud operatsioonid ei ole aga piisavad proovitöö raames vajalike ülesannete teostamiseks, st liidese tööde käivitamiseks ja lõpetamiseks läbi vajaliku Jobs API. Selleks oli vaja järgmiseid operatsioone, millised on olemas aga ainult gRPC liidesel: Protsessimudelite paigaldamine Link gRPC liidesele: https://docs.camunda.io/docs/apis-tools/zeebe- api/gateway-service/#deployresource-rpc Protsessimudelite käivitamine Link gRPC liidesele: https://docs.camunda.io/docs/apis-tools/zeebe- api/gateway-service/#createprocessinstance-rpc Protsessimudelitesse sõnumite saatmine Link gRPC liidesele: https://docs.camunda.io/docs/apis-tools/zeebe- api/gateway-service/#publishmessage-rpc 5/8  Protsessimudelis defineeritud tööde Link gRPC liidesele: teostamatuks märkimine https://docs.camunda.io/docs/apis-tools/zeebe- api/gateway-service/#completejob-rpc Protsessimudelis defineeritud tööde vigaseks Link gRPC liidesele: märkimine https://docs.camunda.io/docs/apis-tools/zeebe- api/gateway-service/#throwerror-rpc 2.21. gRPC mittekasutamiseks oli vajalik seega eeldus, et kõiki operatsioone saab REST-iga teha, kuid ülaltoodud tabelid ja viited kinnitavad, et see pole käesoleval hetkel võimalik. 2.22. Kõigele eelnevale lisaks kui analüüsida hankija proovitöö soovituslikku paigaldusvaadet, siis nähtub ka sellest, et hankija on enda soovituslikus paigaldusvaates näinud ise ette gRPC kasutamise, sest lahtris „Äriprotsesside juhtimine“ asuvate Zeebe ja BPMN paigaldusteenuse vahel toimub suhtlemine üksnes gRPC abil. Samuti kasutab gRPC-d BPMN paigaldus läbi Desktop Modeleri töövahendi, milline on proovitöö punkti 2.4.5.2 kohaselt nõutud lahendus. Kõik see kogumis kinnitab samuti gRPC kuulumist tellija tehnoloogiate hulka. 2.23. Seda, et hankija enda soovituslik lahendus nõuab just gRPC protokolli, kinnitab vaidlustaja hinnangul ka hankija senine praktika. Vaidlustaja leidis upTIS koodibaasist teegi: https://gitlab.sotsiaalministeerium.ee/uptis/camunda-commons. See on väga sarnaste 6/8  tööpõhimõtete ja ülesannetega komponent nagu proovitöö raames loodud https://koodivaramu.eesti.ee/net-group/skais2/skais2-backend/skais2-backend-business-process- engine - kuulab sõnumivahendajat, korreleerib sõnumeid ja mh kasutab Zeebe'iga suhtluseks gRPC- d (link koodireale: https://gitlab.sotsiaalministeerium.ee/uptis/camunda-commons/- /blob/master/commons- camunda/src/main/java/ee/tehik/uptis/commons/camunda/service/ProcessServiceImpl.java#L131 ). Tegemist on nö "common" teegiga ehk koodiga, mida kasutavad mitmed upTIS teenused Zeebe'iga suhtlemiseks. 2.24. Üks selline teenus, mis kasutab eelmises lõigus viidatud upTIS teeki on Integrity (link: https://gitlab.sotsiaalministeerium.ee/uptis/fhir/integrity). Integrity teenuse README-s on kirjas, et .bpmn failide paigaldamiseks Zeebe'isse on kasutusel Camunda Modeler, ehk proovitöö 2.4.5.2 kohaselt nõutud lahendus. Ehk Camunda Modeler kasutab protsessimudelite paigaldamiseks gRPC- d.3 2.25. Eelnevast jääb vaidlustaja ka antud küsimuses enda vaidlustuses esitatud seisukoha juurde, et hankija on ebaõigesti rakendanud enda nõudeid ning hinnanud ka vaidlustaja README failis esitatud põhjendusi ebaõigesti, mille tõttu on vaidlustajale määratud vähem hindepunkte kui hindamismetoodika ette nägi. 2.26. Vaidlustaja on tutvunud ka kolmanda isiku I seisukohaga. Vaidlustaja hinnangul on vaidlustaja juba ülaltoodud vastustes esitanud piisavad vastuväited ka kolmanda isiku I seisukohaga seonduvalt ning ei asu enda seisukohti uuesti üle käima. Muus osas (s.h erinevate jooniste esitamine) on vaidlustaja hinnangul kolmanda isiku seisukoht asjakohatu ega ole vaidlusalune küsimus, mistõttu palub vaidlustaja jätta selliseid seisukohad tähelepanuta. 2.27. Õiged ei ole kolmanda isiku püüded rebida poolte vahelise suhtluse kontekstis välja suvalisi sõnu, esitleda enda seisukohas „kohustuslikke“ sisuküsimusi põhjenduste kirjutamisel, kuigi selliseid küsimusi hankija ei olnud ise riigihanke dokumentides kehtestanud või luua vaidluse keskmesse meelestatust „miks põhjendas, kui polnud vaja“. See, kuidas iga pakkuja enda pakkumuse esitab on iga pakkuja sisemine otsustus, s.j oli pakkujatel õigus esitada selgitusi endale soovitud hulgas ka siis, kui need ei olnud pakkuja hinnangul vajalikud. Seega vastavate etteheidete tegemine kolmanda isiku I poolt ei ole kohane. 2.28. Põhjendamatuks peab vaidlustaja ka kolmanda isiku I taotlust jätta vaidlustaja kolmas taotlus rahuldamata põhjenduste puudumise tõttu. Antud taotlus on seotud otsuse järgnevuse põhimõttega, milline ei vaja kehtiva praktika kohaselt sisulisi põhjendusi. 2.29. Kokkvõtlikult jääb vaidlustaja enda vaidlustuses esitatud taotluste juurde ja palub vaidlustuse täies ulatuses rahuldada. 3. MENETLUSKULUDE TAOTLUS 3.1. RHS § 199 lg 1 kohaselt lepingulise esindaja kulude väljamõistmiseks tuleb vaidlustuskomisjonile kirjalikus menetluses hiljemalt RHS § 196 lg 3 sätestatud täiendavate selgituste ja dokumentide esitamise tähtpäevaks esitada taotlus koos kulude nimekirjaga, milles on detailselt näidatud kulude koosseis. 3 Link Camunda Modeleri koodireale mis kasutab Zeebe Node teegi "deployResource" meetodit: https://github.com/camunda/camunda-modeler/blob/develop/app/lib/zeebe-api/zeebe-api.js#L192 Link Zeebe Node teegi koodireale, mis näitab, et "deployResource" kasutab gRPC-d https://github.com/camunda/camunda-8-js-sdk/blob/main/src/zeebe/zb/ZeebeGrpcClient.ts#L698 Link Zeebe Node teegi koodireale, mis kirjeldab gRPC "DeployResource" RPC: https://github.com/camunda/camunda-8-js-sdk/blob/main/src/proto/zeebe.proto#L792 Lisaks link Zeebe Node teegi REST kliendile, mis ei ole võimeline protsessimudelit paigaldama, vaid ainult "user task" ja "cluster" operatsioone läbi viima – just nagu ka Zeebe serveri REST liides ise https://github.com/camunda/camunda-8-js-sdk/blob/main/src/zeebe/zb/ZeebeRESTClient.ts 7/8  3.2. Käesolevaga esitab vaidlustaja vaidlustuskomisjonile menetluskulude nimekirja, paludes vaidlustuskomisjonil RHS §-des 198 ja 199 alusel välja mõista riigihanke nr 280265 vaidlustamisel tekkinud menetluskulud. 3.3. Vaidlustaja on vaidlustusmenetluses kandnud menetluskulusid järgnevalt: 1) riigilõiv 1280 eurot (vt vaidlustuse lisa); 2) lepingulise esindaja kulud summas 2356,90 eurot (ilma käibemaksuta). Kuupäev Töötaja Kommentaarid Hind Kestvus Summa 05.09.2024 Keidi Kõiv Menetlusdokumendi koostamine (kliendi 185,00 6,21 1148,85 esitatud materjalidega tutvumine, suhtlus kliendiga, vaidlustuse koostamine) 16.09.2024 Keidi Kõiv menetlusdokumendi koostamine (hankija ja 185,00 1,00 185,00 kolmandate isikute seisukohtadega tutvumine, analüüs) 17.09.2024 Keidi Kõiv menetlusdokumendi koostamine (vastuse 185,00 3,42 632,70 koostamine hankija ja kolmanda isiku seisukohtadele) 18.09.2024 Keidi Kõiv menetlusdokumendi koostamine (vastuse 185,00 2,11 390,35 koostamine hankija ja kolmanda isiku seisukohtadele) 10,63 2356,90 Koos KM- 2875,42 ga 3.4. Seega on vaidlustaja vaidlustusmenetluse kulud kokku 3636,90 eurot, mille palub vaidlustaja välja mõista hankijalt. Kõik kulutused on olnud põhjendatud ja mõistlikud. Vaidlustaja lepinguline esindaja kinnitab, et kõik lepingulise esindaja kulude nimekirjast nähtuvad kulud on kantud seoses vaidlustusmenetlusega. 3.5. Lähtudes eeltoodust palub vaidlustaja mõista Tervise ja Heaolu Infosüsteemide Keskuselt (TEHIK) Net Group OÜ kasuks välja vaidlustusmenetluse kulud kokku summas 3636,90 eurot. Lugupidamisega /digitaalselt allkirjastatud/ Keidi Kõiv vandeadvokaat Net Group OÜ lepinguline esindaja 8/8