Grįžti į sąrašą

Geros gamybos praktikos reikalavimus atitinkanti elektroninė kokybės valdymo sistema (11789)

Išanalizuota

VšĮ Vilniaus universiteto ligoninė Santaros klinikos (PV)

196 000 €
Atviras konkursasCPV: 72260000 - Su programine įranga susijusios paslaugos
ID: 78799062026-05-18 05:31Pasiūlymai iki: 2026-06-22 09:00
Atidaryti CVP IS

Aprašymas

Perkančioji organizacija siekia įsigyti elektroninę kokybės valdymo sistemą (eQMS), atitinkančią geros gamybos praktikos (GMP) reikalavimus. Ši sistema bus naudojama pažangios terapijos vaistinių preparatų ir ląstelių/genų terapijos produktų gamyboje. Pirkimas apima sistemos konfigūravimo, validavimo ir palaikymo paslaugas.

Kvalifikaciniai reikalavimai

  • 1Tiekėjas per pastaruosius 5 (penkerius) metus turi būti įdiegęs ir pradėjęs eksploatuoti siūlomą kokybės valdymo sistemą ne mažiau kaip 2 (dviejose) organizacijose, vykdančiose pažangios terapijos vaistinių preparatų ir (ar) ląstelių/genų terapijos preparatų gamybą pagal geros gamybos praktikos reikalavimus. Sistema turi būti faktiškai naudojama ne trumpiau kaip 12 mėnesių be nustatytų kritinių sutrikimų, kas galėtų sukelti žymių trikdžių numatytoje gamybos veikloje.
  • 2Tiekėjas neturi interesų, galinčių kelti grėsmę nacionaliniam saugumui – vadovaujantis VPĮ 47 straipsnio 9 dalimi, jis pats, jo subtiekėjai ar ūkio subjektai, kurių pajėgumais remiamasi ar juos kontroliuojantys asmenys nėra registruoti (jeigu tiekėjas, jo subtiekėjas, ūkio subjektas, kurio pajėgumais remiamasi, ar kontroliuojantis asmuo yra fizinis asmuo – nuolat gyvenantis ar turintis pilietybę) VPĮ 92 straipsnio 14 dalyje numatytame sąraše nurodytose valstybėse ar teritorijose.
  • 3Tiekėjo siūlomos teikti paslaugos nekelia grėsmės nacionaliniam saugumui – vadovaujantis VPĮ 37 straipsnio 9 dalies 2 punktu, paslaugų teikimas nebus vykdomas iš VPĮ 92 straipsnio 14 dalyje numatytame sąraše nurodytų valstybių ar teritorijų.
  • 4Tiekėjui/subtiekėjui, kurie yra pasitelkti ar bus pasitelkti ateityje, ūkio subjektams, kurių pajėgumais remiamasi ar (ir) bus remiamasi, prekių (ir jų sudedamųjų dalių) gamintojams netaikomos Lietuvos Respublikoje įgyvendinamos tarptautinės sankcijos, kaip tai apibrėžta Lietuvos Respublikos tarptautinių sankcijų įstatyme.

Techniniai reikalavimai

Apmokymai

  • 1Apmokymų platforma turi užtikrinti interaktyvų turinį (vaizdo įrašus, testus ir simuliacijas), turėti intuityvią ir vartotojui patogią naudoti sąsają, suteikti galimybę stebėti vartotojų mokymosi progresą realiuoju laiku, bei leisti individualiai pritaikyti mokymų planus pagal vartotojus ir jų pareigas.

Auditų valdymas

  • 1Sistema turi užtikrinti, kad vartotojai galėtų kurti ir planuoti auditus, nurodant audito tipą (vidinis, išorės, tiekėjo), subkategoriją, audito apimtį, audituojamą padalinį ar organizaciją, vyriausiąjį auditorių ir audituojamą subjektą. Pradžios ir pabaigos datos turi būti pasirenkamos per interaktyvų kalendorių, su galimybe koreguoti tvarkaraštį po sukūrimo, išlaikant įvykių seką.
  • 2Sistema turi leisti naudotojams pradėti auditą įvedant faktines atlikimo datas ir, jei reikia, naudoti versijomis valdomus audito kontrolinių sąrašų šablonus, sudarytus iš anksto apibrėžtų klausimų ar patikros punktų.
  • 3Sistema turi suteikti vartotojui galimybę kurti, redaguoti ir pašalinti audito išvadas. Kiekvienai išvadai turi būti nurodomas tipas (pvz., nereikšminga, reikšminga, kritinė, pastaba), atsako terminas, aprašymas, atsakingas asmuo ir, jei reikalinga, pridedami priedai. Išvados turi būti atsekamos audito įraše.
  • 4Sistema privalo užtikrinti galimybę tiesiogiai susieti CAPA įrašus su konkrečiomis audito išvadomis. Sistemos funkcionalumas turi užtikrinti, kad atsakymai į išvadas yra teikiami su priedais, o jų vykdymo būsena yra stebima iki užbaigimo.
  • 5Sistema turi palaikyti pareigomis (ir pareigoms priskirtomis vartotojo teisėmis) pagrįstas peržiūros ir patvirtinimo užduotis, su pasirinktiniais terminais ir saugiu elektroniniu pasirašymu. Peržiūros vaidmenys gali būti konfigūruojami pagal įvykio tipą arba organizacijos struktūrą.
  • 6Sistema turi užtikrinti, kad tik naudotojai su tam suteiktomis teisėmis gali peržiūrėti visus audito įrašus, o kiti naudotojai – tik tuos, kurie susiję su jų padaliniu ar vaidmeniu.
  • 7Sistema turi automatiškai siųsti pranešimus apie suplanuotus auditus, išvadų pateikimo terminus, peržiūros užklausas ir pavėluotus veiksmus. Pranešimų dažnis, besikeičiantis prioritetas ir informacijos gavėjų sąrašas turi būti konfigūruojami.
  • 8Sistema turi registruoti visus audito įvykdymo veiksmus įvykių sekos funkcijoje, įskaitant audito sukūrimą, koregavimus, išvadų keitimus, priedų įkėlimą ir peržiūras. Audito duomenys, išvados, CAPA įrašų nuorodos ir būsenos turi būti eksportuojamos į PDF ir CSV formatus. Sistema turi leisti sugeneruoti audito suvestines, įskaitant audito išvadas ir bendrą santrauką.
  • 9Sistema turi generuoti suvestinę arba lentelės peržiūrą, kurioje pateikiami planuojami, vykdomi ir pavėluoti auditai bei jų išvados. Ši funkcija turi turėti filtravimo ir rūšiavimo galimybes.

