Grįžti į sąrašą

Karpol.lt naujos interneto svetainės sukūrimo, įdiegimo, duomenų perkėlimo ir garantinio palaikymo paslaugos

Išanalizuota

VŠĮ Karoliniškių poliklinika (PV)

Rinkos konsultacijaCPV: 72000000 - IT paslaugos: konsultavimas, programinės įrangos kūrimas, internetas ir aptarnavimo paslaugos
ID: 77627132026-05-07 14:59
Atidaryti CVP IS

Aprašymas

Perkamos naujos Karoliniškių poliklinikos interneto svetainės (karpol.lt) sukūrimo, diegimo ir palaikymo paslaugos. Svetainė turės reprezentacines, informacines ir pacientų savitarnos funkcijas, įskaitant mokamų paslaugų užsakymą ir apmokėjimą. Pirkimas taip pat apima duomenų perkėlimą, testavimą, darbuotojų apmokymą ir 12 mėnesių garantinį palaikymą.

Kvalifikaciniai reikalavimai

Kvalifikacinių reikalavimų nerasta

Techniniai reikalavimai

Integracijos

  • 1Privalomas registracijos mygtukas / nuoroda į išorinę registracijos sistemą.
  • 2Privalomos nuorodos į kitas pacientams aktualias išorines sistemas (pvz., E. paslaugų sprendimus), jei jas pateikia Užsakovas.
  • 3Turi būti numatyta galimybė be programuotojo įsikišimo įrašyti analitikos ar žymų valdymo identifikatorius (pvz., GA4 ar GTM), jei Užsakovas nuspręstų juos naudoti.
  • 4Privaloma integracija su Užsakovo pasirinktu mokėjimo paslaugų teikėju arba banklink sprendimu, skirta mokamų paslaugų krepšelio apmokėjimui, jei Užsakovas pateikia techninius integracijos duomenis, testavimo aplinką ir reikiamus identifikatorius.
  • 5Mokėjimo sprendimas turi užtikrinti saugų nukreipimą į mokėjimo aplinką, grįžimą į svetainę ir apmokėjimo būsenos perdavimą.
  • 6Apskaitos, fiskalizacijos, sąskaitų faktūrų, laboratorinių, registracijos ar kitų vidinių sistemų integracijos laikomos privalomomis (perkeliamas veikiantis sprendimas iš senos svetainės).
  • 7Tiekėjas privalo aiškiai nurodyti visus sprendimo komponentus, kuriems reikalingos trečiųjų šalių licencijos, prenumeratos ar papildomi mokesčiai; tokie komponentai negali būti naudojami be išankstinio Užsakovo sutikimo.
  • 8Jei integracija su išorinėmis sistemomis laikinai neveikia, turi būti numatytas alternatyvus sprendimas (pvz., nuoroda į išorinę sistemą), leidžiantis užtikrinti pagrindinių funkcijų pasiekiamumą.
  • 9Mokamų paslaugų funkcionalumui turi būti užtikrintas bent užsakymo numerio, krepšelio sumos, apmokėjimo būsenos ir mokėjimo patvirtinimo duomenų apsikeitimas tarp svetainės ir mokėjimo sprendimo.

Naujienų modulis

  • 1Turi būti naujienų sąrašas su data, pavadinimu, trumpa įžanga ir iliustracija, jei ji pateikiama.
  • 2Turi būti detalus naujienos puslapis su galimybe įterpti tekstą, nuotrauką, dokumentą ar nuorodą.
  • 3Turi būti galimybė pažymėti naujieną kaip rodomą tituliniame puslapyje arba išskirtinę.
  • 4Turi būti užtikrintas aiškus archyvavimas ir URL struktūra.

