CAIET DE SARCINI

Autoritatea contractanta: Casa Nationala de Asigurari de Sanatate

Pagina 2

CUPRINSLista de Acronime 5

1. Introducere 7

1.1. Continutul achizitiei 7

1.2. Costul ofertei 8

1.3. Limba folosita pentru prezentarea ofertei 8

2. Obiectivele achizitiei 8

2.1. Obiective generale 8

2.2. Obiectivele specifice 9

3. Situația actuala 10

3.1. Beneficiarul investiției 10

3.2. Grupurile ținta 10

3.3. Beneficiile aduse grupurilor tinta 12

3.4. Cadrul legal 12

3.5. Cadrul institutional 13

3.6. Volumul tranzactiilor 16

4. Cerinte privind solutia tehnica 17

4.1. Scenarii de utilizare 18

4.1.1. Intocmirea prescriptiilor medicale 19

4.1.1.1. Tratarea exceptiilor 20

4.1.2. Eliberarea prescriptiilor medicale 21

4.1.2.1. Tratarea exceptiilor 21

4.2. Standarde 21

4.3. Cerinte privind arhitectura software a solutiei 22

4.3.1. Cerinte privind componenta aplicativa 23

4.3.1.1. Modulul central 23

4.3.1.2. Modulul prescriere 24

4.3.1.3. Modulul validare 24

4.3.1.4. Modulul eliberare 28

4.3.1.5. Extinderea sistemului SIUI 29

4.3.1.6. Modulul de integrare 29

4.3.1.7. Solutia de management a infrastructurii IT 30

4.3.2. Componente functionale 31

4.3.2.1. Administrare si monitorizare 31

4.3.2.2. Securitate informatica 32

4.3.2.3. Autentificare si autorizare 33

Pagina 2

4.3.2.4. Audit si control 33

4.3.2.5. Help-desk 33

4.3.3. Cerinte nefunctionale 34

4.3.3.1. Software de Gestiune a Bazelor de Date 34

4.3.3.2. Serverul de web 35

4.3.3.3. Software pentru serverul de aplicatie 36

4.3.3.4. Sistemul de management al regulilor de business 37

4.3.3.5. Solutia de management a infrastructurii IT 37

4.3.3.5.1. Managementul operational al infrastructurii si serviciilor 38

4.3.3.5.2. Monitorizarea sistemelor si a aplicatiilor 39

4.3.3.5.2.1. Componenta de monitorizare fara agenti 39

4.3.3.5.2.2. Componenta tablou de bord 39

4.3.3.5.2.3. Componenta diagnosticare aplicatii 40

4.3.3.5.3. Monitorizarea calitatii serviciilor 41

4.3.3.5.3.1. Managementul SLA-urilor 41

4.3.3.5.3.2. Monitorizarea serviciilor IT din perspectiva utilizatorilor finali 42

4.4. Cerinte privind platforma hardware si infrastructura de comunicatie 44

4.4.1. Precizari referitoare la platforma hardware si infrastructura de comunicatie 48

4.5. Cerinte privind managementul utilizatorilor si accesul la sistem 49

5. Cerinte de servicii 49

5.1. Cerinte privind ofertantul solutiei 49

5.2. Cerinte privind serviciile de implementare 49

5.3. Graficul de implementare 51

5.4. Cerinte privind serviciile de management de proiect 51

5.4.1. Implementarea proiectului 52

5.5. Cerinte privind instruirea 53

5.6. Cerinte privind serviciile de suport si mentenanta 54

5.6.1. Servicii de garantie 54

5.6.2. Servicii de suport pentru solutia informatica 54

5.6.3. Urmarirea incidentelor 55

5.6.4. Niveluri de Prioritate 56

5.6.5. Timpi de raspuns si rezolutii 56

6. Cerinte privind resursele umane 57

6.1. Director de proiect 59

6.2. Manageri de proiect 59

6.3. Arhitecti de solutie 60

6.4. Experti tehnici 61

Pagina 2

6.5. Experti software 61

6.6. Expert financiar 62

6.7. Responsabil calitate 62

6.8. Responsabil instruire 62

6.9. Specialist logistica 62

7. Cerinte privnd formatul ofertelor 62

8. Alte cerinte 63

9. Anexa 1- Functionalitati expuse de SIUI prin servicii web 65

9.1. Serviciul pentru sincronizarea nomenclatoarelor 65

9.2. Serviciul pentru sincronizarea datelor de personalizare 66

9.3. Serviciul pentru trimiterea raportărilor periodice 66

9.4. Serviciul pentru preluarea rezultatelor raportărilor periodice 67

9.5. Serviciul pentru preluarea decontului calculat în SIUI 67

9.6. Serviciul pentru consultarea cererilor şi a deciziilor 68

9.7. Serviciul pentru verificarea calității de asigurat 69

9.8. Serviciul pentru pre-validarea mișcărilor de capitație 69

9.9. Serviciul pentru pre-validarea serviciilor și investigațiilor medicale 70

9.10. Serviciul pentru pre-validarea rețetelor prescrise de medici 71

9.11. Serviciul pentru pre-validarea biletelor de trimitere emise de medici 72

9.12. Serviciul pentru pre-validarea certificatelor medicale emise de medici 72

9.13. Serviciul pentru pre-validarea reţetelor emise de farmacii 73

9.14. Serviciul pentru consultarea reţetelor prescrise 74

9.15. Serviciul pentru consultarea biletelor de trimitere 74

9.16. Matricea de acoperire a serviciilor Web 76

9.17. Pachet pentru dezvoltatori software 79

10. Anexa 2- Definitiile serviciilor web expuse de sistemul SIUI 79

Pagina 2

Lista de Acronime

Acronim Explicatie

CNAS Casa nationala de asigurari de sanatate

MS Ministerul Sanatatii

PE Prescriptia Electronica

FNUASS Fondul national unic de asigurari de sanatate

SIUI Sistemul informatic unic integrat al CNAS

TIC Tehnologia informatiei si a comunicatiei

WSDL Web Service Definition Language

XML Extensible Markup Language

DMZ Demilitarized Zone

SQL Structured Query Language

J2EE Java 2 Platform, Enterprise Edition

BRMS Business Rule Management System

BRE Business Rule Engine

SSL Secure Sockets Layer

CEAS Cardul Electronic de Asigurari de Sanatate

ANM Agentia Nationala a Medicamentului

HTTP Hypertext Transfer Protocol

HTTPS HTTP Secure

TCP Transmission Control Protocol

IP Internet Protocol

ANSI American National Standards Institute

SQL Structured Query Language

ISO International Organization for Standardization

IEC International Electrotechnical Comission

Pagina 2

DCI Denumirea Comuna Internationala

OCSP Online Certificate Status Protocol

PHP Hypertext Preprocessor

JSP JavaServer Page

JEE Java Platform, Enterprise Edition

API Application Programming Interface

RPC Remote Procedure Call

SLA Service Level Agreement

IMC Indice de masa corporala

Pagina 2

1. Introducere

Casa Nationala de Asigurari de Sanatate (CNAS) este institutie publica, autonoma, de interes national, cu personalitate juridica, al carei principal obiect de activitate il reprezinta asigurarea functionarii unitare si coordonate a sistemului asigurarilor sociale de sanatate din Romania.

Sistemul asigurarilor sociale de sanatate reprezinta principalul sistem de finantare a ocrotirii si promovarii populatiei care ofera un pachet de servicii de baza care cuprinde servicii medicale, servicii de ingrijire a sanatatii, medicamente, materiale sanitare si dispozitive medicale.

CNAS functioneaza pe baza Statutului propriu si are urmatoarele obligatii:

● sa asigure logistica functionarii unitare si coordonate a sistemului asigurarilor sociale de sanatate;

● sa urmareasca colectarea si folosirea cu eficienta a fondului; ● sa foloseasca mijloace adecvate de mediatizare pentru reprezentarea, informarea

si sustinerea intereselor asiguratilor pe care ii reprezinta; ● sa acopere nevoile de servicii de sanatate ale persoanelor, in limita fondurilor

disponibile. CNAS are in subordine casele judetene de asigurari de sanatate, Casa de Asigurari de Sanatate a Municipiului Bucuresti, Casa Asigurarilor de Sanatate a Ministerului Transporturilor, Constructiilor si Turismului, Casa Asigurarilor de Sanatate a Apararii, Ordinii Publice, Sigurantei Nationale si Autoritatii Judecatoresti.

CNAS doreste sa extinda sistemul SIUI prin achizitionarea, implementarea si integrarea in cadrul acestuia a unei solutii care sa ofere toate functionalitatile necesare introducerii prescriptiei electronice („PE”) pentru retetele suportate partial sau integral din Fondul National al Asigurarilor Sociale de Sanatate („FNUASS”).

Solutia va raspunde integral la toate cerintele CNAS tehnice si functionale, exprimate in prezenta cerere de oferta.

Solutia va fi conforma, din punct de vedere functional si tehnic, cu:

● Legea Romana;● Normele si reglementarile CNAS;● Recomandarile standardelor mentionate in acest document

 

1. Continutul achizitieiSolutia propusa de catre Ofertant va include:

● Componenta aplicativa de extindere a sistemului SIUI, compusa din urmatoarele module specifice:

○ Modulul central○ Modulul prescriere○ Modulul validare○ Modulul eliberare○ Modulul integrare

Pagina 2

● Extinderea aplicatiilor specializate SIUI folosite de catre medicii prescriptori si de catre furnizorii de servicii farmaceutice in vederea asigurarii functionalitatilor necesare introducerii PE.

● Platformele hardware si infrastructura de comunicatie● Serviciile de implementare specifice:

○ servicii de implementare propriu-zise, inclusiv proiectare si dezvoltare in beneficiul CNAS si de project management

○ servicii de instruire● Servicii de mentenanta si suport tehnic anual● Servicii de actualizare a aplicatiei in conformitate cu actualizarile legislative din

Romania legate de prescriptia electronica, pentru o perioada de 10 aniOferta trebuie sa contina suficiente informatii si detalii, astfel incat, comisia CNAS sa poata evalua capacitatea de implementare a solutiei in conformitate cu cerintele acestui document.

Oferta va include, daca este cazul, o lista a functionalitatilor aditionale ale solutiei care nu au fost solicitate in acest document.

2. Costul oferteiToate cheltuielile pentru pregatirea si depunerea ofertelor sunt suportate de catre Ofertanti.   CNAS nu poate fi facuta responsabila pentru aceste costuri, indiferent de rezultatele procesului de selectie a ofertelor.

3. Limba folosita pentru prezentarea ofertei

Toata corespondenta va fi redactata in limba romana, la fel ca si intocmirea ofertei de catre Ofertant, precum si toate documentele care au legatura cu oferta.

2. Obiectivele achizitiei 1. Obiective generale

Prescripţia electronică („PE”) este parte a strategiei e-Health a Uniunii Europene, ca instrument cheie care poate influenţa benefic securitatea pacientului prin limitarea erorilor medicale, efectelor adverse ale medicamentelor şi prin simplificarea şi eficientizarea interacţiunilor actorilor implicaţi în actul medical. Prescripţia electronică implică de asemenea implementarea instrumentelor de monitorizare şi de control, cu rezultate favorabile asupra scăderii costurilor actului medical, deziderat de actualitate în Romania, în special în perioada de criză a sistemului medical, perioadă caracterizată de insuficienţa fondurilor alocate pentru sănătate.

PE este un instrument important în implementarea istoricului medical al pacientului. De asemenea, prescripţia electronică permite corelarea medicaţiei recomandate pentru un diagnostic cu bolile şi alergiile pacientului, constituind astfel elemente esenţiale pentru sprijinirea actului medical. Nu in ultimul rând, prescripţia electronică este un vector de creştere a competitivitaţii sectorului medical şi a mobilităţii pacienţilor în contextul serviciilor medicale transfrontaliere. Prescripţia electronică este una din componentele

Pagina 2

strategiei de e-Health a Comunităţii Europene, enuntate încă din anul 2004, potrivit căreia, până la sfârşitul anului 2008, ţările europene ar fi trebuit să fie capabile să asigure sisteme de teleconsultaţie, prescriere electronică, telemonitoring şi teleCare.

Implementarea PE este necesară pentru eficientizarea prescrierii medicaţiei de către furnizorii de servicii medicale, prin asistarea informatică a procesului de elaborare a medicaţiei pentru un diagnostic specificat. De asemenea, sistemul asigură urmărirea şi controlul respectării legislaţiei privind prescrierea medicamentelor, în condiţiile în care medicamentele gratuite şi compensate reprezintă unul dintre cei mai mari consumatori ai Fondului Naţional Unic de Asigurari Sociale de Sănătate din România, FNUASS.

Totodată, implementarea sistemului naţional pentru prescripţia electronică va asigura un important progres către alinierea cu realităţile existente în prezent în Uniunea Europeană şi un pas important în realizarea Sistemul Naţional de Sănătate.

2. Obiectivele specifice

PE va fi realizat ca o componenta functionala intrinseca a sistemului SIUI prin intermediul careia se va asigura suportul necesar introducerii prescriptiei electronice, astfel mentinandu-se aspectul unitar al activitatii de exploatare.

Serviciile informatice oferite de PE vor fi puse la dispoziţia entităţilor utilizatoare sub formă de servicii sau de aplicaţii web.

Pentru realizarea PE trebuie proiectate şi realizate, pe de o parte, componenta aplicativă care va implementa funcţionalităţile sistemului şi, pe de altă parte, infrastructura informatică necesară.

Soluţia de implementare a componentei de prescripţie electronică a sistemului SIUI va consta dintr-un ansamblu de servicii şi produse informatice integrate, astfel încât să se obţină funcţionalităţile şi nivelurile de performanţă, securitate şi disponibilitate impuse de importanţa sistemului.

Pe lângă sistemul de producţie, PE va conţine un subsistem de testare/dezvoltare şi instruire necesar exploatării în conformitate cu bunele practici internaţionale şi cu metodele actuale in domeniul formării profesionale continue a personalului.

Pagina 2

3. Situația actuala1. Beneficiarul investiției

Beneficiarul investiției este Casa Naționala de Asigurări de Sănătate.

Casa Naţională de Asigurări de Sănătate (CNAS) este instituţie publică, autonomă, de interes naţional, cu personalitate juridică, care administrează şi gestionează sistemul de asigurări sociale de sănătate în vederea aplicării politicilor şi programelor Guvernului în domeniul sanitar.

CNAS s-a înfiinţat în baza Legii Asigurărilor Sociale de Sănătate - Legea nr. 145/1997. Aceasta a urmărit modelul de asigurări tip Bismark, cu asigurare de sănătate obligatorie, bazat pe principiul solidarităţii şi funcţionând în cadrul unui sistem descentralizat. Legea a intrat în vigoare, cu toate prevederile, începând cu 1 ianuarie 1999 dar a existat o perioada de tranziţie în anul 1998 în care Direcţiile Sanitare Judeţene şi Ministerul Sănătăţii au administrat fondurile de asigurare. În consecinţă, de la 1 ianuarie 1999, conform legii au funcţionat şi casele de asigurări ca instituţii publice autonome, conduse de reprezentanţii asiguraţilor şi patronatului prin consiliile de administraţie, deci şi Casa Naţională de Asigurări de Sănătate.

CNAS funcţionează pe baza statutului propriu, avizat de consiliul de administraţie şi aprobat prin Hotărârea Guvernului nr. 972/2006 pentru aprobarea Statutului Casei Naţionale de Asigurări de Sănătate, cu modificările şi completările ulterioare.

2. Grupurile ținta

Grupurile ținta vizate sunt:

● 41 Case Judeţene de Asigurări de Sănătate şi Casa de Asigurări de Sănătate a Municipiului Bucureşti

● Casa Asigurărilor de Sănătate a Ministerului Transporturilor Construcţiilor şi Turismului

● Casa Asigurărilor de Sănătate a Apărării, Ordinii Publice, Siguranţei Naţionale şi Autorităţii Judecătoreşti

● Medicii prescriptori● Furnizorii de servicii farmaceutice● Beneficiarii serviciilor de sănătate

Descrierea grupurilor ținta vizate

● Casele Judeţene de Asigurări de Sănătate şi Casa de Asigurări de Sănătate a Municipiului Bucureşti

○ Casele de asigurări de sănătate judeţene şi a municipiului Bucureşti sunt instituţii publice cu personalitate juridică, cu bugete proprii, în subordinea

Pagina 2

CNAS. Casele de asigurări colectează contribuţiile persoanelor fizice, altele decât cele pentru care colectarea veniturilor se realizează de către Agenţia Naţională de Administrare Fiscală, denumită în continuare ANAF, şi gestionează bugetul Fondului naţional unic de asigurări sociale de sănătate aprobat, cu respectarea prevederilor legii, asigurând funcţionarea sistemului de asigurări sociale de sănătate la nivel local. Casele de asigurări pot derula şi activităţi pentru valorizarea fondurilor gestionate, respectiv închirieri, proiecte, studii, manifestări ştiinţifice, exploatarea patrimoniului propriu, precum şi alte activităţi în acest sens, aprobate prin hotărâre a Guvernului.

● Casa Asigurărilor de Sănătate a Ministerului Transporturilor Construcţiilor şi Turismului

○ Casa Asigurărilor de Sănătate a Ministerului Transporturilor Construcţiilor şi Turismului este instituţie publică, fără scop lucrativ, cu personalitate juridică, cu buget propriu, în coordonarea Ministerului Transporturilor şi Infrastructurii.

● Casa Asigurărilor de Sănătate a Apărării, Ordinii Publice, Siguranţei Naţionale şi Autorităţii Judecătoreşti

○ C.A.S.A.O.P.S.N.A.J. aplică şi respectă politica şi strategia generală stabilită de Casa Naţională de Asigurări de Sănătate pentru sistemul de asigurări sociale de sănătate specific ministerelor şi instituţiilor cu reţele sanitare proprii din domeniul apărării, ordinii publice, siguranţei naţionale si autorităţii judecătoreşti. C.A.S.A.O.P.S.N.A.J. este instituţie publică, cu personalitate juridică şi buget propriu, subordonată Casei Naţionale de Asigurări de Sănătate (CNAS)

● Medicii prescriptori○ aproximativ 30.000 medici au contract cu Casele Judeţene de asigurări de

sănătate○ medicii prescriptori care pot să elibereze prescripţii, conform legislaţiei în

vigoare:■ medici de familie■ medici din cadrul cabinetelor şcolare sau studenţeşti■ medici din cadrul căminelor de bătrâni■ medici din cadrul instituţiilor subordonate Agenţiei Naţionale pentru

Persoanele cu Handicap■ medici din cadrul unităţilor medicale de urgenţă

● Farmacii○ sunt 5.386 farmacii, conform ultimelor raportări.○ în această categorie intră societăţile comerciale farmaceutice, cu toate

farmaciile din subordine● Beneficiarii serviciilor de sănătate (persoanele asigurate)

○ În anul 2009, valoarea medicamentelor compensate şi gratuite eliberate prin farmaciile cu circuit deschis a fost de 5.103.129.389 lei, pentru un număr de 9.299.380 pacienţi, eliberându-se un număr de 43.714.167 reţete, cu o medie lunară de 774.948 pacienţi/lună şi a unui număr mediu de 3.642.847 reţete eliberate/lună

○ Din cei peste noua milioane de asigurați care au beneficiat de rețete compensate/gratuite in anul 2009, principalele categorii sunt:

■ salariați■ alte categorii:■ pensionari,■ someri,

Pagina 2

■ persoane care beneficiaza de ajutor social,■ co-asigurati■ copii, gravide, lauze■ beneficiari de legi speciale■ boli licitate A

3. Beneficiile aduse grupurilor tinta

● Pentru Casele de Asigurari de Sanatate○ reducerea erorilor de raportare de la farmacii către casele de asigurari○ reducerea riscului de apariţie a fraudelor○ eficientizarea raportării

● Pentru medicii prescriptori○ reducerea timpului alocat activităţilor administrative în avantajul actului

medical○ reducerea erorilor cauzate de implicarea factorului uman.

● Pentru furnizorii de servicii farmaceutice○ reducerea timpului alocat activităţii administrative○ posibilitatea de a deservi mai mulţi clienţi (creşterea eficienţei economice)

● Beneficiarii directi ai serviciilor de sanatate (persoanele asigurate)○ scade numărul erorilor cauzate de interpretarea greşită a scrisului de mână○ reducerea costurilor (achiziţia unor medicamente inutile)○ reducerea timpului de aşteptare în farmacie

4. Cadrul legalCadrul legal al implementarii PE este constituit din:

● Acte normative specifice:○ Legea nr. 95/2006 privind reforma in domeniul sanatatii, cu modificarile si

completarile ulterioare○ Legea nr. 677/2001 pentru protectia persoanelor cu privire la prelucrarea

datelor cu caracter personal si libera circulatie a acestor date, modificata si completata

○ Legea nr. 506/2004 privind prelucrarea datelor cu caracter personal● Acte normative necesare procedurii de achizitie:

○ Ordonanta de Urgenta nr. 34/2006 privind atribuirea contractelor de achizitie publica, a contractelor de concesiune de lucrari publice si a contractelor de concesiune de servicii, cu completarile si modificarile ulterioare

○ HGR nr. 925/2006 pentru aprobarea normelor de aplicare a prevederilor referitoare la atribuirea contractelor de achizitie publica din OUG nr. 34/2006 privind atribuirea contractelor de achizitie publica, a contractelor de concesiune de lucrari publice si a contractelor de concesiune de servicii, cu completarile si modificarile ulterioare

○ HGR nr. 1660/2006 pentru aprobarea Normelor de aplicare a prevederilor referitoare la atribuirea contractelor de achizitie publica prin mijloace electronice din OUG nr. 34/2006 privind atribuirea contractelor de achizitie publica, a contractelor de concesiune de lucrari publice si a contractelor de concesiune de servicii, cu completarile si modificarile ulterioare

Pagina 2

○ OUG nr. 30/2006 privind functia de verificare a aspectelor procedurale aferente procesului de atribuire a contractelor de achizitie publica, a contractelor de concesiune de lucrari publice si a contractelor de concesiune de servicii, cu modificarile si completarile ulterioare

○ HGR nr. 942/2006 pentru aprobarea Normelor de aplicare a OUG nr. 30/2006 privind functia de verificare a aspectelor procedurale aferente procesului de atribuire a contractelor de achizitie publica

○ Ordin nr. 175/2007 privind aprobarea Manualului operational pentru activitatea de observare si verificare a atribuirii contractelor de achizitie publica, a contractelor de concesiune de lucrari publice si a contractelor de concesiune de servicii - modelul si continutul formularelor si documentelor utilizate