Mokymų valdymas

  • 1Sistema turi leisti administratoriaus teises turintiems naudotojams kurti, priskirti, redaguoti, peržiūrėti ir išregistruoti mokymo įrašus ir mokymo programas. Mokymų turinį sistemoje turi sudaryti dokumentai, užduotys, testai/vertinimai ir išorinės nuorodos. Visa mokymo medžiaga turi būti saugiai saugoma ir išlaikoma audito bei atitikties tikslams.
  • 2Mokymų priskyrimas sistemoje turi būti konfigūruojamas pagal vartotojo rolę, padalinį, dokumento patvirtinimą ar reviziją arba kitus administratoriaus nustatytus kriterijus. Sistema turi palaikyti mokymo grupių kūrimą ir valdymą, priskyrimų tikslumo patvirtinimą, taip pat automatinį mokymų priskyrimų inicijavimą, kai to reikia.
  • 3Prieiga prie mokymo medžiagos ir veiksmų turi būti valdoma pagal rolėmis pagrįstas teises. Mokymo užbaigimas sistemoje turi reikalauti elektroninio vartotojo patvirtinimo, o prireikus — papildomo patvirtinimo paskirtos rolės (pvz., vadovo ar QA atstovo) prieš galutinį užbaigimo fiksavimą.
  • 4Sistema turi sudaryti galimybę kurti ir administruoti testus/vertinimus, taip pat fiksuoti ir saugoti jų rezultatus. Remiantis nustatytais mokymų ir kompetencijos kriterijais, sistema turi automatiškai generuoti ir išduoti sertifikatus.
  • 5Sistema turi generuoti konfigūruojamus pranešimus ir priminimus apie naujus mokymų priskyrimus, artėjančius terminus, pavėluotus mokymus, naujai priskirtas užduotis ir galutinio užbaigimo patvirtinimus.
  • 6Sistema turi leisti naudotojams įkelti (ir saugoti) mokymų užbaigimo įrodymus (pvz., sertifikatus), ir užtikrinti pilną atsekamumą naudojant įvykių sekos funkciją kurioje, registruojami visi veiksmai, įskaitant mokymų priskyrimus, būsenų pokyčius, užbaigimus, vertinimą, elektroninius parašus ir visas naudotojų sąveikas, nurodant datą/laiką ir naudotojo tapatybę.
  • 7Sistema turi užtikrinti mokymų statuso ir atitikties ataskaitų generavimą, su galimybe eksportuoti mokymų užbaigimo ataskaitas PDF formatu, peržiūrėti atitikties suvestines bei mokymų matricą, vizualiai pateikiančią mokymų reikalavimus ir jų įvykdymo būseną pagal darbuotoją, rolę ar padalinį.
  • 8Sistema užtikrina, kad mokymų valdymas yra integruojamas su dokumentų valdymu, kad dokumentų patvirtinimai ar revizijos automatiškai inicijuotų susijusius mokymų priskyrimus, užtikrinant pilną atsekamumą tarp mokymų įrašų ir kontroliuojamų dokumentų.

Įrangos valdymas

  • 1Sistema gali generuoti unikalias brūkšninių kodų etiketes, skirtas įrangos identifikavimui ir atsekamumui užtikrinti.
  • 2Sistema gali nuskaityti brūkšninius kodus procedūrų metu, kad būtų sekamas įrangos naudojimas.
  • 3Sistema seka įrangos naudojimą registruojant atliktas veiklas, laiko žymas, atsakingus operatorius ir nuorodas į susijusius gamybos ar bandymų įrašus.
  • 4Įrangai gali būti priskiriami būsenos žymenys, tokie kaip „Išleista“, „Karantinuota“ ir „Nurašyta“, o jų keitimą nustato pagal rolėmis suteiktos prieigos teisės.
  • 5Pranešimų nustatymai apima (bet neapsiriboja) automatinius įspėjimus apie artėjančius kalibravimus, pavėluotą priežiūrą ir įrangos būsenos pasikeitimus. Pranešimų dažnis, ribinės vertės ir gavėjai yra konfigūruojami.
  • 6Sistemos vartotojai gali kurti, keisti, peržiūrėti ir deaktyvuoti įrangos įrašus, kuriuose pateikiami unikalūs identifikatoriai ir susiję metaduomenys.
  • 7Sistema leidžia kurti pasirinktinius kontrolinius sąrašus, naudojamus įrangai iš karantininės būsenos patvirtinti ir išleisti.
  • 8Sistema turi funkciją palaikyti ir valdyti kiekvienos įrangos valymo įrašus.
  • 9Visi su įranga susiję veiksmai, įskaitant informaciją apie naudotoją, datą, laiką ir veiksmų pobūdį, turi būti rodomi sistemos įvykių sekoje. Įvykių sekos duomenis galima eksportuoti reguliaciniams patikrinimams ir vidinėms auditų veikloms.
  • 10Sistema generuoja PDF ataskaitas, kuriose pateikiama visa informacija apie įrangą ir jos aptarnavimą.
  • 11Įrangos sąrašuose ir profilių puslapiuose rodomi artėjančių aptarnavimų rodikliai, automatiniai įspėjimai siunčiami pagal kalibravimo ar priežiūros terminus, o būsimi aptarnavimai gali būti suplanuojami sistemoje.
  • 12Sistema leidžia naudotojams įkelti ir susieti įrangos sertifikatus, aptarnavimo ataskaitas ir instrukcijas.
  • 13Gali būti apibrėžti standartiniai paslaugų tipai (pvz., kalibravimas, planinė priežiūra, remontas), o paslaugų įrašai gali būti papildomi pasirenkamais laukais, tokiais kaip paslaugos teikėjas, sąnaudų centras ar panaudotos dalys.
  • 14Perkančioji organizacija gali apibrėžti pasirinktines priežastis, dėl kurių įranga priskiriama karantino būsenai, pavyzdžiui, „Nenaudojama“ arba „Nauja įranga“.
  • 15Naudotojai gali pridėti pasirinktinius metaduomenų laukus prie įrangos įrašų (pvz., turto žymė, vietos kodas), o įstaiga gali nustatyti, kurie laukai yra privalomi ir kokie duomenų tipai yra leidžiami.

Pokyčių valdymas

  • 1Sistema užtikrina, kad vartotojų galimybę inicijuoti ir saugoti keitimų kontrolės įrašus su nurodyta priežastimi bei aprašymu.
  • 2Sistema turi užtikrinti, kad kiekvienam pakeitimui būtų automatiškai suteikiamas unikalus identifikavimo numeris ir priskiriamas poveikio lygis.
  • 3Sistema užtikrina, kad pakeitimų valdymo eiga sistemoje apima inicijavimą, QA peržiūrą, keitimo komiteto sprendimą, įgyvendinimą ir uždarymą. Visi sprendimai, veiksmai bei komentarai fiksuojami su laiko žymomis.
  • 4Sistema turi užtikrinti, kad veiksmai galėtų būti planuojami ir įgyvendinami, priskiriant atsakingus asmenis, nustatant įvykdymo terminus ir išlaikant tinkamą dokumentaciją.
  • 5Sistema turi užtikrinti pilną veiksmų užbaigimą, jų dokumentavimą bei susijusių įrašų ir būsenų kontrolę.
  • 6Sistema užtikrina, kad visi pokyčių (keitimų) įgyvendinimo veiksmai būtų užbaigti prieš galutinį QA patvirtinimą.
  • 7Sistema turi leisti naudotojams įkelti papildomus (pagrindžiančius) dokumentus, o galutinį dokumento uždarymą, įskaitant sprendimo priėmimą ir laiko žymą, turi atlikti QA.
  • 8Sistemos funkcionalumas užtikrina, kad vartotojai gali sugeneruoti ataskaitą PDF formatu su pilna pakeitimų istorija ir patvirtinimais.
  • 9Įvykių sekos įrašai gali būti eksportuojami su laiko žymomis ir visais vartotojų veiksmais.
  • 10Sistema leidžia konfigūruoti pakeitimų tipus (pvz., dokumentiniai, įrangos, procesų) ir sukonfigūruoti pakeitimų numerius, taip kad jie būtų sudaromi pagal pasirinktą struktūrą (pvz., pradžioje gali būti pridėtas pasirinktas žymuo ar žodis).
  • 11Sistema užtikrina nustatytus rizikos klasifikavimo lygius ir vartotojų rolėmis pagrįstas peržiūros užduotis, konfigūruojamas pagal įvykio tipą ar vietą.