Paslaugų modulis

  • 1Paslaugos turi būti grupuojamos pagal logiškas kategorijas arba sritis.
  • 2Paslaugos puslapyje turi būti galimybė pateikti aprašymą, kam paslauga skirta, ar reikia siuntimo, kur ji teikiama, susijusius dokumentus ir susijusias nuorodas.
  • 3Privaloma numatyti ryšį tarp paslaugų ir padalinių; ryšys tarp paslaugų ir gydytojų gali būti įgyvendintas, jei Užsakovas pateiks struktūrizuotus duomenis.

Dokumentų modulis

  • 1Dokumentai turi būti skirstomi bent pagal kategorijas arba temas.
  • 2Turi būti galimybė įkelti PDF, DOCX ir kitus viešai skelbtinus failus, nurodant pavadinimą, datą ir trumpą aprašą.
  • 3Dokumentų sąraše turi būti matomas dokumento pavadinimas ir, jei taikoma, paskutinio atnaujinimo data.

Duomenų migracija

  • 1Tiekėjas turi perkelti turinį iš esamos svetainės ir kitų Užsakovo pateiktų šaltinių tokia apimtimi, kokia nurodyta Užsakovo patvirtintoje migracijos lentelėje.
  • 2Prieš migraciją turi būti suderintas turinio žemėlapis: kas perkeliama, kas archyvuojama, kas nebekeliama į naują svetainę.
  • 3Jei senieji URL keičiasi, turi būti sudarytas peradresavimų sąrašas ir įgyvendinti nukreipimai į naujus adresus.
  • 4Migracija nelaikoma vien automatinio importo veiksmu – tiekėjas turi užtikrinti ir korektišką atvaizdavimą naujoje struktūroje.
  • 5Jei iš esamos svetainės ar kito Užsakovo šaltinio perkeliami mokamų paslaugų klasifikatoriaus duomenys, turi būti užtikrintas jų korektiškas perkėlimas, kategorijų struktūros ir kainų atvaizdavimo vientisumas.
  • 6Jei pirkimo metu tikslūs turinio kiekiai nėra galutinai nustatyti, tiekėjas privalo į pasiūlymo kainą įtraukti visą esamos svetainės turinio perkėlimą, išskyrus aiškiai Užsakovo pažymėtą turinį, kuris nėra perkeliamas.

Priėmimo kriterijai

  • 1Rezultatas laikomas tinkamu priėmimui tik tada, kai veikia visi privalomi funkcionalumai ir nėra kritinių defektų.
  • 2Svetainė laikoma tinkamai įgyvendinta tik tuo atveju, jei Užsakovas gali savarankiškai valdyti pagrindinį turinį ir naudotis sistema be tiekėjo įsikišimo kasdienėse operacijose.
  • 3Priėmimo metu neturi būti likusių aukšto kritiškumo saugumo pažeidžiamumų.
  • 4Prieinamumo atitiktis vertinama pagal privalomus WCAG 2.1 AA kriterijus; leistinos tik aiškiai dokumentuotos ir teisės aktais pagrįstos išimtys.
  • 5Tiekėjas privalo ištaisyti priėmimo metu nustatytus neatitikimus, jei jie susiję su šioje specifikacijoje nustatytais privalomais reikalavimais.
  • 6Įgyvendinus mokamų paslaugų funkcionalumą, priėmimo metu turi veikti paslaugų pasirinkimo, krepšelio, apmokėjimo inicijavimo, grįžimo į svetainę ir apmokėjimo būsenos atvaizdavimo scenarijai.
  • 7Svetainės našumas vertinamas kaip priėmimo dalis; jei pagrindinių puslapių veikimo sparta neatitinka 4.4 skyriuje nustatytų kriterijų, rezultatas nelaikomas tinkamu priėmimui.