○ Hotararea nr. 782/2006 pentru aprobarea Regulamentului de organizare si functionare al Consiliului National de Solutionare a Contestatiilor, cu modificarile si completarile ulterioare

○ Ordin nr. 113/2008 pentru aprobarea Regulamentului privind supravegherea modului de atribuire a contractelor de achizitie publica, a contractelor de concesiune de lucrari publice si a contractelor de concesiune de servicii. Supravegherea va viza inclusiv procedurile de achizitie publica impuse operatorilor economici de catre autoritatile de management pentru derularea proiectelor finantate din fondurile structurale acordate Romaniei de catre Uniunea Europeana.

● Acte normative complementare necesare procesului de achizitie:○ Legea contenciosului administrativ nr. 554/2004, cu modificarile si completarile

ulterioare ○ Ordonanta nr. 2/2001 privind regimul juridic al contraventiilor, cu modificarile

si completarile ulterioare

5. Cadrul institutional

Atribuţiile Casei Naţionale de Asigurări de Sănătate sunt următoarele:

● gestionează Fondul, în condiţiile legii, prin preşedintele CNAS, împreună cu casele de asigurări, inclusiv Casa Asigurărilor de Sănătate a Apărării, Ordinii Publice, Siguranţei Naţionale şi Autorităţii Judecătoreşti şi Casa Asigurărilor de Sănătate a Ministerului Transporturilor, Construcţiilor şi Turismului, până la reorganizarea acestora;

● propune, cu avizul Ministerului Sănătăţii, proiecte de acte normative pentru asigurarea funcţionării sistemului de asigurări sociale de sănătate şi acordă avize conform proiectelor de acte normative care au incidenţă asupra Fondului;

● elaborează, implementează şi gestionează procedurile şi formularele unitare, avizat de Ministerul Sănătăţii, pentru administrarea sistemului de asigurări sociale de sănătate;

● elaborează şi actualizează Registrul unic de evidenţă a asiguraţilor;● elaborează şi publică raportul anual, precum şi execuţia bugetară pe capitole şi

subcapitole şi planul de activitate pentru anul următor;● asigură organizarea sistemului informatic şi informaţional unic integrat pentru

înregistrarea asiguraţilor şi pentru gestionarea şi administrarea Fondului. Indicatorii folosiţi în raportarea datelor în sistemul de asigurări sociale de sănătate

Pagina 2

sunt unitari şi se stabilesc de Ministerul Sănătăţii, la propunerea CNAS, Colegiului Medicilor din România şi Colegiului Medicilor Dentişti din România;

● răspunde pentru activităţile proprii sistemului de asigurări sociale de sănătate în faţa Guvernului şi faţă de asiguraţi;

● elaborează strategia sistemului de asigurări sociale de sănătate cu privire la colectarea contribuţiilor de asigurări sociale de sănătate care se afla în administrarea CNAS, potrivit competenţelor stabilite de lege, precum şi cu privire la utilizarea şi administrarea acestuia în condiţiile legii;

● participă la stabilirea obiectivelor programelor de sănătate publică, în colaborare cu Ministerul Sănătăţii, Colegiul Medicilor din România, Colegiul Farmaciştilor din România, reprezentanţi ai asiguraţilor, spitalelor şi clinicilor universitare, ai unităţilor de cercetare, ai organizaţiilor neguvernamentale, ai sindicatelor şi patronatelor, ai ministerelor şi institutiilor centrale cu reţea sanitară proprie;

● elaborează şi stabileşte, împreună cu Ministerul Sănătăţii, prin comisiile organizate la nivel naţional, metodologia şi nivelul de evaluare a furnizorilor de servicii medicale, de dispozitive medicale şi medicamente;

● elaborează proiectul contractului-cadru, care se prezintă de către Ministerul Sănătăţii spre aprobare Guvernului;

● elaborează proiectul normelor metodologice de aplicare a contractului-cadru, cu consultarea Colegiului Medicilor din România, Colegiului Farmaciştilor din România, Colegiului Medicilor Dentişti din România, Ordinului Asistenţilor Medicali şi Moaşelor din România, Ordinului Biochimiştilor, Biologilor şi Chimiştilor din România, precum şi a organizaţiilor patronale şi sindicale reprezentative din domeniul medical, până la data de 15 decembrie a anului în curs pentru anul următor, care se aprobă prin ordin al ministrului sănătăţii publice şi al preşedintelui CNAS;

● elaborează împreună cu Ministerul Sănătăţii criteriile privind calitatea asistenţei medicale acordate asiguraţilor referitoare la diagnostic şi tratamentul medico-chirurgical şi stomatologic;

● elaborează condiţiile privind acordarea asistenţei medicale din cadrul sistemului de asigurări sociale de sănătate, cu consultarea Colegiului Medicilor din Romania şi a Colegiului Medicilor Dentişti din România;

● participă anual şi ori de câte ori este nevoie la elaborarea listei de medicamente eliberate cu sau fără contribuţie personală, pe baza prescripţiilor medicale, pentru persoanele asigurate;

● administrează şi întreţine bunurile imobile şi baza materială din patrimoniu, în condiţiile legii;

● analizează proiectele bugetelor de venituri şi cheltuieli ale caselor de asigurări propuse de acestea;

● elaborează caracteristicile tehnice ale cardului european de asigurări sociale de sănătate, precum şi modalităţile de elaborare şi implementare a acestuia;

● îndeplineşte funcţia de organism de legătură, care asigură comunicarea cu organismele similare din statele care au incheiat cu România documente internaţionale cu prevederi în domeniul sănătăţii;

● elaborează strategiile necesare şi acţionează pentru îndeplinirea condiţiilor de aderare impuse de Uniunea Europeană ca parte integrantă a politicii guvernamentale în domeniul asigurărilor sociale de sănătate;

● realizează prognoze, strategii, studii şi analize privind dezvoltarea, funcţionarea, eficacitatea şi performanţele sistemului de asigurări sociale de sănătate din România, în vederea perfecţionării acestuia;

● îndrumă metodologic şi controlează modul de aplicare a dispoziţiilor legale de către casele de asigurări;

Pagina 2

● negociază şi contractează cu instituţii abilitate de lege colectarea şi prelucrarea datelor privind unele servicii medicale furnizate asiguraţilor, în vederea contractării şi decontării acestora de către casele de asigurări;

● acordă gratuit informaţii, consultanţă şi asistenţă în domeniul asigurărilor sociale de sănătate persoanelor asigurate, angajatorilor şi furnizorilor de servicii medicale;

● participă la licitaţii naţionale organizate de Ministerul Sănătăţii pentru achiziţia de medicamente şi materiale specifice pentru realizarea programelor de sănătate;

● încheie şi derulează contracte de achiziţii publice pentru medicamente şi materiale sanitare pentru derularea programelor de sănătate, precum şi contracte de furnizare de servicii medicale de dializă;

● monitorizează şi controlează modalitatea de eliberare a medicamentelor compensate şi gratuite;

● organizează, împreună cu Ministerul Sănătăţii şi Ministerul Justiţiei, comisia centrală de arbitraj, care este condusă de un consiliu de conducere format din reprezentanţi ai Ministerului Sănătăţii, CNAS, Colegiului Medicilor din România, Colegiului Farmaciştilor din România şi Colegiului Medicilor Dentişti din România;

● aprobă bugetele de venituri şi cheltuieli ale caselor de asigurări, în condiţiile legii;● asigură evidenţa statistică necesară în activitatea specifică sistemului de asigurări

sociale de sănătate şi colaborează cu instituţii care au atribuţii în domeniul statisticii;

● efectuează, direct sau prin intermediari specializaţi, sondaje în vederea evaluării gradului de satisfacţie a asiguraţilor şi de evaluare a interesului manifestat de aceştia faţă de calitatea serviciilor medicale şi asigură controlul măsurilor stabilite în gestionarea fondurilor pentru realizarea funcţionării sistemului de asigurări sociale de sănătate într-un mod coerent şi unitar;

● iniţiază, negociază şi încheie cu instituţii similare documente de cooperare internaţională în domeniul său de activitate şi derulează programe finanţate de organisme internaţionale având ca specific asigurările de sănătate;

● cooperează cu partenerii sociali (patronate, sindicate, societate civilă) şi cu celelalte instituţii cu atribuţii în asigurarea şi promovarea sănătăţii;

● asigură informarea cel puţin o dată pe an a fiecărui asigurat, prin casele de asigurări, asupra serviciilor de care beneficiază, nivelului de contribuţie şi modului de plată, dar şi asupra drepturilor şi obligaţiilor sale, precum şi asupra mijloacelor de păstrare a sănătăţii, de reducere şi de evitare a cauzelor de îmbolnăvire şi asupra pericolelor la care se expun în cazul consumului de droguri, alcool şi tutun;

● monitorizează şi controlează modul de încheiere şi executare a contractelor încheiate între casele de asigurări şi furnizorii de servicii medicale, de medicamente şi de dispozitive medicale;

● monitorizează funcţionarea organelor de conducere ale caselor de asigurări şi stabileşte atribuţiile acestora, în condiţiile legii;

● asigură logistica funcţionării unitare şi coordonate a sistemului de asigurări sociale de sănătate;

● foloseşte mijloacele adecvate de mediatizare pentru reprezentarea, informarea şi susţinerea intereselor asiguraţilor;

● organizează şi efectuează împreună cu casele de asigurări controlul serviciilor medicale care se acordă asiguraţilor pe baza contractelor de furnizare de servicii încheiate, potrivit Legii nr. 95/2006 privind reforma în domeniul sănătăţii;

● asigură aplicarea unitară a modalităţilor de acordare a asistenţei medicale cetăţenilor statelor cu care România a încheiat acorduri;

● asigură logistica şi baza materială necesare activităţii de pregătire şi formare profesională a personalului, din cheltuielile de administrare a Fondului;

Pagina 2

● prezintă un raport anual Guvernului privind starea sistemului de asigurări sociale de sănătate;

● prezintă rapoarte Parlamentului, la solicitarea acestuia;● implementează programele naţionale de sănătate cu scop curativ finanţate din

bugetul Fondului, conform strategiei aprobate de Ministerul Sănătăţii;● răspunde de asigurarea, urmărirea şi controlul fondurilor alocate pentru derularea

programelor şi subprogramelor de sănătate cu scop curativ, precum şi de monitorizarea, controlul şi analiza indicatorilor fizici şi de eficienţă, prin intermediul caselor de asigurări de sănătate;

● transmite Agenţiei Naţionale pentru Programe de Sănătate, trimestrial, anual şi ori de câte ori este nevoie, analiza modului în care au fost derulate programele naţionale de sănătate cu scop curativ finanţate din bugetul Fondului;

● poate elabora, pentru furnizorii aflaţi în relaţii contractuale cu casele de asigurări de sănătate, protocoale de practică, ca bază de decontare pentru servicii medicale, medicamente şi dispozitive medicale, cu consultarea Colegiului Medicilor din România, Colegiului Farmaciştilor din România, Colegiului Medicilor Dentişti din România şi Ordinului Asistenţilor Medicali şi Moaşelor din România;

● alte atribuţii prevăzute de acte normative în domeniul sănătăţii.

6. Volumul tranzactiilor

An Nr total de pacienti

Nr total de retete eliberate

Nr. mediu lunar de pacienti

Nr mediu lunar de retete eliberate

2009 9.299.380 43.714.167 774.948 3.642.847

2010 8.643.608 42.347.824 720.300 3.528.985

Pagina 2

4. Cerinte privind solutia tehnica

Solutia propusa de Ofertant va avea in vedere acoperirea tuturor cerintelor exprimate in Caietul de Sarcini.

Sistemul informatic PE trebuie sa raspunda urmatoarelor cerinte generale:

1. va fi proiectat si implementat astfel încât să extinda sistemul SIUI operat de CNAS pentru a se păstra consistenţa din punct de vedere logic.

2. Din punct de vedere tehnologic va indeplinii urmatoarele criterii:a. va fi proiectat ca un sistem de înaltă performanţă şi disponibilitate.b. va oferi suport pentru soluţii moderne şi deschise de integrare.c. va include servicii de mentenanţa si suport pentru infrastructura

informaticăd. bazat pe standardele deschise de interoperabilitate, cum ar fi WSDL,

XML, etc.e. va permite comunicaţii sincrone şi asincrone între aplicaţii cu

asigurarea securităţii datelor prin mecanisme de tip SSL.3. va fi realizat într-o structură modulară, deosebindu-se o componentă aplicativă

dedicată şi componente funcţionale de gestiune a sistemului informatic, implementate în ansamblu pe o infrastructură informatică de înaltă performanţă şi înaltă disponibilitate.

4. va asigura un schimb de informaţii uşor de gestionat şi va oferi un nivel de accesibilitate cel puţin la nivelul oferit de stocarea datelor pe hartie. Asigurarea unui schimb consistent de informaţii şi date medicale se poate realiza doar în condiţiile abordării multi-nivel pentru interoperabilitate:

a. La nivel legal – baza legală pentru prescrierea şi eliberarea electronică a medicamentelor, inclusiv prin susţinerea eliminării formularelor tipizate imprimate şi identificarea unică a persoanelor asigurate, inclusiv prin intermediul cardurilor CEAS, din momentul introducerii acestora.

b. La nivel organizaţional – logistică pentru medicaţie, eliberarea medicamentelor, plăţi şi supraveghere, recunoaşterea autorizaţiilor medicilor prescriptori

c. La nivel semantic – codificări, nomenclatoare, compoziţia medicamentelor, brand, instrucţiuni de dozaj, etc

d. La nivel tehnic – sintaxa, standarde de mesagerie, reţele, comunicaţii5. Va proteja investitia initiala facuta de CNAS pentru implementarea sistemului

SIUI astfel incat sa nu duplice infrastructura hardware si functionalitatile deja existente.

Sistemul informatic PE trebuie sa raspunda urmatoarelor cerinte minime si obligatorii:

1. va asigura generarea codurilor de bare bi-dimensionale ce pot fi tiparite in momentul eliberarii prescriptiilor.

2. va asigura eliberarea fracţionată a prescripţiei de la mai multe farmacii. Pentru a permite eliberarea parţială a prescripţiilor PE trebuie proiectat astfel încât să permită gestionarea stării „eliberat” la nivel de medicament şi nu la nivel de reţetă. În cazul în care un furnizor de servicii farmaceutice eliberează parţial medicamente, orice alt furnizor de servicii farmaceutice care va vizualiza prescripţia va putea elibera exclusiv medicamentele rămase.

Pagina 2

3. va contine un modul de validare a prescripţiilor pe baza regulilor de business. 4. va permite adaugarea, modificarea şi publicarea regulilor de business de către

utilizatori experţi ai CNAS, prin intermediul unei interfeţe grafice. 5. Modificarea regulilor de validare nu va presupune actualizarea codului

aplicatiei.6. Va implementa prescripţiile repetitive, în cazul bolnavilor cronici. Se va

permite eliberarea prescripţiilor pentru bolnavii cronici direct de la farmacii, dupa adoptarea modificarilor legislative in acest sens. Verificarea respectării intervalelor de prescriere se va face de PE iar iniţiatorul unei astfel de reţete va fi medicul de familie.

7. Va permite autorizarea şi validarea prescripţiilor printr-un serviciu de tip centru de apel.

8. Să permită interoperabilitatea cu sistemele informatice cu care PE va interacţiona, dintre care cel mai important este SIUI.

9. Identificarea medicilor prescriptori cu certificatul digital calificat si a persoanelor asigurate cu cardul CEAS.

10. Adaugarea semnăturii electronice pentru reţetele electronice.11. Includerea actualizărilor sistemului în concordanţă cu cadrul legislativ din

România al prescriptiei electronice, pentru o perioadă de 10 ani de la punerea în producţie.

12. Va utiliza categoriile de date existente in sistemul SIUI (nomenclatoare, asiguraţi, registre de servicii medicale şi farmaceutice, registre de furnizori de servicii medicale şi farmaceutice, etc). Accesul la aceste categorii de date se va face programatic.

13. Va include extinderea aplicaţiilor SIUI destinate uzului furnizorilor de servicii medicale şi farmaceutice pentru a include functionalitatile specifice introducerii PE.

14. Va permite folosirea de către furnizorii de servicii medicale si farmaceutice a aplicaţiilor terţe, dacă acestea sunt integrate programatic cu PE şi dacă aceste aplicaţii răspund tuturor cerinţelor funcţionale ale acestuia.

15. Va fi proiectat să funcţioneze în principal în mod ON-LINE. Pentru perioadele de timp în care, din motive tehnice, clientul instalat pe staţia de lucru a furnizorilor de servicii medicale si farmaceutice nu va putea schimba date cu componenta centrala a sistemului informatic PE (cu alte cuvinte va funcţiona în mod OFFLINE), solutia propusa trebuie sa asigure accesul la un număr limitat de funcţii. In momentul restaurării legăturii de date, aplicaţia va fi capabilă să sincronizeze informaţiile cu PE.

16. Va asigura suport pentru stabilirea automata a plafoanelor bugetare alocate furnizorilor de servicii farmaceutice in vederea compensarii (contor dinamic al consumului fata de plafonul alocat).

17. Va include specificatii care sa permita producatorilor independenti de aplicatii dedicate furnizorilor de servicii medicale si farmaceutice sa modifice aplicatiile respective conform cerintelor PE.

1. Scenarii de utilizare

Scenariile de utilizare in forma detaliata si formalizata sunt activitati care trebuie avute in vedere de Ofertant pentru faza de analiza a proiectului. In acest caiet de sarcini sunt descrise scenariile care trebuie luate in considerare de catre toti Ofertantii la elaborarea ofertelor, acestea fiind considerate minimum necesare.

Pagina 2

Proiectarea si implementarea, de catre ofertant, a sistemului informatic PE astfel incat functionarea acestuia sa fie in concordanta cu urmatoarele scenarii de utilizare, constituie o cerinta minima si obligatorie.

Pagina 2

1. Intocmirea prescriptiilor medicale

Ofertantul va extinde si modifica din punct de vedere functional aplicaţia SIUI specializată utilizata de medicii prescriptori, astfel incat furnizorii de servicii medicale vor putea intocmi prescripţii medicale. Accesul către funcţiile puse la dispoziţie de PE se va face numai după autentificarea şi autorizarea furnizorilor de servicii medicale sau farmaceutice de către sistemul SIUI.

Ofertantul va proiecta sistemul informatic PE astfel incat pentru intocmirea prescriptiilor medicale sa se parcurga următorii paşi:

● Validarea prin intermediul sistemului SIUI, a informaţiilor legate de calitatea de asigurat şi de eligibilitate a prescriptorului. Validarea se va face prin mecanismele puse la dispozitie de catre SIUI si anume:

○ certificatul digital calificat pentru medicul prescriptor si ○ cardul CEAS pentru persoana asigurata.

● Odată cu identificarea pacientului, aplicatia va evidenţia o serie de date care vor fi utilizate în reţeta:

○ Identificatorul pacientului○ vârsta, ○ categoria de asigurat, ○ boli cronice○ alergii○ etc.

● Aplicatia, prin intermediul interfaţei utilizator dedicate, va permite medicului prescripitor introducerea diagnosticului, prin selectare acestuia din nomenclatoarele existente in SIUI (CIM10).

● Intocmirea reţetei se va face prin completarea unei machete cu medicamentele prescrise.

● Aplicatia va dispune de mecanisme care sa preia si sa afiseze mesajele de atentionare destinate medicului prescriptor, generate de catre modulul de validare, in mod sincron, atunci când se semnalează apariţia unei erori cauzate de inconsistenţa datelor introduse sau de imposibilitatea de validare a datelor în concordanţă cu regulile specifice ale acestor date. Regulile se referă, pe de o parte, la normativele privind decontarea medicamentelor gratuite/compensate, iar pe de altă parte, la incompatibilităţile între medicamentele prescrise sau între acestea şi particularităţile medicale cunoscute ale pacientului.

● Sistemul trebuie să permită selectarea medicamentului după denumirea comercială sau substanţa activă, aceasta fiind o opţiune configurabilă. Medicul prescriptor trebuie sa poata face alegerea medicamentelor pentru prescripţie din nomenclatoarele de medicamente puse la dispoziţie de sistemul SIUI. Acestea sunt actualizate, de fiecare dată cand este necesar, cu listele furnizate de ANM si autorizate de Ministerul Sănătaţii. Medicului prescriptor i se va oferi posibilitatea consultării informaţiilor privind caracteristicile medicamentului ales din nomenclator (indicaţii, doze recomandate în funcţie de vârstă, greutate, mod de administrare ş.a.), ţinând seama totodată de posibilele interacţiuni cu alte medicamente sau reacţii adverse în cazul considerat.

Pagina 2

● Anterior inregistrarii in sistem, este necesar ca reteta sa faca obiectul unei serii de validări, menţionate în continuare:

○ Verificarea eligibilităţii pacientului de a beneficia de medicamente cu şi fără contribuţie personală. Consistenţa acestei informaţii, în stransă legătură cu categoria de asigurat, este întreţinută în sistemul SIUI, prin preluarea datelor de la diferite organizaţii şi instituţii şi prin validarea prezenţei pacientului pe lista unui singur medic de familie, la nivelul intregii ţări; astfel este necesara interogarea sistemului SIUI in mod sincron pentru a se obtine datele necesare.

○ Verificarea eligibilităţii medicului de a prescrie medicamente cu şi fără contribuţie personală. De regulă, eligibilitatea medicului şi categoriile de date pe care acesta le poate accesa sunt confirmate prin contractul pe care acesta îl are cu o Casă Judeteană de Asigurări de Sănătate; astfel este necesara interogarea in mod sincron a sistemului SIUI pentru a se obtine informatiile despre medic. Pentru verificarea eligibilitatii medicului de a prescrie medicamente se vor folosi certificatele digitale calificate.

○ Va implementa verificarea prescrierii medicamentelor conform normativelor şi regulilor impuse de CNAS şi Ministerul Sănătaţii în acest scop. Medicul este atenţionat de eventuale abateri de la aceste reguli si normative.

○ Verificarea respectării protocoalelor terapeutice privind prescrierea medicamentelor, prin apelarea motorului de validare bazat pe reguli de business. Medicul este atenţionat de eventuale abateri de la protocoalele terapeutice.

● Daca toate validarile sunt realizate cu succes, sistemul PE va inregistra şi procesa prescripţia emisă electronic şi semnată digital de către medicul prescriptor.

● Prescripţia electronică va avea cel puţin următoarele câmpuri completate automat de către sistem:

○ Data şi ora la care s-a finalizat prescripţia○ Detaliile medicului prescriptor○ Detaliile asiguratului, inclusiv categoria de asigurat○ Semnătura electronică○ Codul de validare al prescripţiei, în conformitate cu raspunsul primit de la

