Vastus pöördumisele

Raamlepingu nr 1.8-2/7828 lisa I Asjaolud 1. Sotsiaalministeerium, registrikood 70001952, aadress Gonsiori 29, 15027 Tallinn, keda esindas põhimääruse alusel kantsler Marika Priske (raamlepingus tellija) ja Eesti E-tervise Sihtasutus registrikood 90009016, aadress Uus Tatari 25/Veerenni 13, 10134 Tallinn, keda esindas põhikirja alusel juhatuse liige Margus Auväärt (raamlepingus tellija) ning Casadeva OÜ (endise ärinimega OÜ Affecto Estonia), registrikood 11124544, aadress Toompuiestee 35, 10133 Tallinn, keda põhikirja alusel esindas juhatuse liige Andrus Altrov (raamlepingus töövõtja) sõlmisid 17.02.2017 riigihanke „Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine“ (riigihanke registreerimisnumber e- Riigihangete registris: 178741) hankeosas I esitatud pakkumuse alusel raamlepingu nr 1.8-2/7828 (edaspidi Leping). 2. Sotsiaalministeerium, keda esindas põhimääruse alusel kantsler Marika Priske andis 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga üle Sotsiaalministeeriumi valitsemisel oleva riigivara lepingu ja sellest tulenevad õigused ja kohustused „Raamleping Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuste teostamiseks“ nr 1.8-2/7828, mis sõlmiti 17.02.2017 Casadeva OÜ-ga ja Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25/Veerenni 13, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold, võttis nimetatud Lepingu 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga vastu. 3. Sotsiaalministeerium tema haldusalas tegutseva Tervise ja Heaolu Infosüsteemide Keskuse kaudu, keda esindas põhimääruse alusel kantsler Marika Priske ja Eesti E- tervise Sihtasutus, keda esindas põhikirja alusel juhatuse liige Margus Auväärt vahel 29.11.2016 sõlmitud ettevõtte üleandmise lepinguga nr 1.8-2/7755 kohustus Eesti E-tervise Sihtasutus üle andma ja Tervise ja Heaolu Infosüsteemide Keskus vastu võtma seisuga 01.01.2017 tervise infosüsteemi haldamise ja volitatud töötlejaks olemisega seotud Eesti E-tervise Sihtasutuse õigused ja kohustused, sh täitmisel olevad lepingud ning nimetatuist tulenevad õigused ja kohustused. 4. Äriregistri andmetel on Casadeva OÜ uueks nimeks Industry62 OÜ. II Ilmselge ebatäpsuse parandamine Lepingus 5. Eeltoodust tulenevalt Tervise ja Heaolu Infosüsteemide Keskus, keda esindab põhimääruse alusel direktor Katrin Reinhold (raamlepingus tellija) ja Industry62 OÜ, keda põhikirja alusel esindab juhatuse liige Andrus Altrov (raamlepingus töövõtja) sõlmivad käesoleva Lepingu muutmise lisa ilmselge ebatäpsuse parandamiseks järgmiselt.  6. Käesolevaks ajaks on selgunud, et 17.02.2017 poolte vahelt sõlmitud Lepingus esineb ilmselge ebatäpsus Lepingu summa fikseerimisel. E-Riigihangete registris välja kuulutatud riigihanke tingimuste alusel, milliseid silmas pidades on Industry62 OÜ (endise nimega Casadeva OÜ) esitanud pakkumuse, kohustusid pooled sõlmima Lepingu eeldatava maksumusega 600 000 eurot. Poolte poolt allkirjastatud Lepingu punktis 10.1 on Lepingu orienteeruvaks mahuks märgitud ekslikult 400 000 eurot. 7. Käesoleva Lepingu lisaga muudavad pooled Lepingut tagamaks kooskõla e- Riigihangete registris välja kuulutatud riigihanke tingimustega järgnevalt: 7.1 tunnistada kehtetuks Lepingu punkt 10.1 ning 7.2 kehtestada Lepingu punkt 10.1 järgnevas sõnastuses: „10.1. Töö/tarkvara hind (arendustöö tunni maksumus 51,85.- eurot ilma käibemaksuta) on kindlaks määratud kogu raamlepingu kehtivuse ajaks. Tellija tellib töid vastavalt tehnilises kirjelduses märgitud tööde spetsifikatsioonile orienteeruvalt 600 000.- (ilma käibemaksuta) euro ulatuses lepingu perioodil. Tellija ei garanteeri nimetatud mahus Tööde tellimist.“ Poolte allkirjad: Tellija: Töövõtja: (Allkirjastatud digitaalselt) (Allkirjastatud digitaalselt) Katrin Reinhold Andrus Altrov Tervise ja Heaolu Infosüsteemide Keskus Industry62 OÜ registrikood 70009770 registrikood 11124544 Uus-Tatari 25/Veerenni 13 Toompuiestee 35 Tallinn Tallinn  Pakkumuse maksumuse vorm Pakkumus 117889, pakkuja: OÜ Quretec (11043739) Nr Nimetus Kirjeldus Kogus Ühi Ühiku hind Maksumus KM-ta KM Maksumus KM- Märkused Ei k % ga summeeru kogu- maksumu- sele 1 Arendusteenuse hind Ühe töötunni 1 tund 40,00 40,00 20 48,00 hind Maksumus kokku KM-ta: 40,00 Maksumus kokku KM-ga: 48,00 Kriteerium Numbri hindamine Väärtus Hanke osa  Tervise ja Heaolu Infosüsteemide Keskus Avaldus Sotsiaalministeerium ja Eesti E-tervise SA viisid läbi ühishanke „Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine“ (viitenumber eRHR-s 178741). Käesolevaga soovin pikendada OÜ Quretec riigihanke 178741 pakkumuse jõusoleku tähtaega RHS § 112 lg 1 alusel. Pakkumuse uueks jõusoleku tähtajaks palun lugeda 400 päeva alates pakkumuse esitamisest. Olen nõus raamlepingu sõlmimisega tagasiulatuvalt, eesmärgiga korrigeerida leping vastavaks väljakuulutatud hanke tingimustega. Allkirjastatud digitaalselt Lugupidamisega, Margus Jäger OÜ Quretec juhatuse liige OÜ Quretec Ülikooli 6a Tartu 51003 reg. nr. 11043739 www.quretec.com [email protected]  Vorm 8 – Ühispakkujate volikiri Hankija nimi: Sotsiaalministeerium/Eesti E-tervise Sihtasutus Riigihanke nimetus ja registreerimisnumber: Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine (Riigihanke registreerimisnumber: 178741) Käesolevaga volitame OÜ Quretec ja OÜ Tarkvara Tehnoloogia Arenduskeskus (ühispakkujate nimed) Kristjan Eljand, OÜ Tarkvara Tehnoloogia Arenduskeskus juhatuse liige (volitajate nimed ja ametikohad) isikus Margus Jägerit, OÜ Quretec juhatuse liiget (volitatava nimi, ametikoht) olema käesoleva ühispakkumuse esitanud pakkujate ametlik esindaja hankemenetlusega ja hankelepingu sõlmimisega seotud toimingute tegemisel. Käesolevaga kinnitame, et vastutame ühispakkujatena hankelepingu täitmise eest solidaarselt. Volitatava allkirja näidis: Volikiri on ilma edasivolitamise õiguseta.  Tehnilise kirjelduse lisa nr 2. Nõuded arendustele Käesolev dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded uutele infosüsteemidele ning nende dokumentatsioonile. Käesolevat dokumenti tuleb vaadata kui arenduste kvaliteedi- ja mittefunktsionaalsete nõuete põhidokumenti. Põhidokumendi ja viidatud dokumentide erisuste puhul tuleb lähtuda põhidokumendis kirjeldatust. Põhidokumendis viidatud Sotsiaalministeeriumi poolt koostatud dokumentide ja kolmandate osapoolte poolt koostatud dokumentide erisuste puhul tuleb lähtuda Sotsiaalministeeriumi poolt loodud dokumentides kirjeldatust. Kui mõnda nõuet ei ole võimalik või otstarbekas täita, tuleb selle mittetäitmise fakt ja põhjendus välja tuua pakkumuse esitamisel. Nõudeid tuleb järgida ka olemasolevate infosüsteemide versiooniuuendustel nii palju kui versiooniuuenduse käigus võimalik. Nõude Nõude Nõude sisu Seletused Koostamise liik nr. eest vastutaja Vastavus üldistele standarditele 1.1 Lahendus peab olema https://www.mkm.ee/sites/defa Arendaja kooskõlas riigi IT koosvõime ult/files/riigi_it_koosvoime_raa raamistiku nõuetega. mistik.pdf 1.2 Lahenduse X-tee teenused https://www.ria.ee/ee/xtee- Arendaja peavad vastama RIA nõuetele. juhendid.html 1.3 Lahendus peab vastama Arendaja tervise infosüsteemi IT- profiilile. 1.4 Rakendus peab olema Tervise infosüsteemi ISKE Arendaja kirjutatud arvestades selle turvaklass on K2T3S2. rakenduse poolt https://www.ria.ee/ee/iske- töödeldavatele andmetele kkk.html määratud ISKE turvaklassi  nõudeid. 1.5 Lahendus peab vastama https://www.mkm.ee/sites/defa Arendaja veebide koosvõime ult/files/veebide_raamistik.pdf raamistikule. 1.6 Veebirakenduse kasutajaliides http://www.w3.org/TR/WCAG2 Arendaja peab vastama vähemalt 0/ WCAG 2.0 tasemele AA. 1.7 Veebipõhine kasutajaliides Valideerimiseks kasutatakse Arendaja peab ühilduma täielikult vastavaid standarditega vähemalt HTML validaatoreid: http://validator.w 4.01 ja CSS 2.1, eelistatult 3.org/ Kui on tegu HTML 5 ja CSS 3 olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni. 1.8 ID-kaardiga allkirjastamisel on Arendaja loodud lahenduse Arendaja eelistatud veebipõhine digidoc- dokumentatsioonis (nt teenuste kasutamine. detailanalüüs vms) peab olema välja toodud digidoc- teekide versioonid ja kasutuskohad 1.9 Veebirakendus peab Kui pole arenduse eraldi Arendaja probleemideta läbima OWASP kokku lepitud teisiti, siis on ASVS baasil põhineva testi OWASP ASVS 3.0 tasemeks 2 (https://www.owasp.org/index. php/Category: OWASP_Application_Security _Verification_Standard_Projec t). Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile.Tellija poolset turvatestimist teostab kolmas sõltumatu pool.Selline esmane kolmanda poole turvatestimine tellitakse tellija  finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui tellija vastava nõudmise esitab. 1.10 Krüptoalgoritmide ja Arendaja loodud lahenduse Arendaja räsifunktsioonide kasutamisel dokumentatsioonis (nt tuleb järgida uusimat RIA detailanalüüs vms) tuleb välja kodulehel avaldatud tuua kasutatavad krüpto- ja krüptograafiliste algoritmide räsialgoritmid, nende kasutusvaldkondade ja võtmepikkused, elutsükli uuringut, st kasutuskohad, sh SSL lahendustes ei tohi kasutada sertifikaatide kasutuskohad. uuringus väljatoodud Värskeima uuringu leiab ebaturvalisi algoritme ja aadressilthttps://www.ria.ee/is võtmepikkuseid ke-dokumendid/ 1.11 Andmete edastus peab Arendaja välisvõrgu liikluses olema kaitstud kasutades turvalisi ja üldteada andmeedastusprotokolle 1.12 Infosüsteem peab kasutama Arendaja serveri kellaaega ja ajatsooni 1.13 Süsteemi Arendaja edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. Nõuded rakenduse arhitektuurile 2.1 Rakenduse, andmebaasi ja Arendaja loodud lahenduse Arendaja kolmanda osapoole dokumentatsioonis (nt komponendid peavad olema detailanalüüs vms) peab sellised, mille eluea lõpp olema välja toodud (EOL) pole teadaolevalt kasutatavate komponentide  vähem kui 2 aasta pärast. nimetused ja versioonid. Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui uus versioon on välja lastud. 2.2 Tulevase ja olemasolevate Süsteemi jõudlus peab Arendaja infosüsteemide platvormid vastama kokkulepitud (rakendusserver, andmebaas, topoloogial eelanalüüsi ja kolmanda osapoole lähteülesande käigus välja komponendid) ja topoloogia toodud jõudlusnäitajatele. peab olema enne reaalse arenduse algust Infrastruktuuri juhiga kooskõlastatud. 2.3 Rakendusserver peab - Arendaja võimaldama töötamist andmebaasiserverist eraldi serveril. 2.4 Rakendusserver peab olema - Arendaja vajadusel klasterdatav aktiivklastris (kasutajasessioon ei tohi olla klastri node põhine). Sessiooniinfot tuleb hoida vähemalt andmebaasis ning neid ei tohi replikeerida rakendusserverite vahel. 2.5 Rakendust peab saama ilma Lahendus ei tohi olla sisse Arendaja ümberprogrammeerimata kompileeritud absoluutseid liigutada erinevate domeenide URI-sid ja domeeni saitide vahel 2.6 Rakenduse liidesed peavad Väliste liidestatud süsteemide Arendaja olema tõrkekindlad tõrke korral ei tohi süsteem kolmandate osapoolte hanguda, vaid väljastama süsteemide vigade suhtes mõistliku (võimalikult lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid. 2.7 Rakenduse Rakendus peab neid sealt ka Arendaja konfiguratsiooniparameetrid kasutama (mitte kopeerima tuleb ühte kohta kokku tuua parameetreid käivitamisel nii, et nende muutmisel ei kolmandatesse kohtadesse), peaks rakendust uuesti kokku logimise seaded võivad olla kompileerima (nt ühte rakenduse tekstipõhisesse konfiguratsioonifailist eraldi konfiguratsioonifaili, ühes lisakonfiguratsioonifailis andmebaasi tabelisse). (näit Log4net). Samuti on väga soovitatav eraldi konfiguratsioonifailis hoida arendaja ja administraatori vastutusala parameetrid. Infosüsteem peab olema seadistatav konfiguratsiooniparameetrite(d e) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi. 2.8 Rakenduse kompileerimine, Maksimaalselt 30 sek. Kui Arendaja saidi taaskäivitus, rakendus vajab indekseeritud konfiguratsiooni muutmine sisu ja see pole kättesaadav, vms peaks toimuma mõistliku siis peab rakendus väljastama aja jooksul. selle kohta selge teate 2.9 Rakendus peab kasutama 64- Suund on 64-bitiste Arendaja bitist arvutiarhitektuuri kui ei rakenduste op süsteemide ole kokku lepitud teisiti. kasutamise poole. 2.10 Kui tellijaga kokku lepitud, et Suund on 64-bitiste Arendaja rakendus kasutab 32-bitist rakenduste op süsteemide arvutiarhitektuuri, peab ta kasutamise poole. olema võimeline töötama (testitud) ka 64-bitisel opsüsteemil. 2.11 Kõik andmed, andmebaasid, - Arendaja SQL skriptid ja rakendus  peavad kasutama UTF-8 kodeeringut. Alternatiivina on kokkuleppel tellijaga lubatud ka UTF-16. 2.12 Failisüsteemi salvestamisel ei Failid peab katalogiseerima Arendaja tohi ühte kausta tekkida üle kokkulepitud tunnuste alusel 10000 faili. (nt aasta, kuu, kuupäev). 2.13 Rakenduse loomisel tuleb Eelistuse eiramine tuleb Arendaja eelistada objektorienteeritud kooskõlastada projektijuhiga mudelit enne arendamise alustamist 2.14 Ühest andmetabelist teise - Arendaja viitamisel tuleb kasutada väliseid võtmeid (Foreign key). 2.15 Kõik välised võtmed (Foreign Andmebaasis peab kasutama Arendaja Key) peavad olema indekseid või muid meetmeid, indekseeritud. et nõuded rakenduse jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – vastavalt planeeritud kasutusajale). 2.16 Tuleb kasutada SQL päringute väljakutsumisel Arendaja päringumuutujaid (Parameter väljastpoolt andmebaasi, peab Binding). kasutama päringumuutujaid, et vältida SQL vahemälu fragmentseerumist (When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation) 2.17 Kõigis andmebaasi tabelites Kasutada vastava Arendaja peab olema defineeritud üks andmebaasisüsteemi primaarvõti. Andmebaasi nimetamise parimaid objektide nimetused peavad praktikaid. olema sisulised ja andma aimu nende otstarbest. 2.18 Rakenduse tööks vajalikud Need õigused, mis on Arendaja  andmebaasi objektid ja vajalikud ainult rakenduse skeemid luuakse andmebaasis baasi loomiseks, on eraldi rakenduse kasutaja õigustes. välja toodud ja tuleb peale Objektide loomiseks vajalikud installi ära võtta. Ei kehti teiste õigused ja ressursid on andmebaasisüsteemide loetletud rakenduse korral, seal võib see tekitada dokumentatsioonis. mõttetut keerukust. 2.19 Failide hoidmise asukoht Failide hoidmine klassikalises Arendaja lepitakse igakord kokku. Kuid andmebaasis on kulukas ja failid ja failide indeks peavad seab kõrgendatud nõudmised olema replikeeritavad teise ja piirangud serveriruumi. andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht. 2.20 Peab olema minimiseeritud Halduri haldustoimingud Arendaja vajadus, et haldur teeb lepitakse tellijaga kokku haldustoiminguid otse baasis. detailanalüüsi käigus. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid. 2.21 Rakendus peab olema Näiteks logifailides. Arendaja võimeline kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne). 2.22 Andmebaas peab toetama nii Ei tohi kasutada teenuseid, Arendaja külm- kui ka kuumvaru mis välistavad andmebaasi (peegeldamist) peegeldamist (nt "failstream"). teise serviruumi. 2.23 Sorteerimisreeglistik peab Näiteks MS SQL puhul Arendaja olema Eesti tähestikule vastav. Estonian_CI_AS. Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud. 2.24 Kui infosüsteemid saadavad e- Saatja ja adressaadid, pealkiri Arendaja  kirju, peavad nad kasutama ja sisu ei tohi olla rakendusse välist e-mailiserverit. Kirja kodeeritud, vaid on saatmisel peab rakendus muudetavad veenduma, et e-mailiserver konfiguratsioonifaili kaudu. võttis meili vastu. E-kirjade Genereeritud kirjade puhul vormindamine peab järgima peab tagama kirjade interneti standardeid (RFC jälitatavuse (näiteks lisada X- 5322). päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info). 2.25 Konfiguratsiooniparameetrite Näiteks : X-tee Turvaserver, Arendaja nimed peavad olema sisulised. mitte XTTS või viitenumber, Kui see ei ole võimalik, siis mitte vk_seb jne peab kõrval olema seletus. 2.26 Infosüsteemides on Koostöövõime raamistik 2011. Arendaja eessüsteemid (front end) ja Punkt 3.1. Tagasüsteemide tagasüsteemid (back end) ülesanneteks on andmete arhitektuuriliselt selgelt haldamine ja võrguteenuste lahutatud. pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagavad eessüsteemid. Tagasüsteemi või süsteemide katkemine ei tohi peatada eessüsteemi tööd. Tagasüsteemi taastumisel peab eessüsteem olema suuteline oma tööd jatkama taaskäivitamata. 2.27 Konfiguratsioonifailid peavad Näiteks IIS: *.config , Arendaja olema vastavalt *.resources Apache: *.conf, rakendusserveri tüübile .htaccess. Arendaja peab vaikimisi kaitstud failid välja tooma konfifailide listi, kui neid on mitu. 2.28 Rakenduse failid, mida Näiteks: IIS: Bin,App_Code, Arendaja  kasutaja näha ei tohi, peavad App_Data, App_Browsers, olema vaikimisi kaitstud App_GlobalResources, kaustades. App_LocalResources, App_Themes, App_WebReferences 2.29 Konfiguratsiooniparameetrite Kõiki parameetreid tuleks Arendaja taaskasutus. Erinevaid sama konfiguratsioonis kirjeldada sisuga parameetreid ei tohi vaid korra, mitte nii, et igas konfiguratsioonis eksisteerida. lõigus kirjeldatakse samu asju uuesti. 2.30 Kõik rakenduse liidesed Rakendustes tohib kasutada Arendaja peavad olema võimelised vaid masinapõhiseid töötama kõrgkäidetavalt. teenuseid, mis lubavad kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav lahendus on selline, mida saab samaaegselt käitada erinevates masinates. 2.31 Klientrakendus ei tohi Tuleb kasutada Arendaja pöörduda otse andmebaasi rakendusservereid. poole. 2.32 Keskkonnapõhised muutujad Näiteks WSDL ei tohi Arendaja peavad olema sisaldada viiteid konfiguratsioonifailist arendusserveritele. seadistatavad. 2.33 Rakenduses peab olema Eelistama peaks IP- Arendaja võimalik piirata aadressipõhist blokeeringut. ebaõnnestunud logimisi Erandina tellijaga kokkuleppel ajaühiku kohta (mobiil-ID, ID- võib kasutada captchat või kaart, paroolid) ühelt IP- konto lukustamist. aadressilt. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist muuta. 2.34 Rakendus ei tohi kasutada .NET rakenduste puhul on Arendaja meetodeid, mis välistavad suund shared hostingu shared hostingu kasutamise. kasutamise suunas. 2.35 Rakenduse äriloogika tuleb Andmebaas ei tohi sisaldada Arendaja realiseerida äriloogikat, mis muudab andmebaasist eraldisõltumatu andmetabelites olevaid/sinna s rakenduskihis. kirjutatavaid andmeid, va trigerid, mis tekitavad logi. 2.36 Andmebaasis võib kasutada *Ei ole soovitav kasutada Arendaja vaid ISO/IEC 9075 mingit platvormispetsiifilist standardiga kaetud lahendust, mille üleviimine funktsionaalsusi. Lisaks ei tohi mõnele muule kasutada ka sama standardi andmebaasiplatvormile ei ole osas 13 kirjeldatud võimalik. funktsionaalsusi. *ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis. 2.37 Kui rakendus eeldab eraldi AAM on keskne Arendaja kasutajate, rollide ja õiguste autentimislahendus ehk SSO registri pidamist, siis peab rakendus kasutama Tellija autentimis- ja autoriseerimismoodulit AAM. 2.38 Uniform resource identifier Harilikult on piiriks 2000 Arendaja (URI) pikkus ei tohi ületada tähemärki, kuid iga IS puhul ühegi IS poolt toetatava tuleb seda eraldi järele uurida brauseri maksimaalset lubatud sõltuvalt IS komponentidest. väärtust. Asjakohased viited: RFC 3986 ja RFC 7239. 2.39 SOAP teenuseid pakkuva Näiteks: Alajaotis Arendaja rakenduse WSDL peab olema definitions/types/schema: üles ehitatud nii, et see toetaks * complexType defineerimisel teenuste versioneerimist. tuleb sellele lisada any element. 2.40 Rakendus peab olema SSL offload Arendaja võimeline töötama koormusjaoturitega varustatud taristul. 2.41 Sidusinfosüsteemide mitte Sidussüsteemi töö taastumisel Arendaja  kättesaadavus ei tohi segada peab rakendus olema rakenduse töötamist. suuteline oma tööd jätkama Sidusinfosüsteemidega taaskäivitamata. andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse. 2.42 Kui ajastatult käivitatav Arendaja taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud. 2.43 Ühe tarkvarakomponendi Näiteks kui rakenduse Arendaja raames ei tohi sama komponent pöördub parameetri seadistamine andmebaasi või veebiteenuse toimuda rohkem kui ühes poole, siis selle pöördumise kohas. parameetrid peavad olema muudetavad vaid ühes kohas. 2.44 Uue toote arenduse ja Arendaja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate Tehnoloogiate ja standardite valik tuleb kooskõlastada Tellija poolse arhitektiga 2.45 Rakenduse ühenduste (s.h. Implementeeritud peab olema Arendaja andmebaasi ja vähemalt maksimaalsete sidusinfosüsteemide ühenduste arvu piirang ja ühendused) realiseerimisel päringu aegumise aeg tuleb kasutada ühenduste (request timeout).Rakenduse puulimist (connection pooling). ühenduste katkemine ei tohi peatada rakenduse tööd. Ühenduste taastumisel peab rakendus olema suuteline oma tööd  jatkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. Turvalisuse tagamisega seotud nõuded 3.1 Sisemised rakendusliidese Erandina tellija kooskõlastusel Arendaja autentimised peab saama teha võib sellest loobuda ja Active directory põhiselt. kasutada vaid ID-kaardi ja mobiil-ID põhist autentimist. Isiku sertifikaatide kehtivust peab saama kontrollida vastu OCSP ja CRL-i (vastavalt vajadusele). 3.2 Kliendi ja serveri vahel peab - Arendaja autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades. 3.3 SSL veebiserver peab https://www.ssllabs.com/ssltes Arendaja kasutama turvalisi ja SSL/TLS t/ versioone ja šifrikomplekte 3.4 Rakendus tohib kasutada vaid - Arendaja sessiooni küpsiseid. Muude küpsiste kasutamine on keelatud. 3.5 Kui andmebaasis olevate St kõik andmemuudatused Arendaja andmete ISKE tervikluse peavad baasis säilima. turvaosaklass on 2 või Andmete muutmisel andmeid kõrgem, siis tuleb kõik klass 2 ei kustutata, vaid tehakse uus infot sisaldavad andmebaasi kirje uute andmetega. Vana kirjed/tabelid versioneerida. muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist informatsiooni: *viide kirjele, mille ta kehtetuks muutis (kui on) *kasutaja, kes kirje lõi *kirje loomise aeg *sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje  peab omama järgmist informatsiooni: *kasutaja, kes kirje kehtetuks tunnistas *kirje kehtetuks tunnistamise aeg. 3.6 Kui rakenduse poolt Testandmed peavad säilitama Arendaja töödeldavate andmete kõik toodangu andmete konfidentsiaalsuse omadused (pikkuse, tüübi) ja turvaosaklass on 2 või omavahelised suhted. kõrgem, peab rakendusega kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni. 3.7 Andmebaasis olevate Ei resource, dba, ANY ega Arendaja rakenduse kontod peavad muud sellist. Nõude täitmiseks omama ainult minimaalselt vajalikud vahendid (skriptid) rakenduse tööks vajalikke peavad kuuluma rakenduse õiguseid. juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse installijuhendis. 3.8 Rakendusse ja andmetele St rakendustes ega Arendaja tohib olla ligipääs vaid andmebaasides ei tohi olla dokumenteeritud ja tellimuses ligipääsemiseks teisi kirjeldatud teid mööda ning võimalusi. dokumenteeritud autentimisprotseduure kasutades. 3.9 Kõik paroolid ja salaküsimuste Räsimine peab kasutama Arendaja vastused peab rakendus turvalist räsifunktsiooni (nt salvestama vaid SHA2, SHA3, RIPEMD-160) räsitud+soolatud. Kui räsimise ja kindlasti ka soola (salt). asemel valitakse Sool peab olema krüpteerimine, siis tuleb andmebaasiüleselt unikaalne, kirjeldadakrüptovõtme piisavalt suure bitiarvuga ja turvalise hoidmise protseduur. (pseudo)random. Krüpteerimisel peab kasutama  turvalisi algoritme (nt AES256) ja CBC, CRT vms režiimis. Kindlasti ei tohi kasutada ECB režiimi. Paroolid ja salaküsimuste vastused tohivad olla krüpteerimata kujul vaid ajutiselt serveri muutmälus. Krüpteerimata kujul ei tohi paroole salvestada (ka ajutiselt) ühelegi kettale. Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema ära toodud kasutatavad räsi ja krüptoalgoritmid, võtmepikkused ja nende kasutuskohad (vt nõue p 1.10) 3.10 Rakendused, kuhu saavad ligi Kui on vajalik ka parooliga Arendaja välised kasutajad, peavad logimine, peavad välised võimaldama sisselogimist ID- kasutajad autentima ennast kaardi ja mobiil-ID-ga. spetsiaalse väliskasutajate Paroolipõhist autentimist ei jaoks mõeldud AD pihta. Kui tohi kasutada. parooliga autentimist tehakse alati samadelt üksikutelt IP- delt, siis tuleb lisaks paroolile kasutada ka IP-põhist ligipääsukontrolli. Rakendus ei tohi lubada kasutada nõrku paroole, peab võimaldama paroolide eelmääratud aegumist ja mitme valesisestuse (nt 5 korda) korral kontode lukustamist. Sertifitseerimiskeskuse dokument digisertifikaatide kasutamise kohta EV dokumentidel: https://sk.ee/upl oad/files/SK-CPR-ESTEID- ET-v5_0-20150101.pdf 3.11 Mobiil-ID autenimise korral Veebilehel kuvatav Arendaja tuleb lisaks kasutaja kontrollkood peab olema telefoninumbrile küsida ka selgelt nähtav, sh ka kasutaja isikukoodi. nutitelefonidel ilma ekraanipilti kerimata. 3.12 Rakendus ei tohi teostada X- Kasutajaarvutitest otse x-tee Arendaja tee päringut otse päringute tegemine on kasutajaarvutist. arvutivõrgu tasemel kinni. 3.13 Veebipõhised välise IIS puhul peab kasutama Arendaja veebilehega rakendused, mis näiteks URL scan, apache on keskmise või kõrgema puhul modsecurity või ISKE turbeastmega, peavad vastavat tööriista. Lubatud kasutama vahendeid päringud on kõik päringud, kaitsmaks rakendust mis ei ole detailanalüüsi lubamatute päringute eest. käigus vastavalt kasutusjuhtudele ette nähtud. Kasutama peab whitelisting põhimõtet, mitte blacklisting. 3.14 Kui rakenduse mõni ISKE Kasutaja peab saama soovi Arendaja turvaosaklass on 2 või korral veenduda, kas keegi kõrgem, peab rakendus pole tema nime all vahepeal sisenemisel näitama pärast sisse loginud. õnnestunud sisselogimist eelmise õnnestunud sisselogimise aega. Kui on toimunud ebaõnnestunud sisselogimise katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti. 3.15 Kõigil rakendustel peab olema Aeg peab olema muudetav Arendaja konfigureeritav koos teiste kasutajasessiooni aegumise konfiguratsiooniparameetriteg aeg. a. 3.16 Krüpteerimise ja/või räside Järgida tuleb uusimat RIA Arendaja arvutamise korral tuleb kodulehel avaldatud kasutada tugevaid algoritme. krüptograafiliste algoritmide kasutusvaldkondade ja  elutsükli uuringut. Lubatud on: AES-256, Blowfish-256, RSA- 2048, SHA-2, RIPEMD-160 või tugevamaid. Lahenduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. 3.17 Autenditud sessiooni tunnust Sessiooni ei tohi olla võimalik Arendaja ei tohi ainult lihtsa küpsisega üle võtta sessioonitunnuse lahendada. kopeerimisega ühest arvutist teise. 3.18 AD või AAM-i autentimise Näiteks: konto on lukus, Arendaja kasutamisel peab rakendus parool aegunud, konto kasutama ka AD või AAM-i aegunud, paroolipoliitika jne. kontoga kaasnevaid piiranguparameetreid. 3.19 Tagada tuleb rollide lahusus. Administraatoril, halduril ja Arendaja Halduritel ei tohi olla võimalik tavakasutajal on erinevad muuta ega näha rakenduse tööülesanded. Rollide/õiguste konfiguratsiooni. kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest. 3.20 ID-kaardiga autentimisel, peab Proxy tugi Arendaja rakendus suutma vastu võtta ID-kaardi sertifikaati ka päises. 3.21 Kui kasutajaid hallatakse ka Eesmärk vähendada AD ja Arendaja rakenduses ja autenditakse AAM-i koormust. AD või AAM-i vahendusel, tuleb sisselogimisel kõigepealt kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole. 3.22 Arendus peab olema Toodangukeskkonna Arendaja orienteeritud rakendus ei tohi sisaldada toodangukeskkonnas osiseid, mis toodangu toimimiseks. keskkonnas on ebavajalikud  või segavad (näiteks kasutuseta funktsionaalsus ja komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks arenduskeskkonnas jne). 3.23 Rakendus ei tohi lubada ühe Juhul kui lähteülesanne Arendaja kasutajaga mitut samaaegset spetsiaalselt ei ütle teisiti. sessiooni. 3.24 Kui rakenduse tervikluse Milline lahendus valitakse Arendaja turvaosaklass on T3, peavad tuleb kokku leppida tellijaga. tõestusväärtust omavad Täpsustuseks vt ISKE nõue andmed olema kas HT.34. Vt ka nõuet 3.28. ajatembeldatud, digiallkirjastatud või digitembeldatud. 3.25 Kui lahendus peaks kasutama Ajatempli kasutamise vajadus Arendaja ajatempli teenust, siis tuleks lepitakse eraldi kokku Tellija eelistada Guardtime IT juhiga ja infoturbejuhiga. lahendust. See sõltub Tellija keskse ajatempli kasutamise võimalustest. 3.26 Kui rakenduse tervikluse Täpsustuseks vt ISKE nõue Arendaja turvaosaklass on T3, peavad HT.10. Krüptoahela tõestusväärtust omavad kasutamise vajadus lepitakse andmed olema eraldi kokku Tellija krüptoaheldatud, et tagada et infrastrktuuri juhiga ja tõestusväärtusega andmeid ei infoturbejuhiga. See sõltub saaks märkamatult kustutada. Tellija keskse krüptoahela kasutamise võimalustest. 3.27 Kui rakenduses on S3 Täpsustuseks vt ISKE nõue Arendaja salastuse astmega andmeid, HT.37 . peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult. 3.28 Veebirakendus ei tohi jätta Kui paks klient kasutab ajutisi Arendaja sulgemisel kasutaja tööjaama faile, tuleb tagada nende  maha ajutisi faile. perioodiline kustutamine Paksu kliendi korral ei tohi tagamaks, et ei koormata rakendus kasutaja tööjaama liigselt kasutaja arvutit. Nõude jätta maha krüpteerimata kujul eesmärk on tagada, et ajutisi faile, mis sisaldavad või rakenduse sulgemisel ei jääks võivad sisaldada kasutaja arvutisse maha konfidentsiaalse või kõrget informatsiooni, mida sinna terviklust jääda ei tohiks, sh nõudvat informatsiooni. pääsuandmeid, isikuandmeid, andmekogu sisulisi andmeid jms 3.29 Rakendus ja selle Arendaja arendab Arendaja komponendid peavad arenduskeskkonnas ja annab võimaldama kasutada tarne üle tellijale keskkondade lahusust paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas. 3.30 Rakendus peab võimaldama Krüptograafiat kasutav Arendaja hõlpsalt välja vahetada rakenduskood ei tohi aegunud ja ebaturvalise nimeliselt välja kutsuda krüptoalgoritmi. krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada. 3.31 Rakenduse andmebaasi Andmebaasides kasutatavad Arendaja krüpteerimisega seotud krüpteerimisfunktsioonidest andmeväljad peavad olema tingitud lisaväljad peaksid  muudetava pikkusega. olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme. Logimine, debuggimine, testimine 4.1 Rakendusel peab olema Testlehe kättesaadavus Arendaja masinloetav XML-testleht. erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom builtrakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone reeta. Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei tööta). Rakenduse, andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb tellijaga kokku leppida eelanalüüsi käigus. Testleht peab oma konfiguratsiooni võtma rakenduse üldisest konfiguratsioonist (baasistring, välised ühendused). 4.2 Rakenduse kõik üleantavad Testitulemused tuleb Arendaja versioonid peavad enne edastada tellijale koos tellijale üle andmist olema rakenduse üleandmisega testitud 4.3 Rakendus peab logima Logima peab ka autentimise Arendaja kasutaja edukat ja ebaedukat ebaõnnestumise koos autentimist ja sessiooni põhjusega (vale parool,  lõpetamist, kasutaja IP ja aegunud konto jne). Logida autentimismeetodit (ID-kaart, tuleks IP-aadress, meetod ja mobiil-ID vms), eduka autendi kui võimalik kasutajatunnus puhul tuleks logida ka kasutaja (mobiil-ID puhul telefoni isikukood ja mobiil-ID puhul number, ID-kaardi puhul telefoninumber isikukood). Kui rakendus kasutab kasutajate autentimiseks AAM-i, siis leppida projektijuhiga eraldi kokku autentimise detailsus ehk mis kajastatakse AAM-is ja mis rakenduses. 4.4 Erinevate logifailide kirjeid Näiteks timestamp või mingi Arendaja peab olema võimalik seotud ID abil. komponentide logidega loogiliselt kokku viia. 4.5 Rakendus peab suutma logida Vajalik eelkõige Arendaja kõiki X-tee teenuste kaudu debuggimiseks ja toodangu liikuvaid andmeid. Peab olema keskkonna võimalus logimist sisse-välja probleemide lahendamiseks. lülitada. 4.6 Kui rakenduse ISKE Andmetöötlust peab olema Arendaja konfidentsiaalsus võimalik kokku viia konkreetse turvaosaklass on 2 või kasutajaga ning kõrgem, peab rakendus logima sessiooniinfoga. Isikuandmete kõiki konfidentsiaalsus kaitse seadus §25 lg2 klassiga 2 või kõrgemate p3:(Isikuandmete töötleja on andmete loomist, muutmist (sh kohustatud) ära hoidma kustutamist) ja vaatamist. isikuandmete omavolilist salvestamist, muutmist ja kustutamist ningtagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; 4.7 Kui rakenduse ISKE tervikluse Andmetöötlust peab olema Arendaja turvaosaklass on 2 või kõrgem võimalik kokku viia konkreetse peab rakendus logima kasutajaga ning kõiki tervikluse klassiga 2 sessiooniinfoga. Isikuandmete andmete loomist ja muutmist kaitse seadus §25 lg2 (sh kustutamist). p3:(Isikuandmete töötleja on kohustatud) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ningtagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele isikuandmetele andmetöötlussüsteemis juurdepääs saadi; 4.8 Kui rakenduse andmete Lahendus peab tagama, et Arendaja konfidentsiaalsuse administraatorid/haldurid ei turvaosaklass on 3, siis ka saa andmete vaatamise kõiki administraatorite ja logimist ise (ka tavakasutajate haldurite poolt tehtavaid logimist) deaktiveerida või andmete vaatamised (ka otse logisid kustutada/muuta. Võib baasis) tuleb logida. tellijaga kokku leppel nõudest loobuda kui andmed on krüpteeritud. 4.9 Kui rakenduse andmete Lahendus peab tagama, et Arendaja tervikluse turvaosaklass on 3, administraatorid/haldurid ei siis ka kõiki administraatorite saa andmete muutmise ja haldurite poolt tehtavaid logimist ise (ka tavakasutajate andmete muudatused (ka otse logimist) kinni keerata või baasis) tuleb logida. logisid kustutada/muuta. Tellijaga kokkuleppel võib nõudest loobuda, kui andmed on kaitstud digiallkirja, digitempli või välise osapoole ajatempliga. 4.10 Andmete Logid peavad asetsema Arendaja loomise/vaatamise/muutmise/k andmetest eraldi andmebaasi  ustutamise logid peavad failides-andmeruumides, et asuma andmebaasis ja neile neid oleks võimalik vajadusel on loodud vastav logide lihtsalt andmetest eraldi vaatamise liides rakenduse arhiveerida või anda nendele peakasutajale. ligipääsuks eraldi õiguseid. Kui rakendusel on eraldi liides administraatorile või peakasutajale, siis seal peab olema eraldi logidega tutvumise võimalus vastavate pääsuõiguste olemasolul. 4.11 Andmebaasi logidest Failisüsteemi logide eesmärk Arendaja saadetakse reaalajas koopia on koguda logid ühtesesse failisüsteemi logisse ja seal logihaldussüsteemi, neid logis peab kajastuma ka krüptoaheldada ja logimisfunktsionaalsuse aegtembeldada aktiveerimise ja deaktiveerimise info (aeg, kasutaja jms) 4.12 Rakendusega peab olema Jõudlustestide täpne kirjeldus Arendaja kaasas skript jõudlustestide tuleb kokku leppida tegemiseks. detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. 4.13 Rakendus peab logima kõiki Logi sisaldab minimaalselt vea Arendaja rakenduses tekkivaid tehnilisi tekkimise aega, veakoodi, vigu. veakirjeldust (stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST-parameetrid ja nende väärtusi. Logimise detailsusrežiimi (info, warning,  errog, debug) peab saama muuta. 4.14 Vea ja süsteemilogid peavad Kui logitakse mitmesse kohta, Arendaja olema vähemalt failisüsteemi siis vajadusel peab saama tekstifailis üldtuntud ühte või teise kohta logimist vormingus, lisaks võib ka välja lülitada. Logi peab olema andmebaasis hoida. lihtsalt masintöödeldav ja tuntud vormingus. Näiteks syslog, syslog-ng, XML, CSV. 4.15 Failisüsteemi logimise korral Ei tohi esinda olukorda, kus Arendaja peavad logid olema ka ühte kausta tekib rohkem kui katalogiseeritud (näiteks 1000 faili. kuupäeva või liigi järgi) ja üldtunnustatud faililaiendiga (näiteks .log, .txt, .xml), logi peab olema roteeruv, et ei tekiks liiga suuri faile (nt 5MB). Logifailide seadistamisel peab olema failinime/kaustatee nimedes võimalik kasutada keskkonnamuutujaid (kuupäev, masinanimi jne). Nõuded rakenduse lähtekoodile 5.1 Lähtekoodi kommentaarid NB! Nõuet ei arvestata Arendaja peavad kõigis lahenduse arendustarkvara poolt kihtides (rakenduse enda automaatselt genereeritavate kood, andmebaas, jne) olema koodilõikude puhul – neid ei kirjutatud eelistatult inglise ole vaja tõlkida. Samuti ei keeles, vähem eelistatud rakendata nõuet kolmandate alternatiivina eesti keeles. osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad lahtise koodiga koodilõigud jms. Kui on tegu olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt. 5.2 Lähtekoodi kommentaarid Rakenduse kood peab olema Arendaja  peavad olema selged, piisavalt hästi arusaadavad ja sisuliselt kommenteeritud, et erialast kirjeldama vastavat koodi, haridust omav mille juures nad on ning tarkvaraarendaja on võimeline moodustama vähemalt 20% süsteemile jätkuarendusi koodi mahust. teostama. 5.3 Muutujate, tüüpide ja Parim praktika Arendaja funktsioonide nimed peavad olema sisulised ja andma aimu nende otstarbest. 5.4 Koodis kasutatavad Parim praktika. Nt Arendaja konstandid ja lühendid tuleb Identifikaator --> ID kirjutada suurte tähtedega. 5.5 Koodis kasutatavaid konstante - Arendaja ei tohi selle kasutamise kohta väärtusena hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende. 5.6 Koodis defineeritud N:Isik; Menetlus; jne. Arendaja andmetüübid peavad olema Andmebaaside nimetava käände ainsuses. struktuurikirjeldustes/andmem Kõik andmemassiivid tuleb udelis ei tohi kasutada nimetada nimetava mitmuses täpitähti. (st igasugu collectionid, arrayd, jms). 5.7 Andmetabelites sisalduvad Kasutada tuleb konkreetse Arendaja võõrvõtmed peavad nime järgi andmebaasisüsteemi seostuma tabeli ja väljaga nimetamise parimaid millele need viitavad. praktikaid. Nt kui on tegu tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_ID 5.8 Andmebaasi väljade pikkused Selle asemel, et eraldada Arendaja tuleb kirjeldada sümbolites, väljale x baiti, tuleb eraldada x mitte baitides. tähemärki. (Instead of allocating x bytes of storage  for the field, x chars of storage must be allocated). 5.9 Kui kokku pole lepitud teisiti, http://java.sun.com/docs/code Arendaja siis JAVA rakenduse kood conv/ Valideerimiseks peab olema kirjutatud kasutatakse 'checkstyle' vastavalt "Oracle Java Code vaikimisi konfiguratsiooni convention" dokumendile. 5.10 Kui kokku pole lepitud teisiti, http://www.python.org/dev/pep Arendaja siis Python rakenduse kood s/pep-0008/ peab olema kirjutatud vastavalt "Style Guide for Python Code " dokumendile 5.11 Kui kokku pole lepitud teisiti, http://msdn.microsoft.com/en- Arendaja siis .NET rakenduse kood us/library/ms229042.aspx Vali peab olema kirjutatud deerimiseks kasutatakse vastavalt "NET Framework 'StyleCop' vaikimisi Developer's Guide - Design konfiguratsiooni Guidelines for Developing Class Libraries". 5.12 JAVA koodi valideerimiseks 1. Arendaja kasutatakse: PMD(http://pmd.sourceforge.n et) 2. DocCheck(http://java.sun.com /j2se/javadoc/doccheck/) 3. Findbugs (http://findbugs.sourceforge.ne t/). Findbugs reeglid asuvad failis “Java koodi kvaliteedi nõuded.zip” 5.13 .NET koodi valideerimiseks FxCop(http://msdn.microsoft.c Arendaja kasutatakse: om/en- us/library/bb429476.aspx) 5.14 Pythoni koodi valideerimiseks Pychecker(http://pychecker.so Arendaja kasutatakse: urceforge.net/) 5.15 Kasutuses mitteolev kood - Arendaja tuleb rakenduse lähtekoodist  kõrvaldada. 5.16 Arendamisel kasutatakse DRY http://en.wikipedia.org/wiki/Do Arendaja ja SOLID printsiipe n%27t_repeat_yourself http://en.wikipedia.org/wiki/SO LID_(object-oriented_design) 5.17 Üleantavas koodis ei tohi olla Kehtib ka siis, kui need on Arendaja paroole, mida on kasutatud välja kommenteeritud. Kõik arenduse käigus sellised paroolid tuleb asendada fraasiga “<password>“. 5.18 Rakenduste lähtekoodi Eelpoolmainitu haldamine Arendaja tasemel ei tohi olla ühtegi toimub failis või andmebaasis. sisse kodeeritud parameetrit, väljade nimetust, veateadet. Andmekvaliteet ja standardid 6.1 Aadressiandmete Liidestatakse maaameti X-tee Arendaja sisestamisel, kuvamisel ja teenusega. hoidmisel tuleb lähtuda Vabariigi Valitsuse 20. detsembri 2007. a määrusest nr 251 "Aadressiandmete süsteem". 6.2 Rakendus peab võimalikult Välja arvatud logimisvormi Arendaja palju informatsiooni eeltäitma lahtrid autentimisel automaatselt (kirje sisestamise kuupäev, kasutaja nimi jne). 6.3 Tegevusalade andmete - Arendaja sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse 10. Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. 6.4 Tervishoiuteenuste osutajate Liidestatakse Terviseameti x- Arendaja  andmete kasutamisel peab tee teenusega kontrollima nende andmeid, sh tegevuslubade kehtivust Terviseameti Tegeuslubade registrist 6.5 Tervishoiutöötajate andmete Liidestatakse Terviseameti x- Arendaja kasutamisel peab kontrollima tee teenusega nende andmeid Terviseameti tervishoiutöötajate registrist 6.6 Meditsiiniandmete www.hl7.org Vajadusel on Arendaja vahetamiseks tuleb kasutada lubatud ka teiste standardite meditsiiniandmete kasutamine, kuid see tuleb andmevahetuse standardit tellijaga eraldi kokku leppida HL7 6.7 Tervise valdkonna Võimalusel tuleb kasutada Arendaja/Tellija klassifikaatorid peavad olema olemasolevaid OID-e ja kooskõlas Tellija OID-ide ja klassifikaatoreid, mida publitseerimiskeskusega vajadusel täiendatakse või luuakse uued ning publitseeritakse samuti publitseerimiskeskuses http:// pub.e-tervis.ee Kasutajaliides 7.1 Kasutajaliidese kõik - Arendaja disainiotsused peavad olema kooskõlastatud tellijaga enne nende realiseerimist 7.2 Veebipõhine kasutajaliides Minimaalselt Internet Explorer, Arendaja peab olema kasutatav Mozilla Firefox, Chrome ja enamlevinud Safari arenduse testimise veebibrauseritega, sh hetkel tootja poolt toetatud nutiseadmetel (Android, IOS, versioonid. Täpsemad nõuded Windows Phone) dokumendis "Front-end arendusreeglid" 7.3 Rakenduse värviskeem ja logo Kui tegemist on Arendaja kasutamine peab vastama struktuurfondide projektiga on Tellija ametlikule visuaalsele lisaks nõutud ka vastav SF  identiteedile (CVI) ja sümboolika. Tellija ametlikud disainijuhistele (UIG). CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida tellijalt. 7.4 Kasutajaliidese kõik osad ja Kui soovitakse juurde eraldi ka Arendaja teated peavad olema muid keeli, siis see on eestikeelsed. spetsifitseeritud hankedokumentides 7.5 Avalikuks kasutamiseks tehtav Toetatud peavad olema Arendaja rakendus peab olema vähemalt resolutsioonid: graafiliselt eskaleeruv ja 1920x1200, 1920x1080, mugavalt kasutatav kõigi 1680x1050, 1600x1200, enamlevinud arvutite 1440x900, 1360x768, monitoride resolutsioonidega. 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, 1024x768, 1024x600. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. 7.6 Sisemiseks Ühegi nimetatud resolutsiooni Arendaja kasutamiseks tehtav rakendus korral ei tohi tekkida peab olema graafiliselt horisontaalset kerimisriba. eskaleeruv ja mugavalt kasutatav järgmiste monitoride resolutsioonidega: 1024x768, 1280x1024, 1680x1050, 1920 x 1080, 1920x1200. 7.7 Hüpikaknaid (pop-up) ei tohi Silmas on peetud uusi Arendaja kasutada. veebilehtiseja aknaid avavaid hüpikaknaid 7.8 Kasutajaliideses toiminguni Kõik rakenduse Arendaja (põhi- ehk enamkasutatavad kasutajaliidesest tehtavad tegevused) navigeerimiseks toimingud tohivad üksteisest peab kehtima 3 kliki printsiip, olla maksimaalselt 3 hiirekliki väljalogimiseks 1 kliki printsiip. kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama.  Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas. 7.9 Kasutajaliides peab alati - Arendaja küsima kinnituse andmete kustutamise ja massmuutmiste kohta kui pole kokku lepitud teisiti. 7.10 Rakenduse kasutamisel Veateated peavad olema Arendaja tekkinud veale peab sellised, mis võimaldavad IT- kasutajaliides vastama abil võimalikult lihtsalt kasutajale eestikeelse tuvastada vea olemuse ja kasutajasõbraliku veateatega, asukoha. mis sisaldab soovituslikult ka vea koodi. 7.11 Kasutajaliides peab olema Uue keele lisamine peab Arendaja ilma rakenduse koodi olema teostatav muutmata tõlgitav teise konfiguratsiooni failist või keelde, v.a kui ei ole administreerimisliidesest. kokkulepitud teisiti. 7.12 Rakenduse tausta, menüüde - Arendaja ja teksti värvid peavad olema ilma rakenduse koodi muutmata vahetatavad. 7.13 Rakenduse kasutajaliides Ette teavitamise aeg peab Arendaja peab teavitama kasutajat ette olema konfigureeritav. sessioon aegumisest. 7.14 Kui vormile sisestatakse Kui vorm koosneb paljudest Arendaja mahukaid andmevälju peab väiksest andmeväljadest (nt kasutajaliides kokku lepitud taotlus), siis jagatakse vorm ajavahemike järel salvetama etappideks ning salvestatakse välja sisu, et sessiooni vastava etapi lõpus. aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. 7.15 Sisestusvormidel andmete - Arendaja  sisestamisel peab saama väljade vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga. 7.16 Interaktiivsete vormide puhul - Arendaja (näiteks faili üleslaadimine), ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). 7.17 Kui päring võtab aega kauem Ikoon peab muutuma Arendaja kui 3 sekundit, peab kasutaja liivakellaks ja/või kuvatakse saama visuaalse teate, et teade: päringut sooritatakse süsteem tegeleb päringu või muu tellijaga kokkulepitud läbiviimisega. indikaator. 7.18 Esilehel (sisselogimata) ja ka Näiteks võimalikud teavituses: Arendaja pärast kasutaja sisselogimist mingi süsteemi osa on vigane, peab olema lihtne võimalus tuli mingi uus funktsionaalsus, teavitada kasutajat vahetage oma parool, muudatustest või uuendage isikuandmeid jne. probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav. 7.19 Nutiseadmetele tuleb luua See vajadus Arendaja eraldi kohaldatud spetsifitseeritakse arenduse kasutajaliides. tellimisel. 7.20 Infosüsteem peab Arendaja funktsionaalse vea (näiteks kohustuslikkude väljade täitamata jätmisel) korral kasutajale kuvama kasutajasõbraliku veateate. Veateated peavad olema hallatavad. 7.21 Päringu vastusena kuvatud Arendaja tabeli veerge on võimalik  andmete/teksti tähestikulises järjekorras sorteerida. 7.22 Andmeväljade kohustuslikkus Arendaja peab olema infosüsteemi väljadel märgitud tärniga (*). 7.23 Rakenduse andmeväljade Arendaja mõisted peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel. 7.24 Kasutajaliides peab vastama https://wiki.sm.ee/display/DAO ka dokumendis "Front-end /Front-end+arendusreeglid arendusreeglid" kirjeldatud reeglitele Dokumentatsioon 8.1 Kogu rakenduse Erandiks võivad olla kolmanda Arendaja dokumentatsioon peab olema osapoole komponentide (mis kirjutatud eesti keeles. pole kirjutatud tellija jaoks) dokumentatsioon. Samuti võib erandiks olla välispooltega seotud projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni koostamist 8.2 Lahendus kirjeldatakse RIHA https://www.riigiteataja.ee/akt/ Arendaja / määruse nõuete kohaselt. 12933746?leiaKehtiv#para6 Projektijuht / Tellija RIHA haldur 8.3 Rakenduse dokumentatsioon Dokumentatsioon peab olema Arendaja peab sisaldama versioneeritud, paigaldusjuhiseid, muutmiskuupäevadega, autori varundatavate komponentide nimedega, korrektse kirjeldust, kasutajate keelekasutusega, selge kasutusjuhendeid, struktuuriga.  peakasutajate ja Dokumentatsiooni detailsus administraatorite peab olema piisav, et kasutusjuhendeid, sõltumatu kolmas tehnliste IT andmemudeleid, baasteadmistega isik suudaks arhidektuurilisi mudeleid, dokumendist vajalikke süsteemitehnilisi kirjeldusi, järeldusi teha (st dokument nõudeid riistavarale, peab olema arusaadav sellele krüptoalgoritme ja isikule, kuid näiteks võtmepikkuseid, SSL paigaldusjuhise järgi sertifikaatide kasutuskohti jms toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi). 8.4 Rakenduse Esialgne kirjete mahu hinnang Arendaja dokumentatsioon peab peab tulema lähteülesandest, sisaldama tabelite-andmete- ning täpsustuma eel ja logide mahu kasvu detailanalüüsi käigus. arvestuslikku hinnangut Mahuhinnang peab sisaldama rakenduse sihipärase ka logide säilitamise, kasutamise korral ettenähtud arhiveerimise tähtaegu. arvu kasutajate poolt. (MB/GB kuus/aastas). 8.5 Iga uue versiooniga peab alati Release notes peab Arendaja välja tooma versiooni kajastama kõiki muudatusi muudatuse kirjeldused eelmise ja uue versiooni (release notes). vahel. 8.6 Rakenduse dokumentatsioon https://wiki.sm.ee/pages/viewp Arendaja peab vastama ka dokumendis age.action?pageId=2556031 "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele Versioonihaldus 9.1 Kõik rakenduse testimiseks, Arendajale antakse selleks Arendaja koolituseks või õigused implementeerimiseks üle Tellija versioonihalduse antavad tarkvarapaketid repositooriumi, kus ta peab peavad olema versioneeritud. hoidma oma erinevaid Kasutama peab versioone. Versioonihalduse Tellija versioonihalduse repositooriumi juurdepääsutao  repositooriumi. tlus esitatakse Tellija kasutajatoele läbi projektijuhi 9.2 Arendaja peab veenduma, et - Arendaja teeb muudatusi aktuaalsesse koodi. Ehk paralleelse arendamise puhul võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist. 9.3 Paigalduspaketile koostatakse Räsialgoritmiks tuleb kasutada Arendaja kontrollkood (checksum), mis SHA256. Linuxi käsurealt pannakse eraldi .sum failina kontrollkoodi koostamiseks: $ tarnele kaasa. sha256sum filename [filename2] ... > kontrollkood.sum 9.4 Kõik rakenduste tellijale Ka tagant järgi peab olema Arendaja lepingujärgsete üleantavate 100% kindel, et üle anti õige versioonide lähtekoodid arendaja signeeritud, mitte peavad olema varustatud kolmanda osapoole poolt arendaja esindaja kompromiteeritud versioon. digiallkirjaga. Mahuka lähtekoodi asemel võib signeerida paigladuspaki kontrollkoodi. 9.5 Nii arendamisel kui ka Arendajale antakse selleks Arendaja hoolduslepingute korral õigused Tellija veahalduse kasutatakse Tellija veahalduse keskkonda. keskkonda. Juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi Paigalduspaketi kooste 10.1 Tarnitava lahenduse Näiteks võib lahenduse Arendaja koosseisus üle antava paigalduspaketi lähtekoodiga peavad kaasas koosteprotsess ette näha, et olema kirjeldused sellest käivitada tuleb rida shell- paigalduspaketi koosteks. käske või võivad lahenduse koosseisus olla valmis (ant, ..)  koosteskriptid või mis iganes muu moodus paigalduspaketi tekitamiseks. 10.2 Kooste kirjelduste alusel Näiteks: kompileeritavate Arendaja valmiv paigalduspakett tohib keelte puhul ei tohi sisaldada sisaldada ainult minimaalse lähtekoodi, kui see pole vajalik rakenduse käitamiseks rakenduse käitamiseks. vajamineva failikomplekti. 10.3 Kooste kirjelduste alusel Näiteks ei tohi tekitada Arendaja valmivat paigalduspaketti peab olukorda, kus rakenduse olema võimalik liigutada jooksutamiseks uues serveris erinevate masinate vahel. tuleb see tingimata just sealsamas kokku kompileerida. 10.4 Lähtekoodi kompileerimine Erandina võib kasutada Arendaja peab olema teostatav ka NuGet pakette väliste teekide võrguühenduse puudumise jaoks, kuid erand tuleb korral. kooskõlastada esmalt tellijaga projekti alguses 10.5 Andmebaasi paigalduse Administraator tahab Arendaja skriptid ei tohi olla veenduda skripti sisus. kompileeritud.  Sotsiaalministeerium ja Eesti e-Tervise SA Terviseinfosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine (Riigihanke registreerimisnumber: 178741) Teenuse tehniline kirjeldus II Tervise infosüsteemi portaalid ja moodulid Hankedokumendi lisa 4. 2016 1 Sisukord Sisukord ................................................................................................................................ 2 1. Sissejuhatus ................................................................................................................... 3 1.1 Dokumendi eesmärk ................................................................................................ 3 1.2 Dokumendi sihtrühm ................................................................................................ 3 1.3 Dokumendi sisu ....................................................................................................... 3 2. Taust ja kirjeldus ............................................................................................................ 3 2.1. Tellija tegutsemisvaldkond ....................................................................................... 3 3. Tervise infosüsteem ....................................................................................................... 3 3.1. TIS liidesed .............................................................................................................. 4 4. Hangitav teenus ....................................................................................................... 4 4.1. Hangitavate teenuste nimekiri: ................................................................................. 5 4.2. Teenuse sisu ........................................................................................................... 5 5. Arendusmeeskond ja –meetod ....................................................................................... 6 5.1. Arendusmeeskond ................................................................................................... 6 6. Mittefunktsionaalsed nõuded .......................................................................................... 8 7. Arendus -, Test-, Prelive- ja toodangukeskkonnad ......................................................... 9 2 1. Sissejuhatus 1.1 Dokumendi eesmärk Dokumendi eesmärk on anda ülevaade hangitavatest teenusest ja sätestada tingimused teenuse osutamiseks. 1.2 Dokumendi sihtrühm Dokument on suunatud potentsiaalsetele pakkujatele. 1.3 Dokumendi sisu Käesolev dokument kirjeldab hangitavat teenust ning annab üldise ülevaate keskkonnast, kus partneril tuleb tegutseda. 2. Taust ja kirjeldus 2.1. Tellija tegutsemisvaldkond Sotsiaalministeerium (edaspidi ministeerium) on valitsusasutus, kes täidab seadusest tulenevaid ja Vabariigi Valitsuse poolt seaduse alusel antud ülesandeid oma valitsemisalas. Ministeeriumi valitsemisalas on riigi sotsiaalprobleemide lahendamiskavade koostamine ja elluviimine, rahva tervise kaitse ja arstiabi, tööhõive, tööturu, töökeskkonna ja töösuhete, sotsiaalse turvalisuse, sotsiaalkindlustuse ja -hoolekande korraldamine, võrdse kohtlemise ning naiste ja meeste võrdõiguslikkuse edendamise ja sellealase tegevuse koordineerimine, laste õiguste ja perede elukvaliteedi edendamine, puudega inimeste sporditegevuse edendamine ja toetamine ning vastavate õigusaktide eelnõude koostamine. Ministeeriumi põhiülesanne on seadustes ja teistes õigusaktides sätestatud pädevuse piires korraldus-, arendus-, planeerimis- ja järelevalvetoimingute tegemine oma valitsemisalas, lähtudes valitsemisala arengukavas esitatud ministeeriumi ja valitsemisala strateegilistest eesmärkidest ning 4. peatükis sätestatud osakondade põhiülesannetest. Eesti E-tervise Sihtasutus on üleriigiliste e-lahenduste edendaja ja arendaja tervishoiusüsteemis –loome lahendusi ja pakume teenuseid, mille eesmärk on toetada kvaliteetse ja kättesaadava tervishoiuteenuse osutamist. Meie laiem eesmärk on aidata kaasa tervishoiusüsteemi arendamisele teadliku patsiendi keskseks. 3. Tervise infosüsteem Tervise infosüsteem (TIS) on riigi infosüsteemi kuuluv andmekogu (edaspidi tervise infosüsteem), milles töödeldakse tervishoiuvaldkonnaga seotud andmeid tervishoiuteenuse osutamise lepingu sõlmimiseks ja täitmiseks, tervishoiuteenuste kvaliteedi ja patsiendi õiguste tagamiseks ning rahva tervise kaitseks, sealhulgas tervislikku seisundit kajastavate registrite pidamiseks ja tervishoiu juhtimiseks (Tervise infosüsteemi põhimäärus §2 3 https://www.riigiteataja.ee/akt/13015769 ). TIS-ga on liidestunud 1094 Tervishoiuteenuseid osutavat asutust. TIS serveerib 17 X-tee teenust, millest tähtsaimas hl7 teenuses on omakorda kasutusel 293 HL7 v3-l põhinevat standardit. TIS andmebaasis on üle miljardi kirje. TIS on liidestatud erinevate üleriigiliste infosüsteemidega ning pilooditud on ka üleeuroopalist terviseandmete vahetust. TIS kasutab 200+ tabelit. Süsteemis on 1,4 miljoni isiku andmed. Baasis on üle 20 miljoni kehtiva tervisedokumendi, milles on kajastatud üle 200 miljoni tervisesündmuse. 3.1. TIS liidesed 3.1.1 TIS serveerib hetkel 17 X-tee teenust. Mõned kasutajad: Tervishoiuteenuse osutajad, Tervisearengu Instituut, patsiendiportaal jne. 3.1.2 Andmeid päritakse X-tee kaudu: Rahvastikuregistrist, Terviseameti tervishoiutöötajate ja tegevuslubade registritest, Retseptikeskusest, Haigekassa kindlustatuse registrist, Ravimiameti koodikeskusest 3.1.3 Süsteem suudab saata automaatteateid tervisetõendite kehtivuse lõppemise kohta riigiportaali teavituskalendri kaudu, mis kasutab hetkel e- maili abil teavitamist 4. Hangitav teenus Leping sõlmitakse meeskonna rollipõhise teenuse ostmiseks. Kõikidel rollidel on sama tunnihind. Hankija hangib vähemalt seitsmeliikmelise meeskonna, mis pakub Hankijale rollipõhist teenust tervise infosüsteemi ja seonduvate tarkvaraliste moodulite arendamiseks. 4 4.1. Hangitavate teenuste nimekiri: 4.1.1. Analüüsi teostamine: Ärianalüüsi ja detailanalüüsi läbiviimine (sh tehniline standardimine). Analüüsi dokumentatsiooni nõuded on kirjeldatud lisas nr. „Nõuded infosüsteemi dokumentatsioonile“ 4.1.2. Disaini teostamine: Tarkvaralahenduse disain (nii visuaalne kui ka süsteemne); 4.1.3. Arenduse teostamine: Tarkvara lahenduse loomine, sh rakendustarkvara koodi, andmebaasi struktuuri täiendamine ja testide kirjutamine; 4.1.4. Konsulteerimine: Tellija spetsialistide nõustamine tarkvaraarenduse valdkonnas ja vajadusel osalemine kohtumistel Tellijaga ja Tellija partneritega; 4.1.5. Tarkvara testimine: Tellija lepingupartneri poolt loodud lahenduse testimine (k.a. koormustestid). Automaattestide (sh regressioontestide ja smoke testide) koostamine ja haldamine; 4.1.6. Dokumentatsiooni koostamine ja täiendamine Dokumenteerimise nõuded on kirjeldatud lisas nr „Nõuded infosüsteemi dokumentatsioonile“ 4.1.7. Infosüsteemi versioonimuudatuste korral paigalduspakettide ettevalmistamine. 4.2. Teenuse sisu 4.2.1. Tervise infosüsteemi juurde kuuluvate portaalide ja moodulite analüüsi ja arenduse teostamine; 4.2.2. Kodanikule ja partneritele suunatud e-teenuste analüüsi ja arenduse teostamine, mida käsitletakse ühe osana tervise infosüsteemist. 4.2.3. Tegevused teostatakse järgnevate komponentide ulatuses: 4.2.3.1. TIS portaalid ja moodulid 4.2.3.2. Autentimis-autoriseerimismoodul 5 5. Arendusmeeskond ja –meetod 5.1. Arendusmeeskond Rakendatava meeskond on vähemalt kuueliikmeline. Meeskonna rollipõhine jaotus on alljärgnev: Rolli nimetus arv Kvalifikatsiooninõuded Arendaja 2  valdab eesti keelt emakeelena või Keeleseaduse lisa 1 kohasel tasemel B2;  valdab inglise keelt;  on minimaalselt 2-aastase PostgreSQL-i, Tomcati, Java, AJAX tehnoloogia ja HL7 standardi arenduskogemusega;  on osalenud programmeerijana vähemalt ühes (1) üle 50 000 EUR eelarvega projektis, kus on arendanud lahendust, mis baseerub PostgreSQL-i, Tomcati, Java, AJAX tehnoloogiatel ja HL7 standardil. Testija 1  valdab eesti keelt emakeelena või Keeleseaduse lisa 1 kohasel tasemel B2;  valdab inglise keelt;  on osalenud testijana vähemalt kahes (2) üle 50 000 EUR eelarvega arendusprojektis. Analüütik 2  omab kõrgharidust;  valdab eesti keelt emakeelena või Keeleseaduse lisa 1 kohasel tasemel B2;  valdab inglise keelt;  on UML (Unified Modeling Language) ja HL7 standardiga töötamise kogemus ning on osalenud süsteemianalüütikuna vähemalt ühes (1) üle 50 000 EUR eelarvega HL7 standardit rakendanud arendusprojektis. Projektijuht 1  omab kõrgharidust;  valdab eesti keelt emakeelena või Keeleseaduse lisa 1 kohasel tasemel B2;  valdab inglise keelt;  on kehtiv Scrum Alliance 6  (https://www.scrumalliance.org/certifications) poolt väljastatud sertifikaat koolituse läbimisest;  on osalenud projektijuhina vähemalt kahes (2) üle 50 000 EUR eelarvega arendusprojektis;  on vähemalt kolmeaastane tarkvaraarendusprojektide juhtimise kogemus. Pakkuja on kohustatud kasutama hankelepingu täitmisel pakkumuses nimetatud meeskonna liikmeid. Meeskonna liikmeid võib vahetada ainult tellija eelneval nõusolekul.  peab uus meeskonnaliige vastama hankes esitatud kvalifikatsiooninõuetele  meeskonnaliikme pädevuse hindamiseks tuleb esitada meeskonna liikme CV, mis sisaldab vastab hankes esitatud nõuetele (sh. Projektid kus nõutud kogemus on omandatud) Meeskonnaliikmete CV´d hoitakse dokumendihalduse keskkonnas. 5.2 Nõuded arendusprotsessile 5.2.1 Lepingu raames tellitavaid töid hallatakse järgnevalt: Sündmus Tulem Kommentaar Tegemata tööde haldus Kohtumine. Ettevalmistatud Võib toimuda paralleelselt (Backog grooming ja sprint kasutajalood koos käigus oleva backlog) lisamaterjalidega järgmiseks arendustsükliga. arendustsükliks. Tellija projektijuht kaasab vajalikud inimesed. Arendustsükli planeerimine Kohtumine. Järgmiseks Arendaja annab (Sprint planning) arendustsükliks realiseerimisele kuuluvate realiseeritavate kasutajalugudele kasutajalugude üleandmine mahuhinnangu ja arendusmeeskonnale maksumuse vastavalt tellijapoolse projektijuhi või keerukusele. Vastavalt tooteomaniku poolt. arendajapoolsele vajadusele luuakse kasutuslugudele arenduse käigus Arendustsükkel (Sprint) Arendaja töötab vajadusel Tellija projektijuht või koos tellijaga (tellija tooteomanik annab ruumides), et operatiivselt tagasisidet arendajale. saada vastused küsimustele Tulemite Kohtumine. Arendaja annab See on ettevalmistus üleandmine/vastuvõtmine ülevaate loodud vastuvõtutestimiseks (Sprint review) funktsionaalsusest 7  tooteomanikule ja töögrupile Vastuvõtutestimine Tellijapoolne testijate Vead (bugid) kõrvaldatakse (Acceptance testing) töögrupp viib läbi testimise jooksvalt. vastavalt tööprotsessile Muudatusettepanekud lisatakse tegemata tööde nimekirja Arendusprotsessi osadeks olevaid sündmusi hallatakse Sotsiaalministeeriumi Jiras. Arendusprotsessi käigus loodavaid ja hallatavaid dokumente hoitakse Sotsiaalministeeriumi Confluence´is. Confluence´i ja Jira kasutamine lepitakse täpsemalt kokku kodukorras. 5.2.2 Arendustsükli tulemid Arendaja poolt tehtud tööde tulemusena antakse iga arendustsükli käigus üle vähemalt:  Töötav tarkvara  Kokkulepitud dokumentatsioon ja juhendid  Juurdepääsud vajalikele keskkondadele Lisaks antakse tööde käigus üle toote ja selle toimimiseks vajalike komponentide omandiõigust tõendavad dokumendid. 6. Mittefunktsionaalsed nõuded Tervise infosüsteemi (TIS) ja sinna juurde kuuluvate komponentide (teenuste, liideste jms) tööd teostatakse lähtuvalt Tellija üldistest arendusnõuetest (lisa nr 2. „Nõuded arendustele“) või Tellija poolt kinnitatud viimastest arendusnõuetest. Komponentide platvormid on järgmised: 1. TIS arstiportaali arendatakse PostgreSQL 9.2 ning Tomcat 7 ja Java 7 või nende uuematel versioonidel 2. TIS patsiendiportaali arendatakse Tomcat 8 ja Java 8 või nende uuematel versioonidel 3. Autentimis-autoriseerimismoodulit arendatakse PostgreSQL 9.2 ning Tomcat 7 ja Java 7 või nende uuematel versioonidel. Platvormide uuemate versioonide kasutusele võtmisel tuleb see kooskõlastada tellijaga. 8 7. Arendus -, Test-, Prelive- ja toodangukeskkonnad 1. Arenduskeskkond koosneb vähendatud võimsusega komponentidest 2. Testkeskkond koosneb vähendatud võimsusega komponentidest. Arendajatel on testkeskkonnale lugemisõigusega ligipääs. 3. Prelive keskkond koosneb toodangukeskkonnale sarnastest komponentidest, sh. Andmebaasid, rakendusserverid ning väliste süsteemide liidesed. Arendajatel prelive keskkonnale ligipääs puudub. 4. Toodangukeskkonna konfiguratsioon lepitakse kokku arenduse käigus. Arendajatel toodangukeskkonnale ligipääs puudub. 5. Pooled teevad mõistlikud pingutused tagamaks, et Testkeskkond sarnaneks Toodangukeskkonnale järgmises osas: (a) arvutivõrgu konfiguratsioon; (b) liidesed kolmandate süsteemidega; 6. Kui maksimaalne sarnasus ei ole majanduslikult põhjendatud või tulenevalt andmekaitse piirangutest mõistlik, kohustub Pool informeerima teist Poolt Test- ja Toodangukeskkondade disainitud erinevustest. Vajadusel lepivad Pooled kokku alternatiivse võimaluse keskkondade erinevuse puudujäägi kompenseerimiseks. 7. Arendus- ja Testkeskkondade installeerimise, keskkondade ning ligipääsude haldamise osas lepitakse kokku projekti alguses. 9  Raamlepingu lisa 3 „Kodukord“ KODUKORD 1. EESMÄRK 1.1 Kodukorra eesmärgiks on täpsustada lepingu täitmisel teostatavad tegevused ning Töövõtja ja Tellija omavaheline suhtlus ning tagasiside andmise kord. 1.2. Kodukorras toodud tööprotsesse võivad pooled koostöös täpsustada. 2. SUHTLEMIST JA PROJEKTI ELLUVIIMIST TOETAVAD KESKKONNAD JA VAHENDID 2.1. Suhtluskanalid 2.2.1 E-post – e-post kasutatakse projektis igapäevase suhtluskanalina (v.a kui konkreetset infot tuleb vastavalt kodukorrale edastada Tööülesannete halduskeskkonna või Projekti dokumendihalduskeskkonna kaudu). Kui e-postile oodatakse vastust, tuleb subjekti real või kirja alguses see üheselt määratleda. Kui e- posti saatmisele järgneb kontorist eemaloleku teade (inglise k. Out of Office), siis edastatakse sama kiri teates märgitud asendajale. E-postile tuleb vastata hiljemalt viie (5) Tööpäeva jooksul algse sõnumi saamisest (v.a e-post, mis on edastatud vaid info jagamise eesmärgil). 2.2.2 Mailinglistid – Projektimeeskonna liikmete omavahelise suhtlemise lihtsustamiseks luuakse vajadusel Projekti mailinglistid. Iga Tellija ja Töövõtja vahelise mailinglisti puhul arvestatakse reeglit, et kui e-posti lugemine on ühe või mitme konkreetse meeskonnaliikme poolt oluline, tuleb kiri nimeliselt nendele isikutele adresseerida. 2.2.3 Koosolek – koosoleku kokkukutsumisel esitatakse päevakord (olulisemad arutamist vajavad punktid) ja eesmärk. Võimaluse korral lepitakse Projekti alguses kokku korralised koosolekud (näiteks regulaarsed iganädalaselt kindlatel aegadel toimuvad analüüsikoosolekud). Korralisi koosolekuid võib Poolte kokkuleppel tühistada (hiljemalt samal päeval 2-tunnise etteteatamise ajaga). 2.2.4 Skype (või sarnane sõnumivahetuskeskkond) – kiireloomuliseks ja operatiivseks suhtluseks on lubatud kasutada kas Skype’i või sarnast teenust. Kui alustatud vestluse teine pool koheselt ei reageeri, tuleb saata e-post. Juhul kui Skype’i või sarnase teenuse vahendusel vahetatud informatsioon on oluline, tuleb info e-posti teel üle korrata või teemat koosolekul arutada. 2.2.5 Telefon – kasutatakse operatiivse ja olulise informatsiooni edastamiseks, samuti kriisisituatsioonides. Telefonikõnele mitte vastates tuleb tagasi helistada esimesel võimalusel, aga mitte hiljem kui järgneva Tööpäeva lõpus. Olulistel juhtudel (näiteks juurutusfaasis) peavad mõlema Poole projektijuhid olema telefoni teel kättesaadavad ka pärast ametlikku Tööpäeva lõppu. Valmisolek lepitakse eraldi kokku. 2.3 Tööülesannete halduskeskkond 2.3.1 Tööülesannete halduskeskkond on konfiguratsiooni- ja tööülesannete haldustarkvara, mida kasutatakse arendustööde ning Töödes leitud vigade ja probleemide registreerimiseks tööülesannetena, tööülesannete täitmise jälgimiseks ning tööaja arvestuseks. Tellija registreerib arendustööde tulemis leitud vead tööülesannetena Tööülesannete halduskeskkonnas. Raamlepingu lisa 3 „Kodukord“ 2.3.2 Tellija võib lisaks Tööülesannete halduskeskkonnas registreerimisele viidata leitud vigadele ka e-posti või muude suhtluskanalite vahendusel, kuid vea/tööülesandega tegelema hakkamise eelduseks on selle registreerimine Tööülesannete halduskeskkonnas ning lepingus toodud kontaktisiku poolt nimetatud tööde eest vastutava isiku korraldus tööde alustamiseks. Korraldus tööde alustamiseks võib olla antud ka muu suhtluskanali kaudu. 2.3.3 Tellija võib teha tööde täitmise käigus veahalduskeskkonnas registreeritud tööde osas teha tööde teostamise järjekorra muudatusi. 2.3.4 Vajadusel lepivad Pooled kokku täpsema Tööülesannete halduskeskkonna kasutamise korra, milles täpsustatakse ülesannete lisamise nõuded (pealkirjad, teemad, ülesannete prioriteetide kategooriad jmt). 2.3.5 Tööülesannete halduskeskkond asub Tellija juures. 2.4 Dokumendihalduskeskkond 2.4.1. Dokumendihalduskeskkonda kasutatakse Tellija ja Töövõtja vaheliseks infovahetuseks ning selle keskkonna kasutamine on kohustuslik dokumentide vahetamisel. 2.4.2. Tellitavate tööde kokkuleppimise ja käivitamise faasis Tellija poolt nõutud ja tööde täitmiseks ja vastuvõtmiseks vajalik dokumentatsioon luuakse ja täiendatakse dokumendihalduskeskkonnas viisil mis võimaldab Töövõtjal ja Tellijal jooksvalt jälgida dokumentide täiendamist vastavalt teostatud töödele. 2.4.3. Töövõtja edastab dokumendihalduskeskkonda töö täitmise käigus koostatud kogu dokumentatsiooni Tellijale ülevaatamiseks ja kooskõlastamiseks. 2.4.4. Dokumendi kustutamine Projekti dokumendihalduskeskkonnast on lubamatu (v.a juhul, kui Tellija ja Töövõtja projektijuhid on kustutamiseks kirjalikku taasesitamist võimaldaval viisil nõusoleku andnud).. 2.4.5. Vajadusel lepivad Pooled kokku täpsema Tööde dokumendihalduskeskkonna kasutamise korra, milles täpsustatakse dokumentide lisamise tingimused (pealkirjad, koodid, teemad, kategooriad jmt). 3. ÜLDINE TÖÖKORRALDUS 3.1 Tellija soovil toimub Tööde teostamine agiilsel arendusmeetodil. Metoodikat võib Poolte kokkuleppel muuta lähtudes tõhususe, kvaliteedi, säästlikkuse ja otstarbekuse põhimõtetest ning arvestades vastavas tegevusvaldkonnas kehtivaid õigusakte, standardeid ja head tava. 3.2 Töövõtja poolne Tööde teostamise kohustuste täitmine ei tohi tekitada häireid Tellija mistahes teiste liidestatud süsteemide või teenuste talitluses, v.a juhul kui Töövõtja lähtus Töö teostamisel Tellijapoolsetest juhistest ja kokkulepetest, kuid sellele vaatamata tekkisid häired. Juhul, kui Töö teostamine toimub Tellija ruumides, peavad Tellija ruumides viibivad Töövõtja Teostajad kinni pidama Tellija sellistest sisekorraeeskirjadest, sh turvanõuetest, mida on Tellija tutvustatud. 3.3 Lepingu täitmisest tulenev suhtlus toimub eesti keeles, kui ei lepita kokku teisiti. Raamlepingu lisa 3 „Kodukord“ 4. TÖÖDE TEOSTAMISE MEESKOND 4.1 Tööde teostamiseks moodustatakse projektimeeskond, kui Tellija peab seda vajalikuks. 4.2 Projektijuhid 4.2.1 Kumbki Pool nimetab tööde teostamiseks omapoolse projektijuhi. 4.2.2 Töövõtja projektijuht juhib Töövõtja poolt tööde tulemusena tulemi kokkuleppimist, vastutab tööde teostamise ajaplaani koostamise eest ning tagab kokkulepitud tööde tulemi ja ajaplaani täitmise. 4.2.3 Tellija projektijuht juhib Tellija poolt tööde tellimuse ja ajaplaani kokkuleppimise (sh dokumenteerimise) ja tööde teostamist. Tellija projektijuhil on õigus kontrollida Lepingu täitmise käiku ning kohustus anda Töövõtjale töödega seotud informatsiooni ja juhiseid vastava nõude esitamisel. 4.2.4 Kumbki Pool peab tagama, et tema projektijuhil on vajalik ajaressurss ning kõik vajalikud õigused ja pädevus vastava Poole nimel tegutseda. 4.2.5 Poolte projektijuhid jälgivad kodukorras toodud nõuete täitmise eest. 4.3 Teostajad 4.3.1 Teostajad vastutavad, et nende poolt teostatud tööd on teostatud ja dokumenteeritud vastavalt kokkulepitud töö eesmärgile ning Tellija suunistele ja nõuetele ning valdkonnas kehtivatele parimale praktikale. 4.3.2 Töövõtja on kohustatud kasutama Lepingu täitmisel Pakkumuses nimetatud Teostajaid või Tellija eelneval kirjalikul nõusolekul asendama nad Teostajatega, kes vastavad kõikidele Riigihankes nimetatud rolli kohta esitatud kvalifitseerimistingimustele. 4.3.3 Kumbki Pool peab tagama, et tema kaasatud Teostajal on kõik vajalikud teadmised, oskused ja kogemused ning piisav ajaressurss vastava Poole nimel Töid või Projekti teostada. 4.3.4 Vajadusel täpsustavad Pooled tööde teostamise eelselt meeskonnas teostajate rollid. 5. TÖÖVÕTJA JA TELLIJA ÜLESANDED 5.1 Töövõtja ülesanded: 5.1.1 teostada kokkulepitud Tööd kokkulepitud ulatuses ning ajakavas; 5.1.2 koostada ja täiendada dokumendihaldussüsteemis tööde teostamise eelselt ja käigus kokkulepitud dokumentatsioon; 5.1.3 anda selgitusi teostatud töödest; 5.1.4 konsulteerida Tellijat Tööde rakendamisel; 5.1.5 hoida Tellijat kursis Tööde arengu ja hetkeseisuga ning täita muid Lepingust tulenevaid kohustusi. 5.2. Vajadusel täpsustavad pooled tööde teostamise eelselt Töövõtja ülesandeid. 5.3. Tellija ülesanded on: 5.3.1 tagada Töövõtjale Tööde teostamiseks vajalik informatsioon, dokumentatsioon ja juurdepääsud; Raamlepingu lisa 3 „Kodukord“ 5.3.2 üle vaadata, testida ja kooskõlastada Töövõtja esitatavad tulemid, parandus- ja täiendusettepanekud kokkulepitud tähtaegade jooksul; 5.3.3 tagada Tellija hallatavate infotehnoloogiliste keskkondade korrektne toimimine Tööde teostamise vältel, mis on olulised Töövõtja poolsete kohustuste täitmiseks. 5.4. Vajadusel täpsustavad pooled tööde teostamise eelselt Tellija ülesandeid. 6.1 Kriisisituatsioonide haldamine 6.1.1 Kriisisituatsiooniks loetakse olukorda, kus Poolte esindajad ei suuda kokkuleppele jõuda või on muutunud võimatuks võtmeisikute osalemine tööde teostamisel või ilmnenud on muud asjaolud, mis võivad oluliselt mõjutada tööde edukat elluviimist. 6.1.2 Kriisi tekkimisel on Pool kohustatud sellest teise Poole esindajat viivitamatult kirjalikult teavitama. 6.1.3 Kriisist väljumiseks teevad mõlemad Pooled kõik endast sõltuva, et tagada tööde teostamine.  RAAMLEPING Tallinnas, Sotsiaalministeerium, registrikood 70001952, aadress Suur-Ameerika 1, Tallinn, keda esindab põhimääruse alusel kantsler Marika Priske andis 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga üle Sotsiaalministeeriumi valitsemisel oleva riigivara lepingu ja sellest tulenevad õigused ja kohustused „Raamleping Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuste teostamiseks“ nr 1.8-2/7824, mis sõlmiti 02.01.2017 Quretec OÜ-ga ja Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25/Veerenni 13, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold, võttis nimetatud lepingu 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga vastu. Sotsiaalministeerium tema haldusalas tegutseva Tervise ja Heaolu Infosüsteemide Keskuse kaudu, keda esindas põhimääruse alusel kantsler Marika Priske ja Eesti E-tervise Sihtasutus, registrikood 90009016, aadress Uus Tatari 25/Veerenni 13, 10134 Tallinn, keda esindas põhikirja alusel juhatuse liige Margus Auväärt vahel 29.11.2016 sõlmitud ettevõtte üleandmise lepinguga nr 1.8-2/7755 kohustus Eesti E-tervise Sihtasutus üle andma ja Tervise ja Heaolu Infosüsteemide Keskus vastu võtma seisuga 01.01.2017 kõik tervise infosüsteemi haldamise ja volitatud töötlejaks olemisega seotud Eesti E-tervise Sihtasutuse õigused ja kohustused, sh täitmisel olevad lepingud ning nimetatuist tulenevad õigused ja kohustused. Eeltoodust tulenevalt: Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25/Veerenni 13, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold (edaspidi: Tellija) ja OÜ Quretec registrikood 11043739 (ühispakkujaga OÜ Tarkvara Tehnoloogia Arenduskeskus registrikood 11672027) aadress Ülikooli 6a, Tartu, keda põhikirja alusel esindab juhatuse liige Margus Jäger (edaspidi: Töövõtja) edaspidi ka eraldi pool või koos pooled, sõlmisid alljärgneva raamlepingu: 1. Raamlepingu ese 1.1. Pooled sõlmivad raamlepingu kolmeks aastaks töövõtja poolt riigihankel „Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine “ (Riigihanke registreerimisnumber: 178741) hankeosas II esitatud pakkumuse alusel. 1.2. Raamlepingu esemeks on tervise infosüsteemi arendus- ja hooldustööd, tööde teostamise täpsemad tingimused on kokku lepitud Lepingu Lisas „Tehniline kirjeldus“ ja Lisas „Hinnapakkumus“ (edaspidi nimetatud töö). 1.3. Pooled teevad raamlepingu täitmiseks ja eesmärkide saavutamiseks koostööd. Raamlepingu täitmisel kohustuvad Pooled tegema kõik vajalikud pingutused, et täita õigeaegselt ja korrektselt kõiki Raamlepingust, hankelepingust ning õigusaktidest tulenevaid kohustusi. 1.4. Tellija ei anna omapoolseid garantiisid lepingu jõustumise hetkel valitseva olukorra suhtes. Tellija eeldab, et töövõtja on lepingu valdkonna professionaal, kes võtab endale teadlikult kanda lepingu tingimuste täidetavuse ja lepingu tulemuse saavutatavuse riski. 1.5. Töövõtja kinnitab, et on lepinguga ja riigihanke hankedokumentidega tutvunud ning mõistab täielikult enesele võetavate kohustuste sisu ja tagajärgi ning on nõus nendes toodud tingimustega. 2. Lepingus kasutatud mõisted 2.1. Hankeleping – raamlepingu alusel sõlmitud töövõtu- ja autorileping koos kõigi selle lisadega. Hankelepingu esemeks on töövõtja tehtavad tarkvara arendus- ja rakendustööd või muud raamlepingu punktis 1.2 nimetatud tööd koos autoriõiguste või kasutuslubade (litsentside) andmisega tellijale. 2.2. Tarkvara – infosüsteemi arendamise käigus tekkiv tarkvara, mis vastab lepingus, hankedokumentides või pakkumuses esitatud tarkvara kirjeldusele. Tarkvara tähendab ühtlasi loodavat kogumikteost autoriõiguse seaduse mõttes ja töövõtuga tehtavat tööd võlaõigusseaduse mõttes. 2.3. Tarkvara kirjeldus – tarkvara struktuursete, funktsionaalsete, tehniliste, õiguslike ja muude omaduste kogukirjeldus, mis sisaldub hankedokumendis, lepingus ja selle lisades. Tarkvara kirjeldus ei ole üks eraldi dokument, vaid hankedokumendist, lepingust ja selle lisadest tulenev terviklik kontseptsioon tarkvarast kui sellisest. 2.4. Projektiplaan – tarkvara väljatöötamise ja juurutamise tööülesannete kirjeldused, nende täitmise etapiviisilised ajakavad, töö etappide ja tellijale üleantavate tööde vahetulemuste kirjeldused, mis vastavad tarkvara kirjeldusele; töö vahetulemuste üleandmise tähtajad, töö (tarkvara) tervikuna üleandmise ja vastuvõtmise tähtpäevad, töö vahetulemustele esitatavate nõuete kirjeldused ning meeskonna loetelu ja ülesannete kirjeldused, mis on esitatud lepingus ja selle lisades. 2.5. Töö kirjeldus – töö tulemuse kirjeldus, milleks on arendustööde puhul eelkõige tarkvara kirjeldus ning muude raamlepingu punktis 1.2 (tehniline kirjeldus) nimetatud tööde puhul pakkumuse esitamise ettepanek ja töövõtja pakkumus. 2.6. Töö üleandmine – töövõtja poolt eelnevalt testitud tarkvara või selle loomise vahetulemuse üleandmine tellijale ülevaatamiseks lepinguga ettenähtud tingimustel. Tarkvara üleandmisena ei käsitata selle vastuvõtmist (aktsepteerimist) tellija poolt. Üleandmine võib muu hulgas käsitada tarkvara või selle vahetulemuse installeerimist tellija töökeskkonda. 2.7. Töö vastuvõtmine – tarkvara või selle loomise vahetulemuse vastuvõtmine tellija poolt raamlepingu ja hankelepinguga ettenähtud tingimustel. 2.8. Vastuvõtu test – tarkvara või selle vahetulemuse testimine lepingus sätestatud tingimustel. Vastuvõtu testi edukas sooritamine on tarkvara tellija poolt vastuvõtmise peamiseks, kuid mitte ainsaks eelduseks. 2.9. Tarkvara juurutamine – töövõtja poolt lepingu alusel teostatavad tegevused, mille sihiks on tarkvara ettenähtud töö tagamine, sh tarkvara tarviliku ühilduvuse tagamine riist- ja tarkvaraga tellija kasutuskeskkonnas, töö vahetulemuste ja kogu tarkvara vastuvõtu testide ettevalmistamine ja läbiviimine ning garantiiaja jooksul tarkvara vigade ja puuduste kõrvaldamine. 2.10. Litsents – tarkvara või selle osa autoriõiguslik kasutusluba (autorilitsents). 2.11. Kodukord – Poolte vahel sõlmitav kokkulepe raamlepingu ja hankelepingu kohaste tööde teostamiseks. 2.12. Leping käsitab ka muid mõisteid, mis on määratletud lepingu tekstis või mille tähendus tuleneb lepingu kontekstist ja lepinguga käsitletavate poolte tegevusvaldkondade tavapärasest mõistestikust. 3. Raamlepingu täitmine 3.1. Töövõtja ja tellija viivad 30 (kolmekümne) kalendripäeva jooksul alates raamlepingu sõlmimistest läbi töökorraldusliku koosoleku tellimustööde ja projektide juhtimise ning metoodikate ühtlustamiseks ning kooskõlastamiseks ning sõlmivad kodukorra. 3.2. Töövõtja kohustub tagama tellija esindajate koolitamise ja juhendamise raamlepingu kehtivuse ajal rakendatavate töömeetodite tõhusaks rakendamiseks. 3.3. Tellija tagab vajalikud volitused kohustuste ja nõuete kvaliteetseks täitmiseks. 3.4 Töövõtja on kohustatud kasutama hankelepingu täitmisel pakkumuses nimetatud meeskonna liikmeid või tellija eelneval nõusolekul spetsialiste, kelle kvalifikatsioon vastab vähemalt hankedokumentides esitatud tingimustele. Meeskonna liikmete vahetamisest tuleb teavitada tellijat ning saada vahetuse osas tellija kooskõlastus. 3.5. Tellija jätab endale õiguse valida hankelepingu täitmiseks täiendavaid isikuid, kelle rollid ei ole hankemenetluse raames fikseeritud. 3.5. Töövõtja kohustub raamlepingu täitmise perioodil esitama tellija nõudmisel oma töötajate või alltöövõtjate kvalifikatsiooni tõendavaid dokumente tõendamaks nende kvalifikatsiooni vastavust tellija poolt nõutule. Juhul kui töötaja või alltöövõtja kvalifikatsioon ei vasta tellija poolt nõutule kohustub töövõtja asendama töötaja või alltöövõtja. 3.6. Tellija nõudmisel peavad täitja vastavad meeskonna liikmed hankelepingu täitmisel viibima tellija asukohas. 3.7. Raamlepingu kehtivuse ajal võib pakkumuses nimetatud alltöövõtjaid muuta ainult tellija kirjalikul loal. Raamlepingupartnereid võib kaasata hankelepingu alusel tehtavate tööde teostamisse. 3.8. Alltöövõtjate kasutamise korral jääb raamlepingu nõuetekohase täitmise eest vastutavaks töövõtja. 3.9. Töövõtja esitab tellijale kokkulepitud vormis ja aegadel (võib fikseerida projektiplaanis) aruanded tehtud töödest ning raamlepingu täitmise peamistest asjaoludest sh võimalike riskide aktualiseerumisest. 3.10. Töövõtja poolne raamlepinguliste kohustuste täitmine ei tohi tekitada häireid tellija mistahes teiste liidestatud süsteemide/teenuste talitluses. 3.11. Töövõtja tagab üleantavate tööde ühilduvuse tellija baaskomponentide ja funktsionaalsusega. 3.12. Töövõtja kohustub koheselt informeerima tellijat tehnilistest või organisatoorsetest piirangutest, mis võivad seada ohtu raamlepinguga seatud eesmärkide saavutamise. 3.13 Töövõtja tagab, et raamlepingu täitmisega ei kahjustata kolmandate isikute õigusi ja huve ning puuduvad mistahes asjaolud, mis välistaksid tema õigusi sõlmida raamlepingut ja hankelepinguid ja neid nõuetekohaselt täita. 4. Hankelepingu sõlmimine maksumusega alla 10 000 euro 4.1. Töö, mille eeldatav maksumus käibemaksuta jääb alla 10 000 euro (edaspidi tellimus) tehnilised tingimused (sh funktsionaalsed ja mittefunktsionaalsed nõuded), tähtaeg, maht ja hindamise kriteeriumid määratletakse pakkumuskutses. 4.2. Hankelepingu sõlmimiseks esitab tellija kirjalikku taasesitamist võimaldavas vormis ettepaneku esitada pakkumus. Pakkumuse esitamise tähtaeg on 3 (kolm) tööpäeva. 4.3. Töövõtjal on õigus küsida selgitusi pakkumuskutses toodud tööde ja tingimuste kohta enne pakkumuse tähtaega. 4.4. Tellija on küsimuse esitamisel kohustatud andma küsitud lisainfot pakkumuskutses toodud tööde ja tingimuste kohta hiljemalt 1 (ühe) tööpäeva jooksul kirjalikult kõigile raamlepingu partneritele või juhul kui pakkumuse esitamise tähtaeg on rohkem kui 3 (kolm) tööpäeva, 3 (kolme) tööpäeva jooksul. 4.5. Töövõtja kohustub pakkumuses kirjeldama kõiki töö läbiviimiseks vajalikke tegevusi, nimetades lisaks iga tegevuse teostaja(d) ning tegevuseks kuluva aja tundides nii iga teostaja poolt kui kõigi teostajate poolt kokku. Samuti, kas ja millised autoriõigused töö tegemisel tekivad ning millised autoriõigused ja millises mahus tellijale loovutatakse ja milliste osas antakse kasutusõigus vastavalt raamlepingu punktile 9.4. 4.6. Tellija jätab endale õiguse konkreetse tellimuse puhul sätestada Täitja pakkumuse hindamiseks kriteeriumid, mille alusel tunnistatakse edukaks pakkumus ja pakkumuse alusel sõlmitakse Hankeleping. Hindamiskriteeriumitena võib hankija kasutada järgnevaid kriteeriume: 4.6.1. Pakkumuses esitatud madalaim tunnihind; 4.6.2. Pakkumuses esitatud hankelepingu raames tellitava teenuse fikseeritud koguhind; 4.6.3. Pakkumuses esitatud madalaim rolli- ja/või isikupõhine tunnihind. 4.7. Juhul, kui pakkumuses sisaldub ärisaladus kohustub töövõtja pakkumuses märkima ärisaladust sisalduvad osad. 4.8. Juhul, kui töövõtja kasutab töö tegemisel alltöövõtjaid, kohustub ta pakkumuses esitama andmed alltöövõtja nime ja alltöövõtu suuruse kohta. 4.9. Vajadusel peab tellija töövõtjatega läbirääkimisi kirjalikku taasesitamist võimaldavas vormis või samas vormis protokollituna. Läbirääkimised on konfidentsiaalsed. 4.10. Esitatud pakkumus on kuni pakkumuse esitamise tähtaja möödumiseni konfidentsiaalne. Pärast pakkumuse edukaks tunnistamist ei avalda tellija andmeid pakkumuse osade kohta, milles sisaldub ärisaladus. 4.11. Pakkumusi hinnatakse madalaima hinna või majandusliku soodsuse alusel. Metoodika ja kriteeriumite valik fikseeritakse pakkumuskutses. Majandusliku soodsuse alusel hinnates on kriteeriumiteks maksumus ja tööde teostamise aeg. 4.12. Tellija hindab pakkumust, mis vastab pakkumuskutsele ja milles ei esine sisulisi kõrvalekaldumisi. Kui pakkumus ei vasta pakkumuses sätestatud hindamiskriteeriumitele jätab tellija pakkumuse hindamata. 4.13. Tellija teavitab töövõtjat raamlepingu alusel hankelepingu sõlmimisest 3 (kolme) tööpäeva jooksul pärast eduka pakkuja väljavalimist. 4.14. Edukale pakkujale edastab tellija hankelepingu, millele edukas pakkuja on kohustatud allkirjastama 5 (viie) tööpäeva jooksul. Juhul, kui edukas pakkuja keeldub hankelepingu sõlmimisest, on Tellijal õigus nõuda edukaks tunnistatud pakkumuse tagasi võtnud pakkujalt kahju hüvitamist tagasi võetud pakkumuse ja järgmise edukaks tunnistatud pakkumuse maksumuse vahe osas. 4.15. Edukale pakkujale edastatud tellija tellimuskiri ja töövõtja poolt antud tellimuse kinnitus loetakse raamlepingu lisaks, millele kohalduvad kõik raamlepingu ja hankelepingu tingimused. 5. Hankelepingu sõlmimine maksumusega üle 10 000 euro 5.1. Töö, mille eeldatav maksumus käibemaksuta ületab 10 000 eurot (edaspidi projekt) tehnilised tingimused (sh funktsionaalsed ja mittefunktsionaalsed nõuded), tähtaeg, maht ja hindamise kriteeriumid määratletakse pakkumuskutses. 5.2. Hankelepingu sõlmimiseks esitab tellija kirjalikku taasesitamist võimaldavas vormis ettepaneku esitada pakkumus. Pakkumuse esitamise tähtaeg on 5 (viis) tööpäeva. Või 5.2. Töö tellimiseks esitab tellija täitjale pakkumuse esitamise ettepaneku koos lepingu objekti tehnilise kirjelduse ja hankelepingu projektiga. Pakkumuse esitamise tähtaeg on 5 (viis) tööpäeva. 5.3. Töövõtjal on õigus küsida selgitusi pakkumuskutses toodud tööde ja tingimuste kohta enne pakkumuse esitamise tähtaega. 5.4. Tellija on küsimuse esitamisel kohustatud andma küsitud lisainfot pakkumuskutses toodud tööde ja tingimuste kohta hiljemalt 3 (kolme) tööpäeva jooksul kirjalikult ja kõigile raamlepingu partneritele. 5.5. Tellija jätab endale õiguse konkreetse tellimuse puhul sätestada täitja pakkumuse hindamiseks kriteeriumid, mille alusel tunnistatakse edukaks pakkumus ja pakkumuse alusel sõlmitakse Hankeleping. Hindamiskriteeriumitena võib hankija kasutada järgnevaid kriteeriume: 5.5.1. Pakkumuses esitatud madalaim tunnihind; 5.5.2. Pakkumuses esitatud hankelepingu raames tellitava teenuse fikseeritud koguhind; 5.5.3. Pakkumuses esitatud madalaim rolli- ja/või isikupõhine tunnihind; 5.5.4. Majandusliku soodsuse hindamiskriteeriumid ja hindamiskriteeriumite kirjeldus, mida on kasutatud raamlepingu sõlmimisele eelnevas riigihankemenetluses. Kusjuures hinnatakse pakkumuses esitatud hinda 55% osakaaluga ning tehnoloogiapõhist kompetentsi 45% osakaaluga. 5.6. Töövõtja kohustub pakkumuses kirjeldama kõiki töö läbiviimiseks vajalikke tegevusi, nimetades lisaks iga tegevuse teostaja(d) ning tegevuseks kuluva aja tundides nii iga teostaja poolt kui kõigi teostajate poolt kokku. Samuti, kas ja millised autoriõigused töö tegemisel tekivad ning millised autoriõigused ja millises mahus tellijale loovutatakse ja milliste osas antakse kasutusõigus vastavalt raamlepingu punktile 9.4. 5.7. Juhul, kui pakkumuses sisaldub ärisaladus kohustub töövõtja pakkumuses märkima ärisaladust sisalduvad osad. 5.8. Juhul, kui töövõtja kasutab töö tegemisel alltöövõtjaid kohustub ta pakkumuses esitama andmed alltöövõtja nime ja alltöövõtu suuruse kohta. 5.9. Vajadusel peab tellija töövõtjatega läbirääkimisi kirjalikku taasesitamist võimaldavas vormis või samas vormis protokollituna. Läbirääkimised on konfidentsiaalsed. 5.10. Esitatud pakkumus on kuni pakkumuse esitamise tähtaja möödumiseni konfidentsiaalne. Pärast pakkumuse edukaks tunnistamist ei avalda tellija andmeid pakkumuse osade kohta, milles sisaldub ärisaladus. 5.11. Pakkumusi hinnatakse madalaima hinna või majandusliku soodsuse alusel. Metoodika ja kriteeriumite valik fikseeritakse pakkumuskutses. Majandusliku soodsuse alusel hinnates on kriteeriumiteks maksumus ja tööde teostamise aeg. 5.12. Tellija hindab pakkumust, mis vastab pakkumuskutsele ja milles ei esine sisulisi kõrvalekaldumisi. Kui pakkumus ei vasta pakkumuses sätestatud hindamiskriteeriumitele jätab tellija pakkumuse hindamata. 5.13. Edukaks tunnistatud pakkumuse esitajaga sõlmib tellija kirjaliku hankelepingu. 5.14. Tellija teavitab töövõtjat raamlepingu alusel hankelepingu sõlmimisest 3 (kolme) tööpäeva jooksul pärast eduka pakkuja väljavalimist. 6. Üldised nõuded tööle 6.1. Töövõtja teostab töö kooskõlas pakkumuses toodud kirjeldusega ja parimate praktikatega tarkvaraarenduses ning tagab, et üleantav töö on kvaliteetne ja vastab esitatud nõuetele. 6.2. Kui töö või tarkvara ettenähtud funktsionaalsuse, jõudluse jt oluliste omaduste saavutamiseks on võimalik kasutada erinevaid lahendusi, peab töövõtja valima tellija jaoks hanke eesmärgist lähtudes kõige mõistlikuma lahenduse. Töövõtja on kohustatud konsulteerima selles küsimuses tellijaga ning saama valitud lahendusele tellija poolse kirjaliku kinnituse. Tellija annab kinnituse 3 tööpäeva jooksul. 6.3. Raamlepingu ja hankelepingu alusel koostatavad dokumendid antakse tellijale üle eestikeelsetena poolte poolt eelnevalt kokkulepitud vormingus. 6.4. Tellijale üleantavad dokumendid peavad vastama järgmistele nõuetele: 6.4.1. dokumendid peavad sisaldama kogu informatsiooni tehtud töö kohta (sh võimalikud muudatused võrreldes pakkumusega); 6.4.2. dokument peab olema terminoloogiliselt üheselt mõistetav; 6.4.3. dokument peab järgima semantilise koosvõime raamistiku nõudeid ning vastama riigi infosüsteemide arendamise dokumenteerimise nõuetele; 6.4.4. dokument peab tagama tellijale võimaluse parandada ja arendada tarkvara, samuti koolitada ja juhendada oma töötajaid tarkvara kasutamisel. 7. Töö valmimise tähtajad 7.1. Töövõtja nimetab pakkumuses tähtaja, mille jooksul töövõtja kohustub teostama tellimuse või projekti töö ühes kaasneva dokumentatsiooni, kõigi materjalide ja teenustega või tegema pakkumuskutses nimetatud töö. 7.2. Pooled lepivad hankelepingus kokku töö ja selle vahetulemuste (töö etappide) valmimise ja tellijale üleandmise, vastuvõtutestide läbiviimise ning tellija poolt vastuvõtmise tähtajad või ajakava. 7.3. Tarkvara kasutuse alguseks loetakse päev millal tellija tarkvara vastu võttis. 8. Tööde üleandmine, testimine ja vastuvõtmine 8.1. Töövõtja annab tellijale töö üle vastavalt raamlepingus ja pakkumuskutses sätestatud tingimustele. Üleantav tarkvara peab olema töövõtja poolt testitud. 8.2. Töö või selle etapi üleandmise eelduseks on töövõtja poolse testimise positiivne tulemus. Tellija võib töö ülevaatamisel kasutada kolmandaid isikuid. 8.3. Testimisele seatavad kriteeriumid lepitakse kokku projekti lähteülesandes või tellimuse ülesande püstitusega. 8.4. Testimise tehniline lahendus (sh automaat-testide skriptid) on dokumentatsiooni lahutamatu osa. 8.5. Töövõtja vastutab adekvaatse testandmestiku ning funktsionaalsete teststsenaariumite eest ning tellija ärivajaduste toimivuse eest. 8.6. Tarkvara vahetulemuse edukad testid ei ole tarkvara kui terviku vastuvõtmise aluseks. 8.7. Töö vahetulemuse üleandmine tellijale ei ole käsitatav selle vastuvõtmisena tellija poolt. 8.8. Pärast töö või selle etapi üleandmist töövõtja poolt on tellijal õigus töö üle vaadata, s.h uurida dokumente ja programmi lähtekoodi ning sooritada vastuvõtu test kokkulepitud aja jooksul (edaspidi testperiood). 8.9. Juhul, kui tellija testperioodi jooksul leiab, et töö ei ole tehtud vastavalt lepingu tingimustele või tarkvara ei vasta selle kirjeldusele, on tellija kohustatud teavitama töövõtjat töös (tarkvaras) avastatud puudustest, keeldumisest tööd enne puuduste kõrvaldamist vastu võtta ja kirjeldama töö puudused ning määrama mõistliku tähtaja nende kõrvaldamiseks. Töö puuduste kõrvaldamise kulud kannab töövõtja. 8.10. Vastuvõtmiseks valmis töö (tarkvara) peab vastama raamlepinguga, hankelepinguga ja seadusega sätestatud töövõtu tingimustele, tarkvara kirjeldusele ning pakkumuskutses esitatud nõuetele. Tarkvara vastuvõtu testi edukas sooritamine on tellija poolt tarkvara vastuvõtmise peamiseks, kuid mitte ainsaks eelduseks. 8.11. Töövõtja annab iga töö üleandmisel tellijale üle ka dokumendid, mis peavad vastama raamlepingus sätestatud nõuetele. 8.12. Tellija vaatab töö üle ja vajadusel esitab täitjale kirjalikult oma pretensioonid (edaspidi nimetatud vastuväited) seoses töö mittevastavusega lepingule 10 (kümne) tööpäeva jooksul pärast töö üleandmist. 8.13. Töö loetakse tellija poolt vastuvõetuks, kui tellija ei ole kirjalikult esitanud vastuväiteid punktis 8.12 nimetatud tähtaja jooksul ning pooled on allkirjastanud töö üleandmise-vastuvõtmise akti. 8.14. Juhul, kui tellija esitab oma vastuväited, peab töövõtja tegema töös parandused tellija määratud tähtaja jooksul. Sellisel juhul loetakse töö vastu võetuks, kui täitja on teinud töös parandused ja tellijal ei ole enam vastuväiteid ning pooled on allkirjastanud töö üleandmise- vastuvõtmise akti. 8.15. Üleandmise-vastuvõtmise akt peab sisaldama kokkuvõtete tehtud tööst sh testimise tulemustest, lepingu täitmise käigus kokku lepitud muudatusi töös ning tööga kaasneva väljamakse summat koos käibemaksuga. Üleandmise-vastuvõtmise aktis peavad olema toodud välja loovutatavad või litsentseeritavad autoriõigused. 8.16. Juhul, kui töös esineb puudusi mis ei takista kogu töö vastu võtmist tuleb puudused aktis fikseerida koos tähtajaga puuduste kõrvaldamisele. Sellisel juhul hakkab töö garantiiaeg kehtima pärast parandatud töö üleandmist. 8.17. Töövõtjal ei ole õigus nõuda tasu enne töö üleandmise-vastuvõtmise akti allkirjastamist. 8.18. Töö juhusliku hävimise või kahjustumise risk läheb tellijale üle pärast lõplikku üleandmise- vastuvõtmise akti allkirjastamist. 8.19. Töövõtja annab iga kord koos valmis tööga üle tarkvara lähtekoodi. 9. Intellektuaalne omand ja autoriõigused 9.1. Töövõtja tagab, et lepingu täitmiseks kasutatavate intellektuaalse omandi objektide suhtes ei ole kolmandatel isikutel nõudeid ega patenditaotlusi, registreeritud kasulikke mudeleid või registreeritud tööstusdisainilahendusi, samuti ei ole vaidlustatud tarkvaraga seotud leiutiste patente. Töövõtja vastutab kõigi töö üleandmiseks ning otstarbekohaseks kasutamiseks vajalike autoriõiguste olemasolu, kasutatavuse ja loovutatavuse eest. 9.2. Töövõtja kinnitab ja vastutab, et tarkvara ettenähtud kasutamisel tellija poolt ei rikuta kolmandate isikute autoriõigusi ega muid intellektuaalomandi õigusi. 9.3. Töövõtja tagab, et ta on võtnud tarvitusele kõik meetmed autorite isiklike õiguste realiseerimiseks viisil, mis ei takista ega raskenda töö tulemusena valminud tarkvara ettenähtud kasutamist ja autori varaliste õiguste teostamist tellija poolt. 9.4. Töövõtja võib tarkvara loomisel kasutada järgnevaid komponente: 9.4.1. Üleantav tarkvara (või tarkvara üleantavad komponendid) – töövõtja loovutab kõik varalised autoriõigused tarkvarale tervikuna (või selle teatavatele osadele) tellijale. 9.4.2. Jagatav tarkvara (või komponendid) – töövõtja annab kõik varalised autoriõigused (või osa neist) tellijale ja jätab samad õigused ka endale. Jagatavate õiguste sisu ja maht tuleb pakkumuses selgelt määratleda. 9.4.3. Litsentseeritav tarkvara (või komponendid) – töövõtja annab tellijale enda loodud tarkvara suhtes litsentsi. 9.4.4. All-litsentseeritavad tarkvara komponendid – kolmandate isikute loodud tarkvara, mida töövõtja kasutab tarkvara koosseisus. 9.4.5. Vaba tarkvara (või vabatarkvaralised komponendid), nt GNU, GPL või EUPL alusel) v.a juhul kui vaba tarkvara komponendi kasutamine muudab loodava tarkvara kui kogumikteose tervikuna vabaks tarkvaraks. 9.5. Pooled lepivad kokku, et hankelepingu alusel töö tulemusena loodud tarkvara kui terviku (kogumikteose) autori varalised õigused kuuluvad tellijale. Töövõtja ei tohi hankelepingu alusel loodud tarkvara kui terviku lähtekoodi kopeerida, müüa või muul moel kasutada v.a tellija tellimusel tarkvara edasiarendamiseks või hooldamiseks. 9.6. Pooled lepivad kokku, et tarkvara kui terviku osadeks olevaid komponente, mille autoriõiguste osas on töövõtja tellijale andnud kasutusõiguse (punktid 9.4.3-9.4.5) või jaganud autori varalisi õigus tellijaga (punkt 9.4.2), võib töövõtja taaskasutada. 9.7. Tarkvara üleandmisega tellijale annab töövõtja ühtlasi esialgse litsentsi (loa) kasutada tarkvara sellisel viisil ja tähtajal, mis on vajalik tarkvara testimise, vastuvõtmise ja juurutamise ettevalmistamiseks. 9.8. Tarkvara vastuvõtmisel tellija poolt töövõtja loovutab, jagab või annab tellijale kõik õigused ja kasutusload tarkvara komponentidele, mis on nimetatud punktis 9.4.3-9.4.5. 9.9. Tellijal on õigus kasutada tarkvara raamlepingus ja hankelepingus sätestatud ja piiritletud tingimustel, ulatuses ja korras kõigis Eesti Vabariigi riigiasutustes (ministeeriumid, ametid, inspektsioonid, riigi poolt asutatud avalikke ülesandeid täitvad sihtasutused, avalik-õiguslikud juriidilised isikud). Sealhulgas on tellijal õigus anda tarkvara lähtekoodi kasutamiseks ja edasiarendamiseks teistele Eesti Vabariigi riigiasutustele. 9.10. Tellija võib arendada tarkvara ise või anda arendada kolmandatele isikutele. Tarkvara on all- litsentseeritav kogu avalikus sektoris. 9.11. Tarkvara ja selle komponentide kasutamise (kasutajate hulk, töökeskkond, kasutusviisid, arendusviisid jne) või levitamise viisid ei ole piiratud. 9.12. Tellijal on oma kohustuste nõuetekohasel täitmisel 99 aastane tarkvara kasutusõigus. 9.13. Tellija poolt omandatud tarkvara kõigi autoriõiguste ja kasutuslubade (litsentside) kehtivuse territoorium on Euroopa Liit ja Euroopa Majanduspiirkond. 9.14. Tarkvara autoriõiguste ja kasutuslubade (litsentside) tellijale andmise tunnistuseks on raamleping, hankeleping ja tellimuskiri koos nende täitmist kinnitavate dokumentidega. 9.15. Omandiõigus töö/tarkvara materiaalsetele andmekandjatele, mille vahendusel tellijale edastatakse tarkvara või selle komponendid, lähtekood ja dokumentatsioon, samuti tarkvara loomise lähte- või vahetulemused, lähevad üle pärast tellijale töö/tarkvara üleandmise-vastuvõtmise akti mõlema poole poolt allkirjastamist. 10. Tööde maksumus ja maksmise kord 10.1. Töö/tarkvara hind (arendustöö tunni maksumus 40.- eurot ilma käibemaksuta) on kindlaks määratud kogu raamlepingu kehtivuse ajaks. Tellija tellib töid vastavalt tehnilises kirjelduses märgitud tööde spetsifikatsioonile orienteeruvalt 400 000.- (ilma käibemaksuta) euro ulatuses lepingu perioodil. Tellija ei garanteeri nimetatud mahus Tööde tellimist. 10.2. Töövõtja ei või raamlepingus määratud hinnast kõrgemat hinda pakkuda. 10.3. Raamlepingu alusel esitatavate pakkumuste hind võib olla väiksem raamlepingus määratud hinnast. 10.4. Töö/tarkvara hinnas (raamlepingu alusel makstavates tasudes) sisalduvad kõik autoritasud ja litsentsitasud. 10.5. Raamlepingust tulenevate maksete laekumise kohaks on arvel näidatud arvelduskonto. 10.6. Töö/tarkvara eest tasutakse hiljemalt 21 (kahekümne ühe) kalendripäeva jooksul pärast asjakohase üleandmise-vastuvõtmise akti allkirjastamist ning nõuetekohase arve kättesaamist. 10.7. Hankelepingus määratud hind on töövõtja ainuke tasu seoses hankelepinguga, see ei ole seatud sõltuvusse inflatsioonist või muudest teguritest ning seda võib muuta üksnes poolte kirjaliku kokkuleppega. 11. Garantii ja pretensioonid 11.1. Töövõtja garanteerib töö vastavuse lepinguga ja seadusega sätestatud töövõtu tingimustele, tarkvara kirjeldusele ning tellija põhitegevuse tavapärastele ja mõistlikele nõuetele kokkulepitud aja jooksul pärast tarkvara vastuvõtmist tellija poolt (edaspidi garantii ja garantiiaeg). 11.2. Raamlepingu kestel hankelepingute ja tellimuste alusel tehtavatele tööle/tarkvarale või teenustele kehtib töövõtja garantii 24 (kakskümmend neli) kuud, mis rakendub töö/tarkvara vastuvõtmisest. 11.3. Garantii korras vea parandamine hõlmab kõigi tarkvara osade, sealhulgas abistava dokumentatsiooni parandamist või muutmist. 11.4. Pooled lepivad vastavalt pakkumuskutsele hankelepingu sõlmimisel kokku, kas garantii laieneb või ei laiene tarkvara koosseisus kolmandatelt isikutelt eraldi litsentseeritavatele arvutiprogrammidele või andmebaasidele. 11.5. Tellijal on õigus garantiiajal teha tarkvaras, ise või kolmandate isikute abil muudatusi ilma töövõtja eelneva kirjaliku loata juhul kui töövõtja ei ole nõuetekohaselt täitnud tellimusi või hankelepinguid. Sellisel juhul muutmata tarkvara osadele garantii ei lõppe. 11.6. Tellija teavitab töövõtjat töös esinevatest vigadest kirjalikku taasesitamist võimaldavas vormis. 11.7. Garantiiajal kõrvaldab töövõtja kõik vead omal kulul punktis 11.9 sätestatud tähtaegade jooksul. Juhul, kui vigade tekkimine on põhjustatud tellija süülisest tegevusest, tasub parandamisega seotud kulud tellija. 11.8. Tarkvara töös eristatakse kolme tüüpi vigu: 11.8.1. Kriitiline viga – tarkvara kasutamine ettenähtud tööks on takistatud, muuhulgas, ent mitte ainult, tarkvara seiskumise või häirivate vigade ebamõistliku sageduse tõttu; 11.8.2. Häiriv viga – tarkvara saab kasutada ettenähtud tööks, kuid veaolukorra vältimine või ületamine nõuab töötajatelt lisaks tööülesannete täitmisele täiendavaid toiminguid või pingutust; 11.8.3. Pisiviga – ilming või kõrvaltoime tarkvara töös, mis ei takista ettenähtud töö tegemist ja puudutab tarkvara üksikuid kasutajaid, kuid ei ole täielikult eiratav. 11.9. Kui tellija pretensioonis kirjeldatud puudus on kaetud garantiiga, kõrvaldab töövõtja selle puuduse enda kulul: 11.9.1. Kriitilise vea korra kokkuleppel tellijaga kiireima mõistliku aja jooksul; 11.9.2. Häiriva vea korral 10 (kümne) tööpäeva jooksul kui pooled ei lepi kokku teisiti; 11.9.3. Pisivea korral 10 (kümne) tööpäeva jooksul või kokkuleppel tellijaga pikema mõistliku aja jooksul. 11.10. Garantiitingimused laienevad ka nendele juhtumitele, kui tarkvara kasutamine tellija poolt on takistatud kolmandate isikute autoriõigustest või nende rikkumisest tulenevate nõuete tõttu. Sellisel juhul on töövõtja kohustatud samadel tingimustel, nagu tehniliste vigade parandamisel, kõrvaldama tarkvara kasutamise õiguslikud takistused. Käesolev säte ei piira autoriõiguste rikkumisest tulenevat töövõtja muud vastutust. 12. Konfidentsiaalsuskohustus 12.1. Raamlepingu alusel saadud teave on konfidentsiaalne ega kuulu avaldamisele kolmandatele isikutele. Raamlepinguga seonduva konfidentsiaalse informatsiooni avaldamine kolmandatele isikutele on lubatud vaid teise poole eelneval kirjalikul nõusolekul. Lepingus sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele juhtudel, kui pool on õigusaktidest tulenevalt kohustatud informatsiooni avaldama. Pool on kohustatud enne info avalikustamist sellest tellijat kirjalikult informeerima. Töövõtja on teadlik, et raamleping on avalik, v.a osades, mis on märgitud avaliku teabe seadusest tulenevatel alustel asutusesiseseks kasutamiseks. 12.2. Töövõtja kohustub sõlmima konfidentsiaalsuskokkuleppe töötajate või alltöövõtjatega, kes tööde tegemisel puutuvad kokku tellija andmeturvet, riigisaladust või isikuandmeid puudutavate andmetega. 12.3. Tellijal on õigus nõuda töövõtja töötajaga või alltöövõtjaga sõlmitud konfidentsiaalsuskokkuleppe esitamist. 12.4. Konfidentsiaalsuskohustuse rikkumist loetakse raamlepingu või hankelepingu oluliseks rikkumiseks. 12.5. Töövõtja ei tegele raamlepingu ja hankelepinguga seoses avalike suhetega ega anna teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija eelneval kirjalikul nõusolekul. Avaldada võib vaid teateid, mis on tellijaga eelnevalt kooskõlastatud. 12.6. Raamlepingust tulenev konfidentsiaalsuskohustus on tähtajatu, kui õigusaktidest ei tulene teisiti. 13. Vääramatu jõud 13.1. Pooled vastutavad raamlepingust ja hankelepingust tulenevate kohustuste rikkumise eest, välja arvatud, kui rikkumine on vabandatav. Kohustuse rikkumine on vabandatav, kui pool rikkus kohustust vääramatu jõu tõttu. 13.2. Raamlepingust ja hankelepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta raamlepingu või hankelepingu rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatu jõuna käsitavad pooled võlaõigusseaduse §-s 103 lõikes 2 nimetatud asjaolusid. Pool, kelle tegevus lepingujärgsete kohustuste täitmisel on takistatud vääramatu jõu asjaolude tõttu, on kohustatud sellest koheselt kirjalikult teatama teisele poolele. Vääramatu jõu asjaolude ilmnemisel pikeneb hankelepingu lõpptähtaeg nimetatud asjaolude esinemise perioodi võrra. Pool peab vääramatu jõu asjaolude äralangemisel raamlepingut ja hankelepingut täitma asuma. Kui vääramatu jõu asjaolude tõttu on Poole raamlepingust ja hankelepingust tulenevate kohustuste täitmine takistatud enam kui 2 (kahe) kalendrikuu jooksul, võivad pooled hankelepingu lõpetada. 14. Vastutus ja sanktsioonid 14.1. Kui tellija viivitab arvete tasumisega, on töövõtjal õigus nõuda tellijalt viivist 0,15% päevas iga maksmisega viivitatud tööpäeva eest. 14.2. Raamlepingus või hankelepingus sätestatud nõuete rikkumise korral on tellijal õigus nõuda töövõtjalt leppetrahvi kuni 5000 (viis tuhat) eurot. 14.3. Konfidentsiaalsusnõude rikkumisel on tellijal õigus nõuda leppetrahvi kuni 20 000 (kakskümmend tuhat) eurot. 14.4. Garantiitingimuste rikkumise korral on tellijal õigus nõuda töövõtjalt leppetrahvi kuni 30% hankelepingu hinnast iga juhtumi korral. 14.5. Juhul kui töövõtja ei anna tööd/tarkvara tellijale üle punktis sätestatud tähtajaks või viivitab puuduste kõrvaldamisega, kohustub töövõtja maksma tellijale leppetrahvi 0,15% lepingu hinnast iga üleandmise või puuduste kõrvaldamisega viivitatud päeva eest. 14.6. Puuduste korral töös/tarkvaras on tellijal õigus võtta töö/tarkvara osaliselt vastu ja tasuda selle osa eest. Sellisel juhul esitab tellija töö/tarkvara hinna alandamise avalduse, milles määrab kindlaks, milliseid autoriõigusi või kasutuslube ta soovib töö/tarkvara edasiseks arendamiseks ja kasutamiseks. 14.7. Leppetrahvi tasumine ei vabasta töövõtjat raamlepingu või hankelepinguga seotud kohustuste täitmisest. 14.8. Kui töö ei vasta töö/tarkvara kirjelduse või lepingu ja seadusega sätestatud töövõtutingimustele või ei läbi vastuvõtutesti või kui töö/tarkvara toimimine ei vasta tellija põhitegevuse tavapärastele ja mõistlikele nõuetele, mis tähendab, et tellija ei saa töö/tarkvara tulemusena ettenähtud omadustega tööd või tarkvara, on tellijal õigus nõuda töö/tarkvara puuduste kõrvaldamist lepingus ettenähtud tähtaja jooksul, esitades töövõtjale puudusi võimalikult täpselt kirjeldava vastuväite. 14.9. Tellijal on õigus raamleping ühepoolselt ette teatamata üles öelda, kui töövõtja on oluliselt rikkunud tellijaga sõlmitud raamlepingut või hankelepingut. Sealhulgas loetakse raamlepingu oluliseks rikkumiseks korduvat (vähemalt kolm korda) põhjendamatut keeldumist pakkumuse esitamisest ja konfidentsiaalsuskohustuse täitmata jätmist. 14.10. Töövõtja pakkumust ei arvestata ja töövõtjaga ei sõlmita käesoleva raamlepingu alusel uusi hankelepinguid olukorras, kus töövõtja ei ole käesoleva raamlepingu alusel sõlmitud kehtivaid hankelepinguid täitnud nõuetekohaselt. 15. Pooltevahelised teated ja kontaktisikud 15.1. Teadete edastamine toimub üldjuhul telefoni, e-posti või posti teel. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated olema edastatud kirjalikku taasesitamist võimaldavas vormis (s.o kirjalikus vormis või e-posti teel). Informatiivset teadet võib edastada ka telefoni teel. Teate edastamise hetkeks loetakse elektronkirja tehniliselt tõendatud saatmise hetk või kirjaliku teate allkirjaga tõendatud vastuvõtmise hetk. 15.2. Tellija kontaktisikud on: 15.2.1. Artur Novek, [email protected] , tel. 694 3943 15.2.3. Tellija volitatud esindajal on õigus esindada tellijat kõikides lepinguga seotud küsimustes, v.a lepingu muutmine, lepingu ühepoolne lõpetamine ning leppetrahvi, või kahjude hüvitamise nõude esitamine. Juhul kui tellija volitatud esindaja on ajutiselt teenistusest eemal või lahkunud, loetakse tellija volitatud esindajaks mõni muu tellija esindaja. Kui tellija ei ole töövõtjale teatanud volitatud esindaja ajutisest teenistusest eemal viibimisest ja määranud selleks ajaks asendajat, täidab volitatud isiku ülesandeid osakonnajuhataja. 15.3. Töövõtja kontaktisik on: 15.3.1. Margus Jäger, [email protected]; tel. 5011 358 15.4. Kontaktisiku(te) muutumisest tuleb teist poolt kirjalikult teavitada 5 (viie) kalendripäeva jooksul. Kontaktisikute ajutisest eemal viibimisest ning nende asendajatest tuleb teist poolt teavitada 3 (kolme) kalendripäeva jooksul. 15.5. Kontaktisikud võivad omavahel kokku leppida omavahelise teadete edastamise korra, mis vormistatakse kirjalikult raamlepingu lisana. 16. Lepingu kehtivus 16.1. Käesolev raamleping sõlmitakse tagasiulatuvalt alates 07.01.2017. Raamleping jõustub selle allkirjastamisest poolte poolt ja kehtib kolm aastat alates kuupäevast 07.01.2017. Raamleping on koostatud eesti keeles ja allkirjastatud digitaalselt. 16.2. Hankelepingu kehtivus ei ole piiratud raamlepingu kehtivuse lõpptähtpäevaga. 16.3. Raamlepingu ülesütlemine poole poolt ei muuda automaatselt kehtetuks selle alusel varem sõlmitud hankelepinguid. 16.4. Raamlepingu või hankelepingu mõne sätte kehtetuks tunnistamine kohtu või mõne muu pädeva ametiasutuse poolt ei muuda kehtetuks ülejäänud lepingut. 17. Raamlepingu muutmine 17.1. Raamlepingut või hankelepingut võib muuta ainult poolte vahelise kirjaliku kokkuleppega. 17.2. Raamlepingu muutmises võivad kõik pooled ühiselt kokku leppida üksnes juhul, kui muutmise tingivad objektiivsed asjaolud, mida ei olnud pooltel võimalik raamlepingu sõlmimise ajal ette näha ja lepingu muutmata jätmise korral satuks täielikult või olulises osas ohtu raamlepinguga taotletud eesmärgi saavutamine. 17.3. Hankelepingu muutmises võivad pooled kokku leppida üksnes juhul, kui muutmise tingivad objektiivsed asjaolud, mida ei olnud pooltel võimalik hankelepingu sõlmimise ajal ette näha ja lepingu muutmata jätmise korral satuks täielikult või olulises osas ohtu hankelepinguga taotletud eesmärgi saavutamine. 17.4. Raamlepingu või hankelepingu muudatused jõustuvad pärast allakirjutamist poolte poolt või poolte poolt määratud tähtajal. Kirjaliku vormi mittejärgimisel on muudatused tühised. 17.5. Raamlepingu muutmine ei mõjuta sõlmitud hankelepingu tingimusi. 18. Raamlepingu lisad 18.1. Raamleping koosneb lepingu põhiosast ja selle lisadest (sh tellimiskirjad, tellimuse üleandmise- vastuvõtmise akt). 18.2. Raamlepinguga samaaegselt allkirjastatavad lisad on: 18.2.1. Lisa 1. Hankelepingu kavand; 18.2.2. Lisa 2. Tehniline kirjeldus; 18.2.3. Lisa 3. Kodukord; 18.2.4. Lisa 4. Hinnapakkumus.  18.2.4. Lisa 5. Pakkumuse jõusoleku pikendamise avaldus. 19. Lõppsätted 19.1. Töövõtjal ei ole õigust ilma tellija nõusolekuta üle anda raamlepingut või sellest tulenevaid kohustusi kolmandatele isikutele. 19.2. Raamlepinguga või hankelepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju Maakohtule. Raamlepingule kohaldatakse Eesti õigust. Poolte allkirjad: Tellija: Töövõtja: (Allkirjastatud digitaalselt) (Allkirjastatud digitaalselt) Katrin Reinhold Margus Jäger Tervise ja Heaolu Infosüsteemide Keskus Quretec OÜ registrikood 70009770 registrikood 11043739 Uus-Tatari 25/Veerenni 13 Ülikooli 6a Tallinn Tartu  Lisa 1. Hankelepingu kavand HANKELEPING nr , (registrikoodiga ) asukohaga , keda põhimääruse alusel esindab (edaspidi tellija), ja , registrikood , aadressiga , keda esindab alusel (edaspidi töö saaja), , registrikood , aadressiga , keda esindab alusel (edaspidi töövõtja), edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr ... alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas. 1. Lepingu ese 1.1 Lepingu esemeks on lisas 1 „Hankelepingu eseme tehniline kirjeldus“ nimetatud tööd koos garantiiteenustega (edaspidi töö). 2. Lepingu hind 2.1 Tellija kohustub tasuma töö eest kokku eurot koos käibemaksuga 30 (kolmekümne) tööpäeva jooksul arvates arve saamisest. 2.2 Töövõtja esitab tellijale arve pärast töö/ tarkvara üleandmise-vastuvõtmise akti allkirjastamist. 3. Töö üleandmise ja vastuvõtmise tingimused 3.1 Töövõtja annab töö üle 3.2 Töö tegemise täpne ajakava lepitakse kokku Töö tellimise käigus vastavalt agiilse arendusmeetodile ja fikseeritakse Tellija poolt nimetatud Tööülesannete halduskeskkonnas Jira. Täitjal on kohustus sisestada tööajaarvestus Tellija arenduskeskkonnas Jira (Tempo Timesheets) iga tööpäeva lõpuks. Tööajaarvestust peetakse kõikide meeskonnaliikmete osas. 3.3 Tähtajad Tööga seotud Tarnete üleandmiseks lepitakse kokku Töö tellimise käigus ja fikseeritakse kirjalikult ajakavas Tööülesannete halduskeskkonnas. 3.4 Tellija vaatab töö/ tarkvara üle vastavalt raamlepingule. 4. Poolte vastutus 4.1 Juhul kui tellija ei tasu üleantud töö/ tarkvara eest tähtaegselt, on töövõtjal õigus nõuda tellijalt viivise tasumist suuruses 0,15% iga tasumisega viivitatud päeva eest tähtajaks tasumata summalt. 4.2 Juhul kui töövõtja ei annatööd/ tarkvara tellijale üle punktis sätestatud tähtajaks või viivitab puuduste kõrvaldamisega, kohustub töövõtja maksma tellijale leppetrahvi 0,15% lepingu hinnast (lepingu punkt ...) iga üleandmise või puuduste kõrvaldamisega viivitatud päeva eest. 4.3 Garantiitingimuste rikkumise korral on tellijal õigus nõuda töövõtjalt leppetrahvi kuni 30% lepingu hinnast iga juhtumi korral.  4.4 Lepingust tulenevate viiviste ja leppetrahvide maksmine, samuti tekitatud kahju hüvitamine ei vabasta lepingut rikkunud poolt mistahes lepingujärgsete kohustuste täitmisest. 5. Poolte vahelised teated ja kontaktisikud 5.1 Teadete edastamine toimub üldjuhul telefoni, e-posti, või posti teel. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peavad teisele poolele edastatavad teated olema edastatud taasesitamist võimaldavas vormis (s.o kirjalikus vormis või e-posti teel). Informatiivset teadet võib edastada ka telefoni teel. 5.2 Teate edastamise hetkeks loetakse elektronkirja tehniliselt tõendatud saatmise hetk või kirjaliku teate allkirjaga tõendatud vastuvõtmise hetk. 5.3 Tellija kontaktisikuks lepingu täitmisel on tel , e-post: . 5.4 Teenuse saaja kontaktisikuks lepingu täitmisel on tel , e-post: . 5.5 Töövõtja kontaktisikuks lepingu täitmisel on , tel e-post: . 6. Lepingu kehtivus 6.1 Leping on koostatud eesti keeles ja allkirjastatud digitaalselt. 6.2 Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni. 7. Lõppsätted 7.1 Lepingu täitmisel tekkinud vaidlused ja lahkarvamused lahendavad pooled läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlused Harju Maakohtus. 7.2 Lepingu täitmisel ja lepingust tulenevate vaidluste lahendamisel lähtutakse Eesti Vabariigi õigusaktidest. 7.3 Pooled ei tohi lepingust tulenevaid õigusi ja kohustusi üle anda kolmandatele isikutele ilma teise poole kirjaliku nõusolekuta. 7.4 Lepingu dokumendid koosnevad käesolevast lepingust, lepingu lisadest ning lepingu muudatustest, milles pooled võivad kokku leppida lepingu allakirjutamise järgselt. 7.5 Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid: 7.5.1 Lisa 1. Hankelepingu eseme tehniline kirjeldus; 7.5.2 Lisa 2. Pakkumus. 8. Poolte allkirjad: Tellija: Teenuse saaja: Töövõtja: (allkirjastatud digitaalselt) (allkirjastatud digitaalselt) (allkirjastatud digitaalselt)  Lisa 1 Nõuded infosüsteemi dokumentatsioonile Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele: Andmemudel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem - > Andmemudel) Eeldus Teenuste/kasutuslugude dokumentatsioon dokumendile: Otstarve: Kirjeldada andmeobjekte ja nendevahelisi seoseid Sisu: Andmebaasi põhjal luua andmetabelite ja -objektide seosdiagramm. Sihtgrupp: Tellija, peakasutajad, rakenduse administraatorid Ajakava: enne esimese arendusetapi enne igat igakordsel algust arendusetapi algust üleandmisel Kirjeldada andmemudelit jah jah kontseptuaalse mudelina interaktioone/seoseid Kasutaja õiguste ja tegevuste vastavustabel (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Kasutaja õiguste ja tegevuste vastavustabel) Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldada kasutaja rollide õigusi erinevates kasutuslugudes ja tegevustes Sisu: CRUD maatriks Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja  edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese enne igat arendusetapi igakordsel arendusetapi algust algust üleandmisel Nimetada kasutaja rollid jah jah Teenuste/kasutuslugude dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Teenused ja kasutuslood) Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Kirjeldab detailselt üleantavaid teenuseid/kasutuslugusid. Sisu: Teenuste/kasutuslugude detailse kirjelduse sisuks on: • Infosüsteemi kasutusloo/andmevahetuse teenusepõhised nõuded (ärinõuded ja neile vastavad detailsed funktsionaalsuse nõuded); • Tehnilised parameetrid; • Veateated/Hoiatused; • Teostatavad kontrollid; • Funktsionaalsuse enda põhiprotsess ja mõned sagedamini esinevad alternatiivsed protsessid (vastavalt vajadusele); • Üldine kirjeldus, kuidas ja kus kajastub antud teenus/kasutuslugu tervikprotsessis; • Nõudeid ja reegleid toetavad (sisu mõistmisele kaasaaitavad) pildid, diagrammid, tabelid, loendid • Andmevahetuse teenuste kirjeldus (andmete küsimine/vastuvõtmine, turvalisus, teenuse andmestik, klassifikaatorid, xml/xsd schema ) Sihtgrupp: Tellija äriprotsesse valdavad kontaktisikud, ärianalüütikud, süsteemianalüütikud, täitjast sõltumatud tarkvara hooldajad, arendajad ja edasiarendajad, testijad, arhitektid, projektijuhid. Ajakava: enne esimese enne igat arendusetapi igakordsel arendusetapi algust algust üleandmisel Nimetada kasutuslood jah jah  Arhitektuuridokument (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Arhitektuur) Eeldus Süsteemi üldine kirjeldus dokumendile: Otstarve: Dokumendi eesmärgiks on kirjeldada loodava süsteemi üldist ehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise korda. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest. Sisu: Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid (Arhitektuuridokumendimall_v1.1): 1. topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms) 2. Nõuded arhitektuurile (operatsioonisüsteem, andmebaasid, liidestused, rakendusserverid, raamistikud, teenused) 3. Nõuded käideldavusele (süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, kättesaadavus, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms) 4. liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest. Liideste kirjeldused/otstarve 5. süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub X teenuse poole) 6. kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks  Document Sihtgrupp: Arhitekt, administraator, turvaspetsialist Ajakava: enne esimese enne igat arendusetapi igakordsel arendusetapi algust algust üleandmisel Dokumendi esialgne jah versioon Seadmete ja tarkvara kasutajakesksed juhendid (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> -> Seadmete ja tarkvara kasutajakesksed juhendid) Eeldus Teenuste/kasutuslugude dokumentatsioon dokumendile: Otstarve: Teenuse funktsionaalsuse kasutamiseks ja kasutuslugude läbimiseks vajalikud juhised Sisu: Igale esitluskihile peab olema koostatud eraldi kasutusjuhend, mis kirjeldab vastava komponendi funktsionaalsuse kasutusvoo põhiselt. Kirjeldus tarkvara ja seadmete kasutamise üldisest protsessist, protsessi olulisemate sammude kirjeldus. Koostatakse projekti lähteanalüüsi aluseks võttes. Tarkvara kasutusjuhend on aluseks kasutajate koolitamisel. Kasutajajuhend kirjeldab kõiki kasutajate funktsionaalsusi koos tööprotsesside kirjeldusega ning ekraanipiltide vormis näidetega. Haldusliidese kasutusjuhend (peakasutaja ja rakenduse administraatori funktsionaalsus) peab olema eraldi tavakasutaja kasutusjuhendist.  Esitluskihi kasutusjuhendi minimaalne ülesehitus:  lühitutvustus  üldine kirjeldus koos komponentidega  autentimine (kui eksisteerib)  komponentide detailne kirjeldus koos kõikide funktsionaalsustega  Rollide kirjeldus ja õigused Sihtgrupp: Tarkvara kasutajad, peakasutaja, rakenduse administraator Ajakava: enne esimese enne igat arendusetapi igakordsel arendusetapi algust algust üleandmisel jah Paigalduse ja administreerimise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Paigalduse ja administreerimise juhend) Eeldus Arhitektuuridokument dokumendile: Süsteemi üldine kirjeldus Otstarve: Juhend on aluseks süsteemi administreerimisele Sisu: Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid. Konfiguratsioonifailide kirjeldus koos asukohtadega failisüsteemis; 2. logimise realisatsiooni kirjeldused (kuhu, mida, logide struktuur 3. rutiinsete hooldusprotseduuride kirjeldus (komponentide taaskäivituse vajadus parameetrite muutmisel); 4. paigaldamise protseduurid. Juhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldamise protseduurid peavad olema kirjutatud selliselt (samm sammult), et süsteemiadministraator suudab rakenduse paigaldada ilma kõrvalise abita. 4.1 Nõuded rakenduse komponentidele 4.2 Rakenduse paigaldus (Vajalik tarkvara ja konfigureerimine, rakenduse  pakkimine ja paigaldamine) 4.3 Andmete alglaadimine 4.4 Varundusskript 4.5 Monitooringu kirjeldus Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator Ajakava: enne esimese enne igat arendusetapi igakordsel arendusetapi algust algust üleandmisel jah Lähtekood (sh andmebaasi struktuur) (Kuuluvus: Lähtekoodi üleandmine lepitakse kokku Tellijapoolse projektijuhiga) Eeldus Arhitektuuridokument dokumendile: Teenuste/kasutuslugude dokumentatsioon Andmemudel Kasutaja õiguste ja tegevuste vastavustabel Prototüüp Otstarve: Lähtekood on vajalik selleks et kompileerida rakendust, ning võimaldada tulevikus rakenduse muutmist. Sisu: Lähtekood peab olema hästi struktureeritud, piisavalt dokumenteeritud ning võimalikult lihtne, et sellest saaksid aru ka teised arendajad. Lähtekood peab vastama MFNile Lähtekood peab olema pakendatud vastavalt versioonimisjuhendile. Rakenduste lähtekood peab olema piisavalt modulaarne, et seda saaks tulevikus lihtsasti täiendada ning muuta. Ajakava: enne esimese enne igat arendusetapi igakordsel arendusetapi algust algust üleandmisel  Minimaalselt iga nädalal tagant uuendada versioonihalduskeskkonnas. Testide ettevalmistuse dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testiplaanid) Eeldus Teenuste/kasutuslugude dokumentatsioon dokumendile: Prototüüp (ainult kasutajaliidesega rakenduse puhul) Arhitektuuridokument Otstarve: Määrata kindlaks arendusetapil testitavad kasutuslood ja liidesed (sh välja tuua need, mille puhul rakendatakse koormusteste) tuues välja nende järjekorra. Sisu: Järjestatud (võib olla ka paralleelne) nimekiri kasutuslugudest ja liidestest (vajadusel määrates nende ulatust) koos märkega, mis on koormustestiga tagatud ning millel on testandmed Sihtgrupp: Tellijapoolne projektijuht, vastuvõtutestijad Ajakava: enne esimese arendusetapi enne igat igakordsel algust arendusetapi algust üleandmisel Nimetada kasutuslood, mille jah puhul rakendatakse koormusteste Testimise tulemite dokumentatsioon (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> Testimise tulemid) Eeldus Testide ettevalmistuse dokumentatsioon dokumendile: Otstarve: Anda tellijale ülevaade läbiviidud testimise tulemustest ning esitada soovitused testandmete ja dokumentatsiooni parendamiseks (ettevalmistus, paigaldus, kasutuslugude kirjeldus jne). Sisu: Teostatud arenduste testimisel saadud informatsioon (näiteks testlood,  testraport, testiplaan, testide kood jms). Peab vastama „Nõuded testimisele“ dokumendile. Dokumenteeritakse iga testimise eesmärgid (testimise maht ja ulatus), tegevused ja tulemused. Sisaldab jõudlus- ja mahutestide infot ning versiooni infot. Teste mitteläbinud testlugudele on lisatud parandused või ülesjäänud vead. MFNi vastavustabel Sihtgrupp: Arhitekt, süsteemiadministraator, turvaspetsialist Ajakava: enne esimese enne igat arendusetapi igakordsel arendusetapi algust algust üleandmisel jah Taasteplaani tegemise juhend (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon - > alamsüsteem -> Taasteplaani juhend) Otstarve: Kirjeldada erisused, millega tuleb arvestada taasteplaani loomisel Sisu: Taasteplaan peab rahuldama vähemalt alljärgnevaid sisunõudeid: 1. süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus; 2. varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid rakendusserverist ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid; 3. süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid Sihtgrupp: Süsteemiadministraator Ajakava: enne esimese arendusetapi enne igat arendusetapi igakordsel algust algust üleandmisel jah Andmekogude semantiline kirjeldus ja andmekoosseis (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem -> [Loomise kuupäev YYYY-MM- DD]_[Tervise_infosüsteem_alamsüsteemi_nimi].owl; [Loomise kuupäev YYYY-MM- DD]_[Tervise_infosüsteem_alamsüsteemi_nimi].xmi ) Sisu: Andmekogu(de) semantiline kirjeldus masinloetaval kujul (OWL-formaadis) ja andmekoosseis (XMI-formaadis) vastavalt RIHA määrusega kehtestatud nõuetele ning infosüsteemi ontoloogiat kirjeldav dokument. Sihtgrupp: Tellija, tellijapoolne projektijuht Ajakava: enne esimese arendusetapi enne igat arendusetapi igakordsel algust algust üleandmisel Esitada viimasel etapil UML vaated (kuuluvus: [Tervise Infosüsteem] -> Infosüsteemi dokumentatsioon -> alamsüsteem - > [Tervise_infosüsteem_alamsüsteemi_nimi].eap) Otstarve: Protsessi, kasutuslugude, süsteemi arhitektuuri vaadete kaudu muuta süsteem läbipaistvamaks ja ülevaatlikumaks Sisu:  Loogiline vaade (Logical view) - komponendid, liidesed, rakenduskihi ja ärikihi loogika  Protsessi vaade (Process view) – jõudlus, skaleeritavus, läbilaskevõime  Rakendus vaade (Deployment diagram) – süsteemi topoloogia, kasutuselevõtmine, paigaldamine Sihtgrupp: Peakasutaja, projektijuht, süsteemiadministraator, arhitekt Ajakava: enne esimese arendusetapi enne igat arendusetapi igakordsel algust algust üleandmisel jah jah Üldised nõuded: Üleantav dokument peab sisaldama sisseviidud muudatusi nii, et on väljatoodud muutunud ja lisandunud osa (võrreldes viimati üleantuga)  Raamlepingu nr 1.8-2/7822 lisa I Asjaolud 1. Sotsiaalministeerium, registrikood 70001952, aadress Gonsiori 29, 15027 Tallinn, keda esindas põhimääruse alusel kantsler Marika Priske (raamlepingus tellija) ja Eesti E-tervise Sihtasutus registrikood 90009016, aadress Uus Tatari 25/Veerenni 13, 10134 Tallinn, keda esindas põhikirja alusel juhatuse liige Margus Auväärt (raamlepingus tellija) ning OÜ Aktors, registrikood 11333578 aadress A. H. Tammsaare tee 118d, Mustamäe linnaosa, Tallinn, keda põhikirja alusel esindab juhatuse liige Aleksander Reitsakas (raamlepingus töövõtja) sõlmisid 09.02.2017 riigihanke „Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine“ (riigihanke registreerimisnumber e- Riigihangete registris: 178741) hankeosas II esitatud pakkumuse alusel raamlepingu nr 1.8-2/7822 (edaspidi ka Leping). 2. Sotsiaalministeerium, keda esindas põhimääruse alusel kantsler Marika Priske andis 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga üle Sotsiaalministeeriumi valitsemisel oleva riigivara lepingu ja sellest tulenevad õigused ja kohustused „Raamleping Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuste teostamiseks“ nr 1.8-2/7822, mis sõlmiti 09.02.2017 OÜ- ga Aktors ja Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25/Veerenni 13, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold, võttis nimetatud lepingu 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga vastu. 3. Sotsiaalministeerium tema haldusalas tegutseva Tervise ja Heaolu Infosüsteemide Keskuse kaudu, keda esindas põhimääruse alusel kantsler Marika Priske ja Eesti E-tervise Sihtasutus, keda esindas põhikirja alusel juhatuse liige Margus Auväärt vahel 29.11.2016 sõlmitud ettevõtte üleandmise lepinguga nr 1.8-2/7755 kohustus Eesti E-tervise Sihtasutus üle andma ja Tervise ja Heaolu Infosüsteemide Keskus vastu võtma seisuga 01.01.2017 tervise infosüsteemi haldamise ja volitatud töötlejaks olemisega seotud Eesti E-tervise Sihtasutuse õigused ja kohustused, sh täitmisel olevad lepingud ning nimetatuist tulenevad õigused ja kohustused. II Ilmselge ebatäpsuse parandamine Lepingus 4. Eeltoodust tulenevalt Tervise ja Heaolu Infosüsteemide Keskus, keda esindab põhimääruse alusel direktor Katrin Reinhold (raamlepingus tellija) ja OÜ Aktors, keda põhikirja alusel esindab juhatuse liige Aleksander Reitsakas (raamlepingus töövõtja) sõlmivad käesoleva Lepingu muutmise lisa ilmselge ebatäpsuse parandamiseks järgmiselt.  5. Käesolevaks ajaks on selgunud, et 09.02.2017 poolte vahelt sõlmitud Lepingus esineb ilmselge ebatäpsus Lepingu summa fikseerimisel. E-Riigihangete registris välja kuulutatud riigihanke tingimuste alusel, milliseid silmas pidades on OÜ Aktors esitanud pakkumuse, kohustusid pooled sõlmima Lepingu eeldatava maksumusega 400 000 eurot. Poolte poolt allkirjastatud Lepingu punktis 10.1 on Lepingu orienteeruvaks mahuks märgitud ekslikult 600 000 eurot. 6. Käesoleva Lepingu lisaga muudavad pooled Lepingut tagamaks kooskõla e- Riigihangete registris välja kuulutatud riigihanke tingimustega järgnevalt: 6.1 tunnistada kehtetuks Lepingu punkt 10.1 ning 6.2 kehtestada Lepingu punkt 10.1 järgnevas sõnastuses: „10.1. Töö/tarkvara hind (arendustöö tunni maksumus 42.- eurot ilma käibemaksuta) on kindlaks määratud kogu raamlepingu kehtivuse ajaks. Tellija tellib töid vastavalt tehnilises kirjelduses märgitud tööde spetsifikatsioonile orienteeruvalt 400 000.- (ilma käibemaksuta) euro ulatuses lepingu perioodil. Tellija ei garanteeri nimetatud mahus Tööde tellimist.“ Poolte allkirjad: Tellija: Töövõtja: (Allkirjastatud digitaalselt) (Allkirjastatud digitaalselt) Katrin Reinhold Aleksander Reitsakas Tervise ja Heaolu Infosüsteemide Keskus OÜ Aktors registrikood 70009770 registrikood 11333578 Uus-Tatari 25/Veerenni 13 A.H. Tammsaare tee 118d Tallinn Tallinn  Raamlepingu nr 1.8-2/7823 lisa I Asjaolud 1. Sotsiaalministeerium, registrikood 70001952, aadress Gonsiori 29, 15027 Tallinn, keda esindas põhimääruse alusel kantsler Marika Priske (raamlepingus tellija) ja Eesti E-tervise Sihtasutus registrikood 90009016, aadress Uus Tatari 25/Veerenni 13, 10134 Tallinn, keda esindas põhikirja alusel juhatuse liige Margus Auväärt (raamlepingus tellija) ning HEISI IT OÜ registrikood 12765966 (ühispakkujaga OÜ IDAKOIDLIK registrikood 10293121), aadress Lõõtsa 2B, Tallinn, keda põhikirja alusel esindas juhatuse liige Raul Raudsepp (raamlepingus töövõtja) sõlmisid 11.01.2017 riigihanke „Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine“ (riigihanke registreerimisnumber e- Riigihangete registris: 178741) hankeosas II esitatud pakkumuse alusel raamlepingu nr 1.8-2/7823 (edaspidi ka Leping). 2. Sotsiaalministeerium, keda esindas põhimääruse alusel kantsler Marika Priske andis 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga üle Sotsiaalministeeriumi valitsemisel oleva riigivara lepingu ja sellest tulenevad õigused ja kohustused „Raamleping Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuste teostamiseks“ nr 1.8-2/7823, mis sõlmiti 11.01.2017 HEISI IT OÜ-ga ja Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Uus-Tatari 25/Veerenni 13, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold, võttis nimetatud lepingu 12.09.2017 Riigivara üleandmise-vastuvõtmise aktiga vastu. 3. Sotsiaalministeerium tema haldusalas tegutseva Tervise ja Heaolu Infosüsteemide Keskuse kaudu, keda esindas põhimääruse alusel kantsler Marika Priske ja Eesti E-tervise Sihtasutus, registrikood 90009016, aadress Uus Tatari 25/Veerenni 13, 10134 Tallinn, keda esindas põhikirja alusel juhatuse liige Margus Auväärt vahel 29.11.2016 sõlmitud ettevõtte üleandmise lepinguga nr 1.8-2/7755 kohustus Eesti E-tervise Sihtasutus üle andma ja Tervise ja Heaolu Infosüsteemide Keskus vastu võtma seisuga 01.01.2017 tervise infosüsteemi haldamise ja volitatud töötlejaks olemisega seotud Eesti E-tervise Sihtasutuse õigused ja kohustused, sh täitmisel olevad lepingud ning nimetatuist tulenevad õigused ja kohustused. II Ilmselge ebatäpsuse parandamine Lepingus 4. Eeltoodust tulenevalt Tervise ja Heaolu Infosüsteemide Keskus, keda esindab põhimääruse alusel direktor Katrin Reinhold (raamlepingus Tellija) ja HEISI IT OÜ (koos ühispakkujaga OÜ Idakoidlik), keda esindab põhikirja alusel juhatuse liige Raul Raudsepp (raamlepingus töövõtja) sõlmivad käesoleva Lepingu muutmise lisa ilmselge ebatäpsuse parandamiseks järgmiselt.  5. Käesolevaks ajaks on selgunud, et 11.01.2017 poolte vahelt sõlmitud Lepingus esineb ilmselge ebatäpsus Lepingu summa fikseerimisel. E-Riigihangete registris välja kuulutatud riigihanke tingimuste, milliseid silmas pidades on Heisi IT OÜ ja OÜ Idakoidlik esitanud ühispakkumuse, alusel kohustusid pooled sõlmima Lepingu eeldatava maksumusega 400 000 eurot. Poolte poolt allkirjastatud Lepingu punktis 10.1 on Lepingu orienteeruvaks mahuks märgitud ekslikult 600 000 eurot. 6. Käesoleva Lepingu lisaga muudetakse Lepingut tagamaks kooskõla e-Riigihangete registris välja kuulutatud riigihanke tingimustega järgnevalt: 6.1 tunnistada kehtetuks Lepingu punkt 10.1 ning 6.2 kehtestada Lepingu punkt 10.1 järgnevas sõnastuses: „10.1. Töö/tarkvara hind (arendustöö tunni maksumus 39,49.- eurot ilma käibemaksuta) on kindlaks määratud kogu raamlepingu kehtivuse ajaks. Tellija tellib töid vastavalt tehnilises kirjelduses märgitud tööde spetsifikatsioonile orienteeruvalt 400 000.- (ilma käibemaksuta) euro ulatuses lepingu perioodil. Tellija ei garanteeri nimetatud mahus Tööde tellimist.“ Poolte allkirjad: Tellija: Töövõtja: (Allkirjastatud digitaalselt) (Allkirjastatud digitaalselt) Katrin Reinhold Raul Raudsepp Tervise ja Heaolu Infosüsteemide Keskus HEISI IT OÜ registrikood 70009770 registrikood 12765966 Uus-Tatari 25/Veerenni 13 Lõõtsa 2B Tallinn Tallinn  Saatja: Kerli Lubja </O=SOTSIAALMINISTEERIUM/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=KERLI LUBJA7F7> Saaja: Annike Koorts Teema: HEISI FW: TIS II raamlepingu parandamise vajadus From: Raul Raudsepp - HEISI [mailto:[email protected]] Sent: Thursday, October 26, 2017 10:08 PM To: Hanked <[email protected]> Subject: Re: TIS II raamlepingu parandamise vajadus Tere, Kinnitame, et nõustume vastava lepingu lisa sõlmima. Terv, Raul Sent from my iPhone On 26 Oct 2017, at 12:58, Hanked <[email protected] <mailto:[email protected]> > wrote: Lugupeetud raamlepingu partner Tervise ja Heaolu Infosüsteemide Keskus (TEHIK) teavitab Teid, et Teiega sõlmitud raamlepingus on tuvastatud ilmselge ebatäpsus, mis vajab lepingu lisa vormistamise teel kõrvaldamist. Sotsiaalministeerium ja Eesti E-tervise SA viisid läbi ühishanke „Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine“ (viitenumber eRHR-s 178741). Riigihange oli jaotatud osadeks, osa I eeldatavaks maksumuseks oli seejuures 600 000 eurot ning osa II eeldatavaks maksumuseks 400 000 eurot. Nimetatud eeldatavaid maksumusi järgides on esitatud riigihangete registrile ühtlasi riigihanke aruanne raamlepingute sõlmimise kohta. Käesolevaks ajaks on selgunud, et ekslikult on sõlmitud raamlepingud vastupidiste summadega – st osa I eeldatava maksumusega 400 000 eurot ning osa II eeldatava maksumusega 600 000 eurot. Kuivõrd hankijal lasub kohustus sõlmida riigihanke menetluse järgselt lepingud vastavuses riigihangete registris välja kuulutatud hanke tingimustega, tuleb sõlmitud lepingute osas sõlmida lepingu lisa ning parandada viidatud ilmselge ebatäpsus ehk korrigeerida raamlepingute maksimaalne maht vastavaks riigihangete registris välja kuulutatud hanke tingimusega. Palume Teil käesolevale kirjale vastates kinnitada, et nõustute vastava lepingu lisa sõlmima, et RIA saaks jätkata projekti „e-Surmasündmus“ täistaotluse menetlemist, mille osas olete esitanud pakkumuse. TEHIK edastab Teile pärast kinnituse saamist kirjeldatud raamlepingu lisa, korrigeerimaks varasemalt välja toodud ebatäpsus raamlepingus. Kerli Lubja Jurist Tervise ja Heaolu Infosüsteemide Keskus [email protected] <mailto:[email protected]> Veerenni 13/Uus-Tatari 25, Tallinn MEMO Kellele: Kaire Põld Koopia: Marje Pihl, Meelis Kerbo Kellelt: Annike Koorts Kuupäev: 26.09.2017 Teema: Arstiportaali, Patsiendiportaali, KMT ja ASM arendustööde pakkumus otsustamiseks teadmiseks 1. Hankija esitas pakkumuse esitamise ettepaneku kolmele raamlepingu partnerile samaaegselt e-postiga 07.09.2017.Täpsustatud pakkumuse ettepanek esitati 15.09.2017. 2. Tähtajaks laekus 2 pakkumust elektroonilise kanali kaudu digitaalkonteineris digitaalselt allkirjastatult: Pakkuja Pakkumus KM-ta Pakkumus KM-ga Heisi IT OÜ, Raul 33 369,05 eurot 40 042,86 eurot Raudsepp (juhatuse liige) OÜ Quretec, Margus Jäger 82 080,00 eurot 98 496, 00 eurot (juhatuse liige) 3. Pakkumusete vastavuse kontroll pakkumuskutses ja raamlepingu hankes esitatud nõuetele: a. Heisi IT OÜ pakkumus vastab pakkumuskutses ja raamlepingus esitatud nõuetele. b. OÜ Quretec pakkumus vastab pakkumuskutses ja raamlepingus esitatud nõuetele. 4. Parima pakkumuse tuvastamine: Parimaks pakkumuseks osutus Heisi IT OÜ poolt esitatud pakkumus. Hankeleping sõlmitakse töö teostamiseks Heisi IT OÜ-ga peale Riigi Infosüsteemide Ameti kooskõlastuse saamist.  center 134 Lisa 1 T ehniline kirjeldus Eesmärk Projekti „e-Surmasündmus“ eesmärgiks on vabastada surnu lähedased surma registreerimise protseduurist. Arstiportaa li ( edaspidi AP) , Patsiendiportaali ( edaspidi PP) , Kiirabi M obiilse Töökoha MOBIIL ja Kiirabi Mobiilse Töökoha PC (edaspidi KMT ) ning K iirabi Analüüsi ja Statistika Mooduli ( edaspidi ASM) arendus ed on üks osa projekti raames tehtavatest töödest, mida rahastatakse struktuurtoetuse (projekti number 2014-2020.12.03.17-0180) vahenditest . Tellitava töö kirjeldus Teenuse peamiseks eesmärgiks on võimaldada AP-i ja KMT kaudu surma sündmuse andmete edastamist Tervise infosüsteemi ( edaspidi TIS) , AP -i kaudu surma põhjuste andmete edastamist TIS-i ning PP-i kaudu näha surma järgselt dokumente. Loodav uus teenus võimaldab: Arstiportaalis koostada, vaadata ja printida surmateatist, surma põhjuste teatist ja perinataalsurma põhjuse teatist; Arstiportaalis lisada epikriisile surma fakti; Kiirabi Mobiilse töökoha (MOBIIL ja PC) kaudu edastada kiirab ikaardiga surma fakti TIS-i; Surnu d isiku esindaja l P atsiendiportaalist näha surmatõendit , surma põhjuse teatist ja perinataalsurma põhjuse teatist ning eemaldada oma esindamise õigust . Arendustööde kestvus ja üle andmise ajakava Arendustööde eeldatavaks kestvuseks on kuni 7 kuud : eeldatav algusaeg on mai 2018 ja lõpptähtaeg on november 2018 (sh tellija poolt läbitud testim ine ja turvatestimine) . Tellitav töö teostatakse ja antakse tellijale üle neljas etapis : Etapp Töö nimetus Eeldatav algus Eeldatav lõpp I Analüüs 01.0 5 .2018 31.06.2018 II AP arendustöö 01.05 .2018 31.06.2018 II I KMT ja ASM-i arendustööd 01.05 .2018 31.08.2018 IV PP arendustöö 01.05 .2018 30.09.2018 Projekti eeldatav ajakava on järgmine: Projekti t egevus ed Eeldatav ajaplaan Ajakulu Tehniline standardimine oktoober-detsember 2017 3 kuud SPR-i arendus jaanuar-juuni 2018 6 kuud RR-i arendused* Jaanuar-juuni 2018 6 kuud TIS-i arendus jaanuar-juuli 2018 7 kuud Portaalide arendused m ai ** -november 2018 7 kuud (sh puhkused - 1 kuu) turvatestid juuni-november 2018 5 kuud ( sh puhkused - 1 kuu) TTO-de arendused * mai 2018-veebruar 2019 9 kuud (sh puhkused - 1 kuu) juurutus veebruar-mai 2019 3 kuud Live-i minek 01.07 .2019 *-kolmanda osapoole tööd, mis on projekti jaoks vajalikud, kuid ei rahastata SF-st **-võib alustada varem, kuid mitte enne tehnilise standardimise lõppu Tööde teostamiseks vajalik informatsioon ja nõuded Töö tellitakse ja tarne toimub neljas etapis . Enne töö üle andmist toimub Täitja poolne testimine, dokumenteerimine. Tarnele järgneb Tellija poolne testimine. Arstiportaali arendustöö Arstiport a ali arendustöö raames tehtavad järgmised muudatused : T äiendada esilehe all olevat teatiste nupu alt avanevat nimekirja. Uued nupud märgitud all oleval joonisel punasega. Võt t a kasutusele uued dokumentide standardid olemasolevates (UC 2, UC61) ja uutes päringutes : s urmateatis – sisestus vorm ja stiilileht ; s urma põhjuse teatis – sisestus vorm ja stiilileht ; p erinataalsurma põhjuse teatis - sisestus vorm ja stiilileht ; s urmatõend - stiilileht . Täiendad a olemasolevaid dokumentide st andardeid uute andmeblokkidega ja -väljadega : ambulatoorne epikriis – sisestus vorm ja stiilileht ; statsionaarne epikriis – sisestus vorm ja stiilileht ; kiirabikaart – stiilileht . Kõikide eespool nimetatud dokumentide kuvamisel ja väl ja printimisel peab järgima TEHIK-u poolt publitseeritud dokumentide stiililehti. Lisada admini streerimise moodulisse uued loendi d (vt lisa 2 vaheleht „loendid“). Lisada kõigile uutele ja olemasolevate dokumentide kohustuslikutele andmeväljadele mitte täimise korral vastava veateate kuvamine ; Täiendada (vajad usel) TIS-i pär inguid vastavalt muudetud päringu standarditele A rendustöö ks vajalikud dokumenti de tehnilise s tandardid koos stiililehtedega valmivad detsemb r is 2017. Lisas 2 „surmasündmuse STRK_120717 ja sisestusvormid“ on kirjeldatud uute dokumentide andmeko osseisud ( sh stiililehe ja sisestus vormide kujundused ) ja olemasolevate dokumentide täiendused andmekoosseisudes (sh sisestus vormi kujundused) . Eskiiside järgmine ei ole rangelt kohustuslik, kui arenduse käigus selgub, et andmevälju on kasutajaliidesesse võrreldes dokumendiga võimalik paremini paigutada. Arendaja peab sellisel juhul oma ettepanekud Tellijaga kooskõlastama. Tellija annab vajalikud dokumendi- ja päringu standardid teostajale üle enne arendustöö algus t . Patsiendiportaali arendustöö Patisendi portaali arendustöö raames tehtavad järgmised muudatused: Lisada uute dokument i d e stiililehed : s urmatõend s urma põhjuse teatis p erinataalsurma põhjuse teatis Võt t a kasutusele o lemasolevate dokumentide standardite uued versioonid (sh täiendada stiililehed) : ambulatoo rne epikriis ; statsionaarne epikri is ; kiirabikaart . Luua tehniline võime kus surnu (seadusest tuleneval ja PP-s määratud) esindajal näha surmatõendit , surma põhjuse teatist ja perinataalsurma põhjuse teatist vastavalt TIS-i poolt täiendatud kasutajaõiguste ja ligipääsude funktsionaalsusele (täpsustub) PP-s peab olema võimalus määrata (nt ühe linnukese panemisel) , et sugulased ei näe pärast isiku surma tema surma dokumente. E sindaja määramisel peab saama täpsustada, kas esindaja saab pärast esindatava surma näha esindatava surma kõiki dokumente (vaikimisi) või ainult surmatõendit ja surma põhjuse teatist(märkides linnukese vastavasse kohta); Luua tehniline võimekus PP- s esindajal oma esindamise õiguse eemaldamiseks esindatavate lehel ; Kui esindaja on omapoolt eemaldanud esindamise õiguse, siis selle järgselt tal enam surma dokumentide nägemise õigust ei ole ja taga si esindamise õigust ei saa panna. Lisatakse PP-i dokumentide avamise lingid ja päringu standardid. A rendustööks vajalikud dokumentide tehnilised standardid valmivad detsembris 2017. Lisas 2 „surmasündmuse STRK_120717 ja sisestusvormid“ on kirjeldatud uute dokumentide andmekoosseisud ja olemasolevate dokumentide täiendused andmekoosseisudes. Tellija annab vajalikud dokumendi - ja päringu standardid ning lõplikud PP käitumise reeglid teostajale üle enne arendustöö algus t . K MT ning ASM-i analüüsi ja ar endustöö d K MT ja ASM-i arendustöö de raames tehtavad järgmised muudatused: Täiendada KMT-s o le masoleva kiirabikaardi täitmise funktsionaalsust vastavalt projekti s „e-surmasündmus“ kirjeldatule; Täiendada ASM-s kiirabikaardi dimensioone ja mõõdikuid vastavalt lisandunud andmeväljadele; Võ t ta printimiseks kasutusele kiirabikaardi uue versiooni stiilileht. A rendustööks vajalik dokumendistandard koos stiililehega valmib detsembris 2017. Lisas 2 „surmasündmuse STRK_120717 ja sisestusvormid“ on kirjeldatud vahelehel „Kiirabikaardi täiendused“ lisanduvad andmeväljad. Tellija annab vajalikud dokumendi - ja päringu standardid teostajale üle enne arendustöö algus t . Arendustööde teostamine Meeskond Organisatsioon Koosseis Roll Quretec Anti Alman p rojektijuht Quretec Kadri Hendla a nalüütik Quretec Karol Toompalu a rendaja Quretec Allan Kook arendaja Quretec Mikk Saarepuu testija Arendustöö de töömaht ja maksumus ( OÜ Quretec pakkumus) Moodul / tegevus töömaht, ühik (h) töö maksumus km-ta (EUR) töö maksumus km-ga (EUR) Analüüs 28 0 1 008 0,00 1 2 0 96 ,0 0 A rstiportaali arendustöö 832 29952 ,00 35942 ,4 0 KMT ja ASM-i arendustöö 520 18720,00 22464,00 Patsiendiportaali arendustöö 648 23328 ,00 27993 ,60 Kokku: 2 280 82080 ,00 98496 ,00 /allkirjastatud digitaalselt/ Margus Jäger OÜ Quretec juhatuse liige Lisa 2 töölepingule nr 0082 Kokkulepe töölepingu tingimuste muutmiseks Tervise ja Heaolu Infosüsteemide Keskus, Katrin Reinholdi isikus ja Annike Koorts leppisid kokku 27. detsembril 2012. a sõlmitud töölepingu nr 0082 tingimuste muutmises alates 1. jaanuarist 2017. a alljärgnevalt: TÖÖAEG 8. Ületunnitöö arvestus määratakse TEHIKu töökorralduse reeglites. 9. Tööaja algus ja lõpp, samuti lõunavaheaja ning võimalike muude vaheaegade algus ja lõpp määratakse TEHIKu töökorralduse reeglites. TÖÖTASU 11. Töötaja töötasu (põhipalk) on 1 500 (üks tuhat viissada) eurot kuus (bruto). 13. Tööandja kohustub maksma töötajale töötasu üks kord kuus TEHIKu töökorralduse reeglites ettenähtud kuupäeval. Töötasu maksmine toimub sularahata arvelduse korras ülekandega töötaja isiklikule pangakontole. PUHKUS 14. Töötaja iga-aastase põhipuhkuse kestus on 35 kalendripäeva. /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ Katrin Reinhold Annike Koorts Direktor   Paavo Kirsi Riigi Infosüsteemi Amet Teie 25.10.2017 [email protected] Meie 01.11.2017 nr 1-6/457-4 Pärnu mnt 139a Tallinn, 15169 Vastused RIA küsimustele projekti e- Surmasündmus täistaotlusele II Lugupeetud Paavo Kirsi Riigihanke „Tervise infosüsteemi tarkvaraliste analüüsi- ja programmeerimisteenuse teostamine“ (riigihanke registreerimisnumber e-Riigihangete registris: 178741) õiged raamlepingute summad on Riigihangete registris. Raamlepingute osapooled nõustusid sõlmima lepingu muutmise lisa ilmselge ebatäpsuse parandamiseks ja arendajad said 31.10.2017 lepingu muutmise lisa projektid. TIS I osa allkirjastatud raamlepingu lisa ja TIS II osa lepingute muutmise lisade projektid on lisatud kirjale manusena. TIS I osa raamlepingu alt on juba tellitud üks arendustöö (180 000 eurot). TIS II osa raamlepingute alt pole veel arendustöid tellitud. Lisaks on manusesse lisatud:  Quretec OÜ-ga allkirjastatud TIS II osa raamleping.  AP, PP ja KMT arendustööde minikonkursi otsus  AP, PP, KMT arendustööde minikonkursi teine pakkumus.  projektijuhi leping Lugupidamisega (allkirjastatud digitaalselt) Katrin Reinhold Direktor Lisa:  TIS I osa raamlepingu lisa_Industry62 OÜ  TIS II osa raamleping Quretec OÜ  TIS II osa raamlepingu lisa projekt_Aktors OÜ  TIS II osa raamlepingu lisa projekt_HEISI IT OÜ  HEISI IT_TIS II raamlepingu muutmise lisa sõlmimise kinnitus  Memo_Portaalide arendustööde pakkumuste otsus  Quretec_portaalide arendustööde pakkumus  Projektijuhi tööleping_Annike Koorts Annike Koorts [email protected] Uus-Tatari 25 / Veerenni 13/ 10134 Tallinn / 694 3900 / [email protected] / www.tehik.ee / registrikood 70009770