Saugumo reikalavimai

  • 1Visas viešasis ir administracinis srautas turi būti pasiekiamas tik per HTTPS.
  • 2Sprendimas turi būti apsaugotas nuo dažniausių interneto programų pažeidžiamumų, įskaitant OWASP Top 10 kategorijas.
  • 3Visų formų ir duomenų įvedimo laukų validacija turi būti atliekama tiek naudotojo sąsajoje, tiek serverio pusėje.
  • 4Administracinė dalis turi būti apsaugota nuo bruteforce atakų, įskaitant prisijungimo bandymų ribojimą ir laikiną blokavimą po nustatyto nesėkmingų bandymų skaičiaus.
  • 5Turi būti naudojami saugumo antraščių (header) nustatymai, tokie kaip Content-Security-Policy, X-Frame-Options ar lygiaverčiai, X-Content-Type-Options, Referrer-Policy ir kt., jei jie suderinami su pasirinkta architektūra.
  • 6Administravimo paskyrų slaptažodžiai turi būti saugomi tik maišos (hash) pavidalu, naudojant modernų algoritmą.
  • 7Administravimo sesijos turi baigtis po nustatyto neveiklumo laikotarpio.
  • 8Slapukai, naudojami autentifikavimui, turi būti konfigūruojami kaip Secure, HttpOnly ir su tinkamu SameSite parametru.
  • 9Administratoriams turi būti numatyta galimybė įjungti dviejų veiksnių autentifikavimą, jei to nereikalauja papildomos nenumatytos licencijos.
  • 10Mokamų paslaugų apmokėjimas turi būti organizuojamas per Užsakovo pasirinktą licencijuotą mokėjimo paslaugų teikėją, banklink arba lygiavertį sprendimą (perkeliamas veikiantis sprendimas iš senosios svetainės).
  • 11Svetainėje negali būti saugomi mokėjimo kortelių duomenys; jei naudojami kortelių mokėjimai, jie turi būti tvarkomi tik mokėjimo paslaugų teikėjo saugioje aplinkoje.
  • 12Turi būti užtikrintas saugus užsakymo identifikatoriaus, mokėtinos sumos ir apmokėjimo būsenos perdavimas tarp svetainės ir mokėjimo sprendimo, perduodant tik minimaliai būtinus duomenis.
  • 13Apmokėjimo grįžimo scenarijuose naudotojui turi būti aiškiai pateikiama bent sėkmingo, nesėkmingo ir nebaigto mokėjimo būsena bei tolimesni veiksmai.

Garantinis palaikymas

  • 1Garantinis palaikymas turi būti teikiamas ne trumpiau kaip 12 mėnesių nuo galutinio priėmimo–perdavimo akto pasirašymo dienos.
  • 2Garantiniu laikotarpiu tiekėjas be papildomo mokesčio šalina savo sukurto programinio kodo ar konfigūravimo defektus.
  • 3Kritinių gedimų reakcijos laikas – tą pačią darbo dieną; aukšto prioriteto gedimų – ne vėliau kaip per 1 darbo dieną; vidutinio prioriteto – ne vėliau kaip per 3 darbo dienas, jei sutartyje nenustatyta kitaip.
  • 4Kritiniai gedimai turi būti šalinami nedelsiant ir, kiek tai techniškai įmanoma, pašalinami ne vėliau kaip per 1 darbo dieną nuo jų registravimo momento.
  • 5Jei po paleidimo paaiškėja neatitiktis teisės aktų reikalavimams ar privalomiems standartams, kurie turėjo būti įgyvendinti baziniame sprendime, tiekėjas privalo ją pašalinti garantinio palaikymo ribose.
  • 6Garantinis palaikymas apima ne tik kritinių defektų, bet ir funkcinių neatitikimų šalinimą, jei jie trukdo naudotojams naudotis svetaine pagal numatytą paskirtį.

Testavimo reikalavimai

  • 1funkcinis testavimas;
  • 2naudojamumo ir responsyvumo testavimas;
  • 3naršyklių ir įrenginių suderinamumo testavimas;
  • 4prieinamumo testavimas (automatizuotas ir rankinis);
  • 5formų, teisių ir auditavimo veikimo patikra;
  • 6diegimo ir atkūrimo procedūros patikra.
  • 7mokamų paslaugų klasifikatoriaus, krepšelio ir apmokėjimo scenarijų patikra.

Paieškos funkcionalumas

  • 1Paieškos laukelis turi būti prieinamas iš pagrindinių svetainės puslapių.
  • 2Paieška privalomai turi apimti bent puslapius, naujienas, dokumentus, paslaugas, gydytojus ir DUK.
  • 3Paieška turi korektiškai apdoroti lietuviškus simbolius ir pateikti aiškius rezultatus su nuoroda į konkretų turinį.

Mokamų paslaugų modulis

  • 1Turi būti įgyvendintas atskiras viešas mokamų paslaugų modulis, leidžiantis pacientui peržiūrėti mokamų paslaugų klasifikatorių / kainyną, ieškoti ir filtruoti paslaugas bent pagal kategoriją, padalinį ir raktažodį.
  • 2Kiekvienai mokamai paslaugai turi būti galima pateikti bent pavadinimą, kodą ar kitą identifikatorių (jei taikoma), kainą, trumpą aprašą, teikimo vietą ir papildomas pastabas, jei jos būtinos naudotojui.
  • 3Naudotojas turi turėti galimybę įtraukti pasirinktą mokamą paslaugą į krepšelį, peržiūrėti krepšelio turinį, pašalinti pasirinktas paslaugas ir matyti bendrą mokėtiną sumą prieš apmokėjimą.
  • 4Turi būti įgyvendintas užsakymo apmokėjimas per banklink arba lygiavertį mokėjimo paslaugų teikėjo sprendimą, užtikrinant nukreipimą į saugią mokėjimo aplinką ir grįžimą į svetainę su apmokėjimo būsenos rezultatu.
  • 5Turi būti generuojamas minimalus užsakymo patvirtinimo įrašas ir (arba) pranešimas el. paštu pacientui bei atsakingam Užsakovo darbuotojui.
  • 6Jei apmokėjimo būsena negaunama arba mokėjimas neįvyksta, naudotojui turi būti pateikiamas aiškus pranešimas ir tolimesni veiksmai (pakartoti bandymą, kreiptis nurodytais kontaktais ir pan.).
  • 7Atliekama vidinė apskaitos, fiskalizacijos, sąskaitų faktūrų ir kitų vidinių sistemų integracija šiame modulyje laikoma privaloma (perkeliamas veikiantis sprendimas iš senos svetainės).

Daugiakalbystės palaikymas

  • 1Privalomai turi būti įgyvendintas lietuvių ir anglų kalbų palaikymas.
  • 2Kiekvienos kalbos turinys turi būti valdomas atskirai per TVS ir susiejamas su atitinkamu puslapiu ar įrašu.
  • 3Mašininis automatinis vertimas nelaikomas daugiakalbystės įgyvendinimu.
  • 4Turi būti numatyta galimybė ateityje pridėti papildomų kalbų be esminio sistemos perprojektavimo.

Kontaktų ir karjeros formos

  • 1Turi būti universalus formų mechanizmas, leidžiantis sukurti bent kontaktų ir karjeros formas.
  • 2Formose turi būti palaikomi privalomi ir neprivalomi laukai, el. pašto formato tikrinimas, sutikimo ar informavimo elementai ir antispam priemonė.
  • 3Karjeros formoje turi būti leidžiama prisegti CV failą nustatytų formatų ribose.
  • 4Skirtingoms formoms turi būti galima priskirti skirtingus gavėjus.
  • 5Jei Užsakovas pageidauja, TVS gali būti saugomas minimalus užklausų žurnalas; pilnas CRM funkcionalumas nereikalaujamas.