motorul de validare ● Pacientul va primi la cerere formatul tiparit al reţetei. Prescriptia tiparită va

dispune de cod de bare bi-dimensional prin care se vor codifica cel putin identificatorul unic al asiguratului, diagnosticul, medicamentele şi cantităţile prescrise.

1. Tratarea exceptiilor

Sistemul va asigura un mecanism pentru tratarea situatiei in care medicii prescriptori nu se pot conecta ONLINE pentru a accesa sistemul SIUI. Pentru aceasta situatie Ofertantul va asigura un mecanism de autorizare a medicilor prescriptori in cazul in care acestia nu se pot conecta ONLINE. De asemenea, Ofertantul va implementa un mecanism de adaugare in sistem a prescriptiilor cu caracter temporar, prescriptii care nu vor conţine detaliile referitoare la diagnostic şi la medicaţia prescrisă. Medicul prescriptor are obligaţia de a introduce prescriptia, prin sistemul PE, într-un interval maximal de timp care va fi precizat prin normele CNAS. Prescriptiile completate in situatia descrisa mai sus se vor imprima obligatoriu si pe hartie, pentru a fi inmanate persoanei asigurate, iar

Pagina 2

numarul de autorizare obtinut va fi prezent in codul de bare imprimat. In cazul in care prescriptia realizata in mod OFFLINE a fost eliberata de catre un furnizor de servicii farmaceutice inainte ca medicul prescriptor sa introduca detaliile acesteia atunci aplicatia SIUI specializata va semnaliza acest lucru medicului prescriptor, astfel incat acesta sa completeze informatiile necesare.

Pagina 2

2. Eliberarea prescriptiilor medicale

Ofertantul va extinde si modifica din punct de vedere functional aplicaţia SIUI specializată utilizata de furnizorii de servicii farmaceutice, astfel incat acestia vor putea elibera prescripţiile medicale.

In momentul eliberării medicamentelor conform unei prescripţii se vor efectua următorii paşi:

● Aplicatia va identifica prescriptia din sistemul SIUI. In cazul in care persoana prezinta prescriptia imprimata pe hartie sistemul va identifica reteta pe baza codului de bare. Persoanele care solicita eliberarea medicametelor se vor identifica folosind cardurile CEAS.

● In cazul eliberării fracţionate, SIUI va inregistra medicametele deja eliberate şi va permite persoanei asigurate să solicite eliberarea celorlalte medicamente de către alt furnizor de servicii farmaceutice. În cazul în care o farmacie eliberează parţial medicamente, orice altă farmacie care va vizualiza reţeta va putea elibera exclusiv medicamentele rămase.

● Dacă farmacistul, îndeplinind conditiile legale, a eliberat alte medicamente decât cele prescrise, va indica acest fapt prin completarea în macheta a unor câmpuri dedicate, indicând toate modificările făcute asupra reţetei iniţiale (înlocuire medicament, dozaj, indicaţii de administrare, etc.). Detaliile implementarii acestei functionalitati vor fi stabilite in faza de initiere a proiectului.

1. Tratarea exceptiilor

In cazul în care prescripţia a fost emisă în situaţia descrisa in Capitolul 4.1.1.1, medicul prescriptor neavând acces internet pentru a se conecta la sistemul central PE, iar solicitantul se prezintă la furnizorul de servicii farmaceutice înainte ca medicul prescriptor să introducă în sistemul PE toate detaliile prescripţiei, atunci prescriptia se va putea elibera doar integral, pe baza exemplarului tipărit, prezentat de solicitant. Sistemul va valida prescriptia şi calitatea de asigurat a solicitantului pe baza informatiilor codificate prin intermediul codului de bare iar in cazul in care pre-validarea este facuta cu succes si solicitantul este asigurat, farmacistul va onora prescriptia prezentata.

2. Standarde

Solutia propusa de Ofertant trebuie fie conforma cu cel putin urmatoarele recomandari de buna practica, standarde si specificatii privitor la componentele dezvoltate, componentele care impreuna asigura mediul logic si suportul functional al functionarii solutiei propuse:

● Arhitectura○ Recomandarile W3C cu privirile la SOAP (Simple Object Access Protocol)

versiunea 1.2○ Specificatiile W3C cu privire la XML

Pagina 2

○ Specificatiile si recomandarile W3C si XML Security Working Grup cu privire la XML Encryption si XML Signature

○ Specificatiile si recomandarile W3C cu privire la WSDL (Web Services Description Language) si a extensibilitatii WSDL cu ajutorul SOAP

○ HTTP/HTTPS○ TCP/IP○ ANSI SQL

● Coduri de bareISO/IEC 16022 (Datamatrix) sau ISO/IEC 18004 (QR Code)

● Nomenclatoare○ CIM 10

3. Cerinte privind arhitectura software a solutiei

PE va fi realizat in cadrul SIUI prin intermediul unei structuri modulare, implementată pe o infrastructură informatică de înaltă performanţă şi disponibilitate, după cum este prezentat in diagrama de mai jos:

Pagina 2

Sistemul proiectat si implementat de catre Ofertant trebuie sa modifice sistemul SIUI existent astfel incat sa se obtina functionalitati similare cu cele din diagrama urmatoare:

Pagina 2

1. Cerinte privind componenta aplicativa

Această componentă va fi proiectată să folosească o arhitectură modulară, fiecare modul fiind dedicat câte unei funţionalităţi specifice a sistemului PE. Componenta aplicativă va fi responsabilă atât cu deservirea utilizatorilor interni CNAS/CJAS cât şi cu deservirea utilizatorilor externi (furnizorii de servicii medicale şi farmaceutice), prin intermediul legăturilor internet securizate.

1. Modulul centralAcest modul va fi accesat de utilizatorii interni CNAS/CJAS şi va oferi suport pentru activităţile de rutină ale acestora.

Gradul sporit de complexitate a datelor gestionate de PE presupune proiectarea unui sistem de raportare flexibil, bazat pe tehnologii de tip cub multi-dimensional. O cerinte minima si obligatorie este ca următoarele tipuri de rapoarte sa fie disponibile iniţial:

● Topul consumului pe medici prescriptori● Topul consumului pe diagnostice● Topul consumului pe medicamente● Abateri de la costul mediu pe diagnostic● Abateri de la costul mediu pe grupe de vârstă● Totalul consumului lunar pe judeţe şi/sau farmacii● Lista erorilor de prescriere pe diferite dimensiuni (diagnostice, vârstă, gravide, etc)

Sistemul proiectat va pune la dispoziţia utilizatorilor experţi CNAS unelte intuitive care să le faciliteze adăugarea de noi rapoarte sau costruirea unor rapoarte dinamice, în functie de nevoile instituţiei.

Pagina 2

2. Modulul prescriereAcest modul va fi responsabil cu interacţiunea în timp real cu furnizorii de servicii medicale, interacţiune necesară pentru întocmirea prescripţiilor.

Cerinte minime si obligatorii:

● Aplicaţia folosită de furnizorii de servicii medicale va putea accesa acest modul doar dupa ce sistemul SIUI a efectuat validarile necesare în ceea ce priveste furnizorul de servicii medicale şi eligibilitatea persoanei asigurate de a primi serviciile medicale solicitate.

● Interfaţa pusă la dispozitie de acest sistem va fi bazată pe servicii web, iar specificaţiile acesteia vor putea fi puse la dispoziţia entităţilor interesate in scopul dezvoltarii aplicatiilor terte adresate medicilor prescriptori sau furnizorilor de servicii farmaceutice.

● Va apela modulul de validare pentru realizarea verificarilor necesare in procesul de prescriere.

3. Modulul validare

Pentru realizarea acestui modul se vor lua in considerare urmatoarele caracteristici specifice ale regulilor de validare ale prescriptiilor electronice:

a. regulile depind de un număr mare de factori (diagnostic, substanţă activă, vârstă, stare de graviditate, IMC, alergii, boli cronice, medicaţie curentă, etc...)

b. regulile sunt slab cuplate în sensul că nu depind una de alta, respectarea sau nu a unei reguli neavând niciun efect asupra altei reguli

c. regulile de prescriere se schimba des în special datorită apariţiei de noi regulid. răspunsul aşteptat de la sistem este unul neechivoc, fie acceptarea reţetei fie

respingerea ei fie un mesaj de atenţionare asupra unei eventuale neconcordanţe deci lanţul decizional este scurt.

Datorita acestor particularitati, metoda clasica, programatica, de implementare a regulilor de prescriere ridica un numar mare de probleme ca, de exemplu, lipsa instrumentelor de verificare a completitudinii si corectitudinii setului de reguli implementat sau cresterea exponentiala a complexitatii activitatii de intretinere a regulilor. Pentru evitarea acestor probleme Ofertantul va implementa acest modul cu ajutorului unui sistem de tip BRMS care să permită experţilor CNAS introducerea, publicarea şi actualizarea acestor reguli prin intermediul unei interfeţe grafice. Regulile de business trebuie să se poată aplica atât activităţii de prescriere cât şi celei de eliberare a medicamentelor.

Solutia implementata va raspunde urmatoarelor cerinte generale:

● Va permite descrierea regulilor de catre utilizatori experti în business-ul modelat, cu minime informaţii de utilizare a calculatorului.

● Regulile vor putea fi scrise de mai mulţi utilizatori experţi în paralel, pe domenii de interes diferite.

● Va permite decuplarea dezvoltării regulilor de testarea acestora şi de implementarea lor ulterioară în producţie.

PE va furniza recomandări si opţiuni pentru prescrierea medicamentelor pe baza protocoalelor terapeutice (conform Ordinului MSP-CNAS 1301-500 din 11.07.2008 pentru aprobarea protocoalelor terapeutice privind prescrierea medicamentelor aferente

Pagina 2

denumirilor comune internaţionale prevăzute în Lista cuprinzând denumirile comune internationale corespunzatoare medicamentelor de care beneficiază asiguraţii, cu sau fără contribuţie personală, pe baza de prescriptie medicală, în sistemul de asigurări sociale de sănătate, aprobată prin Hotărârea Guvernului nr. 720/2008).

Se va verifica dacă prescrierea medicamentelor s-a făcut conform listelor de medicamente compensate şi/sau gratuite

O funcţionalitate a sistemului este verificarea şi atentionarea medicului prescriptor privind interacţiunile între medicamentele prescrise şi alimente, pentru a emite atenţionări pacienţilor (de exemplu: alcool, sare etc).

Sistemul va identifica eventualele contraindicaţii pentru medicamentele prescrise, luând în considerare starea pacientului la momentul prescrierii (ex. gravide, lăuze, persoane cu alergii). Odată cu finalizarea Sistemului Naţional de Sănătate, o parte din datele necesare în aceste evaluari vor putea fi preluate din sistemul EHR, cand acest sistem va fi disponibil la nivel national, din fişa electronică a pacientului. În situaţia în care nu există o fişă a pacientului, sau legătura cu sistemul EHR nu este posibilă, se emite o atenţionare către medic (că suportul pe aceasta componentă de evaluare nu este activ), informaţia fiind de asemenea asociată înregistrării reţetei în PE.

Sistemul va permite accesul medicului la protocoale si ghiduri de practică în forma furnizată de organismele medicale (ANM, Asociaţii ale medicilor, etc). În plus, sistemul va pune la dispoziţia medicului recomandări de medicaţie funcţie de diagnostic şi de particularitătile medicale ale pacientului, în situaţia când acestea sunt disponibile prin accesul la fisa medicală din sistemul EHR. De asemenea, sistemul va evalua eventualele incompatibilităţi între medicamentele prescrise, sau faţă de medicamentele administrate pacientului în ultima perioadă de timp, regăsite în sistemul PE/EHR. În situatia în care nu este posibilă conectarea la sistemul EHR, sau nu există informaţii disponibile, medicul este inştiinţat de aceasta şi informaţia se înregistrează în PE odată cu reţeta. Se înregistrează de asemenea acceptarea sau nu de către medic a recomandării date de sistem.

Motorul de validare va asigura suport pentru definirea următorului set minim şi obligatoriu de reguli de validare în ceea ce priveşte activitatea de întocmire a prescripţiilor medicale:

● Dependenţe medicament-diagnostic. Motorul de validare al PE va conţine reguli de validare care să includă relaţii între medicamente, la nivel de DCI sau de denumire comercială şi diagnostice, la nivel de codificare CIM10.

○ Relaţii de incluziune – Motorul de validare al PE va contine un set exclusiv de medicamente care se pot prescrie în cazul unui diagnostic (de exemplu insulina se prescrie doar pentru diabet). În cazul în care sistemul detectează un medicament exclusiv alocat unui diagnostic prescris pentru alt diagnostic va genera un mesaj de atenţionare cu caracter informativ.

○ Relaţii de excluziune – Motorul de validare al PE va include contraindicaţii medicamentoase în cazul anumitor diagnostice. De exemplu - conform Protocolului de prescriere a medicamentelor definit de Ministerul Sănătăţii, pentru ACIDUM URSODEOXYCHOLICUM există contraindicaţia: Nu se va prescrie în regim compensat pentru tratamentul litiazei biliare. Deoarece contraindiaţiile au grade diferite de gravitate, aplicaţia trebuie sa permită definirea mesajului transmis în cazul fiecărei contraindicaţii, la nivel de alertă sau de eroare.

Pagina 2

○ Relaţii complexe – Motorul de validare al PE va defini relaţii complexe între medicamente şi diagnostice, în care să se poate utiliza combinaţii de medicamente şi de diagnostice, fie pe relaţii de incluziune fie pe relaţii de excluziune, conform celor prezentate anterior. Cel mai întâlnit exemplu este cel în care sunt contraindicate unele asociaţii medicamentoase, indiferent de diagnostic, dar se pot defini şi reguli prin care să fie obligatorie prescrierea unui medicament asociat pentru un DCI.

● Dependenţe între medicamente şi caracteristici sau stări personale.○ Relaţii între medicamente şi vârstă. Motorul de validare al PE va include

reguli de constrângere pentru prescrierea medicamentelor în funcţie de vârsta pacientului. De cele mai multe ori este vorba de contraindicaţii de medicamente prescrise copiilor. Este necesară rafinarea constrangerilor la nivel de denumire comercială pentru medicamente deoarece aceeaşi substanţă activă, în funcţie de concentraţie sau de forma de prezentare este sau nu contraindicată copiilor. Raspunsul la aceast tip de contrângere va fi unul de atenţionare.

○ Relaţii între medicamente şi starea de graviditate. Motorul de validare al PE va conţine reguli de constrângere pentru prescrierea medicamentelor la gravide, lăuze şi femei care alăptează. Raspunsul la aceast tip de contrângere va fi unul de atenţionare.

○ Relaţii între medicamente şi IMC. Motorul de validare al PE va conţine reguli de constrângere pentru prescrierea de medicamente în funcţie de IMC.

○ Relaţii între medicamente şi indicatorul de sex. Motorul de validare al PE va conţine reguli de prescriere a medicamentelor în funcţie de indicatorul de sex. De exemplu, conform Protocolului definit de Ministerul Sănătăţii TESTOSTERONUM are prescriere limitată: Deficit androgenic la bărbaţi de cauză primară testiculară sau secundară hipotalamo-hipofizara (confirmat prin nivel plasmatic al testosteronului la cel putin 2 determinari în două dimineţi diferite mai mic sau egal cu limita inferioară a valorilor reactivului utilizat).

○ Relaţii complexe. De exemplu, conform Protocolului de prescriere al medicamentelor definit de Ministerul Sănătăţii medicamentul ORLISTAT se poate prescrie pentru un IMC≥ 35 pentru pacienţi cu vârste între 18 şi 26 de ani, caz în care trebuie combinat IMC cu vârsta.

● Dependenţe complexe. Motorul de validare al PE va conţine reguli complexe de prescriere a medicamentelor care să includă atât diagnostice cât şi caracteristici sau stări personale, cu relaţii de incluziune sau de excluziune între elemente. De exemplu conform Protocolului A001E definit de Ministerul Sănătăţii medicamentul ORLISTAT se poate prescrie pentru (IMC) ≥ 30 Kg/mp cu prezenţa a cel puţin uneia din următoarele comorbidităţi: diabet zaharat tip II, dislipidemie, boală coronariană ischemică, HTA controlată terapeutic, steatoză hepatică, steato-hepatită, apnee de somn, artroze, osteoartrite, hipercorticism reactiv, tulburare gonadică.

● Avertizări cu privire la supradozaj. Aplicaţia va defini reguli de atentionare în ceea ce priveşte dozajul maxim admis pentru un pacient. În calcul trebuie să se includă toate medicamentele prescrise de orice medic (de familie sau din ambulatoriu de specialitate) pentru un pacient pentru o perioada de timp configurabila împreună cu datele personale ale pacientului (vârstă, greutate). Răspunsul transmis de sistem trebuie să fie la nivel de alertă deoarece e posibil ca nu toate reţetele prescrise de medici să fie şi eliberate către pacient.

Motorul de validare va asigura suport pentru urmatorul set minim de reguli de validare în ceea ce priveste activitatea de eliberare a prescripţiilor medicale:

Pagina 2

● Obligativitatea respectării DCI la eliberearea medicamentului. Motorul de validare al PE va conţine reguli de contrângere prin care medicamentul eliberat, definit la nivel de denumire comercială, să conţină exact aceeaşi substanţă activă ca medicamentul prescris. Raspunsul sistemului în cazul nerespectării acestei constrângeri trebuie să fie eroare.

● Obligativitatea coroborării între concentraţie şi cantitate. Motorul de validare al PE va conţine reguli de constrângere referitoare la cantitate şi concentraţia de substanţă activă a medicamentului eliberat faţă de cantitatea şi concentraţia medicamentului prescris. În unele cazuri este permisă schimbarea concentraţiei cu condiţia schimbării cantităţii de medicament prescrisă. De exemplu este permisă o concentraţie înjumătăţită dacă se dublează cantitatea. În cazul descris mai sus este util un mesaj de atenţionare.

● Obligativitatea respectării formei de prezentare. Motorul de validare al PE va contine reguli de constrângere prin care la eliberarea unui medicament se păstrează forma farmaceutică prescrisă de medic. Încălcarea acestei constrângeri generează un mesaj de eroare.

Avertizări cu privire la supradozaj. Aplicaţia trebuie să permită definirea regulilor de constrângere cu privire la dozajul maxim admis pentru un pacient. În calcul trebuie să se includă toate medicamentele eliberate de orice farmacie pentru un pacient împreună cu datele personale ale pacientului (vârstă, greutate) pentru o perioada de timp configurabila. Raspunsul transmis de sistem trebuie să fie la nivel de alertă sau de eroare, în funcţie de efectele supradozajului.

Cadrul normativ actual de prescriptie a retelor

Urmatoarele informatii vor trebui obtinute prin interogarea sistemului SIUI:

● Nomenclatorul de boli şi maladii CIM10● Lista medicamentelor şi dozajelor indicate pentru fiecare maladie din CIM10● Lista contraindicaţiilor pentru fiecare medicament versus maladii din CIM10● Lista incompatibilităţilor intre poziţiile din DCI● Lista contraindicaţiilor pentru fiecare medicament versus alergii● Lista cuprinzând DCI ale medicamentelor ● Metodologia de stabilire a preţurilor

○ Lista preţurilor de referinţă pe unitate terapeutică aferente medicamentelor (denumiri comerciale) din Catalogul naţional al preţurilor medicamentelor de uz uman autorizate de punere pe piaţă (CANAMED)

○ Contractul - cadru privind condiţiile acordării asistenţei medicale în cadrul sistemului de asigurări sociale de sănătate. Modalităţile de prescriere, eliberare şi de decontare a medicamentelor cu şi fără contribuţie personală în tratamentul ambulatoriu se stabilesc prin Normele metodologice de aplicare a contractului-cadru. Normele prevăd următoarele coordonate privind precripţiile medicale:

○ Medicamentele cu şi fără contribuţie personală se acordă în tratamentul ambulatoriu, pe bază de prescriere medicală eliberată de medicii care sunt în relaţii contractuale cu casele de asigurări de sănătate;

○ Eliberarea medicamentelor cu şi fără contribuţie personală se face de către farmaciile autorizate de Ministerul Sănătăţii, în baza contractelor încheiate cu casele de asigurări de sănătate;

○ Suma maximă care se suportă de casele de asigurări de sănătate din FNUASS (Fondul National Unic de Asigurări Sociale de Sănătate) pentru fiecare medicament corespunzator DCI-ului din lista este cea corespunzatoare aplicării unui procent de compensare asupra preţului de

Pagina 2

referinţă pentru DCI-urile cuprinse în sublistele A, B si C, respectiv pretul de decontare pentru medicamentele la care nu se stabileşte preţ de referinţă din lista aprobată prin Ordinul Ministrului Sănătăţii;

○ Procentul de compensare pentru medicamentele corespunzatoare D.C.I.-urilor prevazute în sublista A este de 90% din preţul de referinţă, pentru cele din sublista B este de 50% din preţul de referinţă, iar pentru cele din sublista C este de 100% din preţul de referinţă. Preţul de referinţă reprezintă preţul cel mai mic corespunzător unităţii terapeutice aferente aceleiaşi forme farmaceutice din cadrul DCI şi pentru fiecare concentraţie;

○ Medicii stabilesc modul de prezentare al medicamentelor prescrise si le prescriu sub forma denumirii comune internaţionale (DCI sau substanţa activă);

4. Modulul eliberare

Acest modul va susţine din punct de vedere logic procesul de eliberare integrală sau parţială al prescripţiilor medicale.

Cerinte minime obligatorii:

● Eliberarea prescripţiilor medicale de către furnizorii de servicii farmaceutice presupune, în mod implicit, faptul că acestea sunt conforme normelor de eliberare si ca sunt verificate de catre motorul de validare bazat pe regulile de business.

● Interfaţa pusă la dispoziţie de acest modul va fi bazată pe servicii web, iar specificaţiile de integrare vor putea fi puse la dispoziţia entităţilor interesate pentru dezvoltarea aplicatiilor terte destinate uzului furnizorilor de servicii farmaceutice.

● Va apela modulul de validare pentru realizarea verificarilor necesare in procesul de eliberare.

Pagina 2

5. Extinderea sistemului SIUI Pentru extinderea sistemului SIUI in vederea introducerii PE, Ofertantul va folosi mecanisme programatice astfel incat sa se foloseasca un set minim de fluxuri de date, dupa cum urmeaza:

● Transferul informaţiilor legate de validarea şi eliberarea prescripţiilor, lista medicamentelor omologate, precum si cataloage, nomenclatoare, registre.

● Furnizorii de servicii medicale, pentru validarea prescripţiilor pe baza regulilor de business existente sau alte operatii realizate în mod curent de acest grup de utilizatori. Se va folosi o comunicatie online prin servicii web.