Tiekėjų valdymas

  • 1Sistema turi užtikrinti galimybę vartotojams kurti, peržiūrėti, redaguoti ir naikinti tiekėjų įrašus, naudojant sistemoje sukonfigūruotus duomenų laukus. Tiekėjų įrašų peržiūra ir atsisiuntimas turi būti ribojami pagal pareigomis grįstą prieigos kontrolę.
  • 2Sistema turi užtikrinti tiekėjų kvalifikacijos būsenų valdymą, įskaitant „Laukiama“, „Kvalifikuotas“ ir „Diskvalifikuotas“, aiškiai nurodant dabartinę būseną.
  • 3Kvalifikacijos įrašai turi būti versijuojami, išsaugant kvalifikacijos datą, peržiūrėjusį asmenį, tvirtintoją ir komentarus.
  • 4Sistema turi saugoti pilną įvykių seką visiems tiekėjų gyvavimo ciklo veiksmams, įskaitant būsenų keitimus ir prisijumgimo įrašus.
  • 5Sistema turi leisti nustatyti pirminės ir periodinės kvalifikacijos periodiškumus pagal tiekėjo rizikos lygį (pvz., kasmet, kas dvejus metus).
  • 6Sistema turi automatiškai siųsti pranešimus ir priminimus apie laukiančias kvalifikacijas, artėjančius ar vėluojančius terminus ir būsenų pasikeitimus. Pranešimų dažnumas, slenksčiai ir gavėjai turi būti konfigūruojami.
  • 7Sistema turi vartotojui suteikti galimybę įkelti, saugoti ir valdyti su kvalifikacija susijusius dokumentus ir formas, įskaitant klausimynus, sertifikatus ir kitus įrodymus. Naudotojai turi galėti peržiūrėti priedus tiesiogiai tiekėjo įraše.
  • 8Sistema turi generuoti PDF ir CSV ataskaitas, apibendrinančias tiekėjų kvalifikacijos būsenas, istoriją ir susijusią dokumentaciją.
  • 9Sistema turi integruotis su auditų valdymo sistemos dalimi, užtikrindama, kad tiekėjų atitikties auditai būtų planuojami, sekami ir susiejami su tiekėjo kvalifikacijos būsena.

Gamybos žurnalų valdymas

  • 1Vartotojai gali kurti naujus gamybos žurnalus ir susieti juos su konkrečiomis produktų partijomis bei gamybos procedūromis.
  • 2Į žurnalą galima nuskaityti medžiagas, įrangą ir sudėtis naudojant brūkšninius arba QR kodus.
  • 3Vartotojai gali pašalinti nuskenuotus elementus iš gamybos žurnalo prieš jam tampant galutiniu.
  • 4Sistema turi palaikyti pasirinkčių sąrašų sudarymą, jų naudojimą gamybos procese ir nesunaudotų elementų grąžinimą į sandėlį.
  • 5Sistema turi vykdyti patikrinimus pagal nustatytus atsargų ar procedūrinius kriterijus (pvz., tikrinti, ar galiojimo data yra tinkama).
  • 6Įvykių sekos funkcija turi fiksuoti visus gamybos žurnalo veiksmus, įskaitant pridėjimus, pašalinimus, pakeitimus ir patvirtinimus.
  • 7Vartotojai sistemoje gali generuoti ataskaitas, taikydami filtrus pagal datą, elemento tipą, produkto partiją ar vartotojo vardą.
  • 8Sistema turi palaikyti gamybos žurnalų eksportą į PDF formatu.
  • 9Vartotojai gali pateikti užbaigtą gamybos žurnalą peržiūrai, priskirdami jį atsakingiems tikrintojams.
  • 10Sistema turi palaikyti konfigūruojamus pasirinktinius laukus, skirtus papildomai informacijai apie gamybos žurnalus ir rinkinius saugoti.

Kokybės įvykių valdymas

  • 1Sistema turi užtikrinti, kad vartotojai galės kurti, peržiūrėti, redaguoti ir nukreipti kokybės įvykius (pvz., nuokrypius, incidentus, OOS), priskiriant jiems unikalius identifikatorius pagal konfigūruojamą numeracijos schemą ir organizacines kategorijas (pvz., Gamyba, QA, QC).
  • 2Kiekvienas sistemoje esantis kokybinio įvykio įrašas turi apimti reikalingus metaduomenis, tyrimo informaciją, pagrindinės priežasties analizę, uždarymo santrauką bei galimybę pridėti priedus (pvz., nuotraukas, ataskaitas) bet kuriame darbo eigos etape.
  • 3Sistema turi užtikrinti, kad kokybės įvykio darbo eiga apima etapus nuo inicijavimo iki galutinio patvirtinimo (pvz., inicijavimas → QA vertinimas → tyrimas → priežasties analizė → CAPA → uždarymas), su galimybe priskirti atsakingus asmenis, terminus ir stebėti atlikimo būseną.
  • 4Sistema turi leisti vartotojui nustatyti ir reguliuoti poveikio / rizikos lygius (pvz., žemas, vidutinis, aukštas) bei pasirinkti arba redaguoti pagrindines priežastis (pvz., žmogiškoji klaida, įrangos gedimas).
  • 5Sistema turi užtikrinti, kad susijusios veiklos galėtų būti inicijuojamos tiesiogiai iš kokybės įvykio įrašo, pavyzdžiui, sukuriant CAPA įrašus, priskiriant mokymus ar inicijuojant dokumentų pakeitimus, taip užtikrinant visapusišką procesų atsekamumą.
  • 6Visos įrašų modifikacijos sistemoje turi būti fiksuojamos įvykių sekos istorijoje, nurodant vartotoją, datą ir atliktus veiksmus; uždarymo ir pokyčių po uždarymo įrašai turi būti dokumentuojami.
  • 7Sistema turi palaikyti pareigomis ir teisėmis pagrįstą įrašų peržiūrą ir patvirtinimą, įskaitant elektroninius parašus ir galimybę pateikti peržiūros komentarus.
  • 8Automatiniai pranešimai sistemoje turi būti siunčiami atsakingiems vartotojams darbo eigos metu (pvz., priskyrus įvykį, eskaluojant, pasibaigus terminams, atliekant galutinį patvirtinimą).
  • 9Sistema turi užtikrinti, kad įrašuose būtų fiksuojamos pagrindinės laiko žymos (inicijavimas, tyrimo pradžia, užbaigimas, uždarymas), o trukmė turi būti apskaičiuojama automatiškai, leidžiant atsakingiems asmenims stebėti uždarymo laiką ir terminų laikymąsi.
  • 10Sistemos funkcionalumas užtikrina, kad įvykiai yra analizuojami ir teikiami ataskaitose pagal jų tipą, būseną, poveikio lygį, pagrindinę priežastį, atsakingą vartotoją ir datų intervalą, su galimybe sugeneruoti PDF santraukos ataskaitas.
  • 11Sistema turi užtikrinti, kad kokybės įvykiai būtų susiejami su produkto žurnalais, aplinkos monitoringo duomenimis, temperatūros ir drėgmės įrašai, tam, kad būtų aiškus įvykio /tyrimo kontekstas.