Svetainės bendroji struktūra

  • 1Viešojoje svetainėje privalomai turi būti įgyvendinta aiški, nuosekli, redaguojama informacinė struktūra.
  • 2Puslapių tvarka, meniu lygiai ir nuorodų pavadinimai turi būti valdomi per TVS.
  • 3Viršuje turi būti aiškiai matomas įstaigos logotipas ir pagrindinė navigacija.
  • 4Turi būti aiškus ir vizualiai išskirtas veiksmo mygtukas, vedantis į registracijos sistemą.
  • 5Turi būti vieta skubiai informacijai arba svarbiam pranešimui, kurį galima valdyti per TVS.
  • 6Turi būti 3–6 greitosios nuorodos į dažniausiai naudojamas sritis (pvz., registracija, padaliniai, gydytojai, DUK, dokumentai, mokamos paslaugos).
  • 7Turi būti pateikiama trumpa „Apie mus“ arba lygiavertė įžanginė dalis ir naujausių naujienų ištrauka.
  • 8Apatinėje dalyje (footer) turi būti institucijos rekvizitai, pagrindiniai kontaktai ir svarbios nuorodos (pvz., privatumo / slapukų informacija, karjera ir pan.).

Prieinamumo reikalavimai (WCAG)

  • 1Viešoji svetainė turi atitikti WCAG 2.1 AA lygį.
  • 2Turi būti užtikrintas pilnas valdymas klaviatūra, aiškus fokusavimo indikatorius ir logiška fokusavimo seka.
  • 3Visi informatyvūs paveikslėliai ir grafiniai elementai turi turėti alternatyvų tekstą, o dekoratyvūs – būti tinkamai pažymėti.
  • 4Formos turi turėti aiškias laukų etiketes, klaidų pranešimus, suprantamą validacijos logiką ir būti naudojamos su pagalbinėmis technologijomis.
  • 5Turi būti užtikrintas pakankamas teksto ir fono kontrastas, semantinė HTML struktūra ir korektiški kalbos atributai.
  • 6Turi būti įgyvendinta „Skip to main content“ nuoroda arba lygiavertis sprendimas, leidžiantis apeiti pasikartojančius navigacijos elementus.
  • 7Prieinamumo pareiškimo paskelbimas turi būti numatytas kaip svetainės rezultato dalis.

Diegimo ir aplinkos reikalavimai

  • 1Tiekėjas turi dirbti bent su dviem aplinkomis: testavimo (staging) ir produkcine.
  • 2Į produkcinę aplinką gali būti diegiama tik po testavimo ir Užsakovo suderinimo.
  • 3Staging aplinkoje negali būti naudojami nereikalingi realūs asmens duomenys; testavimo duomenys turi būti anonimizuoti arba sintetiniai.
  • 4Viešoji svetainė turi korektiškai veikti aktualiose ir gamintojo palaikomose stacionarių ir mobiliųjų naršyklių versijose projekto perdavimo dieną.
  • 5Svetainė turi būti pilnai pritaikyta kompiuteriams, planšetėms ir mobiliesiems įrenginiams.

Našumo ir kokybės reikalavimai

  • 1Turi būti įgyvendintas vaizdų optimizavimas, CSS ir JavaScript failų sujungimo arba minimizavimo priemonės, talpyklavimo ir kiti standartiniai našumo gerinimo sprendimai.
  • 2Viešoji svetainė neturi būti perkrauta sunkiais vizualiniais efektais, kurie blogina naudojamumą, prieinamumą ar veikimo spartą.
  • 3Kuriant dizainą turi būti laikomasi principo „pirmiausia turinio aiškumas“, o animacijos gali būti naudojamos tik subtiliai ir neprivalomai.
  • 4Viešosios svetainės puslapiai turi būti įkeliami pakankamai greitai, kad užtikrintų sklandžią naudotojo patirtį; orientacinis tikslas – pagrindinio puslapio įkėlimo laikas neturi viršyti 3 sekundžių esant įprastam vartotojo interneto ryšiui.
  • 5Svetainės našumas turi būti vertinamas naudojant standartinius įrankius (pvz., Lighthouse ar lygiaverčius), siekiant ne mažesnio kaip 85 balų įvertinimo našumo kategorijoje pagrindiniams puslapiams.
  • 6Tiekėjas turi užtikrinti, kad sprendimas būtų optimizuotas mobiliesiems įrenginiams ne tik dizaino, bet ir veikimo spartos prasme.
  • 7Sprendime turi būti naudojami šiuolaikiniai našumo gerinimo metodai, tokie kaip vaizdų „lazy loading“, talpyklavimas (caching), turinio pristatymo optimizavimas ir serverio atsako laiko mažinimas, kiek tai suderinama su Užsakovo infrastruktūra.
  • 8Svetainės našumas yra laikomas vienu iš priėmimo kriterijų. Jei testavimo metu nustatoma, kad pagrindiniai puslapiai neatitinka šiame skyriuje nurodytų našumo reikalavimų (įkėlimo laikas, Lighthouse ar lygiaverčio įrankio įvertinimas), tiekėjas privalo savo sąskaita atlikti optimizavimo darbus iki reikalavimų atitikimo.

