Pakkumuskutse "Üleriigilise digiregistratuuri UX/UI"

Lisa 1 Tehniline kirjeldus Üleriigilise digiregistratuuri UX/UI 1. Ülevaade 1.1 Üleriigiline digiriegistratuur (ÜDR) on isiku iseteenindusportaal, mida kasutavad kõik sellele autoriseeritud ligipääsu omavad isikud iseendale või tema poolt esindatavatele isikutele eriarsti- või perearsti teenustele aegade broneerimiseks, muutmiseks või tühistamiseks või ootejärjekorda lisamiseks ÜDR-ga liidestunud tervishoiuasutuste (TTO) piires. ÜDR on täiendav digikanal isikutele lisaks telefonisuhtlusele ja TTO-spetsiifilistele digiregistratuuridele. 2. Lepingu eesmärk 2.1 Lepingu raames teostatavate tööde eesmärk on võimaldada patsiendil leida ja broneerida temale endale või tema poolt esindatavale isikule sobiv aeg eriarsti teenuse esmasele vastuvõtule saatekirja alusel või ilma selleta. Visiidi eest tasumine on kas Tervisekassa poolne või tasub patsient ise. Tervisekassa poolt tasumise puhul võib sellega kaasneda nn visiiditasu, mille kohta kehtivad erireeglid. 2.2 Hanke eesmärk on: 2.2.1 teenuse broneerimise protsessi parendamine, disaini ning kasutajavaadete parendamine ja mugandamine; 2.2.2 arstile vaba aja leidmise ja broneerimise protsesside analüüs, sh ootejärjekordade ja Ajaleidja (AL) toimimise loogika protsessid; 2.2.3 funktsionaalse prototüübi loomine, testimine ning HTML/CSS arendustööd, sh arvestades WCAG 3.0 nõudeid. 3. Algandmed ja lahendamist vajavad probleemid 3.1 Kasutajad: 3.1.1 Kõik Eesti täisealised isikud; 3.1.2 TTO-de registraatorid ja arstid; 3.2 Eeldused: 3.2.1 TTO on liidestunud ÜDR-ga üle X-tee vastavalt ÜDR liidestusjuhendile ja/või PAIS liidestumisjuhendile; 3.2.2 TTO on defineerinud tema poolt pakutavad teenused registreerides need nn ressursside sõnumite kaudu. 3.3 Reeglid: 3.3.1 Ühele saatekirja nõudeta teenusele, mille eest tasub Eesti Haigekassa, tohib olla üks ja ainult üks kehtiv broneering antud teenusele; 3.3.2 Igale saatekirjaga saab olla üks ja ainult üks kehtiv broneering. Broneeringu tühistamisel või vastuvõtu aja möödumisel ilma visiidi toimumiseta saatekiri vabaneb; 3.3.3 Saatekirja alusel saab broneerida selle kehtivuse ajal, muuta broneeringut saab ka peale saatekirja kehtivuse lõppemist;  3.3.4 Saatekirja alusel broneerimisel tasulisele ajale kasutatakse saatekiri broneeringuga, st saatekiri muutub kasutatuks; 3.3.5 Saatekirja alusel broneerimisel teenuse piiranguid ei rakendata; 3.3.6 Kasutaja saab vaadata saatekirja sisu, ligipääs võib olla piiratud; 3.3.7 Tasulistele teenustele võib broneerida patsiendile sobiva arvu aegu sõltumata saatekirja nõudest ning selle olemasolust; 3.3.8 ÜDR kasutaja saab panna ennast teenuse osutamiseks ootejärjekorda (ootelehele), mida teenindab Ajaleidja pakkudes patsiendile aja vastavalt kirjeldatud kriteeriumitele; 3.3.9 TTO võib broneerida ÜDR vahendusel patsiendile aja ka korduvvastuvõtule; 3.3.10 ÜDR kasutaja saab broneerida aegu endale või tema poolt esindatavale isikule. 3.4 Lähteandmed: 3.4.1 Liidestunud TTOsid võib olla sama palju, kui on litsentseeritud tervishoiuteenuste osutajaid. 3.4.1.1 Seisuga 17.10.2022 on liidestunud ca 270 TTO-d. 3.4.2 Teenuste loend vt . https://pub.e- tervis.ee/classifications/Ambulatoorsed%20vastuv%C3%B5tud/17 3.4.2.1 Teenuseid on ca 300; 3.4.2.2 Teenused on grupeeritud valdkondade kaupa; 3.4.2.3 Teenustele võivad kehtida erinevad täpsustused; 3.4.2.3.1 Vanuse alam- ja ülempiirid; 3.4.2.3.2 Sugu; 3.4.3 Teenustel on oma elutsükkel (kehtivuse periood). 3.5 Nõuded: 3.5.1 Iga TTO peab defineerima tema poolt osutatavad teenused vähemalt järgmises lõikes; 3.5.2 TTO regNr; 3.5.3 Teenuse osutamise asukoht vähemalt maakonna täpsusega; 3.5.4 Üht ja sama teenust võib osutada mitmes asukohas; 3.5.5 TTO võib soovida osutada teatud teenuseid ainult; 3.5.5.1 Perearstide puhul ainult oma nimistu patsientidele või kõigile soovijatele; 3.5.5.2 Ainult teatud TTO-dele (juhul kui broneerijaks on mingi teine TTO, kes tegutseb patsiendi nimel); 3.5.6 Andmevahetusstandardid (HL7 ver 3) on kinnitatud ning nende muutmine ei ole skoobis. TTOde rakendused toimivad nende alusel; 3.5.7 Terviseportaali ja ÜDR kujundus peab olema maksimaalselt ühesugune; 3.5.8 ÜDR kasutajad on: 3.5.8.1 Patsiendid; 3.5.8.2 TTOde registratuurid; 3.5.8.3 TTOde arstid; 3.6 Lahendamist vajavad probleemid 3.6.1 Teenuseid on palju (ca 300) ning sobiva teenuse leidmine ei ole kerge ega mugav; 3.6.2 Liidestunud TTO-sid on palju (ca 280) ning nende leidmine ei ole kerge ega mugav; 3.6.3 Valdkondade ja teenuste nimetused ei ole patsiendisõbralikud;  3.6.4 Patsient ei tea millisele teenusele oma probleemiga peaks aja broneerima. Sünonüümide haldamine on keeruline ning seni olnud ebaefektiivne, eriti kuna tegemist on sünonüümidega kolmes keeles; 3.6.5 Isegi meditsiiniharidusega inimestel on teenustes orienteerumine keeruline, valdkonnad küll pisut aitavad kuid mitte piisavalt; 3.6.6 Patsiendiportaali ja ÜDR kujundused erinevad. 4. Tellitavad tööd 4.1 Teenuse disaini ja kasutajavaadete ning broneerimise protsessi parendamine ning mugandamine; 4.2 Arstile vaba aja leidmise ja broneerimise protsesside analüüs, sh ootejärjekordade ja Ajaleidja (AL) toimimise loogika protsessid; 4.3 Funktsionaalse prototüübi loomine, testimine ning HTML/CSS arendustööd, sh arvestades WCAG 3.0 nõudeid; 4.4 Teostatud tööd antakse etapiviisiliselt üle aktiga, milles kajastuvad teostatud tööd ning selleks kulunud töötundide arv. 4.5 Konkreetsete tööde loetelu tekib hankelepingu täitmise käigus ja seda hallatakse Jiras. Täitja saab sisendi töödega alustamiseks üksnes tellija kontaktisikult. 5. Tööde teostamise põhimõtted 5.1 Tööde teostamisel lähtutakse raamlepingust nr 3-9/3050-1 ja selle lisa 3 kodukorrast. Protsesse täpsustatakse järgnevalt: 5.2 Tööprotsess 5.2.1 Tööraamistik peab tuginema etapiviisilisele planeerimisele, võimaldades arendusmeeskonna prioriteete jooksvalt muuta; 5.2.2 Tööraamistik peab võimaldama süsteemset ülevaadet iga etapi saavutustest; 5.2.3 Tööraamistik peab võimaldama arendusmeeskonna tulemuslikkuse (kasvu) jälgimist ajas; 5.2.4 Tööraamistik peab tagama, et arendusmeeskond tegeleb omal initsiatiivil enda tulemuslikkuse parandamisega ja parendusettepanekute esitamisega; 5.2.5 Täpsem protsess lepitakse kokku tööde käigus. 5.3 Dokumentatsioon: 5.3.1 Dokumenteerimine toimub jooksvalt vastavalt punktis 5.5 olevale loetelule. 5.4 Töökorraldus 5.4.1 Projekti töökorraldus toetub kodukorrale. Täitja peab tagama piisava kaasamise ja ülevaadete andmise tellijale. 5.5 Mittefunktsionaalsed nõuded 5.5.1 Mittefunktsionaalsete nõuete osas tuleb lähtuda Confluence’is olevatest nõuetest (Lisa 3) 5.6 Tulem 5.6.1 Analüüsi ja kasutajaliidese disaini tulemi kohustub täitja andma üle hiljemalt 01.05.2023 üleandmise ja vastuvõtmise aktiga. Akt peab sisaldama endas järgnevat: 5.6.1.1 Analüüs ja prototüüp peab endas sisaldama:  5.6.1.1.1 Viiteid dokumentatsioonile Confluence’is; 5.6.1.1.2 Viited tehtud töödele (Jiradena); 5.6.1.1.3 Navigeeritav prototüüp Figma. 5.6.1.2 Iseteeninduse arendustööde tulem peab olema üle antud Gitlabis (HTML/CSS). 5.6.1.3 Dokumenteeritud WCAG testimiste tulemused peavad asuma Confluence’is. 5.6.1.4 Dokumenteeritud iseteeninduse kasutatavuse testimise tulemused peavad asuma Confluence’is. 6. Tööde teostamise tähtaeg Tööde üleandmise lõpptähtaeg on 01.05.2023. Tööde üleandmisele järgneb tellija poolne tööde vastuvõtmisaeg mõistliku aja jooksul ja vajadusel täitja poolne paranduste tegemine üle antud töödes, kui ilmneb, et tööd ei ole lõpptähtajaks teostatud nõuetekohaselt. MFN Versioon: 2.2 Dokument määrab kvaliteedi- ja mittefunktsionaalsed nõuded (MFN) uutele infosüsteemidele ning nende dokumentatsioonile. Dokumenti hoiavad ajakohasena Tervise ja Heaolu Infosüsteemide Keskuse (TEHIK) arhitektid. 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 TEHIKu koostatud dokumentide ja kolmandate osapoolte koostatud dokumentide erisuste puhul tuleb lähtuda TEHIKu 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. Erandid tuleb kooskõlastada TEHIKu vastutava arhitektiga. Nõude Nõude sisu Seletused Võrdluses LinuxForHealth KeFHIR nr arvestada 1. Vastavus üldistele standarditele Lahenduse X-tee teenused peavad https://www.ria.ee/et/ametist/juhendid.html Mitte 1.1 vastama RIA nõuetele arvestada Lahendus peab vastama IT-Profiil Arvestada OK OK 1.2 Sotsiaalministeeriumi IT-profiilile Rakendus peab olema kirjutatud https://www.ria.ee/et/kuberturvalisus/infosusteemide-turvameetmete-susteem-iske. Arvestada NOK NOK 1.3 arvestades selle rakenduse poolt html töödeldavatele andmetele määratud ISKE turvaklassi nõudeid Veebirakenduse kasutajaliides peab https://www.w3.org/TR/WCAG21/ Mitte 1.4 vastama vähemalt WCAG 2.1 arvestada tasemele AA Veebipõhine kasutajaliides peab Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on Mitte 1.5 ühilduma täielikult standarditega tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemas olevat HTML arvestada HTML 5 ja CSS 3. ja CSS versiooni. Allkirjastamisel tuleb kasutada Vaata ka https://www.tehik.ee/arendusjuhendid Mitte 1.6 TEHIK'u SiGA/SiVa arvestada vahendusteenust. Veebirakendus peab probleemideta Kui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS tasemeks 2 (http Mitte 1.7 läbima OWASP ASVS baasil s://www.owasp.org/index.php/Category: arvestada põhineva testi OWASP_Application_Security_Verification_Standard_Project). Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile. Tellija poolset turvatestimist teostab kolmas sõltumatu osapool. Selline esmane kolmanda osapoole turvatestimine tellitakse tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui tellija vastava nõudmise esitab. Krüptoalgoritmite ja Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA Arvestada NOK NOK 1.8 räsifunktsioonide kasutamisel kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli tuleb kasutada turvalisi algoritme ja uuringut. Värskeima uuringu leiab aadressilt https://www.ria.ee/et/ametist/uuringud- võtmepikkuseid. analuusid-ulevaated.html Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh sertifikaatide kasutuskohad. Andmete edastus peab olema Autentimist ei ole vaja ainult avalikke andmete edastamisel. Näiteks avaandmed. Arvestada OK OK 1.9 kaitstud kasutades krüpteeritud ja vajadusel autenditud kanalit. Autentimise mehhanism tuleb kokku leppida TEHKu poolse arhitektiga. Infosüsteem peab kasutama serveri Kõik mahakirjutatavad ja talletatavad kellaajad tuleb salvestada UTC ajatsoonis Arvestada OK OK 1.10 kellaaega. koos ajatsooni infoga. Kasutajatele mõeldud kuvades tuleb kasutada sirviku ajatsooni. Aja esitamisel tekstikujul lähtuda standardist ISO 8601. Süsteemi edasiarendamisel Arvestada OK OK 1.11 /loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. Rakendus peab olema tehniliselt Lahenduse arhitektuuris kasutada domeenist juhitud disaini ja mikroteenuste Arvestada NOK NOK 1.12 tükeldatud vastavalt loogilisele põhimõtteid. jaotusele. Saadud osised peavad olema eraldi versiooneeritavad ja Näiteks, kui rakendus on eraldi turvakontekstidega liidesed ametnikule ja paigaldatavad kodanikule, peab rakendus olema jagatav kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks. Avalike e-teenuste loomisel peab https://riigikantselei.ee/valitsuse-too-planeerimine-ja-korraldamine Mitte 1.13 arvestama valitsusasutusele /valitsuskommunikatsioon/visuaalne-identiteet arvestada kehtestatud visuaalse identiteedi stiilijuhiseid 1.14 Avalike e-teenuste loomisel peab https://zeroheight.com/3d136290e/p/188910-veera-disainissteem/b/94293b Mitte arvestama Veera disainisüsteemiga. arvestada 2. Nõuded rakenduse arhitektuurile Rakenduse, andmebaasi ja Arendaja loodud lahenduse dokumentatsioonis (nt analüüs vms) peab olema välja Arvestada OK OK 2.1 kolmanda osapoole komponendid toodud kasutatavate komponentide nimetused ja versioonid. Versiooni eluea lõppu peavad olema sellised, mille eluea ei loeta võrdseks terve komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui lõpp (EOL) pole teadaolevalt vähem uus versioon on välja lastud. kui 2 aasta pärast. Jätkuarenduse puhul tuleb kaardistada eelneva arendusperioodi komponentide kaardistus. EOL komponentide kasutamisest tuleb teavitada TEHKu arhitekti. Tulevase ja olemasolevate Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja Arvestada OK OK 2.2 infosüsteemide platvormid lähteülesande käigus välja toodud jõudlusnäitajatele. (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peab olema loodud kooskõlas IT profiiliga. Rakendusserver peab võimaldama Arvestada OK OK 2.3 töötamist andmebaasiserverist eraldi serveril. Rakendusserver peab olema Lahendused peavad toetama rakenduste horisontaalset skaleeruvust. Arvestada OK OK 2.4 vajadusel klasterdatav aktiivklastris. Kasutaja sessioonid ei tohi olla rakenduserveri klastri õla põhised. Rakendust peab saama ilma Lahendus ei tohi olla sisse kompileeritud absoluutseid URI-sid Arvestada OK OK 2.5 ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahel. Rakenduse komponentide Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel Arvestada OK OK 2.6 konfiguratsiooni peab olema kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse võimalik ette anda käivitamisel. konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näit Log4net). Samuti on Konfiguratsiooni muudatus peab väga soovitatav eraldi konfiguratsioonifailis hoida arendaja ja administraatori olema teostatav ilma rakendust vastutusala parameetrid. Infosüsteem peab olema seadistatav kompileerimata. konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi. Näiteks dockeri konteinerite puhul keskkonnamuutujad. 2.7 Rakenduse taaskäivitus, Tavaline käivitusaeg ei tohi ületada 1 minutit. Arvestada OK OK konfiguratsiooni muutmine vms peab toimuma mõistliku aja jooksul. Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate. 2.8 Lahenduse väliste osapoolte Kui rakendusel või mõnel selle komponendil on tihti kasutatav teenus ning sellel Arvestada OK OK komponentide konfiguratsioonid teenusel on laetav konfiguratsioon, siis tuleb: peavad olema puhverdatud. laadida konfiguratsioon ühekordselt ja seda korduvkasutada; konfiguratsiooni automaatselt ja regulaarselt värskendada; regulaarsuse tarbeks peab saama määrata intervalli, millise aja järel või täpsed kellaajad, millal konfiguratsiooni värskendatakse; luua võimalus värskendada konfiguratsiooni käsitsi. Näiteks: digidoc4j teegi korral laetakse TSL nimekiri välisvõrgust puhvrisse, et vähendada koormust kolmandale osapoolele. OpenID konfiguratsioon Rakendus peab kasutama 64-bitist Arvestada OK OK 2.9 arvutiarhitektuuri. Kõik andmed, andmebaasid, SQL Arvestada OK OK 2.10 skriptid, lähtekood ja rakendus peavad kasutama UTF-8 kodeeringut. Rakenduserveri failisüsteemi ei tohi Näiteks objektide talletuseks kasutada S3 lahendust. Arvestada OK OK 2.11 salvestada midagi püsivaks kasutamiseks. Ühest relatsioonilise andmebaasi Erinevate skeemide vahelised ühendused on keelatud. Peab kasutama REST/SOAP Arvestada OK OK 2.12 andmetabelist teise viitamisel tuleb /AMQP liidestust. kasutada väliseid võtmeid (Foreign key). Skeemide vahelised ühendused on keelatud - miks? Kõik välised võtmed (Foreign Key) Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded rakenduse Arvestada OK OK 2.13 peavad olema indekseeritud. jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – vastavalt planeeritud kasutusajale). Tuleb kasutada päringumuutujaid SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama Arvestada OK OK 2.14 (Parameter Binding) 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) Kõigis andmebaasi tabelites peab Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid. Arvestada OK OK 2.15 olema defineeritud üks primaarvõti. 2.16 Andmebaasi objektide nimetused Kasutada tuleb vastava andmebaasisüsteemi nimetamise parimaid praktikaid. Arvestada OK OK peavad olema sisulised ja andma aimu nende otstarbest.  Andmebaasis defineeritakse Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja Arvestada OK OK 2.17 üldjuhul kaks või enam kasutajat: toodud ja tuleb peale installi ära võtta. Karbitoodete puhul tuleb erisused läbi arutada TEHIK arhitektiga. Rakenduse peakasutaja, kellena luuakse objektid ja Lahenduse puhul, milles kasutatakse andmebaasi versiooneerimist, tuleb kasutada skeemid. mitut andmebaasi ühendust. Ennem rakenduse käivitumist teostatakse andmebaasi Rakenduse piiratud õigustega skeemi muudatused eraldi kasutajaga. Rakendus kasutab enda põhitööks kasutajat, kasutaja, kellena pöördub kellel puudub õigus andmebaasi skeemis muudatusi teostada. rakendusserver/rakendus. Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis. Failide hoidmise asukoht lepitakse Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud Mitte 2.18 iga kord kokku, kuid failid ja failide nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb arvestada indeks peavad olema ära tuua failide hoidmise asukoht. replikeeritavad teise serveriruumi. Näiteks objektide talletuseks kasutada S3 lahendust. Peab olema miinimumini viidud Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. Mitte 2.19 vajadus, et haldur teeb arvestada haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid. Rakendus peab olema võimeline Näiteks logifailides. Arvestada OK OK 2.20 kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne). Andmebaas peab toetama nii külm- Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "MSSQL Mitte 2.21 kui ka kuumvaru (peegeldamist) filestream"). arvestada teise serviruumi. Sorteerimisreeglistik peab olema Näiteks PostgreSQL puhul et_EE. Mitte 2.22 Eesti tähestikule vastav. arvestada Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud. Kui infosüsteemid saadavad e-kirju, Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on Mitte 2.23 peavad nad kasutama välist e- muudetavad konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab tagama arvestada mailiserverit. Kirja saatmisel peab kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis rakendus veenduma, et e-posti protsess/skriptifail/kasutaja kirja genereeris jms abistav info). server võttis kirja vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322). Konfiguratsiooniparameetrite nimed Näiteks : X-TEE-TURVASERVER, mitte XTTS või viitenumber, mitte vk_seb jne Arvestada OK OK 2.24 peavad olema sisulised. Kui see ei ole võimalik, siis peab kõrval olema seletus. Infosüsteemides on eessüsteemid Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on Arvestada OK OK 2.25 (front end; presentatsiooni kiht) ja andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele tagasüsteemid (back end; äriloogika lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise kiht) arhitektuuriliselt selgelt tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt lahutatud ja eraldi paigaldatavad. sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem olema suuteline oma tööd jätkama taaskäivitamata. Konfiguratsioonifailid peavad olema Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Arvestada OK OK 2.26 vastavalt rakendusserveri tüübile vaikimisi kaitstud failid/objektid Arendaja peab välja tooma konfifailide listi, kui neid on mitu. Rakenduse failid, mida kasutaja Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, Mitte 2.27 näha ei tohi, peavad olema vaikimisi App_LocalResources, App_Themes, App_WebReferences, .git arvestada kaitstud kaustades ja ei tohi olla veebi juurkaustas. Konfiguratsiooniparameetrite Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, mitte nii, et igas Arvestada OK OK 2.28 taaskasutus. Erinevaid sama sisuga lõigus kirjeldatakse samu asju uuesti. parameetreid ei tohi konfiguratsioonis eksisteerida. Kõik rakenduse liidesed peavad Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad Arvestada OK OK 2.29 olema võimelised kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav lahendus on selline, mida saab töötama kõrgkäideldavalt. samaaegselt käitada erinevates masinates. Klientrakendus ei tohi pöörduda Tuleb kasutada rakendusservereid. Mitte 2.30 otse andmebaasi poole. arvestada Keskkonnapõhised muutujad Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. Arvestada OK OK 2.31 peavad olema konfiguratsioonifailist seadistatavad. Eelistada tuleb tsentraalseid Kui rakendus realiseerib ise autentimist, siis peab olema võimalik piirata Arvestada OK OK 2.32 autentimislahendusi (nt TEHIK ebaõnnestunud logimisi ajaühiku kohta (mobiil-ID, paroolid) ühelt IP-aadressilt. SSO). Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada captchat või konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist muuta. Rakenduse äriloogika tuleb Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna Arvestada OK OK 2.33 realiseerida andmebaasist eraldi kirjutatavaid andmeid, va trigerid, mis tekitavad logi. sõltumatus rakenduskihis.  Relatsioonilises andmebaasis võib Arvestada OK OK 2.34 kasutada vaid ISO/IEC 9075 Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine standardiga kaetud mõnele muule andmebaasiplatvormile ei ole võimalik. funktsionaalsusi. Lisaks ei tohi ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutada ka sama standardi osas kasutamist andmebaasis. 13 kirjeldatud funktsionaalsusi. Kui rakendus eeldab eraldi Mitte 2.35 kasutajate, rollide ja õiguste registri arvestada pidamist, siis peab rakendus kasutama Tellija tsentraalseid autoriseerimislahendusi. Uniform resource identifier (URI) Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi järele uurida Mitte 2.36 pikkus ei tohi ületada ühegi IS poolt sõltuvalt IS komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239. arvestada toetatava brauseri maksimaalset lubatud väärtust. Veebiteenuseid (REST, SOAP) Näiteks WSDL puhul: Alajaotis definitions/types/schema: Arvestada OK NOK 2.37 pakkuv rakendus peab olema üles ehitatud nii, et see toetaks teenuste complexType defineerimisel tuleb sellele lisada any element. versioneerimist URL-i ja/või schema tasemel. Rakendus peab olema võimeline Koormusjaoturi peal kasutatakse järjestikplaanurit (Round Robin) päringute Arvestada OK OK 2.38 töötama koormusjaoturitega suunamisel. Samuti võidakse teostada koormusjaoturil TLS ühenduse lahtivõtmist ja varustatud taristul. uuesti kokkupanemist (SSL offload) . Sidusinfosüsteemide mitte Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude Mitte 2.39 kättesaadavus ei tohi segada toimimist. Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd arvestada rakenduse töötamist. jätkama rakendust taaskäivitamata. Sidusinfosüsteemidega andmevahetamisel tekkinud vead Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid väljastama logitakse ja kasutajat hoiatatakse. mõistliku (võimalikult lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid. 2.40 Automaatselt käivituvaid taustatöid Vajalik juhuks, kui automaatsel käivitumisel on tekkinud viga ja/või taustatöö on Mitte peab saama käsitsi (taas)käivitada. pooleli jäänud. arvestada Pärast vea põhjuse korrigeerimist peab saama taustatöö uuesti käivitada. Kui ajastatult käivitatav taustatöö, ei Mitte 2.41 ole mõeldud käima paralleelselt, arvestada 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. Uue toote arenduse ja Mitte 2.42 olemasolevate infosüsteemide arvestada versiooniuuendustel kasutusele võetavate tehnoloogiate ja standardite valik tuleb kooskõlastada Tellija poolse arhitektiga. Rakenduse ühenduste (s.h. Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang, Arvestada OK OK 2.43 andmebaasi ja sidusinfosüsteemide päringu aegumise aeg (request timeout) ja ühenduse elususe periood (keepalive). ühendused) realiseerimisel tuleb Rakenduse ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutada ühenduste puulimist kasutuslugude toimimist. Ühenduste taastumisel peab rakendus olema suuteline (connection pooling). oma tööd jätkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse. Rakenduse uuendustega Näiteks Liquibase või Flyway. Arvestada OK OK 2.44 kaasnevad andmebaasi muudatused tuleb automatiseerida. 3. Turvalisuse tagamisega seotud nõuded Asutusesiseseks kasutamiseks Mitte 3.1 mõeldud rakenduse kasutajate arvestada autoriseerimist peab saama teha Active Directory põhiselt. Kliendi ja serveri vahel peab Arvestada OK OK 3.2 autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades. Rakendus tohib kasutada vaid Mitte 3.3 sessiooni küpsiseid (cookies). arvestada Muude küpsiste kasutamine on keelatud. Kui andmebaasis olevate andmete St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei Arvestada OK OK 3.4 ISKE tervikluse turvaosaklass on 3 kustutata, vaid tehakse uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga (kõrge), siis tuleb kõik andmebaasi uus kirje peab sisaldama järgmist informatsiooni: kirjed/tabelid versioneerida. 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.  Rakendusega peab kaasas olema Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja Mitte 3.5 lahendus, mis suudab toota omavahelised suhted. arvestada toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset Täpsem vajadus ja tegevusplaan tuleb koostada TEHIKu arhitekti ja tooteomanikuga. informatsiooni. Rakendusse ja andmetele tohib olla St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi. Mitte 3.6 ligipääs vaid dokumenteeritud ja arvestada tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades. Kõigi rakenduse poolt salvestatud Hetkel kehtivad nõuded saab TEHIKu arhitektilt. Arendaja loodud lahenduse Mitte 3.7 paroolide ja salaküsimuste vastused dokumentatsioonis (nt detailanalüüs vms) peab olema ära toodud kasutatavad räsi arvestada peavad olema räsitud+soolatud. Kui ja krüptoalgoritmid, võtmepikkused ja nende kasutuskohad (vt nõue p 1.10) räsimise asemel valitakse krüpteerimine, siis tuleb dokumenteerida ka krüptovõtme turvalise hoidmise protseduur. Rakendus ei tohi teostada X-tee Kasutajaarvutitest otse x-tee päringute tegemine on arvutivõrgu tasemel kinni. Mitte 3.8 päringut otse kasutajaarvutist. arvestada Veebipõhised välise veebilehega IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat Mitte 3.9 rakendused peavad kasutama tööriista. Lubamatud päringud on kõik päringud, mis ei ole detailanalüüsi käigus arvestada vahendeid, kaitsmaks rakendust vastavalt kasutusjuhtudele ette nähtud. Kasutama peab whitelisting põhimõtet, mitte lubamatute päringute eest. blacklisting. Kasutaja peab saama soovi korral Rakendus peab sisenemisel näitama pärast õnnestunud sisselogimist eelmise Mitte 3.10 veenduda, kas keegi pole tema õnnestunud sisselogimise aega. Kui on toimunud ebaõnnestunud sisselogimise arvestada nime all vahepeal sisse loginud. katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti. Ebaõnnestunud logimiste katsete kuvamise nõue kehtib juhul, kui autentimine ja autoriseerimine lahendatakse rakenduses lokaalselt. Kõigil rakendustel peab olema Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Mitte 3.11 konfigureeritav kasutajasessiooni arvestada aegumise aeg. Autenditud sessiooni tunnus peab Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega ühest Mitte 3.12 olema krüpteeritud. arvutist teise. arvestada LDAP lahenduse (nt AD) Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne. Mitte 3.13 kasutamisel peab rakendus arvestada kasutama kontoga kaasnevaid piiranguparameetreid. Tagada tuleb rakenduse rollide Peakasutajal ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus Mitte 3.14 lahusus. peab lähtuma detailanalüüsist ja kasutusjuhtudest. arvestada Arendus peab olema orienteeritud Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis toodangu keskkonnas Arvestada OK OK 3.15 toodangukeskkonnas toimimiseks. on ebavajalikud või segavad (näiteks kasutuseta funktsionaalsus ja komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks arenduskeskkonnas jne). Rakendus ei tohi lubada ühe Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti. Mitte 3.16 kasutajaga mitut samaaegset arvestada sessiooni. Kui rakenduse tervikluse Milline lahendus valitakse tuleb kokku leppida tellijaga. Arvestada NOK NOK 3.17 turvaosaklass on T3, peavad tõestusväärtust omavad andmed Täpsustuseks vt ISKE nõue HT.34. Vt ka nõuet 3.28. olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud. Kui rakenduse tervikluse Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus lepitakse eraldi Mitte 3.18 turvaosaklass on T3, peavad kokku Tellija infrastrktuuri juhiga ja infoturbejuhiga. See sõltub Tellija keskse arvestada tõestusväärtust omavad andmed krüptoahela kasutamise võimalustest. olema krüptoaheldatud, et tagada et tõestusväärtusega andmeid ei saaks märkamatult kustutada. Kui rakenduses on S3 salastuse Täpsustuseks vt ISKE nõue HT.37. Mitte 3.19 astmega andmeid, peavad need arvestada olema nii transpordi ajal ja ka salvestatult alati krüpteeritult. Paksu kliendi korral ei tohi rakendus Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine Mitte 3.20 kasutaja tööjaama jätta maha tagamaks, et ei koormata liigselt kasutaja arvutit. arvestada krüpteerimata kujul ajutisi faile, mis sisaldavad või võivad sisaldada Nõude eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse konfidentsiaalse või kõrget terviklust maha informatsiooni, mida sinna jääda ei tohiks, sh pääsuandmeid, isikuandmeid, nõudvat informatsiooni. andmekogu sisulisi andmeid jms Rakendus ja selle komponendid Arendaja arendab arenduskeskkonnas ja annab tarne üle tellijale Arvestada OK OK 3.21 peavad võimaldama kasutada paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel keskkondade lahusust paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas. Üldjoones on kõik keskkonnad majutatud TEHIKu majutuses. Rakendus peab võimaldama Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi Mitte 3.22 hõlpsalt välja vahetada aegunud ja algoritme, vaid peaksid seda tegema vahendavate vaheteekide kaudu üldiste arvestada ebaturvalise krüptoalgoritmi. 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. Rakenduse andmebaasi Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid Mitte 3.23 krüpteerimisega seotud olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste arvestada andmeväljad peavad olema parameetritega krüpteerimisalgoritme. muudetava pikkusega.  4. Logimine Logimiseks tuleb kasutada Näiteks Java raamistikku log4j, SLF4J, logback, transpordiks syslog, fluentd; logi Arvestada OK OK 4.1 standardseid komponente kogu formaadiks JSON. Logi peab olema loetaval tekstilisel kujul, et logikirjeid saaks logiahela ulatuses. töödelda masinloetavalt ja inimloetavalt. 4.2 Logikomponent peab võimalama Näiteks logide saatmiseks syslog, fluentd või muu kokkulepitud meetod. Arvestada OK OK rakenduse administraatoril määratleda ja muuta logide väljundit, logimise taset ja logimise formaati. Logid peavad olema jaotatud Auditlogi (Seansilogi, tegevuslogi) - info sisselogimiste, väljalogimiste ja seansi Arvestada NOK NOK 4.3 loogiliselt. aegumiste kohta. Vigased sisselogimise katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega logimise katsed. Kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi. Tehniline logi - rakendusserveri poolt loodud logi Vealogi - erinevate veaolukordade info Silumislogi - arendajate jaoks vajalik debug info Logimine peab olema optimeeritud. Informatsiooni dubleerimist logides tuleb vältida, kui ei ole nõutud teisiti. Arvestada OK OK 4.4 Logides peab olema maksimaalselt Mitme realiste sündmuste puhul kasutada kodeerimist või JSON formaati. Mitme Arvestada OK NOK 4.5 üks sündmus ühel real. realiste sündmused võivad olla tehnilises-, vea- või silumislogis kui rakendusserver ei oska seda kodeerida. 4.6 Logikirje peab olema JSON Kui logikirje ei ole JSON formaadis, siis ühe ja sama sündmuse väljad peavad olema Arvestada OK NOK formaadis, kui ei lepita kokku teisiti. erinevates logikirjetes samas kohas. 4.7 Logiväljade nimed peavad olema Võimalusel tuleb aluseks võtta Elastic Common Schema. Näiteks samatüübilised Arvestada NOK NOK normaliseeritud. logiväljade nimed peavad olema ühtsed üle logi. 4.8 Rakendus peab logima kasutaja Logima peab ka autentimise ebaõnnestumise koos põhjusega (vale Mitte edukat ja ebaedukat autentimist ja juurdepääsumandaat, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui arvestada sessiooni lõpetamist, kasutaja IP ja võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID-kaardi puhul isikukood). autentimismeetodit (ID-kaart, mobiil- ID, Smart-ID vms), eduka autendi Kui rakendus kasutab kasutajate autentimiseks välist autentimise/autoriseerimise puhul tuleks logida ka kasutaja vahendit, siis leppida eraldi kokku autentimise detailsus ehk mida kajastatakse isikukood ja mobiil-ID ning Smart-ID autentimise/autoriseerimise vahendis ja mida rakenduses. puhul telefoninumber. Üle terve logi peab olema kasutaja Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Mitte 4.9 sessiooni käigus tehtud tegevusi või Selleks ei sobi kellaaeg, IP ega isikukood. Sobib näiteks unikaalne ID, mis ei tohi arvestada sama sündmust võimalik siduda olla sessiooni ID, sest seda saaks logist välja lugeda ja rünnakuks ära kasutada. loogiliselt kokku. Võib olla sessiooni ID räsi koos transaktsiooni ID'ga. Konkreetne lahendus tuleb valideerida TEHIKu arhitektiga. 4.10 Andmete loomise/vaatamise Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes, mida, Arvestada OK OK /muutmise/kustutamise tegevused kus, kust, millal, kuidas ja tulemus. peavad olema kajastatud logides. Logida tuleb ka päringud, mille vastus on puhverdatud. Administraatorite ja haldurite poolt Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise, Arvestada OK OK 4.11 tehtavaid andmete vaatamised, muutmise logimist ise (ka tavakasutajate logimist) deaktiveerida või logisid kustutada (v.a otse muutmised sh kustutamised (ka /muuta. baasis) otse baasis) tuleb logida. Muutmise puhul tuleb logida nii uus kui ka vana väärtus. Kui parameetri väärtus on tühi, tuleb Näiteks NULL Mitte 4.12 see logis märkida arvestada asendusväärtusega. Logis tuleb kõik mitte kuvatavad Näiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff. Mitte 4.13 (non-printable) sümbolid kodeerida. arvestada Rakendus peab logima kõiki Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack trace, Arvestada OK OK 4.14 rakenduses tekkivaid tehnilisi vigu. 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.15 Rakendus peab suutma logida kõiki Vajalik eelkõige silumiseks ja toodangu keskkonna probleemide lahendamiseks. Mitte X-tee teenuste kaudu liikuvaid arvestada andmeid. Peab olema võimalus logimist sisse-välja lülitada. Rakenduse funktsionaalsuse Mida logitakse, kuidas sündmused on logis jagatud, logiridade näited. Arvestada NOK NOK 4.16 kirjeldusega tuleb luua ka logimise dokumentatsioon ja loginäidised. Koos funktsionaalsuse arendamisega tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon. Dokumentatsioon peab sisaldama logis kasutatud klassifikaatorite kirjeldusi. 5. Testimine 5.1 Rakenduse kõik üleantavad Testitulemused tuleb edastada tellijale koos rakenduse üleandmisega. Vaata lisaks Mitte versioonid peavad enne tellijale üle nõuet 5.2 ja 5.3. arvestada andmist olema testitud 5.2 Lahendus peab olema minimaalselt Käivitatakse tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust Mitte 75% ulatuses kaetud automaatsete raporteeritakse lähtekoodi analüsaatoris (nt SonarQube). arvestada komponenditestidega (unit test). 5.3 Lahendus peab olema minimaalselt Käivitatakse tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust Mitte 50% ulatuses kaetud automaatsete raporteeritakse lähtekoodi analüsaatoris (nt SonarQube). arvestada vastuvõtutestidega. Rakendusega peab olema kaasas Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja Mitte 5.4 skript jõudlustestide tegemiseks. peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid arvestada kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. 6. Monitooring Rakendusel peab olema Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Arvestada OK OK 6.1 masinloetav testleht (health check) Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom nt JSON või XML formaadis. built rakenduse 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). 6.2 Rakendus peab pakkuma Näiteks Prometheuse formaadis monitooringu leht, kus näeb infot päringu kestuste Arvestada NOK NOK monitooringu lehte, kus leidub kohta, veakoodide ja nende hulka. Rakenduse mälu kasutamist jne. informatsioon rakenduse funktsionaalsuse toimimise kohta. 7. Nõuded rakenduse lähtekoodile Lähtekoodi kommentaarid peavad NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate Arvestada OK OK 7.1 kõigis lahenduse kihtides koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kolmandate (rakenduse enda kood, andmebaas osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad lahtise koodiga jne) olema kirjutatud inglise keeles. koodilõigud jms. Kui on tegu olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt. Lähtekoodi kommentaarid peavad Rakenduse kood peab olema piisavalt hästi kommenteeritud, et erialast haridust Mitte 7.2 olema selged, arusaadavad ja omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama. arvestada sisuliselt kirjeldama vastavat koodi, mille juures nad on ning moodustama vähemalt 20% koodi mahust. Muutujate, tüüpide ja funktsioonide Parim praktika Arvestada OK OK 7.3 nimed peavad olema sisulised ja andma aimu nende otstarbest. Koodis kasutatavad konstandid ja Nt Javas identifikaator --> ID Arvestada OK OK 7.4 lühendid tuleb kirjutada suurte tähtedega, lähtudes kasutatava programmeerimiskeele parimast praktikast. Koodis kasutatavaid konstante ei Arvestada OK OK 7.5 tohi selle kasutamise kohta väärtusena hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende. Koodis defineeritud andmetüübid N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi Arvestada OK OK 7.6 peavad olema nimetava käände kasutada täpitähti. ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms). Andmetabelites sisalduvad Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt Mitte 7.7 võõrvõtmed peavad nime järgi kui on tegu tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod. arvestada seostuma tabeli ja väljaga millele Isik_ID need viitavad. Andmebaasi väljade pikkused tuleb Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of Mitte 7.8 kirjeldada sümbolites, mitte baitides. allocating x bytes of storage for the field, x chars of storage must be allocated). arvestada Kui kokku pole lepitud teisiti, siis Checkstyle (http://checkstyle.sourceforge.net/) ei tohi käivitamisel järgmise Mitte 7.9 JAVA rakenduse kood peab olema konfiguratsioonifailiga väljastada ühtegi viga. arvestada kirjutatud vastavalt "Oracle Java Code convention" dokumendile. Kui kokku pole lepitud teisiti, siis http://www.python.org/dev/peps/pep-0008/ Mitte 7.10 Python rakenduse kood peab olema arvestada kirjutatud vastavalt "Style Guide for Python Code " dokumendile Kui kokku pole lepitud teisiti, siis . http://msdn.microsoft.com/en-us/library/ms229042.aspx Valideerimiseks kasutatakse Mitte 7.11 NET rakenduse kood peab olema 'StyleCop' vaikimisi konfiguratsiooni arvestada kirjutatud vastavalt "NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries". Koodi valideerimiseks kasutatakse Arvestada OK OK 7.12 minimaalselt TEHIK'u lähtekoodi analüüsi teenust. Kasutuses mitteolev kood tuleb Mitte 7.13 rakenduse lähtekoodist kõrvaldada. arvestada Arendamisel kasutatakse DRY ja http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Mitte 7.14 SOLID printsiipe http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) arvestada  Üleantavas koodis ei tohi olla Kehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb Arvestada OK OK 7.15 paroole, mida on kasutatud asendada fraasiga “<password>“. arenduse käigus Rakenduste lähtekoodi tasemel ei Eelpoolmainitu haldamine toimub failis või andmebaasis. Arvestada NOK NOK 7.16 tohi olla ühtegi sisse kodeeritud parameetrit, veateadet. 8. Andmekvaliteet ja standardid Aadressiandmete sisestamisel, Liidestatakse Maa-ameti ADS teenusega. Mitte 8.1 kuvamisel ja hoidmisel tuleb lähtuda arvestada Vabariigi Valitsuse määrusest Esitluskihis on lubatud liidestada In-ADS teenusega otsingu tarvis. "Aadressiandmete süsteem". Taustsüsteemides toimub liidestamine x-tee teenusega https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv Rakendus peab automaatselt Välja arvatud logimisvormi lahtrid autentimisel Mitte 8.2 eeltäitma kõik võimalikud arvestada andmeväljad, kui need andmed on Näiteks: kirje sisestamise kuupäev, kasutaja nimi, sünnikuupäev jne varem riigile esitatud või kui nende väärtused on võimalik automaatselt arvutada. Tegevusalade andmete Mitte 8.3 sisestamisel, kuvamisel ja hoidmisel arvestada tuleb lähtuda Vabariigi Valitsuse 10. Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. Tervishoiuteenuste osutajate Liidestatakse Terviseameti x-tee teenusega Mitte 8.4 andmete kasutamisel peab arvestada kontrollima nende andmeid, sh tegevuslubade kehtivust Terviseameti Tegevuslubade registrist Tervishoiutöötajate andmete Liidestatakse Terviseameti x-tee teenusega Mitte 8.5 kasutamisel peab kontrollima nende arvestada andmeid Terviseameti tervishoiutöötajate registrist Meditsiiniandmete vahetamiseks www.hl7.org Arvestada OK OK 8.6 tuleb kasutada meditsiiniandmete andmevahetuse standardit HL7 Vajadusel on lubatud ka teiste standardite kasutamine, kuid see tuleb tellijaga eraldi kokku leppida Tervise valdkonna klassifikaatorid Võimalusel tuleb kasutada olemasolevaid OID-e ja klassifikaatoreid, mida vajadusel Mitte 8.7 peavad olema kooskõlas Tellija OID- täiendatakse või luuakse uued ning publitseeritakse samuti publitseerimiskeskuses ht arvestada ide ja publitseerimiskeskusega tp://pub.e-tervis.ee 9. Kasutajaliides Kasutajaliidese kõik Mitte 9.1 disainiotsused peavad olema arvestada kooskõlastatud tellijaga enne nende realiseerimist Veebipõhine kasutajaliides peab Minimaalselt Microsoft Edge, Mozilla Firefox, Chrome ja Safari arenduse testimise Mitte 9.2 olema kasutatav enamlevinud hetkel tootja poolt toetatud versioonid. arvestada veebibrauseritega, sh nutiseadmetel (Android, IOS) Täpsemad nõuded dokumendis "Front-end arendusreeglid" Rakenduse värviskeem ja logo Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav SF Mitte 9.3 kasutamine peab vastama Tellija sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod arvestada ametlikule visuaalsele identiteedile (ka jpg-na) küsida tellijalt. (CVI) ja disainijuhistele (UIG). Kasutajaliidese kõik osad ja teated Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud Mitte 9.4 peavad olema eestikeelsed. hankedokumentides arvestada Avalikuks kasutamiseks tehtav Toetatud peavad olema vähemalt resolutsioonid: 1920x1200, 1920x1080, Mitte 9.5 rakendus peab olema graafiliselt 1680x1050, 1600x1200, 1440x900, 1360x768, 1280x1024, 1280x960, 1280x800, arvestada skaleeruv ja mugavalt kasutatav 1280x768, 1152x864, 1024x768, 1024x600. kõigi enamlevinud arvutite monitoride resolutsioonidega. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. Sisemiseks kasutamiseks tehtav Toetatud peavad olema töökohaprofiilis loetletud resolutsioonid. Mitte 9.6 rakendus peab olema graafiliselt arvestada skaleeruv ja mugavalt kasutatav Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. TEHIK'u töökohaprofiilis loetletud resolutsioonides. Hüpikaknaid (pop-up) ei tohi Silmas on peetud uusi veebilehtiseja aknaid avavaid hüpikaknaid Mitte 9.7 kasutada. arvestada Kasutajaliideses toiminguni (põhi- Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla Mitte 9.8 ehk enamkasutatavad tegevused) maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. arvestada navigeerimiseks peab kehtima 3 Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kliki printsiip, väljalogimiseks 1 kliki kohas. printsiip. Kasutajaliides peab alati küsima Mitte 9.9 kinnituse andmete kustutamise ja arvestada massmuutmiste kohta kui pole kokku lepitud teisiti.  Rakenduse kasutamisel tekkinud Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult lihtsalt Mitte 9.10 veale peab kasutajaliides vastama tuvastada vea olemuse ja asukoha. arvestada kasutajale eestikeelse kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. Veateated peavad olema hallatavad. Kasutajaliides peab olema ilma Uue keele lisamine peab olema teostatav konfiguratsiooni failist või Mitte 9.11 rakenduse koodi muutmata tõlgitav administreerimisliidesest. arvestada teise keelde, v.a kui ei ole kokkulepitud teisiti. Rakenduse tausta, menüüde ja Mitte 9.12 teksti värvid peavad olema ilma arvestada rakenduse koodi muutmata vahetatavad. Rakenduse kasutajaliides peab Ette teavitamise aeg peab olema konfigureeritav. Mitte 9.13 teavitama kasutajat ette sessioon arvestada aegumisest. Kui vormile sisestatakse mahukaid Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse Mitte 9.14 andmevälju peab kasutajaliides vorm etappideks ning salvestatakse vastava etapi lõpus. arvestada kokku lepitud ajavahemike järel salvetama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks. Sisestusvormidel andmete Mitte 9.15 sisestamisel peab saama väljade arvestada vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga. Interaktiivsete vormide puhul Mitte 9.16 (näiteks faili üleslaadimine), ei arvestada tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada). Kui päring võtab aega kauem kui 3 Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse või Mitte 9.17 sekundit, peab kasutaja saama muu tellijaga kokkulepitud indikaator. arvestada visuaalse teate, et süsteem tegeleb päringu läbiviimisega. Esilehel (sisselogimata) ja ka pärast Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli mingi uus Mitte 9.18 kasutaja sisselogimist peab olema funktsionaalsus, vahetage oma parool, uuendage isikuandmeid jne. arvestada lihtne võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav. Nutiseadmetele tuleb luua eraldi See vajadus spetsifitseeritakse arenduse tellimisel. Mitte 9.19 kohaldatud kasutajaliides. arvestada Päringu vastusena kuvatud tabeli Mitte 9.20 veerge on võimalik andmete/teksti arvestada tähestikulises järjekorras sorteerida. Andmeväljade kohustuslikkus peab Mitte 9.21 olema infosüsteemi väljadel arvestada märgitud tärniga (*). Rakenduse andmeväljade mõisted Mitte 9.22 peavad olema üheselt arvestada identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel. Kasutajaliides peab vastama ka Front-end arendusreeglid Mitte 9.23 dokumendis "Front-end arvestada arendusreeglid" kirjeldatud reeglitele. 9.24 Kasutajaliidesel peab olema Hooldusteate sisu, kuvamise aeg/periood peab olema seadistatav ja ei tohi nõuda Mitte hooldusteate võimekus. esitluskihi uuesti kobileerimist. arvestada Mõistlik on hooldusteate võimekiust juhtida taustteenuse abil. Näiteks läbi esitluskihi jaoks loodud seadete REST liidese. 10. Dokumentatsioon Lõppkasutajatele ja avalikkusele Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud tellija Mitte 10.1 suunatud rakenduse jaoks) dokumentatsioon. Samuti võib erandiks olla väliste osapooltega seotud arvestada dokumentatsioon peab olema projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni koostamist kirjutatud eesti keeles. Lahendus kirjeldatakse RIHA https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6 Mitte 10.2 määruse nõuete kohaselt. arvestada  Rakenduse dokumentatsioon peab Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori Arvestada OK OK 10.3 vastama ka dokumendis "Nõuded nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni infosüsteemi dokumentatsioonile" detailsus peab olema piisav, et sõltumatu kolmas tehnliste IT baasteadmistega isik kirjeldatud nõuetele suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi). Nõuded infosüsteemi dokumentatsioonile Rakenduse dokumentatsioon peab Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel- ja Mitte 10.4 sisaldama tabelite-andmete-logide detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arvestada mahu kasvu arvestuslikku hinnangut arhiveerimise tähtaegu. rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas). Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel. Arvestada OK NOK 10.5 tooma versiooni muudatuse kirjeldused (release notes). 10.6 Arendaja loodud lahenduse Mitte dokumentatsioonis (nt detailanalüüs arvestada vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh TLS sertifikaatide kasutuskohad. 11. Versioonihaldus Kogu rakenduse testimiseks, Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta Mitte 11.1 koolituseks või peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi arvestada implementeerimiseks üle antav juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi. lähtekood ja tarkvarapaketid peavad olema versioneeritud. Kasutama peab Tellija versioonihalduse ja tehiste (artifaktide) repositooriumi. Arendaja peab veenduma, et teeb Hea tava on, et paralleelse arendamise puhul võetakse igal hommikul Mitte 11.2 muudatusi aktuaalsesse koodi. versioonihalduse repositooriumist viimane seis koodist. arvestada Nii arendamisel kui ka Arendajale antakse selleks õigused Tellija tööde ja veahalduse keskkonda. Mitte 11.3 hoolduslepingute korral kasutatakse arvestada Tellija tööde ja veahalduse Veahalduse keskkonda juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi keskkonda. projektijuhi. 12. Paigalduspaketi kooste Juhul kui versioonihalduse Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi Arvestada NOK NOK 12.1 keskkond ei paku paigalduspaketile koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum.Arvest kontrollsumma (checksum) automaatset koostamist, siis koostatakse kontrollsumma arendaja poolt ja pannakse eraldi . sum failina tarnele kaasa. Tarnitava lahenduse koosseisus üle Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb Arvestada OK OK 12.2 antava lähtekoodiga peavad kaasas rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid olema kirjeldused sellest või mis iganes muu moodus paigalduspaketi tekitamiseks. paigalduspaketi koosteks. Eelistatud on kasutada Dockerfile ja Gitlab töövooge. Kooste kirjelduste alusel valmiv Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole Arvestada OK OK 12.3 paigalduspakett tohib sisaldada vajalik rakenduse käitamiseks. ainult minimaalse rakenduse käitamiseks vajamineva failikomplekti. Kooste kirjelduste alusel valmivat Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb Arvestada OK OK 12.4 paigalduspaketti peab olema see tingimata just sealsamas kokku kompileerida. võimalik liigutada erinevate masinate vahel. Rakenduse kõik sõltuvused peavad Arvestada OK OK 12.5 olema kompileerimisel saadavad Tellija tehiste repositooriumist. Andmebaasi paigalduse skriptid ei Administraator tahab veenduda skripti sisus. Arvestada OK OK 12.6 tohi olla kompileeritud. Rakenduse lähtekoodi juures peab Tellijal peab olema võimalik suuri pingutusi tegemata ja keskkonna erinevusi vältides Arvestada OK OK 12.7 leiduma skriptid rakenduse teha rakendusest paigaldatav pakk. keskkonnast sõltumatult (konteinerlahenduses) kokku kompileerimiseks. Rakenduse lähtekoodi juures peab Vajadusel peab konteinerlahendus käivitama ka rakenduse muud sõltuvused Arvestada OK OK 12.8 leiduma skriptid rakenduse (näiteks andmebaas). lokaalselt mõnes konteinerlahenduses (Docker) See on Täitjale uue meeskonnaliikme liitumise lihtsustamiseks ja Tellijale võimalus käivitamiseks. suuri pingutusi tegemata süsteemi testimiseks.  Paigalduspakett koostatakse Tellija Mitte 12.9 pideva integratsiooni (continuous arvestada integration - CI) ja paigaldus (continuous deploy - CD) arendus keskkonnas. 12.10 Kubernetesel (K8s) https://helm.sh/ Arvestada OK OK orkestreeritavate lahenduste paigalduste jaoks tuleb luua Helm Helmi jaoks kasutatava malli annab Tellija poolne arhitekt. chart. Hankija: Tervise ja Heaolu Infosüsteemide Keskus Pakkumusettepaneku nimetus: „Üleriigilise digiregistratuuri UX/UI“ Käesolevaga teeb Tervise ja Heaolu Infosüsteemide Keskus (hankija) Teile ettepaneku esitada pakkumus „Üleriigilise digiregistratuuri UX/UI“ teostamiseks raamlepingu nr 3-9/3050-1 alusel. Pakkumus tuleb esitada hiljemalt 01.11.2022 kell 23:59 e-posti aadressile [email protected]. Pakkumus tuleb esitada eesti keeles. Pakkumus esitatakse „Üleriigilise digiregistratuuri UX/UI“ tehnilises kirjelduses (lisa 1) kirjeldatud tööde teostamiseks. Alternatiivsete pakkumuste esitamine ei ole lubatav. Pakkumusena tuleb esitada: - Tööde teostamiseks planeeritud meeskonnaliikmed isikuliselt, tuues välja ka meeskonnaliikmete rollid (vajadusel võib tellimuse käigus Poolte kokkuleppel meeskonnaliikmeid lisada). Kui täitja lisab või asendab meeskonnaliikmeid, tuleb nende uute meeskonnaliimete kohta, kelle osas ei ole andmeid varem esitatud, lisada andmed riigihankes avaldatud vormil. Täitja saab tööde teostamisel kasutada üksnes selliseid meeskonnaliikmeid, kes vastavad riigihankes seatud tingimustele; - Ühe töötunni maksumus, mis ei tohi ületada raamlepingus pakutud ühe töötunni maksumust; - Tööde teostamise eeldatav maht tundides ja üleandmise etapid; - Kontaktisik ja kontaktandmed (e-posti aadress, telefon). Alltöövõtjate kasutamisel tuleb pakkumuses vastav info välja tuua. Küsimuste tekkimise korral palun võtke ühendust enne pakkumuse esitamise tähtaega aadressil [email protected]. Pakkumusettepanekuga koos edastatavad dokumendid: Lisa 1. Tehniline kirjeldus; Lisa 2. Hankelepingu projekt. Lisa 3. MFN Lisa 2 Hankelepingu projekt Tervise ja Heaolu Infosüsteemide Keskus, registrikood 70009770, aadress Pärnu maantee 132, 11317, Tallinn, keda esindab põhimääruse alusel direktor Margus Arm, (edaspidi tellija), ja BitWeb OÜ, registrikood 11737838, aadress Vallikraavi tn 2, 51003 Tartu, keda esindab põhikirja alusel Tõnis Tobre (edaspidi täitja), edaspidi eraldi pool või koos pooled, sõlmisid raamlepingu nr 3-9/3050-1 alusel käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu ese 1.1. Lepingu esemeks on pakkumuskutse tehnilises kirjelduses nimetatud tööd (edaspidi tööd). 1.2. Lepingu tööde teostamise aeg on 01.05.2023. 2. Töö üleandmise ja vastuvõtmise tingimused 2.1. Täitja annab töö üle hankelepingu p-s 1.2 märgitud ajal. 2.2. Tellitavad tööd antakse üle vastavalt lepingu tehnilises kirjelduses kokkulepitud tingimustele ja pakkumuses esitatud etappidele. 2.3. Tellija vaatab töö üle vastavalt raamlepingu tingimustele. 2.4. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused vastavalt raamlepingus kirjeldatule. 3. Lepingu hind 3.1. Ühe töötunni maksumus on ___ (maksumus sõnadega) eurot käibemaksuta. Tööde maksimaalne maht on kuni __ h. Tellija tasub reaalselt teostatud ja akteeritud töötundide põhiselt. 3.2. Täitja esitab tellijale e-arve pärast vastava osa töö üleandmise-vastuvõtmise akti allkirjastamist. 4. Poolte vahelised teated ja kontaktisikud 4.1. Teadete edastamisel ja kätte toimetamisel lähtutakse raamlepingu regulatsioonist. 4.2. Tellija kontaktisikuks lepingu täitmisel on Lembit Pirn, tel 5028707, e-post [email protected] või tema asendaja. 4.3. Täitja kontaktisikuks lepingu täitmisel on ________, tel ________, e-post ______ või tema asendaja. 5. Lõppsätted 5.1. Leping jõustub sellele poolte poolt allakirjutamise hetkest ja kehtib kuni poolte poolt oma lepinguliste kohustuste täitmiseni. Lisa 2 5.2. Lepingu dokumendid koosnevad riigihanke alusdokumentidest, sh lepingu lisadest, lepingu muudatustest ja pakkumusest. 5.3. Lepingu lahutamatuteks osadeks lepingu sõlmimise hetkel on järgmised dokumendid, mida ei allkirjastata koos lepinguga: 5.3.1. Lisa 1 - Tehniline kirjeldus; 5.3.2. Lisa 2 – Pakkumus; 6. Poolte allkirjad Tellija: Täitja: