Grįžti į sąrašą

RINKOS KONSULTACIJA Dėl Užkrečiamųjų ligų ir jų sukėlėjų valstybės informacinės sistemos palaikymo ir vystymo paslaugų viešojo pirkimo

Išanalizuota

Nacionalinis visuomenės sveikatos centras prie Sveikatos apsaugos ministerijos

Rinkos konsultacijaCPV: 72250000 - Sistemų ir aptarnavimo paslaugos
ID: 71923862026-03-31 11:57
Atidaryti CVP IS

Aprašymas

Perkančioji organizacija ieško tiekėjo, kuris teiktų Užkrečiamųjų ligų ir jų sukėlėjų valstybės informacinės sistemos (ULSVIS) palaikymo ir vystymo paslaugas. Šios paslaugos apima sistemos funkcionalumo plėtrą, naujų modulinių sprendimų ir integracijų kūrimą, atnaujinimų diegimą, klaidų šalinimą, veikimo palaikymą bei konsultacijas.

Kvalifikaciniai reikalavimai

Kvalifikacinių reikalavimų nerasta

Techniniai reikalavimai

AMR modulis

  • 1Pranešimą ULSVIS IP formuoja mikrobiologijos laboratorija, todėl mikrobiologijos laboratorijai sukurtos atskiros IP naudotojų teisės.
  • 2ULSVIS IP NVSPL gauna pranešimą, todėl darbui su gautais pranešimais sukurtos NVSPL naudotojų teisės.
  • 3Pranešime yra galimybė pažymėti rankiniu būdu, ar tai yra ne unikalus atvejis (pagal paciento asmens kodą NVSPL specialistas įvertina, ar gautas pranešimas yra vienintelis to paties susirgimo atvejo apimtyje).
  • 4Jeigu pranešime pažymima, kad bus siunčiama bakterijų kultūra atsparumui patvirtinti, aktyvuojamas „Bakteriologinio tyrimo protokolas“ pildyti, kurio laukai automatiškai užsipildo informacija, pateikta pranešime (kitą informaciją užpildo NVSPL specialistas).
  • 5Sąrašinėse Formose yra indikatorius, leidžiantis NVSPL specialistams identifikuoti, kad yra gautas naujas pranešimas, o mikrobiologijos laboratorijai – identifikuoti naujai gautą „Bakteriologinio tyrimo protokolą“.
  • 6Pranešimas susideda iš pagrindinės dalies ir priedų. Pasirinkus priedą pildyti, aktyvuojami priedo laukai pildyti, o pranešimas įgauna jį identifikuojančią žymą, priklausomai nuo to, kuris priedas buvo užpildytas.
  • 7NVSPL naudotojas gali redaguoti visus duomenų laukus, nepriklausomai nuo pranešimo bylos statuso.

Integracijos

  • 1Visos ULSVIS funkcinės sritys (moduliai) tarpusavyje integruotos. Visi informacijos pasikeitimai vienoje srityje (modulyje) atsispindi susijusiose srityse be papildomų ULSVIS naudotojų veiksmų.
  • 2ULSVIS palaiko žiniatinklio paslaugas (angl. Web Services) integracijai su kitomis sistemomis. Sistema palaiko šiuolaikines ir saugiai įgyvendintas REST arba SOAP žiniatinklio paslaugas integracijai su kitomis sistemos dalimis ar išorinėmis sistemomis. Naudojamas HL7 standartas (FHIR kompozicijos) arba jam lygiavertis.
  • 3Juridinių asmenų duomenys tikrinami su JAR.
  • 4Fizinių asmenų duomenys tikrinami su GR.
  • 5ULSVIS adresai tikrinami su AR.
  • 6Iš išorinių sistemų duomenys gaunami pagal eiliškumą, suteikiant pirmenybę duomenis teikiančioms sistemoms (pvz., jeigu ESPBI IS duomenyse nėra asmens gyvenamosios vietos adreso, adresas gaunamas iš GR; jeigu GR nėra gyvenamosios vietos adreso, adresas gaunamas iš MR ir t.t ).
  • 7Nustatytas ULSVIS duomenų mainams gaunamų duomenų eiliškumas.
  • 8Šios integracijos (GR, MR, SR, SODRA, SVEIDRA, JAR, AR) įgyvendintos per VDV IS, naudojant Palantir API techninę specifikaciją, tiek tiesioginės duomenų bazės jungties būdu, tiek ir per REST API.
  • 9Duomenų mainų funkcionalumas įgyvendintas pagal duomenų teikimo ar gavimo sutartyse nurodytas technines sąlygas.
  • 10Duomenų saugumo standartai: visi duomenų perdavimai užšifruoti naudojant SSL/TLS protokolus, užtikrinant, kad duomenys nebus prieinami neautorizuotiems asmenims.
  • 11API standartai: API atitinka RESTful standartus ir yra suderinami su OpenAPI specifikacijomis.
  • 12Duomenų sinchronizavimo dažnumas: kritiški duomenys yra sinchronizuojami realiuoju laiku, o mažiau kritiški – pagal nustatytą grafiką.
  • 13Klaidų tvarkymas: visos klaidos yra žurnalizuojamos į centralizuotą klaidų žurnalą, o sistemos administratoriai informuojami el. paštu apie kritines klaidas.
  • 14Atitikimas reglamentams ir standartams: integracijos atitinka ES Bendrąjį duomenų apsaugos reglamentą (BDAR), užtikrinant asmeninių duomenų apsaugą.
  • 15Suderinamumas ir prieinamumas: integracijos yra suderinamos su pagrindinėmis operacinėmis sistemomis, pavyzdžiui, Windows, Linux, ir palaiko skirtingas duomenų bazės sistemas.
  • 16Palaikymas ir atnaujinimai: yra užtikrinama galimybė vykdyti atnaujinimus ir įgyvendinti procesus, siekiant skubiai reaguoti į saugumo pažeidimus.
  • 17Testavimas ir patvirtinimas: prieš diegiant integraciją, ji ištestuojama naudojant automatizuotus testavimo scenarijus, jos atitiktis peržiūrima.
  • 18Per integracines sąsajas gautų duomenų struktūra išskaidoma į atskirus laukus (pvz.: gautas adresas išskaidomas į atskirus elementus duomenų bazėje: miestas, kaimas, gatvė, namo Nr., buto Nr., ir t.t.).
  • 19Integracinių duomenų paėmimas inicijuojamas rankiniu būdu ir (arba) automatiškai.
  • 20Rankiniu būdu inicijuotas paėmimas suteikia galimybę naudotojams pasirinkti laiką ir sąlygas, kada duomenys bus paimami. Automatinis paėmimas užtikrina, kad duomenys bus reguliariai atnaujinami be papildomo naudotojo įsikišimo, remiantis iš anksto nustatytais intervalais arba įvykiais.
  • 21Administravimo modulyje įdiegtas funkcionalumas, leidžiantis inicijuoti ESPBI IS duomenų gavimo procesą, nurodant duomenų rinkinių pasirašymo laiką.
  • 22Administravimo modulyje įdiegtas integracijų darbingumo stebėjimo funkcionalumas, kad kiekvienai sistemai, su kuria yra įgyvendinta integracija, būtų siunčiamas neribotas skaičius testinių užklausų.