Gydytojų ir specialistų modulis

  • 1Gydytojų sąrašas turi būti filtruojamas bent pagal padalinį, specialybę ir tekstinę paiešką pagal vardą ar pavardę.
  • 2Kiekvienoje gydytojo kortelėje turi būti bent vardas, pavardė, specialybė, padalinys ir nuoroda registracijai.
  • 3Jei Užsakovas teiks tokius duomenis, turi būti galimybė rodyti kabinetą, darbo laiką, kalbas ir trumpą specializacijos aprašą.
  • 4Gydytojo puslapio struktūra turi būti vienoda ir valdoma per TVS.

Perduodami rezultatai ir dokumentacija

  • 1pilnai veikianti viešoji svetainė ir administravimo aplinka;
  • 2programinio kodo ir konfigūracijų perdavimas Užsakovui;
  • 3diegimo, atnaujinimo ir atkūrimo instrukcijos;
  • 4naudotojo (redaktoriaus / administratoriaus) vadovas PDF arba DOCX formatu;
  • 5testavimo rezultatų suvestinė ir defektų ištaisymo ataskaita;
  • 6mokamų paslaugų modulio ir apmokėjimo proceso aprašas, įskaitant administravimo tvarką ir klaidų scenarijus;
  • 7prieinamumo atitikties suvestinė ir prieinamumo pareiškimo turinio pagrindas;
  • 8duomenų migracijos / turinio perkėlimo ataskaita;
  • 9mokymų medžiaga ir bent vienas mokymų seansas Užsakovo paskirtiems darbuotojams;
  • 10Sprendimas turi būti perduodamas taip, kad jį galėtų perimti ir prižiūrėti kitas tiekėjas be esminių techninių apribojimų; negali būti naudojami sprendimai, kurie sukuria nepagrįstą priklausomybę nuo konkretaus tiekėjo.
  • 11Jei tiekėjas naudoja atvirojo kodo ar trečiųjų šalių komponentus, turi būti pateiktas jų sąrašas su trumpu paskirties paaiškinimu ir licencijavimo informacija.

Architektūros ir technologijų principai

  • 1Sprendimas turi būti sukurtas naudojant modernias, gamintojo palaikomas ir saugias technologijas.
  • 2Tiekėjas turi užtikrinti, kad pagrindinės svetainės funkcijos nebūtų kritiškai priklausomos nuo vienos mokamos temos, neprižiūrimų trečiųjų šalių įskiepių grandinės ar tiekėjo neperduodamų komponentų.
  • 3Užsakovui turi būti perduodama visa eksploatacijai būtina programinio kodo, konfigūracijų ir diegimo instrukcijų apimtis.
  • 4Sprendimas turi būti modulinis, dokumentuotas ir tinkamas priežiūrai bei vėlesnei plėtrai.
  • 5Sprendimas turi būti tinkamas diegti Užsakovo infrastruktūroje, nenaudojant tiekėjo valdomo hostingo kaip būtinos priklausomybės.
  • 6Sprendimas negali būti kuriamas naudojant šablonines turinio valdymo sistemas, kurių veikimas grindžiamas temų ir trečiųjų šalių įskiepių (pluginų) ekosistema (pvz., WordPress, Joomla, Drupal ar analogiški sprendimai), kai pagrindinis funkcionalumas priklauso nuo išorinių, Užsakovo nekontroliuojamų komponentų.
  • 7Tiekėjo siūlomas sprendimas turi būti grindžiamas stabilia, palaikoma ir dokumentuota architektūra, užtikrinančia ilgalaikį saugumą, veikimo patikimumą ir galimybę Užsakovui savarankiškai valdyti bei plėtoti sistemą be priklausomybės nuo trečiųjų šalių įskiepių grandinės.

