CONSILIUL NAŢIONAL DE SOLUŢIONARE A CONTESTAŢIILOR
CONSILIUL NAŢIONAL DE SOLUŢIONARE A CONTESTAŢIILOR
C. N. S. C.
Str. Stavropoleos, nr. 6, România, CIF 00000000, CP 030084
Tel. x0 000 0000000 Fax. x0 000 0000000, x00000000000 xxx.xxxx.xx
În conformitate cu prevederile art. 266 alin. (2) din OUG nr. 34/2006 privind atribuirea contractelor de achiziţie publică, a contractelor de concesiune de lucrări publice şi a contractelor de concesiune de servicii, aprobată prin Legea nr. 337/2006, cu modificările şi completările ulterioare, Consiliul adoptă următoarea
DECIZIE
Nr. ...
Data: ...
Prin contestaţiile nr. ... şi nr. ... înregistrate la CNSC sub nr. şi
respectiv nr. ... înaintate de ... cu sediul în ... ... ... înmatriculată la Oficiul Registrului Comerţului sub nr. ... având CIF reprezentată
legal prin ... – ... şi ... cu sediul în ... reprezentată legal prin ,
formulate împotriva documentaţiei de atribuire elaborate de cu
sediul în ... ... judeţul ... în cadrul procedurii, licitaţie deschisă cu etapă finală de licitaţie electronică, organizate în vederea atribuirii contractului de achiziţie publică având ca obiect: „Aplicaţii informatice de management al resurselor economico-financiare”, cod CPV 48000000-8 – Pachete software şi sisteme informatice (Rev.2), 32420000-3 – Echipament de reţea (Rev.2), 48820000-2 – Servere (Rev.2), 72268000-1 – Servicii de furnizare de software (Rev.2), 80530000-8 – Servicii de informare profesională (Rev.2), s-a solicitat Consiliului suspendarea procedurii de atribuire şi modificarea documentaţiei de atribuire şi, în subsidiar, anularea procedurii de atribuire.
În baza legii şi a documentelor depuse de părţi, CONSILIUL NAŢIONAL DE SOLUŢIONARE A CONTESTAŢIILOR
DECIDE:
Conexează cele două contestaţii.
Admite, în parte, contestaţiile formulate de ... şi de ... şi obligă autoritatea contractantă la continuarea procedurii de atribuire, în maxim 10 zile de la primirea deciziei, prin modificarea documentaţiei de atribuire, conform celor reţinute în motivarea ce urmează.
Obligă autoritatea contractantă la publicarea în SEAP a măsurilor de remediere a documentaţiei de atribuire, inclusiv la decalarea termenului actual de depunere a ofertelor, cu minim 15 zile.
Respinge cererea ... de eliminare a modulului Banca de sânge, precum şi cererile implicite de anulare a procedurii de atribuire ale ambelor contestatoare, ca nefondate.
Prezenta decizie este obligatorie, în conformitate cu dispoziţiile art.
280 alin. (1) şi (3) din OUG nr. 34/2006, cu modificările şi completările ulterioare.
Împotriva prezentei decizii se poate formula plângere, în termen de 10 zile de la comunicare.
MOTIVARE
În luarea deciziei, s-au avut în vedere următoarele:
Prin contestaţia nr. ..., înregistrată la CNSC sub nr. ..., ... atacă atât fişa de date a achiziţiei, cât şi caietul de sarcini, elaborate de ... în calitate de autoritate contractantă în procedura mai sus amintită, considerând că acestea cuprind cerinţe discriminatorii şi excesive/ restrictive şi care, în esenţă, fac abstracţie de dispoziţiile actelor normative ale dreptului pozitiv în materie („art. 355”, din OUG nr. 34/2006).
Astfel, prezentând cerinţele minime stabilite pentru Arhitect sistem, menţionate la cap. III.2.3.a) - Capacitatea tehnică şi/sau profesională, contestatoarea solicită eliminarea ultimelor două cerinţe, respectiv:
- Cunoştinţe privind controlul şi/sau managementului riscurilor în sistemele informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional;
- Cunoaşterea aprofundată a unei metodologii recunoscute naţional/internaţional de auditare, control şi evaluare a securităţii sistemelor informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional”.
Întrucât, pentru arhitectul de sistem, s-a solicitat deţinerea de cunoştinţe privind managementul serviciilor IT, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional, contestatoarea apreciază că nu se justifică cerinţa: Cunoştinţe
privind controlul şi/sau managementului riscurilor în sistemele informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/ internaţional, deoarece acestea din urmă sunt incluse în obiectul de studiu al oricărei programe care are ca destinaţie obţinerea de cunoştinţe privind managementul serviciilor IT.
De asemenea, contestatoarea consideră excesivă şi cerinţa referitoare la Cunoaşterea aprofundată a unei metodologii recunoscute naţional/internaţional de auditare, control şi evaluare a securităţii sistemelor informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional, în condiţiile în care, în vederea asigurării cerinţelor de securitate, există deja un expert dedicat solicitat în fişa de date a achiziţiei şi anume expertul securitate şi testare.
În ceea ce priveşte cerinţele minime obligatorii referitoare la Expert interoperabilitate, contestatoarea susţine, pe de o parte, că niciun organism de stat sau privat, european sau de pe teritoriul României, nu emite certificări pe vreun standard de interoperabilitate în domeniul medical, în sensul prevăzut de art. 177 alin. (1) din OUG nr. 34/2006, iar pe de altă parte, că nicio autoritate publică competentă nu face recunoaşterea vreunui standard de interoperabilitate în domeniul medical.
În aceste condiţii, contestatoarea solicită eliminarea cerinţelor legate de certificarea pe un standard de interoperabilitate.
În continuare, menţionează că, în cadrul caietului de sarcini, la cap.
3.5.3.2. - Sistem de gestiune a bazelor de date, autoritatea contractantă a stabilit ca Baza de date relaţională să permită salvarea online a bazei de date direct pe bandă, precum şi ca Baza de date relaţională să permită o restaurare a bazei de date direct de pe bandă.
În opinia sa, executarea procedurilor de backup direct pe bandă reprezintă o metodă extrem de veche, din punct de vedere tehnologic, având performanţe şi manevrabilitate scăzute în procedurile de restaurare a datelor, fapt confirmat chiar de către autorul caietului de sarcini prin descrierea serverului de backup din care rezidă, fără putinţă de tăgadă, că acest server, de generaţie actuală, nu are unitate de bandă şi nici nu necesită aşa ceva, deoarece backup-ul se execută pe disk-uri medii mult mai rapide şi mai sigure.
Pentru aceste motive, contestatoarea solicită eliminarea din documentaţia de atribuire a oricăror referinţe la caracteristici ale sistemului care să presupună banda drept suport de păstrare a informaţiilor, chiar şi de backup.
De asemenea, menţionează că ... nu este organizat ca o Bancă de sânge, motiv pentru care consideră că solicitarea privind realizarea unui modul destinat acestui proces/secţie/departament inexistent şi
despre care nu a fost făcută vreo informare publică, până la momentul publicării documentaţiei de atribuire, are doar rolul de a favoriza anumite soluţii informatice.
În acest sens, cere eliminarea, din documentaţia de atribuire, a oricăror referinţe privind acest modul şi a altor module destinate unor secţii inexistente sau despre care spitalul nu a făcut în mod oficial vreo comunicare publică în sensul apariţiei înainte de publicarea documentaţiei de atribuire pentru prezentul proiect.
De asemenea, caietul de sarcini descrie o soluţie informatică existentă, aleasă de către autorul acestuia înainte de a concepe documentaţia de atribuire şi nu una care urmează să fie dezvoltată sau adaptată la nevoile beneficiarului aşa cum, teoretic, reiese din cap. 4. Management Resurse, în care „Echipa tehnică din partea furnizorului de servicii de dezvoltare şi implementare a Sistemului Informatic Medical Integrat implicată în dezvoltarea şi implementarea proiectului va cuprinde următoarele roluri (...)”.
În opinia sa, afirmaţia este susţinută atât de faptul că o aplicaţie care urmează să fie dezvoltată nu poate face obiectul unei demonstraţii, cât şi de existenţa a 3 elemente în „Capitolul 11. - Organizarea unei sesiuni demonstrative, care elimină orice îndoială privind această teorie:
- Autoritatea contractantă îşi rezervă dreptul de a organiza o sesiune demonstrativă în vederea testării funcţionalităţilor soluţiei informatice ofertate;
- Sesiunea demonstrativă este organizată pe baza scenariilor prezentate în acest capitol şi va fi susţinută de Managerul de Proiect;
- Dacă în urma demonstraţiei practice, rezultă că sistemul informatic ofertat nu corespunde cerinţelor, oferta va fi declarată neconformă, conform prevederilor art. 36 alin. (2) lit. a) din HG nr. 925/2006, cu modificările si completările ulterioare”.
Considerând discriminatoriu faptul că autoritatea contractantă „îşi rezervă dreptul de a organiza o sesiune demonstrativă” organizată
„pe baza scenariilor prezentate în acest capitol” (în care sunt descrise amănunţit atât funcţionalităţile, cât şi modalitatea unică de îndeplinire a acestora de către o soluţie informatică deja dezvoltată
- şi disponibilă pe piaţa informatică din România), urmând ca acele soluţii diferite de aceasta să fie eliminate pe motiv că „sistemul informatic ofertat nu corespunde cerinţelor”, contestatoarea solicită eliminarea sesiunii demonstrative din cadrul cerinţelor caietului de sarcini; în opinia sa, experienţa şi expertiza ofertanţilor sunt suficient de relevante în acest sens.
Totodată, menţionează că, în caietul de sarcini apar şi referinţe la utilizarea unor „standarde de interoperabilitate” (HL7 sau echivalent etc.), despre care autoritatea contractantă afirmă că au rolul de a
permite „colaborarea atât între subsistemele soluţiei cât şi între soluţie şi sistemele externe, cu arhitecturi respectând aceleaşi principii”.
Referitor la acest aspect, susţine că interoperabilitatea unui sistem informatic constă în capacitatea acestuia de a comunica (a face transfer de date inteligibile în mod multidirecţional) cu alte sisteme informatice folosind un limbaj comun, iar în metodele de abordare a interoperabilităţii, folosite în Tehnologia Informaţiei, există şi sunt folosite cu succes astfel de metode: web-serices, XML, CSV, XLS, SQL, care permit comunicarea în timp real şi/sau programată între sisteme informatice.
În acest sens, precizează că aceste metode sunt deosebit de cunoscute şi folosite de orice producător de soluţii informatice ce doreşte să obţină un sistem informatic deschis, care să poată comunica intern, dar şi cu exteriorul.
Privind modalitatea concretă de abordare a acestor standarde, contestatoarea arată că există, în domeniul Tehnologiei Informaţiei, documentaţie deosebit de clară, simplă şi explicată în mod elocvent, cunoscută de orice producător de soluţii IT (ex: xxxx://xx.xxxxxxxxx. org/wiki/lnteroperability), susţinând că aceste metode sunt folosite cu succes de toate sistemele informatice din România şi Uniunea Europeană, în condiţiile în care nimeni nu îşi doreşte izolare, din punct de vedere tehnologic, şi chiar există directive de strategie în adoptarea metodelor de interoperabilitate între sistemele informatice de orice tip şi din orice domeniu, aşa cum o fac cele de tip web-series, XML, CSV, XLS, SQL caracteristice oricărei platforme tehnologice moderne.
De asemenea, arată că HL7 este un standard cu originea în SUA, puternic promovat prin marketing american, care nu are nicio legătură directă cu vreun sistem informatic European, fapt cunoscut deja de către autorităţile decizionale din domeniul proiectelor e- sănătate, care au luat deja mai multe măsuri corective în acest sens.
În aceste condiţii, consideră că cerinţa caietului de sarcini constă, de fapt, în restrângerea metodelor de comunicare universale la standarde de interoperabilitate care sunt folosite exclusiv în domeniul medical: „Health Level Seven International (HL7) is the global authority on standards for interoperabilitv of health information technoloov” (traducere: „standardul HL7 este autoritatea globală de standardizare pentru interoperabiiitatea tehnologiei informatice medicale" - extras de pe site-ul oficial al standardului HL7, prima pagină: xxxx://xxx.xx0.xxx/).
În opinia sa, abordarea unui astfel de standard, submulţime a standardelor universale de comunicare din IT, chiar şi la un nivel simplist, de către un sistem informatic, conduce imediat la
restrângerea capacităţii de comunicare a sistemului cu alte sisteme informatice: acesta va putea comunica doar cu el însuşi şi cu sisteme informatice medicale care au implementat acest standard de interoperabilitate izolat, existent doar în domeniul medical.
Totodată, susţine că standardul de interoperabilitate HL7, la fel ca orice altă echivalenţă a acestuia, reprezintă un caz particular al standardelor de interoperabilitate folosite în sistemele informatice şi anume un caz care are legătură strictă cu domeniul medical.
În aceste condiţii, susţine că îndeplinirea unei astfel de cerinţe produce mai mult decât izolarea tehnologică informaţională a ... de alte sisteme informatice din sectorul medical (respectiv de acelea care nu au implementat limbajul de comunicare ales de autoritatea contractantă), anume izolarea de sisteme informatice de orice tip care nu folosesc standardele de interoperabilitate alese. Astfel că, rezolvarea tehnică a unei astfel de probleme la nivelul comunicării digitale cu alte sisteme informatice ar consta de fapt în proiecte adiacente, cu finanţare separată, care să traducă limbajul standardelor de interoperabilitate folosite de Spitalul Filantropia ... în standardele de interoperabilitate universale, folosite de orice sistem informatic.
Chiar şi în cazul excepţional în care vreunul dintre standardele de interoperabilitate solicitate în caietul de sarcini, de tipul HL7 sau echivalente, ar îndeplini rolul asigurării interoperabilităţii sistemelor informatice, în opinia sa, ... nu are autoritatea de a lua o astfel de decizie cu importanţă strategică naţională, aceasta aparţinând exclusiv Ministerului Sănătăţii. Acesta însă nu se confruntă cu o problemă de interoperabilitate la nivelul sistemelor informatice deoarece acestea deja folosesc metode de interoperabilitate consacrate, de tipul celor enumerate anterior: web-serices, XML, CSV, XLS, SQL. Atât Ministerul Sănătăţii cât şi unităţile subordonate au implementat şi comunicat tuturor spitalelor metodele, tiparele digitale şi standardele care trebuiesc respectate în transferul de informaţii electronice inter-instituţionale şi au confirmat că acestea operează cu succes; exemple: raportările DRG, ŞIUI, etc., nu folosesc niciunul dintre standardele de interoperabilitate expuse în caietul de sarcini, ci limbaje universal valabile care permit comunicarea inclusiv cu sisteme informatice externe Ministerului Sănătăţii.
Din perspectiva acestui proiect, a proiectelor e-sănătate în special, dar şi a proiectelor informatice în general, contestatoarea solicită eliminarea oricăror referinţe la standarde de interoperabilitate izolate de tipul HL7 sau echivalente, care, în opinia sa, nu au nicio legătură cu interoperabilitatea sistemelor informatice în sensul tehnic urmărit de orice Beneficiar raţional care îşi doreşte o soluţie
informatică sigură, deschisă şi liberă în comunicarea cu orice alt sistem informatic modern, nu numai dintr-un anumit domeniu.
În concluzie, având în vedere că elementele de mai sus au un rol determinant în conceperea unei oferte care să acopere necesarul real al autorităţii contractante, contestatoarea consideră imperios necesară rescrierea documentaţiei de atribuire în vederea respectării principiilor elementare care stau la baza reglementărilor din materia achiziţiilor publice.
Pentru motivarea în drept a contestaţiei, autoarea acesteia invocă dispoziţiile art. 7, art. 8 şi art. 11 din HG nr. 925/2006, precum şi cele ale „art. 355”, art. 36, art. 178, art. 188, art. 2562 şi ale art. 270 din OUG nr. 34/2006 cu modificările şi completările ulterioare, aplicabile în cauză.
De asemenea, prin contestaţia nr. ... înregistrată la CNSC sub nr. ...
... atacă documentaţia de atribuire aferentă procedurii în discuţie, considerând că aceasta nu respectă dispoziţiile legale aplicabile.
Raportat la obiectivul major al proiectului (aşa cum reiese din caietul de sarcini), respectiv la eficientizarea actului medical şi îmbunătăţirea serviciilor asigurate de către spital şi oferirea unei game largi de servicii spitaliceşti şi de ambulator pentru aproximativ
770.000 de persoane de pe teritoriul „judeţului ...”, prin implementarea unei soluţii informatice integrate de e-sănătate, contestatoarea apreciază că între criteriul de atribuire ales de către autoritatea contractantă şi obiectivul specific declarat prin caietul de sarcini există o „inconsistenţă majoră”.
În argumentarea afirmaţiei sale, contestatoarea enumeră o serie de aspecte, respectiv:
- „scopul principal al operaţiunii în cadrul căreia s-a obţinut finanţarea constă în dezvoltarea serviciilor medicale ...: reducerea reală a costurilor interne; reducerea timpului de prelucrare a datelor medicale; creşterea numărului persoanelor fizice care vor avea acces la servicii medicale informatizate; creşterea numărului personalului medical instruit pentru folosirea sistemelor informatice de e-sănătate;
- în cadrul etapei de evaluare tehnică şi financiară se verifică inclusiv aspecte ce ţin de: supraestimarea costurilor eligibile sau a necesarului; proiectul nu contribuie la realizarea obiectivelor axei prioritare şi ale domeniului major de intervenţie; analiza financiară greşit efectuată şi lipsa relevanţei rezultatelor acesteia;
- conform mecanismului fondurilor structurale, diferenţa de preţ rezultată din preţul final la care se realizează achiziţiile din cadrul proiectului şi estimarea cuprinsă devizul acestuia (pe baza căruia s- a realizat şi finanţarea proiectului), nu poate profita în niciun fel autorităţii contractante, rambursarea cheltuielilor realizându-se pe baza documentelor justificative;
- criteriul de atribuire reprezintă un set de factori cuantificabili care fac diferenţa între 2 oferte admisibile. Conform dispoziţiilor art. 198 din ordonanţă, criteriul de atribuire poate fi preţul cel mai scăzut sau oferta cea mai avantajoasă din punct de vedere economic.
În concluzie, întrucât criteriul de atribuire este „preţul cel mai scăzut”, în opinia sa, rezultă următoarele ipoteze:
- fie la scrierea proiectului s-a realizat o supraestimare a costurilor eligibile sau a necesarului;
- fie analiza financiară a fost greşit efectuată însă, având în vedere totuşi că proiectul a fost declarat câştigător, cele două ipoteze nu sunt posibile, motiv pentru care susţinem că alegerea criteriului de atribuire nu este întemeiată şi corelată cu obiectivele pe care autoritatea contractantă şi le-a propus.
În susţinerea argumentelor sale, prezintă o serie de alegaţii, solicitând „constatarea inconsistenţei şi lipsei de temeinicie a criteriului de atribuire ales”, sens în care solicită anularea procedurii de achiziţie publică.
În continuare, contestatoarea arată că unele din cerinţele minime privind arhitectul de sistem sunt restrictive şi nu prezintă relevanţă în raport cu atribuţiile sale în cadrul proiectului, respectiv:
- Cunoştinţe privind managementul serviciilor IT, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional;
- Cunoştinţe privind controlul şi/sau managementului riscurilor în sistemele informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional;
- Cunoaşterea aprofundată a unei metodologii recunoscute naţional/ internaţional de auditare, control şi evaluare a securităţii sistemelor informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional.
În acest asens, arată că, potrivit caietului de sarcini, rolul arhitectului de sistem este de a detalia cerinţele şi specificaţiile rezultate în faza de analiză, de a proiecta soluţia tehnică, de a pregăti planul privind etapele de dezvoltare, configurare, implementare pentru a obţine un sistem operaţional, de a confirma cerinţele operaţionale ale proiectului.
În opinia sa, certificările solicitate nu au relevanţă în raport de sarcinile acestuia având în vedere că specialistul propus nu va desfăşura în cadrul proiectului: activităţi privind managementul serviciilor IT; activităţi privind managementul riscurilor în sistemele informatice; activităţi privind auditul, controlul şi evaluarea securităţii sistemelor informatice; acestea fiind în sarcina coordonatorului tehnic, a analistului, a expertului de calitate, respectiv de securitate şi testare.
Drept urmare, contestatoarea solicită eliminarea cerinţelor referite mai sus.
Pe de altă parte, contestatoarea arată că, prin caietul de sarcini, la cap. 3.2.1.1.4. - Gestiunea electronică a activităţilor medicale, se solicită ca sistemul informatic să asigure interoperabilitatea cu HL7
„Sistemul va permite crearea de cereri electronice de analize medicale (...)”.
În opinia contestatoarei, cerinţa autorităţii contractante este restrictivă şi excesivă, având în vedere următoarele considerente:
- HL7 (Health Level Seven) este numele unui set de bune practici aparţinând unei organizaţii voluntare non-profit americane, American National Standards Institute (ANSI), al cărei scop principal este de a contribui la îmbunătăţirea confortului de viaţă american şi creşterea competitivităţii produselor americane pe piaţă, prin facilitarea şi promovarea implicării la nivelul standardizării în anumite sectoare şi a respectării integrităţii acestora (i.e. standarde);
- în secundar, Asociaţia are ca scop şi promovarea internaţională a acestor standarde/practici americane;
- principiul după care se ghidează activitatea de standardizare dezvoltată de către Asociaţie este cel de „openness”, ghidurile/ standardele emise fiind „open” - deschise schimbărilor/ completărilor/adnotărilor/modificărilor, în sensul că organizaţia promovează un proces de elaborare colaborativ, consensual;
- ANSI nu este o instituţie recunoscută la nivel naţional şi/sau internaţional ca având atribuţii în domeniul elaborării de coduri de bună practică/ghiduri/recomandări/standarde în domeniul medical, nefiind, prin urmare, un organism public/privat recunoscut pentru emiterea de standarde europene de certificare;
- „art. 35 xxxx. (6) lit. a) şi f)” din ordonanţă.
În acest sens, arată că HL7 nu îndeplineşte niciuna din condiţiile enunţate de legiuitor; folosirea menţiunii „sau echivalent” se face doar în legătură cu documente care îndeplinesc condiţiile de la art. 35 alin. (6).
Pentru aceste motive, contestatoarea solicită obligarea autorităţii contractante la eliminarea oricăror referiri la HL7.
În drept, contestatoarea îşi întemeiază cererea pe dispoziţiile art. 255, precum şi pe cele ale art. 270 şi următoarele din OUG nr. 34/2006, precum şi celelalte texte de lege menţionate în cuprinsul prezentei.
Prin adresele xx. 20081/04.12.2013, respectiv nr. 20269/ 06.12.2013, înregistrate la CNSC sub nr. 41835 şi nr. 41987 din 06.12.2013, autoritatea contractantă a transmis Consiliului punctele de vedere la cele două contestaţii, copia dosarului achiziţiei publice aferente procedurii atacate fiind înaintată Consiliului prin adresa înregistrată la CNSC sub nr. 42150/ 09.12.2013.
Raportându-se la criticile contestatoarelor, autoritatea contractantă precizează că, la impunerea cerinţelor minime obligatorii pentru arhitectul de soluţie, a avut în vedere necesităţile stringente pe care intenţionează a le satisface prin implementarea proiectului, definite esenţial prin caietul de sarcini. Astfel, „obiectivul general este reprezentat de creşterea calităţii actului medical prin punerea la dispoziţia cetăţenilor din regiunea deservită de ... a serviciilor integrate de sănătate prin implementarea de sisteme, servicii şi aplicaţii e-sănătate şi gestionarea eficientă a principalelor fluxuri de activităţi şi informaţii din cadrul spitalului”. Cerinţele din fişa de date a achiziţiei au fost stabilite cu respectarea dispoziţiilor art. 5 alin. (2), art. 188 alin. (2) lit. d) din OUG nr. 34/2006, ale art. 24 din Instrucţiunile ANRMAP nr. 1/2013 emise in aplicarea prevederilor art. 188 alin. (2) lit. d) şi art. 188 alin. (3) lit. c), precum şi ale art. 7 din HG nr. 925/2006.
În acest sens, susţine că, aşa cum este prezentat şi în caietul de sarcini, la Cap. 4.1.1. Personal implicat în realizarea/implementarea proiectului, arhitectul de sistem are ca roluri, în cadrul proiectului, detalierea cerinţelor şi specificaţiilor rezultate în faza de analiză, proiectarea soluţiei tehnice, pregătirea planului privind etapele de dezvoltare, configurare, implementare pentru a obţine un sistem operaţional, conform cerinţelor operaţionale ale proiectului.
În opinia sa, cerinţele pentru acest expert contestate sunt, în fapt, pe deplin justificate şi absolut necesare pentru asigurarea nivelului optim de calitate a sistemului ce urmează a fi realizat.
De asemenea, precizează că sistemul, ce urmează a fi implementat, trebuie să răspundă cerinţelor de audit, control şi evaluare de securitate informatică. Prin urmare, pentru a proiecta un sistem ce va fi suspus unor astfel de proceduri în conformitate cu cerinţele specifice, este evidentă necesitatea deţinerii de către arhitectul de sistem de cunoştinţe privind controlul şi/sau managementul riscurilor în sistemele informatice, precum şi a cunoştinţelor în audit, control şi evaluare a securităţii sistemelor informatice.
Din acest considerent, arată că sistemul trebuie să respecte standardele de securitate şi confidenţialitate a informaţiilor, de prelucrare a datelor cu caracter personal conform Legii nr. 677/ 2001 pentru protecţia persoanelor cu privire la prelucrarea datelor cu caracter personal şi libera circulaţie a acestor date, cu modificările şi completările ulterioare şi conform Legii nr. 506/2004 privind prelucrarea datelor cu caracter personal şi protecţia vieţii private în sectorul comunicaţiilor electronice, cu modificările şi completările ulterioare.
Deţinerea de către expertul, care proiectează această soluţie tehnică, de cunoştinţe privind controlul şi/sau managementului riscurilor în sistemele informatice, precum şi de cunoştinţe de audit,
control şi evaluare a securităţii sistemelor informatice este în mod evident o condiţie absolut necesară pentru asigurarea nivelului optim de calitate a soluţiei propuse din punct de vedere a securităţii acesteia.
Astfel, autoritatea contractantă consideră ca fiind pe deplin justificate cerinţele sus-amintite, pentru ducerea la bun sfârşit a sarcinilor ce îi revin acestui expert în cadrul proiectului.
În condiţiile în care certificările solicitate expertului arhitect de soluţie vizează îndeplinirea contractului, având legătură indisolubilă cu obiectul acestuia, fără a fi în vreun fel disproporţionată, având în vedere că acesta are rolul de a detalia cerinţele şi specificaţiile rezultate în faza de analiză, proiectează soluţia tehnică, pregăteşte planul privind etapele de dezvoltare, configurare, implementare pentru o obţine un sistem operaţional, confirmă cerinţele operaţionale ale proiectului, iar la impunerea cerinţei respective s- au respectat rigorile impuse prin art. 24 din Instrucţiunile ANRMAP nr. 1/2013 şi din actele normative din domeniul achiziţiilor publice, autoritatea contractantă solicită a se constata solicitarea contestatoarelor ca fiind neîntemeiată, impunându-se a se dispune respingerea acesteia în consecinţă.
Cu privire la solicitarea cerinţei „Certificare pe un standard de interoperabilitate în domeniul medical” pentru expertul interoperabilitate, autoritatea contractantă invocă prevederile art. 5 alin. (2), art. 188 alin. (2) lit. d) din OUG nr. 34/2006, ale art. 24 din Instrucţiunile ANRMAP nr. 1/2013 emise in aplicarea prevederilor art. 188 alin. (2) lit. d) şi art. 188 alin. (3) lit. c), precum şi ale art. 7 din HG nr. 925/2006 şi pe cele ale art. 331 alin.
(1) din OUG nr. 34/2006.
Coroborat cu rolul pe care acesta îl are în cadrul proiectului (de realizare a capabilităţilor de interoperare ale soluţiilor, de elaborare a documentelor de arhitectură şi design folosind standardul de interoperabilitate care este folosit, etc.) şi prevederile art. 177 alin.
(2) din OUG nr. 34/2006, autoritatea contractantă solicită Consiliului să constate netemeinicia cererii formulate de către contestatoare şi respingerea acesteia.
Referitor la critica privind specificaţiile din caietul de sarcini, cap.
3.5.3.2. - Sistem de gestiune a bazelor da date („Baza de date relaţională trebuie să permită salvarea online a bazei de date direct pe bandă”, „Baza de date relaţională trebuie să permită o restaurare a bazei de date direct de pe bandă”), autoritatea contractantă o consideră ca fiind întemeiată şi, în consecinţă, va posta în SEAP un document în sensul precizării faptului că se vor elimina cerinţele referitoare la aspectele sesizate de către contestatoare.
În acest context, autoritatea contractantă solicită Consiliului să constate ca rămasă fără obiect critica contestatoarei.
În continuare, autoritatea contractantă susţine că necesitatea unor module destinate pentru realizarea activităţilor de transfuzie sanguină, rezidă din existenţa în cadrul spitalului a unui Centru de transfuzie sanguină (prevăzut în structura organizatorică a spitalului), a unor secţii de tip chirurgical (obstetrică, ginecologie, etc.) şi a unor secţii ATI (în care se efectuează transfuzii).
În acest context, autoritatea contractantă solicită Consiliului respingerea criticii contestatoarei ca fiind neîntemeiată şi respingerea acesteia.
În ceea ce priveşte critica referitoare la organizarea unei sesiuni demonstrative, autoritatea contractantă precizează că organizarea unei sesiuni demonstrative are rolul de a asigura îndeplinirea în bune condiţii a contractului de către un operator economic competent, iar modul în care a fost detaliată în conţinutul caietului de sarcini, respectă fluxurile de lucru specifice activităţii la nivel de spital, fiind în concordanţă cu cerinţele minime funcţionale corespunzătoare.
Totodată, prin organizarea acestei sesiuni, se asigură respectarea, faţă de operatorii economici participanţi, a principiului tratamentului egal, conform dispoziţiilor art. 2 alin. (2) lit. b) din OUG nr. 34/2006, asigurând acestora şanse egale de a dovedi că au capacitatea de îndeplinire a contractului în cauză, având ca punct de reper, specificul şi complexitatea acestuia.
Toate funcţionalităţile componentelor care vor face obiectul sesiunii demonstrative sunt detaliate în cadrul a trei scenarii bine definite în cap. 11 al caietului de sarcini, astfel consideră că probarea funcţionării şi eficienţei în operare a soluţiilor ofertate, în conformitate cu cerinţele caietului de sarcini, drept elemente de importanţă majoră în evaluarea ofertelor, obiectul contractului prezentei achiziţii fiind de furnizare soluţii informatice pentru realizarea şi implementarea unui sistem informatic integrat şi asigurarea unor servicii aferente acestora.
De asemenea, în caietul de sarcini la cap. 11 Organizarea unei sesiuni demonstrative, în cadrul scenariilor foarte multe operaţiuni pe care operatorii economici participanţi le vor efectua demonstrativ, sunt însoţite de menţiunile „se va prezenta modalitatea (...)”, „se va prezenta modul (...)”, „se va exemplifica (...)”, astfel încât fiecare operator economic va avea posibilitatea demonstrării modalităţii de îndeplinire a „cerinţelor funcţionale” existente ale sistemului integrat propus de fiecare operator economic în propunerea tehnică, nu a unor componente care ar urma să fie dezvoltate.
În acest sens, autoritatea contractantă solicită Consiliului respingerea solicitării contestatoarei de elimnaren a sesiuni demonstrative, ca fiind neîntemeiată.
Referitor la critica privind utilizarea unor „standarde de interoperabilitate", autoritatea contractantă face următoarele precizări:
- HL7 (Health Level Seven) este numele unui set de standarde ANSI care se referă la comunicaţia prin mesaje între aplicaţiile informatice medicale care operează cu date clinice şi administrative (xxxx://xxx. xx0xxxxxxx.xx/0xxxx id—241);
- pe site-ul oficial al Casei Naţionale de Asigurări de Sănătate (CNAS) se poate citi următorul comunicat de presă: (xxxx://xxx.xxxx.xx/ mass-media/comunicate-de-presa/comunicat- cnas-si-uti-au-semnat-contractul-pentru-dosarul-electronic-de- sanatate): „Casa Naţională de Asigurări de Sănătate (CNAS) şi UTI România au semnat joi, 28 martie 2013, contractul privind implementarea sistemului informatic integrat pentru Dosarul Electronic de Sănătate (DES), care reuneşte întreg tabloul clinic al pacienţilor asiguraţi, sprijinind astfel corectitudinea deciziei medicale bazate pe informaţii corelate din surse diferite, dar disponibile în timp real (on-line) şi securizat”.
Aşa cum reiese, în mod clar, din acest comunicat oficial, în prezent se pune accent deosebit pe interoperabilitatea cu alte sisteme informatice folosind standarde deschise din domeniul sănătăţii, precum HL7.
Autoritatea contractantă menţionează următoarele:
- „Noul sistem va integra datele medicale relevante despre fiecare asigurat, oferind astfel o bază necesară în decizia actului medical.
- Complexitatea proiectului este tehnologică (prin furnizarea de servicii on-line pentru asiguraţi şi prestatorii de servicii medicale, cu un grad ridicat de securitate, disponibilitate şi confidenţialitate a datelor), medicală (prin agregarea datelor medicale relevante provenite din surse multiple), cât şi organizaţională (prin colaborarea prestatorilor de servicii de sănătate publică din România)”.
Din comunicat reiese, aşadar, necesitatea ca prestatorii de servicii de sănătate publică să colaboreze cu Casa Naţională de Asigurări de Sănătate în vederea completării cu informaţie medicală a dosarelor electronice ale pacienţilor asiguraţi din România. Utilizarea acestui standard în cadrul unui proiect major la nivel naţional din domeniul sănătăţii face evident faptul ca utilizarea unor standarde deschise din domeniul sănătăţii, precum HL7, face parte din strategia României.
Proiectul Dosarul Electronic de Sănătate (DES) este primul din România de o asemenea complexitate şi printre puţinele implementate la nivel european, în domeniul sănătăţii. „Dosarul Electronic, co-finanţat prin fonduri europene, reprezintă o nouă verigă în demersurile de informatizare a serviciilor oferite de CNAS.
Noul sistem va integra datele medicale relevante despre fiecare asigurat, oferind astfel o bază necesară în decizia actului medical”, (extras din declaraţia oficială a Preşedintelui CNAS).
„Dosarul Electronic de Sănătate va asigura:
- consolidarea datelor clinice ale pacientului, care acoperă, pentru fiecare pacient, întreaga durată de viaţă a acestuia;
- suportul pentru livrarea exactă, completă şi la timp a informaţiilor printr-un sistem permanent online;
- asigurarea accesului privat şi securizat la datele puse la dispoziţie în DES prin intermediul infrastructurii cardului de sănătate;
- soluţie scalabilă şi extensibilă care va permite creşterea continuă, extensivă a informaţiilor clinice stocate;
- interoperabilitatea cu alte sisteme folosind standarde deschise;
- utilizarea standardelor deschise în domeniul sănătăţii, precum HL7”.
În consecinţă, cerinţele referitoare la anumite „standarde de interoperabilitate” au fost introduse tocmai în ideea de a putea garanta o comunicare eficientă cu sistemele electronice naţionale de sănătate.
Astfel, autoritatea contractantă solicită constatarea criticii ca fiind neîntemeiata şi, în consecinţă, respingerea acesteia.
În continuare, autoritatea contractantă precizează că la alegerea criteriului de atribuire s-a ţinut cont de prevederile art. 197, art.
198 din OUG nr. 34/2006, precum şi de cele ale art. 13 şi art. 15 alin. (2) şi (3) din HG nr. 925/2006.
În contextul celor expuse mai sus, autoritatea contractantă solicită Consiliului să respingă critica contestatoarei privind alegerea criteriului de atribuire, ca fiind neîntemeiata şi să constate că nu sunt întrunite condiţiile pentru anularea procedurii, în condiţiile în care au fost respectate prevederile legale în domeniul achiziţiilor publice.
Făcând aplicarea prevederilor art. 273 alin. (1) din OUG nr. 34/2006, după conexarea celor două contestaţii, din analiza susţinerilor părţilor şi a documentelor existente la dosarul cauzei, Consiliul reţine cele ce urmează:
Pentru atribuirea contractului de achiziţie publică având ca obiect
„Aplicaţii informatice de management al resurselor economico- financiare”, cod CPV 48000000-8 – Pachete software şi sisteme informatice (Rev.2), 32420000-3 – Echipament de reţea (Rev.2), 48820000-2 – Servere (Rev.2), 72268000-1 – Servicii de furnizare
de software (Rev.2), 80530000-8 – Servicii de informare profesională (Rev.2), ... (în calitate de autoritate contractantă), a iniţiat procedura, licitaţie deschisă cu etapă finală de licitaţie electronică, prin publicarea în SEAP a anunţului de participare nr. ...
din data de 23.11.2013, odată cu care a postat şi documentaţia de atribuire.
Nemulţumite de prevederile documentaţiei de atribuire, pe care le consideră nelegale, ... şi ... au învestit Consiliul cu soluţionarea prezentelor contestaţii, solicitând suspendarea procedurii, modificarea respectivelor cerinţe sau anularea procedurii de atribuire.
Fiind îndeplinite condiţiile cumulative de admisibilitate a unor cereri de suspendare, regăsite la art. 2751 alin. (1) şi (2) din OUG nr. 34/2006, Consiliul a admis cererile contestatoarelor de suspendare a procedurii de atribuire iniţiate prin publicarea anunţului de participare nr. ... din 23.11.2013 şi a dispus suspendarea acesteia până la soluţionarea cauzelor pe fond (Decizia nr. ... din ...
În ceea ce priveşte afirmaţia operatorului economic aferentă
arhitectului de sistem, conform căreia următoarele cerinţe: Cunoştinţe privind controlul şi/sau managementului riscurilor în sistemele informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional, respectiv: Cunoaşterea aprofundată a unei metodologii recunoscute naţional/internaţional de auditare, control şi evaluare a securităţii sistemelor informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional, sunt nejustificate, Consiliul reţine ca fiind întemeiată.
În aprecierea acestei finalităţii, Consiliul are în vedere faptul că, în fişa de date, la cap. III.2.3.a) – Capacitatea tehnică şi/sau profesională, rubrica – Personal de specialitate, pentru poziţia arhitect sistem, se solicită, printre altele: „Experienţă specifică de minim 3 ani în calitate de arhitect sistem; Cunoştinţe în domeniul arhitecturii enterprise, dovedite prin certificare/diplomă profesională, recunoscută la nivel naţional/internaţional; Cunoştinţe privind managementul serviciilor IT, dovedite prin certificare/ diplomă, recunoscută la nivel naţional/internaţional”.
Astfel că, în opinia Consiliului, cerinţele în discuţie nu sunt necesare, fiind suficientă experienţa specifică de minim 3 ani, în calitate de arhitect sistem, precum şi deţinerea de cunoştinţe în domeniul arhitecturii enterprise şi în managementul serviciilor IT, dovedite prin prezentarea de certificate/diplome recunoscută la nivel naţional/ internaţional.
De asemenea, referitor la solicitarea: cunoaşterea aprofundată a unei metodologii recunoscute naţional/internaţional de auditare, control şi evaluare a securităţii sistemelor informatice, Consiliul constată că autoritatea contractantă a cerut deja, în cadrul aceluiaşi
capitol al fişei de date, şi un expert securitate şi testare, care trebuie să îndeplinească condiţii similare legate de calificarea profesională.
Ori, în condiţiile în care acest expert face parte din echipa propusă şi lucrează împreună cu ceilalţi experţi pentru derularea contractului în cauză şi trebuie să deţină, printre altele, „cunoştinţe privind securitatea reţelelor (inclusiv VPN), securitatea în baze de date şi securitatea sistemelor de operare, dovedite prin certificare/diplomă, emise de organise recunoscute naţional/internaţional”, apare ca nejustificată cerinţa ca şi arhitectul de proiect să deţine certificări/ diplome în acest sens.
Mai mult, în punctul său de vedere, nr. 20081/04.12.2013, înregistrat la CNSC sub nr. 41785/... autoritatea contractantă invocă, printre altele, art. 188 alin. (2) lit. d) din OUG nr. 34/2006, normă legală care prevede următoarele: „În cazul aplicării unei proceduri pentru atribuirea unui contract de servicii, în scopul verificării capacităţii tehnice şi/sau profesionale a ofertanţilor/candidaţilor, autoritatea contractantă are dreptul de a le solicita acestora, în funcţie de specificul, de volumul şi de complexitatea serviciilor ce urmează să fie prestate şi numai în măsura în care aceste informaţii sunt relevante pentru îndeplinirea contractului, următoarele: ... informaţii referitoare la studiile, pregătirea profesională şi calificarea personalului de conducere, precum şi ale persoanelor responsabile pentru îndeplinirea contractului de servicii”.
Ori, această normă legală, coroborat cu art. 7 şi art. 8 alin. (1) din HG nr. 925/2006, prevăd faptul că autoritatea contractantă, atunci când stabileşte criteriile de calificare şi selecţie, trebuie să ţină cont că acestea trebuie, pe de o parte, să reflecte potenţialul ofertanţilor de a îndeplini contractul ce urmează a fi încheiat, iar, pe de altă parte, de a nu restricţiona participarea operatorilor economici interesaţi.
Referitor la solicitarea contestatoarei ... de eliminare a cerinţei
„certificare pe un standard de interoperabilitate în domeniul medical”, aferentă Expertului interoperabilitate, Consiliul o admite, motivat de faptul că, pentru această poziţie s-a solicitat să se demonstreze „experienţa în cadrul a cel puţin un proiect având ca obiect implementarea de sisteme informatice integrate în calitate de expert interoperabilitate”.
Prin urmare, cerinţa ca respectivul expert să fie certificat pe un
standard de interoperabilitate în domeniul medical devine abuzivă. De altfel, chiar norma legală invocată de însăşi autoritatea contratantă, respectiv art. 24 din Instrucţiunile ANRMAP nr. 1/2013, prevede faptul că: „Pentru specialiştii pentru care se solicită anumite certificate privind perfecţionarea profesională/formarea
profesională, ce nu sunt obligatorii în baza unui act normativ, autoritatea contractantă poate solicita experienţă specifică, dar nu poate impune ca aceasta să fie realizată în calitatea deţinută ca urmare a perfecţionării/formării”. Xxx, tocmai solicitarea prezentării unui proiect, în calitate de expert interoperabilitate, probează faptul că respectiva persoană are cunoştinţe în acest domeniu.
În ceea ce priveşte cererea contestatoarei de eliminare, din cadrul capitolului 3.5.3.2 – Sistem de gestiune a bazelor de date, din caietul de sarcini, a cerinţelor: Baza de date relaţională să permită salvarea online a bazei de date direct pe bandă, respectiv Baza de date relaţională să permită o restaurare a bazei de date direct de pe band, Consiliul constată că este rămasă fără obiect.
În acest sens, Consiului are în vedere faptul că, ulterior contestaţiei în cauză, autoritatea contractantă, în temeiul art. 256³ alin. (1) din OUG nr. 34/2006, a publicat pe SEAP, în data de 06.12.2013, Măsura de remediere, constând în „eliminarea din caietul de sarcini a următoarelor specificaţii tehnice (...):Baza de date relaţională să permită salvarea online a bazei de date direct pe bandă, Baza de date relaţională să permită o restaurare a bazei de date direct de pe band”.
În ceea ce priveşte solicitarea contestatoarei de eliminare a oricăror referinţe la modulul Banca de sânge, pe motiv că această/acest secţie/departament este inexistentă/inexistent, Consiliul o respinge ca neîntemeiată, deoarece, pe de o parte, în cadrul spitalului se află Centrul de transfuzie sanguină, ce necesită informaţii aferente transpuse electronic şi care poate fi dezvoltat ulterior, iar pe de altă parte, dispoziţiile art. 35 alin. (2) din OUG nr. 34/2006 prevăd următoarele: „Specificaţiile tehnice reprezintă cerinţe, prescripţii, caracteristici de natură tehnică ce permit fiecărui produs, serviciu sau lucrare să fie descris, în mod obiectiv, în aşa manieră încât să corespundă necesităţii autorităţii contractante.”
În aceste condiţii, Consiliul apreciază ca fiind neconcludentă afirmaţia contestatoarei, conform căreia autoritatea contractantă nu este organizată ca o Bancă de sânge, nepublicând nici o informaţie în acest sens, decât în momentul postării documentaţiei de atribuire, pe SEAP, întrucât acest aspect nu împiedică dorinţa achiziţionării unor servicii informatice complexe, cu atât mai mult cu cât, în caietul de sarcini, la cap. 3.2.1.2.1 – Sistemul de laborator, pentru componenta Banca de sânge, sunt prezentate informaţiile necesare pe baza cărora operatorii economici pot să-şi întocmească oferta.
Referitor la critica privind cap. 11 – Organizarea unui sesiuni demonstrative, din caietul de xxxxxxx, în sensul existenţei doar a 3 scenarii, Consiliul apreciază că este întemeiată solicitarea autoarei contestaţiei de eliminarea a acestei sesiuni demonstrative.
În aprecierea acestei finalităţi, Consiliul are în vedere faptul că la cap. III.2.3.a) – Capacitatea tehnică şi/sau profesională, pentru Experienţa similată, se solicită, printre altele: „Ofertantul trebuie să demonstreze că a furnizat/prestat în ultimii 3 ani, în baza a cel puţin un contract de furnizare de pachete software şi sisteme informatice (harware, aplicaţii, portal) de complexitate similară, în valoare cumulată de minim 930.000 lei, fără TVA”.
De asemenea, la acelaşi capitol, la rubrica Personal de specialitate autoritatea contractantă impune, pentru derularea acestei achiziţii, un număr de 8 specialişti (manager proiect, coordonator tehnic, arhitect sistem, expert analist, ... baze de date, expert interoperabilitate, expert securitate şi testare, expert calitate), cu atribuţii clare şi certificări adecvate, precum şi încă 3 specialişti care fac parte din echipa de implementare şi 2 specialişti ce constituie echipa de instruire.
Xxx, ţinând cont de cerinţele de mai sus, Consiliul apreciază că acestea permit demonstrarea capabilităţii unui ofertant de realizare a unui asemenea contract de servicii, astfel că nu mai este necesară menţiunea: „autoritatea contractantă îţi rezervă dreptul de a organiza o sesiune demonstrativă ...”, întrucât solicitarea în cauză încalcă principiul proporţionalităţii, prevăzut de art. 2 alin. (2) lit. e) din OUG nr. 34/2006.
O altă critică a contestatoarei se referă la faptul că, în caietul de sarcini, apar referinţe la utilizarea unor standarde de interoperabilitate (HL sau echivalent etc.), care, în opinia sa, abordarea unui astfel de standard, submulţime a standardelor universale de comunicare IT, chiar şi la un nivel simplist, de către un sistem informatic, conduce la restrângerea capacităţii de comunicare a sistemului cu alte sisteme informatice, respectiv la restrângerea participării operatorilor economici care pot folosi alte metode de interoperabilitate consacrate: „web-services, XML, CSV, XLS, SQL”.
Potrivit informaţiilor de specialitate, standardele HL7 facilitează comunicarea între diferite tipuri de aplicaţii software din sistemul informatic medical. El asigură suportul necesar în schimbul de mesaje referitor la: managementul pacienţilor (internarea, completarea datelor personale, istoricul medical, transferul, externarea, etc.), programarea pacienţilor pe resursele disponibile, costurile actului medical, observaţii clinice, rezultate de laborator, diagnosticul stabilit, tratamente administrate, transferul de documente medicale.
Din analiza conţinutului caietului de sarcini, Consiliul constată că autoritatea contractantă face trimitere la acest standard (ex. cap.
3.4.4 – Standardizare - „Soluţia tehnică propusă va avea la baza
standarde şi protocoale de comunicaţie specifice domeniului medical ( ex. HL7, DICOM)”.
De asemenea, la acelaşi capitol, se regăsesc şi trimiteri la standardele Web-Services, XML (standarde indicate de contestatoare), precum şi alte standarde: SSH, HTTPS, LDAP, SSO. În aceste condiţii, pentru a se asigura o participare cât mai largă la această procedură de atribuire a operatorilor economici din domeniu, pentru respectarea principiului transparenţei, consacrat de art. 2 alin. (2) lit. d) din OUG nr. 34/2006 şi a dispoziţiilor art. 35 alin. (5) din OUG nr. 34/2006, Xxxxxxxxx apreciază că autoritatea contractantă trebuie fie să accepte orice soluţie informatică care să asigure interoperabilitatea între sistemele informatice, fie să elimine orice referire la standardul de interoperabilitate HL7 sau echivalent. În ceea ce priveşte contestaţia aparţinând ... Consiliul constată că una din critici se referă la modul în care autoritatea contractantă a ales criteriul de atribuire la acestei proceduri, respectiv: preţul cel mai scăzut.
Referitor la acest aspect, Consiliul nu reţine ca fiind întemeiată solicitarea contestatoarei de anulare a procedurii de atribuire în cauză, pe motiv că între acest criteriu de atribuire şi obiectivul specific declarat prin caietul de sarcini există o inconsistenţă majoră, deoarece, pe baza principiului asumării răspunderii, prevăzut la art. 2 alin. (2) lit. g) OUG nr. 34/2006, coroborat cu art. 197 din acelaşi act normativ „autoritatea contractantă are obligaţia de a preciza în anunţul de participare criteriul de atribuire a contractului de achiziţie publică, care, odată stabilit, nu poate fi schimbat pe toată durata de aplicare a procedurii de atribuire”.
De altfel, dispoziţiile art. 198 alin. (1) lit. a) şi b) din ordonanţa de urgenţă, permit aplicarea următoarelor criterii de atribuire: „fie oferta cea mai avantajoasă din punct de vedere economic; fie, în mod exclusiv, preţul cel mai scăzut”, la alegerea autorităţii contractante.
Mai mult, Xxxxxxxxx constată că autoarea contestaţiei nu face trimitere în nici un fel la posibilitatea reală de a fi utilizat cel de-al doilea criteriu de atribuire permis de lege, respectiv oferta cea mai avantajoasă din punct de vedere economic.
Asupra criticilor aferente poziţiei Arhitect de sistem, privind cerinţele
„Cunoştinţe privind controlul şi/sau managementului riscurilor în sistemele informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional, respectiv: Cunoaşterea aprofundată a unei metodologii recunoscute naţional/internaţional de auditare, control şi evaluare a securităţii sistemelor informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional”, precum şi asupra standardului HL7, Consiliul constată temeinicia lor,
pentru aceleaşi considerente expuse la soluţionarea contestaţiei formulate de către ....
De asemenea, Xxxxxxxxx reţine ca fiind întemeiată şi solicitarea contestatoarei de eliminare, tot pentru poziţia de Arhitect de sistem, şi a cerinţei: „Cunoştinţe privind managementul servicilor IT, dovedite prin certificare/diplomă, recunoscute la nivel naţional/ intrenaţional”, acesat fiind disproporţionată, având în vedere faptul că, pentru acelaşi specialit, s-au cerut deja: „Cunoştinţe în domeniul arhitecturii entreprise, dovedite prin certificare/diplomă, recunoscute la nivel naţional/internaţional”, aspecte care sunt suficiente în demonstrarea activităţii pe care acesta o va derula.
Luând în considerare aspectele de fapt şi de drept amintite, în baza art. 278 alin. (1), (2), (4) şi (6) din OUG nr. 34/2006, cu modificările şi completările ulterioare, Consiliul admite, în parte, contestaţiile formulate de ... şi de ... şi obligă autoritatea contractantă la continuarea procedurii de atribuire, în 10 zile de la primirea prezentei, prin modificarea documentaţiei de atribuire, în sensul următor:
• eliminarea, de la poziţia Arhitect sistem, a cerinţelor: :
„Cunoştinţe în domeniul arhitecturii entreprise, dovedite prin certificare/diplomă, recunoscute la nivel naţional/ internaţional, Cunoştinţe privind controlul şi/sau managementului riscurilor în sistemele informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional; Cunoaşterea aprofundată a unei metodologii recunoscute naţional/ internaţional de auditare, control şi evaluare a securităţii sistemelor informatice, dovedite prin certificare/diplomă, recunoscută la nivel naţional/internaţional” (cap. III.2.3.a) - Capacitatea tehnică şi/sau profesională);
• eliminarea, de la poziţia Expert interoperabilitate, a cerinţei:
„Certificare pe un standard de interoperabilitate în domeniul medical”;
• xxxxxxxxxx, din caietul de sarcini, a sesiunii demonstrative;
• precizarea, în caietul de sarcini, fie a acceptării oricărei soluţii informatice care să asigure interoperabilitatea între sistemele informatice, fie să elimine orice referire la standardul de interoperabilitate HL7 sau echivalent.
În temeiul dispoziţiilor de la alin. (5) al aceluiaşi art. 278 din ordonanţa de urgenţă, Consiliul respinge cererea ... de eliminare a modulului Banca de sânge, precum şi cererile implicite de anulare a procedurii de atribuire ale ambelor contestatoare, ca nefondate.
Pentru punerea în aplicare a dispoziţiilor prezentei, autoritatea contractantă va emite actele de completare a informaţiilor, pe care le va publica în SEAP, sub forma unui anunţ de tip erată, aşa cum este prevăzut la art. 26 alin. (1) din HG nr. 925/2006, coroborat cu
art. 50 alin. (3) din ordonanţa de urgenţă, şi va decala termenul actual de depunere a ofertelor cu o perioadă de cel puţin 15 zile.
Prezenta decizie este obligatorie pentru părţi, în conformitate cu dispoziţiile art. 280 alin. (1) şi (3) din OUG nr. 34/2006, cu modificările şi completările ulterioare şi poate fi atacată cu plângere, în temeiul art. 281 din acelaşi act normativ .
PREŞEDINTE COMPLET
...
MEMBRU COMPLET MEMBRU COMPLET
... ...
....