● Furnizorii de servicii farmaceutice, pentru trimiterea notificarilor referitoare la prescripţiile eliberate, vizualizarea şi eliberarea prescripţiilor, etc. Se va folosi o comunicatie online prin servicii web.

6. Modulul de integrare

Modulul de integrare va asigura conectivitatea dintre entitatile logice deja existente in sistemul SIUI (de exemplu: cataloage, nomenclatoare, registre) si Prescriptia Electronica prin intermediul serviciilor web. Astfel se vor asigura scalabilitatea si robustetea solutiei implementate precum si posibilitatea de interconectare facila cu cardurile CEAS si Dosarul Electronic de Sanatate.

Pentru realizarea modului de integrare se vor considera urmatoarele standarde:

● HTTP

● SOAP

● WSDL

● UDDIOfertantul va avea in vedere securizarea comunicatiei prin incapsularea informatiilor transmise prin intermediul protocolului HTTP in flux SSL/TLS.

Sistemul Informatic Unic Integrat (SIUI) expune serviciile web cu ajutorul pachetului AXIS pus la dispozitie de Apache Software Foundation, o implementare a protocolului SOAP publicat de W3C (WWW,Consortium). Pachetul AXIS a fost conceput pentru a fi utilizat in cadrul unui container Web, acesta fiind în cazul SIUI serverul Tomcat.

Functionalitatile expuse de sistemului SIUI prin intermediul serviciilor web sunt descrise in Anexa 1 iar definitiile serviciilor web sunt prezentate in Anexa 2.

Pagina 2

7. Solutia de management a infrastructurii IT

Soluția propusă trebuie să poata adresa administrarea ciclului de viață al serviciilor IT. Acest lucru se realizeaza prin implementarea de procese și instrumente specifice, raspunzand astfel nevoilor organizației IT; nevoi aliniate cu obiectivele de business. Aceste procese de business adreseaza cresterea eficientei in operare, reducerea riscurilor si optimizarea costurilor la toate nivelele IT. Componentele solutiei propuse trebuie să inglobeze bune practici in domeniul managementului in IT folosind servicii și hardware intr-o abordare integrata.

Soluția pentru managementul infrastructurii IT trebuie sa ofere facilitati ce au in vedere optimizarea activităților si implicit a costurilor, cresterea calitatii serviciilor oferite, cat și creșterea beneficiilor din investițiile in IT. Astfel, solutia va ajuta la luarea de decizii si la alocarea de resurse in functie de priorități pentru a creste disponibilitatea serviciilor si a optimiza costurile, automatizarea proceselor pentru creșterea eficienței și, în același timp, pentru a avea controlul asupra acestora si pentru validarea conformității si activității de optimizare.

Din punct de vedere functional, soluția propusă trebuie să acopere managementul operațional al serviciilor și al infrastructurii IT prin:

● Reducerea riscurilor si costurilor asociate cu operarea serviciilor IT prin vizibilitate și control asupra serviciilor critice in productie, pornind de la construirea automata a hartii serviciilor. Harta serviciilor include relaţiile dintre servicii IT, aplicaţii, infrastructură şi componente de reţea urmata de folosirea acestora pentru:● Identificarea impactului asupra serviciilor in urma detectarii unei erori la nivel

de infrastructura si/sau servicii prin monitorizarea automata● Identificarea rapida a cauzelor care duc la degradarea calitatii serviciilor● Controlul si planificarea schimbarilor

● Imbunatatirea calitatii serviciilor prin monitorizarea proactivă a performantei lor precum și a întregului mediu IT.

● Cresterea productivitatii organizatiei IT prin automatizarea proceselor si a altor componente de administrare manuala și repetitive, automatizare care permite eliminarea acestora si care are ca rezultat subsidiar si eliminarea erorilor umane, deci reducerea riscurilor.

Solutia pentru monitorizarea calitatii serviciilor va fi solutie intregrata care permite organizațiilor să optimizeze disponibilitatea, performanţa şi eficienţa serviciilor.

Solutia pentru monitorizarea calitatii serviciilor va include un CMDB, o bază de date folosită pentru administrarea configuraţiilor pentru a documenta şi stoca definiţiile serviciilor IT şi relaţiile de infrastructură asociate acestora. Aceasta va ajuta la integelegera impactului unei întreruperi sau a unei degradări a calității serviciilor asupra activităţii organizației.

Solutia pentru monitorizarea calitatii serviciilor va desoperi în mod automat si fara agenti mediul IT și va popula baza de date CMDB cu harta conexiunilor dintre aplicaţii şi infrastructura corespunzătoare pentru a facilita managementului serviciilor. De altfel, aceasta va trebui sa descopere automat orice schimbare în infrastructură prin

Pagina 2

compararea datelor descoperite cu cele autorizate din CMDB astfel încât administratorii IT sa aibă o imagine actualizată aproape în timp real a serviciilor și a legaturilor acestora.

Solutia pentru monitorizarea calitatii serviciilor va măsuara în mod proactiv experienţa utilizatorului final prin executarea de tranzacţii controlate, repetabile și din locaţii multiple. Rezultatele monitorizarii permit indentificarea proactiva a potentialelor degradari ale nivelului de serviciu,oferindu-se posibilitatea de a reactiona rapid in acest caz și, in acelasi timp, oferă informații care pot fi folosite pentru a accelera triajul şi soluţionarea problemelor atunci când este cazul.

Solutia pentru monitorizarea calitatii serviciilor, prin intermediul componentei pentru diagnostic, va pune la dispoziţie o abordare „top-down”, „end-to-end” privind monitorizarea, trierea şi diagnosticare problemelor critice cu aplicaţii .NET, SAP, Oracle, Siebel, J2EE, SOA, şi Java.

Prin abordarea integrată, solutia pentru monitorizarea calitatii serviciilor va prezenta o vedere completă asupra starii mediului IT şi unelte pentru a putea identifica rapid zona sau cauza de bază a problemelor prin corelarea evenimentelor.

Solutia pentru monitorizarea calitatii serviciilor trebuie sa permita măsurarea experienţei online a utilizatorilor interni sau externi. Administratorii IT vor putea apoi evalua impactul asupra activităţii rezultate din problemele de performanţă şi datorită perioadelor de inactivitate, prin izolarea caracteristicilor utilizatorului în detaliu. Solutia trebuie sa asculte fiecare solicitare şi răspuns trimise către şi de la serverele web. Aceasta va organiza datele pe sesiune pentru o analiză ulterioară şi pentru a ajuta echipele IT din mai multe departamente sau companii să colaboreze. Procesul Real User Monitor arată fiecare cale de navigare şi identifică numărul de utilizatori. Solutia va ajuta astfel personalul IT să identifice cu rapiditate cauzele de bază aferente infrastructurii, din care rezulta problemele utilizatorului final.

Solutia pentru monitorizarea calitatii serviciilor va permite administrarea nivelurilor de servicii şi asigura raportarea de conformitate cu SLA pentru aplicaţii și servicii complexe în medii distribuite. Aceasta va permite administratorilor IT să definească obiective de performanţă şi disponibilitate realiste, cuantificabile care să reflecte scopul activitatilor, să măsoare performanţa şi disponibilitatea serviciilor aşa cum se vede din perspectiva utilizatorilor finali, să dispună de un catalog ierarhic al serviciilor IT, să izoleze şi să soluţioneze problemele legate de performanţă, înainte ca obiectivele privind nivelul serviciilor să fie nerespectate.

2. Componente functionale1. Administrare si monitorizare

Sistemul va contine o componentă însărcinată cu funcţionalităţile necesare administrării sistemului precum şi cu monitorizarea funcţionării acestuia în vederea urmăririi îndeplinirii obiectivelor de performanţă şi disponibilitate.

Aceasta componenta trebuie sa raspunda urmatoarelor cerinte generale:

Pagina 2

● Definirea şi documentarea procedurilor şi proceselor necesare pentru operarea solutiei. Minimum urmatoarele cerinte vor fi acoperite de aceste proceduri şi definitii de procese:

○ Operarea şi administrarea solutiei în mod proactiv şi eficient○ Monitorizarea permanenta a functionarii sistemului cu alertarea anomaliilor

– erori sau avertizari legate de functionalitate.○ Readucerea sistemului în parametrii normali de operare○ Persoane cu nivel mediu de cunostinte IT şi a produselor solutiei sa poata

aplica procedurile definite.○ Procedurile vor cuprinde şi acele actiuni care permit:

■ reducerea timpului necesar activitatilor reactive şi legate de rezolvarea incidentelor

■ reducerea timpului în care sistemul nu este disponibil● Toate componentele solutiei vor inregistra principalele evenimente de succes de

eroare în jurnale specializate care indeplinesc urmatoarele cerinte:○ pot fi securizate pentru a limita accesul la aceste informatii○ permit consultarea lor directa de catre un operator uman ○ permit interpretarea prin metode programatice – sunt organizate intr-un

mod consistent şi structura este documentata.● Toate componentele hardware si software are solutiei respecta cerintele de

suportabilitate emise de producator.

2. Securitate informatica

Această componentă va asigura şi urmări operarea sistemului PE la nivelulul de siguranţă impus de importanţa critică a acestuia şi de natura datelor stocate si prelucrate.

Soluţia de securitate proiectată trebuie să asigure confidenţialitatea informaţiilor, ceea ce reprezintă o misiune critică. Informaţia dintr-un astfel de sistem trebuie protejată împotriva ameninţărilor în orice situaţie, fie când este stocată, fie când este transportată.

Instrumentele proiectate pentru asigurarea confidenţialităţii datelor trebuie sa asigure accesul utilizatorilor sistemului doar prin intermediul protocolului HTTPS, pentru a elimina posibilele încercări de interceptare a datelor când sunt transmise prin mediile de comunicaţie.

Solutia de securitate trebuie sa permita corelarea de evenimente aparent fara nicio legatura si date de tip NetFlow de la dispozitivele de retea, folosind tehnici avansate de corelare in timp real.

Solutia de securitate propusa trebuie sa includa o solutie de management al logurilor pentru a putea beneficia de cautari si investigatii asupra datelor structurate si nestructurate din loguri.

Solutia propusa va trebui sa puna la dispozitie, atat suport “out of the box” pentru cat mai multe dispozitive si aplicatii, cat si o arhitectura de colectare a evenimentelor, prin intermediul careia sa se poata include si produsele de nisa si aplicatiile customizate in vederea analizarii si crearii unei viziuni complete de securitate.

Solutia propusa va trebui sa includa regulile, alertele si rapoartele necesare pentru protectia CNAS. Orice regula sau raport va trebui sa poata fi extins sau adaptat usor prin folosirea unor metode care sa nu necesite cunostine de programare.

Pagina 2

Se doreste ca solutia de securitate propusa sa ofere o semnificatie evenimentelor de securitate prin plasarea lor intr-un context: ce, unde, cand si de ce a avut loc fiecare eveniment. Alertele in timp real vor pune la dispozitie administratorilor evenimentele critice de securitate si conformitate, alaturi de contextul necesar pentru a putea analiza si inlatura ulterior o bresa de securitate descoperita.

Solutia va trebui sa adreseze, de asemenea, cerintele de conformitate cu standardele relevante in domeniu si va trebui sa dispuna de abilitatea de stocare a logurilor, precum si de reluarea unor rapoarte predefinite de conformitate pentru a inlesli auditurile.

Pagina 2

3. Autentificare si autorizareAceastă componentă este destinată controlului accesului utilizatorilor interni sau externi la funcţiile sistemului, pe baza drepturilor de acces specifice pentru fiecare categorie şi grup de utilizatori.

Este necesar să se implementeze cel puţin următoarele funcţionalităţi:

● Posibilitatea restricţionării accesului utilizatorilor privilegiati la datele manipulate de aplicatiile de business, prin segregarea responsabilităţii.

● Solutia va permite autentificarea furnizorilor de servicii medicale si farmaceutice pe baza certificatelor digitale calificate.

● Certificatele digitale calificate trebuie validate la momentul accesului in sistem prin protocolul OCSP.

● Solutia va permite autentificarea persoanelor asigurate pe baza cardurilor CEAS- obligatoriu si exclusiv, din momentul introducerii acestora.

4. Audit si controlAcestă componentă va îndeplini atât funcţiile de audit informatic cât si funcţiile de audit, control şi combatere a fraudei specifice domeniului de funcţionare.

Solutia va indeplini urmatoarele cerinte generale:

● Se va pastra un istoric de tip log al activitatii utilizatorilor din sistem.● Va permite includerea informatiilor despre momentul in care au fost modificate

anumite seturi de date de catre utilizatori

5. Help-deskSolutia se va integra in sistemul de help-desk existent al CNAS si va oferi preluarea cererilor venite din partea medicilor prescriptori in cadrul procesului de prescriere a retetelor prevazut in prezentul caiet de sarcini, inclusiv pentru situatii de urgenta.

Solutia va respecta urmatoarele cerinte generale:

● Preluarea si inregistrarea cererilor ● Autentificarea utilizatorilor.● Gestionarea şi dirijarea cererilor.● Tratarea primară a cererilor.● Transmiterea cazurilor care nu pot fi tratate către personalul specializat in vederea

solutionarii.● Evidenţa informatizată a trasabilităţii între cazul raportat, starea acestuia, modul

de rezolvare şi timpul parcurs intre raportare si rezolvare, etc.

Pagina 2

3. Cerinte nefunctionale1. Software de Gestiune a Bazelor de Date

Software-ul de gestiune al bazelor de date va respecta urmatoarele cerinte:

1. Sa fie un sistem de gestiune a bazelor de date de tip relational2. Sa permita minimizarea conflictelor de acces la date si garantarea simultaneitatii

accesului la date3. Sa permita reorganizarea, mutarea si redefinirea de tabele fara blocarea activitatii4. Sa fie compatibila cu standardul ANSI SQL 5. Sa permita in mod nativ stocarea si gestiunea de structuri de date de tip XML6. Sa ofere suport pentru proceduri stocate si triggeri7. Sa ofere suport pentru tranzactii autonome8. Sa permita executia paralela a operatiilor cu blocarea doar a inregistrarilor

afectate, nu a intregii tabele9. Sa permita definirea de tabele de tip index pentru acces rapid la anumite tabele10. Sa ofere mecanisme integrate in baza de date pentru anularea unei tranzactii care

a fost comise, fara a fi necesara restaurarea dintr-un backup sau intretinerea prin proceduri de utilizator a unor copii ale datelor

11. Sa permita limitarea numarului de conexiuni la baza de date prin folosirea unui mecanism de tip database connection pooling

12. Sa ofere suport complet pentru folosirea de expresii regulate13. Sa permita restrictionarea accesului la nivelul obiectelor bazei de date14. Sa ofere o lista cu operatiile pe care un grup sau o clasa de utilizatori le poate

executa15. Sa pemita salvarea totala si/sau partiala a bazei de date16. Sa permita salvarea pentru unul sau mai multe spatii alocate tabelelor asa cum

este specificat de catre administratorul bazei de date17. Sa ofere posibilitatea de rulare pe diverse platforme hardware si pe sistemele de

operare majore de pe piata (Windows, Linux si UNIX)18. Sa permita compresia datelor stocate in tabele pentru a minimiza spatiul de

stocare19. Sa permita instalarea unei singure baze de date pe mai multe noduri (arhitectura

de tip cluster) pentru a asigura toleranta la defecte hardware sau nefunctionare planificata, scalabilitatea si disponibilitatea crescuta a sistemului

20. Sa permita stoparea temporara a unui nod din clusterul de baza de date pentru mentenanta, suport sau upgrade, sistemul ramanand disponibil in tot acest timp

21. Sa ofere securitate tranzactionala in cazul aparitiei unor erori hardware sau software in clusterul de baza de date

22. Sa ofere capabilitati incluse de monitorizare si diagnosticare continua a starii bazei de date in scopul identificarii potentialelor probleme de performanta

23. In scopul reducerii riscului accesului neautorizat la date, baza de date trebuie sa puna la dispozitie facilitati de control preventiv al accesului utilizatorilor privilegiati (de tip super-user sau administrator), pe baza principiului separarii responsabilitatilor.

24. Baza de date trebuie sa ofere capabilitati independente si transparente fata de aplicatii care sa permita protectia datelor fata de utilizatorii cu drepturi extinse (administratori), limitind atit accesarea cit si modificarea bazei de date.

Pagina 2

25. Sa utilizeze mecanisme de partitionare la nivelul obiectelor din baza de date (tabele, indecsi).

2. Serverul de web

Serverul web trebuie sa respecte urmatoarele cerinte:

1. Suport pentru SSL2. Sa permita extensia functionalitatilor pe baza de plugin-uri sau module3. Serverul web trebuie sa dispuna de plugin-uri astfel incat sa permita utilizarea ca

server de interfata pentru serverul de aplicatii4. Sa permita integrarea cu solutii de accelerare hardware a criptarii/decriptarii5. Sa permita operarea in mod reverse-proxy6. Sa dispuna de functionalitati de rescriere a adreselor URL7. Sa dispuna de mecanisme de balansare a incarcarii8. Sa permita configurarea intr-un mod de disponiblitate ridicata9. Sa permita rularea continutului dinamic, oferind suport cel putin pentru

tehnologiile PHP, JSP, C++10. Sa ofere o zona tampon continut (Web Cache)11. Sa permita rularea serverului web pe distributiile majore de sisteme de operare

prezente pe piata (Windows, Linux si UNIX)

Pagina 2

3. Software pentru serverul de aplicatie

Serverul de aplicatie trebuie sa respecte urmatoarele cerinte:

1. Compatibil cu specificatiile platformei JEE sau echivalent;2. Suport complet pentru specificatiile Java Servlets 2.3, 2.4 si 2.5 sau echivalent;3. Suport complet pentru specificatiile JavaServer Pages 1.2, 2.0 si 2.1 sau

echivalent;4. Suport complet pentru specificatiile Enterprise JavaBeans 2.0, 2.1, 3.0 sau

echivalent;5. Suport pentru servicii web conform specificatiilor WS-I Basic Profile 1.0 si 1.1;6. Suport complet pentru servicii web utilizind specificatiile JAX-WS 2.0 si JAX-RPC

1.1 sau echivalent;7. Suport pentru Simple Object Access Protocol (SOAP) versiunile 1.1 si 2.0 si SOAP

with Attachments API for Java (SAAJ);8. Transformarea datelor in format XML utilizind standardul W3C Extensible

Stylesheet Language (XSL);9. Citirea si scrierea datelor in format XML utilizind interfetele de programare

standard Document Object Model (DOM) si Simple API for XML (SAX) si specificatia Streaming API for XML (StAX) sau echivalent;

10. Suport complet pentru standardul Java Database Connectivity (JDBC) versiunile 2.1 si 3.0 sau echivalent;

11. Suport pentru conectarea la multiple sisteme de gestiune a bazelor de date relationale (SGBDR);

12. Suport complet pentru standardul Java Messaging Service (JMS) versiunile 1.0 si 1.1 sau echivalent;

13. Suport complet pentru managementul tranzactiilor utilizind specificatia Java Transaction API (JTA) versiunile 1.0 si 1.1 sau echivalent;

14. Stoparea temporara a unui nod din cluster pentru mentenanta si suport, sistemul in acest timp fiind disponibil pentru activitati normale;

15. Sa permita rularea serverului de aplicatii pe toate distributiile majore de sisteme de operare prezente pe piata: Windows, Linux si UNIX.

Pagina 2

4. Sistemul de management al regulilor de businessSistemul de management al regulilor de business va deservi din punct de vedere informatic modulul validare. Deoarece un BRMS conţine cel puţin doua componente si anume un motor de rulare a regulilor (BRE) şi un instrument de modelare a regulilor, descrierea cerinţelor va fi organizată pe cele 2 componete separat. Unele cerinte descrise la aceste componente pot fi implementate in diferite BRMS in alte componente specializate

a. Instrumentul de modelare a regulilorCerinte obligatorii:

● Creare/gestionare vocabular de entitati si atribute. De exemplu, entităţile gestionate pot fi persoană, reţetă, etc iar exemple de atribute sunt greutate, indicator de sex pentru persoane şi diagnostic, substanţă activă pentru reţete.

● Creare/gestionare seturi de valori posibile pe atributele vocabularului. Instrumentul de modelare a regulilor trebuie să permită definirea de seturi de valori ale atributelor conform metricilor specifice atât tipului fiecărui atribut cât şi logicii specifice. Seturile de valori trebuie să poată fi reprezentate ca:

○ enumerare de valori - de exemplu M, F pentru indicatorul de sex○ intervale - de exemplu grupele de vârsta, exprimată în luni sau ani○ liste - de exemplu diagnosticele○ colecţii de alte atribute - de exemplu adresa care poate fi descompusă

în oras, strada, numar, etc● Creare/modelare de seturi de reguli de business pe baza de entitati, atribute si

operatori cu obtinere de rezultate (valori sau actiuni). Această cerinţă este nucleul oricărui instrument de modelare a regulilor.

● Sistem de autorizare şi aprobare a modelării şi testării seturilor de reguli

b. Modulul de rulare a regulilorCerinte obligatorii:

● Posibilitate rulare a seturilor de reguli în servere native şi/sau ca şi componente în servere existente (J2EE, .NET, WebServer, etc).

● Posibilitate de functionare în sisteme de tip cluster/fault tolerance/load balancing.

● Sistem de autorizare şi aprobare a încărcării şi rulării seturilor de reguli.● Programare intervale de timp de valabilitate a regulilor. ● Posibilitatea apelarii regulilor via WebServices

5. Solutia de management a infrastructurii IT1. Ofertantul trebuie sa propuna o solutie integrata produsa de acelasi vendor si

disponibila comercial (COTS) pentru managementul calitatii serviciilor in intregul ciclu de viata al acestora de la etapa de pre-productie si testare pana la operarea in productie. Scopul solutiei de management este eficientizarea activitatii in organizatia IT, controlul si reducerea costurilor precum si cresterea calitatii serviciilor oferite, bazat pe bune practici si automatizarea proceselor.

Pagina 2

1. Managementul operational al infrastructurii si serviciilor

1. Soluția pentru monitorizarea infrastructurii IT (hardware și software) trebuie să asigure un management cuprinzător al evenimentelor, o monitorizare proactivă a performanţei, precum şi un sistem automatizat de alertare, raportare şi realizare grafice pentru elemente de rețea, sisteme de operare Windows, Linux şi UNIX, pachete software dezvoltate intern sau adaptate şi aplicaţii de tip Oracle.

2. Solutia se va licentia conform infrastructurii propuse.3. Soluția trebuie să ofere o platforma integrată și centralizată pentru monitorizare