Duomenų apsaugos ir tvarkymo reikalavimai

  • 1TVS turi registruoti prisijungimus, atsijungimus, turinio sukūrimą, redagavimą, ištrynimą, failų įkėlimą ir svarbių nustatymų pakeitimus.
  • 2Auditavimo įrašai turi būti prieinami tik autorizuotiems naudotojams ir negali būti trinami įprastų redaktorių teisėmis.
  • 3Tiekėjas turi pateikti rekomenduojamą atsarginių kopijų darymo ir atkūrimo tvarką Užsakovo infrastruktūrai.
  • 4Jei atsarginės kopijos automatizuojamos pačiame sprendime, turi būti aprašytas jų veikimo principas, saugojimo vietos ir atkūrimo procedūra.
  • 5Formose turi būti renkami tik tie duomenys, kurie būtini konkrečiam tikslui pasiekti.
  • 6Visose asmens duomenis renkančiose formose turi būti pateikiama nuoroda į aktualią asmens duomenų tvarkymo informaciją ir privalomas sutikimo ar informavimo elementas, kai tai būtina.
  • 7Užklausų duomenys turi būti perduodami ir saugomi taip, kad nebūtų nepagrįstai kaupiami pertekliniai asmens duomenys.
  • 8Jei TVS saugomos užklausos, turi būti numatytas jų saugojimo terminas, peržiūros teisės ir ištrynimo / archyvavimo tvarka.
  • 9Antispam apsaugai turi būti naudojamas captcha arba lygiavertis sprendimas, atitinkantis prieinamumo ir duomenų apsaugos principus.

Bendrieji reikalavimai ir teisinė atitiktis

  • 1Tiekėjo siūlomas sprendimas ir jo įgyvendinimas turi atitikti viešojo pirkimo paskelbimo dieną galiojančius teisės aktus ir standartus, kiek jie taikomi viešojo sektoriaus interneto svetainėms ir jų administravimui.
  • 2Europos Parlamento ir Tarybos reglamentą (ES) 2016/679 (Bendrasis duomenų apsaugos reglamentas, BDAR) ir kitus taikytinus asmens duomenų apsaugos reikalavimus.
  • 3Galiojančią Lietuvos Respublikos Vyriausybės nutarimo Nr. 480 redakciją dėl Bendrųjų reikalavimų valstybės ir savivaldybių institucijų ir įstaigų interneto svetainėms ir mobiliosioms programoms aprašo patvirtinimo.
  • 4Europos Parlamento ir Tarybos direktyvą (ES) 2016/2102 dėl viešojo sektoriaus subjektų interneto svetainių ir mobiliųjų programų prieinamumo, taip pat jai taikomus standartus.
  • 5WCAG 2.1 AA lygio reikalavimus ir, jei taikoma, EN 301 549 standartą tiek, kiek jis susijęs su interneto svetainėmis.
  • 6Taikytinus kibernetinio saugumo, informacijos saugos ir viešojo sektoriaus informacinių išteklių valdymo reikalavimus, susijusius su svetainės diegimu Užsakovo infrastruktūroje.
  • 7Tiekėjo pasiūlymas turi apimti visus darbus, kurie būtini tam, kad būtų sukurta, ištestuota, paleista ir Užsakovui perduota pilnai veikianti interneto svetainė su turinio valdymo sistema.
  • 8Jei tiekėjas siūlo techninį sprendimą, kuris pagal pavadinimą, platformą ar architektūrą skiriasi nuo šiame dokumente minimų pavyzdžių, tačiau atitinka visus funkcinio rezultato, saugumo, prieinamumo, palaikomumo ir perduodamumo reikalavimus, toks sprendimas laikomas priimtinu.