Produktų partijų valdymas

  • 1Vartotojai turi turėti galimybę sistemoje inicijuoti naują produkto partiją ir nurodyti jos atributus, įskaitant produktą, partijos numerį, inicijavimo datą, patalpą ir kitus konfigūruojamus laukus.
  • 2Sistema leidžia vartotojams susieti kelis gamybos žurnalo įrašus su produkto partija.
  • 3Sistema leidžia priskirti operatorius kiekvienam gamybos žurnalo įrašui produkto partijoje.
  • 4Gamybos žurnalo įrašai yra pildomos elektroninės formos, skirtos dokumentuoti pagrindinius proceso etapus, naudotas medžiagas ir reikalingus parašus viso gamybos proceso metu.
  • 5Kokybės įvykiai turi būti tiesiogiai susieti su paveikta produkto partija, siekiant užtikrinti atsekamumą ir sudaryti sąlygas veiksmingai šakninės priežasties analizei.
  • 6Įvykių seka fiksuoja visus veiksmus, susijusius su produkto gamyba.
  • 7Sistema gali eksportuoti produktų išleidimo duomenis ir istoriją, taip pat generuoti susijusias ataskaitas.
  • 8Vartotojai gali įkelti papildomus failus į sistemą prie produkto partijos.
  • 9Konfigūruojami produkto partijos duomenų laukai.
  • 10Elektroniniai parašai turi būti taikomi ir registruojami pildomose gamybos žurnalo formose, patvirtinant ir autorizuojant gamybos veiksmus. Užbaigus gamybos partijos įrašą, jis užrakinamas ir patvirtinami skaitmeniniu parašu.
  • 11Vartotojas, turintis administratoriaus teises, privalo galėti peržiūrėti partijų įrašus prieš jų užbaigimą ir išleidimą.
  • 12Sistema turi leisti susieti gamybos žurnalus su produkto išleidimo partijomis, kad būtų pateiktas išsamus nuskaitytų komponentų, atliktų operacijų ir priskirto personalo įrašas kiekvienai partijai.
  • 13Aplinkos monitoringo duomenys gali būti susieti su produkto partijomis, siekiant užtikrinti, kad gamybos procesų sąlygos atitiktų GMP švaraus kambario reikalavimus.
  • 14Gamybos arba išleidimo testavimo metu surinkti mėginiai gali būti susieti su produkto partijomis, kad vartotojui būtų lengviau sekti rezultatus ir užtikrinti atitiktį QC protokolams.
  • 15Kiekvienas gamybos žurnalo įrašas turi pateikti pagrindinius metaduomenis: priskirtus operatorius, būseną, prašymo ir išdavimo datas bei susijusį personalą.
  • 16Tarp partijų atliekami įrangos perstatymo ir aptarnavimo veiksmai turi būti registruojami ir susiejami, kad būtų užtikrintas pilnas valymo, priežiūros ir įrangos būsenos dokumentavimas.
  • 17Su produkto partija susieti kriogeninio saugojimo vienetai ir mėgintuvėliai turi būti tiesiogiai atsekami iš partijos sąsajos, užtikrinant nuolatinį matomumą dėl jų saugojimo būsenos ir atsargų vietos.
  • 18Vartotojai su administracinėmis teisėmis gali išleisti produkto partiją, įskaitant sąlyginį išleidimą su pateiktais pagrindimais ir reikalavimais, arba atmesti partiją nurodydami priežastį.
  • 19Su produkto partija susijusios stabilumo studijos gali būti peržiūrimos, siekiant patvirtinti, kad produktas išlaiko reikalaujamą kokybę ir atitinka patvirtintą tinkamumo vartoti terminą.
  • 20Kokybės rodikliai gali būti sukonfigūruoti taip, kad iš gamybos partijų įrašų būtų išgaunami pagrindiniai duomenys (pvz., ląstelių skaičius, gyvybingumas), kurie vėliau gali būti analizuojami ir teikiami ataskaitose, taip palaikant nuolatinį tobulinimą ir atitikties užtikrinimą.
  • 21Sistema išsaugo išsamią įvykių seką apie visus veiksmus, atliktus su produkto partija, įskaitant būsenos pakeitimus ir naudotojų veiksmus.
  • 22Kokybės įvykiai yra susiejami su paveikta produkto partija, siekiant užtikrinti atsekamumą ir atlikti šakninės priežasties analizę.
  • 23Sistema turi susieti laboratorinių žurnalų projektus su produkto partijomis, kad technologijų perdavimo dokumentacija būtų išsaugoma ir pateikiama atitinkamos gamybos partijos kontekste.
  • 24Konkrečiai partijai priskirtos galutinio produkto etiketės turi būti peržiūrimos ir valdomos partijos įrašo kontekste, kad būtų užtikrintas nuoseklus visų išleistų vienetų ženklinimas.
  • 25Kiekvienai produkto partijai gali būti parengtas CoA, kuriame dokumentuojami analitinių tyrimų rezultatai, kokybės požymiai ir galutinis partijos sprendimas; šis dokumentas veikia kaip oficialus partijos išleidimo patvirtinimas.
  • 26Sistema turi sekti ir rodyti būsenas tiek atskiriems gamybos žurnalo įrašams, tiek visai produkto partijai (pvz., „Vykdoma“, „Išleista“, „Atmesta“).
  • 27Vartotojų teisių struktūroje turi būti apibrėžta peržiūros (review) rolė.
  • 28Šablonai: Pildomi PDF ataskaitų šablonai, naudojami Sertifikatams apie analizę (CoA) generuoti kiekvienai produkto partijai.

Kriogeninių atsargų valdymas

  • 1Vartotojai gali pridėti, redaguoti ir ištrinti kriogeninius mėginius, įskaitant metaduomenis (mėginio tipą, pasirinktinius laukus, vieneto tipą – mėgintuvėlis arba maišelis).
  • 2Sistema palaiko mėgintuvėlių ir maišelių vienetų tipus, konfigūruojamus kiekvienam mėginiui.
  • 3Įstaiga gali apibrėžti leidžiamus mėginių tipus (pvz., ląstelės, plazma, virkštelės kraujas).
  • 4Sistema palaiko pasirinktinius mėginių duomenų laukus papildomai informacijai saugoti.
  • 5Vartotojai gali įregistruoti ir išregistruoti mėginius naudojant brūkšninį kodą; mėginių registravimo būsenos pateikiamos sistemoje.
  • 6Sistema seka mėginių būsenas, pvz., „Įregistruotas“, „Išregistruotas“, „Laukiama patikros“, „Laukiama patvirtinimo“, „Laukiama vietos priskyrimo“.
  • 7Mėginiams gali būti kuriamos atskiros mėginio dalys (alikvotinės dalys), kurios sekamos pagal taros numerį, tūrį ir vietą.
  • 8Mėginio dalims gali būti priskiriamos būsenos (pvz., „Išleista“, „Pasibaigusi“, „Utilizuota“) ir leidžiami veiksmai (perkėlimas, redagavimas, ištrynimas).
  • 9Vartotojai gali masiškai įkelti alikvotus naudodami sistemos šablonus.
  • 10Sistema gali generuoti etiketes mėginio dalims, įskaitant brūkšninius kodus ir metaduomenis.
  • 11Mėginiai saugomi hierarchinėje šaldiklio struktūroje: Šaldiklis → Kvadrantas (laikymo plokštuma ar lentyna) → Rėmas → Kasetė.
  • 12Sistema palaiko vizualią šaldiklių navigaciją, įskaitant vietos užpildymo rodiklius ir vietų priskyrimą.
  • 13Šaldiklių ir mėginių juose išdėstymas gali būti konfigūruojama: pavadinimai, talpos ribos, išdėstymo matmenys.
  • 14Sistema turi suteikti galimybę konfigūruoti įspėjimus apie laukiančias registravimo (check-in) užduotis.
  • 15Įvykių sekos funkcija užtikrina, kad visi veiksmai susiję su mėginių ir mėginio dalių veiksmais yra registruojami ir atsekami, o šie duomenys gali būti eksportuojami.
  • 16Sistema leidžia generuoti ataskaitas, naudojat paieškos filtrus, ir eksportuoti jas PDF arba CSV formatais.
  • 17Filtrai prieinami visoje vartotojo sąsajoje.
  • 18Sistema suteikia galimybę realiuoju laiku matyti mėginių kiekius ir atsargų lygius.
  • 19Patvirtinimo veiksmai turi būti užregistruoti nurodant naudotojo, datos ir mėginio identifikatorius.