cu următoarele caracteristici:a. Monitorizarea integrată a elementelor de infrastructura legate de rețea,

sisteme, aplicații eterogene. Se va oferi suport pentru dispozitive de rețea provenind de la diferiți producători; sisteme de operare – diferite tipuri de OS Microsoft Windows, diferite tipuri de OS Unix; tipuri de aplicații – baze de date, servere de internet etc.

b. Crearea (descoperirea automată) și prezentarea de harți care să prezinte legăturile dintre diferite componente de infrastructura (elemente de rețea, servere, aplicații) pentru a oferi o imagine totala a serviciilor

c. Generarea și prezentarea în interfața grafica de evenimente cu întârzieri cât mai mici în cazul în care apar situații de excepție.

d. Afișarea stării serviciilor în timp real prin intermediul tabloului de borde. Colectarea datelor de performanță despre infrastructură și servicii și

raportare a acestora.f. Definirea de diferite grade de prioritate pentru evenimente în funcție de

gravitatea lorg. Păstrarea evenimentelor într-o baza de date relațională accesibilă prin

ODBC. h. Folosirea de standarde în soluție: comunicarea între componente bazata pe

protocoale standard, folosirea de limbaje de programare standardi. Capabilități de monitorizare predefinite incluse cu soluția propusă pentru

tehnologiile oferitej. Capabilități de monitorizare combinate cu agent si fara agentk. Ușor de folosit și configurat: interfața grafica nativa și web; configurare prin

interfața grafică; folosirea de limbaje de programare cunoscutel. Integrarea diferitelor utilitare și aplicații pentru operarea eficienta a

infrastructurii oferite.m. Diagnosticarea problemelor aplicațiilor Java, .NET, SAP, Oracle, MS SQL,

WebSphere MQn. Monitorizarea calității serviciilor din perspectiva utilizatorilor finalio. Definirea și monitorizarea parametrilor SLA ai serviciilor

2. Monitorizarea sistemelor si a aplicatiilor1. Componenta de monitorizare fara agenti

1. Soluţia trebuie să includa capabilitaţi de monitorizare fara agenti a infrastructurii IT, a serviciilor IT şi a performanţei aplicaţiilor integrate intr-un tablou de bord.

2. Monitorizarea trebuie să se realizeze cu o singura aplicație, fara agenti instalati pe sisteme sau pe serverul de monitorizare;

Pagina 2

3. Vendorul trebuie să dispună de șabloane standard pentru monitorizarea de aplicatii enterprise gen Oracle, SQL Server etc. care să poată fi achiziționate ulterior;

4. Soluția trebuie să permită configurarea de sabloane noi pentru aplicatii non-standard sau pentru metode de monitorizare conform proceselor organizației;

5. Soluția trebuie să permită extinderea prin module aditionale produse de acelasi vendor. Acestea trebuie să ofere functionalitati de creare a serviciilor IT și a dependintelor dintre acestea intr-un CMDB; monitorizarea serviciilor; corelarea evenimentelor; testarea performantei;

6. Soluția trebuie să poată initia actiuni corective cum ar fi restartarea echipamentelor, curatarea spatiului de pe disk și executarea comenzilor;

7. Soluția trebuie să dispuna interfata grafica Web ce poati fi personalizata în funcție de rol;

8. Soluția trebuie să include metode de notificare cum ar fi: e-mail, SNMP trap, pager, POST, și alerte în baze de date;

9. Soluția trebuie să monitorizeze sisteme Windows, Linux și UNIX precum și metodele de conectare specific cum ar fi TELNET, rlogin, HTTP, SSH, and NetBIOS;

10. Soluția trebuie să suporte nativ monitorizarea cel putin a urmatorilor parametrii de sistem: CPU utilization, Database, DHCP, Disk space, Memory, Network, NT event log, UNIX resources, Windows resources;

11. Soluția trebuie să suporte nativ monitorizarea cel putin a urmatoarelor aplicatii: Apache Web Server, BEA WebLogic Application Server, Cisco Works, IBM DB2, IBM WebSphere Application Server, JBOSS AS 4.x, Microsoft IIS 6.0, Microsoft SQL Server 2005, Oracle 10g Application Server, Oracle® JDBC, Sybase database, VMware ESX Server 3.x;

12. Soluția trebuie să suporte native monitorizarea Web: Link check, URL, Web Server, Web Service

13. Soluția trebuie să suporte native monitorizarea urmatoarelor servicii de retea: DNS, FTP, Network bandwidth, Ping, Port, SNMP.

2. Componenta tablou de bord1. Soluţia trebuie să ofere rapoarte şi să prezinte informaţii în timp aproape real

printr-o interfaţa web bazata pe roluri. Interfaţa trebuie să permită navigarea contextuala de la informaţii de nivel inalt pana la detaliu (drill down) pentru a putea fi utilizate de către personalul operaţional.

2. Prezentarea informaţiilor trebuie să fie bazata pe indicatorii cheie de performanţa (KPI-uri) care vor permite determinarea în timp aproape real a stării operaţionale a serviciilor IT, precum şi a impactului în timp.

3. Soluţia trebuie să ofere o modalitate de a determina imediat starea serviciilor afişand impactul pe baza KPI-urilor prezentate în mod grafic şi folosind coduri de culori. Acest algoritm trebuie să fie bazat pe o ierarhie constand în elemente de infrastructura, containere virtuale şi reguli de calcul. Toate aceste funcţii trebuie să fie personalizabile.

4. Tabloul de bord trebuie să ofere posibilitatea de a accesa rapoartele pentru fiecare dintre funcţiile integrate. Trebuie să se ofere funcţionalitatea de a tipari rapoartele sau de a le exporta în diferite formate (pdf, csv, xml).

5. Tabloul de bord trebuie să ofere capabilitaţi de filtrare. 6. Informaţiile legate de componentele infrastructurii IT şi serviciile IT vor fi stocate

intr-o Baza de Date de Management a Configuraţiilor (CMDB), cu detalierea componentelor de infrastructura (CI), a atributelor lor şi relaţiilor dintre ele.

Pagina 2

7. Soluţia trebuie să includa un model extensibil pentru CMDB cu diferite tipuri de CI-uri. Soluţia trebuie să permită adăugarea de atribute CI-urilor existente, precum şi definirea de noi tipuri de CI-uri, în funcţie de necesitaţi.

8. Soluţia trebuie să suporte definirea de diverse relaţii între diferite componente.9. Soluţia trebuie să suporte filtrarea informaţiilor din CMDB pentru a crea diferite

vederi ce vor fi folosite pentru alte funcţionalitaţi, cum ar fi tabloul de bord, raportare, etc. Datele din CMDB trebuie să fie baza vizualizarilor din tabloul de bord.

3. Componenta diagnosticare aplicatii1. Monitorizarea în timp real a serverelor de aplicatii compatibile cu standardul Java

2 Enterprise Edition (J2EE) sau echivalent2. Colectarea metricilor de executie se va face prin tehnologicii de tip agent cu

impact minim asupra performantei sistemelor monitorizate3. Sa permită activarea/dezactivarea monitorizarii aplicațiilor fara intreruperea

functionarii acestora (Hot Deployment)4. Posibilitatea de diagnosticare a aplicațiilor Java sau echivalent prin analiza

detaliata a executiei la nivel de:a. memorie ocupata;b. fire de executie;c. sesiuni de date

5. Capabilitati de analiza detaliata a obiectelor stocate în memorie la un moment dat dupa criterii multiple: tipuri de obiecte, dimensiune ocupata, ierarhie de obiecte, dependente între obiecte

6. Capabilitati de capturare a continutului memoriei la intervale de tip discrete cu facilitati de comparare a datelor colectate

7. Monitorizarea stării firelor de executie și detectarea situatiilor de tip asteptare obiect, asteptare date, asteptare I/O sau deadlock

8. Corelarea cererilor client cu firele de executie asociate și mai departe cu conexiunile către bazele de date ce faciliteaza accesul la informații

9. Analiza în detaliu a timpilor de executie a unei cereri pe fiecare nivel al aplicației (prezentare, logica de business, baza de date)

10. Rapoarte predefinite pentru identificarea cererilor client cele mai consumatoare de resurse

11. Rapoarte predefinite pentru identificarea componentelor aplicației care consuma cele mai resurse

12. Sa detecteze componentele și codul cu o performanta scazuta în mediul de productie sau pre-productie.

13. Sa sigure vizibilitate end-to-end în cadrul componentelor prin functionalitati de urmărire a tranzactiilor în cadrul unor nivele multiple

14. Sa identifice perfomantele cererilor primite și să ofere capabilitati de coreleare a acestora cu cererile trimise

15. Sa masoare latenta la nivel de consumator/furnizor de servicii 16. Sa descopere componente/cod neautorizate în timp real, pe masura ce acestea

apar17. Sa reduca Mean Time To Repair (MTTR) prin scaderea timpului de triaj al

aplicațiilor composite 18. Sa asigure o incarcare minimala în timpul colectarii datelor relevante de la

serverele monitorizate aflate în mediul de productie 24x7 19. Să afișeze unde anume în aplicație se asteaptă, fie pentru procesarea datelor, fie

pentru asteptarea unui raspuns din cadrul altei componente din aplicație 20. Să afișeze nivelurile de infrastructură cele mai lente

Pagina 2

21. Să afișeze cererile cele mai lente către server, care sunt puncte de intrare în aplicație

22. Să afișeze posibilele fire de execuție care contribuie la problemele de performanță 23. Să afișeze problemele de memorie 24. Să afișeze cele mai mari colectii de date sau cu cea mai mare rata de crestere 25. Să afișeze leaking objects, object growth trends, object instance counts, și byte

size for objects26. Să afișeze cele mai lente cereri SQL 27. Să afișeze numărul de exceptii și timeout-uri28. Să poată fi customizată facil pentru a monitoriza aplicatii astfel incat să poată

colecta metode și clase specifice, care nu sunt suportate default 29. Să ofere capabilitati de integrare cu instrumente 3rd party, în special

funcționalități de export de date pe baza de API-uri comune, log-uri sau baze de date

30. Să ofere notificări vizibile în GUI și via trap-uri SNMP pe baza regulilor de alertare și de notificare, ce vor fi lansate la momentul depășirii unor praguri specifice

3. Monitorizarea calitatii serviciilor1. Soluția de monitorizare a calității serviciilor bazată pe procesele de business

trebuie să nu incarce Solutia monitorizata cu mai mult decat incarcarea data de un utilizator.

2. Soluția de monitorizare a calității serviciilor trebuie să permită simularea unui proces de business din perspectiva utilizatorului final și să ofere suport pentru monitorizare din multiple locații;

3. Soluția de monitorizare a calității serviciilor trebuie să asigure simularea de procese de business complexe.

4. Soluția trebuie să monitorizeze performanta și disponibilitatea aplicației .5. Soluția de monitorizare a calității serviciilor trebuie să ofere rapoarte relevante

referitoare la performanta și disponibilitatea serviciilor pentru pașii configurați în procesul de business și pentru locațiile din care se realizează monitorizarea. Acolo unde este posibil, soluția trebuie să raporteze și timpii de răspuns detaliați la nivel tehnologic – cat a durat cererea de DNS, timpul petrecut de server pentru primul răspuns, etc…

6. Soluția de monitorizare a calității serviciilor trebuie să fie integrată cu tabloul de bord.

1. Managementul SLA-urilor1. Soluţia trebuie să ofere funcţionalitatea de a monitoriza nivelul serviciilor prin

definirea de SLA-uri, precum şi consolidarea şi procesarea KPI-urilor în conformitate cu SLA-urile şi regulile definite.

2. Capabilitatile oferite de managementul SLA-urilor trebuie să fie bazate pe datele oferite de aplicația de monitorizare a serviciilor și monitorizarea de infrastructură

3. Capabilitatile oferite de managementul SLA-urilor trebuie să fie bazate pe datele oferite de CMDB (folosind modelele de servicii deja definite în CMDB) .

4. Soluţia trebuie să permită definirea de diverse calendare pentru calculul SLA-urilor. Calendarele trebuie să fie flexibile şi să se permită definirea cu o granularitate la nivel de ore.

5. Soluţia trebuie să permită definirea de ferestre de indisponibilitate şi să le includa pe acestea în rapoarte. Trebuie să permită definirea ferestrelor de inactivitate retroactiv şi recalcularea SLA-urilor pe baza acestora.

6. Soluţia trebuie să includa suport pentru nivele de servicii implicite.

Pagina 2

7. Soluţia trebuie să ofere suport pentru obiectivele legate de disponibilitate, performanţa / timp de răspuns, MTTR, MTBF, conform cu datele obţinute din soluţia de Help Desk

8. Solutia de monitorizare a SLA-urilor trebuie să fie integrată cu tabloul de bord.

2. Monitorizarea serviciilor IT din perspectiva utilizatorilor finali

1. Solutia trebuie sa ofere capabilitati de administrare prin interfata web.2. Solutia trebuie sa nu incarce Solutia monitorizata cu mai mult decat incarcarea

data de un utilizator. 3. Produsul trebuie sa asigure simularea de procese de business complexe.4. Solutia trebuie sa ofere rapoarte detaliate despre traficul la nivel de aplicatie,

pagini si tranzactii predefinite. Deasemenea, trebuie sa dispuna de mecanisme pentru analizarea sesiunilor create de catre utilizatori.

5. Solutia trebuie sa suporte monitorizarea prin HTTP, TCP si SOAP.6. Solutia trebuie sa ofere capabilitati de urmarire pas cu pas a tranzactiilor din

cadrul unui proces, cu prezentarea grafica a interactiunilor dintre toate componentele sistemului. Inregistrarea tranzactiilor generate trebuie efectuata intr-o maniera neintrusiva.

7. Solutia trebuie sa ofere functionalitati de corelare a evenimentelor in cadrul a multiple aplicatii, sisteme de operare si statii.

8. Solutia trebuie sa includa informatii despre impactul asupra procesului de business.

9. In cadrul procesului de monitorizare a tranzactiilor, solutia trebuie sa ofere masuratori relevante pentru revizuirea cerintelor de capacitate

10. Solutia trebuie sa ofere capabilitati de interceptare a mesajelor si functionalitati de actionare in timp real pe baza continutului mesajelor, in scopul masurarii calitatii serviciilor furnizate catre clientii importatnti.

11. Solutia trebuie sa ofere posibilitatea de a realiza diagrame ale topologiei in scolpul identificarii arhitecturii mesajelor.

12. Solutia trebuie sa ofere capabilitati de descompunere a tranzactiilor de business in subcomponente, incluzand masuratori ca latenta retelei si “time on queue”

13. Solutia trebuie sa asigure posibilitatea capturarii de evenimente generate de utilizator si de aplicatii.

14. Solutia trebuie sa asigure identificare automata a tranzactiilor de business, necesitand activitati de reglare fina manuala minime.

15. Solutia trebuie sa ofere capabilitati de detaliere la nivel de atribute de mesaje

Pagina 2

6. Solutia de securitate informatica

1. Solutia trebuie sa fie oferita sub forma unui appliance (trebuie sa includa si licentele software), care sa dispuna de capabilitati de monitorizare a evenimentelor de securitate, precum si de management a logurilor si va cuprinde toate componentele hardware necesare functionarii depline, precum si licentele software, incluzand aici si licentele tertelor producatori.

2. Sa permita colectarea logurilor si monitorizarea unui numar de minim 700 de dispozitive de retea/securitate (servere, firewall-uri, IDS/IPS-uri, routere etc);

3. Sa dispuna de capabilitati de colectare, stocare si analiza ulterioara a log-urilor; 4. Sa ofere o rata de compresie a log-urilor de pana la 10:1;5. Sa ffere interogari dinamice si distribuite (trebuie sa suporte atat cautari simple

cat si cautari complexe bazate pe expresii regulate si expresii logice de tip Boolean).

6. Sa includa o baza de date relationala pentru stocarea log-urilor colectate;7. Sa ofere posibilitatea dezvoltarii ulterioare a solutiei intr-un mod cat mai facil (sa

fie scalabila); 8. Sa ofere posibilitatea identificarii de actiuni repetitive sau tiparuri de evenimente,

pe baza carora se pot seta reguli de alertare si se pot adopta politici de securitate.9. Sa transforme logurile colectate intr-un format comun (normalizat) si sa permita

categorizarea acestora in vederea efectuarii unei analize ulterioare cat mai facile;10. Sa dispuna de un motor de corelare care sa permita identificarea elementelor

comune din doua sau mai multe evenimente aparent fara nicio legatura;11. Sa permita accesul la aplicatie unui numar nelimitat de utilizatori prin intermediul

unei interfete de tip web;12. Sa ofere posibilitatea identificarii incidentelor de securitate IT in timp real pe baza

regulilor prestabilite si sa permita prioritizarea evenimentelor in functie de importanta;

13. Sa dispuna de un pachet de reguli de corelare si alertare care sa adreseze cele mai intalnite amenintari asupra securitatii unei retele, precum si posibilitatea modificarii acestor reguli functie de cerinte/necesitati;

14. Sa permita vizualizarea evenimentelor in timp real si intr-un format comun, inteligibil, din cadrul consolei de administrare, fara a fi necesara accesarea unei terte aplicatii;

15. Sa dispuna de abilitatea de a reprezenta dinamic intr-un mod grafic evenimentele desfasurate pentru a putea realiza amploarea unui atac, precum si pentru a putea identifica cu usurinta initiatorul acelui atac;

16. Sa permita acces la unelte de identificare a atacatorului: nslookup, whois, ping;17. Sa dispuna de diferite mecanisme de notificare: alerte la consola, e-mail, SNMP;18. Sa contina un modul de raportare, care sa includa atat rapoarte predefinite, cat si

posibilitatea modificarii acestora in functie de cerinte/necesitati;19. Sa permita exportarea rapoartelor cel putin in urmatoarele formate: PDF, XML,

HTML.20. Sa includa tablouri de bord grafice predefinite, precum si posibilitatea

personalizarii acestora pentru o imagine cat mai elocventa asupra nivelului de securitate; acestea trebuie sa poate afisa informatiile in timp real;

21. Sa beneficieze de mecanisme de criptare a comunicatiei logurilor catre dispozitivul de monitorizare, precum si de un mecanism de validare a integritatii logurilor, conform NIST 800-92 (Log Management Standard);

Pagina 2

22. Sa posede un mecanism de depozitare temporara a datelor si de retransmitere a lor in situatia in care comunicatia intre sursa generatoare de log si solutia de monitorizare este temporar indisponibila;

23. Sa ofere capabilitati de limitare/ajustare a folosirii latimii de banda in vederea transmiterii log-urilor din locatii geografice diferite

24. Sa ofere capacitati de corectare a marcii temporale a unui eveniment provenit de la un dispozitiv/sistem configurat/setat neadecvat;

25. Sa ofere posibilitatea dezvoltarii de reguli de alertare inlantuite (compuse din 2 sau mai multe reguli definite anterior);

26. Sa dispuna de posibilitatea filtrarii log-urilor bazata pe orice criteriu legat de informatiile continute in log-urile respective;

27. Sa puna la dispozitie un API (Application Programming Interface) pentru a permite normalizarea si managementul log-urilor provenite de la surse de evenimente/aplicatii proprietare sau care nu sunt suportate in mod implicit;

28. Sa fie capabila sa colecteze evenimente de la minim urmatoarele surse:a. Cisco Routerb. Cisco Pix Firewallc. Cisco Catalyst d. F5 Big IPe. HPUXf. IBM AIXg. Microsoft Windows 2000, 2003, 2008 Server, XP, Vistah. RedHat Linuxi. VMWare ESX Serverj. Oraclek. IBM DB2l. Microsoft Active Directorym. Microsoft Exchangen. Microsoft IISo. Microsoft SQLp. Apacheq. Juniper IDPr. Juniper Networks Firewall and VPNs. Juniper SSL VPN t. McAfee Intrushieldu. McAfee Virus Scanv. McAfee ePOw. McAFee FoundScanx. Saint Vulnerability Scannery. Snortz. Imperva Secure Sphere

4. Cerinte privind platforma hardware si infrastructura de comunicatie

Din punctul de vedere hardware, sistemul proiectat trebuie sa fie in concordanta cu arhitectura existenta a sistemului SIUI pentru valorificarea investitiei initiale a CNAS si, de

Pagina 2

asemenea, trebuie poata fi extins atat pe orizontala cat şi pe verticala iar din punct de vedere tehnologic solutia trebuie sa foloseasca o arhitectura deschisa organizata pe nivele de abstractizare care separa functionalitatile fiecarei componente.

PE trebuie sa contina, pe langa mediul de productie şi un mediu de testare şi instruire iar din punctul de vedere al disponibilitatii sistemul de productie trebuie sa indeplineasca urmatoarele cerinte:

● sa implementeze conceptul de arhitectura redundanta atat la nivelul componentelor hardware cat şi software

● sa aiba o arhitectura de inalta disponibilitate intr-un scenariu de tip single-site● sa fie disponibil şi utilizabil 24 ore/zi, 7 zile/saptamana, 365 zile/an cu un maxim

de 90 de ore de indisponibilitate planificata pe an● sa includa procese software, proceduri manuale de validare şi componente

hardware care impreună sa poată fi folosite pentru salvarea datelor critice din sistem şi să includă mecanismele pentru restaurarea acestor date

Arhitectura dorita pentru extinderea sistemului SIUI in vederea intruducerii PE are in vedere mentiunile din capitolul de dimensionare a sistemului; se doreste asigurarea functionarii sistemului in mod disponibilitate ridicata.

Pentru efectuarea salvarilor de siguranta (backup) se vor folosi echipamentele si aplicatiile de salvare/recuperare care deservesc sistemul SIUI iar pentru extinderea acestora ofertantul va avea in vedere livrarea driverelor de scriere, a benzilor de tip LTO 4 si a licentelor software astfel incat sa se acopere necesarul de capacitate si performanta, inclusiv in ceea ce priveste cresterea estimata pentru urmatorii trei ani.

Sistemul informatic central va fi proiectat astfel încat să funcţioneze în regim de înaltă performanţă şi disponibilitate şi va fi separat pe trei niveluri, conform celor mai bune standarde în domeniu: stocarea datelor, prelucrare şi prezentare.

Solutia propusa de Ofertant va fi compusa cel puțin din echipamente hardware echivalente cu cele prezentate mai jos1:

Numar Descriere Cantitate1 Sasiu servere blade tip 1 (productie) 22 Sasiu servere blade tip 2 (test) 23 Servere de baza de date tip 1(productie) 24 Servere de baza de date tip 2 (test) 25 Servere de aplicatie 56 Masiv stocare date 17 Masiv stocare date extern 28 Switch-uri Ethernet 7