Turinio valdymo sistema (TVS) ir administravimas

  • 1TVS turi leisti kurti, redaguoti, publikuoti ir archyvuoti viešosios svetainės turinį be programuotojo įsikišimo.
  • 2TVS turi palaikyti atskirų puslapių, naujienų, dokumentų, gydytojų, padalinių, paslaugų, mokamų paslaugų įrašų ir formų duomenų valdymą.
  • 3TVS turi palaikyti failų, nuotraukų ir dokumentų biblioteką, leidžiančią priskirti pavadinimus, aprašus ir alternatyvų tekstą.
  • 4TVS turi turėti naudotojų ir rolių valdymo modulį, auditavimo galimybes ir juodraščio / publikavimo būsenas.
  • 5Administratorius: Pilna prieiga prie modulių, struktūros, naudotojų, nustatymų, auditų ir publikavimo.
  • 6Turinio redaktorius: Gali kurti, redaguoti ir publikuoti jam leistiną turinį, bet negali keisti sistemos konfigūracijos.
  • 7Ribotas redaktorius: Gali redaguoti tik priskirtus skyrius ar turinio tipus; negali keisti struktūros ar valdyti kitų naudotojų turinio.
  • 8Skaitymo režimas: Gali peržiūrėti administracinę aplinką ar tam tikras ataskaitas, bet negali atlikti pakeitimų.
  • 9WYSIWYG redaktorius, palaikantis antraštes, sąrašus, lenteles, nuorodas, paveikslėlius ir dokumentų įterpimą.
  • 10Meniu struktūros valdymas, galimybė keisti eiliškumą ir įjungti / išjungti meniu punktus.
  • 11Juodraščio, paskelbto ir archyvuoto turinio būsenos.
  • 12Peržiūros funkcija prieš publikavimą, jei ji techniškai suderinama su pasirinktu sprendimu.
  • 13SEO laukai bent meta pavadinimui, meta aprašymui ir redaguojamam URL.
  • 14Media biblioteka su failų pavadinimų, aprašų ir alternatyvių tekstų valdymu.
  • 15Mokamų paslaugų klasifikatoriaus / kainyno įrašų valdymas per TVS arba importas iš struktūrizuoto duomenų šaltinio (pvz., CSV ar XLSX), jei toks mechanizmas numatomas sprendime.
  • 16301 peradresavimų sąrašo valdymas arba kita tvarkinga priemonė išlaikyti senųjų nuorodų nukreipimus po migracijos.
  • 17Auditavimo žurnalas ir naudotojų veiksmų atsekamumas.
  • 18Administravimo sąsaja turi būti aiški, nuosekli ir nereikalauti techninių žinių atliekant kasdienes turinio operacijas.
  • 19Alternatyvaus teksto neįvedus prie informatyvaus paveikslėlio, TVS turi bent perspėti redaktorių apie trūkstamą informaciją.
  • 20Daugiausia naudojami duomenų tipai turi būti valdomi per aiškias formas, o ne reikalauti HTML kodo redagavimo.
  • 21TVS turi būti pritaikyta ne techniniams naudotojams, o kasdienį turinį administruojantiems darbuotojams; sudėtingi ar programuotojo žinių reikalaujantys turinio valdymo scenarijai nelaikomi tinkamu sprendimu.

Dokumentai3

  • RK kvietimas Karpol lt.docx
  • 1772_7762713.pdf
  • karpol_lt_technine_specifikacija_galutine_v4.docx
tendis.lt · Sukurta recodin.lt