Bendrieji sistemos reikalavimai

  • 1Kompiuterizuotos sistemos serveriai ir duomenų bazės turi būti fiziškai įrengtos Lietuvoje arba kitoje Europos Sąjungos valstybėje narėje, užtikrinant BDAR ir Lietuvos teisės aktų reikalavimų laikymąsi.
  • 2Kompiuterizuotos sistemos dizainas turi būti aiškus, nuoseklus ir patogus naudotojui. Visos funkcijos turi būti pažymėtos pavadinimais lietuvių arba anglų kalba ir lengvai pasiekiamos iš pagrindinio ekrano.
  • 3Pirkimo metu turi būti jau sukurta ir veikianti kompiuterizuota programinės įrangos platforma, kuri yra paruošta bazinė sistema. Kompiuterizuota sistema negali būti tiekėjo kuriama nuo nulio konkrečiam pirkimui. Sistema turi sudaryti galimybę konfigūruoti sprendimus, nekeičiant bazinės sistemos architektūros.
  • 4Tiekėjo siūlomas sprendimas turi sudaryti galimybę kurti ir diegti naujus funkcinius praplėtimus bei palaikyti tolesnį atnaujinimą ir palaikymą viso sistemos gyvavimo metu.
  • 5Siekiant sumažinti duomenų praradimo rizikas, kompiuterizuota sistema privalo automatiškai kurti duomenų atsargines kopijas.
  • 6Visi kritiniai duomenys ir konfigūracija turi būti kopijuojami nustatytais su vartotoju sutartais intervalais ne ilgesniais kaip 24 val.
  • 7Visi nukopijuoti duomenys ir sistemos konfigūracija turi būti atkuriami pagal naudotojo prašymą bet kuriuo metu, užtikrinant, kad duomenys nebūtų prarasti. Išimtis taikoma tik tais atvejais, kai paskutinės paros atsarginės kopijos kūrimas dar nebuvo baigtas ir duomenys dėl to negali būti atkurti. Duomenų atkūrimas turi būti atliktas ne vėliau kaip per 48 valandas nuo naudotojo užklausos gavimo.
  • 8Atsarginių kopijų laikmenos turi būti saugios, apsaugotos nuo neteisėtos prieigos ir laikomos kontroliuojamoje aplinkoje, o atkūrimo procedūros – dokumentuotos, išbandytos ir periodiškai (ne rečiau kaip kas 12 mėn.) tikrinamos, siekiant užtikrinti duomenų integralumą ir sistemos pasiekiamumą. Priimtini pavyzdžiai pateikiami pirkimo metu: Atsarginių kopijų kūrimo ir atkūrimo procedūra (SOP), atkūrimo testų / bandymų ataskaitos (ne senesnės kaip 12 mėn.).
  • 9Pateikiama ISO/IEC 27001 arba lygiavertė saugumo sertifikato kopija.
  • 10BDAR (GDPR) atitikties deklaracija.
  • 11Sistemos validacijos arba atlikto audito ataskaita (jei taikoma).
  • 12Informacinės žinutės turi būti pateikiamos aiškiai, suprantamai ir struktūruotai, kad naudotojas galėtų lengvai atpažinti sistemos būseną, įvykius ar klaidas, aprašant informaciją žodžiais o ne kodais.
  • 13Žinutėse turi būti nurodytas žinutės tipas, informacija, perspėjimas, klaida.
  • 14Žinutės tekstas turi būti pateiktas lietuvių arba anglų kalba, priklausomai nuo sistemos nustatymų.
  • 15Žinutės turi būti skirstomos pagal tipą (pvz., informacija, perspėjimas, klaida).
  • 16Visos informacinės žinutės, susijusios su kokybės ar gamybos procesais, turi būti išsaugotos sistemos įvykių sekos žurnale atsekamumui užtikrinti.
  • 17Visi automatiniai skaičiavimai turi būti patikimi, dokumentuotai patikrinti validavimo metu.
  • 18Jei atliekami kritiniai skaičiavimai (pvz., dozavimo, mišinių sudėties), sistema turi patvirtinti jų tikslumą prieš tęsiant procesą.
  • 19Sistema privalo turėti įvykių sekos („audit trail“) funkciją. Joje turi būti registruojami ir matomi: visi sistemos sugeneruoti aliarmų pranešimai; informacinės žinutės; operatorių atlikti veiksmai (įskaitant įvykio laiką ir datą, operatoriaus vardą); sistemos konfigūracijos ar nustatymų pakeitimai.
  • 20Įvykių seka turi būti nuolat kaupiama ir atsekama be laiko apribojimų. Taip pat sistema privalo turėti galimybę sugeneruoti išsamią įvykių sekos ataskaitą PDF formatu.
  • 21Sistema privalo turėti vartotojų valdymo („User Management“) funkciją leidžiančią kurti, redaguoti, šalinti vartotojus, priskirti jiems roles bei prieigos teises pagal atsakomybės lygį.
  • 22Kompiuterizuota sistema turi riboti prieigą, užtikrinant, kad prisijungti galėtų tik registruoti naudotojai. Naudotojų prisijungimo duomenys turi būti apsaugoti prisijungimo proceso metu, o kiekvienam naudotojui suteikiama prieiga tik prie tų funkcijų ir duomenų, kurie atitinka jam priskirtą vaidmenį ir atsakomybės lygį.
  • 23Prieiga prie sistemos suteikiama tik individualiai identifikuotiems, registruotiems naudotojams; bendros (bendrinės) naudotojų paskyros draudžiamos ir negali būti naudojamos įprastinei veiklai vykdyti.
  • 24Prisijungimo metu naudotojų autentifikavimo duomenys (naudotojo vardas, slaptažodis, autentifikavimo žetonas ir pan.) turi būti perduodami ir saugomi užšifruotai, naudojant saugius protokolus.
  • 25Vartotojas gali pasiekti tik tas funkcijas ir duomenis, kurie atitinka jo priskirtą rolę, pareigas ir atsakomybės lygį (rolėmis pagrįstas prieigos valdymas – RBAC), įskaitant administracinių teisių ribojimą.
  • 26Prisijungimo, atsijungimo, nesėkmingų prisijungimo bandymų ir pagal vartotojo teises leistinų veiksmų įvykiai turi būti registruojami, apsaugomi nuo neteisėto pakeitimo ir reguliariai peržiūrimi vadovaujantis organizacijos informacijos saugos politika.
  • 27Autentifikavimo priemonės ir prieigos valdymo procedūros turi atitikti organizacinius ir techninius kibernetinio saugumo reikalavimus (KSRA) ir įstaigos informacijos saugos dokumentus.
  • 28Naudojant SSO, sistema neturi lokalioje aplinkoje saugoti ar tvarkyti naudotojų slaptažodžių; autentifikavimas (įskaitant daugiafaktorę autentifikaciją – MFA) turi būti deleguojamas centriniam tapatybės teikėjui pagal KSRA ir įstaigos informacijos saugos politikos reikalavimus.
  • 29Sistema turi suteikti galimybę prieigos teises susieti su tapatybės teikėjo objektais (naudotojų grupėmis, rolėmis ar atributais), kad būtų galima centralizuotai valdyti vartotojus per visą gyvavimo ciklą (paskyrų kūrimą, keitimą, blokavimą, panaikinimą).
  • 30SSO sesijų valdymas (sesijos galiojimo laikas, neaktyvumo laikas, išėjimas iš sistemos) turi būti įgyvendintas taip, kad atitiktų KSRA ir įstaigos nustatytus saugumo reikalavimus.
  • 31Sistemoje turi būti realizuotas autentifikavimas, naudojant vieningo prisijungimo (SSO) mechanizmą per Perkančiosios organizacijos elektroninių tapatybių valdymo sistemą (IAM).
  • 32Pradinis Sistemos puslapis, rodomas iš karto po sėkmingo naudotojo prisijungimo (per SSO), ir turi aiškiai nurodyti, prie kurios Sistemos ir kurios aplinkos (pvz., produkcinės, testinės) naudotojas jungiasi, taip pat paprašyti naudotojo patvirtinti, ar jis sutinka pradėti darbą šioje Sistemoje, net jei autentifikavimas jau buvo atliktas per SSO. Naudotojo pateiktas patvirtinimas turi būti registruojamas Sistemos įvykių sekos žurnaluose.
  • 33Naudotojų ir organizacinės struktūros metaduomenys (pvz., padaliniai, pareigos, rolės, grupės) turi būti automatiškai perduodami į Sistemą iš Perkančiosios organizacijos elektroninių tapatybių valdymo sistemos, naudojant suderintą duomenų mainų sąsają (pvz., tiesioginio krovimo į duomenų bazę mechanizmą ar API). Autentifikavimas ir autorizavimas turi būti užtikrinami naudojant SSO priemones ir IAM sistemos valdomas tapatybes bei jų atributus.
  • 34Sistema privalo turėti galimybę generuoti ataskaitas PDF formatu, kuriose būtų aiškiai pateikiamas operatoriaus vardas, atliktų veiksmų data ir laikas, šių veiksmų statusas bei kita aktuali rašytinė ir grafinė informacija.
  • 35Kompiuterizuotos sistemos licencija turi būti suteikiama kaip įstaigos masto licencija, nepriklausanti nuo konkretaus naudotojų ar darbo vietų skaičiaus, apimanti Vilniaus universiteto ligoninės Santaros klinikas.
  • 36Kompiuterizuotos sistemos funkcionalumas, dizainas ir pritaikymas privalo atitikti ES GMP 11 priedo, EudraLex Volume 4 ir / ar FDA 21 CFR Part 11 reikalavimus. Sistema turi užtikrinti duomenų integralumą, atsekamumą, elektroninių įrašų saugumą bei elektroninių parašų naudojimą. Tai turi būti patvirtinta atliekant kompiuterizuotos sistemos validavimą. Jei sistema sukurta užsienyje ir atitinka tik tos šalies reguliacinius reikalavimus, tiekėjas privalo pateikti įrodymus (reikalavimų atitikties palyginimą), patvirtinančius šių reikalavimų lygiavertiškumą Europos Sąjungos ir Lietuvos teisės aktams.
  • 37Pirkimo sutartis turi būti sudaroma 7 (septynerių) metų laikotarpiui.
  • 38Sutarties galiojimo laikotarpiu Tiekėjas įsipareigoja per nustatytus terminus ir pagal sudarytą bei Užsakovo patvirtintą techninę specifikaciją sukonfigūruoti ir įdiegti kompiuterizuotą sistemą, teikti techninę pagalbą, užtikrinti saugų duomenų saugojimą, vykdyti atsarginių kopijų darymą bei periodinius patikrinimus.
  • 39Be to, Tiekėjas įsipareigoja naujai sukonfigūruoti, ištestuoti ir perduoti sistemą naudoti ne vėliau kaip per vieną (1) mėnesį nuo naudotojo (užsakovo) užklausos gavimo dienos.
  • 40Techninė priežiūra ir palaikymas turi būti įskaičiuoti į pasiūlymo kainą ir apimti ne mažiau kaip: nuolatinę techninę pagalbą (helpdesk, nuotolinę pagalbą, klaidų šalinimą), reakcijos laiką kritinėms problemoms ≤ 24 val., bei kompiuterizuotos sistemos atnaujinimus ir saugumo pataisas.
  • 41Tiekėjas privalo užtikrinti pilną kompiuterizuotų sistemų validaciją (Computerized System Validation, CSV), kuri užtikrintų atitiktį EudraLex Volume 4, Annex 11 ir (arba) 21 CFR Part 11 reikalavimams bei būtų atliekama vadovaujantis GAMP5 gairėmis. Kaip įrodymas turi būti pateikiamas validavimo protokolo šablonas. Jei sistema sukurta užsienyje ir atitinka tik tos šalies reguliacinius reikalavimus, tiekėjas privalo pateikti įrodymus (reikalavimų atitikties palyginimą), patvirtinančius šių reikalavimų lygiavertiškumą Europos Sąjungos ir Lietuvos teisės aktams.
  • 42Validavimo apimtis: Įdiegimo kvalifikavimas (IQ) – patvirtinant, kad sistema įdiegta pagal patvirtintą projektinę dokumentaciją ir tiekėjo specifikacijas.
  • 43Validavimo apimtis: Veikimo kvalifikavimas (OQ) – įrodant, kad sistema veikia pagal iš anksto nustatytus funkcinius ir techninius reikalavimus.
  • 44Validavimo apimtis: Validacijos planas (Validation Plan, VP), apibrėžiantis validacijos strategiją, metodiką, atsakomybes ir dokumentacijos struktūrą.
  • 45Validavimo apimtis: Funkcinė specifikaciją (FS), detalizuojančią sistemos funkcionalumą ir konfigūraciją.
  • 46Validavimo apimtis: Validavimo išvados (VR / QR).
  • 47Visi validavimo dokumentai turi būti paruošti pagal “Good documentation practice”. Duomenys turi būti dokumentuoti taip, kad būtų aiškiai priskiriami atsakingam vykdytojui, o dokumentai – įskaitomi, nuolat prieinami ir apsaugoti nuo pakeitimų be atsekamumo.
  • 48Visi protokolo žingsniai turi būti pasirašomi atsakingo vykdytojo ir peržiūrimi bei patvirtinami kvalifikuotų asmenų (pvz., kokybės užtikrinimo atstovo). Naudojant elektroninius parašus, jie turi atitikti FDA 21 CFR Part 11 ir EudraLex Volume 4, Annex 11 reikalavimus ir būti lygiaverčiai ranka rašytiems parašams. Jei sistema sukurta užsienyje ir atitinka tik tos šalies reguliacinius reikalavimus, tiekėjas privalo pateikti įrodymus (reikalavimų atitikties palyginimą), patvirtinančius šių reikalavimų lygiavertiškumą Europos Sąjungos ir Lietuvos teisės aktams.
  • 49Įrašai ranka: daromi gyvu laiku, be tuščių eilučių ar langelių; klaidos taisomos perbraukiant, nenaudojant korektoriaus.
  • 50Visi validavimo metu atliekami veiksmai žymimi data ir autoriaus inicialais ar parašu.
  • 51Visi validavimo metu pastebėti nuokrypiai privalo būti užregistruoti gyvu laiku: aprašant faktinę situaciją, sąlygas ir galimą įtaką rezultatams.
  • 52Nustatytų nuokrypių kritiškumas privalo būti įvertintas nustatant ar nuokrypis turi įtakos produkto kokybei, duomenų integralumui ar reguliaciniam atitikimui.
  • 53Atlikus nuokrypio nagrinėjimą siūlomi korekciniai prevenciniai veiksmai. Atliekamas pakartotinis testavimas.
  • 54Validavimo nuokrypis uždaromas tik gavus patvirtinimą iš validavimo inžinieriaus ir kokybės užtikrinimo (QA) ar kito paskirto atsakingo asmens patvirtinimo.
  • 55Kompiuterizuotos sistemos validavimas negali būti laikomas pabaigtu kol visi jame nustatyti nuokrypiai nėra uždaryti.
  • 56Kompiuterizuotos sistemos validavimas turi būti sėkmingai įgyvendintas ne vėliau kaip per 60 kalendorinių dienų nuo instaliavimo. Bet kokia kita data turi būti pagrįsta ir suderinta su užsakovu.
  • 57Tiekėjas įsipareigoja, po kompiuterizuotos sistemos suvalidavimo, bet ne vėliau kaip per 1 (vieną) kalendorinį mėnesį, išskyrus atvejus, kai Šalys raštu susitaria dėl kito termino, organizuoti ir atlikti personalo mokymus nuotoliniu būdu ar gyvai.
  • 58Mokymų metu Tiekėjas privalo: Supažindinti Užsakovo personalą su kompiuterizuotos sistemos bendra darbo aplinka ir kiekviena išbaigta sistemos dalimi.
  • 59Mokymų metu Tiekėjas privalo: Suteikti galimybę praktiniams bandymams, imituojant realias darbo situacijas.
  • 60Mokymų metu Tiekėjas privalo: Pateikti vartotojo instrukciją anglų kalba (elektroniniu formatu).
  • 61Jeigu kompiuterizuotos sistemos perdavimo–priėmimo metu sistemos dalis nėra galutinai parengta, Tiekėjas įsipareigoja ją parengti ir įdiegti ne vėliau kaip per 90 kalendorinių dienų nuo Užsakovo raštiško užsakymo pateikimo dienos. Parengta ir įdiegta sistemos dalis turi būti perduodama Užsakovui nemokamai, po jo pareikalavimo.
  • 62Neužbaigtų sistemos elementų parengimas ir įdiegimas negali trukdyti kitai kompiuterizuotos sistemos naudojimo veiklai.
  • 63Naujos funkcijos negali turėti įtakos jau anksčiau numatytai ir patvirtintai kompiuterizuotos sistemos konfigūracijai.
  • 64Kiekvienos naujai sukonfigūruotos sistemos dalies funkcionalumas privalo būti patikrintas atliekant validavimą, kurio rezultatai yra privalomai pridedami kaip priedas prie bendros kompiuterizuotos sistemos validavimo bylos.
  • 65Atnaujinus sistemos konfigūraciją vartotojas privalo būti supažindintas su pakeitimais ir apmokytas naudotis visomis funkcijomis.
  • 66Pasibaigus ar nutraukus sutartį, tiekėjas privalo užtikrinti pilną duomenų eksportą ir migraciją į kitą sistemą be papildomų kaštų ir be duomenų praradimo per 15 kalendorinių dienų nuo vartotojo užklausos.
  • 67Visi sistemoje saugomi ir generuojami duomenys lieka išimtine perkančiosios organizacijos (Santaros klinikų) nuosavybe.