Naudotojo sąsaja

  • 1Grafinė naudotojo sąsaja bei joje esantys valdymo elementai kiek galima labiau unifikuoti visoje ULSVIS.
  • 2Sąsajai su naudotoju naudojamos atvirosios technologijos. Naudotojo sąsaja įgyvendinta remiantis Web sprendimo (angl. Web based) principais.
  • 3Naudotojo sąsaja nepriklauso nuo operacinės sistemos, atitinka W3C XHTML specifikaciją.
  • 4ULSVIS naudotojų grafinė sąsaja pritaikyta, intuityvi ir suprantama neturintiems ypatingos darbo patirties su žiniatinklio portalais (turi atitikti KISS (angl. Keep it Simple, Stupid) principą) ir informacinėmis sistemomis.
  • 5Projektuojant žiniatinklio formas ir langus atsižvelgiama į gerąsias praktikas, taikytas kitose valstybinėse informacinėse sistemose.
  • 6ULSVIS sąsajos kūrimo procesas vykdomas vadovaujantis metodika ir gerąja praktika: Kuriamų viešųjų ir administracinių elektroninių paslaugų tinkamumo naudotojams užtikrinimo priemonių metodinėmis rekomendacijomis, LST EN ISO 9241 serijos standartais.
  • 7Naudotojų grafinės sąsajos įgyvendintos taikant kompiuterio pelės ir klaviatūros navigavimo grafinėje sąsajoje įrenginius (angl. mouse pointing device).
  • 8ULSVIS naudotojo sąsaja parengta vadovaujantis bendrinės lietuvių kalbos taisyklėmis.
  • 9Naudojamos informatyvios antraštės aiškiai parodo, kaip naudotojams orientuotis portale.
  • 10ULSVIS praneša apie sistemos klaidas ir (arba) priminimus apie neatliktus, tačiau privalomus atlikti veiksmus kompiuterio ekrane, pvz., panaudojant pop-up langus ar pranešimų juostas.
  • 11Visi ULSVIS naudotojams skirti klaidų pranešimai yra lietuvių kalba. ULSVIS administratoriui skirti pranešimai pateikiami lietuvių ar anglų kalbomis.
  • 12Naudotojo sąsajos klaidų pranešimai suformuluoti taip, kad naudotojui būtų aišku, kas atsitiko ir kokius veiksmus jam toliau reikia daryti, kad galėtų tęsti darbą.
  • 13Visi to paties tipo (klaidų, įspėjamieji ir kt.) pranešimai pateikiami vienodu stiliumi. Pranešimai yra spalvoti atsižvelgiant į pranešimo tipą, pavyzdžiui, klaidos žymimos raudona spalva, įspėjimai – geltona.
  • 14ULSVIS grafinė sąsaja ULSVIS naudotojams teikia pagalbą įvedant informaciją, siūlydama pasirinkti reikšmes iš klasifikatorių, sąrašų ir sistemoje suvestų duomenų (angl. autocomplete).
  • 15ULSVIS grafinė sąsaja turi ULSVIS naudotojams teikti pagalbą įvedant informaciją, siūlydama pasirinkti reikšmes, kai jų duomenys yra gaunami per integracijas (angl. autocomplete).
  • 16Datos tipo reikšmėms įvesti ULSVIS Formose yra naudojamas specializuotas komponentas, sugebantis pavaizduoti kalendorių (angl. datepicker).
  • 17ULSVIS naudotojų grafinės sąsajos informacijos įvedimo elementai teikia kontekstinę pagalbą ULSVIS naudotojui. Užvedus žymeklį ant elemento, atsiranda paaiškinimas apie laukiamos informacijos turinį ir formatą (angl. tooltip).
  • 18Vykdomas loginis duomenų laukų tikrinimas laukų lygiu ir laukų grupių lygiu. Prieš išsaugant pateiktus duomenis atliekamas išsamus loginis jų patikrinimas (pvz., ar visi privalomi laukai užpildyti, ar tinkamas asmens kodo ilgis ir pan.).
  • 19Privalomieji ir nebūtinieji duomenų įvedimo laukai aiškiai išskirti.
  • 20Mygtuko pavadinimas tiksliai nusako jo atliekamą veiksmą.
  • 21Formos pildymo / sukūrimo metu, žinoma informacija užpildoma ir išsaugoma automatiškai, pvz., Formos sukūrimo data ir laikas, ją sukūręs naudotojas, naudotojo ASPĮ ir kt.
  • 22Kiekvienas ULSVIS elementas (meniu punktas, pavadinimas ir pan.) turi nuosekliai suformuluotus pavadinimus ir išlaiko juos visuose puslapiuose.
  • 23Kiekvienas duomenų įvedimo laukas turi aiškų pavadinimą, nurodantį ULSVIS naudotojams, ką reikia įvesti.
  • 24ULSVIS naudotojams nereikia įvesti tos pačios informacijos daugiau nei vieną kartą.
  • 25Projektuojant ULSVIS grafinę sąsają yra pritaikyti naudotojo sąsajos patogumo nustatymo (angl. usability) metodai.
  • 26Visiems naudotojams sudarytos galimybės pasiekti ULSVIS titulinį puslapį iš bet kurio kito puslapio.
  • 27ULSVIS grafinė sąsaja tinkamai atvaizduojama įvairios rezoliucijos ekranuose, t. y. įgyvendinta taikant prisitaikančio dizaino (angl. Responsive design) principus.
  • 28ULSVIS grafinė sąsaja tinkamai veikia šiose naršyklėse: Microsoft Edge, Google Chrome, Mozilla Firefox.

Sistemos saugumas

  • 1Naudojama saugaus projektavimo ir kodavimo (angl. Secure Coding) praktika ir metodai (The Open Web Application Security Project (OWASP) Secure Coding Practices arba lygiaverčius).
  • 2ULSVIS saugumas pagrįstas praktikoje naudojamais įrankiais bei protokolais, tokiais kaip SSH ir SSL/TLS, S/MIME, IPSEC ir kitais.
  • 3Kiekvienas ULSVIS naudotojas unikaliai identifikuojamas. Savo tapatybę patvirtina slaptažodžiu arba kita identifikavimo ir autentifikavimo patvirtinimo priemone (pvz., per VIISP, el. bankininkystės, panašias arba lygiavertes vienareikšmiškai identifikuoti ir autentifikuoti asmenį galinčias sistemas).
  • 4ULSVIS naudotojų slaptažodžiai saugomi užšifruotu pavidalu, nesuteikiančiu galimybės atstatyti slaptažodžio. Slaptažodžių saugojimas įgyvendintas naudojant stiprius šifravimo algoritmus, pavyzdžiui, bcrypt ar Argon2.
  • 5ULSVIS nerodo įvedamo slaptažodžio.
  • 6ULSVIS naudotojų slaptažodžiai jautrūs simbolių registrui (angl. Case Sensitive), juose naudojamos raidės, skaičiai bei specialieji simboliai.
  • 7ULSVIS užtikrina, kad jos funkcijomis galėtų naudotis tik vienareikšmiškai identifikuoti asmenys.
  • 8ULSVIS autorizavimo mechanizmas įgyvendintas pagal vaidmenų / rolių modelį (angl. Role-based Model).
  • 9ULSVIS naudotojams pateikia tik tas duomenų tvarkymo priemones, kurias naudotojas turi teisę naudoti.
  • 10ULSVIS naudotojui leidžiama keisti tik tuos įrašus, kuriuos jis turi teisę keisti.
  • 11ULSVIS yra galimybė administratoriui nustatyti laiko, per kurį naudotojas neatliko sistemoje jokių veiksmų, trukmę.
  • 12ULSVIS naudotojų darbo seansas yra automatiškai užbaigiamas, jei neveikimo laikas viršija nustatytą trukmę. Automatinį seanso užbaigimą lydi aiškus naudotojo informavimas apie seanso pabaigą.
  • 13ULSVIS įgyvendinami funkcionalumai susieti su ULSVIS dalimi, įgyvendinančia veiksmų registravimo ir kontrolės mechanizmą (angl. audit trail).
  • 14ULSVIS parengtos reikiamos priemonės, kurios leistų: registruoti žurnalinius įrašus (angl. log records); apsaugoti žurnalinius įrašus nuo nesankcionuoto ar netyčinio pakeitimo.
  • 15ULSVIS duomenų bazėje saugomi ir per sąsajas perduodami duomenys yra apsaugoti nuo sąmoningo ar nesąmoningo jų iškraipymo.
  • 16Įgyvendinta apsauga nuo kenkėjiško kodo įkėlimo į ULSVIS (pvz., apribota galimybė įkelti bylas su plėtiniais .com, .exe, .bat., apsauga nuo skriptų įterpimų ar SQL injekcijų ir pan.).

