Leping

Industry62 OÜ Samtrack I-etapi arendusplaan koos arendusmetoodika kirjeldusega Tallinn 2019 Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Sisukord Sisukord................................................................................................................................................... 2 Sissejuhatus............................................................................................................................................. 3 Samtrack I-etapi arendusplaan ............................................................................................................... 3 Arendusplaani selgitus ........................................................................................................................ 3 Arendusplaan tabelvaatena ................................................................................................................ 5 Continuous integration (CI) ja Continuous delivery (CD) rakendamine ............................................. 8 Samtrack I-etapi arendusmetoodika....................................................................................................... 9 Agiilne lähenemine ............................................................................................................................. 9 Arendusprotsessi kirjeldus ................................................................................................................ 10 Töö Tootekuhjaga ......................................................................................................................... 10 Arendustsükli ja sprindi planeerimine .......................................................................................... 11 Töövoo visualiseerimine ............................................................................................................... 12 Töö sprindi kestel .......................................................................................................................... 13 Sprindi ja arendustsükli lõpetamine ............................................................................................. 14 Retrospektiivid .............................................................................................................................. 14 UX ja disaini läbiviimise protsess ...................................................................................................... 15 Meeskond ......................................................................................................................................... 16 Industry62 meeskond ................................................................................................................... 16 Ootused TEHIK meeskonnale ........................................................................................................ 18 Riskid ja riskide maandamise ettepanekud ...................................................................................... 19 Arendusmetoodika Samtrack järgmiste etappide läbiviimisel. ............................................................ 21 Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Sissejuhatus Käesolev dokument selgitab, mida võeti arvesse Samtracki I-etapi arendusplaani koostades, tuuakse välja arendusplaan ise ning kirjeldatakse CI/CD rakendamist. Samuti kirjeldab dokument tarkvaraarendusprojekti läbiviimiseks kasutatavat metoodikat, töökorraldust ning neid toetavaid (tehnilisi) vahendeid. Samtrack I-etapi arendusplaan Arendusplaani selgitus Võtsime aluseks arendusplaani soovitusliku vormistuse, kuid tegime sinna mõningad muudatused. Arendusplaani näidises kasutatud mõistet „Töö“ on võimalik laialt tõlgendada. Tegemist võib olla süsteemianalüüsiga üldisemalt, või konkreetse funktsionaalsuse lõplikule kujule viimisega. Lähtusime „Töö“ defineerimisel tehnilises kirjelduses esitatud funktsionaalsuse kogumitest ja jaotasime tööd analüüsi- ning arendustöödeks. Üks annab teisele sisendi. Hindasime oma plaanis tervet arendustsükli mahtu ning praeguse parima teadmise kohaselt sinna sisse mahtuvaid töid. Meie hinnangul on praeguses ajahetkes iga detailsema nõude kohta maksumuse andmine keerukas, kuna funktsionaalsuse kogumid nõuavad täpsemat detailanalüüsi. Selguse huvides jaotasime arendustsükli arendustöödeks (back- ja frontend programmeerija) ning analüütikute töödeks. Arenduse tööde juurde on arvestatud lisaks testija tööd ning analüüsi juurde on arvestatud UX analüütiku ja veebidisaineri tööd. Täpsemad kasutusjuhu hinnangud tekivad arendustsükli planeerimise koosolekutel. Detailanalüüsi tööde käigus tekib esimeses arendustsüklis (eeldatavalt esimese kuu lõpuks) esialgne andmemudel, mis täieneb jooksvalt projekti väitel ning saab lõpliku viimistluse analüüsi lõpuks. Võimalikult varajane esialgse andmemudeli kirjeldamine võimaldab alustada arendustöödega. Paljudel juhtudel toimuvad konkreetse funktsionaalsuse kogumite arendamised erinevates arendustsüklites, ehk tööd tükeldatakse tsüklite vahel. Näiteks müügilubade arendus hakkab ühes tsüklis analüüsiga (sh kirjeldatakse kasutuslood ja ärireeglid, luuakse esialgne andmemudel, joonistatakse disainis rohkem lahti), esimeses ja teises tsüklis teostatakse Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com backend tööd ning teises kuni kolmandas teostatakse rakenduses frontend tööd. Valminud müügilubade funktsionaalsust täiendatakse järgnevates tsüklites teiste tööde käigus (näiteks juhtumid). Seega ühe nõuete kogumi tervikhinnang jaotub üle mitme tsükli. Arendusplaanis oleme arvestatud (enamikel juhtudel) kahe kuu pikkuste arendustsüklitega, mis omakorda jagunevad kahenädalasteks sprintideks (iteratsiooniks). Tööd on plaanis jagatud arendustsüklitesse. Töö tükeldatakse arendustsükli planeerimisel ning sprintide planeerimisel lisatakse ülesanne konkreetsesse sprinti. Arendustsükli kõrvale oleme toonud kuise vaate, mis annab parema ülevaate projekti käigust. Projektitöödeks on ette nähtud 9 arendustsüklit ning 18 kuud. Arendusplaanis on kajastatud suvine puhkuste periood, seega reaalselt toimuvad tegevused 16 kuul. Lisatud on kümnes arendustsükkel toodangus oleku kahe esimese kuu toetamiseks. Loomulikult sõltuvad kuu nimetused plaanis projekti alguse tähtajast. Oleme parima teadmise juures esimeseks töökuuks planeerinud märtsi 2020. Tegime seda tuginedes pakkumise tähtajale, eeldatava tulemuste selgumise ja omavahelise plaanide sünkroniseerimise ajale. Puhkusekuud on hetkel lisatud jäigalt, kuid täpsemad plaanid tehakse sedasi, et need ei mõjutaks üldist plaani. Arendusplaanis näeme ette, et kolmas osapool teostab turvatestimised 3-nda ja 7-nda arendustsükli ajal. Neljanda arendustsükli alguses on tuumikfunktsionaalsus valminud. Kaheksanda tsükli alguseks on tegevused peamiste funktsionaalsustega lõppenud, jäänud on olemasolevate teenuste ja funktsionaalsuste parandused ning parendused. Seega on sobilik aeg turvatestimiseks, mis jätab veel aega testimisel leitud vigade parandamiseks. Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Arendusplaan tabelvaatena Arendus- Kuu nr. Kuu Aasta Realiseeritavad kasutuslood/nõuded tsükkel Hind (km-ta) Frontend ja backend tööd Süsteemianalüütiku ja UX analüütiku tööd (sh disain) Kõikide arendusetappide üldine planeerimine, prioriteetide seadmine. Arendus- ja tarneprotsesside kokkuleppimine. Esimese arendusetapi detailsem planeerimine. Töökeskkondade paigaldus / tarne paigaldused Materjalidega tutvumine 1 märts 2020 Autentimise/autoriseerimise printsiibid. Autentimine Müügilubade funktsionaalsus 1 Esialgne raam, töötaja töölaua esialgne versioon Juhtumite haldus 87860 Müügiload Esialgne andmemudel Töökeskkondade paigaldus / tarne paigaldused Ravimi andmed (ravimikaart). Loendid (andmehaldus) 2 aprill 2020 Müügiload. Ravimikaart Dokumendihaldus Menetlusprotsessid (töövood, tähtaegsus, dokumendi mallid, etapid) Müügiload. Ravimikaart. Loendid (andmehaldus) Töötaja töölaud 3 mai 2020 Juhtumite haldus Päringute koostamine 2 99880 Juhtumite haldus Administreerimine 4 juuni 2020 Dokumendihaldus Kasutajate haldus, sh rollid ja rolligrupid 5 juuli 2020 puhkus Eestisisesed liidesed (SAP, Ravimiregister, 6 august 2020 Dokumendihaldus dokumendihaldus) 3 82120 Menetlusprotsessid (töövood, tähtaegsus, 7 september 2020 dokumendi mallid, etapid) Piiriülesed liidesed (CESP, CTS, SPOR) Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com  Menetlusprotsessid (töövood, tähtaegsus, 8 oktoober 2020 dokumendi mallid, etapid) Migratsioonitööde analüüs 4 64040 Turvatestimise vigade parandus 9 november 2020 Töötaja töölaud. Teavitused. Päringute koostamine 10 detsember 2020 Töötaja töölaud. Teavitused. Päringute koostamine 5 Kasutajate haldus, sh rollid ja rolligrupid. 57080 11 jaanuar 2021 Administreerimine Eestisisesed liidesed (SAP, Ravimiregister, 12 veebruar 2021 dokumendihaldus) Eestisisesed liidesed (SAP, Ravimiregister, 6 43880 dokumendihaldus) 13 märts 2021 Piiriülesed liidesed (CESP, CTS, SPOR). Loendid (andmehaldus) Piiriülesed liidesed (CESP, CTS, SPOR). Loendid 14 aprill 2021 (andmehaldus) 7 34600 Migratsiooni arendustööd (backend) 15 mai 2021 Teadete- ja modalite ühtlustamine (frontend) Turvatestimise vigade parandus 8 16 juuni 2021 Jõudluse optimeerimine 22020 Puhver 17 juuli 2021 puhkus Parandused / Turvatestimise parandused Peakasutajate kasutajakoolitused 9 18 august 2021 Juurutamise tugi 17700 Andmete migratsioon Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com  Puhver 19 september 2021 Toodangusse minek 19 september 2021 Toodangu tugi 10 19600 20 oktoober 2021 Toodangu tugi Esimese etapi maksumus kokku (ilma käibemaksuta) 528 780 € Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Continuous integration (CI) ja Continuous delivery (CD) rakendamine Projektis plaanime juurutada Continuous integration (CI) ja Continuous delivery (CD) printsiipe, mis mõlemad toetavad hästi agiilse protsessi metoodikat. CI/CD eelduseks on kõikide tarneahelas olevate rutiinsete ülesannete maksimaalne automatiseeritus ning vastavate töövahendite rakendamine. Automatiseeritud peaksid olema koodi kompileerimine, koodi kvaliteedi kontrollid, erinevate moodul-/integratsiooni testide jooksutamine, artefaktide koostamine ning paigaldused erinevatesse keskkondadesse. See omakorda seab suured nõuded nii koodi kvaliteedile kui ka testide kvaliteedile ning koodi kaetusele testidele – koodi testidega kaetuse tase peaks olema pideva jälgimise all. Nõutud on programmeerijate ja testijate (sh TEHIKU testija) vaheline pidev koostöö. CI/CD rakendamine jätab projekti meeskonnale võimaluse valida tarneprotsess, mis sobib projekti iseloomuga ja meeskonna vajadustega. CI/CD toetab nii pidevat valmisolekut viia toodangusse ridamisi väikseid muudatusi kui ka regulaarselt – näiteks iga kahe nädala tagant – toimuvat paigaldust. CI/CD rakendamisel kasutatakse GIT-i ja koodi harude (branch) haldamise metoodika valitakse selline, mis toetab valitud tarneprotsessi. Kasutusel on kindlasti ka koodi kvaliteedi tagamiseks levinud töövõtted – näiteks funktsionaalsuse arendamisel kasutusel oleva koodi haru ühendamisel (merge) pea-arendusharuga peaks toimuma läbi nn. pull requesti ning koodi muudatused peavad läbima koodi läbivaatuse (code review). Tarneprotsessi automatiseerimiseks kasutatakse vastavat keskkonda – GitLab Pipeline või samaväärne töövahend. Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Samtrack I-etapi arendusmetoodika Agiilne lähenemine Tellija on hankedokumendis soovinud, et töid teostataks agiilse arendusprotsessi põhimõtetele vastavalt. Definitsiooni järgi võib agiilseks nimetada sellist tarkvara arendusprotsessi, mis järgib Agiilse Manifesti väärtuseid ning kasutab meetodeid ja praktikaid, millised omakorda võimaldavad kiiret inkrementaalset arendust ja sagedast tarkvara tarnimist ning lõppkokkuvõttes peaks protsess tagama kliendi rahulolu. Kindlasti on Industry62 meeskonnal plaanis kasutada inkrementaalset arendust ja sagedast tarkvara tarnimist. Arendame tarkvara võttes kasutusele Scrum metoodikast tuntud rollid (Tooteomanik, Scrum Master, Arendusmeeskond), tseremoniaalsused (Sprint, Sprindi planeerimine, Stand-up (püstijala koosolek), Sprindi/arendustsükli ülevaatus ja Retrospektiiv) ning artefaktid (Tootekuhi (Product Backlog), Sprindi kuhi (Sprint Backlog) ja Inkrement (meie mõistes arendustsükkel)). Antud projekti puhul peame meetodit kohandama vastavalt projekti iseloomule ning piirangutele ja tõenäoliselt ei saa järgida kõiki Agiilse Manifesti printsiipe, kuna seda teatud olukordades ei ole võimalik teha. Peame arvestama sellega, et tegemist on fikseeritud eelarve ja ajaraamiga projektiga. Kliendi rahulolu võib saabuda nõude mitmekordsel itereerimisel, kuid piirangute tõttu tuleb mingil hetkel nõude arendamisele joon vahele tõmmata. Kindlasti järgitakse kliendi kaasatuse, maksimaalse inimeste vahelise suhtluse, töötava tarkvara ja muudatusele reageerimisele nõuet. Agiilsel lähenemisel järgime alljärgnevaid põhimõtteid: • Kliendi kaasatus. TEHIK meeskond peab olema arendusprotsessi tihedalt kaasatud. Ootame Tellija poolt valmisolekut tarkvara nõuete kirjeldamisel (tooteomaniku rollis), prioriteetide seadmisel, disainiotsustele kaasa rääkimisel, valminud funktsionaalsuse ülevaatamist ja operatiivset tagasiside andmist selle kohta, kuivõrd valminud tarkvaratoode vastab oodatule. • Inkrementaalne tarkavara tarnimine. Tarkvara plaanime arendada inkrementaalselt sprintide (iteratsioonide) kaupa. Iga sprindi käigus valmib sprindi alguses kliendiga kokku lepitud funktsionaalsuste hulk. Sprindid on pakendatud arendustsüklitesse, mille lõppemisel toimub valminud lahenduse demonstreerimine Tellijale. • Inimesed on tähtsamad kui protsess. Arendusmeeskonna kogemused ja oskused on väga olulised, kuna nendest suurel määral sõltub projekti produktiivsus ja edukus. Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com  Komplekteerime meeskonna, kes on omavahel juba koos töötanud ning võimelised ühise eesmärgi saavutamisel tegutsema. • Muutused on oodatavad. Tarkvara arendamisel oleme muutusteks valmis ning disainime tarkvara juba algusest peale selliselt, et muutusi tarkvara nõuetes oleks kerge sisse viia. • Tehniline tipptase. Agiilne tarkavaraarendus rõhutab kõrge kvaliteediga tarkvarakoodi tähtsust, kuna kvaliteetne ja hästi dokumenteeritud kood hõlbustab tarkvara tundma õppimist ning edasiarendust. Industry62 arendusprojekti on kaasatud pikalt oma valdkonnas töötanud inimesed, tuumikul on samuti pikaajaline ärivaldkonna kogemus. Arendusprotsessi kirjeldus Töö Tootekuhjaga Esialgsed tehnilised ning funktsionaalsed nõuded on kirjeldatud hankedokumendis. Detailanalüüsi käigus tekib tootekuhi (Product Backlog), mida hallatakse eraldi projektina TEHIK JIRA-s. Tootekuhi on tähtsuse järgi järjestatud nimekiri kasutaja lugusid, nõudeid ja vigu, alates süsteemi kõige väärtuslikumast kuni vähemväärtuslikuni. Tootekuhja kasutuslugu, funktsionaalne nõue, ülesanne või viga (bug) on eraldi JIRA pilet (issue). Suuremad teemad (näiteks analüüsid) saab koondada kokku kasutades JIRA-s olevat epic tunnust, seega on võimalik konkreetse epic-u staatust (kui palju on sellest valmis) jälgida. Esmase tootekuhja teevad Tellija Tooteomanik/Arhitekt ja Industry62 Analüütik/Arhitekt koostöös, lüües teemad eraldiseisvateks hallatavateks tükkideks. Industry62 analüütik/arhitekt kirjeldab nõude sisu tehniliselt arusaadavas keeles. Analüüsitavad nõuded kirjeldatakse tööhaldustarkvaras (JIRA) ja dokumenteeritakse Confluence-s (TEHIK wikis) kasutusloo ja ärinõude kujul. Kasutuslood registreeritakse Enterprice Arhitect (EA) keskkonnas jälgides üldiseid TEHIK printsiipe arenduste kasutuslugude kirjeldamisel. EA kasutamine võimaldab disainida ja visualiseerida kõiki TEHIK portfellis olevaid kasutuslugusid ning konkreetselt eraldi ka Samtrack kasutuslugusid. Peale nõuete kirjeldamist prioritiseerib Tellija Tooteomanik/Arhitekt ja Industry62 Analüütik/Arhitekt koostöös Tootekuhja tööd vastavalt, et tegevuste järjekord oleks loogiline. Aluseks saab võtta Industry62 poolt pakutava arendusplaani. Arendusplaanis on osad Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com arendustööd prioriteetsemad ja seega paigutatud ettepoole kuna need on terve projekti aluseks ja peavad kindlasti asetsema eespool (näiteks müügiload/juhtumid). Funktsionaalsete nõuete osas saab arendustsüklitesse paigutust (seega prioriteeti Tootekuhjas) muuta. Samas Industry62 plaan on koostatud lähtudes põhimõttest, et saaks töid teostada paralleelset. Tootekuhja prioritiseerimisel peab viimasega arvestama. Kõikide tegemata tööde nimekirja haldus on Tootekuhjas ja seda uuendatakse projekti käigus jooksvalt. Tootekuhjas ei saa muuta nõudeid, mis on juba käimasolevasse sprinti planeeritud. Tootekuhi peab olema uuendatud hiljemalt arendustsükli alguseks. Tootekuhja värskuse eest vastutab Tooteomanik. Vajadusel (kui meeskond, sh. Tooteomanik kes on meeskonna liige, peab seda vajalikuks) korraldatakse regulaarselt Tootekuhja uuendamise koosolekuid (Backlog Grooming). Groomingu tulemusel eemaldatakse mittevajalikud, lisatakse uued ja uuendatakse/poolitatakse olemasolevad kasutuslood/nõuded. Samuti muudetakse ülesannete prioriteete ja vajadusel määratakse töömahu hinnang (story points). Samtrack puhul on tegemist fikseeritud skoobi, mahu ja ajakavaga projektiga. Mahtu ja ajakava saab hoida ainult siis, kui skoop ei muutu. See tähendab agiilsest printsiibist kõrvalekallet, kuna sama ülesannet (nõudeid) ei itereerita üle mitme sprindi kuni kliendi täieliku rahuloluni. Tootekuhja paigutatud analüüsitud ülesande lahendus kinnitatakse Tooteomaniku poolt ning realiseeritakse. Kui siiski on vaja sama asja parendada (uuesti itereerida), siis pannakse ülesanne Tootekuhja ja läheb tegemisse prioriteetide alusel. Fikseeritud ajaraami tõttu võib see tähendada seda, et vähemtähtsad ülesanded jäävad tegemata või neile tuleb leida koht järgmises Samtrack etapis. Ajaplaanis on arvestatud ajapuhvriga lõputsüklites praegu ettenägematute tööülesannete täitmiseks. Arendustsükli ja sprindi planeerimise koosolekutel on ülesannete allikaks Tootekuhi seal tehniliselt valmis kirjeldatud ülesannetega. Arendustsükli ja sprindi planeerimine Sprindid on kahenädalased ja on pakendatud kahe kuu pikkusteks arendustsükliteks. Üheksa arendustsüklit moodustavad projekti ning üks tsükkel jääb toodangusse mineku toetamiseks. Sprindi lõpp on vahekokkuvõtte tegemise aeg käimasolevast arendustsüklist. Projekt algab esmase arendustsüklite planeerimisega, mille käigus jaotatakse Tootekuhjas olevad tööd tsüklite vahel (esmane Grooming). Selline lähenemine võimaldab jälgida jooksvalt Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com projekti liikumist esmase ajakava vastu ning hinnata, kui kaugele on töödega jõutud. See on oluline, kuna tegemist on fikseeritud ajakava ja mahuga projektiga. Esmase planeerimise käigus planeeritakse detailsem esimese arendustsükli plaan. Esimese arendustsükli tööd jagatakse nelja sprinti. Tööga seotakse meeskonna liige, st peale isikule omamist tekib meeskonnaliikme tööde nimekiri (Individual Backlog). Peale sprindi lõppu toimub järgmise sprindi (ümber)planeerimise koosolek. Sisuliselt vaadatakse üle, mis jäi esimesest sprindist välja, või mida võeti teisest sprindist lisaks. Vajadusel tõstetakse töid ümber, et teine sprint oleks täilikus mahus ning võimaldaks arendustsükli tulemusi selle lõpus Tellijale demonstreerida. Iga arendustsükli alguses on uus planeerimise koosolek, kus planeeritakse konkreetne arendustsükkel ja neli sprinti. Enne arendustsükli ja sprintide algust peab olema lõppenud töö Tootekuhjaga, st nõuded ja kasutuslood on uuendatud vastavalt viimasele olevale teabele. Tõenäoliselt toimub arendustsükli planeerimisel ka aktuaalsete (st arendustsüklisse ja sprinti planeeritavate tööde) ümberhindamine vastavalt kõige uuemale teabele. Sprindi planeerimisel eeldame, et nõuded on hästi defineeritud ning sprinti võetud nõuete mittemuutmine on tagatud. Vastasel juhul ei ole võimalik hinnata sprinti minevaid töid ega tagada nende valmimist. Planeerimise koosolekud dokumenteeritakse TEHIK wikis. Kui sprint on planeeritud, siis algab töö ülesannetega. Töövoo visualiseerimine Töövoo visualiseerimiseks kasutame Kanban-ist pärit metoodikat, st Tootekuhjas on piiritletud ülesanded ja loodud on tööülesande kohta kaardid (JIRA piletid) ja omistame piletile vastutaja(d). Piletid on nähtavad Kanban töölaual. Visualiseeritud töövoos olev pilet on paremini haaratav ja kontrollitav. Metoodika tagab korrapärase töövoo, prioriteetidest ülevaatlikkuse ning aitab ressursi ja tööde planeerimisel. Eesmärgiks peab olema Tootekuhja kirjeldada tööülesanded, mis oleks paremini hinnatavad (mahuga 1-2 tööpäeva). Kanban töölauda saab rakendada TEHIK kasutatavas JIRA-s. Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Töö sprindi kestel Sprindi kestel on kasutusel agiilsest metoodikast tulenev distsipliin Stand-up (püstijala koosolek), mis toimub iga päeva hommikul kestusega umbes 15 minutit. Koosoleku eesmärk on anda kiiresti ja tõhusalt ülevaade tehtust, edasistest tegevustest ning kõrvaldada võimalikud tekkinud takistused. Koosolekul osalevad kõik meeskonna liikmed (sh Tooteomanik), seega kõik liikmed on informeeritud hetkel toimuvast. Projekti edenedes võib stand-up koosolekute esinemissagedust muuta (näiteks üle päeva), kui meeskond niimoodi arendustsükli kokkuvõttes otsustab. Sprindi edenemiseks võib kasutada ka JIRA sprindi langustrendi graafikut (Sprint Burndown). Samuti võib kasutada ka JIRA-s olevat epic-u langustrendi graafikut. Samas igapäevased stand-up koosolekud, Kanban töölaua ning tööaja registreerimine peaks tagama sprindi käekäigust piisava ülevaate. Sprindi käigus toimub pidevalt valminud ülesannete testimine. Testija alustab tööd niipea, kui saab sprindi plaanis olevatest töödest midagi testida. Sprindi esimene pool võib kuluda eelmise sprindi tööde testimisele. Eesmärk on arendustsükli (inkremendi) lõpuks saada töötav kliendile tarnitav versioon. Analüütik (ja ka disainer) valmistavad järgmisteks sprintideks ette eeldusena olevad kasutuslood ja nõuete kirjeldused. Scrum masteri rollis olev inimene jälgib sprindi kulgu ning tegeleb takistuste eemaldamisega ja neile lahenduste leidmisega. Meeskonnaliige annab perioodiliselt infot töö edenemise kohta (täidab kas jooksvalt või päeva lõpus tööaega (JIRA-s Log Work). Koostöö sprindi ja arendustsükli vältel peab olema operatiivne. Vajadusel lepitakse asjaomastega kokku tehnilised koosolekud. Initsiatiivi võtab see, kellel koosolekut on vaja. Scrum Master rollis olev isik jälgib, et suhtlus ja kokku leppimine saaks toimima. Lisaks igapäevasele stand-up koosolekule ja e-kirjale suheldakse omavahel e-kanalis, mis on Tellijale samuti sobiv (kas Slack või Skype). Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Sprindi ja arendustsükli lõpetamine Sprindi lõpus tekib sprindis testitud töödest tarnitav tulem Tellijale. Tellija testija saab alustada käimasoleva arendustsükli testimistöödega. Samas tarnete sagedus lepitakse eraldi kokku projekti alguses (CI/CD rakendamise printsiibid), seega tarne võib minna ka kohe peale mingi kindla funktsionaalsuse valmimist ja Tellija testija saab alustada testimistöödega. Kui Tellija testijat tuleb tagasiside mittetoimivuse kohta, siis vaadatakse probleemi ulatust. Meeskond otsustab, kas see parandatakse koheselt või planeeritakse eraldi sprinti. Arendustsükli lõpus tekib tsükli töödest töötav tulem Tellijale. Tellija testija jätkab arendustsükli testimistöödega ja lõpetab vastuvõtutestid. Tellija testija peab kinnitama, et üleantud tööülesanded on tema poolt vastu võetud. Iga arendustsükli lõpus on Tellija esindajatele arendustsükli ülevaate koosolek (demokoosolek). Ülevaatusel demonstreerib arendusmeeskond tsükli jooksul valminud tarkvara osa. Tooteomanik kontrollib, et valminud funktsionaalsus vastab vastuvõtmise kriteeriumitele (acceptance criteria). Iga arendustsükli lõpus koostavad Tellija esindaja ja Industry62 esindaja akti Industry62 poolt üle antud ja Tellija poolt vastu võetud töödele. Retrospektiivid Arendustsükli lõpus koos arendustsükli lõpetamise koosolekuga või eraldi koosolekuna viiakse läbi Retrospektiivid, kus osaleb terve arendusmeeskond (sh. Tooteomanik). Retrospektiivil arutab arendusmeeskond mis läks hästi, mis ei läinud hästi ning milliseid parandustegevusi saab järgmises arendustsüklis ette võtta kõrvaldamaks tuvastatud probleeme/puudujääke. Näiteks, retrospektiividel vaatab meeskond üle kasutusel oleva arendusprotsessi ja analüüsib kasutusel oleva arendusmetoodika rakendamist. Eesmärgiks on tagada agiilse arendusmetoodika põhimõtete järgimine kujul, mis sobiks antud projekti kõige paremini. Selleks, et retrospektiiv tooks reaalset kasu, on väga oluline retrospektiivi tulemusi ja kokkuleppeid dokumenteerida ning määrata iga parendusettepaneku elluviimise eest vastutav isik. Nii on lihtsam järgmise retrospektiivi ajal probleemide staatust kontrollida ning vajadusel oma tegevusplaani korrigeerida. Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com UX ja disaini läbiviimise protsess UX kasutajakogemuse analüütik / disainer töötab koos detailanalüüsi läbi viiva analüütikuga. Disainimisel lähtume VEERA raamistikust, millega on meil eelnevatest projektidest kogemus. Allolevalt anname ülevaate analüüsis läbiviidavast UX ja disainimise tööprotsessist. Kaardistamine (UX etapp) • Lähteülesande täpsustus • Probleemi definitsioon • Teenuse olemasoleva info ja andmete kaardistus • Eesmärgid, vajadused ja pikem perspektiiv Kasutajad (UX etapp) • Kasutajaprofiilide ülevaatamine ja loomine • Kasutajatega intervjuud (vastavalt profiilidele) • Töö-flowde ülevaatamine • Kokkuvõtted Teekonnad ja prototüüp (UX etapp) • Kasutajate teekondade kaart • Struktuur ja sisustrateegia • Wireframe teekondadest ja vaadetest • Wireframe prototüüp Prototüüpi valideerimine (UX etapp) • Use Case loomine • Kasutajatestid ja intervjuud (vastavalt profiilidele) • Kokkuvõtted ja parandused prototüüpil Visualiseerimine (UI disain) • Visuaalne disain (vaated, elemendid, responsive) Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Visuaali testimine (UX disain) • Use Case • Kasutajatestid ja intervjuud (vastavalt profiilidele) • Kokkuvõtted ja parandused visuaalis Arendaja konsultatsioon • Juhend arendajale • Konsultatsioon projekti vältel Meeskond Tellija ja Industry62 rollid ja nende vastutuse ulatused. Industry62 meeskond Samtrack ülesande lahendamiseks koostatakse Industry62 poolt meeskond, kes katab ära terve arendusperioodi ning jääb hiljem rakendust toetama. Industry62 poolt tegeleb projektiga vähemalt 7 rolliga (liikmeid on rohkem) meeskond: projektijuht, analüütik, frontend programmeerija, backend programmeerija, arhitekt, testija, UX / disainer. Meeskond teeb ühte projekti, võtab selle eest vastutuse (ka liikme tasandil). Projektiliikmete koormus varieerub arendustsüklite kaupa ning planeeritakse vastavalt vajadusele projektijuhi ning tooteomaniku koostöös. Klassikaliselt agiilselt meeskonnalt oodatakse liikmelt kõikide vajalike oskuste olemasolu, näiteks tehniliste (programmeerimine, projekteerimine, testimine) või äriliste (valdkonna teadmine, otsuste tegemise oskus). Pakutav Industry62 meeskond jaguneb erinevatesse rollidesse, ehk erineb klassikalisest agiilse meeskonna ülesse ehitusest, st frontend programmeerija keskendub puhtalt Samtrack portaalile ja backend programmeerija teenusdisaini realiseerimisele (kuigi mõlema rolli programmeerijad on võimelised ka full-stack arenduseks ja saavad vajadusel üksteisele appi tulla). Testija testib mõlemat komponenti. Leiame, et selline meeskonna ülesse ehitus Samtrack ehitamisel on maksimaalselt efektiivne, kuna laseb meeskonna liikmel keskenduda just oma rolli võimalikul hästi täitmisele. Arhitekt vastutab süsteemide üldise arhitektuuri ja disaini eest. Arhitekt spetsifitseerib/valib tarkvara põhikomponendid ja nende omavahelise suhtluse. Tegeleb tehniliste lahenduste väljapakkumisega nõutud funktsionaalsuse realiseerimiseks koostöös süsteemianalüütiku ja Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com tooteomanikuga. Arhitekt roll vajab tihedat koostööd Tellija arhitektiga, kuna valitud komponendid ning arhitektuursed põhimõtted tuleb temaga kinnitada. Arhitekti roll on projekti startides asendamatu ning seega osaleb arhitekt aktiivselt projektis ning projektikoosolekutel. Roll olulisus ajapikku väheneb ning tõenäoliselt ei ole vajadust arhitekti kaasata ka igapäevastesse stand-upidesse. Küll aga osaleb arhitekt uute arendustsüklite planeerimisel. Arhitekti rolli täitev isik teostab ka backend arendusi. Analüütik kirjeldab koostöös kliendiga (võimalusel Samtrack tooteomaniku rollis oleva inimesega) süsteemi detailsemad nõuded (dokumenteerib), mis saavad sisendiks meeskonnale tööde hindamiseks ja töö teostamiseks. Analüütik suhtleb UX-veebidisaineriga analüüsi vältel, et kirja pandavad sammud saaksid loogilised ja visuaalis mõistlikult lahendatavad. Analüütik vastutab selle eest, et nõuded on arendusmeeskonnale tehniliselt arusaadavad, olles samas ka Tellijale arusaadavad. Selleks tuleb nõudeid analüüsida, spetsifitseerida ning koostada detailanalüüs. Lisaks pakub analüütik programmeerijatele ja TEHIK testijale igapäevast tuge, vastates nende küsimustele tööülesannete kohta ja täpsustades ärinõudeid tooteomanikuga. Vajadusel kuulub analüütiku tööülesannete hulka ka valminud tööde manuaalne testimine, süsteemi peakasutajatele tugiteenuste osutamine (sh. peakasutajate koolitused), valminud funktsionaalsuse dokumenteerimine ning vajadusel tarnete planeerimine koostöös tooteomaniku ja projektijuhiga. Veebidisainer töötab peamiselt koostöös analüütikuga, kuid pakub ka programmeerijatele igapäevast tuge visuaaliotsuste tegemisel. Tema ülesandeks on lahti joonistada analüütiku poolt detailanalüüsi läbinud tööülesanded, et frontend programmeerija saaks oma töödega alustada. Veebidisainer osaleb nendel projektikoosolekutel, mis on tema töödega seotud. Antud rolliga isik on esimeste arendustsüklite vältel projektiga aktiivselt hõivatud ning järgnevate tsüklite käigus lisandub vajadusel. Testija roll on oluline kvaliteedi tagamiseks ja kindlustamaks, et loodud tarkvara vastab Tellija ootustele. Testimise planeerimine algab juba nõuete spetsifitseerimise faasis, kus luuakse testimise plaan. Testiplaan kirjeldab testimismetoodika, testimise ulatuse ja testimise lõpetamise kriteeriumid. Testija kirjeldab testijuhtumid funktsionaalsete nõuete ja kasutuslugude põhjal. Testijuhtumid on alus süsteemi testimiseks. Testijuhtum koosneb kirjeldusest, eeltingimustest ja sammudest, mis kirjeldavad tehtavaid tegevusi ja oodatavaid tulemusi. Automaattestide kirjutamisel teeb testija tihedat koostööd analüütiku ja programmeerijatega tagamaks automaattestide usaldusväärsust ja kvaliteeti. Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Testimisega saab alustada kohe, kui esimene töötav versioon tarkvarast on valmis. Testimine koosneb tsüklitest – testimine, vigade raporteerimine, vigade parandamine ja paranduste üle testimine. Projektijuht soodustab meekonna liikmete vahelist koostööd ning pidevat suhtlemist. Põhiülesandeks on arendusmeeskonna töö organiseerimine, s.h. erinevate organisatsiooniliste küsimuste lahendamine, igapäevast tööd segavate takistuste elimineerimine, konfliktide lahendamine, juhtkonnale raporteerimine jms. Lisaks vastutab projektijuht selle eest, et kõigil meeskonna liikmetel on tööülesanded alati olemas. Vajadusel tegeleb projektijuht ka süsteemide testimise ja dokumenteerimisega. Scrum Master kui roll on Samtrack projektis olemas isegi siis, kui ei järgita täielikult Scrum praktikaid. Scrum Master vastutab agiilse protsessi järgimise eest. Scrum Master-i rolli täidab enamjaolt projektijuht, kuid vastavalt metoodikale võib seda rolli projektis täita ükskõik kes. Ootused TEHIK meeskonnale Kuna Industry62 ja samuti agiilsed meetodid eeldavad tihedat koostööd kliendiga, on oluline, et Tellija tunneks tõelist huvi arendatava tarkvara vastu ning Tellijal oleks aega arendusprotsessis aktiivselt osaleda ning arendusmeeskonnale tagasisidet anda. Tõstaksime eriti esile alljärgnevad rollid. Ootame, et TEHIK võtab omaltpoolt kanda Samtrack Tooteomaniku rolli. Tooteomanikul on selge nägemus, milliseid funktsionaalsusi ning millisel kujul peaks Samtrack omama, et see vastaks lõppkasutaja ootustele. Tooteomanik näeb nii suurt pilti, kui ka oskab tähele panna detaile. Samuti oskab tooteomanik näha seoseid süsteemide ja protsesside vahel, st tähtsaks ülesandeks on ka süsteemide sõltuvuste haldamine tihedas koostöös integreeritud naabersüsteemide tooteomanikega. Tooteomanik on täieõiguslik meeskonna liige ja Industry62 meeskonna esimene kontakt Tellija poolelt. Tooteomanik osaleb planeerimiskoosolekutel, igapäevastel stand-up koosolekutel (võib osaleda üle Skype), funktsionaalsuse kokkuleppimisel, lahenduse demodel jne. Tooteomaniku ülesanne on aidata arendusmeeskonnal seada erinevate tööülesannete prioriteete. Arenduse käigus küsimuste, mitmeti tõlgendatavuste, visuaalselt erinevate lahenduste võimaluste jm tekkides peab Tooteomaniku roll aitama lahendusteni jõuda (leides sobiva inimese vastama, kohtudes huvigrupiga, organiseerides juhtrühma koosoleku jne). Tooteomanik võtab vastutuse kokku Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com lepitud lahenduse (analüüs ja disain) eest. Tooteomanik kontrollib ja kinnitab, et valminud funktsionaalsus vastab vastuvõtmise kriteeriumitele Ootame TEHIK arhitekti aktiivselt kaasa lööma rakenduse arhitektuuri välja mõtlemisel ning ettepanekute edastamisel. Tellija arhitekt on meeskonna liige, kes osaleb vajadusel koosolekutel Tooteomaniku kutsel. Arhitektuurilised lahendused lepitakse Tellija arhitektiga kokku ning koostöös püütakse leida kõige sobivam hankes seatud ülesande realisatsioon. Töö tegemisel lähtutakse hankes seatud nõuetest, kuid vajadusel tehakse arhitektuursed muudatused, mille peab kinnitama ka Tellija arhitekti. Tellija testija testib valminud arendusi ja kinnitab nende vastavust tehnilisele püstitusele. Annab Industry62 meeskonnale operatiivset tagasisidet. Testija osaleb vajadusel meeskonna koosolekutel (näiteks stand-upidel Tooteomaniku kutsel). Riskid ja riskide maandamise ettepanekud Riski kirjeldus Tagajärjed Maandamis-meetmete kirjeldus realiseerumisel Arendusvõimekus on Lahendus ei valmi Projekt on jagatud arendustsükliteks, madal ajaliselt ettenähtud seetõttu nihked ajakavas ilmnevad tähtajaks arendustsüklite planeerimisel ning täitjal on võimalused ja valmisolek suurendada projektimeeskonda. Lisaks sisalduvad projektiplaanis ajalised puhvrid. Ilmnevad süsteemiga Lahenduse Projektiplaani on lisatud ajaline puhver; seotud ootamatud valmimine venib muudatuste halduse metoodikas lepitakse kulud Tellijale (näiteks ning võib tekkida kokku; arendatakse iteratiivselt, projekti käigus vajadus iteratsioonide lõpus jälgitakse eelarves vajadused muutuvad, täiendavate püsimist. mis muudab projekti eelarveliste skoopi) vahendite järele Esialgse planeeritud Valmib nõuetele Testimisel algavad juba esimeses meeskonna oskused mittevastav arendustsüklis ning vaadatakse jooksvalt osutuvad projekti süsteem või ei üle ajakavas püsimist. Samuti viiakse läbi teostamiseks suudeta ajakavast igapäevaseid stand-upe, kus ilmnevad ebapiisavaks kinni pidada varakult keerulised probleemid, millele Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com  saab seejärel lahendusi otsida väljastpoolt projektimeeskonda.. Tellija ei ole rahul Tulemus ei rahulda Tellija Tooteomanik on meeskonna liige ja jooksvalt esitatavate Tellija vajadusi igapäevaste otsuste juures, seega on ta tulemitega lahendusega kursis ja saab jooksvalt anda oma tagasiside. Iga arendustsükli lõpus on kliendidemo, kus tutvustatakse kliendile valminud lahendust. Täitja meeskonnal Ei realiseerita Meeskonda kaasatakse projektiga seotud puudub motivatsioon parim lahendus; aruteludesse, jälgitakse, et ei tekiks otsida proaktiivseid tulemus ei rahulda ülekoormust ning kõigi ettepanekute ja lahendusi Tellija vajadusi arvamustega arvestatakse/arutatakse läbi. Tellijalt tulnud Ei suudeta kinni Muudatuste haldamiseks kasutatakse muudatussoove ei pidada ajakavast korrektseid muudatuste haldamise hallata korrektselt ja/või eelarvest meetodeid. Kõik muudatused ning puudub registreeritakse ning analüütik haldab ülevaade nende ülevaadet. muudatustest Tellija ei jätku ressurssi Täitja ressurss on Tellija planeerib projekti piisava ressursi. projektiga tegeleda tühjalt ootel ning Tellija leiab ressursi vajalikeks projektiga (sprindi) tähtaegu seotud tegevusteks (testimine, pole võimalik täita ülevaatused jms) Tellija või ärinõude Täitja ressurss on Tellija planeerib projekti piisava ressursi. lõpptarbija ei reageeri tühjalt ootel ning Tellija informeerib huvigruppe projekti päringutele/küsimustele (sprindi) tähtaegu toimumisest ning sõlmib kokkuleppe või tema vastused ei pole võimalik täita operatiivselt vastamiseks. anna vajalikku infot Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com Arendusmetoodika Samtrack järgmiste etappide läbiviimisel. Samtrack järgmiste etappide teostamisel järgitakse välja kujunenud parimat agiilset praktikat. Vajadusel muudetakse töötamise metoodikat. Uute etappide väljakutseteks on olemasolev toodangus olev Samtrack ning uue etapi tööülesanded läbisegi eelmiste etappide parandusülesannetega. Seega üks sprint võib sisaldada nii eelmise etapi parandusi kui ka uue etapi tööülesandeid. Industry62 OÜ Reg. no. 11124544 +372 6505050 Toompuiestee 35 VAT EE101014733 [email protected] 10133 Tallinn, Estonia IBAN EE167700771002430211 industry62.com  Infosüsteemi SamTrack I-etapi arendustööd Hankelepingu lisa 3-9/2203-2 Tehniline kirjeldus Sisukord: Infosüsteemi SamTrack I-etapi arendustööd ............................................................................. 1 Tehniline kirjeldus ............................................................................................................................. 1 1. Hankelepingu objekt ..................................................................................................................... 2 2. Hanke eseme kirjeldus ................................................................................................................. 2 3. Hankelepingu skoop ..................................................................................................................... 2 4. Tööde teostamise põhimõtted ................................................................................................... 4 6. Lisad .................................................................................................................................................. 5 Lisa 1.1 Samtracki nõuete kirjeldus ......................................................................................... 5 1 1. Hankelepingu objekt Hankelepingu eesmärk on teostada infosüsteemi Samtrack I-etapi funktsionaalsuse arendustööd, lähtudes käesolevas dokumendis ja selle lisas toodud tehnilistest nõuetest. Hankelepingu tulemusena peab valmima uus infosüsteem, mille arendus peab vastama järgmistele nõuetele:  teostatakse veebipõhise rakendusena, mille vaated kohalduvad lõppkasutajate seadmetele;  arvestab teenuspõhise arhitektuuri nõuetega;  kasutab X-tee liidestust, mis tagab ravimite andmete ajakohasuse ravimiregistris; retseptikeskuses ja ravimite käitlejate andmebaasides;  võimaldab liidestamist rahvusvaheliste teenustega (tehniline lahendus selgub arenduse käigus, XML-l põhinev);  võimaldab paberivaba ning automatiseeritud asjaajamist;  võimaldab olemasolevates süsteemides menetluses olevate ja kehtivate müügilubade ja ravimipakendite andmete ja pakendikoodide ülekandmist juurutamise käigus. Hankelepingu täitmise periood on vastavalt riigihankes esitatud pakkumusele 16-18 kuud. 2. Hanke eseme kirjeldus Hankelepingu täitmise tulemusena peab valmima uus infosüsteem. Infosüsteemi Samtrack terviklahenduse loomiseks on planeeritud käesoleval ajal kolm arendusetappi, millest iga eeldatavaks ajaliseks kestuseks on 16-18 kuud (koos turvatestimise ja vigade parandusega). Käesoleva hankelepingu täitmise tulemusena realiseeritakse esimene arendusetapp vastavalt järgnevalt kirjeldatud skoobile. Infosüsteemi Samtrack I-etapi tööde hulka kuuluvad analüüsitööd (sh UX/UI analüüs), arendustööd arvestades analüüsi tulemitega, teostatud arendustööde testimine, teostatud tööde kohta dokumentatsiooni koostamine, testimiste käigus väljatulnud vigade parandamine. 3. Hankelepingu skoop Tehniliselt on tööde teostamise aluseks raamlepingu tehnilise kirjelduse lisa 1.1 „Samtrack arhitektuur“. Funktsionaalse poole pealt on tööde dokumenteerimisel aluseks raamlepingu tehnilise kirjelduse lisa 1.4 „Nõuded infosüsteemi dokumentatsioonile“. Samuti peab pakkuja arvestama tellija IT-profiili ja teistes raamlepingu lisaks olevates dokumentides toodud nõuetega. Tööde teostamisel tuleb lähtuda käesoleva dokumendi lisaks olevast dokumendist „Samtrack nõuded“. 3.1. Arendustööde I-etapi tulemusena tuleb arendada toimiv infosüsteem koos järgnevate teenuste ja nende funktsionaalsusustega: 3.1.1. Ravimite müügilubade taotluste menetlemine ja müügilubade andmine:  Müügiloa taotluse sisestamine ja registreerimine  Müügiloa taotluse esmane hindamine  Ravimipakendite kodeerimine 2   Müügiloa arvete koostamine ja edastamine (liides Riigi Tugiteenuste Keskuse SAP andmebaasiga)  Müügiloa taotluse sisuline hindamine  Müügiloa otsuse tegemine  Müügiloa otsuse avalikustamine avalikus dokumendiregistris ja ravimi andmete edastamine ravimiregistrile. 3.1.2. Üldised funktsionaalsused:  Andmehaldus  Sünkroniseerimisteenus EL andmekogudega  Menetlusprotsessid (etapid ja dokumendimallid, töövood)  Kasutajate haldus, sh rollid ja rolligrupid  Menetluste tähtaegsuse mõõtmine  Päringute koostamine  Dokumendihaldus. 3.1.3. Liidestused järgmiste infosüsteemidega:  Riigi Tugiteenuste keskuse andmebaasiga SAP (x-tee liides, mille kaudu edastatakse arvete info)  Ravimiameti avalik dokumendiregister (ei ole x-tee liides)  Ravimiregister (x-tee liides, mille kaudu edastatakse andmed ravimiregistrile ja sealt Retseptikeskusele ja ravimite käitelejatele). Tegemist on infosüsteemidega, millega olemasolev Samtrack on liidestatud. Hankelepingu täitmise käigus tuleb luua samad liidestused uuele infosüsteemile ja neid testida. Väliseid infosüsteeme muutma ei pea. 3.1.4. Infosüsteemid, millega olemasoleval Samtrackil liidestus puudub, kuid mis tuleb hankelepingu täitmisel uue Samtrackiga liidestada:  Common European Submission Portal ehk CESP - EL ravimiametite portaal, mille kaudu esitatakse müügiloa taotlused ja seotud materjalid  Communication and Tracking System ehk CTS - Euroopa keskne taotluste menetlussüsteem, sisaldab ajagraafikuid, ravimiametite kommentaare protseduuride kohta ja menetluse käigus loodud dokumentide versioone (sh lõplikud heakskiidetud ravimiinfod ja avalikud hinnanguraportid)  Euroopa Ravimiameti andmehaldussüsteem ehk SPOR – terminite, organisatsioonid ja ainete loendid EL loendid, mida Samtrack kasutab. Neid termeineid peab saama alla laadida ja sünkroniseerida. 3.1.5. Olemasolevast infosüsteemist Samtrack tuleb üle tuua järgmised andmed:  Kehtivate müügilubade andmed  Menetluses olevate müügiloa taotluste andmed  Kõikide ravimite pakendid, mis on kunagi välja antud. 3 Andmete ülekandmise käigus tuleb täitjal andmeid parandada, et need vastaks SPORis olevate andmete struktuurile ja oleksid vastavalt kodeeritud. Projekti käigus tuleb luua lahendus, et ravimiregister oskaks müügiloaga ravimite andmeid võtta uuest ravimite infosüsteemist, müügiloata ravimite andmeid aga vanast infosüsteemist, kuni Samtrack arenduse müügiloata ravimite teenus saab valmis (teenuse arendus on planeeritud realiseerida järgnevates arendusetappides). 4. Tööde teostamise põhimõtted Töid teostatakse vastavalt järgnevatele arendusprotsessi põhimõtetele. 4.1. Arendustööde teostamine hankelepingu raames on jagatud arendustsükliteks vastavalt täitja esitatud pakkumusele. Igas arendustsüklis peab valmima töötava tarkvara kogum, mida on võimalik kasutusele võtta. Ühe arendustsükli hinnanguline kestus on 4 - 8 nädalat. Arendustsüklid on omakorda jagatud sprintideks, millest iga hinnanguline kestus on 2 nädalat. Iga sprindi lõpus peab toimuma tööde tarnimine ja testimine. Testimisel kontrollitakse tellija poolt (vähemalt) funktsionaalsuse vastavust Samtrack nõuete dokumendis kirjeldatud aktsepteerimise kriteeriumitele. 4.2. Täitja poolt tehtud tööde tulemusena antakse iga sprindi lõpus üle: 4.2.1. Töötav (testitav) tarkvara koos testraportite ja testlugudega; 4.2.2. Tarkvara juurde kuuluv dokumentatsioon, sh juhendmaterjalid. 4.3. Arendustööd tuleb täitja poolt enne tellijale üleandmist testida, viia omaalgatuslikult ellu vajalikud parandused ning koostada testiraportid ja testilood. Tööde tarnega antakse tellijale üle töödega seotud dokumentatsioon (detailne kasutusjuhend, rakenduse administreerimisjuhend, paigaldusjuhend, andmevahetusteenuste kirjeldus, arhitektuuri kirjeldus, andme- ja komponentmudel, kommenteeritud lähtekood, testiraportid, testilood ning vajadusel testiskriptid), mis lisatakse tellija versioonihalduse keskkonda. Ligipääs vajalikele keskkondadele ja ligipääsu tehnilised tingimused jmt täpsustatakse tööde teostamise käigus. 4.4. Arendustsükli tööde nõuetele vastavuse ja kvaliteedi kontrollimiseks teostab tellija vastuvõtutestid. Kui konkreetse arendustsükli töö või mistahes selle osa ei läbi teste, kohustub täitja tegema üle antud töödes vajalikud parandused. Parandatud tööde osas viib tellija tööde üle andmise järgselt läbi kordustestid. Tellija ei kohustu vastu võtma töid, mis ei ole vastuvõtutestimist vigadeta läbinud. 4.5. Teostatud töödele kehtib garantii, mille täpsed tingimused on fikseeritud raamlepingus. 4.6. Hankelepingu täitmise käigus luuakse uus infosüsteem, osa andmeid (vt punkt 3) tuleb andmete ülekanne uude infosüsteemi hetkel kasutusel olevast (vanast) infosüsteemist. Tulevikus jääb kasutusele ainult uus infosüsteem. Andmete migreerimiseks tuleb vana süsteemi andmete kvaliteet viia vastavusse uue süsteemi nõuete ja struktuuriga, selleks:  tagab tellija juurdepääsu olemasolevasse andmebaasi ja ülekandetabelite kirjelduse;  migreerib täitja andmed loodud infosüsteemi. Ülekande lahendusest tingitud vigade korral kordab täitja migratsiooni selle õnnestumiseni. 4.7. Infosüsteemi peakasutaja kasutajakoolitused viib läbi täitja, edasised kasutajakoolitused viib läbi infosüsteemi peakasutaja, kaasates vajadusel täitja töötajaid, enne tarkvara live-keskkonnas kasutusele võtmist. 4.8. Pakkuja peab arvestama sellega, et arendustööde teostamise hilisemas arendustsüklis võib olla vajalik varem realiseeritud funktsioone muuta, täiendada või ümber kirjutada. 4.9. Lisaks täitja ja tellija poolt läbi viidavatele testidele peab loodav tarkvara läbima ka turvatestid vastavalt OWASP ASVS 3.0 tase 2 metoodikale. Turvatestimine viiakse läbi kolmanda osapoole poolt ning tellitakse tellija poolt eraldiseisvalt. 4  4.10. Riigihankes pakkumusena esitatud arendusplaan ei ole siduv. Tellija hindab hankemenetluses eelkõige pakkuja arusaama ja valmisolekut tööde teostamiseks. Esitatud arendusplaan vaadatakse poolte vahel üle enne hankelepingu täitmisega alustamist ja lepitakse kokku täpne arendusplaan, mis kujuneb tööde teostamisel aluseks. Nimetatu käigus ei muudeta pakkumusena esitatud tööde kogumaksumust ja teostamise lõpptähtaega. 4.11. Poolte kokkuleppel võib arendustööde käigus tulenevalt agiilse arenduse põhimõtetest arendusplaanis toodud tegevuste järjestuses (ja sellest tulenevalt ka arendustsüklite töömahus) teha muudatusi (nt muuta tööde teostamise järjekorda), kui see ei mõjuta hankelepingu eesmärgi täitmist, mahtu, lõpptähtaega ega kogumaksumust. Arendusplaani selliseid muudatusi ei käsitleta hankelepingu muudatustena, kuna sellest ei muutu hankelepingus fikseeritud kogumaksumus ning riigihanke alusdokumentides ja tehnilises kirjelduses soovitud saavutatav eesmärk. Arendusplaani muudatused lepitakse kokku poolte kontaktisikute vahel kirjalikku taasesitamist võimaldavas vormis. 4.12. Pakkumusega esitatud arendusmetoodika kirjeldus peab olema kooskõlas käesolevas dokumendis esitatud nõuetega ja on aluseks arendustööde tegemisel ja hankelepingu täitmisel. 4.13. Selleks, et kindlustada mõlemapoolne ülesannete ja vastutuse üheselt mõistmine, on töökoosolekute protokollimine ja kokku lepitud tööülesannete kirjeldamine täitja kohustus. Täitjal on kohustus osaleda operatiivselt tellija korraldatud töökoosolekutel. Töökoosolekutel osalemine (sh protokollimine) on hankelepingu täitmise osa ja ei kuulu eraldiseisvalt tasustamisele. 4.14. Samtrack arendustööde teostamisel tuleb arvestada ISKE turbeklassiga K1T2S2. 5. Tulemite vastuvõtmine 5.1. Tööde teostamine ja tarne toimub arendustsüklite kaupa, sh on igas arendustsüklis hõlmatud arendustööde teostamine, täitja poolne testimine, dokumenteerimine ja tarne paketeerimine, mis vastavad lähteülesandele. Iga etapi tarnele järgneb tellija poolne vastuvõtutestimine. Täitja peab lõpliku veebirakenduse kujunduse kooskõlastama tellijaga, muuhulgas peavad rakenduse avalehel kajastuma ka Euroopa struktuurfondide logod. 5.2. Enne lõplike tulemite vastuvõtmist, peab projekti juhtrühm olema kinnitanud, et tulemid vastavad lähteülesandele. Lõplikuks tulemiks on skoobile vastavalt toimiv tarkvaralahendus koos selle juurde kuuluva dokumentatsiooni ja kasutusjuhenditega, andmete migratsioon vanast Samtrack infosüsteemist on edukalt teostatud ning läbi on viidud kasutajakoolitused, misjärel on võimalik arendustööd vastu võtta. 6. Lisad Lisa 1.1 Samtrack nõuded 5  Rollide nimetused Administraator - TEHIK Administraator - Ravimiamet Sisestaja CTS sisestaja - RMS EURS sisestaja Valideerija Arved Hindaja määraja - Kliiniline koordinaator Hindaja - Koordineerija Hindaja - Ravimi kvaliteet Hindaja - BE Hindaja - Kliiniline Hindaja - Mittekliiniline Hindaja - Pakendimärgistus Hindaja - Ravimiohutus Hindaja - ERA Hindaja - User testing Osakonna juhataja Büroo juhataja ML muutuste allkirjastamine ML komisjoni koordinaator ML Otsuste allkirjastaja CTS andmete haldaja - CMS Loendite administraator ("data steward") Selgitused Tehniline administraator Protsesside muutmine, mallide tegemine, kasutajate haldus jne Esmaste, uuendamiste ja muutuse taotluste, vastuste, kirjade ja muu sissetulnud info sisestamine SamTracki RMS esmaste, uuendamiste ja muutuse taotluste protseduuride loomine CTSis eCTD formaadis saadetiste EURSi sisestamine Esmane hinnang Esmased, muutused, uuendamised, aastamaks Kliinilise hinnangu koordineerija Protseduuri koordineerija Kvaliteedi hinnangu teostaja Bioekvivalentsusuuringu hinnangu teostaja Kliinilise hinnangu teostaja Mittekliinilise hinnangu teostaja Pakendimärgistuse hinnangu teostaja Ravimiohutuse hinnangu teostaja Keskkonnariskide hinnangu teostaja User testingu hinnangu teostaja Hinnangu teostajate määramine, ülevaated, statistika Hinnangu teostajate määramine, ülevaated, statistika ML muutuste otsuste allkirjastamine Komisjoni raportid, ML vormistamine, infode haldamine; ravimiregister Müügiloa otsuste allkirjastamine CTS protseduuride ajakava ja staatuste märkimine SamTracki CMS taotluste puhul Loendite haldamine (terminite muutmine, lisamine, tõlked)  SAMTRACKI NÕUETE DOKUMENT 1 Peamised üldised funktsionaalsed nõuded uuele infosüsteemile .................................................. 3 1.1 Juhtumid .................................................................................................................................. 3 1.2 Ravimi andmed (ravimikaart) .................................................................................................. 4 1.3 Töövood................................................................................................................................... 5 1.4 Töötaja töölaud ....................................................................................................................... 5 1.5 Rollid ........................................................................................................................................ 6 1.6 Dokumendihaldus.................................................................................................................... 6 1.6.1 Dokumendid .................................................................................................................... 7 1.6.2 e-kirjad............................................................................................................................. 7 1.7 Loendid .................................................................................................................................... 7 1.8 Liidesed .................................................................................................................................. 10 1.9 Otsingud ................................................................................................................................ 11 1.9.1 Lihtotsing ....................................................................................................................... 11 1.9.2 Detailotsing.................................................................................................................... 11 1.10 Administreerimine ................................................................................................................. 13 2 Müügilubade funktsionaalsus ....................................................................................................... 14 2.1 Müügiloa taotluse liigid ......................................................................................................... 15 2.1.1 Esmase müügiloa taotlus ............................................................................................... 15 2.1.2 Müügiloa laiendus ......................................................................................................... 15 2.1.3 Müügiloa uuendamine .................................................................................................. 16 2.1.4 Teisese müügiloa taotlus ............................................................................................... 16 2.1.5 Müügiloa muudatus ...................................................................................................... 16 2.1.5.1 Müügiloa muudatuse taotluse liigid .......................................................................... 17 2.1.5.1.1 IA tüübi muudatus ............................................................................................... 17 2.1.5.1.2 IB tüübi muudatus ............................................................................................... 17 2.1.5.1.3 II tüübi muudatus ................................................................................................ 17 2.1.5.1.4 P-muudatus ......................................................................................................... 18 2.1.5.2 Müügiloa muudatuse taotluse esitamise liigid.......................................................... 18 2.1.5.2.1 Üksiktaotlus (Single) ............................................................................................ 18 2.1.5.2.2 Grupeeritud taotlus ............................................................................................. 18 2.1.5.2.3 Tööjaotusmenetluse (worksharing) taotlus ........................................................ 19 2.2 Müügiloa taotluse protseduuri liigid ..................................................................................... 19  2.2.1 Riiklik (N)........................................................................................................................ 19 2.2.2 Detsentraalne (DC) ........................................................................................................ 20 2.2.3 Vastastikune tunnustamine (MRP)................................................................................ 21 2.2.4 Korduv MRP protseduur (repeate-use procedure) ....................................................... 21 2.2.5 Tsentraalne (C) .............................................................................................................. 22 2.3 Müügiloa juhtumid ................................................................................................................ 23 2.3.1 Müügiloa juhtumi etapid ............................................................................................... 23 2.3.1.1 Juhtumi algatamine ................................................................................................... 23 2.3.1.2 Taotluse sisestamine ................................................................................................. 23 2.3.1.2.1 Ravimiametile esitatavate taotluste/teavituste/lisadokumentatsiooni vastuvõtmine. ........................................................................................................................ 23 2.3.1.2.1.1 CESP saadetised............................................................................................ 23 2.3.1.2.1.2 E-kirja postkastid .......................................................................................... 24 2.3.1.2.2 Taotluste/teavituste/lisadokumentatsiooni registreerimine SamTrackis........... 25 2.3.1.3 Esmane hinnang ........................................................................................................ 26 2.3.1.4 Sisuline hinnang ......................................................................................................... 28 2.3.1.5 Otsus .......................................................................................................................... 30 2.3.2 Müügiloa juhtumi liigid.................................................................................................. 31 2.3.2.1 Taotluse või teatise põhjal algatatud juhtumid......................................................... 31 2.3.2.1.1 Müügiloa taotlus ................................................................................................. 31 2.3.2.1.2 Üldjuhtumid (taotluse vormi ei esitata) .............................................................. 32 2.3.2.2 Ravimiameti poolt algatatud juhtumid ..................................................................... 32 2.3.3 Bulk juhtum ................................................................................................................... 33 2.3.4 Müügiloa juhtumi staatused ......................................................................................... 33 2.3.5 Müügiloa juhtumi põhiandmed..................................................................................... 33 2.4 Müügiloa staatused ............................................................................................................... 34 2.5 Ravimi andmed ...................................................................................................................... 34 2.5.1 Ravimi põhiandmed....................................................................................................... 34 2.5.2 Ravimi lisaandmed......................................................................................................... 35 2.5.3 Ravimi müügiloaga seotud andmete blokk ................................................................... 35 2.6 SamTracki kaudu esitatavad arved ........................................................................................ 35 2.6.1 Arvete hinnastamine ..................................................................................................... 36 2.6.2 Arvete liigid.................................................................................................................... 36 2.6.2.1 Taotluse erialase hindamise tasu arve ...................................................................... 37  2.6.2.2 Hinnanguraporti lisatasu kui Eesti on hindav riik ...................................................... 37 2.6.2.3 Ohutus- ja kvaliteediseire tasu arve .......................................................................... 37 2.6.2.4 Ohutuse lisatasu, kui Eesti on hindav riik .................................................................. 37 2.6.2.5 Kreeditarved .............................................................................................................. 37 2.6.3 Nõuded arvetele ............................................................................................................ 38 2.6.4 Arvete koostamine ja töötlus ........................................................................................ 38 1 Peamised üldised funktsionaalsed nõuded uuele infosüsteemile 1.1 Juhtumid Süsteem ehitatakse üles juhtumi (Case) põhiselt. Juhtumitega  Luuakse või muudetakse ravimi metaandmeid (põhiobjekt)  Lisatakse täiendavaid andmeid (nt müüdud ravimipakendite arv, ravimi tarneraskus)  Pikendatakse, peatatakse või lõpetatakse andmete kehtivust (nt ravimi müügiloa kehtivusaja pikendamine; müügiloa kehtivuse peatamine) Põhiobjektiks on ravimi metaandmed, mida lähtuvalt juhtumi liigist ja sisust kas muudetakse või millele lisatakse täiendavaid andmeid. Põhiobjekte ei ole võimalik hallata ilma juhtumiteta. Juhtumiga seotakse alati mingi töövoog, mille aluselt hakatakse juhtumit menetlema, kõik juhtumid peavad olema ajaliselt mõõdetavad, omama algust ja lõppu. Juhtumil on oma liik, mis näitab, millise töövoo grupi alusel juhtumit menetletakse, näiteks müügiluba, müügiloata ravimi kasutusluba, sisseveoluba, väljaveoluba jms. Juhtumiks on enamasti Ravimiametile esitatud taotlus, mille põhjal tehakse loa väljastamise/muutmise otsus, juhtum võib olla ka aruanne, teatis vms. dokument. Juhtumeid algatab SamTrackis vastavate õigustega Ravimiameti töötaja (spetsialist, menetleja) kas taotleja/teavitaja dokumendi või RA tegevusest tuleneva vajaduse alusel. Põhiobjekti juures on näha kõik selle objektiga seotud juhtumid (põhiobjekti loonud esmane juhtum, muutmise juhtumid, pikendamise juhtumid, lõpetamise juhtum jms). 1.2 Ravimi andmed (ravimikaart) Ravimi metaandmete kogum ehk ravimikaart, kus on näha ravimi kehtivate andmete koosseis. Andmete hulk on defineeritud. Ravimikaardi andmed tekivad esmase müügiloa taotluse või müügiloata ravimi sisse-väljaveo loa taotluse sisestamisel. Määratud andmed muutuvad avalikuks, st nähtavaks ravimiregistris, müügiloa või sisse-väljaveo loa andmise järgselt. Ravimikaardil on näha ravimi elutsükkel - muudatused, seotud juhtumid, iga muudatuse või juhtumiga muudetud andmed. 1.3 Töövood Süsteemis kirjeldatakse erinevate juhtumitega seotud töövood. Töövoos on näha etapid, tööülesanded, samuti vastava etapi/tööülesandega seotud tähtajad, dokumendi mallid ja e- kirja vormid. Etappi peab saama seostada konkreetsete rollidega. Töövoo järgi arvutatakse töögraafikut ette nii pikalt, kui protsess võimaldab, sellest tulenevalt saab töövoos määratud rolli omanik teavitusi ülevaateid ja aruandeid, samuti saab seadistada meeldetuletusi. Vajadusel arvutab süsteem ühe etapi lõppedes ühe või mitme järgmise etapi töögraafiku. Töövoole peab saama Ravimiameti administraator lisada etappe ja määrata töövooge rollidele. Töövool on algus, vaheetapid ja lõpp. Töövoog võib alata eelnevast töövoost ja lõppedes käivitada uue töövoo. 1.4 Töötaja töölaud Töölaud on avavorm, mida kasutajale kuvatakse peale infosüsteemi sisse logimist. See, millist teavet kasutaja vaikimisi näeb, määratakse kasutaja rollis sisalduvate õigustega. Alati on aga kasutajale kuvatud isiklik e-kirjapostkast, kasutaja tööülesanded ja süsteemi poolt saadetud teavitused. Töölaual kuvatakse tööülesanded ja teavitused liikide kaupa grupeerituna. Iga grupp on eraldi rida, mille juures on toodud gruppi kuuluvate kirjete arv. Grupp ise on link, mis avab eeltäidetud otsingu vormi kõikidest gruppi kuuluvatest juhtumitest. Nimekirja vormilt on võimalik avada valitud juhtumeid. Teavitusi on 3 liiki:  Kõikidele kasutajatele kuvatavad teated  Rollipõhised teated (kasutaja rolli põhiselt)  Kasutajapõhised (suunatud tegevus konkreetsele kasutajale või kui on määratud töölt eemal viibijale asendusisik, siis temale suunatud tegevus) Igal kasutajal peab olema võimalik ümber paigutada tööülesannete ja teadete gruppe. 1.5 Rollid Lisatud tabel „SamTrack Rollid“ (lisa 1).  Kasutajate sirvimise, lisamise, kustutamise jne. õigused määratakse kasutajatele vastavate rollidega. Kasutajale võib olla määratud üks või mitu rolli.  Rollides defineeritakse milliseid vorme on kasutajal õigus näha ning milliseid nuppe (funktsioone) õigus kasutada.  Kasutajate haldus ja kasutajate rollide määramine toimub SamTrack kasutajaliideses.  Rollide õiguste määramine toimub SamTrack kasutajaliideses. 1.6 Dokumendihaldus SamTrack peab sisaldama funktsionaalsust loodud kirjade ja saabunud kirjade registreerimiseks ja e-kirjade saatmiseks ja sisselugemiseks ning peab toetama dokumentide digiallkirjastamist. Üldised põhimõtted kirjade (dokumendid, e-kirjad) registreerimisel:  Kõik loodavad dokumendid peavad saama identifitseeriva numbri, asja numbri ja olema seotud kindla dokumendisarjaga.  Dokumendi number on unikaalne sarja lõikes; selle täpsem ülesehitus fikseeritakse arenduse käigus.  Dokumente/e-kirju peab olema võimalik siduda kõikide taotluste, teatiste ja kliendi poolt esitatud aruannete juurde. Nii saabunud kui ka väljuvaid kirju ja faile peab olema võimalik siduda mitme taotlusega, üksuse kõigi taotluste, erinevate üksuste taotlustega  Dokumendisarjale peab saama lisada juurdepääsupiiranguid ja igale dokumendile piirangu alguse ja lõpu.  Dokumentidele lisatakse ka dokumendiliik ja alamliigid, mis iseloomustavad dokumendi kuuluvust juhtumi ja selle etappide juurde. 1.6.1 Dokumendid Dokumentide all on silmas peetud kirju, otsuseid, lube jms, mis luuakse või salvestatakse SamTracki. SamTrackis dokumentide loomisel lähtutakse eeldefineeritud mallidest. Vaikimisi on mallid seotud töövoo konkreetse lõiguga, kuid malle peab saama valida ka kõikide SamTrackis olemasolevate mallida seast. Süsteem peab sisaldama malle ja mallidega seotud SQL-päringuid, millede alusel koostatakse dokumentide põhjad kasutaja jaoks. Mallid ja nende põhjal genereeritud dokumendid peavad põhinema MS Office toodetel. SamTrack peab toetama mallide koostamist mitmes keeles. Olemasolevaid malle peab olema võimalik võtta aluseks uute mallide loomisel. Dokumentide registreerimisel lähtutakse Ravimiameti asjaajamise korrast ja dokumentide loetelust, kus on kirjas dokumendisarjad. 1.6.2 e-kirjad Lisaks mallidele loodavatele dokumentidele peab süsteem toetama e-kirjade koostamist ja väljasaatmist töövoo erinevate etappide juurest. Vastusena saabunud e-kirja peab saama salvestada konkreetse juhtumi, töövoo etapi või välja saadetud e-kirja vastusena. Töövoo ja sellega seotud rolliga on seotud eeldefineeritud grupimeiliaadress, millelt kirju välja saata. SamTracki loetakse sisse kindlatele grupimeiliaadressidele saabunud kirjad. Juhul kui klient on saatnud registreerimist vajava kirja töötaja isiklikule e-posti aadressile, edastab töötaja selle soovitud grupimeiliaadressile. 1.7 Loendid Andmete halduseks kasutatakse loendeid, teksti andmevälja kasutatakse vaid alternatiivide puudumisel. SamTracki loendid on kas EL-i kesksed või Eesti kesksed. Loendite täielikku nimekirja käesolevas dokumendis välja ei tooda. Kõikides loendites peab saama määrata loendi elemendi kehtivuse algust ja lõppu. Igal loendi sisendil peab olema unikaalne ja ajas muutumatu ID, lisada peab saama SamTracki väliseid ID numbreid. EL andmehalduse loendid Selleks, et ühtlustada ravimite alast andmevahetust maailmas, on kokku lepitud ISO IDMP standardid: • ISO 11238 – Substances • ISO 11239 - Pharmaceutical dose forms, units of presentation, routes of administration and packaging • ISO 11240 - Units of measurement • ISO 11616 - Regulated pharmaceutical product information • ISO 11615 - Regulated medicinal product information Euroopa Ravimiamet on standardite kasutusele võtmisel loonud SPOR andmehalduse keskkonna. https://spor.ema.europa.eu/sporwi/ ja need terminid tuleb kasutusele võtta ka SamTrackis. Terminid (Referencials Management System RMS), organisatsioonid (OMS) ja edaspidi ka tooted ja ained (Products and Substances). Kõik need teenused pakuvad sünkroniseerimisteenust. SamTrackis on alustatud olemasolevate loendite vastavusse seadmist Euroopa ravimiameti loenditega. SamTracki andmebaas peab hakkama Euroopa ravimiameti andmebaasiga loendeid sünkroniseerima. Loendite puhul, mille andmeid uuendatakse välisest süsteemist, peab info uuendatud andmete kohta saabuma perioodiliselt (näiteks kord ööpäevas), süsteem annab loendite haldaja rollis spetsialisti töölauale teate uuenenud andmete kohta, spetsialist muudab andmed loendis. Uuendamist peaks saama ka käsitsi esile kutsuda. Loendite uuendamisel on 2 võimalikku varianti: ühel juhul uuendatakse välisest süsteemist vaid loendis sisalduvate ridade andmeid ja uusi ridu andmeuuenduse käigus ei lisata; teisel juhul peavad andmed olema sünkroonis, st. uuenduste käigus ühtlasi lisatakse loendisse ridu juurde. Lisaks peab saama defineerida, et teatud andmevälju uuendatakse ja teatuid mitte. RMS loendi näiteks on ATC klassifikatsioon ATC - HUM: https://spor.ema.europa.eu/rmswi/#/searchback/lists/100000093533/terms#search ATC – VET: https://spor.ema.europa.eu/rmswi/#/searchback/lists/100000116677/terms#search ATC (Anatomical Therapeutic Chemical) klassifikatsioonisüsteem, mis jaotab toimeained erinevatesse rühmadesse vastavalt elundile või elundsüsteemile, millesse nad toimivad, ning nende farmakoloogilistele ja keemilistele omadustele. Ravimeid klassifitseeritakse peamise toimeaine olulisima näidustuse järgi põhimõttel, et iga manustamisviisi kohta väljastatakse üks ATC kood, sarnase koostise, kuid erineva toimeainesisaldusega ravimitel on sama ATC kood. ATC kood on tähtede ja numbrite kombinatsioon. www.whocc.no ATC koodi ülesehitus. Ravimi liik ATC rühm, esimene tase ATC rühm, teine tase ATC rühm, kolmas tase ATC rühm, neljas tase ATC kood Humaanravimid 1 koht +2 kohta +1 koht +1 koht +2 kohta Veterinaarravimid 2 kohta +2 kohta +1 koht +1 koht +2 kohta ATC koodid humaanravimite korral 7- kohalised ja veterinaarravimite korral 8-kohalised, algavad Q tähega Näide ATC koodist ja koodile vastavatest rühmadest: A SEEDEKULGLA JA AINEVAHETUS A02 MAOMAHLA HAPPESUSEGA SEOTUD HÄIRETE RAVIKS KASUTATAVAD AINED A02A ANTATSIIDID A02AA Magneesiumi ühendid A02AA0 Magneesiumkarbonaat 1 Reeglid:  Enne ATC- koodi lisamist peavad olema süsteemi sisestatud kõik sellele koodile vastavad ATC rühmad.  Enne iga ATC rühma sisestamist (v.a. esimene tase), peab olema sisestatud talle vastava eelmise taseme rühm.  Korraga ei saa olla kehtivad mitu ühesugust ATC-koodi või rühma s.t ATC kood või ATC rühma kood on unikaalne hetkel kehtivate koodide hulgas  ATC-koodide ja ATC-rühmade koodide muutmise ajalugu peab olema jälgitav ATC-koodide sisestamisel:  ATC- koodi peab saama siduda ühe või mitme toimeainega, kusjuures üks neist võidakse määratakse põhitoimeaineks.   ATC koodi peab saama siduda ühe või mitme manustamisviisiga  ATC-koodile peab saama sisestada päevadoosi OMS loend: Euroopa Ravimiamet haldab ravimi andmetes kasutatavate organisatsioonide andmeid. Enne müügiloa taotluse esitamist on taotleja kohustatud registreerima firma andmed, esitades OMS süsteemi taotluse saada unikaalne ID firma nimetuse kohta (ORG-ID) ja firma asukohtade kohta (LOC-ID). Müügiloa taotluse elektroonilist vormi täites ei saa tulevikus taotleja vabatekstina andmeid sisestada, vaid valib eelregistreeritud üksuste (ORG-ID+LOC- ID) hetkel OMSis kehtivad andmed ning vormi andmeväljad täidetakse automaatselt. OMS ei halda firmade hierarhiat ega tegevusalasid, st sama üksus võib müügiloa taotluses olla märgitud erinevates rollides. OMS kasutajaliides näitab ainult kehtivaid ORG-ID ja LOC-ID andmeid (staatus Current), rakendusliides võimaldab saada andmeid ka eelnevate versioonide kohta. Süsteem peab toetama üksuste versioonide haldust. 1.8 Liidesed  Ravimiregister www.ravimiregister.ee SamTrackist edastatakse Ravimiregistrisse ravimite andmeid, et võimaldada nende kasutamist nii avalikkusele kui ka tervishoiuvaldkonnas. Andmete edastamine toimub üle x-tee. Täpsem info RIHA registris. Kõikides Ravimiregistrisse edastatavates loendites logitakse kõik andmete muudatused. Logi on kasutajaliidese tasemel vaadatav.  Avalik dokumendiregister (ADR, Ravimiameti avalik dokumendiregister) SamTracki registreeritud dokumentide metaandmed ja sõltuvalt juurdepääsu piirangust ka dokumendid edastatakse Ravimiameti avalikku dokumendiregistrisse. Kasutusel on Delta tarkvara.  SamTrackis loodud arved, arvete saajate andmed ja müügilubade otsuste andmed edastatakse Riigi Tugiteenuste Keskuse SAP infosüsteemi, kus peetakse arvestust laekumiste üle.  CESP (Common European Submission Portal) – veebiportaal, mille kaudu saavad müügiloa taotlejad edastada müügiloa taotlused koos lisadokumentatsiooniga Euroopa Majanduspiirkonna riikide pädevatele asutustele. Automaatne regulaarne protsess peab tõmbama taotluste dokumentatsiooni CESP-ist Samtracki.  CTS (Communication and Tracking System) – Saksamaa ravimiameti hallatav tarkvaralahendus, mille kaudu toimub Euroopa Majanduspiirkonna riikide pädevate asutuste vaheline suhtlus, ajagraafikute genereerimine ja jälgimine. Automaatne  regulaarne protsess peab tõmbama SamTracki andmed protseduuride kohta, milles osaleb Eesti.  SPOR – Euroopa Ravimiameti infosüsteem ravimite põhiandmete haldamiseks, koosneb neljast alamsüsteemist (Substance, Product, Organisation, Referentials). Liides peab võimaldama SamTrack loendite sünkroniseerimist SPOR andmetega. 1.9 Otsingud Juhtumite, ravimikaartide ja erinevate loendite põhiseid otsinguid saab teha kasutaja töölaual oleva otsinguvormi kaudu. 1.9.1 Lihtotsing Otsinguvormil asub piiratud arv kokkulepitud parameetreid (valik sõltub konkreetsest menüüst- alamsüsteemist, mida kasutatakse), mille kasutaja võib väärtustada või mitte väärtustada, ja seejärel teostada otsingu. Vaikimisi väljastatakse kirjed juhtumi unikaalse numbri (näiteks taotluse number) järgi sorteerituna, Kasutajal on võimalik neid ümber sorteerida. Lihtotsingu vormilt on võimalik liikuda detailotsingu vormile. Seejuures on detailotsingu vorm eeltäidetud lihtotsingus valitud parameetritega. 1.9.2 Detailotsing Detailotsing võimaldab teostada päringuid üle baasi (kõigi võimalike seotud andmete osas). Kogu SamTracki peale on üks ühtne detailotsingu vorm, kust saab otsida kõiki põhiobjekte, alamsüsteemidele luuakse eraldi ainult lihtotsingu vormid. Detailotsing on üldjuhul jaotatud järgmistesse blokkidesse:  Põhiobjekti valik – võimaldab määrata, millise põhiobjekti (müügiloa taotlus, toimeaine, üksus jms) kohta otsingut teostatakse. Põhiobjektiks võib olla ka kasutaja ise (näiteks otsingu teostamiseks, mis leiab kõik kasutajaga seotud võimalikud juhtumid).  Eeldefineeritud päringu valik - võimaldab valida sobivat aruannet eeldefineeritud otsingute seast. Samuti saab sisestada nime uue päringu salvestamiseks; sõltub põhiobjekti valikust  Andmete grupeerimine - vajadusel võimaldatakse valida, milliste parameetrite alusel saab andmeid grupeerida; sõltub põhiobjekti valikust (näiteks statistika andmed)  Otsingufilter - võimaldab erinevatele andmeväljadele seada piiranguid; sõltub põhiobjekti valikust   Väljad otsingutulemustes – võimaldab määrata tulemustes kuvatavaid veerge; sõltub põhiobjekti valikust Detailotsingul peab saama määrata ajaperioodi, mille kohta päringut esitatakse ning märkida, kui soovitakse saada teatud sagedusega aegrida (st näiteks aasta aruanne, kuid andmeid on kvartali kaupa eraldatud). Kasutajal peab olema võimalik valida eeldefineeritud päring või defineerida ise uusi päringuid. Eeldefineeritud päringutel on eelvalitud parameetrid, mida saab otsingu tegemiseks muuta. Igal eeldefineeritud päringul on unikaalne nimi. Eeldefineeritud päringud on kas süsteemi poolt defineeritud mittemuudetavad otsingud, kasutaja enda poolt salvestatud otsingud või kasutaja poolt grupile salvestatud otsingud. Kasutaja saab olemasoleva eeldefineeritud otsingu põhjal salvestada uue, muutes mõningaid parameetreid ja määrates unikaalse nime. Uue päringu saab salvestada kas endale või grupile. Kuna andmevälju on väga palju, siis saab näha detailotsingu tegemisel olemasolevaid andmevälju grupeerituna. Arenduse käigus pannakse paika, kuidas andmevälju grupeerida, et detailotsinguid oleks hõlpsam teha. Administraator peab saama hallata otsingutes nähtavaid andmevälju, st saab määrata, millised andmeväljad on otsingute tegemisel nähtavad ja millised mitte. Kasutajal peab olema võimalik tellida aruanne e-kirjaga ja määrata aruande arvutamise algusaeg. Otsingu tulemusi peab saama edastada Excelisse. Samuti peab saama tulemusi e-kirjaga edastada. Detailotsingute erisused: Logide päringud - Detailotsingu vormil peab vastava õigusega isikul olema võimalik otsida ka logisid. Otsingu tingimusteks peavad olema võimalikud logi väärtused (näiteks tegevuse tüüp – muutmine, kustutamine jms). Menetlusaegade päringud – peab olema võimalus genereerida aruandeid taotluste menetlemiseks kulunud aja kohta, vajadusel etapiviisiliselt ja kasutajate kaupa. Näiteks:  Esmane ja/või sisulise hinnangu perioodi pikkus teatud ajaperioodil üle kõikide sel perioodil laekunud müügiloa taotluste, teatud kindlal taotlusel või teatud rollis.  MRP/DCP esmased ja uuendamised: sisulise hinnangu lõpust otsuse väljastamiseni Perioodi aruanded – teatud päringuid peab saama tellida teatud kuupäevaks. Tegemist on eeldefineeritud otsingutega, mida saab näiteks tellida kvartaalselt. 1.10 Administreerimine Administreerimistegevuste loetelu ei ole lõplik. Arenduse käigus võib selguda täiendavaid administreerimistegevusi.  Kasutajate administreerimine. Administraator saab lisada, kustutada ja muuta kasutajate andmeid. Samuti on võimalik lisada kasutajatele rolle. Ühel kasutajal võib olla mitu rolli.  Rollide administreerimine. Administraator saab lisada, muuta ja kustutada rolle. Administraator defineerib rollidele õiguste komplekti. Olemasolevate rollide põhjal peab olema võimalik luua uusi. Kasutajad määratakse konkreetsesse rolli.  Asendajate määramine. Kasutajale saab määrata asendaja. Kasutatakse juhul, kui kasutaja on kindlal perioodil puhkusel või muul viisil hõivatud. Asendamisel on algus ja lõpp. Asendajaks määratakse teine kasutaja, kes saab asendusperioodi ajaks asendatava kasutaja tööülesanded (kuvatakse asendaja töölaual).  Süsteemiüleste töölauateadete haldamine. Administraatoril peab olema võimalik käsitsi sisestada süsteemiüleseid teateid, mida kuvatakse kõikidele kasutajatele. Süsteemiülene teade on näiteks teavitus SamTracki hooldustöödest. Süsteemiülesel teatel on algus- ja lõppaeg ning sisu.  Mallide haldamine. SamTrackis peab olema võimalik hallata erinevaid dokumendimalle. Süsteem peab sisaldama malle ja mallidega seotud SQL-päringuid, millede alusel koostatakse failide ja kirjade põhjad kasutaja jaoks. Mallid ja nende põhjal genereeritud failid peavad põhinema MS Office toodetel. SamTrack peab toetama mallide koostamist mitmes keeles. Olemasolevaid malle peab olema võimalik võtta aluseks uute mallide loomisel.  Töövoogude haldamine. Administraator peab saama hallata erinevate juhtumite töövooge (ajagraafikuid): etappe ja etapiga seotud alamtööülesandeid ning nendega seotud tähtaegu. Tööülesandega peab saama siduda kirja- või failimalle, mille alusel süsteem genereerib tööülesandega seotud kirja- või failipõhja. Etappide ja tööülesannetega peab olema võimalik siduda rolle. Töövood peavad olema versiooneeritavad; igal versioonil peab olema kehtivuse algus- ja lõppaeg. Olemasolevaid töövooge peab saama võtta aluseks uute töövoogude loomisel.  Dokumendiliikide ja dokumendisarjade administreerimine. Dokumendisari on dokumendile registreerimise käigus omistatud tüüp, mis vastab Ravimiameti dokumendiregistri nõuetele. Dokumendisarjad on SamTrackis sisestatavad, muudetavad ja kustutatavad. Kustutada saab sarja siis, kui sarjaga ei ole seotud ühtegi  dokumenti. Sarjale peab olema võimalik määrata kehtivuse algust ja lõppu. Samuti on võimalik iga sarja jaoks kirjeldada juurdepääsupiirang, juurdepääsupiirangu algus ja lõpu kuupäevad, juurdepääsupiirangu alus, millest lähtuvalt edastatakse avalikku dokumendiregistrisse ainult dokumendi metaandmed või dokument koos detailse infoga. Juurdepääsupiirangu infot ei sisestata dokumendisarjale juhul, kui sari ei määra üheselt vastavate parameetrite väärtust. Vastavat piirangut ja selle alust peab olema võimalik hiljem lisada-muuta sisestataval dokumendil. Dokumendiliik on SamTracki sisene dokumendile omistatav tüüp. Dokumendiliiki on võimalik siduda dokumendisarjaga. Juurdepääsupiirangute infot on võimalik sisestada ka dokumendiliigi juurde. Juhul kui dokumendisarja juures on juurdepääsupiirangute info olemas, kasutatakse sarja andmeid; kui sarja juurest vastav info puudub, kasutatakse dokumendiliigil kirjeldatud juurdepääsupiirangute andmeid. Lisaks, sarja põhist piirangut peab saama muuta, et oleks võimalik konkreetsele dokumendile lisada teistsugune piirang. Dokumendiliigile on võimalik määrata dokumendihalduses kasutatavaid olekuid ja tingimusi 2 Müügilubade funktsionaalsus SamTracki üks põhilisemaid äriprotsesse on ravimi müügiloa taotluse menetlemine ning kehtiva müügiloa elutsükli haldamine (muutmine, uuendamine). Müügiluba annab aluse ravimi Eestis turustamiseks. Eesti Ravimiameti poolt väljastatud müügiluba on riigikeskne. Üldine ML protsessi joonis 2.1 Müügiloa taotluse liigid Müügiloaga seoses on erinevaid taotluse liike. Kõikidel liikidel on menetlusetapid samad, kuid ajakava erinev. Liigid on: 2.1.1 Esmase müügiloa taotlus Taotlus ravimile, millel puudub Eestis müügiluba ja mille ravimikaarti ei eksisteeri SamTrack süsteemis. Taotluse alusel sisestatakse vajalikud andmed: juhtumi andmed, taotletava ravimi andmed, müügiloaga seotud organisatsioonide ja organisatsioone esindavate isikute andmed. 2.1.2 Müügiloa laiendus Müügiluba omavale ravimile taotleb sama müügiloa hoidja teise ravimvormi või tugevuse, teistsuguse näidustuse või loomaliigi lisamist. Laiendamise äriprotsess on sisuliselt identne esmase müügiloa taotlemise äriprotsessiga. Tulemuseks on uus müügiluba või olemasoleva müügiloa muutmine. 2.1.3 Müügiloa uuendamine Müügiluba uuendatakse, et pikendada lõppema hakkavat kehtivat müügiluba. Müügiloa hoidja peab 9 kuud enne müügiloa lõpukuupäeva esitama müügiloa uuendamise taotluse. Müügiluba uuendatakse kas tähtajatult (kehtivuse lõpp puudub), üheks või viieks aastaks. Uuendamise taotluse sisestamisel luuakse vormile märgitud andmete (nt ML number) alusel seos juba andmebaasis oleva ravimi müügiloa andmetega. On võimalik olukord, kus müügiloa uuendamisega paralleelselt on menetluses üks või mitu enne müügiloa uuendamise taotlust esitatud muudatust. Müügiloa uuendamine võib lõppeda enne, kui kinnitatakse varem esitatud muudatused. 2.1.4 Teisese müügiloa taotlus Taotletakse müügiluba Eestis juba registreeritud ravimi impordiks Euroopa Majanduspiirkonna (EMP) riigist ettevõtte poolt, kes ei ole esmase müügiloa hoidja poolt määratud. Tegemist ei ole sisulise hindamise protsessiga, vaid tegemist on kaupade vaba liikumise nõude täitmisega. Andmeid on minimaalselt, kuid siiski võidakse rakendada hindamise peatamist, tagasilükkamist jne. Samuti tehakse otsus müügiloa andmiseks samadel alustel nagu tavalisele müügilao taotlusele. Samale esmasele müügiloale viitavaid teiseseid müügilube võib olla mitu, teisese müügiloa taotlus tuleb esitada iga päritoluriigi kohta, kust ravim imporditakse. Kui esmase müügiloa hoidja algatab müügiloa muutmise ja see taotlus rahuldatakse, peavad ka teisese müügiloa hoidjad müügilube muutma, seepärast peab süsteem teavitama seotud esmase müügiloa muudatustest. 2.1.5 Müügiloa muudatus Taotlus ravimi kehtiva müügiloa muutmiseks ilma uut müügiluba väljastamata. Muudatuse taotluse sisestamisel luuakse taotluse vormile märgitud andmete (näiteks ML number) alusel seos juba andmebaasis olevate müügiloa andmetega. Kõik võimalikud ravimi müügiloa muudatused on Euroopa Liidus kodeeritud ja muudatuse taotlusel on tabel taotletavate muudatuste koodidega. SamTrack peab võimaldama igale muudatuse koodile defineerida vastavad ravimi andmeväljad, mis taotletava muudatuse kinnitamisel võivad muutuda (koodide ja SamTracki väljade vahelised seosed, mida peab saama vajadusel muuta). Ühte müügiluba muudetakse sageli mitme taotlusega, mis on samal ajal käigusolevad. Süsteem peab aru saama, milline on hetkel kehtiv müügiloa andmestik ja arvestama muudatuste aktsepteerimise aega. Ajaliselt hiljem laekunud muudatus võib saada kinnitatud ennem, kui varem laekunud muudatus. Seega peab varem laekunud muudatuse kinnitamisel arvestama ka vahepeal toimunud muudatustega ja vastavad andmed uuendama. Muudatuste puhul on võimalik ka see, et muudatuse suhtes tehakse positiivne otsus, kuid muudatuse reaalne jõustumine jääb otsuse tegemisega võrreldes tulevikku. 2.1.5.1 Müügiloa muudatuse taotluse liigid 2.1.5.1.1 IA tüübi muudatus Väheolulised administratiivsed muudatused. Müügiloa hoidja teavitab, et on müügiloa tingimusi muutnud. Ravimiameti spetsialist algatab esitatud teavituse põhjal SamTrackis juhtumi. Kui ravimiamet kinnitab muudatuse, siis sõltuvalt muudatuse sisust muutuvad Samtrackis ravimi andmed ja juhtum lõpetatakse. Negatiivse otsuse korral antakse sellest taotlejale teada, andmeid ei muudeta, juhtum lõpetatakse. 2.1.5.1.2 IB tüübi muudatus Lihtsamad sisulised muudatused. Müügiloa hoidja peab muudatustest teatama enne muudatuste rakendamist, esitades muudatuse taotluse. Ravimiamet teavitab taotlejat nõuetekohase taotluse kättesaamisest ja menetluse alguspäevast. Kui 30 päeva jooksul pärast taotluse kättesaamist ei ole müügiloa hoidja saanud Ravimiametilt muudatuse tagasilükkamise otsust, loetakse muudatus kinnitatuks ning müügiloa hoidja võib selle rakendada. Kui Ravimiamet kinnitab muudatuse, siis sõltuvalt muudatuse sisust muutuvad SamTrackis ravimi andmed ja juhtum lõpetatakse. Negatiivse hinnangu korral antakse sellest taotlejale teada. IB muudatuse puhul on taotlejal negatiivse hinnangu korral võimalus esitada muudetud teatis, mida ravimiamet seejärel menetleb. Kui ravimiamet kinnitab muudatuse, siis sõltuvalt muudatuse sisust muutuvad SamTrackis ravimi andmed ja juhtum lõpetatakse. Negatiivse otsuse korral antakse sellest taotlejale teada, andmeid ei muudeta, juhtum lõpetatakse. 2.1.5.1.3 II tüübi muudatus Olulised sisulised muudatused, mis vajavad põhjalikumat hindamist, müügiloa hoidja ei tohi enne muudatust rakendada kui on saanud ravimiametilt otsuse muudatuse kohta. Menetlusprotsessi jooksul toimub täiendavate andmete pärimine müügiloa hoidjalt, menetlus peatatakse kuni taotlejalt vastuste saamiseni. Ravimiamet hindab vastuseid. Kui ravimiamet kinnitab muudatuse, siis sõltuvalt muudatuse sisust muutuvad Samtrackis ravimi andmed. Negatiivse hinnangu korral andmeid ei muudeta. Vormistatakse otsus muudatuse kohta ja ning teatatakse müügiloa hoidjale muudatuse heakskiitmisest või tagasilükkamisest, juhtum lõpetatakse. 2.1.5.1.4 P-muudatus Muudatused, mis ei tulene muudatuse määrusest, vaid direktiivist (näiteks pakendiinfo väikesed muudatused). Menetluskäik on sama nagu IA-tüübi muudatuse puhul. 2.1.5.2 Müügiloa muudatuse taotluse esitamise liigid Müügiloa muudatuse taotlus esitatakse üksik-, grupeeritud või tööjaotusmenetluse (worksharing) taotlusena. 2.1.5.2.1 Üksiktaotlus (Single) Ühe ravimi ühe omaduse muutmine (muudatuste määruse kohaselt loetakse samaks ravimiks sama müügiloa hoidja eri tugevuse ja/või ravimvormiga, aga sama(de) toimeaine(te) ja sama nimega ravimeid). 2.1.5.2.2 Grupeeritud taotlus - mitme ravimi sama(de) omadus(t)e muutmine (muudetakse sama taotlusega mitme erineva ravimikaardi andmeid, näiteks IA muudatus üle ühe kindla müügiloahoidja ravimite, mille puhul muutub müügiloahoidja nimi) - ühe ravimi mitme erineva muudatuse teostamine (sama ravimi puhul soovitakse taotleda mitu erinevat samaaegset üksteisega seostatavat muudatust (näiteks IA, IB, II), siis tehakse nende kohta üks grupitaotlus ja menetletakse erinevat tüüpi muudatusi üheaegselt kõige „kõrgemat“ tüüpi muudatuse ajagraafikut järgides). Seda tüüpi grupitaotlus võib lisaks muudatustele sisaldada ka müügiloa laiendust.  Grupitaotluse korral toimub menetlemine grupis oleva kõige kõrgema muudatuse tüübi ajagraafiku järgi. Grupis olevate muudatuste jaoks ei pruugi tulemus olla ühesugune. Osa taotlusi võivad olla tagasi võetud, osa tagasi lükatud, osa kinnitatud. 2.1.5.2.3 Tööjaotusmenetluse (worksharing) taotlus Võimaldab erinevate protseduuriliikidega ravimite kohta taotleda muudatusi ühel taotlusel. Tavalise grupitaotlusega ei ole näiteks võimalik muuta sama taotluse alusel tsentraalset ja riiklikku ravimit. Seda aga võimaldab worksharing’u taotlus. Samuti võimaldab worksharing esitada IB- või II-tüüpi muudatust samal taotlusel sama müügiloa hoidja mitme ravimi kohta, mis tavalise grupimuudatuse taotlusega ei ole lubatud. Worksharing on ka ainus võimalus kui müügiloa hoidja soovib esitada sama muudatuse taotluse mitmes liikmesriigis riiklikult registreeritud ravimi kohta. Kui worksharing sisaldab tsentraalselt registreeritud ravimit, siis koordineerib hindamist Euroopa Ravimiamet. 2.2 Müügiloa taotluse protseduuri liigid 2.2.1 Riiklik (N) Müügiluba taotletakse ainult ühes riigis. Teiste riikide ja Euroopa Komisjoniga seos puudub. 2.2.2 Detsentraalne (DC) Esmase müügiloa taotluse haldamine mitmes riigis samaaegselt, üks riik koordineerib protsessi (hindav riik). Vastavad riigid kasutavad CTS süsteemi ühismenetluse etappide ajagraafiku jälgimiseks ja omavaheliseks suhtluseks. Hindav riik loob taotluse kohta protseduuri kaardi CTS süsteemis, märgib seal ravimi põhiandmed ja ajakava kuupäevad ning koordineerib kogu protseduuri. Pärast protseduuri lõppu vormistatakse protseduuris osalenud liikmesriikides riiklikul tasandil otsus (müügiluba või taotluse tagasilükkamine). Sõltuvalt Eesti rollist protseduuris määratakse juhtumi töövoog: o Detsentraalne hindava riigina o Detsentraalne kaasatud riigina 2.2.3 Vastastikune tunnustamine (MRP) Sarnane DCP-ga, kuid siin on hindavas riigis juba eelnevalt müügiluba olemas. Müügiloa hoidja taotleb mitmest riigist korraga müügiluba (soovib ühes liikmesriigis riikliku müügiloa saanud ravimile taotleda müügiluba ühes või mitmes liikmesriigis). Müügiloaga riik loob sisemiselt uue protseduuri, millega alustatakse senise riikliku müügiloa alusel vastastikuse tunnustamise müügiloa protseduuri menetlust. Kuni vastastikuse tunnustamise protseduur ei ole positiivselt lõppenud, jääb müügiloa protseduuri liigiks „riiklik“. Samal ajal algatatakse CTS-s vastastikuse tunnustamise protsess. Protseduuri hindavaks riigiks on müügiloaga riik. Kaasatud riigid hindavad ravimit sarnaselt detsentraalse müügiloa väljastamisele ning vormistavad vastavalt protseduuri lõpptulemusele eraldi otsuse müügiloa väljastamise või müügiloa taotluse tagasi lükkamise kohta. Sõltuvalt Eesti rollist protseduuris määratakse juhtumi töövoog: o Vastastikune tunnustamine hindava riigina o Vastastikune tunnustamine kaasatud riigina 2.2.4 Korduv MRP protseduur (repeate-use procedure) Olemasoleva MRP/DCP põhjal algatatakse uus ring uute kaasatud riikidega. Müügiloa hoidja taotleb uute kaasatud riikide lisamist olemasolevale MRP või DCP müügiloale. Järgneb analoogne menetlus hindava riigi koordineerimisel kaasatud riikidega nagu vastastikuse tunnustamise protsessi puhul, protseduuris osalevad ainult uued riigid. Ajakava on sama, mis vastastikuse tunnustamise müügiloa väljastamise äriprotsessi korral. Müügiloahoidja saab taotleda uute riikide lisamist olemasolevale müügiloale korduvalt. Sõltuvalt Eesti rollist protseduuris määratakse juhtumi töövoog:  o Korduv MRP protseduur hindava riigina o Korduv MRP protseduur kaasatud riigina 2.2.5 Tsentraalne (C) Müügiloa taotlus esitatakse Euroopa Ravimiametisse, mis teostab esmase hinnangu ja koordineerib kogu hindamisprotsessi, tsentraalne müügiluba annab õiguse turustada ravimit kõikides Euroopa Majanduspiirkonna liikmesriikides. Tsentraalsete ravimite puhul võib RA olla hindav või kaasatud riik. Nende tsentraalsete ravimite taotluste info, mille puhul Eesti osaleb hindamisprotseduuris, sisestatakse SamTracki ja süsteem haldab protseduuri ajakava sisulise hinnangu etapis. Taotlus esitatakse Euroopa Ravimiametisse läbi portaali, lisadokumentatsioon laetakse automaatselt Euroopa tsentraalsesse andmehoidlasse Common Repository. Ravimiameti spetsialist laeb Common Repository´st veebipõhise kasutajaliidese kaudu taotluse alla ning sisestab SamTracki. Nende taotluste andmeid, mille hindamises Eesti Ravimiamet ei osale, sisestatakse SamTracki alles pärast Euroopa Komisjoni otsuse väljastamist. Euroopa ravimiamet teeb pärast menetlusprotseduuri lõppu ravimi kohta hinnangu Euroopa Komisjonile, kes omakorda vormistab müügiloa andmise otsuse. Positiivse otsuse korral avalikustatakse müügiloa info Euroopa Komisjoni kodulehel. Ravimiamet kontrollib regulaarselt Euroopa Komisjoni kodulehel avaldatud teavitusi otsuste kohta. Uue tsentraalse müügiloa andmete kohta sisestab sisestaja rollis spetsialist SamTrackis ravimi müügiloa andmed ja märgib EK otsuse kuupäeva, tsentraalse müügiloaga ravimi andmed kanduvad Ravimiregistrisse. SamTrack genereerib ravimikaardile müügiloa numbri alusel püsilingi Euroopa Komisjoni kodulehel avaldatud ravimiinfole. Tsentraalse müügiloaga ravimite metaandmeid muutvate muudatuste positiivsete otsuste ja müügiloa uuendamise otsuste puhul luuakse SamTracki juhtum ravimi andmete muutmiseks. Sõltuvalt Eesti rollist protseduuris määratakse juhtumi töövoog: o Tsentraalne hindava riigina o Tsentraalne kaasatud riigina 2.3 Müügiloa juhtumid 2.3.1 Müügiloa juhtumi etapid 2.3.1.1 Juhtumi algatamine Toimub kas Ravimiametile esitatud saadetise põhjal või Ravimiameti algatusel. 2.3.1.2 Taotluse sisestamine 2.3.1.2.1 Ravimiametile esitatavate taotluste/teavituste/lisadokumentatsiooni vastuvõtmine. Taotlused/teavitused esitatakse Ravimiametile CESP portaali kaudu (95% ), e-posti teel (5%). 2.3.1.2.1.1 CESP saadetised Kui taotlus esitati läbi CESP portaali, siis esmalt tõmbab automaatne protsess igal öösel kell 02:00 taotluse dokumentatsiooni Euroopa serverist TEHIKu serverisse ajutisse asupaika. Taotluse dokumentatsioon koosneb ühest .ZIP failist (sisaldab muuhulgas taotluse andmete .PDF ja .XML faile) ja delivery failist (CESP portaali genereeritud .XML fail, mis sisaldab taotleja poolt CESP veebiliidese andmeväljadele sisestatud andmeid, muuhulgas näitab ära ka riigid, kuhu saadetis on esitatud). 2.3.1.2.1.2 E-kirja postkastid Iga e-posti aadressi jaoks on oma kaust. Igale e-posti aadressile saab määrata, millise rolliga kasutajad seda e-posti kausta näevad. Administraator peab saama lisada uusi e-posti aadresse ja määrata, millise rolliga kasutajad selle e-posti kausta näevad. Kasutaja SamTrack töölaual on näha nende e-postide kaustad, mille nägemiseks vajalik roll on tal olemas. Osad e-posti aadressid on seotud väliste süsteemidega, aga SamTrack ei liidestu nende väliste süsteemidega. Liidestused väliste süsteemidega on realiseeritud Ravimiameti Exchange serveris. SamTrack saab kirju ja saadab kirju Ravimiameti Exchange serveri kaudu, mis peidab SamTrack jaoks liidestumise detailid. Hetkel teadaolevad välised süsteemid on:  Eudralink. Kiri sisaldab linki Eudralink süsteemi üleslaaditud saadetisele. Töölaual avatud e-kirjast peab olema võimalik seda linki klikkida, et näha vastavat lehte Eudralink sees. Ravimiameti töötajatel on olemas Eudralink kontod, Eudralink-i logivad töötajad SamTrack väliselt sisse.  Eudra Web Mail postkastid, Ravimiameti Exchange server suhtleb selle süsteemiga turvakanali kaudu. Selle kaudu vahetavad liikmesriigid e-kirju. Märkus: teatud protseduuride teatud tegevuste juurest kirju saates peab pakkuma kirja saajaks automaatselt õige Eudra Webmail aadressi.  Common Repository, kust tulevad tsentraalsete protseduuridega seotud kirjad.  Ravimiameti Kliendiportaal. 2.3.1.2.2 Taotluste/teavituste/lisadokumentatsiooni registreerimine SamTrackis - Sisestaja töölaual on info saabunud CESP saadetiste ja e-kirjade kohta. Sisestaja avab dokumendid ja tuvastab saadetise sisu. Sisestajal on ka võimalus algatada juhtum käsitsi ilma e-kirja/CESP saadetiseta (sh Ravimiameti poolt algatatud juhtumite puhul). - Kui tegu on uue juhtumiga, loob sisestaja juhtumi ja sisestab juhtumi liigi ja üldandmed, CESP xml või e-kirja andmed salvestuvad juhtumi juurde. Müügiloa taotluse vormi andmed, sh ravimi andmed sisestatakse süsteemi, elektroonilise vormi puhul loeb süsteem xml andmed automaatselt sisse. Sisestajal peab olema võimalus käsitsi kopeerida olemasoleva ravimikaardi põhjal andmed uue ravimikaardi loomiseks (vajalik nt teisese müügiloa taotluse sisestamise lihtsustamiseks). Muudatuse või uuendamise juhtumi puhul leiab süsteem taotluse vormi andmete alusel ravimi(d), millega juhtum siduda. Kui tegu on uue juhtumiga, mille puhul Eesti osaleb hindava riigina, sisestatakse andmed ka CTSi. Juhtumite puhul, mis ei põhine müügiloa taotlusel, sisestatakse üldandmed ja juhtumi liigi puhul nõutavad lisaandmed. Sõltuvalt juhtumi liigist võib sisestaja juhtumi lõpetada järgnevatesse etappidesse suunamata. - Kui tegu on vastusega olemasoleva juhtumi kohta, pakub süsteem CESP saadetiste puhul xml andmete põhjal seostatava juhtumi, e-kirja puhul otsib sisestaja juhtumi käsitsi. Sisestaja määrab õige juhtumi, mille juurde vastus registreerida. CESP xml ja e-kirja andmed salvestuvad juhtumi juurde. Kui tegu on vastusega, mis sisaldab parandatud andmetega taotluse vormi, võrdleb süsteem muutunud andmeid. Süsteem kontrollib, et kõik nõutud andmeväljad oleks täidetud. Sisestaja kontrollib, kas riigilõiv on tasutud ja teatud taotluste liikide puhul Word infode olemasolu.Sisestaja määrab saadetisega saabunud failide asukoha: osa dokumentatsioonist suunatakse EURSi sisestamisele, osa salvestatakse Failihoidlasse. Taotluse sisestamine on lõppenud ja juhtum suunatakse esmase hinnangu etappi. 2.3.1.3 Esmane hinnang SamTracki sisestatakse esmase hindamise ajakava:  Taotluste puhul, kus Eesti osaleb hindava riigina, märgib valideerija ajakava CTSi ja saadab taotlejale e-kirjaga.  Taotluste puhul, kus Eesti osaleb kaasatud riigina, saabub teade hindava riigi määratud ajakava kohta SamTracki CTSist või Eudra Web Mail postkasti kaudu.  Riikliku taotluse puhul algab esmase hinnangu ajakava kui taotlus on märgitud sisestatuks. Näide esmase müügiloa taotluse esmase hinnangu ajakavast juhtumi puhul, kus Eesti osaleb hindava riigina detsentraalses protseduuris. Ajakava tähtaja Selgitus nimetus/tähis Esmase hinnangu etapi Kuupäev, mil taotleja saadetud kinnituse list of dispatch põhjal algus/ on kõik protseduuris osalevad riigid taotluse kätte saanud. Day -14 Valideerija rollis spetsialist märgib selle kuupäeva ja esmase hinnangu staatuse (valid/invalid) CTSi. Sisulise hinnangu etapi Kui kõikide riikide valideerimisprobleemid on lahendatud ja algus/ staatused CTSis valid, kooskõlastab valideerija protseduuri Day 0 sisulise hinnangu ajakava hindajate määrajatega, märgib protseduuri CTSis alanuks (Day 0) ja saadab ajakava e-kirja teel taotlejale Esmase hindamise käigus valideeritakse esitatud dokumentatsiooni vastavust nõuetele, esmase taotluse puhul täidetakse Word formaadis valideerimisvorm ((ing validation checklist), mis saadetakse taotlejale ja MRP/DC protseduuri puhul salvestatakse CTSi. Kommenteerimise ja vastuste saamise protsess võib toimuda korduvalt. Esmase hinnangu otsuse vormistab valideerija. Kui otsus on negatiivne, antakse võimalus taotlus tagasi võtta. Kui taotleja ei ole seatud tähtajaks taotluse tagasivõtu kirja esitanud, saadetakse taotlejale kiri negatiivse esmase hinnangu kohta, taotlust ei võeta menetlusse, juhtum märgitakse lõppenuks. Kui esmane hinnang on positiivne, genereeritakse edasine menetluse ajakava:  Taotluste puhul, kus Eesti osaleb hindava riigina, märgib valideerija ajakava CTSi ja saadab taotlejale e-kirjaga.  Taotluste puhul, kus Eesti osaleb kaasatud riigina, saabub teade hindava riigi määratud ajakava kohta SamTracki CTSist või Eudra Web Mail postkasti kaudu.  Riikliku taotluse puhul märgib valideerija ajakava käsitsi Samtracki ja saadab selle taotlejale e-kirjaga. Süsteem saadab tööülesande arve koostaja töölauale. Spetsialist saab arvet kontrollida ja vajadusel muuta, misjärel saab andmed läbi SamTracki automaatselt SAP-i saata. Spetsialist laeb arved käsitsi SamTrackist alla ning saadab e-mailiga taotlejale, kes peab arve tasuma. Arve tasumist ei kontrollita, juhtum liigub edasi sisulise hindamise etappi. Müügiloa taotluse arve sõltub taotluse liigist. Üks arve võib olla koostatud mitme taotluse kohta. Ühel arvel on sama liiki taotlused (esmased, muudatused, uuendamised, täiendav hindamistasu). Sellele lisandub täiendav tasu, kui Eesti osaleb MRP-s või DCP-s hindava riigina. Süsteem saadab tööülesande sisulise hinnangu teostajate määraja(te) töölauale. Juhtumi esmane hinnang on lõppenud. 2.3.1.4 Sisuline hinnang Töövoo näide: esmase müügiloa taotluse sisulise hinnang juhtumi puhul, kus Eesti osaleb hindava riigina detsentraalses protseduuris Ajakava Selgitus Kuupäeva märkmine CTSi Day 0 Sisulise hinnangu etapi algus x Day 65 Day70 hinnangu raporti osade valmimistähtaeg Day 70 Day70 hinnangu raporti saatmine taotlejale ja kaasatud riikidele Day 100 Kaasatud riikide kommentaaride saabumistähtaeg Clock- Ühiste kommentaaridega kirja saatmine taotlejale, x stop (Day kell kinni 105) Day 106 Taotleja vastused on saabunud ja eelhinnatud, kell x käima Day 117 Day120 hinnangu raporti kavandi osade valmimistähtaeg Day 120 Day120 hinnangu raporti kavandi saatmine taotlejale ja kaasatud riikidele Day 145 Kaasatud riikide kommentaaride saabumistähtaeg Day 160 Taotlejalt vastuste saamise tähtaeg Day 177 Day180 hinnangu raporti kavandi osade valmimistähtaeg Day 180 Day180 hinnangu raporti kavandi saatmine taotlejale ja kaasatud riikidele Day 195 Kaasatud riikide kommentaaride saabumistähtaeg Day 205 Kaasatud riikide lõpliku seisukoha saabumistähtaeg Day 210 Protseduuri lõpp: x Positiivne/Negatiivne/Tagasivõetud Vastavalt juhtumi liigile määrab sisulise hinnangu teostajad osakonna juhataja, büroo juhataja või Hindaja – Koordineerija rollis spetsialist. Teatud juhtumite puhul jõuab tööülesanne otse eelmääratud hindaja või hindajate grupi ühisele töölauale. Hinnangu teostajate arv sõltub taotluse liigist, sisust ja protseduuri liigist. Süsteem toetab hinnangu teostajate valikut töökoormuse põhjal. Vastavalt juhtumi liigile genereerib süsteem eeltäidetud andmega vormid: juhtumite puhul, milles Eesti osaleb hindava riigina - hinnangu raporti vormi osad; juhtumite puhul, milles Eesti osaleb kaasatud riigina - kommentaaride vormi. Word formaadis ravimiinfo esitatakse koos taotlusega ja on hinnanguraporti üheks osaks, ajakava järgsete etappide versioonidena. Hinnangu teostajate töölauale saabub ülesande vastava vormi valmimistähtajaga. Protseduuri koordinaator saab tööülesande hinnanguraporti osad või kommentaarid ajakava järgseks tähtajaks vormistada ning saata müügiloa taotlejale ja/või protseduuris osalevate riikide e-posti aadressidele. Juhtumite kohta, milles Eesti osaleb hindava riigina saadavad kaasatud riigid oma kommentaarid hinnanguraportile Eudra Web Mail-i või CTS-i kaudu. Saabunud kommentaarid salvestab sisestaja rollis spetsialist juhtumi juurde, hinnanguraporti ja kommentaaride põhjal koostab protseduuri koordinaator ühise tõstatatud probleemide kokkuvõtte (list of questions), mille saadab taotlejale. Teatud juhtumite ajakava kohaselt peatatakse kell kuni taotlejalt vastuste saamiseni. Hinnangu teostajad hindavad saabunud vastuseid ning koordineerija saadab vajadusel järgmise hinnanguraporti hindava riigina või kommentaarid kaasatud riigina, hindamisprotsess võib korduda olenevalt juhtumist 1-n korda. Protseduuri ajakava lõpukuupäeval märgitakse juhtumi sisuline hinnang positiivselt või negatiivselt lõppenuks. Osade Euroopa protseduuri taotluse liikide puhul saadab hindav riik lõpliku hinnanguraporti ja positiivse otsuse puhul ka ingliskeelse ravimiinfo e-kirjaga müügiloa hoidjale ja kaasatud riikidele. Sisulise hinnangu etapp on lõppenud, juhtum läheb edasi otsuse etappi. 2.3.1.5 Otsus Peale sisulist hinnangut tehakse otsus taotluse heakskiitmise või tagasilükkamise kohta. Euroopa protseduuride positiivse otsuse vormistamisele eelneb eestikeelsete tõlgete kontrollimine, heakskiidetud ingliskeelsete ravimiinfode eestikeelsed tõlked peab müügiloa taotleja esitama 5 päeva jooksul pärast protseduuri lõppu. Kui tõlked ei ole saabunud määratud tähtajaks, pannakse kell seisma 6.päeval ning tõlgete saabumisel pannakse kell uuesti käima. Riikliku protseduuri taotluste menetlemisel tõlgete faasi ei ole. Sõltuvalt taotluse liigist teeb formaalse otsuse vastavas rollis spetsialist või on vajalik enne otsust saada arvamus taotluse kohta müügilubade komisjonilt, misjärel teeb otsuste peadirektor. Peadirektori otsuse tegemiseks vajalikud tehnilised andmed sisestab ML komisjoni koordinaatori rollis spetsialist, kelle töölauale saadab süsteem teate komisjoni protokolli ja lühikokkuvõtte koostamiseks Samtrackis. Dokumendid saadetakse komisjoniliikmetele e-kirja teel. Kui komisjon on arvamuse andnud, vormistatakse otsused peadirektorile allkirjastamiseks. Samtrack loob otsuse malli põhjal otsuse dokumendi, mida otsuse koostaja saab vajadusel parandada Otsuse lisa on ravimiinfo (SPC, PIL ja pakendimärgistuse tekst), mis peab olema allkirjastamiseks valmis. ML Otsuste allkirjastaja rollis isikule (peadirektor) saadetakse teavitus selle kohta, et SamTrackis on allkirjastamist vajavaid otsuseid ning ta saab seejärel need digiallkirjastada. Allkirjastatud otsus saadetakse taotlejale (e-post ja DHS teavitusega). Positiivse otsuse vormistamisel muutuvad ravimikaardi andmed ametlikult kinnitatuks. Vajalikud andmed sh ravimiinfod kanduvad Ravimiregistrisse otsuse märkimise järgneval ööl automaatse uuenduse käigus. Negatiivse otsusega taotluse puhul andmeid Ravimiregistrisse ei kanta, samuti ei uuendata ravimikaardi andmeid. Positiivsed ja negatiivsed otsused peavad olema näha avalikus dokumendiregistris (avalikud). Patsiendile suunatud info (PIL) avaldatakse kodulehel teatud ravimite puhul lisaks vene ja inglise keeles. Ravimiameti töötaja edastab tõlkebüroosse eestikeelse ravimiinfo venekeelse/ingliskeelse tõlke saamiseks (e-kiri SamTrackist). Peale tõlgete saamist laetakse need ravimikaardi juurde üles ning edastatakse Ravimiregistrisse. 2.3.2 Müügiloa juhtumi liigid 2.3.2.1 Taotluse või teatise põhjal algatatud juhtumid 2.3.2.1.1 Müügiloa taotlus Esmane müügiloa taotlus - Riiklik - Tsentraalne hindava riigina - Tsentraalne kaasatud riigina - Detsentraalne hindava riigina - Detsentraalne kaasatud riigina - Vastastikune tunnustamine/Korduv MRP hindava riigina - Vastastikune tunnustamine/Korduv MRP kaasatud riigina Müügiloa laiendus (töövoog ja alamliigid samad, mis esmase müügiloa taotlusel) Teisene müügiloa taotlus (ainult protseduuriliik „Riiklik“) Muudatus - Riiklik - Vastastikune tunnustamine kaasatud riigina - Vastastikune tunnustamine hindava riigina - Tsentraalne hindava riigina Müügiloa uuendamine - Riiklik - Tsentraalne hindava riigina - Vastastikune tunnustamine hindava riigina - Vastastikune tunnustamine kaasatud riigina 2.3.2.1.2 Üldjuhtumid (taotluse vormi ei esitata) - Müügiloa juhtumi eeltaotlus (teavitus müügiloa taotlejalt, et soovitakse, et Eesti osaleks MRP/DC/CP esmase taotluse või muudatuse protseduuris hindava riigina. Juhtum lõpetatakse hetkel kui taotleja on esitanud ametliku müügiloa taotluse, eeltaotluse juhtum salvestatakse põhijuhtumi juurde. - ASMF juhtum (Active Substance Master File= toimeaine tootja poolt saadetud dokumentatsioon toimeaine kohta. Sama saadetis võib olla seotud mitme erineva müügiloa juhtumiga ja ravimi andmetega. Peab olema võimalik hallata ASMF versioonide andmeid (sh tootja organisatsiooni andmete muudatusi)). - Müügiloa hoidja volikirja esitamine ja müügiloa hoidjaid esindavate firmade/isikute haldus. - Müügiloa hoidja teatis ravimi kuuluvuse muutmiseks käsimüügi/retseptiravimiks - Ravimi pakendikavandi esitamine - Müügiloa tagasivõtmine müügiloahoidja poolt (müügiloa staatus muudetakse Kehtiv -- > Tagasivõetud) - Müügiloa elektroonilise dokumentatsiooni üldjuhtum - Ravimi näidiste esitamine (juhtum seotakse konkreetse ravimiga, andmed pakendi koguse ja kõlblikkuskuupäeva kohta) - Tarneraskuste teade - Turustamise teade - Turustamise lõpetamise teade - Teade ravimi kvaliteediprobleemide kohta. Defektist teatamise protsessi hallatakse tegevuslubade registris. SamTracki on vaja vaid otsust lingiga tegevuslubade registrisse. Üldjuhtumite liike, täidetavaid andmevälju, töövoogusid ja dokumendimalle saab Ravimiameti administraator lisada ja muuta. 2.3.2.2 Ravimiameti poolt algatatud juhtumid - Müügiloa peatamine (müügiloa staatus muudetakse --> Peatatud) - Müügiloa lõpetamine (müügiloa staatus muudetakse --> Müügiluba lõpetatud) - Ravimiametipoolne andmete parandus 2.3.3 Bulk juhtum Mitme ravimi andmete, protseduuri ajakava ja dokumentide haldamine ühe juhtumina. Luuakse mitme üksikjuhtumi liitmisel. Pärast protseduuri lõppemist vormistatakse otsused eraldi. 2.3.4 Müügiloa juhtumi staatused Moodustatakse etapi nimetusest + protseduuri kella olekust (kell käib/peatatud), lisaks info vastava rolli nimetusest, kelle töölaual juhtum parasjagu on (nt Otsuse etapis/allkirjastamine) Näited: - Sisestamise etapis - Esmane hinnang käigusolev/Esmane hinnang peatatud - Sisuline hinnang käigusolev/Sisuline hinnang peatatud - Otsuse etapis/Otsuse etapp peatatud (ravimiinfode tõlked taotlejalt saamata) - Juhtum lõppenud: Taotlus aktsepteeritud - Juhtum lõppenud: Taotlus tagasi lükatud - Juhtum lõppenud: Taotlus aktsepteeritud osaliselt (partially approved) - Juhtum lõppenud: Taotlus tagasi võetud 2.3.5 Müügiloa juhtumi põhiandmed - Juhtumi liik - Müügiloa taotluse liik (juhul kui on tegu müügiloa taotluse ülemliigiga) ja protseduuri liik - Müügiloa taotluse liigipõhised andmed (erinev loetelu esmase/muudatuse/uuendamise puhul) - Taotluse SamTrack number, lisaks MRP/DC/C protseduuride puhul EL number - Taotleja ja taotlejat esindava firma/isiku andmed - Juhtumiga seotud ravimite blokk (MRP/C teatud grupimuudatuste ja tööjaotusprotseduuride puhul ka ravimipõhised EL numbrid) Lisaks sisestatakse juhtumite liigipõhised andmed (loetelu tekib arenduse käigus). 2.4 Müügiloa staatused - Kehtiv – müügiloa staatus pärast esmase müügiloa protseduuri positiivse otsuse teavitamist müügiloa hoidjale - Peatatud - müügiloa kehtivuse peatamine Ravimiameti poolt - Müügiluba lõpetatud – müügiloa kehtivuse lõpetamine Ravimiameti poolt - Tagasivõetud – müügiluba on hoidja poolt tagasi võetud - Müügiloa kehtivus lõppenud - Müügiloa kehtivus uuendamata - Müügiloa kehtivus lõppenud Sunset Clause tõttu (kuna ravimit ei ole Eestis turustatud 3 aasta jooksul alates müügiloa väljastamise kuupäevast) 2.5 Ravimi andmed Esmane ravimikaart luuakse koheselt peale esmase taotluse sisestamist. Kuni müügiloa saamiseni näidatakse taotletava ravimi andmeid, ravimikaardil on märge, et müügiloa staatust ei ole veel määratud, müügiloa taotlus on menetluses (peab selgelt eristuma ravimikaardist, millel on müügiloa staatus märgitud). Peale esmase müügiloa otsuse tegemist näidatakse müügiloa kehtivaid andmeid. Iga uue müügiloa andmeid muutva juhtumi positiivse otsuse kinnitamise järgselt uuenevad ka ravimikaardi andmed. Andmete ajalugu on võimalik vaadata andmeväljade kaupa ja ravimiga seotud juhtumite ravimikaardi vaatena. Süsteem peab toetama paralleelselt käigus olevate juhtumitega muudetavate andmete haldust. 2.5.1 Ravimi põhiandmed - Ravimi valdkond (H= inimestel kasutatav ravim; V= veterinaarravim) - Ravimi nimi - ATC kood(id) - Toimeaine(d) - Tugevus (toimeaine(te) sisaldus) - Ravimvorm - Manustamisviis(id) - Müügiloa hoidja ja müügiloa hoidjat esindava firma/isiku andmed - Kuuluvus (R, K, N, E, H). Üldjuhul on ravimil üks kuuluvus, aga on võimalik, et osad ravimi pakendid on retsepti- ja osad käsimüügiravimid, sel juhul kuvatakse ravimikaardi vaates R, K.  - Loomaliigid (veterinaarravimite puhul) - Keeluajad (veterinaarravimite puhul) - Näidustus 2.5.2 Ravimi lisaandmed Ravimi lisaandmeid ei kuvata ravimikaardi avavaates vaid eraldi blokkidena - Ravimi tootjate andmed (grupeeritud eraldi tootmisetapi põhifunktsiooni järgi) - Ravimi kliiniliste uuringute teostajate andmed - Ravimi toimeaine(te) tootjate andmed (seos vastava toimeaine andmeväljaga) - Ravimi koostis (välispakendis sisalduva(te) ravimvormi(de) nimetus ja koostis, andmed sisepakendi(te) kohta, pakendiliigid ja -materjalid, pakendis sisalduvad meditsiiniseadmed) - Ravimi pakendisuurused (erinevate müügipakendite info, nt pakendid 10 tabletti, 20 tabletti) - Ravimi müügipakendi andmed: kuuluvus, pakendikood - Ravimi säilitustingimused ja kõlblikkusaeg (seos pakendiliigi ja -materjali andmeväljaga) 2.5.3 Ravimi müügiloaga seotud andmete blokk - Müügiloa number* - Müügiloa protseduuri liik* - Müügiloa protseduuri tüvenumber* - Eesti roll esmase müügiloa protseduuri menetlusprotsessis* - Müügiloa seaduslik alus - Teisese müügiloa märge*; päritoluriik*; müügiloaga seotud esmase müügiloa viide - Müügiloa väljastamise kuupäev - Müügiloa kehtivuse lõpu kuupäev - Müügiloa piirangud - Müügiloa tingimused - Müügiloa staatus* * andmeid kuvatakse ravimikaardi avavaates 2.6 SamTracki kaudu esitatavad arved 2.6.1 Arvete hinnastamine Teenuste hinnastamine toimub SamTrackis sisalduva hinnakirja alusel. Igal hinnakirja real eksisteerib kehtivuse aeg s.o hetkel kehtival hinnakirjal on määratud kehtivuse algus, varem kehtinud hinnakirjadel nii kehtivuse algus kui lõpp. Taotluse eest esitatakse arve selle hinnakirja alusel, mis kehtis taotluse menetlusse võtmise ajal. Erinevad hinnad kehtivad veterinaar- ja humaanravimite kohta. Samuti tuleb vaadata taotluse liike, taotletavat ravimit ja sama müügiloahoidja varasemaid taotlusi, kuna ühe müügiloahoidja sama toimeainega ravimi järgnevatele taotlustele rakendub esimese taotlusega võrreldes erinev hind. Käesoleva dokumendi koostamise ajal kehtiv hinnakiri: http://www.ravimiamet.ee/taotluse-erialase-hindamise-tasud Arve esitatakse alati eurodes. 2.6.2 Arvete liigid SamTracki kaudu esitatavaid arveid jagatakse tasu liigi alusel: 1) Taotluse erialase hindamise tasu arve 2) Hinnanguraporti lisatasu, kui Eesti on hindav riik vastastikuse tunnustamise või detsentraalse taotluse menetlemisel 3) Seiretasu arve 4) Ohutuse lisatasu, kui Eesti on hindav riik SamTracki kaudu esitatavad arved arve liigi alusel on: 1) Ettemaksuarved – siia kuuluvad taotluse erialase hindamise tasu arved ja hinnanguraporti lisatasu arved 2) Arved – siia kuuluvad seiretasu arved 3) Kreeditarved – kreeditarveid peab saama koostada nii ettemaksu arvetele (kui taotluse liik muutub) kui ka seiretasu arvetele (müügiloahoidja taotluse alusel kui ravimi käive on väiksem kehtestatud alampiirist) 2.6.2.1 Taotluse erialase hindamise tasu arve Õigus arvet koostada tekib taotluse eest, mis on positiivselt läbinud esmase hinnangu etapi. Arve esitatakse ettemaksuarvena ja selle tasumiseks on taotlejal aega 40 päeva. Arvete genereerimise protseduuri käigus koostab SamTrack arved kõikide taotluste eest, millede eest arveid ei ole esitatud, kuid õigus arvete esitamiseks on tekkinud. Süsteem seostab arve rea ja taotluse, mille alusel tasu küsitakse. Veel väljastamata arvelt peab saama ridu kustutada. Sel juhul jääb arve esitamine jõusse ning see taotlus kantakse taas arvele järgmise arve loomise ajal. 2.6.2.2 Hinnanguraporti lisatasu kui Eesti on hindav riik Juhul kui Eesti on hindav riik, on arve tegemise aluseks MRP/DCP protseduuri tüvinumber. Ühe MRP/DCP protseduuri tüvinumbriga võib olla seotud mitu ravimit, mille toimeaine ja müügiloa hoidja on sama. Ühe MRP/DCP protseduuri tüvinumbri kohta esitatakse üks lisatasu arve, mis esitatakse hindamise faasi 70.-75. päeval (st koos hinnanguraportiga). See arve on hilisem kui eelmises punktis nimetatud arve. 2.6.2.3 Ohutus- ja kvaliteediseire tasu arve Esitatakse kord aastas eelmisel kalendriaastal mitte vähem kui 6 kuud kehtinud müügiloa kohta. Arve loomisel võetakse aluseks ravimi müügi andmed ravimistatistikast ning selleks peab saama koostada vastavaid päringuid. 2.6.2.4 Ohutuse lisatasu, kui Eesti on hindav riik Lisatasu on seotud toimeainega. Arve esitatakse juhul, kui Eesti osaleb vastastikuse tunnustamise või detsentraalse menetluse protseduurides hindava riigina või osaleb ravimi perioodilise ohutusaruande hindamisel PRAC ühises töökorralduses hinnanguaruande koostajana. Tasu arvestatakse kalendriaastal üle kuue kuu kehtinud müügiloa kohta. Müügiloa hoidjale saadetaval arvel on ka ohutus- ja kvaliteediseiretasu, st need saadetakse koos välja. 2.6.2.5 Kreeditarved - Kreeditarved ettemaksuarvetele  Müügiloa muutmise taotluse liiki saab enne otsuse väljastamist muuta. Juhul kui eelmise liigiga on väljastatud arve, tuleb luua kreeditarve sõltumata sellest, kas summa muutub või mitte. Kui eelnevale arvele on kreeditarve loodud, luuakse uus arve. - Kreeditarve seiretasuarvele Juhul, kui pakendite müük on olnud piisavalt väike, on müügiloa hoidjal õigus taotleda vastava ravimi seiretasust vabastamist. Ravimiameti töötaja kontrollib üle müügi suuruse (algandmed pärinevad statistikast) ja koostab vajadusel kreeditarve müügiloa hoidja taotluse alusel. Selleks: - Kreeditarve koostamist saab algatada originaalarve vormilt. Võimalik on märgistada ridu, millede kohta kreeditarvet koostatakse. - Seiretasu arve vormilt peab olema võimalik algatada ravimistatistika päring. - Arvutuse tulemit näidatakse iga rea vastavas veerus. Süsteem märgistab automaatselt rea, mille müük jääb alla piirmäära (piirmäära suurus peaks olema süsteemis seadistatav). Kasutaja saab märgistusi muuta. Kasutaja koostab kreeditarve. 2.6.3 Nõuded arvetele Arvete numeratsioon lähtub SAP-st. Käesolevas dokumendis seda täpsemalt ei kirjeldata. Arvete ülesehitus peab olema selline, et oleks üheselt arusaadav, mille eest arve esitati. Näiteks ohutustasu arvetel (arve rea tasemel) peab olema välja toodud taotluse number, ravimi number, ravimvorm, tugevus, kas on esmane, korduv, taotluse tüüp. Kreeditarvete korral peab arve viitama originaalarvele, mille kohta kreeditarve koostati. Arve maksja ei ole alati taotluse esitajaga/müügiloahoidjaga sama isik. Süsteemis peab olema võimalus seadistada müügiloahoidjale vastavaid maksjaid. Kui müügiloahoidjale pole eraldi maksjat seadistatud, koostatakse arve müügiloahoidjale endale. Arve .PDF vormile kantakse Ravimiameti rekvisiidid. Rekvisiidid võivad olla hallatavad süsteemisiseselt aga võivad sisalduda ka ainult mallides. Arve .PDF vorm peab olema koostatav nii eesti- kui inglise keeles. Keel määratakse maksja üksuse tasemel. 2.6.4 Arvete koostamine ja töötlus Süsteem saadab arvete haldaja rollis spetsialisti töölauale ülesande arve koostamiseks, kui juhtum on jõudnud vastavasse etappi. Kasutaja kontrollib andmed ja kinnitab arve tüübi. Süsteem genereerib arved saadaolevate tasude kohta. Seni kuni arvet pole SAP-i ega arve saajale edastatud, saab kasutaja arvet muuta (näiteks eemaldada arve rida) või kustutada. Kord ööpäevas moodustab süsteem saatmata arvete detailvaadete andmete alusel arvete .PDF failid ja kui Ravimiameti töötaja on arve kinnitanud, siis edastatakse arve maksja meiliaadressile. Meiliaadressi olemasolu ja korrektsus peab olema tagatud. Samuti edastab süsteem arve andmed SAP-i. Olemas peab olema ka manuaalselt esile kutsutav edastamisvõimalus. SamTracki jääb näha, kas arve edastamine SAP-i õnnestus või mitte. Kui juhtum on süsteemis lõppenuks märgitud, edastatakse SAP-i teatud andmeväljad, et SAP saaks ettemaksuarve alusel moodustada arve. Andmevahetus SAP-ga on ühesuunaline ja toimub üle x-tee tee Lisatud: Lisa 1 – Samtrack rollid (.xls fail).  ISIKUANDMETE TÖÖTLEMISE TINGIMUSED Tervise ja Heaolu Infosüsteemide Keskus (edaspidi volitaja), registrikood 70009700, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja Industry62 OÜ, (edaspidi volitatud töötleja), registrikood 11124544, aadress Toompuiestee 35 Tallinn 10133, keda esindab Andrus Altrov on sõlminud käesoleva isikuandmete töötlemise lepingu hankelepingu nr 3-9/2203-2 lisana nr 3 (edaspidi leping): 1. Lepingu ese ja eesmärk 1.1. Lepingu esemeks on volitaja ja volitatud töötleja (edaspidi koos nimetatud kui pooled) vaheliste tingimuste sätestamine seoses SamTrack arendustööde käigus käsitletavate andmete töötlemisega. 1.2. Volitatud töötleja töötleb lepingus kirjeldatud isikuandmeid hankelepingu nr 3- 9/2203-2 täitmiseks, millele on volitatud töötlejal õigus saada ligipääs hankelepingus määratletud tööde teostamiseks vastavalt lepingus sätestatud piirangutele. 1.3. Lepingu täitmiseks on volitatud töötleja isikuandmete töötlemisega seotud tegevused lepingu alusel piiratud hankelepingu täitmiseks vajalike tegevustega. 2. Isikuandmed 2.1. Volitatud töötlejale võivad hankelepingu täitmisel andmete migratsioonitööde ja testimise käigus teatavaks saada volitaja poolt hallatavas infosüsteemis või andmekogus töödeldavad isikuandmed: 2.1.1. füüsiliste isikute andmed - Ravimiameti töötajad, sh töötajad, kellega on töösuhe lõppenud, müügiloa hoidjaid esindavate isikute andmed; teatavaks võivad saada nimi, e-maili aadress, postiaadress, telefon, ametikoht ning 2.1.2. müügiloa hoidlas paiknevad andmed, kus võivad paikneda nt volikirjad, sh füüsiliste isikute isikukoodid. 3. Volitatud töötleja kohustused 3.1. Volitatud töötleja on kohustatud: 3.1.1. tagama lepingueelsete läbirääkimiste ja lepingu täitmise käigus volitajalt ükskõik mis vormis saadud isikuandmete konfidentsiaalsuse ja mitte edastama ega võimaldama sellele teabele juurdepääsu kolmandale isikule ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 3.1.2. tagama, et lepingu täitmise raames töödeldavaid isikuandmeid ei edastata väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse  kuuluvate riikide territooriumi ilma volitaja sellekohase selgesõnalise kirjaliku nõusolekuta; 3.1.3. kasutama ja töötlema isikuandmeid üksnes hankelepingu täitmiseks ja volitaja dokumenteeritud juhiste alusel, välja arvatud juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab volitatud töötleja volitajat vastava kohustuse olemasolust enne teabe töötlemist; 3.1.4. võimaldama juurdepääsu isikuandmetele ainult nendele isikutele, kellel on selleks oma tööülesannete täitmiseks vajadus ning tagab, et need isikud on teadlikud ning järgivad isikuandmete töötlemis alaseid nõudeid ja õigusakte, nad on saanud asjakohase koolituse eelmainitud nõuete kohta, on võtnud endale konfidentsiaalsuskohustuse või neile kehtib asjakohane seadusest tulenev konfidentsiaalsuskohustus; 3.1.5. teavitama volitajat toimunud või põhjendatult kahtlustatavast lepingu punktis 3.1.4. sätestatud konfidentsiaalsuskohustuse rikkumisest viivitamatult; 3.1.6. täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja muid eeskirju; 3.1.7. rakendama alltoodud organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise; juhusliku hävimise ja tahtliku hävitamise eest ning õigustatud isikule andmete kättesaadavuse takistamise eest, volitamata töötlemise, sh avalikustamise eest: 3.1.7.1. vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele seadmetele; 3.1.7.2. ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist; 3.1.7.3. ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning tagama, 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; 3.1.7.4. tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks; 3.1.7.5. tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised isikuandmed edastati, samuti selliste andmete muutusteta säilimise; 3.1.7.6. tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või kustutamist; 3.1.7.7. pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate seadmete ja tarkvara üle, dokumenteerides järgmised andmed: 3.1.7.7.1. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi; 3.1.7.7.2. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed. 3.1.8. teavitama kirjalikult volitajat turvameetmete rikkumisest, mis põhjustab, on põhjustanud või võib põhjustada töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise või loata avalikustamise või neile juurdepääsu viivitamata, kuid mitte hiljem kui kakskümmend neli tundi  pärast sellest teada saamist. Juhul, kui rikkumisest teadasaamine langeb nädalavahetusele või riiklikule pühale, kohustub volitatud töötleja volitajat kirjalikult teavitama viivitamatult, kuid mitte hiljem kui nelikümmend kaheksa tundi pärast rikkumisest teada saamist. Kirjeldatud teates tuleb vähemalt: 3.1.8.1. kirjeldada isikuandmetega seotud rikkumise laadi, sealhulgas puudutatud andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu; 3.1.8.2. teatada andmekaitsespetsialisti või mõne teise täiendavat teavet andva kontaktisiku nimi ja kontaktandmed; 3.1.8.3. soovitada meetmeid isikuandmetega seotud rikkumise võimalike negatiivsete mõjude leevendamiseks; 3.1.8.4. kirjeldada isikuandmetega seotud rikkumise võimalikke tagajärgi; 3.1.8.5. kirjeldada volitatud töötleja poolt pakutud või võetud meetmeid isikuandmetega seotud rikkumisega tegelemiseks ja 3.1.8.6. esitada muud teavet, mis on mõistlikult nõutav, et volitaja saaks täita kohaldatavaid andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks. 3.1.9. lõpetama eelnevalt kirjeldatud rikkumised või tegema kõik endast oleneva nende lõpetamiseks ja kohaldama meetmeid isikuandmetega seotud rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks; 3.1.10. kustutama, niivõrd kui see on võimalik, lepingu lõppemisel kõik tööde teostamise käigus teatavaks saanud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti; 3.1.11. tegema volitajale kättesaadavaks kogu teabe, mida volitaja peab vajalikuks lepingus sätestatud kohustuste täitmise tõendamiseks; 3.1.12. võimaldama volitajal või volitaja poolt määratud audiitoril teha seoses isikuandmete töötlemisega auditeid ja kontrolle ning panustama nendesse. 4. Lõppsätted 4.1. Volitatud töötleja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma lepingujärgsete kohustuste täitmiseks kolmandat isikut. 4.2. Isikuandmete konfidentsiaalsena hoidmise kohustus jääb kehtima ka pärast käesoleva lepingu lõppemist tähtajatult. 4.3. Isikuandmete konfidentsiaalsena hoidmise kohustus ei laiene teabe avaldamisele volitatud töötleja audiitorile ja advokaadile. 4.4. Leping on kehtiv poolte poolt allkirjastamisest kuni hankelepingu järgsete kohustuste täitmiseni, v.a konfidentsiaalsuskohtustus, mis kehtib tähtajatult. 5. Poole allkirjad Volitaja: Volitatud töötleja: /Allkirjastatud digitaalselt/ /Allkirjastatud digitaalselt/  Samtrack I-etapi arendustööde teostamine Hankeleping nr 3-9/2203-2 Tervise ja Heaolu Infosüsteemide Keskus (edaspidi nimetatud ka tellija), registrikood 70009700, aadress Uus-Tatari 25, Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja Industry62 OÜ, (edaspidi nimetatud ka täitja), registrikood 11124544, aadress Toompuiestee 35 Tallinn 10133, keda esindab Andrus Altrov edaspidi koos või eraldi nimetatud ka pool või pooled, sõlmisid tellija läbiviidud riigihankes „Ravimiameti infosüsteemi Samtrack arendus- ja hooldustööd“ raamlepingu nr 3-9/2203- 1 alusel hankelepingu (edaspidi nimetatud ka leping) alljärgnevas. 1. LEPINGU ESE 1.1. Lepingu esemeks on tööd ja nendega seonduv konsultatsioon koos garantiiteenustega (edaspidi töö), mis on kirjeldatud lisas 1 ja täitja poolt esitatud pakkumuses. 1.2. Teostatavate tööde loetelu, töö teostamise tingimused ja muud olulised lepingu täitmise kokkulepped on fikseeritud lisas 1 (tehniline kirjeldus). 1.3. Lepingu tööde maht on 528 780,00 eurot käibemaksuta. 1.4. Vajadusel on tellijal õigus tellida lepingu esemega seotud täiendavaid töid kuni 20% ulatuses kokkulepitud mahust. 1.5. Täiendavate tööde tellimine ja sellega kaasnevad muudatused lepingu täitmisel lepitakse poolte vahel kokku vähemalt digitaalselt allkirjastatud vormis. 2. LEPINGU ÜLDTINGIMUSED 2.1. Pooled teevad lepingu täitmiseks ja lepingu eesmärkide saavutamiseks koostööd. Lepingu täitmisel kohustuvad pooled tegema kõik vajalikud pingutused, et täita leping õigeaegselt ja vastavalt kokkulepetele, lähtudes lepingus, raamlepingus ja õigusaktides kirjeldatud kohustustest. 2.2. Lepingus reguleerimata osas juhinduvad pooled raamlepingus fikseeritud tingimustest. 3. TÖÖDE ÜLEANDMISE JA VASTUVÕTMISE TINGIMUSED 3.1. Täitja kohustub nõuetekohase töö üle andma hiljemalt 18 kuu möödumisel lepingu sõlmimisest. 3.2. Töö antakse vastuvõtutestimiseks üle iga arendustsükli lõpus kokku lepitud tähtajal vastavalt lepingu lisades kokkulepitud tingimustele. 3.3. Töö antakse üle allkirjastatud üleandmise ja vastuvõtmise aktiga (edaspidi ka akt). 3.4. Koos üle antava tööga annab täitja tellijale üle kõik tööde intellektuaalse omandi õigused vastavalt raamlepingus kirjeldatule. 3.5. Tööde üleandmisel ja vastuvõtmisel lähtuvad pooled raamlepingus fikseeritud tingimustest. 4. TÖÖDE MAKSUMUS JA ARVELDUSTE KORD 4.1. Tellija tasub üksnes lepingu alusel tellitud, teostatud ja üle antud tööde eest. 4.2. Ühe töötunni maksumuseks tööde teostamisel on 50,00 (viiskümmend) eurot ilma käibemaksuta. 4.3. Tellija tasub lepingu alusel tellitud tööde eest kokku 528 780,00 (viissada kakskümmendkaheksa tuhat seitsesada kaheksakümmend) eurot ilma käibemaksuta. 4.4. Täitjal on õigus esitada arve pärast tööde vastu võtmist, mis toimub tellija poolse akti allkirjastamisega. Täitja annab tellijale arve tasumiseks tähtaja minimaalselt 21 kalendripäeva alates arve esitamisest. 4.5. Arvel tuleb märkida riigihanke viitenumber ja nimetus ning lepingu number. 4.6. Teostatud töö eest võib tasuda ka kolmas isik (maksja). Sellisel juhul sõlmitakse leping kolmepoolselt tellija, täitja ja maksja vahel ning selles lepitakse vajadusel kokku tasustamise täpsed tingimused ning kord. 5. LEPINGU LÕPETAMINE JA ÜLES ÜTLEMINE 5.1. Leping lõpeb kohustuste täitmisega, lepingu lõpetamise kokkuleppe sõlmimisega, muul lepingus ettenähtud või seadusest tuleneval alusel. 5.2. Tellijal on õigus leping igal ajal üles öelda, teatades sellest 60 kalendripäeva ette. 5.3. Poolel on õigus leping etteteatamistähtaega järgimata igal ajal üles öelda, kui teine Pool on lepingut oluliselt rikkunud või esineb raamlepingu punktis 15.3 nimetatud alus lepingu üles ütlemiseks. Olulise lepingurikkumisena mõistavad pooled raamlepingu punktis 15.4 kirjeldatut. 6. ESINDAJAD 6.1. Tellija kontaktisik(ud) on: Merle Kale, telefon +372 5100922, e-post: [email protected]. 6.2. Täitja kontaktisik(ud) on: Taavi Tasuja, telefon +372 55641595, e-post: [email protected]. 6.3. Esindajate pädevuses on anda teisele poolele lepingu täitmisega seonduvat informatsiooni ja juhiseid, esitada päringuid seoses lepingu täitmisega, allkirjastada tööde üleandmise ja vastuvõtmise aktid. 7. LÕPPSÄTTED 7.1. Täitjal puudub volitus tegeleda lepingu raames avalike suhetega ning anda teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, välja arvatud tellija eelneval kirjalikku taasesitamist võimaldaval nõusolekul. 7.2. Leping, lisad ja muud selle alusel või selle täitmiseks sõlmitavad kokkulepped jõustuvad alla kirjutamisel ning kehtivad kuni poolte kõikide kohustuste täitmiseni. 7.3. Kõik teated seoses lepingu täitmisega esitatakse e-posti või kirja teel lepingus nimetatud aadressil või mõnel muul aadressil, mille pool on teisele poolele teatavaks teinud. Informatiivset teadet võib edastada ka telefoni teel. Informatiivseks loetakse teade, millega ei kaasne iseseisvaid õiguslikke tagajärgi. 7.4. Lepingut saab muuta poolte kirjalikul kokkuleppel. Kõik lepingu muudatused tuleb sõlmida lepinguga samas vormis ja need jõustuvad allkirjastamisel. 7.5. Lepingu täitmisest tulenevad vaidlused ja lahkarvamused püütakse lahendada läbirääkimiste teel. Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus. Lepingule kohaldub Eesti õigus. 8. LISAD 8.1. Lisa 1 - Hankelepingu eseme tehniline kirjeldus (ja selle lisad); 8.2. Lisa 2 - Täitja poolt esitatud pakkumuse väljavõte; 8.3. Lisa 3 – Isikuandmete töötlemise tingimused.  9. POOLTE ALLKIRJAD Tellija Täitja (allkirjastatud digitaalselt) (allkirjastatud digitaalselt)