Dokumentų valdymas ir kontrolė

  • 1Sistema turi užtikrinti SOP, darbo instrukcijų ir formų peržiūrą, tvirtinimą, platinimą bei atnaujinimą, su pilna versijų kontrole ir dokumento keitimo istorija.
  • 2Automatizuoti peržiūrų ir patvirtinimų darbo srautai konfigūruojami pagal organizacijos procesus, skirtingų lygių vartotojų roles ir prieigos teises. Naudojami elektroniniai parašai turi atitikti FDA 21 CFR Part 11 ir EudraLex Volume 4, Annex 11 reikalavimus bei būti teisiškai lygiaverčiai ranka rašytiems parašams. Jei sistema sukurta užsienyje ir atitinka tik tos šalies reguliacinius reikalavimus, tiekėjas privalo pateikti įrodymus (reikalavimų atitikties palyginimą), patvirtinančius šių reikalavimų lygiavertiškumą Europos Sąjungos ir Lietuvos teisės aktams.
  • 3Sistema integruojama su personalo mokymų valdymo funkciją, leidžiant susieti dokumentų patvirtinimą su mokymų įrašais.
  • 4Užtikrinama išplėstinė paieška, dokumentų gyvavimo ciklo analitika bei automatiniai perspėjimai apie galiojimo pabaigą, planuojamas peržiūras ar pavėluotas užduotis.