In continuare sunt prezentate caracterisiticile componentele hardware prevazute:Articol 1Sasiu Servere Blade tip 1Format 18UDisponiblitate 99.9999Module inteconectare Conexiune SMP inter-blade-uri tip crossbar, 8GB per conexiune * 32

de conexiuniSistem de ventilatie Redundant, hot-swap

1 Se vor include surse de alimentare neintreruptubila cu energie electrica care sa permita, in cazul nefunctionarii retelei electrice, functionarea serverelor pentru minim 30 de minute.

Pagina 2

Servere blade 8 * blade-uri dual-cpu, quad-core, RISC/EPIC, 1.8GHz/24 MB CacheConectivitate Ethernet 2 * switch-uri 10 Geth cu cite 8 porturi uplink si 16 interneConectivitate SAN 2 * switch-uri FC 24 porturi de 8 GB, conectate 2 incinte cu cate 12

HDD SAS 300GB 15KRPM, RAID 0, 1, 3, 5, 6, 10, 50Management sistem Procesoare dedicate in fail-overAlte porturi Atasat de sasiu: incinte cu 24 porturi PCIe, populate cu 8 controloare

dp FC 8 GB si 8 controloare Geth qp

Garantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HW

Articol 2Sasiu Servere Blade tip 2Format 10UDisponiblitate 99.999Module inteconectare 2 * switch-uri FC 8 porturi uplink de 8 GB si 16 interne

2 * switch-uri 10 Geth cu cite 8 porturi uplink si 16 interneSistem de ventilatie Redundant, hot-plugServere blade Max 16Conectivitate Ethernet 2 * switch-uri 10 Geth cu cite 8 porturi uplink si 16 interneConectivitate SAN 2 * switch-uri FC 8 porturi uplink de 8 GB si 16 interne

Management sistem Procesor dedicat on-boardGarantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HW

Articol 3Server de baza de date tip 1 (multi-blade)Procesor 16 * RISC/EPIC, 1.8GHz/24 MB Cache, quad-coreMemorie 256 GB DDR3Subsistem stocare Conectat pe FC la 8 GB, conectate 2 incinte cu cite 12 HDD SAS

300GB 15KRPMControlor retea 32 porturi 10 Geth si 32 porturi GEthControlor fiber channel16 porturi 8GB FCSloturi I/O 24 PCIeManagement Controlor on-board dual in fail-over, remote managementForm factor Sasiu Servere Blade tip 1Sisteme de operare suportate

HPUX ,Linux, sau echivalent

Cluster Cele 2 servere de tip 1 formeaza un cluster tip CFS RACGarantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HW

Pagina 2

Articol 4Server de baza de date tip 2 (mono-blade)Procesor 4 * RISC/EPIC, 1.8GHz/24 MB Cache, quad-coreMemorie 64 GB DDR3Controlor HDD SAS RAIDUnitati de disk interne 4 * 146 GB 15KRPM SAS DP, RAID 1Controlor retea 8 * 10 GEthControlor fiber channel8GB FCSloturi I/O 6 PCIeManagement Controlor on-board dual in fail-over, remote managementForm factor Sasiu Servere Blade tip 2, full-height double wideSisteme de operare suportate

HPUX ,Linux, sau echivalent

Cluster Cele 2 servere de tip 1 formeaza un cluster tip CFS RACGarantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HW

Articol 5Server de aplicatie Procesor Dual-procesor, dual-core, XEON , 1.6 GHz/18 MBMemorie 32 GBControlor HDD SAS RAIDUnitati de disk interne 2 * 72 GB 15KRPM SAS DPControlor retea 4 * GEthControlor fiber channelPosibil de instalatSloturi I/O 3 PCIeManagement Remote management cu procesor dedicatForm factor Sasiu Servere Blade tip 2, full-heightSisteme de operare suportate

LINUX RED HAT Enterprise

Garantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HW

Articol 6Masiv stocare dateHDD 100 * 300 GB 15KRPMCACHE/SM CACHE cu min 64 GB/SM cu min 16 GBSpare HDD 10SW Mangement, performantaGarantie 3 ani, 24*7 24h acoperire, 6 ore „call to repair” HWEchipamentele trebuie insotite de 2 Switch-uri SAN cu urmatoarele specificatiiNr porturi 2 * 48 8-GB FC SW Licente sw Garantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HW

Articol 7Sistem stocare externHDD 50 * 450 GB 15KRPM DP FC, upgradabil la min 90 HDDRAID Vraid0, Vraid1, Vraid 0+1, Vraid5, Vraid 0+5, Vraid 6 & Cross Vraid

Snaps

Pagina 2

Nr Controloare 2Tip drive-uri Solid State Drives (SSD), High Performance Fibre Channel and Fibre

Attached Technology Adapted (FATA)Cache 4 GBConectivitate Fibre Channel, FCoE, iSCSI and Direct ConnectConectivitate SAN 4 * 4GB FCManagement sistem Integrat si/sau externSW Management si prin upgrade replicari locale si remoteGarantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HWEchipamentele trebuie livrate impreuna cu o biblioteca benzi pentru a asigura o inalta disponibilitate a datelor cu urmatoarele specificatiiNr drive-uri 12Tip drive-uri LTO5SW Licente sw ptr. backup, management,etcGarantie 3 ani, 24*7 24h acoperire , 6 ore „call to repair” HW

Articol 8Switch-uri EthernetNr porturi 24 SFP 10-GbE ports; DuplexSursa RedundantaGarantie Lifetime Warranty

Cerinte pentru infrastructura de comunicatie

Subsistemul de comunicatii trebuie sa asigure:● conectivitate interna la nivelul centrului de date primar.

Echipamentele de comunicatie ofertate vor trebui:● sa contina elemente de redundanta hardware sau software potrivit importantei

rolului alocat● sa permita cresterea performantei prin adaugiri ulterioare de module si interfete

fara a necesita inlocuirea echipamentului in intregime● sa contina instrumentatie de management pentru a putea reduce numarul de erori

prin automatizarea proceselor de intretinere de rutina.● sa aiba posibilitatea de a filtra si limita in mod independent traficul de

management fata de traficul de productieSubsistemul de comunicatii va trebui sa prevada o separare corespunzatoare a tronsoanelor pe care sunt amplasate sistemele de calcul si va trebui sa poata folosi tehnici de filtrare a traficului de tip firewall si de tip IDS/IPS.

Ofertantul va trebui sa respecte regulile de buna practica folosite in proiectarea centrelor de date de mare performanta.Autoritatea contractoare va intreprinde demersurile necesare pentru a pune la dispozitie liniile de comunicatii catre Internet conform indicatiilor ofertantului.

1. Precizari referitoare la platforma hardware si infrastructura de comunicatie

● Oferta trebuie sa raspunda obligatoriu tuturor cerintelor minime din caietul de sarcini cu privire la echipamentele hardware si de comunicatie;

● Oferta trebuie sa cuprinda tipul/modelul componentelor;

Pagina 2

● Oferta trebuie sa cuprinda si servicii de instalare hardware, update firmware la versiunea dorita, instalare suita software management si software necesar pentru a face posibila asistenta tehnica de la distanta, pentru toate echipamentele.

Pagina 2

5. Cerinte privind managementul utilizatorilor si accesul la sistem

Urmatoarele tipuri de utilizatori vor avea acces la sistemul PE, in mod diferentiat in functie de nivelul de access:

● Funizorii de servicii medicale si farmaceutice: gestiunea registrului unic de furnizori de servicii este asigurata de SIUI

● Utilizatori CNAS/CJAS: au rolul de a asigura buna funcţionare soluţiei prin aplicarea procedurilor şi proceselor operationale. Managementul acestui tip de utilizatori va fi facut intern prin mecanisme puse la dispozitie de PE.

● Administrator solutie: efectuează o serie de activităţi cum ar fi, de exemplu, definirea în cadrul PE a rolurilor şi a utilizatorilor.

Accesul utilizatorilor autorizaţi către PE se va face fie prin intermediul interfeţei web, pentru expertii CNAS/CJAS, fie prin aplicaţiile specializate utilizate de furnizorii de servicii medicale sau farmaceutice.

5. Cerinte de servicii1. Cerinte privind ofertantul solutiei

In afara cerintelor si conformitatilor derivate din conditiile de eligibilitate, Ofertantul trebuie sa indeplineasca minimal urmatoarele conditii ca baza in finalizarea proiectului si atingerea obiectivelor propuse:

● Sa dispuna de personal specializat in domeniul sistemelor integrate, precum si in domeniul infrastructurii software ofertate si sa ofere suport prin echipa de proiect cu experienta in conformitate cu cerintele minimale de la paragraful „Resurse Umane"

● Sa garanteze proiectarea si functionarea sistemului informatic integrat in conformitate cu legislatia din Romania. Sa poata asigura in timp util adaptarile necesare in cazul aparitiei unor schimbari sau modificari de legislatie, in cadrul contractului de mentenanta software ce se va incheia cu furnizorul dupa perioada post-implementare mentionata in Caietul de Sarcini.

● Pentru implementarea sistemului se va folosi o metodologie unica pentru toate subsistemele in scopul asigurarii premiselor unei implementari de succes. Activitatile de instalare si configurare a sistemului se vor derula la beneficiar, facandu-se astfel si transferul de cunostinte catre specialistii IT ai beneficiarului.

● Sa includa in oferta Planul de Management al Proiectului

2. Cerinte privind serviciile de implementare

Se doreste ca echipamentele si produsele software furnizate sa fie insotite de servicii de implementare si de project management de calitate, care sa garanteze atingerea cu succes a obiectivelor proiectului.

Furnizorul va presta toate servicile necesare pentru implementarea si dezvoltarea solutiei in conformitate cu recomandarile producatorului si cerintele functionale si tehnice prezentate in Caietul de sarcini, precum si rezultate in urma etapei de analiza a proiectului. Toate costurile asociate trebuiesc cuprinse in oferta financiara.

Pagina 2

Implementarea sistemului va include in mod obligatoriu:

● Livrarea si configurarea echipamentelor hardware si de comunicatie; ● Analiza necesitatilor, a proceselor legate de activitatea de baza a beneficiarului,

cu documentarea specificatiilor detaliate si a cazurilor de utilizare;Este obligatoriu ca etapa de analiza a proceselor sa se desfasoare conform unei metodologii recunoscute care sa asigure Beneficiarul ca toata aria de acoperire a proiectului va fi tratata in mod corespunzator. Ofertantul trebuie sa includa in oferta dovada compententei in domeniul analizei proceselor de business prin prezentarea metodologiei pe care o aplica in proiectele sale. Este obligatoriu ca metodologia propusa pentru analiza proceselor sa faca parte din sistemul de management al calitatii implementat in cadrul organizatiei ofertantului si sa fie certificata in conformitate cu prevederile standardului ISO:9001.

Pentru implementarea sistemului furnizorul va folosi o metodologie unica pentru toate componentele sistemului, pentru a asigura premisele unei implementari de succes.

Livrarea echipamentelor hardware si a licentelor software, instalarea lor si punerea in functiune a sistemelor de operare, va fi realizata de catre personalul Furnizorului impreuna cu reprezentantii beneficiarului. Beneficiarul va asigura conditiile tehnice pentru desfasurarea in bune conditiuni a acestor activitati pe amplasamente.

Pagina 2

3. Graficul de implementareDurata de implementare a proiectului este de 6 luni de la data încheierii contractului. In faza de inceput (maximum 10 zile de la data semnării contractului) a proiectului Furnizorul va prezenta un plan de proiect (inclusiv diagrama GANTT), conform metodologiei de project management propuse, care va fi analizat si agreat de Beneficiar.

4. Cerinte privind serviciile de management de proiect

Activitatea de management de project trebuie sa se desfasoare conform unei metodologii recunoscute international de catre organisme profesionale specifice de management de project.

Furnizorul solutiei informatice trebuie sa prezinte in cadrul propunerii tehnice descrierea detaliata a metodologiei de management de project pe care o va utiliza in cadrul proiectului. Metodologia de management a proiectului va fi detaliata in oferta tehnica si va confine cel putin evidentierea urmatoarelor aspecte: controlul fazelor, activitatilor, atributiilor, planificarea in timp, alocarea resurselor, continutul si rezultatul etapelor, confirmarea rezultatetor si documentarea procesului de implementare.

Toate procedurile de lucru prezentate pentru toate fazele de proiect vor fi certificate ISO 9001, in cadrul ofertei find prezentate toate procesele de lucru pentru fiecare activitate identificata de catre furnizor.

Acesta trebuie sa prezinte un plan tehnic de proiect care trebuie sa acopere urmatoarele puncte:

● Organizarea proiectului;● Diagrama Gantt a proiectului confine planificarea activitatilor, timpul de

desfasurare si● Resursele implicate, livrabilele fazelor de implementare;● Organizarea echipei de proiect — include rolurile si responsabilitatile necesare

persoanelor care vor efectua implementarea si operarea.Furnizorul trebuie sa prezinte un plan detaliat, coerent si etapizat care sa acopere fazele de analiza si implementare. Furnizorul va prezenta in cadrul solutiei propuse un plan detaliat pozitionat in timp si spatiu care sa cuprinda elemente esentiale cum ar fi: analiza, identificarea si evaluarea proceselor, designul aplicatiei, dezvoltarea/customizarea sistemului integrat, asistenta tehnica, alte aspecte considerate de importanta pentru proiect. Furnizorul va configura sistemul propus in conformitate cu fluxurile identificate, analizate si evaluate.

Initierea proiectului

Furnizorul va prezenta in detaliu modalitatea in care proiectul va fi organjzat, incluzand cel putin urmatoarele elemente: Comitetul de conducere al proiectului, manager de project, sefii de echipa si alte roluri importante din cadrul echipei tehnice de project.

Se va prezenta modalitatea de escaladare a problemelor in interiorul organizatiei furnizorului. Planificarea proiectului

Furnizorul va prezenta modalitatea in care propune sa aplice procesul de planificare in cadrul proiectului.

Pagina 2

Pentru toate servicjile incluse in bugetul proiectului(in oferta financiara) se vor prezenta livrabilele care vor rezulta in urma prestarii serviciilor.

Executia proiectului

Managerul de proiect din partea Furnizorului va fi responsabil cu executia proiectului. De asemenea acesta va fi responsabil cu intretinerea unui Registru al Problemelor de project pe intreaga durata a derularii acestuia.

Furnizorul va prezenta in cadrul propunerii tehnice modul in care se vor rezolva problemele care pot sa apara pe parcursul proiectului.

Monitorizare si control

Managerul de proiect din partea Furnizorului va prezenta o procedura detaliata de tratare a cererilor de schimbare, incluzand etapele de identificare, analiza, decizie si implementare. Procedura va identifica etapele logice care vor fi ululate, precum si rolurile si responsabilitatile tuturor partilor implicate.

Furnizorul trebuie sa descrie cum va realiza monitorizarea evolutiei proiectului precum si criteriile de calitate urmarite pe durata de viata a proiectului.

Furnizorul va descrie tipul si frecventa rapoartelor de monitorizare a evolutiei proiectului. Finalizarea proiectului

Finalizarea proiectului

Furnizorul va propune documentele care se intocmesc la finalizarea proiectului.

Furnizorul trebuie sa isi dimensioneze echipa de project astfel incat, pe toata durata contractului, persoanele responsabile de derularea acestei activitati sa fie disponibile on-site in vederea derularii in conditii optime a proiectului.

1. Implementarea proiectului

Furnizorul trebuie sa prezinte metodologia de implementare pe care o va folosi in desfasurarea intregului project. Metodologia trebuie sa fie bazata pe metodologiile standard folosite in proiecte IT de complexitate ridicata.

Furnizorul trebuie sa prezinte in cadrul proiectului modalitatea prin care se va realiza comunicarea intre participantii la project.

Furnizorul va prezenta in cadrul propunerii tehnice si modalitatea de tratare a schimbarilor in cadrul proiectului (in limitele Caietului de Sarcini). Se va prezenta descrierea procedurii de management al schimbarilor precum si formularele care vor fi utilizate in cadrul acestui proces pe durata proiectului.

Fumizorul trebuie sa isi dimensioneze echipa de conducere a proiectului astfel incat, pe toata durata contractului, persoanele responsabile de derularea acestei activitati sa fie disponibile on- site in vederea derularii in conditii optime a proiectului.

Acest capitol trebuie sa includa descrierea la nivel inalt a activitatilor, modalitatea in care aceste activitati vor fi duse la indeplinire si livrabilele produse in urma activitatilor pe parcursul urmatoarelor etape:

Pagina 2

● Analiza● Proiectare● Implementare● Testare● Asistenta tehnica● Livrare, instalare si configurare hardware si pachet software

Planul initial care va fi prezentat impreuna cu oferta trebuie sa acopere toate etapele mentionate mai sus.

5. Cerinte privind instruirea

Furnizorul va asigura şcolarizarea unui număr corespunzator de specialisti desemnati de Beneficiar, in vederea testarii, punerii in functiune, administrarii sistemului si instruirii utilizatorilor.

Şcolarizarea se va desfăşura în limba română. La terminarea cursului cursanţii vor primi de la furnizor Certificate de şcolarizare individuale. Prin aceste certificate Furnizorul confirmă capacitatea şi abilitatea cursanţilor de a participa la teste, asista la punerea in functiune, administra şi instrui utilizatorii aplicatiilor.

Furnizorul solutiei va face instruirea utilizatorilor acestuia prin livrarea de documentatie si organizarea de cursuri de instruire la nivel national. Toate costurile necesare derulării acestor cursuri (traineri, săli curs, suport didactic, logistică ,etc) sunt in sarcina Furnizorului.

Instruirea utilizatorilor sistemului proiectat se va efectua la finalizarea implementarii proiectului pe baza manualelor/ghidurilor de utilizare in limba romana care vor fi disponibile in format fizic si electronic (se vor realiza ghiduri distincte in functie de tipurile de utilizatori ai sistemului). Aceste materiale vor fi puse la dispozitia beneficiarului inainte de punerea in productie a sistemului informatic al cardului national de asigurat.

Ofertantul va pune la dispozitia Beneficiarului si un Ghid de operare pentru persoanele care vor administra si opera sistemul, in format fizic si electronic. Ghidul de operare va cuprinde:

● cel putin procedurile descrise in sectiunea Administrarea si operarea solutiei ● optiunile si procedurile de configurare ale solutiei● descrierea completa a arhitecturii cuprinzand:

○ componentele hardware, carecteristicile si configuratia principala a acestora

○ componentele software, versiunile, configuratiile facute si maparea componentelor software pe componente hardware

○ descrierea mediului principal si a celor auxiliare○ configuratea securitatii si descrierea arhitecturii de securitate a solutiei o

descrierea logica a solutiei – componente, fluxuri de date● Instruirea personalului care va utiliza/administra aplicatia va fi realizata in cadrul a

doua activitati de cursuri specifice organizate, in functie de tipul de utilizatori (utilizatori si administratori). Astfel sunt propuse urmatoarele:

○ instruirea dedicata a utilizatorilor solutiei care urmeaza a fi achizitionata○ instruirea dedicata persoanelor care vor asigura administrarea solutiei

Pagina 2

Limba folosita in activitatile de instruire este limba romana.

Ofertantul trebuie sa descrie modul de organizare al acestor cursuri, tematica cursului, necesar de infrastructura, materiale de curs etc.

De asemenea ofertantul trebuie sa specifice urmatoarele:

● etapele in desfasurarea proiectului in care vor avea loc activitati de instruire● strategia de instruire● metodologia de instruire

6. Cerinte privind serviciile de suport si mentenanta1. Servicii de garantie

Se solicita ca perioada de garantie pentru componentele solutiei informatice ofertate sa fie:

● Echipamente hardware: 3 ani (servere), 3 ani (sistem de stocare)● Echipamente de comunicatii : 3 ani

2. Servicii de suport pentru solutia informatica

In timpul perioadei de garantie, Furnizorul va asigura serviciile de suport pentru:

● Customizarile si dezvoltarile / extensiile din cadrul implementarii proiectului;● Produsele / modulele utilizate in dezvoltarea sistemului informatic● Platforma hardware/ sistem de operare utilizata in baza Service Level Agreement

(SLA).Pentru a permite o identificare proactiva a unor posibile solutii pentru problemele ce tin de infrastructura hardware, se va asigura acces la o baza de cunostinte tehnice si/sau documentatie tehnica specificate prin intermediul centrului de Help Desk.

In acest sens, va fi desemnat un singur punct de intrare pentru toate incidentele legate de solutia informatica furnizata si anume catre Administratorul de Servicii al Furnizorului. Administratorul de Servicii al Furnizorului va:

● administra si monitoriza incidentele,● lua legatura cu persoana desemnata ca punct de contact din partea beneficiarului,

pentru analiza starilor incidentelor deschise,● va raspunde tuturor intrebarilor legate de incidente.

Problemele ridicate de beneficiar vor fi inregistrate de catre specialisti ai Furnizorului, in cadrul unei aplicatii de tip HELPDESK.

Suportul furnizat va fi de tip 24x7 cu 6 ore timp de remediere garantat pentru infrastructura hardware.

Pagina 2

Se va asigura diagnosticarea unui incident pentru determinarea problemei de baza. Se va monitoriza in permanenta incidentul pana la inchiderea acestuia.

3. Urmarirea incidentelor

Persoana desemnata ca punct de contact din partea beneficiarului va lansa un incident, Administratorul de Servicii al Furnizorului primind o notificare. Fiecare incident va avea atasat un nivel de prioritate (ca in exemplele de mai jos) care sa reflecte impactul problemei asupra functionarii sistemului. Initial atasarea nivelului de prioritate se va face cu ajutorul Administratorului de Servicii al Furnizorului pentru a facilita rezolvarea incidentului in timp util.

Nivelul de prioritate poate fi modificat cu acordul partilor in functie de evolutia incidentului.

Furnizorul poate sa isi rezerve dreptul de a modifica un nivelul de prioritate a incidentului, dar cu anuntarea in avans a echipei beneficiarului

Serviciile de Suport vor fi furnizate sub incidenta Clauzelor de Confidentialitate.

Asistenta poate fi de doua tipuri:

● on site (numai la sediul central al beneficiarului)● remote (beneficiarul va asigura un acces VPN consultantilor care vor remedia

problema)

Pagina 2

4. Niveluri de Prioritate

Definitiile nivelelor de prioritate sunt cele de mai jos:

Denumire Descriere

Urgent Impact Major asupra functionarii sistemului

Problema impiedica desfasurarea activitatii institutiei, procesul de activitate este serios afectat si nu mai poate continua pierderea functionalitatilor devenind critice.

Critic Impact Semnificativ asupra functionarii sistemului