Sutrikimų valdymas

  • 1Visi (tiek Tiekėjo nustatyti, tiek Perkančiosios organizacijos pastebėti ULSVIS veikimo sutrikimai turi būti registruojami Tiekėjo elektroninių kreipinių registravimo sistemoje.
  • 2ULSVIS veikimo sutrikimų prioritetai ir reakcijos laikas – laikas, per kurį Tiekėjas įsipareigoja sureaguoti į registruotą ULSVIS veikimo sutrikimą per nustatytą reakcijos laiką, atlikti pirminę incidento analizę ir pateikti PO siūlomą sprendimo būdą bei numatomų darbo laiko sąnaudų įvertinimą.
  • 3I lygio sutrikimai atitinka bent vieną iš šių kriterijų: ULSVIS nustojo funkcionuoti ir PO negali tęsti darbo su ULSVIS.
  • 4II lygio sutrikimai atitinka bent vieną iš šių kriterijų: Sutrikimas leidžiantis dirbti su ULSVIS moduliais, kuomet dėl sistemos nekorektiškų rezultatų sutrinka ULSVIS procesas, t. y. bent vienam sistemos vartotojui dėl sistemos sutrikimo nepavyksta laiku atlikti reikalingų funkcijų. Jeigu vykdant operacijas, rezultato nepavyksta pasiekti per keturias (keturias) minutes.
  • 5III lygio sutrikimai atitinka bent vieną iš šių kriterijų: Sutrikimas sukelia nepatogumus naudotis ULSVIS, bet neįtakoja esminių veiklai funkcijų (lėtas ULSVIS veikimas ir kt.); Sutrikimas nekelia grėsmės duomenims ir ULSVIS funkcionavimui, problemos sprendimas yra būtinas, bet ne kritinis.
  • 6I lygio sutrikimo reakcijos laikas/funkcionalumo atstatymo laikas: ne ilgiau kaip 2 darbo valandos/ne ilgiau kaip 2 darbo valandos.
  • 7II lygio sutrikimo reakcijos laikas/funkcionalumo atstatymo laikas: ne ilgiau kaip 4 darbo valandos/ne ilgiau kaip 4 darbo valandos.
  • 8III lygio sutrikimo reakcijos laikas/funkcionalumo atstatymo laikas: ne ilgiau kaip 8 darbo valandos/derinama su Perkančiąja organizacija.
  • 9Reakcijos laikas – laikas per kurį Tiekėjas nuo PO problemos registravimo momento Pagalbos sistemoje patvirtina problemos egzistavimą ir pateikia sprendimo paieškos būdą.
  • 10Išsprendimo laikas – laikas po problemos sprendimo būdo pateikimo per kurį Tiekėjas išsprendžia problemą. Į šį laiką nėra įskaičiuojamas PO problemos išsprendimo tikrinimo ir patvirtinimo laikas.
  • 11Problema išspręsta tada, kai PO patvirtina problemos išsprendimą Pagalbos sistemoje arba kitu suderintu būdu.
  • 12ULSVIS funkcionalumo sutrikimai, atsiradę dėl tinklo veikimo, serverių ar kitos informacinių technologijų infrastruktūros pokyčių, trečiųjų šalių teikiamų integracinių sąsajų konfigūracijų pakeitimų, taip pat dėl iš išorinių sistemų gaunamų ar joms teikiamų duomenų struktūros, formato ar turinio pasikeitimų, nelaikomi garantinės priežiūros sutarties apimties dalimi.
  • 13Tiekėjas privalo atlikti tokių sutrikimų analizę, identifikuoti jų priežastis bei įgyvendinti reikalingus Sistemos konfigūracinius, integracinius ar adaptacinius pakeitimus, užtikrinančius Sistemos veikimo tęstinumą pasikeitusiomis eksploatacinėmis sąlygomis.

Sistemos dokumentavimas

  • 1Tiekėjas turi dokumentuoti ULSVIS pokyčius bei PO perduoti atnaujintą dokumentaciją (projektavimo dokumentai ir naudotojo vadovas).
  • 2Visi atlikti pakeitimai dokumentuojami versijų valdymo sistemoje, nurodant pakeitimo aprašymą, atsakingą vykdytoją, pakeitimo diegimo datą bei aplinką (testinę ar produkcinę), siekiant užtikrinti pakeitimų atsekamumą ir atsakomybės priskyrimą.
  • 3Suvestinėje atliktų darbų ataskaitoje turi būti nurodyta: Tikslios suteiktos Paslaugos, jų pavadinimas, data ir laikas, įkainis; Jei ataskaitiniu laikotarpiu vyko versijos atnaujinimas, suvestiniame darbų akte turi būti pažymėtas naujos versijos įdiegimo faktas ir atnaujinti dokumentai.

Gyventojų portalas (GP)

  • 1Gyventojų modulis yra ULSVIS sudedamoji dalis, skirta fiziniams asmenims (gyventojams) sudaryti galimybes elektroniniu būdu naudotis su užkrečiamųjų ligų valdymu susijusiomis ULSVIS funkcijomis ir paslaugomis.
  • 2Gyventojų modulio naudotojai yra fiziniai asmenys – Lietuvos Respublikos gyventojai, kurie prie modulio jungiasi per Elektroninius valdžios vartus, naudodamiesi teisės aktuose nustatytais elektroninės atpažinties būdais.
  • 3Gyventojų modulis leidžia gyventojams peržiūrėti su jais susijusią informaciją apie užkrečiamųjų ligų atvejus, įskaitant informaciją apie nustatytą ligą, ligos eigą ir taikomas prevencines priemones.
  • 4Gyventojų modulis leidžia gauti informaciją apie galimą ar patvirtintą sąlytį su užkrečiamąja liga.
  • 5Gyventojų modulis leidžia teikti ir tikslinti duomenis, susijusius su ligos atveju, sąlyčiu su užkrečiamąja liga ar kitais epidemiologinei priežiūrai reikalingais duomenimis.
  • 6Gyventojų modulis leidžia pildyti ir teikti elektronines anketas ar kitus struktūruotus duomenis, susijusius su atvejo ar sąlytį su užkrečiamąja liga turėjusio asmens valdymu.
  • 7Gyventojų modulis leidžia gauti informacinę ir metodinę medžiagą apie užkrečiamąsias ligas, prevencines priemones, izoliavimo ar kitų visuomenės sveikatos rekomendacijų taikymą.
  • 8Gyventojų modulis leidžia peržiūrėti NVSC pateikiamus pranešimus ir kitą aktualią informaciją, susijusią su užkrečiamųjų ligų profilaktika ir kontrole.
  • 9Gyventojų modulio prieiga organizuojama laikantis informacijos saugos, asmens duomenų apsaugos ir prieigos kontrolės principų, taikomų ULSVIS.
  • 10Prisijungimas prie gyventojų modulio vykdomas per VIISP, naudojantis VIISP teikiama elektroninės atpažinties paslauga.
  • 11Gyventojų modulio veikimo metu užtikrinamas: naudotojų tapatybės patikimumas; prieigos teisių valdymas pagal būtinosios prieigos principą; asmens duomenų konfidencialumas, vientisumas ir prieinamumas; naudotojų veiksmų registravimas (auditavimas), siekiant užtikrinti veiksmų atsekamumą ir atitiktį teisės aktų reikalavimams.

Sistemos vystymas ir diegimas

  • 1ULSVIS programinio kodo pataisymai ir naujos versijos turi būti diegiamos tik iš anksto su PO atstovais suderintu laiku ir tik esant PO atstovų patvirtinimui.
  • 2ULSVIS programinio kodo pataisymai ir naujos versijos turi būti diegiamos ULSVIS testavimo aplinkoje, kur PO atstovas (-ai) patikrina atnaujintos ULSVIS veikimą.
  • 3Tiekėjas turi užtikrinti, kad įdiegus atnaujinimus, ULSVIS išliktų ir anksčiau įsigytas ULSVIS funkcionalumas, jei tai neprieštarauja naujiems atnaujinto ULSVIS funkcionalumams ir keitimas yra suderintas su PO atstovais.
  • 4Tiekėjas privalo identifikuoti operacinių sistemų ir visos su ULSVIS susijusios serveriuose įdiegtos programinės įrangos atnaujinimų, saugumo pataisų bei kritinių pažeidžiamumų diegimo poreikį ir pateikti PO siūlomų darbų planą bei numatomų darbo laiko sąnaudų įvertinimą.
  • 5Prieš atliekant bet kokius Sistemos keitimus produkcinėje aplinkoje, pakeitimai turi būti: įgyvendinti testinėje aplinkoje; patikrinti pagal nustatytą testavimo procedūrą; suderinti su PO; priskirti atsakingam vykdytojui (garantinės priežiūros arba Paslaugų Tiekėjui).
  • 6Pakeitimai į produkcinę aplinką diegiami tik po jų patvirtinimo testinėje aplinkoje ir suderinimo su PO, užtikrinant, kad pakeitimai nepaveiktų funkcionalumo ar komponentų, kuriems taikoma garantinė priežiūra.
  • 7Naujas funkcionalumas sukurtas kaip integrali ULSVIS dalis, panaudojant esamas ULSVIS priemones bei sukuriant trūkstamas (pvz. paslaugų teikimui reikalingas formas, specifinių veiklos procesų vykdymui ir formų pildymui reikalingas funkcijas ir pan.).

Tuberkuliozės valdymo modulis

  • 1Sukurtas naujas bendras centralizuotas ULSVIS Tuberkuliozės atvejų valdymo modulis ir įgyvendintas asmens duomenų, kaupiamų TVIS, perkėlimas į modernizuotą ULSVIS.
  • 2TVIS duomenys perkelti į ULSVIS Tuberkuliozės atvejų valdymo modulio duomenų bazę. Jie pasiekiami iš ULSVIS Tuberkuliozės atvejų valdymo modulio naudotojo sąsajos.
  • 3Sukurtos naujos naudotojų rolės atskiroms Tuberkuliozės atvejų valdymo modulio formoms pasiekti.
  • 4Tuberkuliozės atvejų valdymo modulyje naudojamoms formoms, jų atvaizdavimui, filtravimui, integracijoms, įgyvendinti ULSVIS funkciniai reikalavimai.
  • 5ULSVIS tuberkuliozės atvejo formoje (357-3/a) pateikti sąlytį turėjusių asmenų duomenys automatiškai susiejami (tik atvaizduojami) su Tuberkuliozės atvejų valdymo modulyje esančios tuberkulioze sirgusių / sergančių asmenų duomenų formomis.

Duomenų valdymas ir ataskaitos

  • 1Duomenų įvedimo Formos pakeistos ar konstruotos taip, kad duomenų įvedimas būtų kiek įmanoma labiau struktūrizuotas. Duomenų įvedimo formos sukurtos vadovaujantis naudotojo patogumo principais, pavyzdžiui, logiška laukų išdėstymo seka ir aiškiai pažymėtais privalomais laukais.
  • 2Duomenų įvedimo Formos kiek įmanoma automatizuotai užpildomos duomenimis, kurie jau yra saugomi ULSVIS ar kitose per integracines sąsajas pasiekiamose IS ir registruose.
  • 3Vykdomas į duomenų įvedimo Formas įvedamų duomenų tikrinimas (angl. validation) pagal nustatytas tikrinimo taisykles.
  • 4Visoms aprašytoms funkcijoms, kurių metu įvedami naudotojo duomenys, įgyvendinama tų duomenų redagavimo funkcija, kuri suderinama su veiklos logika.
  • 5Duomenų saugojimas įgyvendintas naudojant duomenų bazių valdymo sistemą (DBVS).
  • 6Duomenų bazės struktūra papildyta naujomis lentelėmis, o ne pakeista. Duomenų bazės laukai nekeičiami, o esant poreikiui juos keisti, sukuriami nauji.
  • 7Įgyvendintas naudotojų informavimo funkcionalumas, kuris tam tikrais įvykiais sistemoje išsiųstų el. laišką (-us) atitinkamam ULSVIS naudotojui.
  • 8Įdiegta galimybė filtruoti duomenis bei peržiūrėti paieškos / filtravimo rezultatų sąrašą.
  • 9Įdiegta galimybė rūšiuoti duomenis pagal pasirinktus parametrus.
  • 10Įgyvendinta galimybė Formų ir ataskaitų duomenis filtruoti.
  • 11Įgyvendinta galimybė eksportuoti sąrašinių Formų duomenis CSV ir XLSX formatais, o ataskaitų duomenis – XLSX ir PDF formatais.
  • 12Eksportavimas apima ir apjungtų bylų duomenis (pvz. susirgimo bylos yra apjungtos su sukėlėjų bylomis). Visi CSV ir XLSX duomenų laukai, įskaitant ir JSON ar kitaip struktūrizuotus duomenis, yra išskaidyti.
  • 13Įgyvendinta galimybė filtravimo parametruose rinktis daugiau nei 1 parametro reikšmę (pvz.: Vilniaus m. ir Vilniaus raj. savivaldybes).
  • 14Kiekvienoje atskiroje sąrašinių Formų kategorijoje sukurti filtravimo ir paieškos dedikuoti laukai su klasifikatoriais, laisvu tekstu ir datomis.
  • 15Sąrašinėse Formose įgyvendinta duomenų rūšiavimo galimybė.
  • 16Įgyvendinta galimybė keisti lape atvaizduojamų įrašų kiekį.
  • 17Sąrašinėse Formose įgyvendintas puslapiavimas, leidžiantis naudotojams lengvai pereiti tarp skirtingų puslapių.
  • 18Iš sąrašinių Formų, atsidarius konkrečią bylą arba kuriant naują bylą, uždarius bylą ir grįžus į sąrašines Formas, išsaugomi anksčiau pasirinkti filtravimo ir atvaizdavimo parametrai.
  • 19Formų filtro paieška veikia nepriklausomai nuo to, ar buvo įvestos didžiosios, mažosios, specifinės lietuviškos raidės ar žodžio dalis.
  • 20Galima rankiniu būdu redaguoti visus bylų duomenis.
  • 21Įgyvendinta galimybė kurti naują ataskaitinę Formą, kopijuojant anksčiau užpildytą Formą, taip pernaudojant anksčiau užpildytus duomenis.
  • 22ULSVIS vidiniame ir išoriniame portale ULSVIS naudotojui pradėjus pildyti naują Formą, Formos laukai automatiškai užsipildo naudotojo informacija (vardas, pavardė, įstaiga, tel. Nr., pareigos ir kt.).
  • 23Vykdomas duomenų įvedimo į Forma tikrinimas (angl. validation) pagal Formoms nustatytas tikrinimo taisykles: tikrinami privalomi įvesti duomenys; tikrinamas duomenų formatas; tikrinami pridedamų rinkmenų plėtiniai ir rinkmenos dydis; atliekamas loginis tikrinimas tarp Formos elementų; atliekamas loginis tikrinimas tarp Formos elementuose užpildytų duomenų; atliekamas ARV Formose užpildytų duomenų panaudojimas, pildant naują Formą, t. y. kuriama nauja ataskaita senosios pagrindu su galimybe koreguoti duomenis.
  • 24Vidiniame ULSVIS portale peržiūrint ART gautas formas yra patikrinama pagal paciento asmens kodą ir einamuosius metus, ar pacientas turi ULSVIS sistemoje uždarytas hepatito B, hepatito C ir tuberkuliozės formas. Po peržiūros automatiškai ART Formose parenkamos reikšmės iš numatytų klasifikatorių.
  • 25Įgyvendinta pasikartojančių susirgimo atvejų tam pačiam asmeniui valdymo galimybė – administratoriaus modulyje, parenkant TLK-10-AM kodų grupes, joms galima priskirti laiko intervalą dienomis, kai vėliau nei pirmas susirgimo atvejis, registruotas tam pačiam asmeniui ULSVIS, bus vertinamas kaip įtariamas dublis.
  • 26Įtariami dubliai nebus atvaizduojami sąrašinėse Formose, bet jie bus prieinami atskirame skirtuke, vertinamu laikotarpiu, pirmojoje asmeniui patvirtintoje susirgimo byloje.
  • 27Yra galimybė patvirtinti arba atšaukti susirgimo bylos dublio statusą.
  • 28Vertinamu laikotarpiu pirmoji asmeniui patvirtinta susirgimo byla, jeigu jai atsirado įtariamų dublių, išsiskiria suderintu indikatoriumi iki to momento, kol įtariamiems dubliams bus patvirtinti bylų statusai.

Klasifikatorių administravimas

  • 1Sistemoje yra naudojami klasifikatoriai.
  • 2Visi klasifikatoriai duomenimis papildomi per administratoriaus sąsają.
  • 3Įgyvendinta galimybė tvarkyti ULSVIS klasifikatorius: Redaguoti esamų klasifikatorių reikšmes; Įvesti naujas esamų klasifikatorių reikšmes; Nustatyti galiojimo pradžios ir pabaigos datas esamoms klasifikatoriaus reikšmėms.
  • 4Atlikus klasifikatorių tvarkymo veiksmus pakeitimai turi atsispindėti ULSVIS.

Sistemos standartai ir valdymas

  • 1ULSVIS naudoja VSSA infrastruktūrą ir teikiamą programinę įrangą.
  • 2ULSVIS turi tenkinti visus II kategorijos valstybės informaciniams ištekliams keliamus reikalavimus.
  • 3ULSVIS pasiekiama internetinės naršyklės priemonėmis.
  • 4ULSVIS užtikrina korektišką avarinių situacijų, kurias sukėlė neteisingi ULSVIS naudotojo veiksmai, valdymą. ULSVIS naudotojui atlikus neteisingą (neleidžiamą) komandą arba nekorektiškai įvedus duomenis, ULSVIS naudotojui rodo atitinkamus pranešimus ir po to grįžta į darbo būklę.
  • 5LST EN ISO/IEC 27001:2023. Informacijos saugumas, kibernetinis saugumas ir privatumo apsauga. Informacijos saugumo valdymo sistemos. Reikalavimai (ISO/IEC 27001:2022) – Arba lygiavertis: Bendrasis duomenų apsaugos reglamentas (BDAR).
  • 6Valstybės informacinių sistemų gyvavimo ciklo valdymo metodika, patvirtinta IVPK direktoriaus 2014-02-25 įsakymu Nr. 2033 „Dėl Valstybės informacinių sistemų gyvavimo ciklo valdymo metodikos patvirtinimo“.
  • 7LST EN 301 549 V2.1.2:2018. IRT produktų ir paslaugų prieinamumo reikalavimai.
  • 8Visi ULSVIS funkciniai komponentai palaiko Unicode (UTF – 8) standartą.
  • 9Naudojama ne žemesnė kaip HTML5 (angl. Hypertext Markup Language) versija.
  • 10Naudojama ne žemesnė kaip 3 lygio CSS3 (angl. Cascading Style Sheets Language 3).

Bendrieji paslaugų reikalavimai

  • 1Paslaugos turi būti teikiamos darbo dienomis darbo laiku nuo aštuntos (8.00 val.) iki septynioliktos valandos (17.00 val.). Darbo dienos trukmė prieš šventines dienas – viena valanda trumpesnė.
  • 2Konsultacijos turi būti teikiamos telefonu, el. paštu, internetu ar darbo vietoje.
  • 3Kitos Paslaugos teikiamos interneto ryšio priemonėmis (tuo tikslu Perkančioji organizacija sudaro galimybę Tiekėjo įgaliotiems asmenims nuotoliniu būdu prisijungti prie ULSVIS tarnybinių stočių) arba PO darbo vietoje.
  • 4ULSVIS palaikymo ir vystymo paslaugos turi būti teikiamos pagal darbo laiko sąnaudomis pagrįstą modelį.
  • 5Visi Tiekėjo atliekami darbai, įskaitant: ULSVIS veikimo sutrikimų analizę ir šalinimą; funkcionalumo palaikymą; adaptacinius pakeitimus; integracijų konfigūravimą; konsultacijas; naujo funkcionalumo kūrimą ar modifikavimą atliekami tik po to, kai PO suderina planuojamų darbų apimtį ir Tiekėjo pateiktą darbo laiko sąnaudų įvertinimą.
  • 6PO pageidavimai gauti paslaugas įforminami siunčiant pranešimą el. paštu arba per elektroninę Teikėjo kreipinių valdymo sistemą.
  • 7Tiekėjas privalo pateikti PO užduoties įgyvendinimo galimybių įvertinimą, numatomus įgyvendinimo terminus bei darbo laiko sąnaudų įvertinimą ne vėliau kaip per 5 (penkias) darbo dienas nuo užduoties gavimo dienos, jei Šalys nesusitaria kitaip.
  • 8Tiekėjas suteikia garantiją sukurtam ar modifikuotam ULSVIS funkcionalumui visam sutarties galiojimo laikotarpiui, tačiau ne trumpesniam kaip 6 (šešių) mėnesių laikotarpiui nuo konkrečių paslaugų perdavimo–priėmimo akto pasirašymo dienos.
  • 9Garantiniu laikotarpiu nustatyti funkcionalumo veikimo sutrikimai ar klaidos, atsiradusios dėl Tiekėjo atliktų darbų, šalinami Tiekėjo sąskaita be papildomo apmokėjimo, jei funkcionalumas nebuvo modifikuotas PO, kitų tiekėjų, garantinę priežiūrą vykdančio rangovo ar trečiųjų šalių; sutrikimas neatsirado dėl išorinių sistemų, infrastruktūros ar trečiųjų šalių veiksmų; funkcionalumo naudojimas atitinka PO patvirtintą specifikaciją.

Sistemos našumas ir patikimumas

  • 1ULSVIS funkcionavimui taikomi aukšto pasiekiamumo reikalavimai, todėl galima dubliuoti visus pagrindinius techninius elementus (tarnybines stotis, duomenų bazes, tinklo įrangą).
  • 2ULSVIS užtikrina nepertraukiamą paslaugų teikimą dideliam ULSVIS naudotojų skaičiui. Numatoma, kad ULSVIS vienu metu privalo aptarnauti ne mažiau kaip 500 naudotojų.
  • 3ULSVIS turi gebėti išlaikyti nustatytą našumą didėjant naudotojų skaičiui.
  • 4ULSVIS palaiko lankstaus naudojamų techninių resursų valdymo galimybės.
  • 5Vertikalus ULSVIS komponentų mastelio keitimas – naudojamų resursų padidinimas / sumažinimas vienai techninei aplinkai (angl. scale-up).
  • 6Horizontalus ULSVIS komponentų mastelio keitimas – naudojamų resursų padidinimas / sumažinimas keičiant aplinkų, atliekančių analogiškas funkcijas, kiekį (angl. scale-out).
  • 7ULSVIS palaiko galimybę dirbti aukšto patikimumo klasterio konfigūracijoje, kai pagrindinės techninės įrangos gedimo atveju jos funkcijas automatiškai perima rezervinė techninė įranga.
  • 8ULSVIS suderinama su automatinio perkrovimo priemonėmis, kad, įvykus incidentui, programinės įrangos paleidimas įvyktų automatiškai be žmogaus įsikišimo, o apdorojami duomenys bei programinės įrangos konfigūracijos duomenys būtų apsaugoti nuo praradimo incidento metu.
  • 9ULSVIS vidinio ir išorinio portalo realizacija užtikrina, kad, kai su ULSVIS vienu metu dirba 1000 naudotojų ir kiekvienas naudotojas kas 5 sekundes atlieka atsitiktinį veiksmą, atsakas neturi viršyti 3 sekundžių.
  • 10ULSVIS reakcijos laikas į sudėtingus ULSVIS naudotojo veiksmus (įvestos informacijos patikrinimas ir išsaugojimas) neviršija 5 sekundžių.
  • 11USLVIS greitaveika nesulėtėja, kai duomenų bazės žemiau išvardintose lentelėse įrašyta po 20 000 000 (dvidešimt milijonų) testinių duomenų eilučių.
  • 12Įgyvendintas automatizuotas periodinis ULSVIS valdymui, tvarkymui, veiklai, administravimui nenaudojamų sisteminių duomenų trynimas.
  • 13Automatinės (foninės, paketinės) užduotys nedaro įtakos ULSVIS naudotojų darbui.

Techninė ir programinė įranga

  • 1Yra galimybė atkurti duomenis iš rezervinių, duomenų kopijų.
  • 2ULSVIS yra įgyvendintas su sistemos ir jos komponentų veikimo stebėjimo bei išankstinio perspėjimo funkcionalumu.
  • 3Sistemos administratoriaus teises turintiems naudotojams užtikrinta galimybė stebėti sistemos bei atskirų jos komponentų veikimo rodiklius (aktyvius naudotojus, atminties panaudojimą, procesorių apkrovą) ir gauti pranešimus sutrikus komponentų veikimui ar rodikliams pasiekus kritines reikšmes.
  • 4ULSVIS naudotojų skaičius nėra ribojamas licencijomis.
  • 5ULSVIS apdorojamos informacijos apimtys nėra ribojamos licencijomis.
  • 6Tiekėjas gali siūlyti naudoti komercinę programinę įrangą, bet tokiu atveju šią įrangą turi teikti VSSA.
  • 7Licencinės programinės įrangos licencijos yra be galiojimo apribojimų laike.
  • 8Licencijomis neribojama sukurtos ULSVIS programinės įrangos modifikavimo galimybė ateityje.

Protrūkių identifikavimo modulis

  • 1Yra sukurtos naujos naudotojų rolės, leidžiančios pasiekti ULSVIS naudotojams protrūkių identifikavimo modulio funkcionalumą.
  • 2Susirgimo bylos yra pasiekiamos pagal turimas roles.
  • 3ULSVIS Protrūkių identifikavimo modulio funkcionalumas leidžia identifikuoti susijusius susirgimo atvejus, kurie atitinka iš anksto nustatytus kriterijus.
  • 4Galimi pasirinkti kriterijai protrūkiams vertinti, kuriant protrūkio stebėjimo objektą (protrūkių stebėjimo objektų galima kurti neribotą skaičių): TLK-10 AM kodas arba jų sąrašas; Maksimalus atstumas metrais tarp susirgimo atvejų, kurie bus vertinami įtariamo protrūkio identifikavimui; Pasirenkami adresų tipai (darbovietės, gyv. vietos, maisto įsigijimo vieta, galimo užsikrėtimo vietos, maitinimo įstaiga, ugdymo įstaiga), kurie bus vertinami; Maksimalus laiko tarpas, kai patvirtinti susirgimai gali būti vertinami kaip susiję.
  • 5Laisvu tekstu suvesti epidemiologinio tyrimo duomenys yra vertinami, atpažįstant pasikartojančius raktinius žodžius.
  • 6Kriterijai, kurių stebėjimas taikomas automatiškai, nepasirenkant jų atskirai kuriant protrūkio stebėjimo objektą: įtariami protrūkiai identifikuojami vertinant juos ir pagal laboratorinius sukėlėjų duomenis (cgMLST, MLST ir kt.).
  • 7Individualūs atvejai bendrame susirgimų sąraše įgauna indikatorių, pranešantį, kad atvejai yra priskirti įtariamam protrūkiui.
  • 8Protrūkių identifikavimo modulyje atsiranda įtariamo protrūkio valdymo byla. Pasirinkus protrūkį (įtariamą, patvirtintą, užbaigtą ar atšauktą), sąraše ir žemėlapyje atvaizduojamos visos su protrūkiu galimai susijusios susirgimo bylos.
  • 9Protrūkių identifikavimo modulyje žemėlapyje pažymėti protrūkio atvejai (įtariamas, patvirtintas, uždarytas, atšauktas) yra apibraukti apskritimu.
  • 10Identifikuotų atvejų grupei (ar vienam atvejui) NVSC specialistas patvirtina protrūkį (arba atšaukia įtariamą protrūkį), suteikia jam identifikuojantį pavadinimą ir priskiria protrūkiui šeiminio ar išplitusio tipą.
  • 11Patvirtinus protrūkį, jam priklausantys atvejai automatiškai susiejami su protrūkiu ir toliau nėra vertinami identifikuojant kitus protrūkius, bet atvaizduojami žemėlapyje.
  • 12Atšaukus įtariamą protrūkį, jam priklausantys atvejai automatiškai priskiriami atšauktam protrūkiui ir nėra vertinami identifikuojant kitus protrūkius, bet atvaizduojami žemėlapyje.
  • 13Unikalius atvejus (nebūtinai identifikuotus kaip susijusius įtariamam protrūkiui) galima priskirti protrūkiui (arba atsieti nuo protrūkio), suteikiant pirminio ar antrinio protrūkiui priklausančio atvejo požymį.
  • 14Nauji susirgimo atvejai vertinami, automatiškai juos siejant su protrūkiais (įtariamais, patvirtintais, uždarytais, atšauktais).
  • 15Stebėti atvejus (atvaizduoti žemėlapyje ir sąraše), kuriems yra taikomi protrūkio identifikavimo kriterijai.
  • 16Stebėti (atvaizduoti) įtariamus protrūkius, patvirtintus protrūkius, uždarytus protrūkius ir atšauktus protrūkius žemėlapyje ir sąraše.
  • 17Žemėlapyje ir sąraše yra galimybė filtruoti atvejus ir protrūkius pagal: protrūkio pavadinimą; protrūkio būseną; diagnozės nustatymo laiką; susirgimo atvejo tipą; protrūkio tipą; hospitalizavimo faktą; užsikrėtimo aplinkybes susirgimo bylose apibūdinančius duomenis; adresus – žemėlapyje pažymėtos susirgimo bylos su adreso skirtingais tipais turi turėti skirtingus identifikatorius; juridinio asmens pavadinimą ir kt.
  • 18Galimybė keisti protrūkio būseną (pvz. atnaujinti užbaigtą protrūkį, priskiriant jam patvirtinto atvejo būseną).
  • 19Galimybė protrūkio byloje nurodyti protrūkio pradžios ir pabaigos datas.
  • 20Galimybė protrūkio byloje pateikti tekstinį protrūkio aprašymą.
  • 21Protrūkio byloje automatiškai pateikti pagrindiniai duomenys apie protrūkį: tipas, būsena, pavadinimas, pradžios ir pabaigos datos, pirmojo, antrojo ir paskutiniojo atvejo diagnozės patvirtinimo datos, savivaldybės su atvejų skaičiumi, bendras atvejų skaičius, pirminių ir antrinių atvejų skaičius, atvejų skaičius pagal amžių, TLK-10-AM kodų skaičiai protrūkyje; kreipėsi medicininės pagalbos skaičius pagal datą; hospitalizuotų skaičius pagal datą; gydomų ambulatoriškai skaičius pagal datą; laboratoriškai ištirtų skaičius pagal datą; laboratoriškai patvirtintų atvejų skaičius pagal datą.
  • 22Galimybė prie protrūkio bylos prisegti dokumentą (.pdf, .docx, .xlsx formatu).
  • 23Galimybė eksportuoti protrūkio bylos duomenis į csv, xlsx, pdf.
  • 24Galimybė apjungti protrūkius tarpusavyje.
  • 25Naudojama GOOGLE MAPS žemėlapių programinė įranga su atvira sąsaja kreipiniams per internetą, kuri leidžia adresus versti į koordinates, taip pat koordinates galima įrašyti rankiniu būdu arba pasirenkant tašką žemėlapyje.
  • 26ULSVIS programinė įranga vykdo automatinį koordinačių duomenų konvertavimą iš LKS-94 į WGS-84 arba atvirkščiai.
  • 27Protrūkio identifikavimas, įvertinant indikatorių kriterijų atitikimą protrūkiui identifikuoti, vykdoma tuo pat metu, kai susirgimo byla ULSVIS uždaroma.

Atvejo ir sąlyčio valdymo modulis

  • 1Neribota prieiga prie asmens, turėjusio sąlytį su užkrečiamąja liga, anketos pildymo įgyvendinta internetu, pagal IP adresą.
  • 2Yra galimybė susieti asmens, turėjusio sąlytį su užkrečiamąja liga, anketą su visomis susirgimo bylos versijomis (uždaryta / atidaryta / atšaukta).
  • 3Yra galimybė iš susirgimo bylos ir atskirai (kai susirgimo bylos nėra) išsiųsti SMS žinute užklausą anketai pildyti asmeniui, turėjusiam sąlytį su užkrečiamąja liga.
  • 4SMS žinutėje pateikiama unikali nuoroda į atvejo ar asmens, turėjusio sąlytį su užkrečiamąja liga, anketą, kurios duomenys bus susieti su atvejo anketos duomenimis.
  • 5Įdiegta galimybė Lietuvos piliečiams ir asmenims, turintiems leidimą gyventi Lietuvoje, pildyti atvejo ar asmens, turėjusio sąlytį su užkrečiamąja liga, anketas be unikalios SMS gautos nuorodos, autentifikuojant naudotojus per VIISP, el. bankininkystės ar panašias, vienareikšmiškai asmenį identifikuoti ir autentifikuoti leidžiančias sistemas.
  • 6Inicijuojant prašymą anketai pildyti, yra galimybė nurodyti tekstą SMS žinutėje, o nuoroda į anketą būtų pridedama automatiškai. Galutinis SMS žinutės tekstas yra atvaizduojamas jį kuriant.
  • 7Administratoriaus sąsajoje yra galimybė aktyvuoti ir deaktyvuoti asmens, turėjusio sąlytį su užkrečiamąja liga, anketos pildymo procesą pagal TLK – 10 AM (yra galimybė nurodyti kelis TLK-10 AM kodus).
  • 8Susirgimo bylose yra skirtukas, kurį atsidarius matomi asmenų, turėjusių sąlytį su užkrečiamąja liga, pateikti anketų duomenys.
  • 9Administratoriaus sąsajoje yra galimybė aktyvuoti ir deaktyvuoti atvejo anketos pildymo procesą pagal TLK – 10 AM (yra galimybė nurodyti kelis TLK-10 AM kodus).
  • 10Sukurtos atskiros bylų kategorijos: „Atvejų anketos“ ir „Asmenų, turėjusių sąlytį su užkrečiamąja liga, anketos“.
  • 11Sukurta papildoma naudotojų rolė: „Atvejų anketos“ ir „Asmenų, turėjusių sąlytį su užkrečiamąja liga, anketos“.
  • 12Administratoriaus galimybė kurti atvejo ir asmenų, turėjusių sąlytį su užkrečiamąja liga, anketų laukus. Laukai yra vienodi tiek pildomose anketose, tiek pateiktose anketose, tiek ir susietose anketose.
  • 13Aktyvuojant anketas ir kuriant individualius jų laukus, neprarandami anksčiau sukurtų ir užpildytų anketų duomenys.
  • 14Yra galimybė NVSC specialistui sukurti rankiniu būdu pildomą asmenų, turėjusių sąlytį su užkrečiamąja liga, anketą arba atvejo anketą atskirai ir be SMS siuntimo.
  • 15Yra sugeneruotos nuorodos atvejo ir asmenų, turėjusių sąlytį su užkrečiamąja liga, anketoms pildyti internetu.
  • 16Užklausos pildyti atvejo ir asmenų, turėjusių sąlytį su užkrečiamąja liga, anketai gali būti siunčiamos atskirai, ne vien tiktai iš susirgimo bylos.
  • 17Galimybė per administratoriaus sąsają dinamiškai pridėti papildomus laukus, įskaitant klasifikatorius, po kiekvienu iš šių punktų arba apačioje atskirame punkte.

Duomenų archyvavimas ir saugojimas

  • 1Vykdomas automatinis duomenų archyvavimas ir nuasmeninimas pagal šias taisykles: 1. Susirgimų ir sukėlėjų bylos: ŽIV, virusinių hepatitų, tuberkuliozės ULSVIS pagrindinėje duomenų bazėje saugomi 15 metų. Pasibaigus šiam terminui, duomenys perkeliami į ULSVIS duomenų bazės archyvą. Asmens duomenys ULSVIS duomenų bazės archyve saugomi 30 metų. Pasibaigus asmens duomenų saugojimo 30 metų terminui, duomenys yra nuasmeninami. 2. Kitos susirgimų ir sukėlėjų bylos: ULSVIS pagrindinėje duomenų bazėje saugomi 3 metus. Pasibaigus šiam terminui, duomenys nuasmeninami ir perkeliami į ULSVIS duomenų bazės archyvą. 3. Pagrindinėje duomenų bazėje ataskaitos saugomos 5 metus. Pasibaigus šiam terminui, duomenys nuasmeninami ir perkeliami į ULSVIS duomenų bazės archyvą. 4. Kitos pagrindinėje duomenų bazėje ataskaitos saugomos 3 metus. Pasibaigus šiam terminui, duomenys nuasmeninami ir perkeliami į ULSVIS duomenų bazės archyvą.
  • 2Archyviniai duomenys pasiekiami priklausomai nuo ULSVIS naudotojui priskirtų teisių darbui su bylomis (kiekvienai ligų, ataskaitų ir kitų bylų grupei yra atskira rolė), papildomai sukūrus naujas naudotojų roles archyviniams duomenims pasiekti.

Papildomi moduliai ir funkcionalumas

  • 1ULSVIS skiepų funkcionalumas skirtas informacijai apie nepageidaujamas reakcijas į skiepus surinkti iš ASPĮ bei šiai informacijai tvarkyti.
  • 2Yra galimybė peržiūrėti ULSVIS registruotus pranešimus apie nepageidaujamas reakcijas į skiepus pagal suteiktas naudotojo teises.
  • 3Yra galimybė Nepageidaujamų reakcijų į skiepus protokolų duomenis eksportuoti į csv, xlsx.
  • 4ULSVIS Formose informacijos apie sąlytį funkcionalumas skirtas informacijai apie sąlytį turėjusius asmenis surinkti ir apdoroti.
  • 5Informacijos apie sąlytį valdymas yra paremtas informacija, gaunama atliekant atvejo epidemiologinį tyrimą ir suvedant duomenis į atvejo kortelėje esantį skirtuką „Priemonės židinyje” (asmenį identifikuojantys ir kontaktiniai duomenys, duomenys apie darbovietę / ugdymo įstaigą, duomenys apie sąlytį (kontaktą), informacija apie keliautoją, sukėlėjo informacija ir kt.).
  • 6Reikiamų MS Word dokumentų formavimas ir perdavimas į DVS.
  • 7Integracija su JAR (DVS moduliui).

Sistemos architektūra ir technologijos

  • 1ULSVIS architektūrinis sprendimas užtikrina didelį sistemos prieinamumą (High availability).
  • 2Architektūra remiasi į paslaugas orientuotos architektūros principais (angl. service-oriented Architecture) ir užtikrina galimybę plėsti funkcionalumą, sukuriant papildomus programinės įrangos komponentus bei integruojant ją su kitomis informacinėmis sistemomis nekeičiant esamų komponentų.
  • 3Komponentai projektuojami kaip nepriklausomos paslaugos, kurios gali būti įtrauktos arba pašalintos be kitų sistemos dalių keitimo.
  • 4Realizacija pagrįsta daugiasluoksne architektūra, kuri leistų sistemą plėsti ir pritaikyti prie besikeičiančių poreikių.
  • 5Sistema sukurta ne mažiau kaip 3 sluoksnių architektūros (angl. three–tier, 3–tier) pagrindu ir turi galimybę būti integruojama atskirų sluoksnių lygmenyse. Įgyvendinti vaizdavimo, veiklos logikos ir duomenų lygmenys.
  • 6Kiekvienas sluoksnis (pristatymo, verslo logikos, duomenų) aiškiai atskirtas ir komunikacija tarp jų apibrėžta per standartizuotas sąsajas.
  • 7Visi ULSVIS duomenys yra saugomi reliacinėje duomenų bazių valdymo sistemoje.
  • 8Naudotojai negali turėti galimybės atlikti operacijų tiesiogiai duomenų bazėje.
  • 9ULSVIS suprojektuota ir įgyvendinta taip, kad būtų lanksti modifikuojant – įgyvendinus funkcionalumo pakeitimus vienoje ar keliose funkcinėse srityse. Pakeitimai nėra visos ULSVIS sukūrimo iš naujo priežastimi.
  • 10ULSVIS duomenų mainai ir integracijos su kitomis informacinėmis sistemomis ir registrais įgyvendinti pagal SOA (angl. Service Oriented Architecture) principus, išlaikant kuo didesnę sistemą sudarančių komponentų tarpusavio nepriklausomybę.
  • 11ULSVIS palaiko XML (eXtensible Markup Language) bei JSON (angl. JavaScript object notation) ir yra su jomis suderinama.
  • 12Tvarkomų ir saugomų duomenų dydis nėra ribojamas ULSVIS programinio sprendimo ir jo funkcinės architektūros.
  • 13ULSVIS naudojami architektūriniai ir technologiniai sprendimai, užtikrinantys įvedamų ir saugomų duomenų autentiškumą, nepakeičiamumą ir integralumą. Visi duomenų tvarkymo veiksmai registruojami taip, kad bet kada būtų įmanoma nustatyti, kas, kada ir kokius duomenis pakeitė.
  • 14ULSVIS įgyvendinti sprendimai naudotojų nereikalauja įsigyti mokamos programinės įrangos.
  • 15Veiklos procesų schemų, modelių, duomenų bazių schemų, programinių komponentų sąsajų schemų ir kitų elementų sąsajų schemų projektavimui naudojamas UML standartas (angl. Unified Modeling Language) arba lygiavertis.
  • 16ULSVIS palaiko virtualizacijos platformas.
  • 17Siekiant užtikrinti internetu perduodamos informacijos saugą, naudojamas TLS, 1.2 versija ar naujesnė, kuri įtraukia šiuolaikines šifravimo metodikas ir algoritmus, tokius kaip AES ir SHA-256.
  • 18Palaikomas X.509 arba naujesnis standartas naudojant skaitmeninius sertifikatus.
  • 19Šifravimo standartas AES (angl. Advanced Encryption Standard) arba lygiavertis ar naujesnis. AES šifravimas gali būti naudojamas kartu su kitais saugumo protokolais, pavyzdžiui, PGP ar RSA, užtikrinant duomenų saugumą perduodant juos internetu.

Vartotojų valdymas ir prieigos teisės

  • 1Naudotojams įgyvendintos prieigos teisės pagal roles, bylų kategorijas ir savivaldybes.
  • 2Naudotojai turi centralizuotą susirgimo bylų paieškos galimybę visose jų prieigai priskirtose bylose.
  • 3IP konkrečios įstaigos darbuotojo suvestos bylos matomos visiems įstaigos naudotojams pagal jiems priskirtas teises.
  • 4Yra galimybė administruoti vidinio ir išorinio ULSVIS portalo naudotojus.
  • 5Naudotojų teisės ir rolės yra tvarkomos ULSVIS. Yra įgyvendinta galimybė sudaryti roles (apibrėžti rolę ir priskirti teises).
  • 6Diegėjas turi sudaryti pradinius ULSVIS naudotojų rolių ir teisių rinkinius, pvz. rolės kaip „Administratorius“, „Matytojas“, „Standartinis naudotojas“ su atitinkamomis prieigos prie duomenų, ataskaitų generavimo ir sistemos konfigūracijos teisėmis.
  • 7Sukurtos sąsajos, leidžiančios lengvai kurti ir keisti roles, pavyzdžiui, interaktyvus naudotojo sąsajos įrankis rolių kūrimui ir teisių priskyrimui.
  • 8Yra galimybė kurti naujus ULSVIS naudotojus: yra galima sukurti naudotojams prisijungimo vardus ir slaptažodžius; priskirti roles.
  • 9Yra galimybė koreguoti naudotojų duomenis. Negalima koreguoti naudotojo identifikacinių duomenų (naudotojo prisijungimo vardo), kad nebūtų prarasta informacija, kokius veiksmus sistemoje naudotojas atliko.
  • 10Yra funkcionalumas deaktyvuoti naudotojui galimybę jungtis naudojant slaptažodį.
  • 11Yra galimybė blokuoti naudotojus. Blokavimas gali būti laikinas arba nuolatinis.
  • 12Naudotojams leidžiama pakeisti slaptažodį. Naudotojai turi galimybę keisti savo slaptažodžius bet kuriuo metu per naudotojo sąsają ir ši funkcija yra lengvai pasiekiama.
  • 13Sukurtas naujai sukurto naudotojo ar naudotojo slaptažodžio duomenų siuntimo el. paštu funkcionalumas.
  • 14Slaptažodžiai turi turėti galiojimo laiką. Pasibaigus galiojimo laikui sistema turi leisti naudotojui pasikeisti slaptažodį.
  • 15Administratorius yra suteikta galimybė nustatyti naudotojų leidžiamų naudoti slaptažodžių sudėtingumo lygį ir slaptažodžių galiojimo laiką.

Teisinės atitikties ir saugumo standartai

  • 1Atliekamas žaliasis pirkimas, vadovaujantis Lietuvos Respublikos aplinkos ministro 2011 m. birželio 28 d. įsakymu Nr. D1-508 „Dėl Aplinkos apsaugos kriterijų taikymo, vykdant žaliuosius pirkimus, tvarkos aprašo patvirtinimo“ patvirtinto Aplinkos apsaugos kriterijų taikymo, vykdant žaliuosius pirkimus, tvarkos aprašo 4.4.3 papunkčiu: „4.4.3. perkama tik nematerialaus pobūdžio (intelektinė) ar kitokia paslauga, nesusijusi su materialaus objekto sukūrimu, kurios teikimo metu nėra numatomas reikšmingas neigiamas poveikis aplinkai, nesukuriamas taršos šaltinis ir negeneruojamos atliekos“.
  • 2ULSVIS atitinka saugumo reikalavimus, keliamus šiuose Lietuvos Respublikos teisės aktuose: 2016 m. balandžio 27 d. Europos Parlamento ir Tarybos reglamente (ES) 2016/679 „Dėl fizinių asmenų apsaugos tvarkant asmens duomenis ir dėl laisvo tokių duomenų judėjimo ir kuriuo panaikinama Direktyva 95/46/EB (Bendrasis duomenų apsaugos reglamentas)“; Organizacinių ir techninių kibernetinio saugumo reikalavimų, taikomų kibernetinio saugumo subjektams, apraše, patvirtintame Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 5 d. nutarimu Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo“; Techniniuose valstybės registrų (kadastrų), žinybinių registrų, valstybės informacinių sistemų ir kitų informacinių sistemų elektroninės informacijos saugos reikalavimuose, patvirtintuose Lietuvos Respublikos Krašto apsaugos ministro 2020 m. gruodžio 4 d. įsakymu Nr. V-941; Lietuvos Respublikos valstybės informacinių išteklių valdymo įstatyme, 2011 m. gruodžio 15 d. Nr. XI-1807.
  • 3Teikiant paslaugas, vadovaujamasi saugaus projektavimo ir kodavimo (angl. Secure Coding) praktika ir metodais (The Open Web Application Security Project (OWASP) Secure Coding Practices, programinės įrangos saugos užtikrinimo standartu (angl. Application Security Verification Standard) ar lygiaverčius), o atliekant patikrinimus (testavimus) remiamasi Open Web Application Security Project (OWASP) Testing Guide v4, Penetration Testing Execution Standard (PTES), Open Source Security Testing Methodology Manual (OSSTMM), Information Systems Security Assessment Framework (ISSAF), SANS, NIST SP 800-30 ar lygiavertėmis saugumo patikrinimo metodikomis, siekiant užtikrinti, kad Paslaugų rezultatai neturėtų saugumo spragų.

Programinės įrangos kodas ir dokumentacija

  • 1Visa programinė įranga pilnai perduota PO (perduotos visos turtinės teisės ir išeities kodai bei konfigūracijos).
  • 2Kartu su išeities kodu pateikta reikalinga dokumentacija, siekiant užtikrinti, jog PO galės visapusiškai suprasti ir valdyti programinę įrangą.
  • 3Perduodami išeities tekstai (angl. source code) pateikiami tik elektroninėje laikmenoje ir atitinka šiuos reikalavimus: išeities tekstai perduoti kompiliavimui paruoštų rinkmenų paketų forma, nurodant standartines kompiliavimo priemones ir kompiliavimo eigą; išeities tekstai perduoti tų įrankių, kuriais jie sukurti, naudojamu formatu (GIT ar atitinkamu), jeigu toks formatas egzistuoja.
  • 4Išeities tekstai yra su komentarais ir atitinka gerąsias programinio kodo formatavimo, kintamųjų bei funkcijų įvardinimo praktikas.
  • 5PO yra perduoti pilni, korektiški išeities tekstai, iš kurių, naudojant standartines priemones, būtų kompiliuojama naudojimui parengta programinė įranga, atliekanti jai specifikuotas funkcijas.
  • 6Dokumentuotos ir pateiktos SQL select užklausos kiekvienam Formos tipui atskirai. Užklausoje pateikiamas lentelių apjungimas ir išvardyti norimi išgauti laukai. Norimi išgauti laukai turi atitikti ULSVIS atvaizduojamos Formos laukus, įskaitant susietas bylas (tokias kaip sukėlėjų Formos, protrūkių duomenys ir t.t.).
  • 7Visa išeities kodų bazė atitinka aukštus kodo komentavimo standartus: aiškumas, nuoseklumas, reikšmingumas, metodų ir klasės aprašymai, kodų blokų aiškinimai, istoriniai komentarai, skaitomumo užtikrinimas.
  • 8Jei ULSVIS modernizavimui buvo panaudoti trečiųjų šalių komponentai ar kiti sprendimai, su išeities kodu pateikiamas sąrašas naudojamų priklausomybių, trečiųjų šalių bibliotekų ir (arba) įrankių su atitinkamais licencijų aprašymais.

Dokumentai4

  • 2_ULSVIS+PALAIKYMO+IR+VYSTYMO+PASLAUGŲ+TECHNINĖ+SPECIFIKACIJA+.docx
  • 3_ULSVIS_TECHNINIS APRAŠYMAS (SPECIFIKACIJA).docx
  • 1_RINKOS KONSULTACIJA DĖL ULSVIS PALAIKYMO IR VYSTYMO PASLAUGŲ PIRKIMO (2).docx
  • 4917_7192386.pdf
tendis.lt · Sukurta recodin.lt