Suvartojamųjų atsargų valdymas

  • 1Naudotojai gali išleisti, karantinuoti arba atmesti darbo priemonių partijų įrašus, o tiekimo būsenos (pvz., Išleista, Karantinuota, Atmesta, Pasibaigęs galiojimas) valdomos pagal rolėmis pagrįstas prieigos teises.
  • 2Prieš tiekimo panaudojimą vykdoma kontroliuojama išleidimo darbo eiga, dokumentuojanti patvirtinimus ir būsenų pasikeitimus.
  • 3Sistemoje gali būti nustatytos minimalios ir maksimalios atsargų ribos, o jas viršijus automatiškai siunčiami įspėjimai.
  • 4Sistema generuoja unikalias brūkšninių kodų etiketes, skirtas darbo priemonių identifikavimui ir atsekamumui. Etikečių formatas yra konfigūruojamas ir gali būti papildytas pasirenkamais laukais (pvz., tiekimo ID, būsena, QR kodas, vieta). Procedūrų metu brūkšninio kodo nuskaitymas naudojamas darbo priemonių sunaudojimui automatiškai registruoti atsargų apskaitoje.
  • 5Atsargos stebimos realiuoju laiku, su išsamiais žurnalais, fiksuojančiais laiko žymas, atsakingus operatorius ir susijusių procedūrų nuorodas.
  • 6Nurašymo žurnalai tiksliai atspindi sunaudojimą pagal užsakymus ir atsargų pokyčius, o jų įrašai gali būti papildyti pasirenkamais metaduomenų laukais (pvz., sunaudojimo priežastis, veiklos tipas), konfigūruojamais įstaigos lygiu.
  • 7Sistemoje apibrėžiamos atsargų laikymo vietos, o atsargų sutikrinimo funkcijos palaiko reguliarius auditus ir užtikrina įrašų tikslumą.
  • 8Sertifikatai, MSDS dokumentai ir pirkimo dokumentai gali būti įkelti bei susieti su kiekvienu darbo priemonės įrašu, o integruota sertifikatų paieška leidžia greitai rasti susijusius atitikties ir dokumentacijos įrašus.
  • 9Automatizuoti pranešimai sistemoje informuoja vartotojus, kai atsargų kiekis sumažėja arba artėja prekių galiojimo pabaiga. Pranešimų nustatymuose galima konfigūruoti perspėjimo slenksčius, siuntimo dažnį ir gavėjus mažų atsargų kiekio, artėjančio galiojimo pabaigos bei pirkimo įvykiams.
  • 10Sistema turi įvykių sekos funkciją, kuri registruoja visas atsargų operacijas, įskaitant pridėjimus, panaudojimą, perkėlimus ir koregavimus. Generuojamos PDF ataskaitos suteikia išsamų atsargų likučių ir jų panaudojimo istorijos matomumą.
  • 11Sistema turi užsakymų sekimo funkcijas, leidžiančias stebėti pirkimo procesus ir atsargų pristatymus. Užsakymų įrašuose gali būti naudojami papildomi, individualiai pritaikomi laukai, siekiant išplėsti sekimo galimybes.
  • 12Darbo priemonės sistemoje gali būti valdomos kaip pagrindiniai įrašai arba naudojant šablonus. Darbo priemonių partijų įrašai gali būti papildyti pasirinktiniais duomenų laukais pagal perkančiosios įstaigos poreikį.