Problema impiedica desfasurarea in conditii normale a activitatii utilizatorilor.

Nici o solutie alternativa nu este disponibila, dar activitatea utilizatorilor poate totusi continua, insa limitata la componentele neafectate.

Major Impact Mediu asupra functionarii sistemului Problema afecteaza minor functionalitatile sistemului.

Impactul reprezinta un inconvenient care necesita solutii alternative pentru refacerea functionalitatilor.

Minor Impact Minim asupra functionarii sistemului Problema nu afecteaza functionalitatile sistemului.

Rezultatul este o eroare minora care nu impiedica desfasurarea in bune conditii a activitatii utilizatorilor.

In cazul incidentelor cu nivel de prioritate ”urgent” asistenta va fi asigurata 24x7, fiind disponibila pana cand problema va fi rezolvata. Pentru aceasta beneficiarul va furniza o persoana de contact, disponibila 24x7, care sa furnizeze informatii, sa testeze solutii si sa aplice solutiile furnizate.

5. Timpi de raspuns si rezolutiiPentru incidente critice Ofertantul va asigura urmatorii timpi de raspuns si de remediere:

Componenta a sistemului

Timp de raspuns Timp solutie provizorie/temporara

Timp de remediere

Hardware 2 ore 6 ore 6 ore

Aplicatii software specifice

2 ore 12 ore 24 ore

Pagina 2

Timpii de mai sus sunt calculati din momentul in care Furnizorul a fost instiintat de aparitia problemelor.

La sfarsitul fiecarui caz deschis Furnizorul va efectua o analiza a cauzelor care au dus la producerea deranjamentului si va fi inclusa in recomandarea finala.

Definitiile, descrise mai jos se vor aplica la Service Level Agreement:

● Timp de Raspuns : Timpul scurs de la contactul initial dintre Beneficiar si helpdesk si raspunsul primit de la echipa de suport tehnic a Furnizorului catre beneficiar. Aceasta actiune se va desfasura prin intermediul telefonului.

● Timp de Remediere : Durata de timp pana la oferirea solutiei finale● Remediere Temporara : O modificare in cadrul procedurilor sau datelor care sa

evite erorile fara folosirea defectuoasa a produselor.● SLA : Service Level Agreement identifica functionalitatile si defineste procesele

care implica livrarea de catre Furnizor a diferite servicii de suport catre Beneficiar.● Suport : Telefonul de suport tehnic, asistenta web si e-mail oferite de

Furnizor pentru a ajuta Beneficiarul in rezolvarea problemelor aparute.● HELPDESK Un centru de asistenta tehnica ce ofera serviciul de preluare a cererilor

prin telefon, web si e-mail operat de catre personalul care face parte din suportul Furnizorului oferind asistenta pentru componenentele solutiei informatice integrate furnizate.

6. Cerinte privind resursele umane

În opinia Beneficiarului complexitatea arhitecturii deja existente si aflate în regim de exploatare cât şi a soluţiei cerute prin prezentul caiet de sarcini, necesită resurse expert care să poată înţelege cu exactitate modul în care aceasta poate fi integrată şi implementată cu toate funcţionalităţile solicitate de către Beneficiar.

Echipa furnizorului va contine minim următoarii experti:

● Director de proiect- o persoana● Manageri de proiect- trei persoane● Arhitecti de solutie- doua persoane● Experti tehnici- minim trei persoane● Experti software- minim zece persoane● Responsabil instruire- minim o persoana● Specialist logistica- o persoana● Expert financiar- o persoana● Responsabil calitate- o persoana

Cerinte minime obligatorii privind echipa de proiect- experti cheie:

● Ofertantul trebuie sa demonstreze ca are la dispozitie personalul corespunzător pentru natura si dimensiunile acestui proiect. In acest scop, ofertantul va prezenta CV-uri pentru persoanele cheie din proiect.

● Fiecare CV va conţine următoarele elemente obligatorii:● Experienţa de lucru – cu detalierea atribuţiilor avute in cadrul fiecărui proiect

semnificativ● Studii semnificative● Certificări şi atestate

Pagina 2

● In fiecare CV se vor prezenta minim 3 proiecte. În plus, se vor prezenta copii de pe certificările şi atestările personalului implicat în proiect.

Pagina 2

1. Director de proiectVa avea responsabilitatea administrării şi coordonării întregului program, lucrând direct cu managerii de proiect.

Cerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată în domeniul IT & C.● Diploma de absolvire a studiilor Executive Master of Business Administration

(„MBA”)● Certificat emis de o organizatie profesionala internationala de management si

leadership (afiliata la The World Management Council), care atesta calificarea in managementul strategic si leadership (cel putin nivel 7).

● Certificat profesional/calificare echivalentă recunoscută internaţional în management de proiect.

● Vorbitor de limba română nativ. ● Cel puţin 5 ani experienţă în implementarea proiectelor TIC.● Cel puţin 3 ani experienţă în pozitia de Manager de proiect.● Experienţă ca Manager de proiect în cel puţin un proiect de dezvoltare de solutii

informatice finalizate în care a coordonat o echipa de minim 10 persoane.● Experienţă ca Manager de proiect în cel puţin un proiect de dezvoltare de solutii

informatice finalizate, proiecte având drept scop implementarea la nivel naţional (într-un numar de cel puţin 30 unităţi distribuite pe întregul teritoriu naţional) de sisteme informatice.

● Experienţă în organizarea şi monitorizarea activităţilor de instruire desfăşurate în cel puţin un proiect de dezvoltare software.

● Experienţă şi cunoaşterea a cel puţin unei metodologii de Management de Proiect recunoscute, cum ar fi PMBOK, PRINCE2, sau echivalentă – aplicată în cel puţin un proiect.

2. Manageri de proiectVor avea responsabilitatea administrării şi coordonării întregului proiect tehnic, lucrând direct cu ceilalţi experţi şi experţi cheie din proiect.

Cerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată în domeniul IT & C.● Certificat profesional/calificare echivalentă recunoscută internaţional în

management de proiect (PMI, PRINCE2).● Vorbitor de limba română nativ. ● Cel puţin 5 ani experienţă în implementarea proiectelor IT & C.● Cel puţin 3 ani experienţă în pozitia de Manager de proiect.● Experienţă ca Manager de proiect în cel puţin un proiect de dezvoltare de solutii

informatice finalizate în care a coordonat echipe de minim 10 persoane.● Experienţă ca Manager de proiect în cel puţin un proiect de dezvoltare de solutii

informatice finalizate, proiect având drept scop implementarea la nivel naţional (într-un numar de cel puţin 30 unităţi distribuite pe întregul teritoriu naţional) de sisteme informatice.

● Experienţă în întregul ciclu de viaţă de dezvoltare software cu cel puţin o metodologie de dezvoltare software recunoscută

● Experienţă în organizarea şi monitorizarea activităţilor de instruire desfăşurate în cel puţin un proiect de dezvoltare de solutii informatice.

Pagina 2

● Experienţă şi cunoaşterea a cel puţin unei metodologii de Management de Proiect recunoscute, cum ar fi PMBOK, PRINCE2, sau echivalentă – aplicată în cel puţin un proiect.

3. Arhitecti de solutieArhitectii de soluţie vor fi responsabili cu proiectarea la nivel înalt a întregii soluţii cerute în prezentul Caiet de sarcini. Arhitectii de soluţie vor fi legatura între nivelul non-IT şi nivelul IT al echipelor de proiect. Vor fi implicati în toate fazele proiectului pentru a asigura buna punere în practică a analizei şi design-ului soluţiei propuse.

Cerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată în domeniul IT & C.● Vorbitor nativ de limba română.● Cel puţin 5 ani de experienţă în domeniul IT & C. ● Cel puţin 3 ani de experienţă într-o pozitie de arhitect de soluţie.● Experienţă în tehnologia cu nivele multiple – participare în cel puţin un proiect

finalizat, cu o durată de cel puţin 1 an. ● Experienţă în dezvoltarea modelelor de date şi arhitecturilor pentru organizaţie –

participare în cel puţin un proiect.● Certificare, dobandita de la o organizatie independenta, in domeniul arhitecturilor

de tip Enterprise

Pagina 2

4. Experti tehniciCerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată în domeniul IT & C.● Vorbitor nativ de limba română. ● Cel puţin 5 ani de experienţă în domeniul IT & C● Experienţă în dezvoltarea de software folosind instrumentele ofertate – participare

în cel puţin un proiect similar ● Experienţă în tehnologia cu nivele multiple – participare în cel puţin un proiect.

5. Experti softwareCerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată în domeniul IT & C.● Experientă dovedită de minim 5 ani în domeniul IT&C. ● Vorbitor nativ de limba romana.● Experienţă dovedită de cel puţin 3 ani în realizarea solutiilor software complexe.

Pagina 2

6. Expert financiarResponsabilul financiar coordoneaza si conduce activitatile de natura financiara din cadrul proiectului:

● controlul costurilor din cadrul proiectului;● intocmirea raportarilor si situatiilor finaciare necesare in cadrul proiectului;● analiza si prognoza veniturilor si cheltuielilor;● urmarirea indicatorilor finaciari din cadrul proiectului.

Cerinţe minime obligatorii pentru responsabilul financiar

● Diplomă de absolvire a studiilor universitare de lungă durată în domeniul financiar-contabil.

● Vorbitor de limba română nativ. ● Cel puţin 5 ani experienţă în pozitia de Reponsabil financiar.

7. Responsabil calitate

Cerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată în domeniul IT&C.● Vorbitor de limba română nativ. ● Experienta profesionala in domeniul IT&C de minim 5 ani.

8. Responsabil instruire

Cerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată ● Vorbitor de limba română nativ. ● Experienta profesionala in domeniul IT&C de minim 5 ani

9. Specialist logisticaCerinţe minime obligatorii

● Diplomă de absolvire a studiilor universitare de lungă durată.● Vorbitor de limba română nativ. ● Experienta profesionala: a coordonat serviciile de logistica in cadrul unui proiect,

pentru livrarea echipamentelor hardware de tip enterprise in valoare de cel putin 8 milioane EUR.

7. Cerinte privnd formatul ofertelor

Limba de redactare a ofertei este limba romana. Ofertantul va suporta toate costurile asociate elaborarii si prezentarii ofertei sale, precum si documentelor care o insotesc, iar Beneficiarul nu va fi responsabil sau raspunzator pentru costurile respective. Documentatia tehnica (pliante, prospecte, etc.) si documentele emise de institutii/organisme oficiale din tara in care ofertantii straini sunt rezidenti pot fi

Pagina 2

prezentate in alta limba, cu conditia ca acestea sa fie insotite de o traducere autorizata in limba romana.

Ofertantul are obligatia de a mentine oferta valabila pe toata perioada de valabilitate stabilita de autoritatea contractanta. Orice oferta valabila pentru o perioada mai mica decat cea stabilita de autoritatea contractanta va fi respinsa de comisia de evaluare ca fiind necorespunzatoare. Perioada de valabilitate a ofertei este de 90 de zile. Autoritatea organizatoare/contractanta are dreptul de a solicita ofertantilor, in circumstante exceptionale, inainte de expirarea perioadei de valabilitate a ofertei, prelungirea acestei perioade. In cazul extinderii perioadei de valabilitate a ofertei, perioada de valabilitate a garantiei pentru participare va fi prelungita in mod corespunzator. Ofertantul are obligatia de a comunica autoritatii organizatoare/contractante daca este sau nu de acord cu prelungirea perioadei de valabilitate a ofertei. Ofertantul care nu este de acord cu prelungirea perioadei de valabilitate a ofertei se considera ca si-a retras oferta, fara ca acest fapt sa atraga pierderea garantiei pentru participare.

Desi nu se impune un format standard al ofertelor, partea tehnica va acoperi urmatoarele aspecte (ofertantul va adauga orice informatie considerata de interes relativ la oferta proprie):

1. Rezumat executiv2. Prezentarea companiei3. Documente doveditoare cu privire la cerintele minime solicitate in caitul de

sarcini. Scrisorile de recomandare ce trebuie prezentate de Ofertant sunt acceptate daca acestea sunt emise in numele Ofertantului sau in numele unei entitati terte, ambele aflate sub controlul direct sau indirect al unei companii, societati comerciale, firme, corporaţie sau asociere cu personalitate juridica, din Romania sau din strainatate.

4. Intelegerea cerintelor proiectului precum si viziunea asupra realizarii proiectului5. Modul in care oferta raspunde cerintelor proiectului:

● Se va prezenta pe larg solutia propusa in vederea atingerii obiectivelor proiectului si a rezultatelor asteptate

● Se va raspunde punctual la fiecare dintre cerintele exprimate in caietul de sarcini si se va mentiona in clar daca cerinta este indeplinita si se vor da detalii privind modul de realizare a cerintei respective

6. Detalierea scopului proiectului7. Metodologia de lucru confom cerintelor din Caietul de sarcini8. Descrierea activitatilor, a livrabilelor si criteriile de finalizare ale activitatilor9. Planul de Management al Proiectului confom cerintelor din Caietul de sarcini10. Planul de instruire11. Lista livrabilelor infrastructurii hardware, comunicatii si software confom cerintelor

din Caietul de Sarcini12. Lista echipa proiect furnizor cu documentele doveditoare cu privire la cerintele

minime solicitate in Caietul de Sarcini13. Anexe

8. Alte cerinte Solutia propusa de Ofertant trebuie sa indeplineasca urmatoarele cerinte minime obligatorii:

Pagina 2

Nr. Crt Descrierea cerintei1 Ofertantul trebuie sa implementeze functionalitatile cerute prin extinderea

sistemului SIUI astfel incat sa nu se duplice functionalitatile si informatiile deja existente in acesta.

2 Solutia propusa trebuie sa extinda functional, arhitectural si din punctul de vedere al infrastructurii informatice sistemul SIUI.

3 Solutia trebuie sa respecte mecanismele de comunicatie impuse de sistemul SIUI.

4 Solutia trebuie sa extinda aplicatiile specializate SIUI destinate uzului furnizorilor de servicii medicale si farmaceutice.

5 Solutia propusa trebuie sa utilizeze registrele nationale si nomenclatoarele sistemului SIUI.

6 Solutia propusa trebuie sa permita autentificarea cetatenilor cu cardurile CEAS si a furnizorilor de serviii cu certificatul digital calificat.

Pagina 2

9. Anexa 1- Functionalitati expuse de SIUI prin servicii web

În această secţiune sunt prezentate pe scurt funcţionalităţile expuse de sistemului SIUI prin servicii Web, functionaitati care pot fi folosite pentru introducerea prescriptiei electronice.

Detalierea serviciilor și a metodelor expuse de acestea este prezentată pe larg în “Specificațiile de interfațare cu SIUI-Actualizat”, documentaţie publicată pe Portalul CNAS-SIUI la adresa http :// siui . casan . ro / cnas / siui _2.0/ specificatii . Documentaţia conţine şi structura fișierelor XML specifice fiecărui serviciu Web expus, dar și fiecărui tip de furnizor.

1. Serviciul pentru sincronizarea nomenclatoarelorServiciul permite sincronizarea nomenclatoarelor existente în alte aplicaţii cu nomenclatoarele din SIUI. Aplicaţiile de raportare vor putea descărca online nomenclatoarele specifice în urma publicării unor noi versiuni ale acestora. Aplicaţia va afişa un mesaj de avertizare dacă detectează o versiune mai nouă de nomenclatoare, propunând sincronizarea acestora.

Se poate interacţiona cu acest serviciu Web din perspectiva utilizării codurilor din nomenclatoarele standardizate SIUI pentru identificarea semnificaţiei datelor cu caracter medical, dar şi a celor cu caracter administrativ, astfel utilizandu-se un vocabular comun.

Metoda getCatalogues

String[] getCatalogues (String partnerCategory,DateTime start )

Metoda are doi parametri de intrare :

● parametrul partnerCategory de tip şir de caractere reprezintă codul tipului de furnizor pentru care se cere versiunea actuală de nomenclatoare, lista valorilor permise fiind prezentată mai jos;

● parametrul start de tip dată calendaristică reprezintă data de la care se caută în sistem existenţa unei noi versiuni.

Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector reprezintă URL-ul de la care se face descărcarea fişierului, iar cel de-al doilea şir reprezintă dimensiunea fişierului care trebuie descărcat. URL-ul va expira la momentul publicării unei noi versiuni de nomenclatoare pentru a nu permite aplicaţiilor de raportare să descarce accidental un fişier de nomenclatoare mai vechi folosind un URL din cache.

Dacă nu există o versiune mai nouă de nomenclatoare metoda întoarce null.

Cel de-al doilea parametru poate fi folosit pentru a evita transferul inutil de date prin stocarea în aplicaţia client a datei la care s-a efectuat sincronizare anterioară şi prin folosirea acestei date ca dată de început pentru căutare a unei versiuni mai noi a nomenclatoarelor.

Pagina 2

2. Serviciul pentru sincronizarea datelor de personalizare

Serviciul va permite sincronizarea datelor de personalizare a aplicației existente în aplicaţiile furnizorilor cu nomenclatoarele din SIUI. Datele de personalizare se referă la detalii contractuale, servicii și tarife contractate, liste de înscrişi, în funcţie de specificul fiecărui tip de furnizor. Aplicaţiile de raportare vor putea descărca online datele de personalizare specifice în urma actualizării acestora în SIUI. Aplicaţia va afişa un mesaj de avertizare dacă detectează o versiune mai nouă, propunând sincronizarea datelor.

Acest serviciu se adresează strict aplicaţiilor de raportare ale furnizorilor de servicii medicale. Nu se întrevăd posibilităţi de reutilizare în interacţiunea cu alte sisteme informatice.

Metoda getProviderInfo

String[] getProviderInfo (String partnerCategory,DateTime start,DateTime stop,String uic )

Metoda are patru parametri de intrare :

● parametrul partnerCategory de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos;

● parametrul start de tip dată calendaristică reprezintă data de început a perioadei pentru care se caută datele furnizorului în sistem;

● parametrul stop de tip dată calendaristică reprezintă data de sfârşit a perioadei pentru care se caută datele furnizorului în sistem;

● parametrul uic de tip şir de caractere reprezintă codul unic de identificare al furnizorului în sistem, CUI (cod fiscal) sau CNP, după caz.

Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector reprezintă URL-ul de la care se face descărcarea fişierului de personalizare, iar cel de-al doilea şir reprezintă dimensiunea fişierului care trebuie descărcat.

3. Serviciul pentru trimiterea raportărilor periodice

Serviciul permite trimiterea unui fişier de raportare periodică către SIUI. La momentul trimiterii se realizează validarea formei şi conţinutului fişierului, precum verificarea existenţei unui contract valid şi a unei perioade de raportare deschisă pentru furnizorul respectiv. Prelucrarea datelor este asincronă, furnizorul trebuind să se conecteze ulterior pentru a prelua rezultatele raportării și decontul.

Acest serviciu se adresează strict aplicaţiilor de raportare ale furnizorilor de servicii medicale. Nu se întrevăd posibilităţi de reutilizare în interacţiunea cu alte sisteme informatice.

Metoda sendReport

Pagina 2

Boolean sendReport (String reportType,String reportXml )

Metoda are doi parametri de intrare :

● parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos;

● parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare arhivat în formatul ZIP (JavaZip) şi codat ulterior în formatul Base64.

Dacă metoda întoarce valoarea „adevărat”, atunci trimiterea raportului s-a făcut cu succes, altfel trimiterea s-a terminat cu erori. Pe baza mesajului primit în cazul unei erori se poate determina cauza respingerii raportării.

4. Serviciul pentru preluarea rezultatelor raportărilor periodiceServiciul permite preluarea fişierului de răspuns pentru o raportare trimisă anterior către SIUI pentru prelucrare. Pentru ca fişierul de răspuns să poate fi descărcat acesta trebuie să fie salvat într-o locaţie predefinită pe mediile de stocare ale SIUI, lucru care se efectuează automat în urma prelucrării fişierului de raportare.

Acest serviciu se adresează strict aplicaţiilor de raportare ale furnizorilor de servicii medicale. Nu se întrevăd posibilităţi de reutilizare în interacţiunea cu alte sisteme informatice.

Metoda getReportFeedback

String[] getReportFeedback ( String fileName )

Metoda are un singur parametru de intrare :

● parametrul fileName de tip şir de caractere reprezentă numele fişierului de raportare trimis de aplicaţie pentru care se cere răspunsul procesării.

Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector reprezintă URL-ul de la care se face descărcarea fişierului, iar cel de-al doilea şir reprezintă dimensiunea fişierului care trebuie descărcat.

Dacă nu există un fişier de raportare procesat cu numele dat, metoda întoarce null.

Aplicaţia client trebuie să folosească URL-ul rezultat pentru a descărca fişierul cu nomenclatoarele. Dimensiunea fişierului poate fi folosită pentru a verifica completitudinea fişierului descărcat. Fişierul descărcat este o arhivă ZIP care conţine un fişier XML cu rezultatul procesării raportării în SIUI.

5. Serviciul pentru preluarea decontului calculat în SIUIServiciu permite obţinerea fişierului de decont aferent unei perioade de raportare sau unei anumite raportări (în baza numărului de factură). În acest sens, serviciul va expune două metode, una pentru preluarea decontului pentru o perioadă de raportare, și alta pentru preluarea decontului pentru o anumită factură (folosită în mod special de farmacii).

Datele vor fi disponibile după finalizarea procedurii de decontare din cadrul SIUI. Decontul este un raport (în format PDF) și este destinat consultării de către furnizor. Datele de pe raport nu vor fi preluate în aplicație.

Pagina 2

Acest serviciu se adresează strict aplicaţiilor de raportare ale furnizorilor de servicii medicale. Nu se întrevăd posibilităţi de reutilizare în interacţiunea cu alte sisteme informatice.

Metoda getRefund

String[] getRefund (String partnerCategory,DateTime start,DateTime stop,String uic )

Metoda are patru parametri de intrare:

● parametrul partnerCategory de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos;

● parametrul start de tip dată calendaristică reprezintă data de început a perioadei pentru care se doreşte fişierul de decont;

● parametrul stop de tip dată calendaristică reprezintă data de sfârşit a perioadei pentru care se doreşte fişierul de decont;

● parametrul uic de tip şir de caractere reprezintă codul unic de identificare al furnizorului în sistem, CUI (cod fiscal) sau CNP, după caz.

Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector reprezintă URL-ul de la care se face descărcarea fişierului de decont, iar cel de-al doilea şir reprezintă dimensiunea fişierului care trebuie descărcat.

Dacă nu există un fişier de decont generat pentru furnizorul respectiv, metoda întoarce null.