Audinių bankininkystės veiklos valdymas

  • 1Donorystės veiklų valdymas ir atsekamumas sistemoje: Sistema turi funkcijas, kurios leidžia registruoti donoro duomenis, saugoti sutikimo formas, laboratorinių tyrimų rezultatus ir kitą susijusią dokumentaciją, o visi duomenų pakeitimai yra automatiškai registruojami įvykių sekos funkcijoje, fiksuojant datą, laiką ir atsakingą vartotoją.
  • 2Sistema turi užtikrinti donorystės veiklų valdymą, leisdama naudotojams registruoti surinkimo duomenis (įskaitant datą, vietą, atsakingus darbuotojus, laiką ir kitą susijusią informaciją) bei fiksuoti neatitikimus, tokius kaip pažeisti mėginiai, netinkamos sąlygos ar surinkimo klaidos.
  • 3Sistema turi užtikrinti mėginių gavimo valdymą, leisdama naudotojams registruoti mėginio gavimo duomenis, sutikrinti juos su surinkimo įrašais, patvirtinti identifikatorius, pridėti papildomus dokumentus, priskirti karantino būseną iki tyrimų atlikimo ir kokybės patvirtinimo atliktų tyrimų ir kokybės patvirtinimo, bei fiksuoti neatitikimus su išsamiais aprašymais.
  • 4Sistema turi užtikrinti mėginių apdorojimo veiklų valdymą, leisdama naudotojams registruoti apdorojimo protokolus (įskaitant visus veiksmus, panaudotą įrangą ir reagentus), sekti įrangos ir reagentų duomenis, tokius kaip partijos numeriai, galiojimo terminai ir atsargų kiekiai, registruoti kokybės kontrolės rezultatus (pvz., mikrobiologinius tyrimus, gyvybingumo testus, sterilumo patikras), valdyti būsenų pasikeitimus nuo „Karantino“ iki „Patvirtinta“ ar „Atmesta“, automatiškai generuoti tinkamumo sertifikatus pagal kokybės kontrolės rezultatus ir palaikyti pilną įvykių seką su naudotojo veiksmais ir laiko žymomis.
  • 5Sistema turi palaikyti mėginių saugojimo valdymą, leisdama naudotojams nustatyti ir valdyti saugojimo vietas (įskaitant virtualias lentynas ir unikalius vietos identifikatorius), integruoti aplinkos stebėsenos duomenis, tokius kaip temperatūros, drėgmės ir dujų lygio rodmenys, su realaus laiko įspėjimais viršijus nustatytas ribas, bei užtikrinti atsargų valdymą naudojant FIFO/FEFO logiką, realaus laiko likučių atnaujinimus ir vienetų lygmens atsekamumą.
  • 6Sistema turi palaikyti mėginių paskirstymo valdymą, leidžiant registruoti vidinius ir išorinius užsakymus su prioriteto nustatymu, užtikrinti visą atsekamumą nuo donoro ir mėginio iki galutinio gavėjo, atlikti tinkamumo patikrą prieš išleidimą, generuoti transportavimo dokumentus (etiketes, sertifikatus ir išleidimo formas), realiuoju laiku atnaujinti atsargas ir vienetų būsenas, bei registruoti gavėjo pristatymo patvirtinimus.
  • 7Sistema turi užtikrinti ataskaitų generavimą ir galimą duomenų analizės funkciją, įskaitant donorų ir mėginių tendencijų vizualizavimą, neatitikčių ir incidentų registravimą bei sekimą, kokybės kontrolės rodiklių stebėseną, saugojimo talpos ir temperatūrų efektyvumo analizę, taip pat automatizuotą reguliacinių ataskaitų rengimą, atitinkantį SoHO, GMP, GTP ir nacionalinių teisės aktų reikalavimus.

CAPA valdymas (Korekciniai ir Prevenciniai Veiksmai)

  • 1CAPA kūrimas ir klasifikavimas: Sistema turi leisti naudotojams kurti CAPA įrašus tiesiogiai arba inicijuoti juos iš susijusių darbo erdvių, tokių kaip kokybės įvykiai, įvykių seka ar dokumentų valdymo procesai. Kiekvienai CAPA turi būti suteikiamas unikalus identifikatorius, o įrašas turi būti priskiriamas kaip korekcinis, prevencinis arba mišrus.
  • 2Privalomi duomenys ir atsakomybės priskyrimas: CAPA įrašuose turi būti pateikiami privalomi metaduomenys, įskaitant įvykio kilmę, susietus įrašus, atsakingą asmenį (-is), konfigūruojamus terminus ir pagrindinės priežasties analizę. Atsakingas asmuo turi turėti galimybę registruoti vykdymo proceso eigą ir užbaigimą.
  • 3Sistema turi leisti vartotojui valdyti CAPA įrašus pagal apibrėžtą gyvavimo ciklą, taikant būsenas (pvz., nauja, vykdoma, uždaryta, anuliuota). CAPA įrašas negali būti perkeltas į patikros ar uždarymo etapą, kol visi susieti veiksmų punktai nėra užbaigti.
  • 4Sistema turi užtikrinti kelių veiksmų priskyrimą vienam CAPA įrašui, suteikiant jiems atskirus atsakingus asmenis, terminus ir būsenas. Veiksmai turi būti pateikiami kontrolinio sąrašo formatu su filtravimo galimybėmis pagal atsakomybę, terminą ir būseną. Efektyvumo patikra turi būti priskiriama atsakingam asmeniui ir stebima iki įvykdymo.
  • 5Sistema turi suteikti galimybę įkelti ir peržiūrėti priedus (dokumentus, bandymų rezultatus, vaizdus). Sistemoje turi būti galima sugeneruoti PDF ataskaitas su visa CAPA įvykdymo istorija ir priedais.
  • 6Sistema turi užtikrinti darbo eigą pagal naudotojų vaidmenis, įskaitant peržiūrą ir patvirtinimą. Elektroniniai parašai ir peržiūros komentarai turi būti registruojami taip, kad būtų užtikrintas atsekamumas ir atitiktis procedūriniams bei reguliaciniams reikalavimams.
  • 7Sistema turi automatiškai siųsti pranešimus apie CAPA įrašų paskyrimą, artėjančius terminus, pavėluotus veiksmų punktus ir kintantį įrašo prioritetą pagal nustatytas taisykles.
  • 8Sistema turi turėti išsamią įvykių sekos funkciją, taikomą visiems sistemoje atliekamiems su CAPA įrašais susijusiems veiksmams, įskaitant naudotojo tapatybę, atliktą veiksmą, datą ir laiko žymą, taip pat duomenų ar būsenos pokyčius.
  • 9Sistema turi turėti konfigūruojamą CAPA įrašų numeravimo funkciją ir numatytą formatą (pvz., priešdėlis ir seka CAPA-YYYY-###) ir suteikti vartotojui galimybę sukurti pasirinktinius laukus organizacijos lygiu, užtikrinant atitiktį vidinėms SOP nuostatoms.

Dokumentai29

  • 1_General_procurement_conditions.docx
  • 2_Annexes_to_General_procurement_conditions.docx
  • 3_Special_procurement_conditions.docx
  • 5_Technical_Specification.docx
  • 1_Bendrosios_pirkimo_salygos.docx
  • 2_Bendrųjų_pirkimo_salygu_priedai.docx
  • 3_Specialiosios_pirkimo_sąlygos.docx
  • 5_Technine_specifikacija.docx
  • espd-request.pdf
  • espd-request.xml
  • 1_General_procurement_conditions.docx
  • 2_Annexes_to_General_procurement_conditions.docx
  • 3_Special_procurement_conditions.docx
  • 5_Technical_Specification.docx
  • espd-request.pdf
  • espd-request.xml
  • 1_Bendrosios_pirkimo_salygos.docx
  • 2_Bendrųjų_pirkimo_salygu_priedai.docx
  • 3_Specialiosios_pirkimo_sąlygos.docx
  • 5_Technine_specifikacija.docx
  • espd-request.pdf
  • 7879906_Contract notice - general directive, standard regime_0.pdf
  • 4_Sutarties_projektas_Contract_project.docx
  • espd-request.pdf
  • espd-request.xml
  • 4_Sutarties_projektas_Contract_project.docx
  • espd-request.xml
  • 2_c4t_7879906_1.xml
  • 1560_7879906.pdf
tendis.lt · Sukurta recodin.lt