6. Serviciul pentru consultarea cererilor şi a deciziilorServiciul permite sincronizarea informaţiilor referitoare la deciziile de aprobare ale unor categorii de servicii, cum ar fi acordarea de dispozitive medicale sau de îngrijiri la domiciliu.

Serviciul va întoarce ca răspuns un fișier XML care va conține toate datele necesare înregistrării corecte și pre-validării la nivelul aplicației de raportare a serviciilor prestate și a dispozitivelor medicale eliberate.

Acest serviciu se adresează furnizorilor de dispozitive medicale şi servicii de îngrijire la domiciliu.

Metoda getDecisions

String[] getDecisions (String partnerCategory,String requestXml )

Metoda are doi parametri de intrare:

● parametrul partnerCategory de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos;

● parametrul requestXml de tip şir de caractere reprezintă conţinutul fişierului de cerere arhivat în formatul ZIP (JavaZip) şi codat ulterior în formatul Base64.

Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector reprezintă URL-ul de la care se face descărcarea fişierului de răspuns, iar cel de-al doilea şir reprezintă dimensiunea fişierului care trebuie descărcat.

Pagina 2

Dacă nu există un fişier de raportare procesat cu numele dat, metoda întoarce null.

7. Serviciul pentru verificarea calității de asiguratServiciul permite verificarea calităţii de asigurat, prinde ca parametru CNP-ul pacientului. Serviciul Web trebuie sa trateze situația in care parametrul furnizat nu se poate valida ca şi CNP, dar şi cazul în care CNP-ul nu este înregistrat în sistem. Fişierul XML returnat de serviciul web va conține cel puţin următoarele categorii de informaţii:

● Lista categoriilor active la data interogării● Ștampila de timp la momentul emiterii răspunsului● Codul de jurnalizare/auditare al răspunsului

Se poate interacţiona cu acest serviciu Web pentru verificarea online a stării de asigurare a unui pacient care solicită eliberarea reţetă compensată sau la eliberarea medicaţiei prescrise în farmacie.

Metoda getInsured

String getInsured (String pid,Date requestDate )

Metoda are doi parametri de intrare:

● parametrul pid de tip şir de caractere reprezintă CNP-ul unui beneficiar;● parametrul requestDate de tip dată calendaristică reprezintă data la care se

dorește verificarea calității de asigurat, de exemplu data curentă sau data efectuării serviciului.

Metoda întoarce ca răspuns un şir de caractere reprezentând conţinutul unui fişier în format XML care conţine următoarele informaţii:

Un cod numeric de răspuns indicând dacă beneficiarul este asigurat sau nu, dacă figurează ca decedat în sistem, dacă nu este înregistrat în sistem sau dacă CNP-ul nu este corect.

Lista categoriilor active la data interogării

Observaţii:

În cazul unei erori întâlnite în sistem la procesarea cererii se va întoarce un cod numeric de răspuns (-1) precum și o descriere a erorii.

Este de preferat ca aplicaţia de raportare să realizeze validarea de corectitudine a CNP-ului, algoritmul fiind arhicunoscut, pentru a nu supraîncărca sistemul cu cereri inutile.

8. Serviciul pentru pre-validarea mișcărilor de capitațieServiciul permite transmiterea către SIUI a unei cereri de înscriere/ieșire/deces a unui pacient pe lista unui medic de familie. SIUI va valida cererea prin verificarea respectării intervalului de 6 luni de la ultima schimbare de către pacient a medicului de familie si va transmite un răspuns prin serviciul Web către medicul de familie in care este trecut rezultatul operației.

Trebuie sa fie permisă modificarea acestor informaţii de către medicul de familie până la întocmirea decontului per-capita pentru medicul de familie. Raportările on-line cu privire la capitație au prioritate faţă de raportările batch (făcute la sfârșitul lunii), existente acum in SIUI in sensul in care daca înscrierea on-line a unui pacient pe lista unui medic a fost

Pagina 2

aprobata, cererea de înscriere a aceluiaşi pacient pentru alt medic care raportează batch va fi respinsa de SIUI.

Se poate interacţiona cu acest serviciu Web în cazul în care medicul de familie doreşte să elibereze o reţetă compensată, fiind necesar ca pacientul să fie înscris pe lista medicului pentru a beneficia de compensare. Se poate verifica online şi posibilitatea înscrierii unui pacient pe lista medicului de familie dat fiind că normele specifice CNAS prevăd o durata de timp care trebuie să treacă până când un pacient are dreptul să-şi schimbe medicul de familie.

Metoda validateEnlisted

String validateEnlisted ( String enlistedXml )

Metoda are un singur parametru de intrare:

● parametrul enlistedXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în format XML.

Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care conţine următoarele informaţii:

● structură similară cu cea raportată, conţinând fiecare identificator de înregistrare transmisă însoţit de starea validării (validat/nevalidat)

● Lista erorilor sau avertizărilor pentru fiecare înregistrare raportată, în caz că acestea au fost depistate

● Ștampila de timp la momentul emiterii răspunsului

9. Serviciul pentru pre-validarea serviciilor și investigațiilor medicale

Serviciul permite transmiterea serviciile prestate în aplicaţie pe măsură ce acestea sunt introduse în aplicaţie. Ca regula generală, datele transmise la SIUI vor fi validate iar serviciul Web va întoarce un răspuns cu privire la rezultatul validării serviciilor raportate, răspuns care va purta o un identificator unic care poate fi referit de furnizor şi care va permite trasabilitatea cererii transmisă prin serviciul WEB pentru un operator CJAS.

Se poate interacţiona cu acest serviciu Web în momentul validării unei reţete prescrise de medic. Pentru detalii vezi serviciul de validare a unei reţete prescrise.

Observaţie: Această metodă permite raportarea unei reţete prescrise, metoda de pre-validare a reţetelor fiind doar o particularizare a acestei metode, intern datele ajungând în acelaşi loc în SIUI. Din punctul de vedere al SIUI prescrierea unei reţete este un serviciu medical.

Metoda validateReport

String validateReport (String reportXml,String reportType,String requestType )

Metoda are trei parametri de intrare:

● parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în format XML.

● parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos;

Pagina 2

● parametrul requestType de tip şir de caractere reprezintă codul tipului de cerere de validare transmisă, lista valorilor permise fiind prezentată mai jos;

Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care conţine următoarele informaţii:

● structură similară cu cea raportată, conţinând fiecare identificator de înregistrare transmisă însoţit de starea validării (validat/nevalidat)

● Lista erorilor sau avertizărilor pentru fiecare înregistrare raportată, în caz că acestea au fost depistate

● Ștampila de timp la momentul emiterii răspunsuluiConţinutul şi formatul datelor transmise este specific fiecărui tip de furnizor şi va fi descris în detaliu în anexele care însoțesc acest document. Ca regulă generală, datele transmise din aplicaţia de raportare către SIUI vor fi validate iar serviciul Web va întoarce un răspuns cu privire la rezultatul validării serviciului medical raportat.

10. Serviciul pentru pre-validarea rețetelor prescrise de mediciServiciul permite raportarea de către un medic prescriptor a unei rețete prescrise. Validarea corectitudinii întocmirii reţetei se face după completarea și transmiterea tuturor informațiilor necesare legate de rețetă către SIUI, care transmite în urma procesării un mesaj către medicul prescriptor cu privire la corectitudinea rețetei în ansamblu, dar și la fiecare medicament în parte.

Rețetele se află inițial intr-o stare “prescrisă”, fiind disponibile spre interogare în farmacii printr-un apel al serviciului Web dedicat. Modificarea unei rețete prescrise se poate face de către medicul prescriptor și numai de către el, atât timp cat rețeta este în starea “prescrisă”, înainte de a trece in starea “eliberată”.

Se poate interacţiona cu acest serviciu Web în momentul validării unei reţete compensate prescrise de medic. Astfel medicii care doresc să prescrie o reţetă unui pacient vor trebui să transmită spre validare către SIUI prin intermediul aplicaţiei specifice de raportare datele reţetei pentru a se verifica dacă reţeta este eligibilă pentru compensare din punctul de vedere al normativelor CNAS. Acest serviciu va reduce, până la eliminare completă, posibilitatea ca medicii să emită reţete ca nu vor fi compensate de CNAS, evitând punerea pe drumuri pentru pacienţi, aceştia aflând încă de la cabinetul medicul dacă este cazul să revină cu documente justificative sau că pur şi simplu nu pot beneficia de compensare, putând să acţioneze în consecinţă.

Metoda validatePrescription

String validatePrescription (String reportXml,String reportType )

Metoda un singur parametru de intrare:

● parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în format XML;

● parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos.

Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care conţine rezultatul operaţiunii de validare.

Pagina 2

11. Serviciul pentru pre-validarea biletelor de trimitere emise de medici

Serviciul permite unui medic prescriptor sa raporteze biletele de trimitere emise. SIUI va valida biletul de trimitere și va informa medicul emitent despre rezultatul validării. Certificatele medicale astfel raportate vor fi stocate într-o bază de date pentru realizarea verificărilor de unicitate a certificatelor medicale și a verificărilor încrucișate conform normelor în vigoare.

Acest serviciu se adresează medicilor care recomandă trimiteri către specialişti sau investigaţii de laborator.

Acest serviciu va expune două metode online, una pentru preluarea biletelor de trimitere către medicii specialiști și alta pentru biletele de trimetre către investigații de laborator.

Metoda validateClinicReferral

String validateClinicReferral (String reportXml,String reportType )

Metoda un singur parametru de intrare:

● parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în format XML;

● parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos.

Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care conţine rezultatul operaţiunii de validare.

Metoda validateLabReferral

String validateLabReferral (String reportXml,String reportType )

Metoda un singur parametru de intrare:

● parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în format XML;

● parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista valorilor permise fiind prezentată mai jos.

Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care conţine rezultatul operaţiunii de validare.

12. Serviciul pentru pre-validarea certificatelor medicale emise de medici

Serviciul permite unui medic prescriptor sa raporteze concediile medicale prescrise. SIUI va valida concediul medical și va informa medicul prescriptor despre rezultatul validării. Certificatele medicale astfel raportate vor fi stocate într-o bază de date pentru realizarea verificărilor de unicitate a certificatelor medicale și a verificărilor încrucișate conform normelor în vigoare.

Acest serviciu se adresează medicilor care prescriu certificate de concediu medical.

Pagina 2

Metoda validateSickLeave

String validateSickLeave ( String reportXml )

Metoda un singur parametru de intrare:

● parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în format XML.

Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care conţine rezultatul operaţiunii de validare.

13. Serviciul pentru pre-validarea reţetelor emise de farmaciiServiciul permite unei farmacii să valideze medicamentele eliberate în baza unei reţete verificând compatibilitatea dintre medicamentele prescrise si cele eliberate (calitativ si cantitativ) , pentru fiecare medicament eliberat. SIUI va returna un mesaj prin care farmacistul este înştiinţat despre rezultatul operațiunii de eliberare de medicamente.

O rețetă poate fi eliberata, total sau parțial, de o singura farmacie. După eliberare rețeta trece in starea “eliberată” si nu mai este disponibilă pentru alte farmacii. Orice modificare a unei rețete eliberate de către o farmacie poate fi făcuta exclusiv de farmacia in cauza. Aceste modificări trebuie salvate intr-un log pentru posibilitatea consultării ulterioare.

Acest serviciu Web se poate folosi în momentul validării unei reţete compensate eliberată în farmacie. Astfel farmaciştii care doresc să elibereze medicamente în baza unei reţete unui pacient vor trebui să transmită spre validare către SIUI prin intermediul aplicaţiei specifice de raportare datele reţetei pentru a se verifica dacă reţeta este eligibilă pentru compensare din punctul de vedere al normativelor CNAS. Acest serviciu va reduce, până la eliminare completă, posibilitatea ca farmaciile să elibereze medicamente care nu vor fi ulterior compensate de CNAS, reducând astfel pierderile potenţiale de fonduri din partea acestora.

Metoda validateFarmacyDrugs

String validateFarmacyDrugs ( String reportXml )

Metoda un singur parametru de intrare:

● parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în format XML.

Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML.

În cazul în care conexiunea nu a putut fi efectuată, rezultatul apelului metodei Web va fi un mesaj de eroare (o excepţie).

Structura fișierul permite transmiterea mai multor înregistrări simultan, de exemplul la cerea utilizatorului, după ce acesta a finalizat operarea mai multor reţete eliberate, sau în mod automat la revenirea conexiunii online după o perioadă de lucru offline.

14. Serviciul pentru consultarea reţetelor prescriseServiciul permite unei farmacii sa vizualizeze rețetele prescrise de medici si sa elibereze medicamentele aferente prescripției. Transferul de date se va face printr-un serviciu Web in care este obligatoriu, din motive de confidențialitate, ca farmacia sa completeze seria si numărul de rețeta, dar și CNP-ul pacientului pentru care se eliberează medicamente.

Pagina 2

Serviciul Web va returna suficiente date care sa permită aplicației de la farmacie pre-completarea rețetei (medic, pacient, diagnostice, medicație). Nu vor fi disponibile prin serviciul Web rețete filtrate după nume sau CNP.

Rețetele sunt disponibile pentru interogare din momentul inițial în care se află în starea “prescrisă”, până la trecerea în starea “eliberată”. Ulterior, o altă farmacie care interoghează informațiile legate de rețeta respectivă va primi un mesaj că rețeta a fost deja eliberată, prevenind astfel dubla eliberare a unei rețete.

Acest serviciu Web permite descărcarea şi pre-completarea datelor în format electronic a informaţiilor de pe reţetă aşa cum au fost ele raportate electronic de către medic. Acest serviciu permite includerea informaţiilor specifice introducerii prescriptiei electronice prin simpla extindere a setul de date schimbate între SIUI şi sistemele externe cu un set de câmpuri corespunzător.

Metoda getPrescription

String getPrescription (String serial,String number,String pid,String stencil )

Metoda are patru parametri de intrare:

● parametrul serial de tip şir de caractere reprezintă seria rețetei;● parametrul number de tip şir de caractere reprezintă numărul rețetei;● parametrul pid de tip şir de caractere reprezintă CNP-ul beneficiarului rețetei;● parametrul stencil de tip şir de caractere reprezintă numărul de parafă al

medicului emitent;Metoda întoarce şir de caractere reprezentând fişierul de răspuns în format XML.

Aplicațiile de raportare vor avea posibilitatea de implementare a unor funcționalităţi de preluare automată a conținutului acestor documente în format electronic către SIUI. Astfel o farmacie poate apela serviciul Web pentru a descărca o rețetă prescrisă în scopul de a elibera medicamentele aferente.

15. Serviciul pentru consultarea biletelor de trimitereAcest serviciu este folosit pentru consultarea biletelor de trimitere pentru specialități clinice sau investigaţii de laborator validate de SIUI de către furnizorii de servicii medicale care prestează servicii în baza unui bilet de trimitere. Transferul de date se va face printr-un serviciu Web in care este obligatoriu, din motive de confidenţialitate, ca furnizorul să completeze seria şi numărul biletului, dar și CNP-ul pacientului pentru care au fost efectuate servicii medicale.

Acest serviciu se adresează medicilor care efectuează servicii în baza biletelor de trimitere.

Aceste serviciu expune două metode, una pentru consultarea trimiterilor către medicii specialişti şi cealaltă pentru laboratoare.

Metoda getClinicReferral

String getClinicReferral (String serial,String number,

Pagina 2

String pid,String stencil )

Metoda are patru parametri de intrare:

● parametrul serial de tip şir de caractere reprezintă seria biletului de trimitere;● parametrul number de tip şir de caractere reprezintă numărul biletului de

trimitere;● parametrul pid de tip şir de caractere reprezintă CNP-ul beneficiarului biletului de

trimitere;● parametrul stencil de tip şir de caractere reprezintă numărul de parafă al

medicului emitent;Metoda întoarce şir de caractere reprezentând fişierul de răspuns în format XML.

Metoda getLabReferral

String getLabReferral (String serial,String number,String pid,String stencil )

Metoda are patru parametri de intrare:

● parametrul serial de tip şir de caractere reprezintă seria biletului de trimitere;● parametrul number de tip şir de caractere reprezintă numărul biletului de

trimitere;● parametrul pid de tip şir de caractere reprezintă CNP-ul beneficiarului biletului de

trimitere;● parametrul stencil de tip şir de caractere reprezintă numărul de parafă al

medicului emitent;Metoda întoarce şir de caractere reprezentând fişierul de răspuns în format XML.

Pagina 2

16. Matricea de acoperire a serviciilor Web

Această matrice prezintă utilizarea metodelor Web prezentate anterior în cadrul diferitelor categorii de furnizori de servicii medicale şi farmaceutice. Pe verticală sunt prezentate cele 15 metode expuse, iar pe orizontală anexele specifice fiecărei categorii de furnizor.

A-001 A-002 A-003 A-004 A-005 A-006 A-007 A-008 A-009 A-010 A-011 A-012 A-013 A-014 A-015 A-016

1 X X X X X X X X X X X X X X X X2 X X X X X X X X X X X X X X X X3 X X X X X X X X X X X X X X X X4 X X X X X X X X X X X X X X X X5 X X X X X X X X X X X X X X X6 X X X7 X X X X X X X X X X X X X X X X8 X X9 X X X X X X X X X X X X X X X X

10 X X X X X X X X11 X X X X X X X12 X X X X X X X X13 X X14 X X15 X X X X X

1. Serviciul pentru sincronizarea nomenclatoarelor2. Serviciul pentru sincronizarea datelor de personalizare3. Serviciul pentru trimiterea raportărilor periodice4. Serviciul pentru preluarea rezultatelor raportărilor periodice5. Serviciul pentru preluarea decontului calculat în SIUI6. Serviciul pentru consultarea cererilor şi a deciziilor7. Serviciul pentru verificarea calității de asigurat8. Serviciul pentru pre-validarea mișcărilor de capitație9. Serviciul pentru pre-validarea serviciilor și investigațiilor medicale10. Serviciul pentru pre-validarea rețetelor prescrise de medici11. Serviciul pentru pre-validarea biletelor de trimitere emise de medici12. Serviciul pentru pre-validarea certificatelor medicale emise de medici13. Serviciul pentru pre-validarea reţetelor emise de farmacii14. Serviciul pentru consultarea reţetelor prescrise15. Serviciul pentru consultarea biletelor de trimitere

Verificarea calităţii de asigurat

Verificarea calităţii de asigurat este o funcţionalitate expusă exclusiv de SIUI, singurul sistem care gestionează centralizat la nivel naţional informaţiile care permit determinarea situaţiei în care se află o persoană din punct de vedere al plăţii contribuţiei, atât direct cât şi prin reţinere la sursă, precum şi orice alte documente doveditoare ale calităţii de asigurat conform normativelor în vigoare.

Pagina 2

Verificarea calităţii de asigurat este necesară din punctul de vedere al prescriptiei electronice în următoarele situaţii:

● La consultaţiei medicale, în urma căreia medicul va prescrie reţeta, pacientul trebuind să fie asigurat pentru a beneficia de reţeta prescrisă.

● În cazul eliberării medicamentelor în farmacii, când trebuie consultată şi calitatea de asigurat pentru ca furnizorul serviciilor farmaceutice să aibă o garanţie a decontării medicamentelor eliberate în regim de compensare sau gratuitate.

Pre-validarea reţetelor prescrise de medici

Reţetele compensate sau gratuite trebuie pre-validate în SIUI deoarece pacientul care beneficiază de ele poate să nu respecte anumite reguli impuse de CNAS, de exemplu că nu pate beneficia de acelaşi medicament într-un anumit interval, sau nu poate beneficia de mai multe reţete compensate pentru acelaşi diagnostic acut. De asemenea şi medicii care prescriu aceste reţete trebuie să îndeplinească anumite constrângeri, cum ar fi existenţa unui contract valabil cu CAS sau limitarea numărului de pacienţi care poate fi tratat într-un anumit interval ceea ce afectează numărul de reţete care pot fi prescrise.

Toate aceste validări sunt deja implementate în SIUI, şi sunt menţinute în concordanţă cu modificările legislative în acest domeniu ale CNAS. Utilizarea acestor servicii Web devine practic indispensabilă oricărui sistem care doreşte să realizeze aceste verificări pentru a se asigura compatibilitatea cu regulile implementate în SIUI, singurele în baza cărora se realizează decontarea reţetelor compensate şi gratuite.

Pre-validarea reţetelor eliberate de farmacişti

Reţetele compensate sau gratuite trebuie pre-validate în SIUI în scopul verificării respectării reglementărilor impuse de CNAS cu privire la eliberarea medicamentelor compensate. Fie că vorbim de impunerea unor plafoane lunare prin contractele pe care farmaciile le încheie cu CNAS, fie că e vorba de simple validări de formă sau consistenţă a datelor, singurul sistem capabil să realizeze acest lucru în prezent este SIUI. Datorită actualizării permanente în concordanţă cu normativele CNAS, SIUI va rămâne singurul sistem de referinţă în acest domeniu.

Verificarea existenţei reţetei prescrise de medic în sistem

Acest serviciu presupune verificarea la farmacie a reţetei prescrise de medic atât din punct de vedere al existenţei acesteia în sistem, dar şi a faptului că nu a mai fost deja eliberată în altă farmacie. În plus se poate verifica eliberarea corectă a medicamentelor prescrise de medic prin descărcarea informaţiilor existente în SIUI la momentul raportării pentru pre-validarea prescripţiei.

Acest lucru va fi cu atât mai important în cazul eliberării parţiale a unei reţete dacă un pacient nu găseşte toate medicamentele prescrise la aceeaşi farmacie. Acest lucru este imposibil în momentul de faţă, datorită necesităţii predării copiei unice a reţetei către farmacie în momentul eliberării medicamentelor, permiţând astfel doar o eliberare totală sau incompletă în cadrul unei singure farmacii.

Sincronizarea nomenclatoarelor de medicamente

Pentru a face posibilă utilizarea serviciilor Web expuse de SIUI, alte sisteme vor trebui să utilizeze în comunicarea cu acesta nomenclatoarele specifice, puse la dispoziţie de SIUI prin intermediul unui serviciu specializat. Aceste nomenclatoare sunt permanent

Pagina 2

actualizate şi sincronizate cu actele normative ale CNAS privind listele de medicamente compensate şi gratuite.

Pagina 2

17. Pachet pentru dezvoltatori software

În contextul interacţiunilor descrise mai sus, Ofertantul va trebui să pună la dispoziţia producătorilor de aplicaţii informatice furnizorilor de servicii medicale şi farmaceutice specificatiile tehnice necesare care să permită actualizarea aplicaţiilor dezvoltate de aceştia pentru a comunica cu sistemul SIUI.

10. Anexa 2- Definitiile serviciilor web expuse de sistemul SIUI

Pagina 2