SECTIUNEA II : CAIET DE SARCINI

SISTEM INFORMATIC INTEGRAT PENTRU

DOSARUL ELECTRONIC DE SNTATE
Cuprins
1. Prescurtri i definiii.............................................................................................7
2. Informaii Generale .............................................................................................10
2.1. Autoritatea contractant ............................................................................................10
2.1.1. Descrierea instituiei domeniu de activitate i atribuii .......................................................10
2.1.2. Structura CNAS.........................................................................................................................12
2.1.3. Locaia proiectului....................................................................................................................15
2.2. Context ......................................................................................................................15
2.2.1. Situaia actual.........................................................................................................................19
2.2.2. Situaia n viitor........................................................................................................................20
2.3. Programe i strategii relevante pentru proiect............................................................21
2.4. Beneficiarii proiectului (grupuri int).........................................................................24
3. Date generale despre proiect...............................................................................25
3.1. Obiectivul general al proiectului.................................................................................25
3.2. Obiectivul specific al proiectului.................................................................................25
3.3. Rezultate preconizate..................................................................................................27
3.4. Indicatori....................................................................................................................28
3.5. Impactul economic i social al proiectului...................................................................29
3.6. Beneficiile proiectului.................................................................................................29
4. Modele de evoluie a sistemului medical..............................................................32
4.1. Definiii i concepte....................................................................................................32
4.2. Organizarea sistemului Dosarul Electronic de Sntate al pacientului (DES)...............35
5. Descrierea tehnic a proiectului...........................................................................38
5.1. Arhitectura funcional a sistemului...........................................................................39
5.1.1. Subsisteme funcionale...........................................................................................................41
5.2. Vedere de ansamblu asupra sistemului informatic......................................................59
5.3. Scenarii de utilizare.....................................................................................................62

2
 5.3.1. Accident i INTERVENIE de urgen........................................................................................63
5.3.2. Internare la spital i operaie...................................................................................................64
5.3.3. Accesul asiguratului n portal...................................................................................................66
5.3.4. Internare la spital i investigaii laborator...............................................................................67
5.3.5. Dializ.......................................................................................................................................69
5.3.6. Auditarea sistemului.................................................................................................................70
5.3.7. Exemplu de urmrire a unui episod de boala..........................................................................70
5.3.8. Interogare date demografice....................................................................................................71
5.3.9. Interogare vocabulare..............................................................................................................71
5.3.10. Interogare uniti medicale....................................................................................................72
5.3.11. Trimitere la analize de laborator / radiologie i nregistrare rezultate...................................72
5.3.12. Consultarea istoricului medical al pacientului.......................................................................73
5.4. Date privind ngrijirea medicala..................................................................................74
5.4.1. Gestiunea nregistrrilor medicale...........................................................................................74
5.4.2. Gestiunea istoricului pacientului..............................................................................................74
5.4.3. Preferine, indicaii, consimminte i autorizaii....................................................................75
5.4.4. Liste specifice............................................................................................................................75
5.5. Suport clinic................................................................................................................76
5.5.1. Informaii despre prestatorul de servicii medicale..................................................................76
5.5.2. Registrul pacienilor (preluate din eCard)................................................................................77
5.6. Rapoarte, msurtori, analiza i cercetare..................................................................78
5.6.1. Rezultate i analize...................................................................................................................78
5.6.2. Generarea rapoartelor.............................................................................................................78
5.7. Administrarea accesului .............................................................................................79
5.7.1. Autentificarea entitilor..........................................................................................................79
5.7.2. Autorizarea entitilor..............................................................................................................80
5.7.3. Controlul accesului...................................................................................................................80
5.7.4. Gestiunea accesului pacienilor...............................................................................................80
5.7.5. Recunoaterea aciunilor..........................................................................................................80
5.7.6. Schimbul sigur de date.............................................................................................................81
5.7.7. Rutarea securizata a datelor.....................................................................................................81
5.7.8. Certificarea informaiilor..........................................................................................................81
5.7.9. Gestiunea nregistrrilor medicale...........................................................................................83

3
 5.7.10. Stocarea i gestiunea informaiilor medicale.........................................................................84
5.8. Servicii pentru registre i directoare............................................................................84
5.9. Interoperabilitate bazata pe standarde.......................................................................85
5.9.1. Standarde de schimb de date...................................................................................................85
5.9.2. Integrarea intre aplicaii bazata pe standarde.........................................................................85
5.9.3. Acorduri de schimb de date.....................................................................................................85
5.10. Cerine tehnice generale...........................................................................................86
5.10.1. Flexibilitatea sistemului..........................................................................................................87
5.10.2. Performanta i disponibilitate................................................................................................88
5.10.3. Date de dimensionare ...........................................................................................................88
5.11. Funcionaliti expuse de sistemul SIUI prin servicii web..........................................88
5.11.1. Fluxuri de date ntre componente........................................................................................103
5.11.2. Raportrile SIUI....................................................................................................................105
5.11.3. Nomenclatoare - cataloage SIUI...........................................................................................106
5.11.4. Integrri SIUI.........................................................................................................................107
5.12. Fluxuri de date intre componente ..........................................................................115
5.12.1. Fluxuri de execuie SOA (Service Oriented Architecture)....................................................115
5.12.2. Fluxuri de autorizare i autentificare....................................................................................116
5.12.3. Fluxuri de suport pentru funcionalitatea de raportare.......................................................117
5.12.4. Fluxuri de procesare a evenimentelor de monitorizare.......................................................117
5.12.5. Cerine subsistem de integrare............................................................................................118
5.12.6. Cerine subsistem monitorizare...........................................................................................123
5.12.7. Cerine subsistem audit........................................................................................................123
5.12.8. Cerine subsistem salvare i restaurare................................................................................123
5.12.9. Cerine subsistem help desk.................................................................................................124
5.12.10. Cerine subsistem de arhivare............................................................................................124
5.12.11. Cerine subsistem de comunicaii......................................................................................124

6. Cerine tehnice detaliate....................................................................................126

6.1. Cerine hardware detaliate.......................................................................................127
6.1.1. Cerine minime obligatorii pentru sistem de procesare a datelor (2 buci) ........................129
6.1.2. Cerine minime obligatorii pentru infrastructura de stocare (2 buci):................................131
6.1.3. Cerine minime obligatorii pentru infrastructura de biblioteca de benzi (1 bucata):...........134
6.1.4. Cerine minime obligatorii pentru infrastructura de SAN (2 buci):....................................137

4
 6.1.5. Cerine comunicaii................................................................................................................140
6.2. Cerine software detaliate.........................................................................................143
6.2.1. Monitorizare sisteme i aplicaii...........................................................................................143
6.2.2. Help Desk (Sistem suport utilizatori)......................................................................................149
6.2.3. Salvare i restaurare ..............................................................................................................150
6.2.4. Gateway de Securitate...........................................................................................................152
6.2.5. Integrare aplicaii....................................................................................................................154
6.2.6. Server de Procese...................................................................................................................156
6.2.7. Registru servicii.......................................................................................................................161
6.2.8. Portal......................................................................................................................................162
6.2.9. Integrare date........................................................................................................................172
6.2.10. Analiza i raportare...............................................................................................................174
6.2.11. Data Warehouse...................................................................................................................176
6.2.12. Platforma de baze de date relaionala.................................................................................177
6.2.13. Audit.....................................................................................................................................179

7. Cerine servicii de implementare........................................................................181

7.1. Mod de implementare..............................................................................................181
7.1.1. Servicii de implementare........................................................................................................181
7.1.2. Planificarea activitilor..........................................................................................................182
7.1.3. Metodologia de dezvoltare a sistemului................................................................................183
7.2. Servicii de management de proiect...........................................................................188
7.2.1. Metodologia de management de proiect..............................................................................188
7.2.2. Activiti de management de proiect.....................................................................................189
7.2.3. Cerine de raportare ..............................................................................................................190

8. Cerine de administrare, operare i mentenan.................................................194

8.1. Funcionaliti de tip suport pentru DES...................................................................194
8.2. Cerine mentenan..................................................................................................194
8.2.1. Servicii de suport hardware n garanie.................................................................................194
8.2.2. Suportul software n garanie.................................................................................................195

9. Testarea, instalarea, punerea n funciune i recepia sistemului........................197

9.1. Cerine globale..........................................................................................................197
9.2. Organizarea activitii de testare..............................................................................197

5
 9.3. Organizarea certificrii (testrii de conformitate a) aplicaiilor client........................198
10. Cerine de instruire a utilizatorilor....................................................................200
10.1. Instruire..................................................................................................................200
10.2. Cerine generale......................................................................................................200
10.3. Cerine specifice......................................................................................................201

6
 1. Prescurtri i definiii

Termen Explicaie
ADT Admission, Discharge and Transfer
BI Business Intelligence
CA Certificate Authority
CASE Cardul de Asigurare de Sntate European
CASMB Casa de Asigurri de Sntate a Municipiului Bucureti
Casa Asigurrilor de Sntate a Ministerului Transporturilor,
CASMTCT Construciilor i Turismului
Casa Asigurrilor de Sntate a Aprrii, Ordinii Publice,
CASAOPSNAJ Siguranei Naionale i Autoritii Judectoreti
CDA Clinical Document Architecture
CDR Clinical Data Repository
CEN Comisia European de Normalizare (Standardizare)
CIS Clinical Information System
CEAS Cardul Electronic de Asigurri de Sntate
CJAS Casa Judeean de Asigurri de Sntate
CMS Centers for Medicare and Medicaid Services
CNAS Casa Naional de Asigurri de Sntate
CNIN Compania Naional "Imprimeria Naional"
CNP Codul Numeric Personal
DES Dosar Electronic de Sntate
DICOM Digital Imaging and Communications n Medicine
DMR Date Medicale Relevante
DMZ DeMilitarized Zone
EAL4 Evaluation Assurance Level 4
ECG Elector CardioGrama
EHR Electronic Health Record
EMR Electronic Medical Record
EPR Electronic Patient Record
epSOS European Patients Smart Open Services
ETL Extract Transform Load
FNUASS Fondul Naional Unic de Asigurri de Sntate
FOCG Foaia de Observaie Clinic General
GP General Practitioner

7
Termen Explicaie
HIPAA Health Insurance Portability and Accountability Act
HIS Hospital Information System
Health Information Technology for Economic and Clinical
HITECH Health
HL7 Health Level Seven
HL7 V3 Health Level Seven Version 3
HTTP Hyper Text Transfer Protocol
ICD International Classification of Diseases
International Classification of Diseases, 9th Revision, Clinical
ICD-9-CM Modification
International Classification of Diseases, 10th Revision, Clinical
ICD-10-CM Modification
International Classification of Diseases, 10th Revision,
ICD-10-PCS Procedure Coding System
IDS Intrusion Detection System
IPS Intrusion Prevention System
IHE Integrating Healthcare Enterprise
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
LDAP Lightweight Directory Access Protocol
LIS Laboratory Information System
LOINC Logical Observation Identifiers Names and Codes
MF Medic de Familie
MS Ministerul Sntii
OCSP Online Certificate Status Protocol
OHR Open Healthcare Framework
OR / ER Operating Room or Emergency Room
PACS Picture Archiving and Communications System
PCP Primary Care Physician
PDQ Patient Demographics
PHR Personal Health Record
PIN Personal Identification Number
PIX Patient Identifier Cross-Reference
PKI Public Key Infrastructure
POC Point Of Care
POS Point Of Service

8
Termen Explicaie
PSM Prestator de Servicii Medicale
PSQIA Patient Safety and Quality Improvement Act
RBAC Role Based Access Control
RIM Reference Information Model
ROI Return On Investment
SAN Storage Area Network
SEHR Shared Electronic Health Record
SI Sistem Informatic
SIUI Sistemul Informatic Unic Integrat al CNAS
SNOMED Systematized Nomenclature of Human Medicine
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SSL Secure Sockets Layer
SSO Single Sign On
TI Tehnologia Informaiei
TIC Tehnologia Informaiei i a Comunicaiei
UDDI Universal Description, Discovery and Integration
UE Uniunea European
UI User Interface
UML Unified Method Language
UPS Uninterruptible Power Supply
UTF-8 Unicode Transformation Format 8
VLAN Virtual Local Area Network
VPN Virtual Private Network
WS Web Services
WSDL Web Service Definition Language
XDS Cross Enterprise Clinical Document Sharing
XML Extensible Markup Language

9
2. Informaii Generale

2.1. Autoritatea contractant

Numele instituiei conform actului de Casa Naionala de Asigurri de Sntate

nfiinare:
Cod de nregistrare fiscal: 11697800
Adresa potal: Calea Clrai 248, Bl. S19, Sector 3,
030634, Bucureti
Telefon / Fax: 0372309252 / 0372309165
Adresa e-mail: cabinet.presedinte@casan.ro

2.1.1. Descrierea instituiei domeniu de activitate i atribuii

Casa Naional de Asigurri de Sntate (CNAS) este instituie public, autonom, de

interes naional, cu personalitate juridic, al crei principal obiect de activitate l reprezint
asigurarea funcionrii unitare i coordonate a sistemului asigurrilor sociale de sntate
din Romnia.
Sistemul asigurrilor sociale de sntate ofer un pachet de servicii de baz care cuprinde
servicii medicale, servicii de ngrijire a sntii, medicamente, materiale sanitare i
dispozitive medicale.

CNAS funcioneaz pe baza Statutului propriu i are urmtoarele obligaii:

o s asigure logistica funcionrii unitare i coordonate a sistemului asigurrilor sociale
de sntate;
o s urmreasc folosirea cu eficien a fondului de asigurri sociale de sntate;
o s foloseasc mijloace adecvate de mediatizare pentru reprezentarea, informarea i
susinerea intereselor asigurailor pe care i reprezint;
o s acopere nevoile de servicii de sntate ale persoanelor, n limita fondurilor
disponibile.
o CNAS are n subordine casele judeene de asigurri de sntate, Casa de Asigurri de
Sntate a Municipiului Bucureti, Casa Asigurrilor de Sntate a Ministerului
Transporturilor, Construciilor i Turismului, Casa Asigurrilor de Sntate a Aprrii,
Ordinii Publice, Siguranei Naionale i Autoritii Judectoreti.

Principalele atribuii ale CNAS:

asigur, supravegheaz i controleaz funcionarea sistemului de asigurri sociale de
sntate;
gestioneaz, prin intermediul preedintelui CNAS, FNUASS n concordan cu legile
n vigoare i avnd n subordine casele judeene de asigurri de sntate, inclusiv
CASMB, CASMTCT i CASAOPSNAJ
propune, cu avizul MS, proiecte de acte normative pentru asigurarea funcionrii
sistemului de asigurri de sntate i acord avize conform proiectelor de acte
normative care au inciden asupra FNUASS
elaboreaz, implementeaz i gestioneaz procedurile i formularele unitare, avizate de
ctre MS, pentru administrarea sistemului de asigurri de sntate
elaboreaz i public rapoarte anuale
asigur organizarea sistemului informatic i informaional unic integrat pentru
nregistrarea asigurailor i pentru gestionarea FNUASS. Indicatorii folosii n
raportarea datelor n sistemul de asigurri de sntate sunt unitari i se stabilesc de
ctre MS la propunerea CNAS, Colegiul Medicilor din Romnia i Colegiul Medicilor
Stomatologi din Romnia
aprob anual bugetele de venituri i cheltuieli ale caselor de asigurri de sntate n
condiiile legii i, dup caz, cu avizul ministerelor i al instituiilor centrale cu reele
sanitare proprii, corespunztoare unui plan de activiti, precum i obiectivele de
investiii, la propunerea acestora;
negociaz criteriile privind calitatea asistenei medicale acordate asigurailor din
sistemul de asigurri sociale de sntate, elaborate de Colegiul Medicilor din Romnia;
particip la licitaiile naionale organizate de Ministerul Sntii n vederea achiziiei
de medicamente i materiale sanitare specifice pentru realizarea programelor de
sntate i ncheie i deruleaz contracte de achiziii publice pentru medicamente i
materiale sanitare specifice pentru realizarea acestor programe;
o asigur i controleaz respectarea dreptului asigurailor la servicii medicale,
medicamente i materiale sanitare n mod nediscriminatoriu, n condiiile legii;
o asigur, monitorizeaz i controleaz modalitatea de eliberare a medicamentelor;
o particip la acreditarea furnizorilor de servicii medicale, de dispozitive medicale i de
medicamente, care pot fi admii s lucreze n sistemul de asigurri sociale de sntate;
o acord gratuit informaii, consultan i asisten n domeniul asigurrilor sociale de
sntate persoanelor asigurate, angajatorilor i furnizorilor de servicii medicale.

2.1.2. Structura CNAS

Structura organizatoric CNAS se prezint dup cum urmeaz:
o Preedinte
o Vicepreedinte
o Vicepreedinte
o Director General
o Direcia General Management
o Direcia General cu Furnizorii
o Direcia General Evaluare
o Direcia Monitorizare i Corp Control
o Direcia Relaii Media, Relaii publice, Purttor de cuvnt
o Compartiment Audit Public Intern
o Direcia Juridic, Contencios i Acorduri Internaionale
o Direcia Resurse Umane
o Direcia Sisteme Informatice
o Direcia Strategii, Metodologii i Norme
o Centrul de Prognoz i Planificare
o Direcia Contractare, Decontare
o Direcia Buget, Creane, Indemnizaii i Concedii Medicale
o Direcia Financiar, Contabilitate i Salarizare
o Direcia Logistic
o Serviciul Achiziii Publice, Contracte, Investiii
o Direcia Evaluare Furnizori
o Direcia Programe Naionale
Diagrama de relaii a Casei Naionale de Asigurri de Sntate:
 2.1.3. Locaia proiectului
ROMNIA
Judeul / Judee: Bucureti
Localitatea / Localiti: Bucureti
Adresa / Adresele de Splaiul Independenei nr. 323A, sector 6, Bucureti, cod
implementare: potal 060044

2.2. Context

Serviciile medicale de nalt calitate oferite pacienilor i crearea unui spaiu informaional
unic n domeniul sntii reprezint principalele coordonate ale strategiei e-Sanatate
promovat de Comisia Europeana la nivelul arilor membre. n 2004, Comisia European a
adoptat planul de aciune e-Sanatate, cu scopul de a armoniza i completa modul de abordare
al rilor membre UE n adoptarea i implementarea sistemelor de tip e-Sanatate. Planul de
aciune acoper toate sistemele aferente serviciilor de sntate, de la prescripia electronic,
pn la noi sisteme care sporesc eficiena cadrelor medicale i care reduc nivelul de erori
medicale. O prioritate n acest sens este dezvoltarea unei infrastructuri informaionale,
infrastructur ce i propune eficientizarea mediului medical n statele membre, mediu n care
se resimte acut nevoia de partajare a informaiilor de natur clinic i nu numai.
Dimensiunea informatizrii sistemului de sntate depete sfera IT, pentru realizarea cu
succes a acesteia fiind necesar armonizarea cadrului legal, a cadrului de desfurare a actului
medical i un efort susinut n domeniul TIC. Informatizarea sistemului de sntate nu
presupune doar implementarea unui sistem informatic, ci i adaptarea cadrului legal astfel
nct s suporte facilitile sistemului fr a crea tensiuni ntre pacieni i cadrele medicale,
dar i alinierea procedurilor din domeniul sntii cu noua perspectiv a sistemului
informatizat.
Informatizarea cu succes a sistemului de sntate presupune agregarea specificului celor 3
deziderate menionate anterior ntr-o strategie unic naional de informatizare, al crei scop
unic principal s fie poziionarea pacientului n mijlocul sistemului de sntate, n
conformitate cu strategia e-Sanatate la nivel european. Pn n prezent, direciile de
informatizare ale sistemului de sntate au vizat mai mult eficientizarea i mbuntirea
controlului asupra raportrilor fcute de furnizorii de sntate, dect orientarea ctre
eficientizarea i mbuntirea episodului de ngrijire.
Un aspect foarte important este susinerea politic de care acest program beneficiaz, fiind
inclus n Programul de Guvernare 2009-2012. Acest lucru, n corelaie cu programul privind
strategia e-Sanatate la nivelul comunitii europene, completeaz i creeaz premisele
dezvoltrii i implementrii unei strategii naionale de informatizare a sistemului de sntate.
n prezent, tehnologiile TIC sunt utilizate aproape n tot sistemul sanitar, n moduri diferite i
pentru scopuri diferite. Fa de alte sectoare, tehnologiile informaionale i comunicaionale
sunt folosite mult mai puin n sntate. Pana n prezent, doar anumite domenii din sectorul
sanitar au utilizat tehnologii TIC, din diverse motive: dificulti n agrearea unor cerine
specifice de interoperabilitate pentru soluiile e-Sntate, nevoia de comunicare nu a fost aa
de mare n trecut, dar i costurile ridicate ale soluiilor IT. Multe dintre instrumentele TIC
sunt utilizate doar pentru o mic parte din sarcinile pe care le-ar putea prelua, iar
interoperabilitatea este foarte limitat. De asemenea, investiiile n IT nu au fost nsoite de
dezvoltarea competenelor utilizatorilor. n plus, costurile privind mentenana i operarea
post-implementare au fost de cele mai multe ori subestimate.
Proiectul se afl n concordan cu Planul Naional de Dezvoltare a Romniei 2007 2013
ntruct promoveaz dezvoltarea economiei bazate pe cunoatere prin accelerarea dezvoltrii
societii informaionale. Acest aspect va fi realizat n cadrul proiectului prin dezvoltarea
serviciilor de e-sntate destinate facilitrii actului medical, prin accesarea n timp real a
datelor despre pacient, a istoricului sau medical, a rezultatelor investigaiilor efectuate,
tratamentele pe care le urmeaz i eventualele intolerane ale pacientului la anumite substane
medicale.
Proiectul rspunde prioritii Cadrului Strategic Naional de Referina 2007 2013
consolidarea unei capacitai administrative eficiente pentru ca i aduce aportul la
mbuntirea proceselor decizionale n domeniul managementului sanitar prin dezvoltarea
unui sistem informatic integrat de consemnare i monitorizare a traseului medical al
pacientului la furnizorii de servicii de sntate, ceea ce contribuie la adoptarea unor decizii
optime privind diagnosticarea pacienilor i prescrierea reetelor medicale. Prin urmare,
soluia Dosarul Electronic de Sntate - DES va reprezenta un instrument eficient de
comunicare ntre toate prile implicate (pacieni, prestatorii de servicii medicale, Casa
Naional de Asigurri de Sntate i Casele Judeene de Asigurri de Sntate), avnd rolul
de evitare a suprapunerii prescrierilor i investigaiilor i de cretere a calitii serviciilor
medicale.
Succint, situaia actual a sistemului romnesc de sntate poate fi caracterizata prin:
o Implementare insuficient a standardelor TIC;
o Lipsa cooperrii;
o Nivel sczut de interoperabilitate ntre sistemele TIC actuale;
o Nivel sczut de informatizare la nivelul furnizorilor de servicii de sntate;
Lipsa aplicrii standardelor naionale i internaionale acceptate este unul dintre motivele
principale ale interoperabilitii sczute a sistemelor TIC actuale. Astfel, dificultile rezultate
din problemele de integrare a datelor i problemele semantice ale schimbului de informaii
reprezint o consecin logic a acestei situaii. Sistemul actual al serviciilor de sntate din
Romnia utilizeaz foarte multe circuite de informaii pe hrtie i semi-standardizate cu
interoperabilitate semantic sczut, ceea ce implic munca laborioas de introducere a
datelor, calitate sczut a acestora i conduce la o rat potenial mare de producere a erorilor.
Acest lucru determin ntrzieri n finalizarea rapoartelor i costuri mari de operare ale unui
astfel de sistem.
Standardele din domeniul sntii nu nseamn doar liste ale codurilor standard i
terminologii clinice, ci i existena unor concepte acceptate la scar larg, exprimate ntr-un
model informatic formal, care este descris ntr-un dicionar de date i care st la baza seturilor
standard de date utilizate pentru comunicarea dintre actorii din sistemul sanitar.
Din cauza lipsei standardizrii i a coordonrii n sistemul de sntate, exist multe sisteme
informatice care nu fac schimb de date i nu folosesc interfee pentru comunicare. Rezultatul
acestei situaii este interoperabilitatea sczut a sistemelor existente i redundana circuitelor
de date. Aceasta nseamn ca sistemele informatice nu sunt capabile sa fac schimbul eficient
de date din cauza sensului inconsecvent din aceste sisteme i nu pot coopera pentru a
ndeplini serviciile necesare.
n ciuda mbuntirilor treptate ale nivelului de informatizare, nc nu exist suficiente
resurse TIC la nivelul furnizorilor de servicii de sntate. n timp ce spitalele mari au un nivel
de informatizare satisfctor, spitalele mici i cabinetele ambulatorii nu dispun de
calculatoare (reeaua transfuziilor de snge este un bun exemplu n acest sens). Mai mult,
personalul angajat n sntate se caracterizeaz printr-un nivel sczut de cunotine IT,
situaie care poate fi depit prin programe de instruire pentru utilizatori. Exist, totodat, i
un numr insuficient de specialiti TIC la nivelul furnizorilor de servicii de sntate i la
nivelul autoritilor centrale.
Sistemul informatic din domeniul sntii din Romnia este o colecie de sisteme,
instrumente, procese i documente eterogene. Se dorete exploatarea registrelor existente deja
n SIUI precum i extinderea i completarea lor cu noile informaii / registre necesare.
Informatizarea sistemului de sntate face parte din proiectul reformei sectorului sanitar,
avnd ca obiective finale mbuntirea managementului i a finanrii sectorului sanitar,
permind un control mai eficient al distribuiei resurselor financiare, ntrirea posibilitii de
control, eficientizarea sistemului, mbuntirea calitii serviciilor de sntate. Tehnologiile
informatice reprezint o dimensiune obligatorie a sistemului de sntate, crescnd calitatea
serviciilor de sntate i fiind o surs de economii financiare n sistem.
n absena implementrii reglementarilor unitare privind standardele de informatizare,
precum i datorit inexistenei unui sistem de acreditari, certificri, avizri pentru furnizori,
sistemele informatice s-au realizat i implementat ntr-o manier dezorganizat. Acest lucru a
fcut ca informatica, n loc sa ajute activitatea medical, s genereze mai degrab confuzie,
birocraie i nesiguran. Au aprut paralelisme n culegerea datelor primare, dublarea unor
circuite de raportare, incompatibiliti datorit utilizrii unor definiii diferite ale indicatorilor
i a unor codificri proprietare, etc.. Din punct de vedere al derulrii unor investiii specifice,
nu o dat a fost reluat informatizarea unor sectoare care aveau deja soluii acceptabile, n
detrimentul altor zone, ceea ce a generat neutilizarea eficient a fondurilor publice.
Practica medical internaional de tip e-Sanatate permite folosirea tehnologiilor
informaionale i de comunicare i n sectorul medical, prin realizarea dosarelor pacienilor
pe suport electronic, facilitnd accesul la informaie, crescnd calitatea actului medical,
reducnd costurile i eficientiznd sistemele de sntate.
Din punct de vedere al fiei pacienilor, sunt reglementate o serie de aspecte i proceduri care
prevd obligativitatea furnizorilor de sntate sa pstreze n format electronic sau scriptic
informaii minime privind starea de sntate a unui pacient. Un astfel de exemplu este
Ordinul nr. 1782/2006 care prevede obligativitatea utilizrii Foii de Observaie Clinic
General (denumita n continuare, n spiritul actului normativ, FOCG) pentru episoadele de
spitalizare continu i a Foii pentru Spitalizarea de Zi (denumit n continuare, n spiritul
actului normativ, FSZ) pentru pacienii care beneficiaz de servicii medicale n regim de
spitalizare de zi. Mai mult, actul normativ prevede un set minim de informaii clinice pe care
unitile sanitare trebuie s le raporteze lunar. Totui, din reglementrile actului normativ, este
destul de uor de dedus c scopul principal al acestei proceduri este cel de creare a unui cadru
informatic pentru a facilita raportarea serviciilor medicale prestate i pentru a putea culege
informaii de tip statistic i nu de centralizare a informaiilor clinice ale pacientului ntr-o fi
unic. n contextul unei strategii naionale de informatizare, actul normativ trebuie modificat
astfel nct, pe lng obiectivul de raportare, s fie atins i cel de centralizare a informaiilor
pacientului. n anul 2007, Ministerul Sntii a iniiat o aciune naional de colectare i
centralizare a strii de sntate a populaiei Romniei. Rezultatele ar fi trebuit, conform
termenelor comunicate iniial, s fie centralizate pn la sfritul anului 2008, ns n acest
moment este incert starea actual. Informaiile de acest tip ar putea reprezenta o surs
important n cadrul unei strategii naionale n domeniul sntii. De asemenea, n
contractul-cadru de acordare a asistenei medicale pentru anul 2009 sunt prevzute o serie de
reglementri care au scopul de a ncuraja raportarea n format electronic a laboratoarelor.
Msura de ncurajare este de tip financiar, prin acordarea unui numr de puncte mai mare
pentru laboratoarele care gestioneaz i raporteaz activitatea n format electronic.
Un alt aspect foarte important l reprezint multitudinea de aplicaii dedicate informaiilor i
serviciilor medicale implementate n sectorul privat. Conform situaiei prezentate n raportul
ce vizeaz situaia actual, exist o serie de uniti sanitare care au implementat i utilizeaz
astfel de programe. Un aspect negativ, care trebuie ns tratat n contextul unei strategii
naionale de informatizare, l reprezint lipsa interoperabilitii ntre sisteme, att din punct de
vedere semantic i tehnic, ct i din punct de vedere legal. Lipsa implementrii unor
standarde privind fia pacientului i lipsa unui cadru legal de reglementare a aspectelor legale
privind crearea, consultarea i drepturile de proprietate ale dosarului electronic fac practic
imposibil unificarea informaiilor pentru pacienii care au mai multe dosare de sntate de
tip electronic.
Analiznd ntregul cadru al sistemului sanitar din Romnia, se poate desprinde concluzia c
exist o serie de iniiative i realizri care pot fi considerate ntr-o anumit msur ca
reprezentnd o parte din strategia de informatizare. Aici menionm sistemul SIUI care a
adoptat un model de funcionare centralizat din decembrie 2010; celelalte eforturi n
domeniu sunt descentralizate sau nu au o viziune comun la toate nivelurile. Orientarea
strategic european n domeniul e-sntii recomand accelerarea construirii unei reele
sigure de informaii n domeniul sntii, extinderea utilizrii cardului n sntate, precum i
asigurarea accesului on-line la datele medicale ale pacientului.
Aceeai tendin este, de asemenea, prevzut i n liniile directoare pentru Cardul de
Asigurare de Sntate European (European Health Insurance Card) precum i de planurile de
dezvoltare individuale ale Statelor Membre.

2.2.1. Situaia actual

Actualmente, n domeniul sntii, funcioneaz un Sistem Informatic Unic Integrat (SIUI)
destinat gestiunii Fondului Naional Unic de Asigurri Sociale de Sntate prin gestiunea on-
line a tuturor informaiilor medicale ale pacienilor asigurai, sistem ce este administrat de
CNAS i de care beneficiaz CNAS i Casele Judeene de Asigurri de Sntate. Medicii i
prestatorii de servicii medicale introduc n acest sistem toate consultaiile, bolile i
tratamentele pacienilor asigurai cu scopul decontrii acestora. SIUI proceseaz la momentul
de fa tranzacii de tip asigurri sociale, n calitate de pltitor de servicii de sntate; n SIUI
se proceseaz de asemenea aspecte privind autentificarea, gestionarea solicitrilor i a
rambursrilor. n plus, exist date centralizate despre statistici, registre i date tranzacionale
ale furnizorilor de servicii medicale (ex.: spitale, farmacii i medici de familie, precum i
clinici de zi i clinici cu regim ambulatoriu).
Trecerea treptat de la nregistrarea datelor medicale pe suport de hrtie la cea pe suport
electronic este determinat att de progresul din cercetarea medical, ct i de cel din
domeniul tehnologiei. Tradiionalul registru medical pe hrtie, care funcioneaz ca un
depozit static al datelor ce reflect starea de sntate a pacientului n mod fracionat i care se
afl ntr-un singur loc, ngrdind astfel accesul la aceste date, nu mai este n msur s
satisfac cerinele noi din domeniul ngrijirii sntii.

2.2.2. Situaia n viitor

CNAS, avnd competena necesar, i-a asumat responsabilitatea definirii i implementrii
soluiilor informatice pentru::
cardul de sntate (eCard). Proiectul eCard (funcionalitate a SIUI) care i propune s
devin un instrument de autentificare n cadrul tuturor sistemelor informatice care
compun strategia de eSntate n Romnia precum i un instrument de prevenire a fraudei
n domeniul sntii.
prescripia electronic (ePrescripie). Proiectul ePrescripie (funcionalitate a SIUI)
contribuie la creterea calitii actului medical de prescriere a medicamentelor, precum i
un instrument de monitorizare a necesarului i consumului de medicamente n Romnia.
dosarul electronic de sntate al pacientului (DES). Prin acest proiect se face trecerea la
forma electronic a dosarului de sntate al pacientului prin intermediul cruia cetenii
asigurai vor beneficia de un nivel mai ridicat al calitii serviciilor medicale.
Prin intermediul acestor proiecte se asigur mecanisme pentru autentificarea i autorizarea
ceteanului pentru a primi servicii medicale i de colectare a datelor de sntate la nivel
naional. Adiional, aceste mecanisme pot s asigure o reducere a timpului de ateptare a
ceteanului pentru a primi servicii medicale, vor crete nivelul de calitate a datelor medicale
i vor preveni frauda n domeniul sntii.
 2.3. Programe i strategii relevante pentru proiect

Proiectul se afl n concordan cu obiectivul specific al Domeniului Major de Intervenie 2

(Dezvoltarea i creterea eficienei serviciilor publice electronice) ntruct are ca scop
oferirea de servicii medicale prin mijloace electronice, crend astfel beneficii att pentru
utilizatori (ceteni), ct i pentru solicitant. Beneficiile pentru ceteni se manifest, n
principal, prin ntrirea statutului pacientului i o mai bun participare a acestuia la actul
medical, precum i prin furnizarea de servicii de asisten medical fr limite operaionale,
administrative sau geografice. Beneficiile la nivel instituional mbrac forma unor
instrumente de lucru pentru personalul din sntate, ceea ce acioneaz n direcia
eficientizrii managementului resurselor i a creterii eficienei economice a serviciilor de
sntate.
Extinderea utilizrii TIC va asigura simplificarea procedurilor de lucru i a procesului
decizional din cadrul instituiei solicitante. Aceasta va favoriza furnizarea mai eficient a
serviciilor i creterea calitii lor n folosul cetenilor.

TIP DENUMIRE MOD DE RELAIONARE

PROGRAM POSCCE Programul Obiectivul specific al Domeniului Major
Operaional Sectorial de Intervenie 2 aferent Axei 3 este de a
Creterea Competitivitii pune la dispoziie serviciile administrative
Economice prin mijloace electronice, att pentru
utilizatori (ceteni i mediul de afaceri),
ct i pentru administraia publica.
Beneficiile utilizatorilor pot fi exprimate
succint printr-un acces facil la serviciile
administraiei publice. Pentru autoritile
care utilizeaz tehnologia informaiei i
comunicaiilor n scopul furnizrii de
servicii electronice, aceasta nseamn noi
oportuniti, dar i schimbri interne la
nivel organizaional. Rezult conformitatea
proiectului propus cu respectivul obiectiv
avnd n vedere faptul c va facilita accesul
personalului medical la istoricul medical al
 pacientului dar i accesul mai facil al
pacienilor la serviciile de sntate
Proiectul propus susine prin aciunile i
rezultatele urmrite (scderea timpului
necesar diagnosticrii, deci reintegrarea
mai rapida n cmpul muncii) crearea unui
mediu de afaceri favorabil pentru
dezvoltarea ntreprinderilor, obiectiv
specific al Axei prioritare 1 a POSCCE
direct, prezentul proiect fiind elaborat n
vederea finanrii n cadrul Axei Prioritare
3 privind creterea interaciunii ntre
sectorul public i ceteni prin valorificarea
potenialului TIC.
PROGRAM PODCA Programul - direct, relaionare att cu Axa Prioritara 1
Operaional Dezvoltarea mbuntiri de structur i proces ale
Capacitaii Administrative managementului ciclului de politici
publice, ct i cu Axa Prioritara 2
mbuntirea calitii i eficienei
furnizrii serviciilor publice cu accentul
pus pe procesul de descentralizare.
Prezentul proiect constituie un instrument
pentru atingerea unor obiective, precum:
mbuntirea procesului de luare a
deciziilor, mbuntirea eficacitii
organizaionale, mbuntirea calitii i
eficienei serviciilor furnizate de ctre
solicitant.
STRATEGIE Strategia de e-Santate - direct, prin faptul ca proiectul contribuie
la extinderea procesului de informatizare a
sectorului sanitar din Romnia prin
ntrirea statutului pacientului i o mai
bun participare a acestuia la actul medical;
furnizarea de servicii de asisten medical
 fr limite operaionale, administrative sau
geografice; instrumente de lucru mai bune
pentru personalul din sntate;
management eficient al resurselor i
eficiena economic n serviciile de
sntate i crearea condiiilor pentru
utilizarea soluiilor TIC n sntate
PROIECT SIUI Interfaare pentru schimb de date privind
persoanele asigurate.
Sistemul informatic DES va fi integrat cu
sistemele informatice deja existente,
respectiv cu sistemul SIUI al CNAS, care
va integra proiectele eCard i ePrescriptie,
fiind capabil sa schimbe date n formatele
cerute de ctre acest sistem. Modalitatea
principal de schimb de date va fi de tipul
sistem la sistem, folosind tehnologii de tip
servicii web.
ALT Planul Naional de Dezvoltare - direct, proiectul sprijinind atingerea
DOCUMEN (PND) 2007 2013 obiectivelor PND respectiv creterea
T competitivitii economice, mbuntirea
RELEVANT capacitii administraiei publice de
LA NIVEL formulare i implementare a politicilor
NAIONAL publice, creterea calitii serviciilor
/REGIONA publice (inclusiv prin reducerea birocraiei
L i realizarea unei administraii eficiente,
moderne i orientate ctre cetean).
ALT Planul Naional de Reforme - direct, proiectul contribuind la
DOCUMEN promovarea TIC n administraie prin
T sisteme e-sntate. De asemenea, proiectul,
RELEVANT prin implementarea sa, dinamizeaz
LA NIVEL procesul de simplificare administrativ,
NAIONAL unul din obiectivele majore ale reformei
/REGIONA administraiei publice, venind astfel n
L sprijinul ceteanului i al administraiei
nsi.
2.4. Beneficiarii proiectului (grupuri int)

Principalele entiti care vor beneficia de implementarea proiectului sunt:

Casa Naional de Asigurri de Sntate - are rolul de achizitor i administrator al sistemului
i va asigura coordonarea implementrii proiectului i integrrii acestuia cu sistemul SIUI
care va avea implementate i funcionalitile de card electronic de sntate i de prescripie
electronic.
Casele Judeene de Asigurri de Sntate - au rolul de reprezentani ai CNAS n teritoriu i
vor asigura coordonarea implementrii proiectului, n aria de acoperire gestionat.
Populaie toi cetenii Romniei, persoane asigurate, care beneficiaz conform legislaiei
actuale de servicii de asisten medical gratuite.
Mediul prestatorilor de servicii de sntate public din Romnia toate unitile de asisten
medical i prestatori de servicii de sntate public existente i care contribuie la asigurarea
asistenei medicale
3. Date generale despre proiect

3.1. Obiectivul general al proiectului

Prin acest proiect se dorete trecerea la forma electronic a dosarului de sntate al

pacientului prin intermediul creia cetenii Romniei vor beneficia de un nivel mai ridicat al
calitilor serviciilor medicale. Obiectivul general poate fi sintetizat astfel:
Creterea calitii sistemului de sntate din Romnia prin implementarea Dosarul
Electronic de Sntate al pacientului (DES);
Prezentarea ntr-o manier consistent i consolidat a tabloului clinic al pacienilor
asigurai, lucru ce vine n sprijinul direct al corectitudinii deciziei medicale bazate pe
informaii corelate din surse diferite. Aceasta crete nivelul de satisfacie al
beneficiarilor serviciilor medicale care este un indicator important pentru proiect.
Oferirea suportului decizional pentru adoptarea politicilor de sntate n Romnia.
Implementarea proiectului DES va avea urmtoarele consecine:
creterea interoperabilitii ntre furnizorii de servicii de sntate prin implementarea
unor interfee i protocoale de comunicaii standardizate n componena central a
sistemului DES
creterea eficienei serviciilor medicale oferite asigurailor prin accesul rapid la
istoricul informaiilor medicale
3.2. Obiectivul specific al proiectului

CNAS dorete s achizitioneze, sa implementeze si sa integreze in sistemul SIUI o soluie

care s ofere toate funcionalitile necesare introducerii Dosarului Electronic de Sntate al
pacientului. Soluia va rspunde integral la toate cerinele CNAS tehnice i funcionale,
exprimate n prezentul caiet de sarcini.
Obiectivul specific al sistemului a fost definit pe baza direciilor strategice de mai sus i pe
baza cerinelor funcionale, operaionale i tehnologice. Obiectivul specific al proiectului
este:
Implementarea sistemului naional Dosarul Electronic de Sntate al pacientului (DES) ca
funcionalitate intrinsec a SIUI i livrarea lui la cheie. Implementarea sistemului naional
DES reprezint un pas important n sprijinirea mbuntirii deciziei medicale i adoptarea de
politici de sntate bazate pe informaii coerente.
DES se va constitui ntr-o colecie de nregistrri electronice cumulate din diverse surse i
locaii, datele vizate pentru stocare urmnd a fi de tipul: istoric medical, alergii, imunizri,
rezultate la testele de laborator, documente produse n timpul procedurilor medicale, etc. care
se vor dovedi ca fiind relevante pentru decizia medical.
Dosarul electronic de sntate va documenta orice diagnostic sau msur terapeutic ntr-o
manier standardizat. Prin reducerea sau evitarea redundanei la nregistrarea datelor
medicale, DES va facilita prezentarea conceptelor medicale ntr-un mod optimizat, lipsit de
ambiguiti, cu pstrarea contextului original. Dosarul electronic de sntate va reflecta
cronologia evenimentelor medicale i va suporta vederi diferite ale datelor n funcie de
utilizator (medic sau asigurat).
Dosarul Electronic de Sntate va asigura:
o consolidarea datelor clinice ale pacientului, care acoper la nivel de pacient ntreaga
durat de via a acestuia;
o suport pentru livrarea exact, complet i la timp a informaiilor printr-un sistem
permanent online;
o asigurarea accesului privat i securizat la datele puse la dispoziie n DES prin intermediul
infrastructurii cardului de sntate;
o o soluie scalabil i extensibil ce va permite creterea continu, extensiv a
informaiilor clinice stocate
o interoperabilitatea cu alte sisteme folosind standarde deschise;
o utilizarea standardelor deschise n domeniul sntii, precum HL7.
Implementarea sistemului informatic propus va contribui la creterea eficienei serviciilor
publice oferite cetenilor, ceea ce se afla n concordan cu obiectivul Axei Prioritare 3
privind creterea interaciunii ntre sectorul public i ceteni prin valorificarea potenialului
TIC. Eficientizarea se manifest prin:
o obinerea unui mediu standardizat pentru evidena datelor, bazat pe sisteme performante
de gestiune a bazelor de date;
o grad mare de integrare a datelor medicale ntre diverse segmente ale sistemelor
informaionale din asistena medical;
o reducerea semnificativ a spaiului necesar stocrii datelor medicale;
o creterea calitii actului medical prin suportul informativ oferit structurilor
administrative locale i centrale;
o reducerea semnificativ a timpului de acces la informaii medicale, necesare n situaii de
urgen.
Accesul sigur la coninutul DES este asigurat prin politicile de securitate dezvoltate n scopul
de a mbunti sistemul actual, conform prevederilor legale relevante n vigoare i a
standardelor de securitate. Astfel, modelarea politicilor de securitate trebuie s respecte
prevederile Legii 677/2001 privind procesarea informaiilor cu caracter personal
(transpunere a Directivei Europene 95/46/C), Legii 455/2001 (cu modificrile ulterioare)
privind folosirea semnturii electronice, Legii Pacientului, Legea nr. 506 din 17 noiembrie
2004 privind prelucrarea datelor cu caracter personal i protecia vieii private n sectorul
comunicaiilor electronice, etc. n acest sens, separarea coninutului n funcie de dreptul de
proprietate, accesul controlat pe baza de drepturi al medicilor la fiele pacienilor, includerea
acordului pacientului, auditarea permanent a aciunilor sunt doar o parte din msurile ce
trebuie implementate pentru asigurarea unui sistem sigur i eficient.
Adresabilitatea DES la nivelul prestatorilor de servicii din Romnia, i nu numai, impune
implementarea unui nivel de comunicaii standardizat, care s permit actualizarea sau
vizualizarea datelor medicale referitoare la pacieni ntr-un mediu securizat. Consistena i
integritatea coninutului vor fi asigurate prin validarea tuturor mesajelor transmise n
interiorul sistemului, dar i cele venite de la aplicaiile existente n conformitate cu
standardele internaionale. Astfel, DES susine mediul concurenial din domeniul IT specific
serviciilor medicale, avnd ca beneficiu central mbuntirea serviciilor n domeniu.
3.3. Rezultate preconizate

Activitate Rezultate
1 Implementare DES Sistem DES implementat i funcional
1.2 Analiz Cerinele sistemului sunt definite
1.3 Proiectare Sistemul DES proiectat
1.4 Implementare Sistemul DES implementat
84 persoane instruite n utilizarea i
1.5 Instruirea personalului administrarea sistemului DES
Sistemul DES este testat cu succes
1.6 Testare conform planului de testare
 3.4. Indicatori

INDICATORI Valoare la nceputul Valoare la sfritul

perioadei de perioadei
implementare de implementare
Realizare
Ponderea instituiilor sanitare n 0 100%
care s-a implementat proiectul
din totalul acestora
Nr. de servicii electronice 0 1
disponibile
Rezultat
Nr. de persoane instruite pentru 0 84
folosirea aplicaiei informatice
Numrul estimat de utilizatori ai 0 2500
proiectului, angajai n domeniul
sanitar
Numrul estimat de instituii 0 50
sanitare conectate la sistemul
DES
Numr estimat de dosare 0 5000
medicale introduse n sistemul
DES

Meniuni:
Prin ponderea instituiilor sanitare = 100% nelegem implementarea proiectului la
solicitantul CNAS
Prin numrul de servicii electronice disponibile nelegem implementarea serviciului
DES (Dosarul Electronic de Sntate)
Prin numrul estimat de utilizatori ai proiectului, angajai n domeniul sanitar
nelegem numrul celor care vor utiliza facilitile sistemului dup implementarea
soluiei tehnice.
 3.5. Impactul economic i social al proiectului

Impactul economic i social al proiectului propus se va face simit n urmtoarele aspecte:

1. Creterea calitii sistemului de sntate din Romnia prin implementarea Dosarul
Electronic de Sntate al pacientului (DES)
2. Odat cu implementarea tuturor fazelor sistemului, va crete gradul de informare al
instituiilor interesate n definirea politicilor de sntate i n ceea ce privete situaia
n timp real a strii de sntate a populaiei Romniei. Avnd o vedere de ansamblu
asupra strii de sntate a populaiei, se vor putea combate, prin intermediul politicilor
de sntate, epidemii/pandemii sau alte maladii care influeneaz un numr mare de
ceteni;
3. Eliminarea erorilor de diagnosticare i a dublei consultaii ceea ce va conduce la
reducerea costurilor din sistemul sanitar naional;
4. Facilitarea schimbului de informaii n sistemul medical va duce la optimizarea
actului medical n sine i a costului asociat;
5. Creterea interoperabilitii ntre furnizorii de servicii de sntate, n calitate de punct
central i intermediator a schimbului de informaii medicale.
Numrul de poteniali beneficiari ai sistemului este dat de numrul total de persoane
beneficiare ale pachetelor de servicii nscrise pe listele medicilor de familie din sistemul de
sntate din Romnia, care erau la 30.06.2010 n numr de aproximativ 20.455.000. Dup
implementarea Dosarului Electronic de Sntate nou nscuii vor putea beneficia de dosarul
electronic de sntate ce va monitoriza starea de sntate pe parcursul ntregii viei.
Pe lng beneficiarii persoane fizice, de acest sistem vor beneficia cadrele medicale care vor
avea o baz de date complet asupra istoricului medical al pacienilor consultai i vor putea
s evite erorile de diagnostic sau repetarea unor analize. De asemenea acetia vor avea
posibilitatea de a lua decizii medicale n cunotin de cauz, avnd o vedere de ansamblu a
tabloului clinic al bolnavului derulat pe mai muli ani.
3.6. Beneficiile proiectului

n implementarea proiectului DES se vor asigura cel puin urmtoarele beneficii:

Va asigura accesul mbuntit la servicii, ntr-un mod securizat:
o Furnizarea de acces n timp util a datelor medicale relevante indiferent de locul
unde acestea au fost achiziionate i / sau transcrise n mod securizat, pe diverse
niveluri de acces
 o Posibilitatea consultului interdisciplinar la nivelul instituiilor
o Localizarea n sistemele locale unde se gsesc datele medicale complete (date
clinice, investigaii complexe, etc)
o Asigurarea accesului la istoricului medical al pacientului pe diverse niveluri de
acces
o mbuntirea continuitii asistenei medicale prin cunoaterea istoricului
pacientului
o Colaborarea i consultarea datelor clinice n timp real
o Urmrirea activitii medicale a pacientului, respectarea tratamentelor prescrise i
progresul din punct de vedere al sntii acestuia
o Limiteaz accesul la datele medicale n conformitate cu identitatea, funcia (rolul),
timpul i locul de munc a prestatorilor de servicii de sntate
o Acces facil la dosarul de sntate al pacientului, un control mai bun asupra
informaiilor i o actualizare rapid a informaiilor despre pacient
mbuntirea productivitii i asigurarea unui control mai exact al costurilor:
o Reducerea momentelor de ateptare pentru pacieni i de transferare a acestuia
ntre unitile de sntate
o Reducerea numrului de reexaminri, ale unui pacient, care nu sunt necesare
mbuntirea calitii Serviciilor de Sntate:
o mbuntirea calitii informaiilor de sntate (acuratee, completitudine,
consisten, reducerea erorilor de transcriere)
o Reducerea expunerilor la radiaii a pacienilor
o Reducerea erorilor medicale
o ntr-o etap ulterioar identificarea pacienilor cu nevoi speciale de ngrijire
(imunizri, tratamente, teste)
Din punct de vedere al beneficiarilor noului sistem, acesta va aduce, prin urmare, beneficii
importante dup cum urmeaz:
Pentru populaie, sistemul simplific modalitatea de accesare a serviciilor de asisten
medical, deoarece atunci cnd o persoan va merge la un furnizor de asisten medical,
acesta va avea acces securizat la Dosarul Electronic de Sntate al pacientului, n funcie de
nivelul curent de autorizare n care va putea realiza verificri online. Gama mai larga de date
medicale va crete calitatea serviciilor de sntate i va reduce posibilitatea de greeli
administrative i profesionale. Unul din rezultatele ateptate este i o preocupare mai mare a
persoanelor asigurate pentru sntatea lor proprie i o mai bun cunoatere cu privire la
procedurile lor de tratament medical propriu prin intermediul portalului pus la dispoziia
asigurailor.
Pentru furnizorii de servicii medicale, sistemul aduce o modalitate de comunicare ntre
angajaii instituiilor prestatoare de asisten medical (consult interdisciplinar), acetia
beneficiind de istoricul informaiilor medicale ale pacientului i de propunere mult mai
eficient a unor activiti de asisten (la momentul integrrii acestora n sistemul DES)
Pentru CNAS sistemul reprezint un instrument de luare a deciziilor cu impact n sistemul
medical, ofer o baz de date statistice la zi i n continu cretere i asigur sursa de date
pentru rapoartele anuale realizate de ctre CNAS.
mbuntirea serviciilor medicale din perspectiva pacienilor
mbuntirea serviciilor medicale din perspectiva pacienilor va fi realizat prin urmtoarele
caracteristici principale ale sistemului DES:
DES va fi o surs sigur de informaii on-line pentru prestatorii de servicii medicale, ce se
concentreaz asupra pacientului i este disponibil la locul unde se efectueaz
tratamentul;
DES va gestiona fluxul informaional de interaciune ntre prestatorii de servicii medicale,
prin generarea documentelor specifice trimiterilor sau externrilor. n acest mod, fiele
medicale electronice vor fi automat actualizate, evitndu-se deplasrile pacientului;
DES accelereaz fluxul informaional n beneficiul pacienilor, spre exemplu trimiterea
imediat a solicitrilor de tratament, evitndu-se astfel ntreruperi sau ntrzieri n
procesul de tratare.
mbuntirea serviciilor medicale din perspectiva prestatorilor de servicii medicale (PSM)
mbuntirea serviciilor medicale din perspectiva prestatorilor de servicii medicale va fi
realizata prin urmtoarele caracteristici principale ale sistemului DES:
DES va asigura interoperabilitatea informaiilor dintre mai muli prestatori de servicii,
att la nivel naional ct i la nivel internaional;
DES va permite online accesul medicilor la coninutul episoadelor anterioare de ngrijire.
mbuntirea serviciilor medicale din perspectiva susintorilor sistemului de servicii
medicale din Romnia (CNAS, MS)
DES va avea suport pentru introducerea informaiilor;
DES va asigura accesibilitatea i disponibilitatea informaiilor pacienilor;
DES va duce la reducerea timpului petrecut cu activiti administrative.
4. Modele de evoluie a sistemului medical

4.1. Definiii i concepte

Terminologia asociat unui sistem de gestionare a datelor de sntate ale pacienilor are mai
multe variante n funcie de locul n care aceste date sunt obinute, la nivelul medicului de
familie, spitale, laboratoare, uniti specializate, etc.
Pentru a realiza o nelegere clar a conceptului de eSntate n Romnia, i a tipului de
sistem informatic de gestionare a nregistrrilor de sntate, a arhitecturii acestuia ct i a
modalitii de implementare, vom defini i diferenia aceste tipuri de sisteme.
Tipurile de sisteme pentru gestiunea informaiilor medicale ale pacienilor sunt:
o EMR (Electronic Medical Record) fia electronic medical a pacientului existent la
un medic; organizate la nivelul unui singur furnizor de servicii
o EPR (Electronic Patient Record) fia electronic a pacientului existent la un spital sau
unitate specializat; organizate la nivelul unui spital/unitate specializat conine toate
datele existente la nivelul departamentelor spitalului/unitii specializate (la un anumit
moment nu la momentul externrii)
o EHR (Electronic Health Record) - Dosarul Electronic de Sntate - conine datele
medicale relevante colectate la nivel longitudinal corespunztoare unei persoane care
constau din date colectate din mai multe EMR-uri i EPR-uri; date organizate/concentrate
la nivelul pacientului
o HIS Health Information System sistem informatic de eviden a informaiilor
medicale, i poate include informaii stocate n sisteme de genul EMR/EPR ct i alte
tipuri de informaii specifice fiecrei uniti sanitare
Sistem de tip EHR
Sistemul de tip EHR este un set de componente care asigur instrumente prin intermediul
crora datele electronice medicale sunt create, utilizate i nmagazinate. Include persoane,
date, reguli, proceduri, echipamente de procesare i stocare, comunicare i suport. Altfel spus,
un sistem de nregistrare, regsire i manipulare a informaiilor coninute n dosarele
medicale.
EHR-urile conin nregistrri clinice computerizate create n unitile care livreaz servicii de
ngrijire, cum ar fi spitalele i cabinetele medicilor de familie. EHR-urile au capacitatea de a
partaja cu uurin informaii medicale ntre prile interesate i trebuie sa permit informaiei
s urmeze pacientul la diverse uniti de asisten medical la care acesta dorete s mearg.
Prile interesate n acest context sunt consumatorii, furnizorii de servicii medicale,
angajatorii, contribuabilii dar i guvernul i alte instituii ale statului.
Scopul principal al unui EHR este acela de a furniza nregistrri medicale documentate care
s asigure suportul pentru ngrijirea curent i viitoare a pacientului de ctre acelai medic
sau ali medici. Aceast documentare asigur o modalitate de comunicare ntre medicii care
particip la procesul de ngrijire a unui pacient. Principalii beneficiarii sunt pacienii i
medicii.
Tipurile de sisteme EHR
Sistem EHR local
Majoritatea activitilor de ngrijire medical sunt furnizate n cadrul comunitii locale n
care locuiesc pacienii. Aceste activiti includ serviciile asigurate de Medicul de Familie
mpreun cu o serie de alte servicii medicale asigurate de furnizori locali de asisten
medical (medici specialiti , profesionitii din domeniul sntii , etc.) i servicii de
asisten medical complex, cum ar fi serviciile de diagnostic, tratament acut i internare
spital.
n majoritatea unitilor de sntate, medicii de familie i furnizorii de servicii i asisten
medical pstreaz i menin propriile nregistrri/fie medicale ale pacienilor, ntr-un format
manual, electronic sau o combinaie ntre acestea. O caracteristic important a acestor
nregistrri medicale este c acestea conin informaii detaliate referitoare la pacient, colectate
pe parcursul vizitelor pacientului la furnizorul de servicii medicale.
De obicei acestea conin i materiale provenite din exterior, cum ar fi rezultatele de diagnostic
i recomandri , dar accesul la informaii n sistemul local - EHR este de obicei limitat la
cadrele medicale autorizate n unitatea medical respectiv.
Arhitectura sistemelor EHR Local poate fi foarte variabil pentru a putea rspunde i
cerinelor altor discipline sau sectoare din domeniul sntii. De exemplu sistemul EHR
Local al unui Medic de Familie va fi diferit ce cel existent ntr-un spital mare.
Scopul principal al unui sistem EHR Local este de a gestiona informaia medical referitoare
la pacient n cadrul spitalului, clinicii sau alte uniti medicale sau de sntate. Un EHR Local
poate suporta un EHR partajat SEHR.
Sistem EHR partajat - SEHR
Scopul unui sistem EHR partajat (SEHR) este de a asigura integrarea informaiilor de
sntate intr-o comunitate local de ngrijire, permiterea transmiterii i primirii
informaiilor extrase i fluxuri integrate.
Comunitatea local de ngrijire va fi constituit de regul ntr-o regiune geografic restrns
de regul la 10-20km distan de reedina pacientului. Aceast comunitate va include de
regul una sau mai multe clinici de ngrijire primar, clinici de specialitate (de exemplu,
endocrinolog i specialist oftalmolog pentru revizuirea periodic cu diabet zaharat, clinic de
planificare familial, etc) , spitale, laboratoare, etc.
n pofida faptului c cei mai muli oameni i vor satisface majoritatea nevoile lor de asisten
medical n cadrul comunitii locale de ngrijire, sistemele SEHR au utilitate dincolo de
comunitile locale, la nivel regional (de exemplu, jude, regiune) sau chiar la nivel naional .
Pentru sistemele EHR Partajabile SEHR, exist dou modele principale care pot fi propuse:
o Modelul SEHR Federalizat n care informaia sistemului EHR Partajabil este construit n
timp real. Acest lucru poate fi considerat ca un EHR "virtual" i pot consta n vederea
logic sau agregarea fizic a informaiilor extrase din sistemele EHR "n timp real" de la
dou sau mai multe surse de EHR distribuite. Abordarea de tip federalizat este atrgtoare
n teorie, dar are, n practic, mai multe dificulti de performan, n special pentru
sistemele mari, cu multe nregistrri i multe surse federalizate EHR (noduri EHR), i de
fiabilitate (dac un EHR local nu este disponibil nu se pot agrega informaiile, avnd n
vedere c datele medicale trebuie s fie corecte i complete). Sistemele de succes
federalizate se bazeaz pe o serie de factori cum ar fi interogri eficiente distribuite,
laten sczut, i modele compatibile de securitate i care sunt la fel de bune ca cea mai
slab verig din lan.
o Modelul SEHR Consolidat datele din sistemele locale sunt puse mpreun atunci cnd
informaia este creat i actualizat, i nu atunci cnd aceasta este solicitat. Contribuiile
la SEHR sunt introduse de la sistemele Locale sau prin introducerea direct n sistemul
SEHR, aproape de momentul evenimentului de asisten medical. Modelul consolidat
prezint i el unele dificulti tehnice proprii, dar exist unele avantaje importante care
includ: sistemul de control al accesului i de securitate este mult mai simplu n comparaie
cu sistemele federalizate, probabilitatea unui raport mult mai bun pre/performan,
fiabilitate crescut i posibilitatea de a se integra mai uor cu alte sisteme medicale
existente sau de viitor. Modelul consolidat de SEHR poate conine doar un subset al
tuturor informaiilor medicale. Acest subset este definit n funcie de informaiile
medicale colectabile, transmisibile, i relevante din punct de vedere al actului medical.
 4.2. Organizarea sistemului Dosarul Electronic de Sntate al
pacientului (DES)

Pentru implementarea unui proiect de o asemenea anvergura i complexitate dar i innd

cont de numrul mare de sisteme cu care va trebui sa se integreze, urmtoarea etapizare
trebuie considerata pentru implementarea DES:
Etapa I procedura curenta de achizitie
o Stabilirea clara a tuturor informaiilor ce se vor pstra n DES i care alctuiesc Date
Medicale Relevante (DMR). Pentru aceasta se va constitui o comisie (cu participani din
toate sectoarele domeniului de sntate).
o Definirea standardelor de comunicare intre sistemele locale i sistemul central DES
innd cont de securitate, performanta, fiabilitate, auditare, etc.
o Stabilirea funcionalitilor prezente n proiect i modul de integrare cu alte sisteme sau
subsisteme adiacente proiectului DES, precum i a sistemului de autentificare PKI (in
conjuncie cu cardul de sntate)
o Dezvoltarea/testarea proiectului. Vor fi dezvoltate componentele identificate pentru a fi
realizate i vor fi executate testele, n conformitate cu o metodologie standard.
o Implementarea proiectului mpreuna cu spitalele majore din Romania.
o Implementarea unei aplicatii client pentru medici de familie ce va permite modelarea mai
bine a actului medical
o Implementarea sistemului de certificare n vederea integrrii cu alte sisteme din teritoriu
o Punerea n producie a sistemului, prin integrarea cu spitalele majore din Romnia i prin
utilizarea portalului
Motivarea deciziei s-a facut pe baza urmatoarelor criterii:
o Spitalele mari:
o Detin baze medicale de date relevante
o Detin ponderea pacientilor
o Interactioneaza direct cu pacientul
o Achizitioneaza date personale de baza
o Constituie fisa bolnavului
o Ajuta la managementul profilului pacientului
o Detin tehnologie
o Detin infrastructura
 o Detin informatii specializate
o Au posibilitatea inmagazinarii si stocarii datelor
Medici de familie:
o Achizitioneaza date personale de baza
o Constituie fisa bolnavului
o Ajuta la managementul profilului pacientului
Datorit organizrii administrative i teritoriale a rii noastre pe judee, a numrului i tipului
unitilor de asisten medical, ct i a nivelului de informatizare existent n acest moment n
domeniul sntii, modelul de EHR care se preteaz cel mai bine este de tip EHR Partajat
(Shared EHR - SEHR) consolidat. Acest sistem va conine un subset a informaiilor medicale,
numit: Date Medicale Relevante (DMR) i va asigura accesul factorilor implicai din
domeniul sntii prin:
intermediul unui Portal web integrat cu sistemul SIUI
specificaii de integrare, pentru schimbul automat de informaii ntre DES i HIS-urile locale.
aplicaie client pentru medicul de familie
Ca structur i mod de organizare funcional sistemul va conine urmtoarele componente:
o Reeaua de comunicaii securizat asigurat de STS pentru sistemul SIUI
o Infrastructura de securitate care se va implementa n SIUI (componenta eCard) va consta
n smartcard-uri i o soluie de tip PKI. Sistemul DES va verifica identitatea asiguratului
prin intermediul SIUI (componenta eCard), astfel nct identitatea unui utilizator sa fie
recunoscut n mod unic n cadrul sistemului SIUI.
o O component de tip SEHR centralizat care va consolida date de sntate i medicale
relevante pentru asigurati (datele DMR)
o O component web based (Portal) prin care asiguratii au access direct la datele lor
medicale relevante
o O aplicaie client pentru medicii de familie, integrat cu SIUI
o O component de interoperabilitate i integrare care va asigura transferul n mod securizat
al datelor de sntate despre pacieni ntre SEHR i sistemele EMR/EPR/EHR existente la
prestatorii de servicii de sntate
o Un sistem de suport al deciziilor pentru CNAS. Acest subsistem va colecta i stoca
informaii pe perioade mai lungi de timp necesare pentru elaborarea unor rapoarte i
analize statistice complexe, care vor conduce la stabilirea politicilor medicale de sntate
n sistemul medical romnesc
o Infrastructura hardware, software si de comunicatii necesara
Realizarea DES ca un sistem separat de sistemele de tip HIS din cadrul unitilor de sntate
i respectnd contextul impus de ctre SIUI, este o aplicare a principiului separrii
responsabilitilor i permite o arhitectur flexibil i fiabil, bazat pe modularizare i
cuplare slab ntre componentele sistemului informatic integrat. Prin cuplare slab ntre
componente nelegem c EHR/EPR/EMR aflate n teritoriu sunt independente ntre ele din
punct de vedere arhitectur tehnic, funcionaliti, mod de implementare, utilizare i
management, dar cu toate acestea comunic prin protocoale standard ntre ele ct i cu
sistemul DES, astfel nct transferul de informaie s se fac eficient, complet i securizat.

Se are in vedere extinderea ulterioara a DES cu noi functionalitati. Sistemul DES, la

finalizarea etapei I, trebuie sa permita extinderea la:
o Spitale sub 500 de paturi, spitale specializate, etc
o Policlinici
o Sisteme ambulatorii
o Laboratoare
o Centre medicale
o Faculti de medicin
o Centre de imagistic
5. Descrierea tehnic a proiectului

O caracteristic principal a noilor sisteme informatice de sntate o constituie

implementarea unui dosar electronic de sntate al pacientului (DES) care colecteaz n
format digital datele medicale relevante legate de sntatea unui pacient precum i
modalitile de tratament alese.
Un sistem informatic (SI) DES are ca scop:
o s furnizeze suportul necesar sistemului decizional de management n sntate;
o sa asigure accesul online la datele relevante privind sntatea unui pacient, aflat n
procesul de tratament;
o s contribuie proactiv la stabilirea politicilor teritoriale de sntate.
La nivel global exist variaii importante legate de arhitectura unui sistem DES (gradul de
centralizare al sistemului, modelul informaional al dosarului, modul de utilizare a datelor,
etc).
Pentru implementarea unui sistem de sntate corespunztor specificului din Romnia se vor
respecta urmtoarele linii directoare:
a. Sistemul DES face posibil un acces on-line sigur i de ncredere la informaiile
referitoare la sntatea pacienilor, acolo i atunci unde acestea sunt necesare
pentru tratament
b. DES va conine, ntr-o baz de date centralizat, date medicale relevante ale
pacientului. Aceste informaii sunt preluate din sistemele informatice
aparinnd instituiilor medicale, pe msura integrrii acestora n sistem.
Modul de achiziie a informaiilor este de dou feluri:
Informaiile sunt trimise n timp real de la instituiile medicale ctre
sistemul centralizat, n sistem push;
Informaiile sunt colectate de ctre sistemul DES de la instituiile
medicale, n sistem pull, la cerere.
c. Accesul personalului medical (i, mai general, al oricrui utilizator potenial)
la DES va fi pre-autorizat pe baza unui set de reguli stabilite, urmnd ca
sistemul s permit apoi schimbarea nivelului de acces de ctre pacient,
utiliznd proceduri specifice i putnd stabili, n principiu, situaiile i nivelul
pn la care medicii autorizai vor avea acces la dosarul fiecrui pacient;
 identificarea medicilor se va face prin intermediul sistemelor HIS prin care
acetia se conecteaz, pentru audit se vor stoca credenialele trimise de HIS
plus un identificator unic precum un cod de paraf
d. DES aplic msuri pentru protecia i sigurana datelor, indiferent de locul sau
timpul tratrii
e. Autentificarea utilizatorilor se va realiza, n mod optim, prin folosirea cardului
electronic de sntate implementat n componena eCard a SIUI. Cazurile de
utilizare a cardului i informaiile necesare care vor fi stocate n sistem se vor
stabili n cursul procesului de dezvoltare al DES;
f. Prin centralizarea de documente din diferite sisteme, DES face posibil o
perspectiv integrat asupra datelor i ofer acces securizat utilizatorilor,
innd cont de drepturile acestora n contextul fiei pacientului;
g. DES verific autenticitatea informaiilor prin semntur electronic i adaug
date referitoare la timp i surs;
h. DES face posibil o colectare eficient a datelor prin intermediul unor
persoane autorizate, prin diferite medii de introducere a datelor online
(tastatur i import folosind servicii web)
i. DES va fi conectat la registrele de boli cronice, acolo unde acestea exista i va
permite, pe baza unei interfee informatice standard conectarea la registrele
care se vor implementa n viitor.

5.1. Arhitectura funcional a sistemului

Sistemul DES este un instrument pentru sprijinirea unei ngrijiri medicale integrate. Pentru a
se asigura continuitatea n lanul ngrijirii medicale, trebuie ca datele i informaiile privind
sntatea pacientului sa fie puse la dispoziie chiar la locul tratrii. DES nu este un dosar sau
un document n sensul tradiional, ci un sistem de documentare, informare i comunicare
bazat pe o infrastructura IT sigur pe de o parte i pe standarde tehnice i de coninut pe de
alt parte.
Sistemul DES va folosi categorii de date existente n SIUI (nomenclatoare, asigurai, registre
de servicii medicale i farmaceutice, etc.). Accesul la aceste date se va face programatic.
Actori:
o Asigurat. Cetenii nregistrai n sistemul de asigurare medical.
o Medic. Medic nregistrat n SIUI. Exista doua posibilitati: medic de familie si
medic in cadrul spitalului
o Analist. Personal CNAS ce extrage informaii statistice si le pune la dispozitia
organismelor competente pentru interpretare medicala
o Auditor. Personal specializat n verificarea i corectarea fluxurilor de date
medicale
o Administrator. Personal specializat n administrarea sistemului SIUI / DES
Canale de acces:
o DES Asigurat (Dosar Personal de Sntate). Sistem informatic de tip Portal prin
care un asigurat i consulta informaiile medicale proprii sau pentru care este
delegat.
o DES medic de familie. Sistem informatic prin care un medic de familie acceseaz
informaiile medicale ale unui asigurat.
 o Tablou de bord. Sistem informatic prin care un analist proceseaz date
nepersonale n vederea stabilirii politicilor de sntate.
o Audit. Sistem informatic de monitorizare i auditare a ntregului sistem pentru a
verifica accesul la datele medicale.
o Administrare. Interfa utilizator adaptat pentru administratorii de sistem
o HIS. Sistem informatic de gestiune a unui spital.
Servicii aplicative:
o Servicii DMR. Stocheaz i proceseaz datele medicale relevante.
o Servicii de analiz, raportare i statistici. Sistem informatic de analiz a datelor n
vederea stabilirii politicilor de sntate.
Servicii de date:
o Servicii vocabulare
o Servicii entiti
o Servicii documente
o Servicii depozit de date
o Servicii audit
Surse de date (generatoare de DMR):
o Spitale
o Medici de familie
Servicii de integrare i transformare:
o Servicii flux de lucru
o Servicii de comunicare ntre aplicaii
o Servicii de transformare date
o Servicii de tip registru de servicii
Servicii suport:
o Servicii de securitate
o Servicii de administrare
o Servicii de infrastructur
Magistral servicii

5.1.1. Subsisteme funcionale

 1.1.1.1. Subsistemul de acces utilizatori

Subsistemul de acces al utilizatorilor la funcionalitile DES include un Portal, precum i

mecanismele de control al accesului prin acest portal.
Portalul
o Portalul DES asigurat - este o aplicaie web based prin care un asigurat poate vizualiza
informaiile:
Informaii medicale proprii (DMR-uri)
Informaii medicale pentru care este delegat (persoane aflate n grija sa)
Informaii de audit asupra datelor sale medicale (cine a accesat, ce a accesat i cnd)
o Portalul permite accesarea unor domenii informaionale de detaliu aflate n DES (drill
down), plecnd de la sumar.
o Portalul include vederi diferite, n funcie de tipul utilizatorului, n particular vederi
distincte i optimizate pentru medici i asigurai.
o Portalul ofer faciliti separate pentru alte categorii speciale de utilizatori (Analiti,
Auditori, etc)
o Portalul ofer faciliti de administrare a utilizrii datelor medicale de ctre utilizatorii
autorizai.

1.1.1.2. Interfaa utilizator (web portal)

o Interfaa utilizator trebuie sa fie web based. Interfaa este accesibila direct dintr-un
browser WEB; interfaa trebuie sa adreseze minim Internet Explorer i Mozilla Firefox.
o Interfaa trebuie sa ofere suport pentru limba romana. In mod specific toata informaia-
text trebuie sa fie codata UNICODE (preferabil UTF-8).
o Interfaa cu utilizatorul trebuie sa permit traducerea ei n alte limbi fr ca pentru acest
lucru sa fie necesara modificarea aplicaiei.
o Accesul la modulele aplicaiei trebuie sa prevad accesul bazat pe roluri a utilizatorilor
aplicaiei.
o Sistemul trebuie sa conin un modul help on-line care sa afieze informaie n funcie de
contextul curent n care se afla utilizatorul.
o In cazul n care pentru realizarea unei funcii este necesara parcurgerea a mai multor
pagini utilizatorul trebuie sa poat accesa direct o funcie de rentoarcere la pasul anterior.
Sistemul nu trebuie sa necesite re-introducerea unei informaii care a fost deja introdusa
la un pas anterior, exceptnd informaiile de securizare a tranzaciei si/sau procesului


1.1.1.3. Servicii Aplicative

Serviciile DES de tip aplicaie sunt serviciile principale pe care trebuie s le ofere sistemul
din punct de vedere funcional.
Serviciile aplicative trebuie s fie de tip cuplaj slab, pentru a permite extinderea
funcionalitilor ntr-o manier scalabil, folosind tehnologii de tip servicii web. Aceast
cerin este cu att mai important cu ct se preconizeaz o dezvoltare iterativ, cu adugarea
de noi funcionaliti n faze ulterioare de dezvoltare a sistemului DES.

1.1.1.4. Serviciile DMR

Serviciile de tip DMR asigur gestiunea informaiei de sntate eseniale, asociate unui
asigurat.
a) Cerine funcionale
ID Cerin Descriere
1 Coninut minim Informaia gestionat va include, ca un minimum,
urmtoarele categorii:
o starea de sntate a pacientului (ex. probleme
cunoscute, diagnostice, medicamentaie, alergii,
etc) evenimente (de sntate sau semnificative)
(trimiteri, internri / externri, consultaii, etc)
o aspecte / documente conexe (familie, aspecte
sociale, etc)
Detalii coninut minim DMR va permite accesul utilizatorului, pe baza
drepturilor asociate la urmtoarele funcionaliti
minimale:
Cutare asigurat
Stocarea i vizualizarea datelor medicale
sumare
Stocarea, vizualizarea i completarea listei
de probleme medicale
Stocarea, editarea (inclusiv modificarea,
tergerea i golirea), vizualizarea listei
de alergii
ID Cerin Descriere
Stocarea, vizualizarea i completarea listei
de consultaii medicale
Monitorizarea strii de sntate a
asiguratului pe baz de indicatori
predefinii, alerte, etc
Stocarea, editarea i vizualizarea datelor
istorice de familie i sociale ale
asiguratului
Stocarea, vizualizarea i completarea listei
de trimiteri
Stocarea i vizualizarea cererilor de analiz
i rezultatelor documentate
Stocarea, editarea i vizualizarea
medicamentaiei prescrise asiguratului
Verificarea medicamentaiei prescrise fa
de profilul pacientului i emiterea
automat de alerte

3 Identificator unic DMR va utiliza un identificator unic al asiguratului

4 Model de date DMR va suporta un model de date suficient s
acopere necesitile de schimb de date cu toate
entitile cu care comunic n sistem, precizate de
componenta de Schimb de Informaii
5 Extensibilitate DMR va fi uor extensibil pentru a permite
adugarea de noi categorii / tipuri de informaii
medicale, fr a implica modificri substaniale n
aplicaie

6 Asociere medic DMR va permite definirea i gestionarea unei

relaii, pe toat durata ei de via, ntre un asigurat
i personalul medical asociat acestuia
7 Relaii cu alte date DMR va permite identificarea de relaii cu alte date
relevante aparinnd de exemplu rudelor unui
pacient existente n sistem
8 Alerte DMR va permite generarea i rutarea de alerte ctre
ID Cerin Descriere
utilizatorii interesai, ca urmare a producerii unor
evenimente
b) Cerine tehnice
ID Cerin Descriere
1 Tratare erori DMR va trebui s gestioneze situaiile de eroare
(ex. primirea unei cereri cu identificator asigurat
eronat)
2 Corectare erori DMR nu va permite corectarea unor informaii de
ctre o surs diferit de cea care a furnizat
informaia original
3 Modificare informaii Modificrile de informaie se vor face printr-un
mecanism de versionare (i nu prin suprascriere)
care va fi compatibil cu subsistemul de audit

4 Home page La accesarea sistemului utilizatorul va fi logat

ntr-o pagin personalizat tip home page. Fiecare
utilizator va putea selecta categoriile de informatii
ce vor fi afisate implicit la accesarea sistemului.

c) Principiul DMR
Este necesar stabilirea clara a informaiilor ce se vor pstra n DES i care alctuiesc
setul de Date Medicale Relevante (DMR).
Pentru aceasta se va constitui o comisie de specialitate, cu participani din toate sectoarele
domeniului de sntate.
Ofertantul va asista beneficiarul n definitivarea setului DMR, pe baza setului propus de
ctre beneficiar. Se vor identifica i analiza posibile constrngeri sau optimizri de natur
tehnic sau legate de implementarea proiectului.
 1.1.1.5. Serviciile BI

Serviciul de BI (Business Intelligence) permite analiza i afiarea ntr-o form relevant a

unor situaii de interes pentru diferite categorii de utilizatori, de exemplu de tip tablou de
bord, scorecard, etc.
Serviciile vor trebui sa permita generarea diversilor indicatori de sanatate, indicatori necesari
pentru stabilirea politicilor nationale sau regionale de sanatate:
Mortalitate per diagnostic, varsta, zona geografica etc. Ca si cazuri particulare trebuie
sa se evidentieze de exemplu:
o Mortalitate infantila
o Mortalitate perinatala
Morbiditate per diagnostic, varsta, zona geografica, perioada calendaristica, etc. Ca si
cazuri particulare ale acesui indicator trebuie sa se poata evidentia cel putin:
o Procentul si durata de supravietuire pentru boli ca si cancerul, tuberculoza,
SIDA, etc.
o Situatia bolilor infectioase pe zona, perioada calendaristica
Maternitatea pe grupe de varsta
Speranta de viata pe zona geografica, mediu urban/rural, mediu occupational, etc.
Date privind insuficienta ponderala la nastere
Durata medie de spitalizare per diagnostic
Numarul de accidente pe categorii
o Accidente la locul de munca
o Accidente rutiere
o Etc.
Numarul de proceduri medicale efectuate, pe categorii, pe diagnostic, zona
geografica, etc. Ca si cazuri particularear trebui sa se poata evidentia:
o Numarul de proceduri chirurgicale
o Numarul de investigatii de inalta performanta (RMN, Tomografie)
Medicatia administrata per diagnostic, grupa de varsta, zona geografica, etc.

Pe baza datelor din care s-au generat acesti indicatori trebuie ca sistemul sa poata face analize
de tip data-mining, realizand estimari, trenduri, scenarii what-if etc.
a) Cerine funcionale
ID Cerin
1 Analiz informaii complexe
2 Analiz tendine
3 Rapoarte ad-hoc
4 Drill-down
5 Format grafic
6 Format ieire
a) Cerine tehnice
ID Cerin
1 Depersonalizare
(anonimizare)
2 Calitatea datelor
Descriere
Serviciul de BI trebuie s permit comunicarea
unei informaii medicale complexe, prin
intermediul unor tablouri de bord uor de
construit, precum i construirea unor fie de
punctaj (scorecards) pentru alinierea echipelor
medicale i a tacticii adoptate cu nivelul strategic
Serviciul de BI va furniza instrumente pentru
analiza tendinelor i msurarea rezultatelor
Serviciul de BI va permite realizarea de rapoarte
ad-hoc referitoare la datele stocate n DES
Serviciul de BI va oferi faciliti de tip drill-down,
respectiv navigarea facil ntre diferite niveluri de
detaliu, n funcie de necesitile specifice
Serviciul de BI va permite obinerea de situaii
statistice, n diferite formate grafice/numerice,
agregate la diferite niveluri organizaionale sau
geografice
Serviciul de BI va permite obinerea rapoartelor
ntr-o gam variat de formate de ieire, pentru a
putea fi exploatate de ctre sistemele conexe DES
sau exportate ctre alte sisteme naionale i
internaionale (UE)
Descriere
Serviciul de BI va permite depersonalizarea
(anonimizarea datelor) prin extragerea lor din baza
de date central ntr-o baz de date analitic care
va fi exploatat de ctre instrumentele de analiz
i raportare BI
Serviciul de BI va accesa o component de tip
ETL (intern / extern) care s permit asigurarea
unei caliti corespunztoare a datelor, nainte de
ID Cerin Descriere
exploatarea lor de ctre instrumentele BI

1.1.1.6. Arhitectura de Date

Arhitectura de date va detalia n mod obligatoriu, ca un strat unitar:

1. Serviciile de date
2. Modelul de date

1.1.1.6.1. Serviciile de Date

Serviciile de date includ serviciile care expun coninutul de date al sistemului serviciilor
aplicative precum i altor servicii care exploateaz structurile de date medicale.
Este de notat c serviciile de date sunt decuplate de modelul de date i pot exploata datele
relevante, indiferent de subsistemul SIUI din care acestea provin.
Pe de o parte serviciile de date DES vor exploata la maximum structurile de date deja
existente n sistemul SIUI.
Pe de alt parte trebuie avut n vedere c este necesar ca serviciile de date s ofere
funcionalitile sistematizate n aceast seciune, independent de subsistemul n care se afl
localizate efectiv datele (decuplare logic).
Serviciile de date principale sunt urmtoarele:
serviciul de vocabulare;
serviciul de entiti;
serviciul de documente;
serviciul de depozit de date (data warehouse).

1.1.1.6.1.1. Serviciul de Vocabulare

a) Cerine funcionale
ID Cerin Descriere
1 Interfa pentru Serviciul trebuie s joace rolul de interfa SOA
nomenclatoarele SIUI de pentru nomenclatoarele SIUI care furnizeaz
termeni concepte specifice domeniului (ex: nomenclatoare
pentru medicamente).
2 Acces la vocabulare Clientul serviciului trebuie s poat indica un
standardizate concept specific printr-un identificator de concept
i s acceseze informaiile asociate acestuia.
3 Regsire de termeni specifici Clientul serviciului trebuie s poat cuta termeni
ID Cerin Descriere
specifici n cadrul sistemelor de codificare
disponibile pe baza unor criterii.
4 Suport pentru diferite Clientul serviciului poate aduga sau terge
domenii clinice sisteme de codificare existente sau poate edita
informaia despre un anumit sistem de codificare.
5 Regsirea sistemului de Un sistem de codificare trebuie s includ termenii
codificare adecvat unei specifici unui anumit domeniu(concepte).
probleme Informaiile despre sistemul de codificare ajuta
clientul serviciului s identifice sistemul dorit,
prin punerea la dispoziie a descrierii, versiunii, a
limbilor suportate de sistemul de codificare, a
datelor de identificare a sistemul samd.
6 Flexibilitate n descrierea Clientul serviciului trebuie s poat stabili relaii
conceptual a domeniului ntre concepte, precum relaii ierarhice (ex:
Chirurgia este o Specializare medical, Astmul
este o Boal respiratorie etc).
Conceptele sunt caracterizate prin nume i printr-o
serie de atribute de tip proprieti. (De ex:
conceptul Algozone are proprietatea Firma
productoare cu valoarea Ozone)
7 Suport pentru terminologie Clientul serviciului poate aduga, actualiza sau
specific terge termeni n cadrul fiecrui vocabular.
Clientul serviciului poate obine detalii precum
numele sau proprietile conceptului pe baza unui
cod de concept
8 Validarea conceptelor ntr-un Clientul serviciului poate verifica dac un concept,
anumit context pe baza codului acestuia, aparine sau nu unui
sistem de codificare sau unui set de valori.
9 Gruparea seturilor de termeni Seturile de valori reprezint grupri logice de
adecvai unui context termeni dintr-un anumit sistem de codificare. De
ex, n sistemul de codificare ICD-10 (International
Classification of Diseases), se poate realiza un set
de valori care reunete doar bolile dermatologice.
10 Reutilizarea seturilor de Serviciul trebuie s permit compunerea de
termeni sisteme de valori prin agregarea altor sisteme
ID Cerin Descriere
11 Regsirea setului de valori Serviciul trebuie s ofere acces la informaii de
adecvat unei probleme identificare i descriere a unui set de valori
12 Asigur interoperabilitate n cadrul unui flux de lucru, conceptele medicale
ntre diferitelor sisteme de pot fi reprezentate prin diferite scheme de codare.
codificare. Pentru a asigura interoperabilitatea i pentru a
menine nelesul termenilor, utilizatorii trebuie s
defineasc mapri ntre concepte echivalente n
diferite scheme de codare.
13 Regsirea conceptului Un utilizator trebuie s poat regsi conceptul
adecvat unei probleme adecvat care trebuie utilizat ntr-o anumit
operaiune de codificare (Ex: codificarea unui
diagnostic).
b) Cerine tehnice
ID Cerin Descriere
1 Mesaje Serviciul trebuie s poat comunica cu actori
externi folosind mesaje standardizate n domeniul
su de activitate ex: HL7 sau echivalent
2 Concepte Sistemul trebuie s poat s opereze cu concepte
definite conform unui standard adoptat de
comunitatea dezvoltatorilor de software medical -
ex: HL7 sau echivalent

1.1.1.6.1.2. Serviciul de Entiti

a) Cerine funcionale
ID Cerin Descriere
1 Interfaa pentru entitile Serviciul trebuie s joace rolul de interfa SOA
existente n SIUI pentru entitile SIUI (ex: asigurai, medicii care au
contract cu CNAS cu specializrile medicale pentru
fiecare medic n parte, furnizori etc).
ID Cerin Descriere
2 Personalizarea tipurilor de Entitile stocate de serviciu trebuie s poat fi
resurse suportate de grupate dup anumite tipuri de exemplu: Persoan,
serviciu Locaie, etc
De asemenea entitile sistemului pot avea la un
moment dat diverse roluri ex: o persoan poate fi
asigurat, pacient, medic etc
Pentru un anumit tip de entitate trebuie s se poat
defini atributele pe care aceasta le suport. Ex: pentru
Persoan sex, data naterii, CNP, etc
3 Asigurarea funcionalitii Domeniile au rolul de a permite partajarea datelor
adecvate pentru diferite ntre diverse medii ex: operaional, testare,
sisteme consumatoare ale certificare etc
serviciului
4 Modificarea datelor despre Clientul serviciului trebuie s poat crea noi entiti
entiti de un anumit tip definit, s poat edita informaiile
asociate entitii i sau s poat terge entitatea
Clientul serviciului trebuie s poat introduce date
care descriu o entitate existent, pe baza atributelor
definite pentru acel tip de entitate
5 Regsirea datelor despre Clientul serviciului trebuie s poat cuta entiti pe
entiti baza unor criterii de filtrare
Clientul serviciului trebuie poat regsi informaii
despre o anumit entitate identificat printr-un cod
unic de entitate, ntr-un anumit domeniu
b) Cerine tehnice
ID Cerin Descriere
1 Structuri de date Serviciul trebuie s utilizeze structuri de date
adecvate pentru descrierea entitilor - ex HL7 RIM
(entitate, rol) sau echivalent.
2 Mesaje Serviciul trebuie s utilizeze n comunicaie mesaje
adecvate ex HL7 EIS, IHE PIX/PDQ sau
echivalent
 1.1.1.6.1.3. Serviciul de Documente

a) Cerine funcionale
ID Cerin Descriere
1 Optimizarea accesului la Registrul are rolul de a pstra metadate despre
documentele stocate documentele existente reunind informaii precum
registry i repository titlu, autor, data crerii documentului, precum i
informaia necesar pentru regsirea documentului
ntr-unul din repository-uri etc. Repository-ul conine
documentele propriu-zise, fiind un mediu de stocare
de date, n contract cu registrul care este un mediu de
stocare de metadate.
2 ntreinerea metadatelor cu Metadatele asociate documentului trebuie s reflecte
informaii corecte i actuale coninutul documentului pentru a facilita regsirea
unui document.
3 Versionare Pentru un anumit document trebuie s se poat pstra
versiuni anterioare ale sale iar documentele nu vor fi
terse fizic.
4 Acces la documente pe Metadatele asociate unui document indic diverse
baza metadatelor despre informaii despre acesta, iar serviciul trebuie s
acestea permit cutarea de documente pe baza unor criterii
bine definite.
5 Extensibilitate i Documentele pot fi separate pe diverse criterii n
flexibilitate n stocarea repository-uri diferite - cum ar fi atunci cnd este
documentelor necesar utilizarea de medii de stocare diferite sau
pentru tipuri diferite de documente.
6 Asigurarea unui punct de Registrul conine informaii despre localizarea
acces unic pentru regsirea documentului ntr-un repository sau altul
documentelor existente
7 Asigurarea flexibilitii n Unele documente trebuie s poat s fie accesibile i
accesarea documentelor dac sunt stocate n repository-uri externe, plecnd
de la premisa c repository-ul extern exista si este
accesibil i poate interopera cu serviciul de
documente(ex PACS/DICOM pentru imagistica
medical), printr-un mecanism de pointeri, mentinut
la nivelul DES.
ID Cerin Descriere
8 Repository de documente Serviciul trebuie s includ unul sau mai multe
clinice repository-uri de documente clinice. Documentele
clinice sunt documente specifice, bazate pe un model
de date particular i constrns la domeniul clinic, i
reprezint un tip important de documente n cadrul
sistemului DES.
Serviciul trebuie s poat realiza persistarea
documentelor clinice prin descompunerea acestora n
elemente de baz (act, participaie, entiti, roluri,
seciuni samd) i transformarea lor n model
relaional.
9 Interogarea datelor clinice Serviciul trebuie s ofere utilizatorului acces facil la
date clinicele nregistrare n documente. Datele
clinice pot fi: alergii, semne vitale, probleme clinice,
medicaii, imunizri, rezultate de analize, proceduri,
istoricul vizitelor medicale etc.
10 Integritatea sintactic Sistemul trebuie s permit un set predefinit de
structuri de date (mesaje) ex: HL7 CDA sau
echivalent, iar la actualizare s verifice integritatea
sintactic. Nerespectarea principiului integritii
sintactice va genera excepii.
11 Integritatea semantica Sistemul trebuie s permit un set predefinit de tipuri
de documente (ex: epicriza) i s verifice integritatea
semantic a documentelor pe 3 direcii: vocabulare,
entiti, reguli de business (ex: diagnostice asociate).
Nerespectarea principiului integritii semantice va
genera excepii sau avertismente.
b) Cerine tehnice
ID Cerin Descriere
1 Persisten Serviciul trebuie s suporte persistena documentelor
clinice codificate de diverse tipuri (ex: HL7 CDA
sau echivalent), verificate i adoptate ca bun
practic de ctre industria de profil.
ID Cerin Descriere
2 Scheme Serviciul trebuie s suporte scheme adecvate i
confirmate ca bune practici pentru interschimbul de
mesaje referitoare la documente clinice (ex: IHE
XDS a/XDS b, IHE QED, HL7 RLUS sau
echivalente)
3 Metadate Serviciul trebuie s ofere un mecanism de
interogarea metadatelor bazat pe un standard
consacrat (ex: Dublincore sau echivalent)

1.1.1.6.1.4. Serviciul de Depozit de Date

a) Cerine funcionale
ID Cerin Descriere
1 Realizarea de analize i Data warehouse-ul trebuie s poat stoca date fie
rapoarte pe date printr-o abordare analitic bazat pe crearea de
depersonalizate dimensiuni i fapte sau pe baze de date relaionale
construite special n acest scop folosind un proces
unidirecional de depersonalizarea datelor clinice.
2 Modelare Modelul de date al componentei trebuie proiectat la
un nivel de detaliu care permite realizarea de
rapoarte semnificative pentru factorii de decizie.
3 Persistarea adecvat a Data warehouse-ul va include date clinice provenite
datelor clinice din documente de tip HL7 CDA sau echivalent, care
pot fi exprimate i n form relaional (sau
analitic) pentru realizarea de rapoarte pe baza lor.
4 Optimizat pentru viteza de Data warehouse-ul trebuie optimizat pentru a
rspuns la interogri permite interogri complexe care pot fi utilizate n
complexe analiza i/sau raportarea datelor i a trendurilor din
aceste date, i nu pentru introducerea de date ca n
cazul bazelor de date operaionale.
5 Suport pentru cantiti mari Data warehouse-ul va stoca cantiti foarte mari de
de date date din documente colectate la nivel naional.
b) Cerine tehnice
ID Cerin Descriere
1 Model Serviciul trebuie s suporte un model de date
adecvat bazat pe conceptele i structuri de date din
HL7 RIM sau echivalent

1.1.1.6.1.5. Audit

Serviciul de audit este detaliat in capitolul Administrarea accesului

1.1.1.6.2. Modelul de Date

Modelul de date al sistemului va fi implementat innd cont de urmtoarele caracteristici:
Modelul de date va fi centrat pe pacientul asigurat i va oferi o imagine comprehensiv a
informaiilor medicale asociate unui pacient;
Modelul de date va suporta reprezentarea diferitelor domenii clinice pentru:
Administrare Pacieni;
Documente Clinice;
Proceduri;
Probleme medicale;
Diagnoz;
Alte domenii.
Schema de date trebuie s fie flexibil i s includ artefacte necesare pentru
interoperabilitate (de exemplu: Act, Relaie Acte, asociaii Act-Entitate, Clasa de
Confidenialitate, Identificator Eveniment (OID Object ID)
Modelul de date trebuie s poat stoca informaii despre evenimentele asociate unui pacient
care au loc n sistemul de sntate. Sistemul trebuie s poat ntreine date care sunt:
Specifice unei persoane: datele din DES sunt asociate n final unui pacient / unei persoane.
DES nu va conine informaii nesemnificative din punct de vedere al pacientului (ex. numrul
de angajai ai unui spital, date administrative ale unei secii de spital, etc)
Relevante clinic: informaiile critice care afecteaz calitatea, obiectivitatea i promptitudinea
serviciilor medicale trebuie s fie accesibile de ctre furnizorii de servicii medicale asociai
unui pacient. Exist n schimb o serie de alte informaii, de exemplu analize intermediare sau
informaii tranziionale (ex. temperatura luat de mai multe ori pe zi) care nu sunt necesare s
fie puse n comun n DES.
Relevante pentru procesul comun de ngrijire medical: DES nu este o copie 1-la-1 a tot ce
exist la nivel POS (unitate medical).
Datele din modelul informaional DES sunt, n mod normal, asociate unui eveniment
medical. Informaia este asociat unui eveniment medical trecut, care este n desfurare sau
care este planificat s aib loc n viitor. Exemple de evenimente includ: examinare clinic,
imunizare, intervenie chirurgical, prescriere de reet, emiterea unui buletin de analize de
snge, etc.
nregistrarea evenimentelor asociate unui pacient trebuie s asigure n mod exact, consistent
i lipsit de ambiguitate: identificarea pacientului, cine este furnizorul de servicii medicale
asociat, ce tip de eveniment a avut loc, unde a avut loc, cnd a avut loc i detalii asociate.
Pentru ca evenimentele s fie nregistrate n mod unitar este obligatorie folosirea
nomenclatoarelor unice i comune pentru pacieni, furnizori i locaii (existente deja n SIUI),
precum i folosirea unor reprezentri standard ale evenimentelor nsele i a detaliilor lor, pe
baza standardelor de identificare medical n vigoare.
Este necesar, pentru compatibilitate cu cerinele de mai sus, alinierea n ct mai mare msur,
la standardul HL7 RIM, sau la un model informaional compatibil cu acesta.

1.1.1.6.2.1. Coninutul DES

n faza de analiz este necesar definitivarea structurii de date specifice DES. n acest scop
trebuie avute n vedere clasificarea datelor pe baza unor criterii generale cum ar fi:
Proprietatea
Obligativitatea
Valabilitatea
Importana / Relevana
Validarea
Securitatea / Responsabilitatea / Administrarea

1.1.1.7. Servicii de integrare i transformare

Servicii de integrare i transformare

Servicii tip flux de lucru
Servicii de comunicare ntre aplicaii
Servicii de transformare date
Servicii de tip registru de servicii
 1.1.1.7.1. Servicii tip flux de lucru
Serviciile tip flux de lucru (proces) asigur capacitile de control necesare organizrii
fluxului de lucru i a interaciunii ntre aplicaii.
Fluxurile de lucru sunt reprezentate ca procese de business sau sub forma unor maini de
stare.

1.1.1.7.2. Servicii de comunicare ntre aplicaii

Serviciile de comunicare permit schimbul de informaii ntre module aplicative interne SIUI
sau ntre module SIUI i module externe (ex. HIS).
Dei, logic, modalitatea fizic de comunicare este independent de mecanismul tehnic folosit,
se doreste folosirea comunicrii de tip mesagerie folosind mecanisme WS (web services).
n acest sens, componentele existente SIUI (componente comune i modulul de decontri),
ofer un set de funcionaliti accesibile att intern, ct i extern (accesibile public oricror
aplicaii externe care au nevoie s exploateze aceste funcionaliti).

1.1.1.7.3. Servicii de transformare de date

Serviciile de transformare date permit transferul de date externe, n diferite formate, astfel:
1. Trebuie transformate i armonizate datele de la diferite surse, tipice pentru sursele
curente de date din sistemul medical pentru a putea fi compatibile cu modelul de date
intern;
2. Se va implementa un mecanism care s permit extinderea n viitor a formatului
datelor externe, conform standardelor internaionale;
3. Se vor defini i aplica reguli de calitate a datelor;
4. Se va defini i implementa un mecanism de tratare a erorilor.

1.1.1.7.4. Servicii de tip registru de servicii

Registrul de servicii permite publicarea i accesarea automat a celorlalte servicii
operaionale oferite pe magistrala de servicii.

1.1.1.8. Magistrala de Servicii (ESB)

ESB distribuie capacitile de interconectivitate necesare utilizrii serviciilor implementate n

ntreaga arhitectur inclusiv serviciile de transport i mediere. ESB este transparent pentru
serviciile care l utilizeaz (aplicative, de date, etc), fcnd totodat posibil folosirea
serviciilor independente de locaia acestora sau de protocolul folosit.
 1.1.1.9. Servicii suport

Serviciile suport sunt servicii de natur tehnic, sunt amintite n aceast seciune pentru
completitudine (ele sunt detaliate n seciunile relevante din acest document:
Servicii de securitate
Servicii de administrare
Servicii de infrastructur.

1.1.1.10. Standarde

Este necesar alinierea la standardele internaionale, conform celor mai bune practici actuale.
Precizm principalele standarde utilizate n acest moment, cu cea mai mare baz de
implementare:

Conectivitate
Domeniul de infrastructur al organizaiei IHE (Integrating Healthcare Enterprise) include o
serie de profile adoptate n proiecte majore (Canada, SUA, Frana, Austria, UE-epSOS).
Standardele reprezentative:
XDS : schimbul de documente DES ntre instituii medicale;
PIX / PDQ: identificare pacieni i interogare date demografice.

Coninut (schimb de mesaje ntre sisteme medicale)

Standardele din familia HL7 acoper n principal schimbul de mesaje ntre sisteme
informatice clinice eterogene.
Standarde reprezentative:
- HL7-v2: mesagerie ntre sisteme informatice clinice eterogene
- HL7-v3: model de date consistent i definit formal
Arhitectura Documentelor Clinice (CDA)
Familia de standarde HL7 include un model de date obiectual (RIM) pentru a reprezenta
vizual datele clinice i a identifica ciclul de via al evenimentelor transportate de un mesaj
sau de un grup de mesaje nrudite. RIM acoper ntregul domeniu al serviciilor de sntate,
incluznd servicii de laborator i farmaceutice, internri / externri / transferuri de la o clinic
la alta.
Modelul RIM include i folosirea CDA (Clinical Document Architecture), un model pentru
schimbul de documente medicale (nregistrri medicale). Derivat din RIM, CDA convertete
documentele care poate fi citit de un computer, ca i de ctre operatori umani, prin folosirea
standardului XML.
Codificare (taxonomie)
Terminologia clinic pentru a asigura interoperabilitatea sistemelor informatice medicale este
susinut de urmtoarele standarde active:
SNOMED-CT: boli, constatri clinice, proceduri;
ICD-9-CM: boli;
LOINC: date de laborator.

5.2. Vedere de ansamblu asupra sistemului informatic

Obiectivul proiectului este de a achizitiona, implementa si integra in sistemul SIUI o soluie

care s ofere toate funcionalitile necesare introducerii Dosarului Electronic de Sntate al
pacientului.
DES va reprezenta punctul de agregare a datelor medicale relevante cu privire la baza
medical a pacienilor asigurai, consolidnd DMR-urile generate din sistemele informatice
medicale.
Acces-ul la DES se va face prin protocoale i interfee construite conform standardelor din
domeniu i va permite comunicarea cu principalele sisteme implementate / n curs de
implementare din sistemul medical.
Comunicaii de tipul sistem la sistem:

DES <--> HIS

 Schimb DMR pacieni asigurai: Sistemele de tip HIS reprezint sursa de DMR pentru
dosarul electronic de sntate al pacienilor asigurai
Sistemul DES va oferi un set de interfee bazate pe standardul HL7 v3 i CDA pentru
integrarea sistemelor EHR existente i viitoare. Sistemul va folosi standarde de
taxonomie (LOINC, SNOMED, ICD, etc) pentru integrare cu aceste sisteme.
Relaia dintre DES i SIUI
Asigurrile sociale de sntate reprezint principalul sistem de finanare a ocrotirii sntii
populaiei care asigur accesul la un pachet de servicii de baz pentru asigurai. Sistemul
Informatic Unic Integrat (SIUI) este soluia software deinut de CNAS i este implementat la
nivel naional. Principalii utilizatori ai sistemului sunt: CNAS, CJAS, MF, Spitale. Sistemul
Informatic Unic Integrat (SIUI) este o aplicaie de tip distribuit din punct de vedere business /
centralizat din punct de vedere IT, destinat decontrii serviciilor aplicate asigurailor.
Sistemul Informatic Unic Integrat este extrem de important pentru realizarea informatizrii n
domeniul sntii, pentru uniformizarea sistemului de raportare i prelucrare a datelor din
sntate, la nivel naional i judeean. n acelai timp, SIUI este aliniat la strategia naional
de informatizare i se poate alinia uor la reglementrile organismelor internaionale cu care
se efectueaz schimburi permanente de date.
Sistemul Informatic Unic Integrat este destinat gestiunii online a tuturor informaiilor
medicale ale pacienilor asigurai, fiind utilizat la nivel central de ctre CNAS i CJAS pentru
ndeplinirea funciilor specifice de administrare. La acest nivel, SIUI asigur urmtorul set de
funcionaliti:
Evidena pltitorilor de contribuii;
Gestiunea fondului asigurrilor de sntate;
Gestiunea asigurailor;
Gestiunea furnizorilor de servicii medico-farmaceutice;
Asigurarea controlului serviciilor medicale (la nivelul CNAS), respectiv distribuia
documentelor de referin ctre furnizorii de servicii medicale (la nivel CJAS).
Furnizorii de servicii medicale i reprezentanii angajatorilor interacioneaz cu SIUI pentru a
transmite rapoarte i a recepiona documente specifice (de exemplu nomenclatoare).
SIUI a fost actualizat la o versiune nou, online care permite centralizarea datelor. n prezent,
SIUI este folosit pentru a procesa datele a peste 30000 de furnizori de servicii medicale i
farmaceutice.
Prin intermediul cardului de sntate din componena eCard a SIUI se vor valida identitatea
utilizatorilor de tip asigurat; cardul de sntate reprezint punctul central de management al
identitii n sectorul medical.
Unul din sectoarele n care DES va beneficia de datele gestionate n SIUI sunt programele
naionale. n SIUI se face o gestiune a programelor naionale precum i participarea
pacienilor la aceste programe. DES va prelua aceste informaii primite din SIUI n msura n
care acestea sunt disponibile.
Sistemul DES preia din sistemul SIUI date privind calitatea de asigurat. Sistemul DES va
folosi datele deja existente n SIUI privind asiguraii pentru iniializarea sistemului.
Sistemul SIUI este construit pe o arhitectur centralizat, bazat pe standardele web. Acest tip
de arhitectur este compatibil cu standardele n domeniu i va permite o mai bun
comunicare ntre subsistemele SIUI. Comunicarea dintre DES i celelalte subsisteme ale SIUI
se face folosind modulul de integrare i se va baza pe tehnologia serviciilor web.
Metodele tehnice de integrare i alte detalii actualizate despre sistemul SIUI se pot regsi pe
site-ul: http://193.151.30.188/cnas/.
Detaliile i fluxurile de comunicare ntre subsistemele SIUI se vor stabili n faza de analiz a
proiectului.
Comunicaii de tipul utilizator la sistem:
DES <--> Asigurat
Vizualizare DES personal: Prin intermediul unei interfee web se va permite accesul la
DES-ul asigurat ce arat DMR-urile colectate din sistemele de tip HIS sau medici
de familie
Auditeaz acces DES asigurat: Se permite verificarea de ctre asigurat a accesului la
DES-ul sau de ctre medici
Schimb nivel autorizare acces DES asigurat: Se va restriciona accesul la DES-ul
asigurat ctre un grup mai restrns de medici
DES <--> Medici
Vizualizare DES pacieni asigurai: Prin intermediul unei interfee web se va permite
cutarea unui asigurat i vizualizarea DES-ului respectivului asigurat, pe baza rolului i
accesului definit
5.3. Scenarii de utilizare

In acest caiet de sarcini sunt descrise scenariile care trebuie luate in considerare de catre toti
ofertanii la elaborarea ofertelor, acestea fiind considerate minimum necesare. Ofertantii vor
avea in vedere descrierea detaliata in oferta tehnica a abordarii si a propunerilor lor pentru
faza de analiza. Scenariile de utilizare descriu tot fluxul operational pentru o intelegere clara
a fluxului. Totusi cerintele se aplica doar sistemului DES.
n aceasta seciune se ilustreaz scenariile tipice de utilizare a sistemului i se indic modul n
care vor circula informaiile principale n sistemul DES.

5.3.1. Accident i INTERVENIE de urgen

Context:
Un asigurat diabetic i pierde cunotina pe strad i este transportat la serviciul de urgen
de o ambulan;

Pas Aciuni clinice / administrative Interaciuni cu / ntre sistemele informatice

n ambulan pacientului i se
1 asigur tratamentul necesar
stabilizrii (dac este cazul)
Ulterior internrii se verific n HIS-ul
spitalului dac pacientul are un istoric medical
n cadrul instituiei. n cazul n care nu exist
istoric, se creeaz un dosar al pacientului,
existnd posibilitatea de a prelua date relevante
din DES.
La sosirea la spital, un medic
Se creeaz n dosarul (existent sau nou creat)
preia pacientul i i pune
2 din HIS un episod medical al pacientului.
diagnosticul de atac de
Medicul acceseaz DES (autentificare n
hipoglicemie
domeniul naional DES) pentru a verifica
istoria medical a pacientului, precum i
eventuale episoade anterioare similare. n HIS
este introdus diagnosticul pus de ctre medicul
specialist, cu precizarea detaliilor legate de
internarea pacientului.
Medicul creeaz o nou foaie de observaie n
Se administreaz tratamentul HIS-ul spitalului n care sunt precizate i
3
adecvat pacientului. detaliile legate de medicaie i procedurile
efectuate pacientului.
 n sistemul HIS se adaug nregistrri la dosarul
HIS al pacientului, n concordan cu
Starea pacientului este stabilizat, activitile medicale (monitorizare, prescriere
4 este gata de externare i i se emite medicamente, prescriere diet, etc). Sistemul
o reet HIS creeaz o fi de externare; datele medicale
relevante acestui eveniment sunt transmise n
DES unde se adaug la istoricul pacientului.

5.3.2. Internare la spital i operaie

Context:
O pacient aflat n supravegherea MF are simptome repetate de pierdere a cunotinei;
MF i face o trimitere a pacientei pentru consultaie de specialitate la un spital;

Pas Aciuni clinice / administrative Interaciuni cu / ntre sistemele informatice

Recepionista creeaz un dosar nou pentru
pacient n HIS daca nu l gsete deja n sistem.
Pacientul se prezint la recepia n cazul n care pacientul nu are istoric medical
1
spitalului pentru consult nregistrat n HIS-ul spitalului, este creat un
dosar pentru pacient, existnd posibilitatea de a
prelua date relevante din DES.
2 Medicul consultant face anamneza Medicul se conecteaz (dac nu este deja) n
bolii sistemul local (HIS) prin operaiunea de login n
HIS-ul spitalului. Pe baza drepturilor definite n
DES medicul acceseaz informaiile din DES
referitor la pacientul n cauz i automat se
transmit ctre DES, date de identificare a
medicului, inclusiv parafa pentru sistemul de
audit.
Medicul identific i afieaz dosarul pacientului
aflat n HIS. n plus, medicul vizualizeaz
informaiile din DES, prin HIS este nregistrat
anamneza n HIS i e stabilit internarea
 pacientului cu crearea foii de internare.
Medicul efectueaz un consult i l
3 trimite pe pacient s fac o Medicul cere un ECG prin HIS
electrocardiogram (ECG)
Rezultatele testrii sunt adugate la dosarul HIS
al pacientului
Medicul este notificat c este disponibil
4 n spital se efectueaz ECG rezultatul ECG
Medicul poate compara rezultatul ECG cu
rezultatele unor ECG precedente (efectuate n
spital, sau n ambulan)
Medicul analizeaz rezultatele
Diagnosticul este nregistrat n dosarul HIS al
5 ECG i diagnosticheaz un puls
pacientului
neregulat

Medicul concluzioneaz c este Medicul face o trimitere din sistemul HIS, ctre
vorba de o complicaie spitalul judeean
6
coronarian i face o trimitere HIS genereaz foaia de externare care
pacientului la un spital judeean este transmis i n DES;

7 Urmtorul episod medical

Pacientul este transferat la spitalul La internare, pacientului i se creeaz o foaie de

8
judeean internare n HIS-ul spitalului judeean

Sunt preluate n HIS-ul spitalului judeean prin

intermediul DES detaliile relevante nregistrate
n trimiterea i foaia de externare a pacientului
n urma consultului la spitalul
Detaliile tratamentului i procedurilor necesare
judeean, medicul specialist decide
9 sunt nregistrate n HIS spitalul judeean.
c este necesar implantarea unui
n HIS-ul spitalului judeean sunt nregistrate
stimulator cardiac
mai multe evenimente, legate de diagnostic, iar
datele medicale relevante i recomandrile
medicale sunt transmise n DES
 5.3.3. Accesul asiguratului n portal
Context:
Un asigurat acceseaz portalul medical DES pentru a consulta informaii medicale proprii.
Similar i n cazul n care acceseaz dosare ale altor persoane pentru care este delegat
autorizat.

Pas Aciuni clinice / administrative Interaciuni cu / ntre sistemele informatice

Folosind un computer, asiguratul acceseaz

Un asigurat dorete s-i consulte portalul medical prin internet. n continuare i se
1 dosarul propriu cere s se autentifice. Asiguratul se autentific n
portal prin mecanismul de autentificare.

Asiguratul verific datele n pagina de portal dedicat datelor medicale

medicale relevante din portal relevante, asiguratul consult informaiile sale i
2
are posibilitatea exportrii lor n format PDF
pentru a putea fi printate.

Asiguratul vizualizeaz noua intrare medical. i

verifica sursa (datele de identificare i parafa
Asiguratul observ o nou intrare
3 medicului care a accesat informaiile) i
n dosarul su medical din DES
concluzioneaz c este de la ultima vizit
medical de la spital
 n pagina de portal (tab-ul) dedicat auditului,
asiguratul citete lista persoanelor care i-au
accesat dosarul i descoper c la ultima vizit
medical doi doctori i-au accesat dosarul, primul
pentru a-l citi iar al doilea pentru a aduga datele
medicale relevante de la ultima vizit la spital.
j. Citete motivaiile medicilor
Asiguratul verific accesul
4 pentru a-i accesa dosarul i
medicilor la dosarul propriu
concluzioneaz c sunt corecte.
k. Citete motivaiile medicilor
pentru a-i accesa dosarul, dar nu
este clarificat i semnaleaz acest
eveniment prin portal, moment n
care deschide un tichet de
asisten

5.3.4. Internare la spital i investigaii laborator

Context:
Pacient aflat n supravegherea MF acuz dureri repetate n zona abdominal;
MF i face o trimitere a pacientului pentru consultaie de specialitate i investigaii la un
spital;

Pas Aciuni clinice / administrative Interaciuni cu / ntre sistemele informatice

Pacientul se prezint la recepia In cazul n care pacientul nu are istoric medical
1
spitalului pentru consult
2 Medicul consultant face anamneza
Recepionista creeaz un dosar nou pentru pacient
n HIS
nregistrat n HIS-ul spitalului, este creat un dosar
pentru pacient, existnd posibilitatea de a prelua
date relevante din DES.
Medicul se autentific n sistemul local prin
operaiunea de login n HIS.
Medicul identific i afieaz dosarul pacientului
aflat n HIS.
n plus, medicul vizualizeaz n DES, prin HIS.
 Este consemnat n HIS anamneza i decizia de
internare.
Medicul solicit efectuarea unui Medicul solicit prin HIS setul de analize, cu
3
set complex de investigaii selectare pe clase de analize
n laboratorul spitalului este primit cererea de
investigaii prin intermediul HIS spital
Sunt efectuate investigaiile iar rezultatele sunt
adugate la dosarul HIS al pacientului
n laboratorul spitalului se n laborator sunt vizualizate i validate rezultatele
4
efectueaz investigaiile analizelor
Prin intermediul HIS spital este nchis cererea de
investigaii, cu ataarea rezultatelor
Medicul este notificat c sunt disponibile
rezultatele analizelor
Rezultatele analizelor sunt ataate/ nregistrate n
HIS
Medicul vizualizeaz rezultatele transmise de
5 Medicul analizeaz rezultatele ctre laborator prin intermediul HIS, el putndu-
le compara cu rezultatele unor analize similare
precedente (efectuate n spital, n afara spitalului
prin DES, sau n ambulan)
Diagnosticul este nregistrat n dosarul HIS al
pacientului
5 Medicul diagnosticheaz pacientul
Tratamentul prescris pacientului este nregistrat n
dosarul HIS
Medicul creeaz o nou foaie de observaie n
Se administreaz tratamentul HIS-ul spitalului, n care precizeaz evoluia
6
pacientului pacientului n urma tratamentului efectuat i
diagnosticul la externare
7 Starea pacientului este ameliorat, n sistemul HIS se adaug nregistrri la dosarul
este gata de externare i se prescrie HIS al pacientului, n concordan cu activitile
o reet medicale
Prin intermediul HIS, se creeaz o fi de
externare; datele medicale relevante acestui
eveniment i eventual reeta (dac este
 considerat informaie medical relevant) sunt
transmise n DES unde se adaug la istoricul
pacientului.
5.3.5. Dializ
Context:
Pacient aflat n programul de dializ;
Pacientul este nou intrat n program i se prezint pentru efectuarea tratamentului
Pas Aciuni clinice / administrative Interaciuni cu / ntre sistemele informatice
Pacientul se prezint la recepia
1 centrului de dializ pentru Pacientul se prezint la centru pentru tratament.
efectuarea tratamentului
Furnizorul se autentific n domeniul local prin
operaiunea de login n HIS.
Se identific i afieaz dosarul pacientului aflat
n HIS.
Furnizorul de servicii de dializ n plus, se vizualizeaz n DES, prin HIS sau
2
efectueaz tratamentul direct n portal istoricul medical al pacientului
pentru a verifica dac nu s-au nregistrat
evenimente medicale majore de la vizita
anterioar a pacientului sau dac nu a fost
nregistrat n evidena altui centru de dializ
In HIS sunt nregistrate informaiile cu privire la
tratarea pacientului cu precizarea detaliilor
Pacientului i se efectueaz specifice (pacientul se afla n primele 6-12
3
hemodializa edine de hemodializa)
Dup finalizarea edinei, este programata prin
intermediul HIS urmtoarea edina
Tratamentul aplicat n edina de hemodializa este
nregistrat n dosarul HIS
De asemenea este efectuata, nregistrata n HIS i
Pacientul prsete centrul de prezentata pacientului programarea pentru
4
dializa edina viitoare.
Datele medicale relevante acestui eveniment sunt
transmise n DES unde se adaug la istoricul
pacientului.
 5.3.6. Auditarea sistemului
Context:
La nivel de utilizator se poate observa cine a accesat dosarul de sntate
Pas Aciuni clinice / administrative
1 Un utilizator acceseaz portalul DES
2 Fiecare episod din dosarul de sntate are asociat informaii de audit i anume: cine,
cnd, ce anume i de ce
3 In momentul n care un medic acceseaz n dosarul unui utilizator, se creeaz o
intrare n audit care specifica care doctor a accesat dosarul, ce anume a vizualizat i la
ce ora. Acest proces este valabil i n cazul urgentelor medicale
4 In momentul n care un medic introduce un episod n dosarul pacientului prin
sistemul informatic al spitalului unde activeaz, datele de identificare i parafa sunt
transmise ctre DES pentru auditare.

5.3.7. Exemplu de urmrire a unui episod de boala

Context:
Pacientul se prezint se prezint la medicul specialist pentru o problema de sntate
Medicul specialist iniiaz un episod nou de boala
Aciuni clinice / administrative
Pas
1 Medicul specialist iniiaz o noua intrare de tip DMR.
In cadrul consultaiei iniiale medicul decide ca pentru stabilirea diagnosticului este
nevoie de o radiografie i trimite pacientul la o unitate medicala care are departament
specializat.

2 Pacientul se prezint la radiologie. Rezultatele investigaiei sunt introduse de ctre

departamentul de radiologie i ajung n dosarul electronic de sntate al pacientului
pentru a putea fi consultate.

3 Pacientul se prezint a doua oara la medicul specialist. Acesta acceseaz din sistem
rezultatele radiografiei i stabilete diagnosticul pacientului.
4 In urma stabilirii diagnosticului, medicul specialist stabilete i o schema de
tratament. Aceasta este introdusa n sistem i se adaug n dosarul electronic al
pacientului la seciunea de medicaie curenta, pentru a putea fi consultata ulterior.
5 La terminarea perioadei de tratament prescrisa de medicul specialist, pacientul se
ntoarce la control.
Medicul specialist acceseaz din nou datele medicale specifice episodului de boala, l
consulta pe pacient i decide ca boala pacientului a fost vindecat i decide nchiderea
episodului.

5.3.8. Interogare date demografice

Context:
Aplicaia HIS instalata la sediul unei uniti spitaliceti. Un pacient ajunge la Unitatea de
primire a urgentelor a spitalului acuznd o stare acuta de ru.
Pas Aciuni clinice / administrative
1 Personalul de la biroul de recepie a pacienilor utilizeaz aplicaia HIS pentru a
obine pe baza codului unic de asigurat datele demografice ale pacientului (nume,
prenume, adresa, stare civila, etc).

2 Aplicaia HIS solicita Dosarului Electronic de Sntate aceste informaii i le

utilizeaz pentru a completa n mod automat cmpurile corespunztoare din noua fisa
pentru pacient.

5.3.9. Interogare vocabulare

Context:
Aplicaia HIS instalata la sediul unui spital necesit pentru codificarea informaiei medicale
din documentele clinice un set de vocabulare adoptate la nivel naional
Pas Aciuni clinice / administrative
1 Aplicaia HIS instalata la sediul unui spital necesit pentru codificarea informaiei
medicale din documentele clinice un set de vocabulare adoptate la nivel naional,
precum nomenclatorul de medicamente, specialiti clinice, planuri naionale de
compensare a medicamentelor samd.

2 Aplicaia solicita aceste vocabulare Dosarului Electronic de Sntate i le stocheaz

local pentru utilizare n cadrul formularelor medicale electronice i a comunicaiei cu
sisteme externe
 5.3.10. Interogare uniti medicale
Context:
Un pacient este consultat de un medic specialist.
Pas Aciuni clinice / administrative
1 Un pacient este consultat de un medic specialist. Folosind aplicaia informatica din
cabinet, medicul scrie pacientului un bilet de trimitere ctre internare pentru o unitate
clinica specializata pe endocrinologie

2 Pentru a decide unitatea medicala ctre care se trimite pacientul, medicul folosete
aplicaia informatica instalata n clinica de care aparine pentru a cuta unitile
medicale care dispun de aceasta specialitate

3 Pe baza datelor obinute, medicul ii prezint pacientului lista de opiuni pe care acesta
o are n alegerea unitii spitaliceti la care se poate prezenta

5.3.11. Trimitere la analize de laborator / radiologie i

nregistrare rezultate
Context:
Pacientul se duce la medicul de familie pentru o anumita problema de sntate
Pas Aciuni clinice / administrative
1 Medicul de familie l consulta i decide ca trebuie sa l trimit pentru a-i face analize
de laborator sau o investigaie radiologica. Ii emite pacientului un bilet de trimitere
ctre un laborator de analize sau ctre o unitate medicale care are departament de
radiologie. Biletul de trimitere este nregistrat n sistem cu starea de emis. Atta
timp ct pacientul nc nu s-a prezentat la laborator/radiologie, el poate fi nc anulat
de medicul de familie.

2 In momentul n care pacientul s-a prezentat la laborator/radiologie, acesta efectueaz

recoltarea sau investigaia radiologica i n acelai timp n sistem biletul de
marcheaz ca fiind n starea pacient prezentat.

3 In momentul n care sunt finalizate rezultatele de laborator, acestea sunt introduse n

sistem i se ataeaz dosarului electronic al pacientului, pentru a putea fi consultate la
Pas Aciuni clinice / administrative
nevoie.

4 Daca dup un interval de timp de la emitere pacientul nu se prezint la

laborator/radiologie, biletul trece automat n starea expirat.

5.3.12. Consultarea istoricului medical al pacientului

Context:
Pacientul se prezinta la un medic specialist, fie n regim ambulatoriu, fie n cadrul unei
spitalizari
Medicul specialist consulta sistemul pentru a studia cteva categorii de informatii esentiale
Pas Aciuni clinice / administrative
1 O pacienta este consultata de medicul obstetrician. Pacienta este n trimestrul al III-
lea de sarcina si acuza o stare de slabiciune generala.

2 Medicul specialist consulta sistemul pentru a studia cteva categorii de informatii

care sunt esentiale n procesul de diagnosticare si tratare a pacientului
Boli cronice
Alergii la medicamente si/sau alimentatie
Medicatie curenta
Antecedente familiale
Lista de imunizari efectuate de pacient
Istoricul medical al pacientului: lista de episoade anterioare, pentru fiecare putnd
consulta eventualele rezultate la analize de laborator, investigatii radiologice, etc.

3 Pentru a avea o vedere de ansamblu a starii de sanatate a pacientei de-a lungul

timpului, medicul solicita lista nregistrarilor de semne vitale din ultimul an.

4 Medicul solicita de asemenea lista rezultatelor imagistice, precum si rezultatele

analizelor de laborator existente n Dosarul Electronic de Sanatate.

5 Aplicatia poate sa nregistreze noi date medicale pentru pacienta n cadrul Dosarului
Electronic de Sanatate sau sa le actualizeze pe cele existente.
 5.4. Date privind ngrijirea medicala

Activitile de ngrijire medicala sunt cele executate de ctre prestatorii de servicii medicale;
acestea creeaz nregistrri medicale electronice n sistemul DES.

5.4.1. Gestiunea nregistrrilor medicale

Datele pot fi nregistrate folosind seturi de coduri standardizate sau nomenclatoare, depinznd
de natura datelor. Datele pot fi nregistrate i folosind modele nestructurate. Detaliile privind
identitatea celor care au introdus datele i momentul de timp exact al introducerii trebuie
nregistrate.

1.1.1.11. Identificarea i actualizarea datelor pacientului

Sistemul trebuie sa asigure identificarea unica a unui pacient mpreuna cu seturile de date
aferente. Unicitatea nregistrrilor este foarte importanta att din punct de vedere legal ct i
pentru organizarea coerenta a datelor de ctre prestatorii de servicii. Unicitatea se asigura prin
identificator unic intern bazat pe ID-ul de asigurat. Acestui identificator i se pot asocia
identificatori externi (ex: CNP). Informaiile medicale sunt preluate i ataate nregistrrilor
pacientului.

1.1.1.12. Gestionarea informaiilor demografice

Se nregistreaz i actualizeaz informaiile demografice ntr-un mod n care sa fie relevant

din punct de vedere clinic iar datele s poat fi folosite pentru raportare. Informaiile de
contact, incluznd adrese i numere de telefon precum i informaii demografice precum data
naterii, sex i alte informaii sunt stocate i actualizate n nregistrrile pacienilor i sunt
folosite pentru furnizarea serviciilor de ngrijire i pentru raportare. Informaiile demografice
trebuie nregistrate sub forma de cmpuri discrete (nume separat de prenume i adresa, etc.)
Sistemul de audit va urmri cine actualizeaz informaiile demografice i ora exacta cnd
sunt actualizate.

1.1.1.13. Realizarea unui sumar al nregistrrilor medicale

Sistemul trebuie sa fie capabil sa ofere informaia necesara ntr-un mod sumar sau sub forma
de raport determinat de politicile definite de exemplu pentru folosirea la terminarea unor
episoade de ngrijire fr a necesita nregistrarea altor informaii de ctre personalul
prestatorului de servicii. Un exemplu de sumar poate fi un raport de o singur pagin tipizat.

5.4.2. Gestiunea istoricului pacientului

Datele conin istoricul informaiilor medicale relevante ca de exemplu: date istorice care au
legtur cu diagnosticele precedente, intervenii chirurgicale i alte proceduri efectuate
pacientului precum i condiii de sntate relevante a membrilor de familie. Datele
nregistrate n sistem provin din interviuri pacient sau date istorice electronice sau ne-
electronice. n mod tipic cnd pacienii viziteaz pentru prima data un prestator de servicii
medicale, aduc cu ei informaii medicale provenite din evenimente anterioare.

5.4.3. Preferine, indicaii, consimminte i autorizaii

1.1.1.14. Gestiunea preferinelor pacientului i a familiei

Date precum limba, religia, practicile spirituale i cultura pot fi importante pentru modul cum
sunt administrate serviciile medicale. Sistemul trebuie sa poat nregistra date astfel nct
acestea sa fie disponibile prestatorului de servicii medicale la locul de ngrijire.

1.1.1.15. Gestiunea indicaiilor pacientului

Datele privind indicaiile furnizate de pacient precum i circumstanele n care acestea au fost
nregistrate pot fi importante pentru modul cum sunt administrate serviciile medicale. Datele
pot face referiri la nregistrri sau documente legale daca este cazul.

1.1.1.16. Gestiunea consimmintelor i autorizaiilor

Sistemul trebuie s permit crearea, actualizarea i verificarea deciziilor pacientului privind

tratamentul sau autorizaiilor pentru divulgarea informaiilor atunci cnd sunt necesare.
Deciziile trebuie sa fie documentate i trebuie sa includ gradul de informare, nivelele de
verificare i de expunere la opiunile de tratament. Documentaia va asigura ca serviciile
medicale care sunt efectuate pacientului sunt conform prevederilor pacientului, familiei sau
altor pri responsabile. Pot exista o serie de documente active la un moment de timp dat care
determina modul de efectuare al serviciilor medicale.

5.4.4. Liste specifice

1.1.1.17. Gestiunea listei alergiilor, intoleranelor i reaciilor
adverse
Alergenii, inclusiv imunizrile i substanele sunt identificare i nregistrate de preferat
folosind seturi de coduri specifice daca este posibil. Lista este actualizata de-a lungul
timpului. Toate datele relevante, inclusiv evenimentele raportate de pacient sunt stocate
mpreuna cu descrierea alergiei i reaciei adverse i poate fi modificata ulterior. Lista include
reacii ale pacientului care sunt clasificate ca alergii dar i alte reacii precum intolerante,
efecte secundare i alte reacii adverse la medicamente, dieta sau declanatori din mediul
nconjurtor.

1.1.1.18. Gestiunea listei medicamentelor

Listele de medicamente sunt actualizate de-a lungul timpului, fie de-a lungul vizitei sau
internrii unui pacient fie de-a lungul unei perioade mai mari de timp. Toate datele relevante
inclusiv data/ora nceperii administrrii, modificri ce au loc asupra medicaiei i perioadelor
de administrare i data/ora ncetrii administrrii sunt stocate n lista. Elementele din lista pot
include date privind medicamente alternative, suplimente i medicaie naturista daca este
cazul. Lista nu este limitata la medicamentele nregistrate de prestatorii de servicii dar poate
include de exemplu i nregistrri provenite din modulul ePrescripie, medicaie raportata de
pacient (si nregistrata ca atare) i informaii adiionale dozajul particular administrat.

1.1.1.19. Gestiunea listei de probleme

Problemele pot include condiii cronice, diagnostice, simptome, limitri funcionale, condiii
specifice ale vizitei sau internrii. Listele de probleme sunt gestionate de-a lungul timpului,
fie de-a lungul vizitei sau internrii unui pacient fie de-a lungul unei perioade mai mari de
timp permind documentarea informaiei istorice i urmrirea schimbrilor aprute n
probleme i prioritatea lor. Sursa problemelor (raportate de pacient, verificate de medic, etc.)
trebuie nregistrata explicit n sistem att timp ct fac parte din setul date medicale relevante.
Toate datele relevante sunt stocate n fiecare nregistrare inclusiv data notarii i a
diagnosticului, datele schimbrilor aprute n probleme.

1.1.1.20. Gestiunea listei imunizrilor

Listele de imunizri sunt gestionate de-a lungul timpului fie de-a lungul vizitei sau internrii
unui pacient fie de-a lungul unei perioade mai mari de timp. Detaliile imunizrilor
administrate sunt nregistrate ca elemente discrete care trebuie sa includ informaii precum
data, tipul, productorul, numrul lotului.
5.5. Suport clinic

5.5.1. Informaii despre prestatorul de servicii medicale

1.1.1.21. Nivele de acces pentru prestatorul de servicii
medicale
Sistemul trebuie sa includ un registru cu persoanele care au acces la sistem. Registrul trebuie
s conin date privind nivelul de acces necesar pentru accesarea sistemului i orice alte
informaii necesare pentru verificarea ca utilizatorul este autorizat s foloseasc sau s
vizualizeze datele.

1.1.1.22. Informaii privind locaiile

Sistemul trebuie sa includ informaii privind locaiile prestatorilor de servicii medicale

inclusiv date de contact i informaii de contact pentru intervale de timp din afara
programului de lucru pentru persoanele abilitate. Sistemul trebuie s includ informaii
privind locaiile principale dar i locaiile secundare ale prestatorului de servicii medicale
daca acestea exista. Informaiile gestionate pot include adrese web, hri, adrese i locaia
exact a cldirilor, etc.

1.1.1.23. Registrul prestatorilor de servicii medicale

Registrul ofer acces de tip director, registru sau depozit pentru informaiile prestatorilor de
servicii medicale actualizate aflate n SIUI n concordanta cu legile, regulamentele i
cerinele interne i externe relevante. Datele incluse pot fi numele complet, specialitatea,
adresa, locaia, date contact, etc. Vizualizarea datelor este posibila pentru utilizatori conform
nivelurilor de securitate i acces necesare. Pacienii nu vor avea de exemplu acces la
informaii personale ale prestatorilor de servicii medicale.

5.5.2. Registrul pacienilor (preluate din eCard)

Sunt incluse informaii precum numele complet, adrese, persoane de contact, informaii
contact. Vizualizarea datelor se face n conformitate cu nivelele de securitate i acces
necesare.

1.1.1.24. Informaii demografice pacient (preluate din eCard)

Sistemul trebuie sa includ setul de date minimal necesar conform legilor aplicabile i
necesitailor de raportare. Registrul trebuie sa includ posibilitatea urmririi schimbrilor
elementelor, suport pentru multiple coduri de identificare i nume multiple, i istoricul
schimbrilor de nume.

1.1.1.25. Locaii de reedina ale pacienilor pentru

pregtirea i administrarea serviciilor
Informaiile privind reedina pacienilor este necesara pentru servicii care au loc n afara
locaiilor prestatorului de servicii medicale. Exemple pot include vizitele pentru oferirea
ngrijirii medicale pentru copii nou nscui direct la domiciliu sau n cazul pacienilor cu
probleme de mobilitate. Sistemul trebuie sa permit identificarea reedinelor multiple pentru
un pacient.
 5.6. Rapoarte, msurtori, analiza i cercetare

Funciile de raportare, msurtori, analiza i cercetare trebuie sa vina n completarea

funciilor existente deja n SIUI.

5.6.1. Rezultate i analize

De multe ori este necesara raportarea asupra statisticilor medicale ctre persoane i publicul
larg. Sistemul trebuie sa permit generarea rapoartelor prin exporturi de date sau generare
rapoarte. Trebuie sa fie posibila generarea rapoartelor bazate pe informaii particulare precum
boli transmisibile sau diagnostice specifice. Rapoartele pot include indicatori privind procesul
de ngrijire, rezultate, cost i aderarea la cele mai bune practici.

5.6.2. Generarea rapoartelor

Prestatorii de servicii medicale precum i administratorii sistemului au nevoie de acces la
datele stocate n DES pentru generarea rapoartelor standard i ad-hoc. Aceste rapoarte pot fi
necesare din perspectiva medicala, administrativa, financiara sau pentru luarea unor decizii.
Rapoartele pot fi bazate pe date structurare sau texte nestructurate provenite din nregistrrile
pacienilor.

1.1.1.26. Generarea nregistrrilor medicale sub forma de

rapoarte
Sistemul trebuie sa permit generarea unor rapoarte formale coninnd informaii provenite
din dosarul pacientului. Trebuie sa fie posibila generarea unor subseturi ale dosarului bazate
pe profile. De exemplu un profil poate conine informaii demografice pacient i informaii
externare iar alt profil poate conine toate informaiile create de un anumit prestator de
servicii medicale n timp ce un al treilea profil poate conine toate informaiile nregistrate n
timpul un episod de ngrijire.

1.1.1.27. Generarea rapoartelor standard

Prestatorii de servicii medicale i administratorii sistemului au nevoie de acces la datele

stocate n DES din perspectiva medicala, administrativa, sau pentru luarea unor decizii.
Rapoartele pot fi bazate pe date structurare sau texte nestructurate provenite din nregistrrile
pacienilor. Utilizatorii trebuie sa poat filtra/sorta rapoartele n funcie de diverse criterii (de
exemplu sa poat vedea doar pacienii cu diabet dintr-o lista de pacieni i diagnostice).
 1.1.1.28. Generarea rapoarte ad-hoc

Sistemul trebuie sa ofere suport pentru generarea rapoartelor folosind instrumente adecvate.
Aceste instrumente trebuie sa permit rspunsuri rapide la cerine de raportare i analiza noi.
Utilizatorii trebuie sa i poat defini parametrii pentru rapoarte cu rezultate care pot conine
att date structurate cat i date nestructurate. Sistemul trebuie sa permit cutri i dup
prezenta sau absenta unor seturi de date. De exemplu n cadrul unei verificri pentru
respectarea unui protocol medical care presupune testarea unei categorii de pacieni o data la
3 luni, investigatorul trebuie sa poat crea un raport pentru aflarea pacienilor care nu au date
de test n DES.

5.7. Administrarea accesului

Pentru asigurarea confidenialitii toate modulele aplicaiei trebuie sa adere la un set de

reguli stabilite pentru asigurarea controlului accesului i protejarea datelor personale.
Masurile de control al accesului previn utilizarea fr autorizaie a datelor i protejeaz
mpotriva pierderilor, modificrilor i distrugerii datelor. Sistemul DES trebuie sa fie capabil
sa se integreze cu sisteme standard de securitate i sa asigure ca orice entitate (persoana,
aplicaie, echipament, etc.) care acceseaz sistemul este autentificat, autorizat i auditat n
conformitate cu politicile de administrare a accesului.

5.7.1. Autentificarea entitilor

Att utilizatorii cat i aplicaiile se supun regulilor de autentificare. DES ofer mecanisme de
autentificare atunci cnd se ncearc folosirea aplicaiei. Aplicaiile care se conecteaz la DES
trebuie sa se autentifice n prealabil pentru a se putea face autorizarea. Modalitile prin care
se face autentificarea sunt:
1. Posesorii de carduri de sntate se pot autentifica n portal prin internet i la medic
prin prezenta fizica, astfel:
In portal web autentificarea se face pe baza codului unic de asigurat, parolei personale si a
matricei de siguranta. Codul unic de asigurat este imprimat pe cardul de sanatate. Parola
reprezinta un cuvant cheie pe care asiguratul o foloseste pentru autentificare in portal.
Matricea de siguranta reprezinta un tabel cu N linii si M coloane in care sunt trecute anumite
caractere aleatorii, generate la initializare. Parola si matricea de siguranta se ridica de la
sediul central sau local al CNAS. Pentru autentificare asiguratul se conecteaza in portal unde
introduce codul unic de asigurat, parola, si i se cere sa introduca caracterele din matricea de
securitate localizate la intersectia linilor Nx si My, alese aleator. Daca asiguratul se
conecteaza prima data in portal i se va cere sa schimbe parola. In cazul in care asiguratul
doreste sa schimbe parola sau matricea de siguranta se adreseaza CNAS.
La medic sau la spital, pacientul (posesorul de card) se autentifica prin introducerea cardului
n cititorul din dotarea medicului sau spitalului, urmat de codul PIN.

2. Medicii, pentru activitati profesionale, se autentifica n sistemele locale, (ex: HIS),

folosind metode definite de sistemele locale. Pentru a accesa date din DES, sistemul
HIS se autentifica folosind certificatul digital propriu calificat la care se aduga parafa
medicului care face cererea de date. Sistemul HIS al spitalului pstreaz o corelare
intre sistemul propriu de autentificare i parafa medicului care s-a autentificat n
sistem.
Aplicaiile care schimba informaii cu DES se vor autentifica pe baza de certificat digital.
Canalul de comunicaie este ntotdeauna criptat.

5.7.2. Autorizarea entitilor

Utilizatorii DES sunt autorizai sa foloseasc componentele acestuia conform identitii,
rolului, sarcinilor, locaiei, condiiile curente ale pacientului, domeniului n care activeaz
presatorul de servicii medicale i jurisdicia legala aplicabila.

5.7.3. Controlul accesului

Sistemul verifica i impune controlul accesului pentru toate componentele DES, informaiile
din DES i aciunile utilizatorilor precum i pentru componente externe pentru a preveni
utilizarea neautorizata a resurselor. DES profita de mecanismele deja existente n SIUI
(eCard).

5.7.4. Gestiunea accesului pacienilor

Sistemul trebuie sa permit gestiunea drepturilor de vizualizare a coninutului dosarului
electronic de sntate. Pacientul poate vedea seciuni de date ale propriului dosar conform
legilor i regulamentelor aplicabile.

5.7.5. Recunoaterea aciunilor

Sistemul trebuie sa nu permit nerecunoaterea aciunilor fcute de ctre utilizatori folosind
sistemul DES inclusiv a datelor primite sau transmise prin sistem. Sistemul nregistreaz
informaii audit pentru toate activitile executate de utilizatori sau pentru datele primite n
sistem i transmise din sistem. Sistemul garanteaz c utilizatorii sistemului nu pot nega mai
trziu introducerea unor date sau recepionarea unor date.

5.7.6. Schimbul sigur de date

La schimbul de informaii din cadrul sistemului DES este necesara o securitate adecvata care
poate fi obinuta prin mecanisme specifice precum criptare i autentificare. Un schimb de
date securizat necesita o coordonare globala a schimbului de informaii intre componentele
DES i reguli privind modul cum vor decurge aceste comunicaii. Politicile de securitate
aplicate la nivele i locaii diferite trebuie sa fie consistente i compatibile intre ele pentru a
asigura protecia informaiei la trecerea intre ele.

5.7.7. Rutarea securizata a datelor

Datele electronice trebuie sa fie transmise ctre i de la entitile cunoscute i autentificate n
concordanta cu regulile i standardele relevante. Aceasta funcie a sistemului se bazeaz pe
autentificarea, autorizarea i criptarea informaiilor intre entiti.

5.7.8. Certificarea informaiilor

Scopul certificrii informaiilor este de a indica entitatea care a creat sau modificat datele i
pentru a putea impune responsabilitatea pentru o aciune, eveniment, opinie, diagnostic, etc.
Fiecare element din dosarul electronic trebuie sa poat fi identificat clar ca fiind creat sau
semnat de ctre autor. Certificarea informaiilor trebuie sa se supun standardelor i cerinelor
legale.
Cerine subsistem de securitate, sigurana i confidenialitate
In locaia finala echipamentele vor prezenta urmtoarele sisteme de sigurana. La nivel fizic,
accesul n sala serverelor va fi protejat folosind sisteme electronice de acces (cartele
magnetice si/sau cod de acces). Distribuirea lor se va face pe baza rolului i a nevoii de acces
a fiecrui operator. Sistemul ce permite accesul n zona serverelor va fi conectat la sistemul
de audit centralizat. Aceast cerin este ndeplinit de ctre operatorul centrului de date unde
este gzduit sistemul.

1.1.1.29. Cerine de operare n centrul de date

o Accesul fizic la rack-ul serverelor este pe baza de cheie. Ofertantul trebuie sa furnizeze
rack-uri cu sistem de nchidere cu cheie
o Accesul la consolele serverelor se va face pe baza de user i parola
o Componentele IT fizice ce susin rularea aplicaiei n condiii optime vor avea alimentare
electrica duala (doua surse de alimentare) i vor fi protejate cu UPS-uri redundante sau n
 configuraie N+1. Timpul de funcionare n sarcina pe baterii a UPS-urilor va fi cu cel
puin 30% mai mare dect timpul necesar opririi n condiii de sigurana a echipamentelor
IT ce deservesc sistemul informatic dar nu mai puin de 20 minute n total.

1.1.1.30. Cerine de securitate a sistemului

Securitatea sistemului este asigurata folosind urmtoarele metode n funcie de nivelul de

acces, astfel:
o La nivel de sistem de stocare, se vor folosi arii de discuri dedicate pentru partiiile logice
ce folosesc date medicale, astfel nct discurile fizice sa conin date medicale sa poat fi
marcate corespunztor.
o La nivel de server, se vor folosi sisteme virtualizate ce ndeplinesc i funcia de izolare a
partiiilor virtuale astfel nct sa nu exista comunicare intre doua partiii prin alte mijloace
dect cele dorite.
o Sistemele de operare folosite vor fi certificate minim EAL4
o La nivelul echipamentelor de comunicaii se va folosi tehnologia VLAN pentru izolarea a
traficului. Echipamente IT din aceeai zona de securitate vor avea VLAN-uri dedicate. O
zona de securitate reprezint echipamentele protejate firewall i ca nu pot fi accesate
dect prin firewall.
o Accesul la sistemele de operare se va face pe baza de cont i parola, i fiecare logare
(conectare) va fi nregistrata n sistemul de audit de platforma. Administratorii de sistem
vor avea fiecare un cont unic i dedicat. Pentru a folosi contul (utilizatorul) cu drepturi
depline, administratorii se vor conecta mai nti cu contul lor unic i dedicat, i apoi vor
comuta ctre contul cu drepturi depline, daca este cazul.
o Transferul datelor intre sistemul central i sistemele externe se va face numai criptat.

1.1.1.31. Confidenialitatea datelor

o Traficul utilizatorilor va trece prin mai multe sisteme de filtrare.

La nivel de reea, traficul va trece prin firewall-uri, IDS, IPS i sisteme de
autentificare i autorizare dedicate. n plus reeaua de date va fi mprit n mai multe
zone (ex: acces internet, DMZ, zona de management i administrare, zona de aplicaii,
zona bazelor de date , zona audit i monitorizare, etc)
La nivel de aplicaie traficul sa fi filtrat folosind metode de genul ReverseProxy i
sisteme tampon (daca acestea sunt compromise se ntrerupe legtura la serverele de
date)
o Beneficiarul datelor medicale (asiguratul medical) va avea acces la informaiile de audit,
prin portal, astfel nct sa poat monitoriza toate accesele efectuate asupra propriului
dosar medical.
o Accesul n sistemul de audit se va face strict pe baza nevoii de cunoatere.

1.1.1.32. Managementul utilizatorilor i accesul la sistem

Pentru asigurarea securitii aplicaiei este nevoie de un sistem solid dar n acelai timp
flexibil care sa permit integrarea mai multor surse de autentificare printre care LDAP i baze
de date. Sistemul trebuie sa fie dimensionat corespunztor pentru a permite stocarea tuturor
utilizatorilor definii n sistem i scalabil pentru a satisface nivelul de performanta cerut.
Autentificarea se va face o singura data pentru toate aplicaiile componente (SSO Single
Sign On). Pentru fiecare utilizator se vor afia doar aplicaiile i informaiile pentru care a
fost autorizat.
Drepturile de acces vor putea fi definite intr-un mo flexibil: cine i ce se poate accesa n
cadrul aplicaiei. Pentru fiecare rol se va putea defini ce resurse pot fi accesate.
La nivel de aplicaie accesele la date vor fi logate n modul who, what, when, indiferent de
modul n care datele sunt accesate, prin portal sau prin sistemele din spital (HIS). Astfel
fiecare informaie medicala i alte informaii ce se vor defini ca fiind private sunt
monitorizate din punct de vedere al accesului (citire, scriere, modificare, etc)
Accesul la datele medicale sau de alta natura cu caracter privat se va face folosind semntura
digitala (att a utilizatorilor individuali prin cardurile de sntate cat i a sistemelor cu care
DES se va integra) pentru a mpiedica negarea aciunilor efectuate asupra datelor
Datele adunate n urma auditrii acestor evenimente vor putea fi vizualizate apoi n cadrul
unor rapoarte. Pe fiecare raport se poate da drept de vizualizare pentru diverse roluri ale
aplicaiei.

5.7.9. Gestiunea nregistrrilor medicale

1.1.1.33. Pstrarea, disponibilitatea i distrugerea datelor

Datele medicale trebuie sa fie pstrate pentru a asigura accesibilitatea i disponibilitatea

acestora. Datele trebuie sa fie stocate i interogate intr-o maniera care sa permit folosirea lor
inteligenta (de exemplu cronologic, dup un anumit diagnostic, etc. sau n concordanta cu
cerinele legale i regulamentele aplicabile).
Datele trebuie pstrate n sistem pentru o perioada de timp stabilita de legislaia curenta.
Dup aceasta data datele se distrug. Sistemul trebuie sa permit identificarea datelor care
trebuie distruse i sa permit evaluarea i aprobarea distrugerii datelor.

1.1.1.34. nregistrri auditabile

Sistemul trebuie sa ofere funcii de audit pentru acces i folosire indicnd autorul,
modificarea care a fost fcuta (atunci cnd este posibil), data i ora la care elementele au fost
create, modificate, vizualizate, extrase sau terse. Trebuie sa fie posibila generarea unor
rapoarte de audit bazate pe aceste date. Toate schimburile de date cu sisteme externe trebuie
sa fie auditate precum i toate activitile care in de securitate.

1.1.1.35. Anonimizarea datelor

Sistemul trebuie sa permit exportul datelor - un mod care s ndeplineasc cerinele de

anonimizare a datelor conform legislaiei i regulamentelor n vigoare. Sistemul trebuie sa
nregistreze toate exporturile de date de acest fel, cu detalii privind cine, ce, de ce i cnd au
fost cerute i exportate aceste date.

5.7.10. Stocarea i gestiunea informaiilor medicale

1.1.1.36. Gestiunea informaiilor nestructurate

Informaiile nestructurate sunt informaii care nu sunt separate n elemente discrete i nu sunt
reprezentate ca date numerice, enumerate sau codificate. Date nestructurate sunt de tip text
introduce de ctre un operator fr structura predefinit. Sistemul trebuie sa fie capabil sa
gestioneze astfel de date adic sa permit nregistrarea, interogarea, tergerea, corectarea,
actualizarea, fie direct fie indirect prin referine la sisteme externe.

1.1.1.37. Gestiunea informaiilor structurate

Informaiile structurate sunt informaii care sunt separate n elemente. Exemple de date
structurate pot include adrese, presiune sanguina (element numeric), observaii codate,
diagnostice, etc.. Sistemul trebuie sa fie capabil sa gestioneze astfel de date adic sa permit
nregistrarea, interogarea, tergerea, corectarea, actualizarea.
5.8. Servicii pentru registre i directoare

Sistemul trebuie sa permit folosirea registrelor de tip registru sau directoare pentru a
identifica n mod unic, localiza, i furniza referine la informaii pentru pacieni i prestatori
de servicii medicale, organizaii din domeniul sntii, resurse i echipamente, etc.
Registrele pot fi interne sau externe; n cazul folosirii unor registre externe sistemul trebuie sa
se poat sincroniza folosind protocoale standard (LDAP, baza de date, etc)
5.9. Interoperabilitate bazata pe standarde

Standardele de interoperabilitate permit DES sa opereze intr-un sistem complex care include
i sisteme externe. Rezultatul este o perspectiva unica a unui sistem care este compus din mai
multe module/subsisteme i comunica cu sisteme externe. Standardele de interoperabilitate
permit partajarea informaiilor intre sisteme de tip EHR, ce da posibilitatea schimburilor de
informaii la nivel naional dar i internaional. Astfel, este promovat accesul la informaie
intr-un mod eficient i rapid pentru utilizatorul final.

5.9.1. Standarde de schimb de date

n general sunt folosite mai multe standarde de schimb de date pentru a ndeplini cerinele de
interoperabilitate cu entiti interne i externe. Este fundamentala existenta unei nelegeri
comune asupra regulilor de conectivitate, structuri de informaii, formate i semantica.
Schimbul de date intre componente interne sau externe trebuie sa aib loc intr-un mod
transparent pentru utilizatorul final. De exemplu schimbul de date care implica introducerea
repetata a acelorai date n sisteme diferite sau copierea datelor manuala de ctre utilizator nu
este acceptabila.
Suportul pentru moduri de interaciune multiple este necesar pentru a rspunde la diverse
tipuri de schimburi de date i nivele de timpi de rspuns.
Terminologiile standard, descrise mai sus, sunt fundamentale pentru schimbul de informaii.
Folosirea unui model informaional specific este necesara pentru optimizarea
interoperabilitii.

5.9.2. Integrarea intre aplicaii bazata pe standarde

Sistemul trebuie sa permit integrarea la nivel de aplicaie cu alte sisteme folosind standarde
recunoscute (exemplu servicii web, etc.).

5.9.3. Acorduri de schimb de date

Sistemul trebuie sa poat fi configurat sa i ajusteze modul de interaciune cu alte sisteme
conform unor acorduri de schimb de date. Regulile impuse de acordurile existente trebuie sa
fie folosite pentru a permite schimbul de mesaje cu sistemele externe. Interaciunea pentru
descoperirea serviciilor de schimb de date trebuie sa se fac intr-un mod standardizat de
exemplu folosind standarde precum UDDI i WSDL.
 5.10. Cerine tehnice generale

o Nu sunt permise pierderi de date la transferul spre baza de date.

o Aplicaia este dezvoltata urmrind o arhitectura n trei straturi (baza de date, logica de
aplicaie, interfaa cu utilizatorul).
o Sistemul informatic propus n cadrul prezentului proiect trebuie proiectat, instalat, testat
i pus n funciune ca un sistem complet integrat, scalabil, deschis, extensibil, flexibil, cu
atribute nalte de securitate i disponibilitate, interoperabil cu alte sisteme informaionale,
prin interfee care vor fi descrise mai jos.
o Utilizarea unei arhitecturi modulare permite o cuplare redusa intre componente i n care
responsabilitile fiecrei componente sunt specializate.
o Structura modulara permite adugarea de noi module fr modificri n modulele
software finalizate.
o Pentru schimbul de date cu alte sisteme se solicita utilizarea de standarde deschise (de ex.
bazate pe XML).
o Sistemul va expune o interfaa bazata pe servicii WEB prin care aplicaiile instituiilor
medicale pot transmite informaie folosind un canal de comunicare sistem la sistem.
o Sistemul propus permite exportul informaiilor stocate n diverse formate (bazate pe
XML).
o Infrastructura hardware trebuie sa includ toate componentele necesare care sa satisfac
cerinele de performanta. Aceast infrastructura trebuie sa conin cel puin:
Sisteme de calcul
Sistem de stocare - storage (SAN)
Sisteme de arhivare secundare, librrie de benzi
Sistem de asigurare continua a energiei electrice
Rack-uri
Infrastructura de reea necesara n cadrul soluiei (ntre componentele ce compun
sistemul propriu-zis)
o Va fi proiectat ca un sistem de nalta performanta i disponibilitate
o Va oferi suport pentru soluii moderne deschise de integrare
o Sistemele i echipamentele livrate trebuie sa fie noi, neutilizate i de ultima generaie. Ele
trebuie sa asigure gradul necesar de performanta, fiabilitate i flexibilitate fiind proiectate
i destinate pentru aplicaii critice enterprise level.
o Dispozitivele hardware trebuie sa fie astfel proiectate nct sa poat asigura scalabilitatea
sistemului n cazul creterii nevoii de putere de calcul.
o Dispozitivele hardware livrate, care au n configuraie posibilitatea de upgrade pentru
anumite componente, trebuie astfel configurate nct upgrade-ul sa se fac fr pierderea
de dispozitive existente.
o Dispozitivele hardware trebuie sa fie compatibile cu caracteristicile reelei electrice din
Romnia astfel nct sa nu existe probleme la conectarea acestora la reeaua electrica.
o Ofertantul va prezenta specificaiile tehnice privind organizarea i amenajarea camerei
serverelor (dataroom / datacenter) n care se vor instala echipamentele astfel nct sa fie
asigurate condiiile operaionale optime pentru funcionarea acestora.
o Ofertantul va preciza care este greutatea totala a echipamentelor livrate i dimensiunile
fizice ale acestora pentru a se putea verifica sigurana instalrii n locaia solicitantului.
o Ofertantul va preciza n oferta care este puterea totala consumata de echipamentele livrate
precum i caracteristicile de climatizare/ventilaie necesare, astfel nct solicitantul sa
poat asigura acest necesar n locaia unde urmeaz a fi instalate echipamentele.
o Implementatorii posibili vor avea n vedere ca toate cerinele i caracteristicile hardware
sunt minime i obligatorii.
o Cerinele nu sunt limitative ofertanii avnd libertatea de a le dezvolta i extinde conform
soluiei pe care o au n vedere. Este aadar necesar ca ofertanii sa propun soluii
complete i integrate, care sa ndeplineasc n totalitate cerinele solicitantului.
o Ofertanii au obligativitatea de include n propunerea tehnica i comerciala toate
componentele hardware, software i de servicii pe care le considera necesare, chiar daca
acestea nu sunt individualizate sau solicitate explicit n documentaia de atribuire cu
condiia explicrii detaliate a funcionalitilor n cadrul construciei arhitecturilor
software i hardware din care sa reias necesitatea lor.

5.10.1. Flexibilitatea sistemului

o Aplicaiile informatice vor trebui sa prezinte un grad important de parametrizare care sa

permit modificri rapide i facile.
o Aplicaiile informatice trebuie sa utilizeze un sistem modern de gestiune al coninutului
care s permit funcii optime de administrare i gestiune a datelor
o Tehnologia cu care va fi gestionata baza de date nu trebuie sa fie dependenta de sistemul
de operare instalat pe servere.

5.10.2. Performanta i disponibilitate

o Sistemul trebuie sa permit stocarea n baza de date, accesul i salvarea pe mediu
secundar de stocare
o Capacitatea de stocare a sistemului trebuie sa poat fi extinsa fr modificarea aplicaiilor
instalate.
o Sistemul trebuie sa permit extinderea numrului de utilizatori suportai i a numrului de
accesri zilnice prin adugarea de hardware suplimentar fr a fi necesare modificri la
nivelul aplicaiei.
o ntreaga soluie centrala trebuie realizata astfel nct sa nu existe nici un punct unic de
avarie (Single Point of Failure).
o Timpul de rspuns al sistemului la nivel de interfaa utilizator nu trebuie sa depeasc 5
secunde pentru 90% din cereri cu excepia operaiilor de logare, generare de rapoarte i a
cutrilor.
o Prin utilizarea unor tehnici avansate de cluster, soluia propusa trebuie sa asigure un nivel
nalt de disponibilitate (availability) i fiabilitate (reliability). Utilizarea tehnicilor
avansate de cluster asigura, pe lng un nivel crescut de scalabilitate i o buna distribuie,
i un nivel ridicat de fiabilitate prin creterea nivelului de tolerana la erori.
o Implementarea unei soluii de Disaster Recovery (DR) la nivelul tuturor sistemelor i
datelor gestionate de CNAS, (inclusiv crearea unui plan i a unor proceduri de replicare
automata a datelor n Centrul DR) este n afara scopului proiectului DES

5.10.3. Date de dimensionare

o Numrul de medici este de aproximativ 50.000, din care 12.000 de medici de familie.
Accesul la portalul DES se va face prin intermediul cardului de sntate
o Portalul DES trebuie sa susin aproximativ 20.000.000 de utilizatori . Fiecare asigurat va
avea acces la portalul DES folosind cardul de sntate. Estimam un numr de 50.000 de
sesiuni concurente.
o Estimam 20.000 de evenimente pe zi generatoare de nregistrri/aciuni tip DMR.

5.11. Funcionaliti expuse de sistemul SIUI prin servicii web

n acest capitol sunt prezentate funcionalitile expuse de sistemul SIUI prin intermediul
serviciilor web.
Detalierea serviciilor i a metodelor expuse de acestea este prezentat pe larg n
Specificaiile de interfaare cu SIUI-Actualizat, documentaie publicata pe Portalul CNAS-
SIUI la adresa http://siui.casan.ro/cnas/siui_2.0/specificatii. Documentaia conine i structura
fiierelor XML specifice fiecarui serviciu Web expus, dar i fiecrui tip de furnizor.

Detalierea serviciilor i a metodelor expuse de acestea, este realizat n Anexele acestui

document.

3. Serviciul pentru sincronizarea nomenclatoarelor

Serviciul permite sincronizarea nomenclatoarelor existente n alte aplicaii cu
nomenclatoarele din SIUI. Aplicaiile de la furnizori vor putea descrca online
nomenclatoarele specifice n urma publicrii unor noi versiuni ale acestora. Aplicaia va afia
un mesaj de avertizare dac detecteaz o versiune mai nou de nomenclatoare, propunnd
sincronizarea acestora.

Sistemul DES si HIS-urile pot interaciona cu acest serviciu Web din perspectiva utilizrii
codurilor din nomenclatoarele standardizate SIUI pentru identificarea semnificaiei datelor cu
caracter medical, dar si a celor cu caracter administrativ, nlesnind astfel utilizarea unui
vocabular comun cu SIUI att pentru sistemul de gestiune pentru Dosarul Electronic de
Sntate, ct i pentru alte sisteme naionale din domeniul sntaii i al asigurrilor de
sntate, cum ar fi Cardul Electronic de Asigurri de Sntate sau Prescripia electronic.

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
existena 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 descrcarea fiierului, iar cel de-al doilea ir reprezint
dimensiunea fiierului care trebuie descrcat.URL-ul va expira la momentul publicrii unei
noi versiuni de nomenclatoare pentru a nu permite aplicaiilor de raportare s descarce
accidental un fiier 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 aplicaia client a datei la care s-a efectuat sincronizare anterioar i prin folosirea acestei
date ca dat de nceput pentru cutare a unei versiuni mai noi a nomenclatoarelor.

4. Serviciul pentru sincronizarea datelor de personalizare

Serviciul va permite sincronizarea datelor de personalizare a aplicaei existente n aplicaiile
furnizorilor cu nomenclatoarele din SIUI. Datele de personalizare se refer la detalii
contractuale, servicii i tarife contractate, liste de nscrii, n funcie de specificul fiecrui tip
de furnizor. Aplicaiile de raportare vor putea descrca online datele de personalizare
specifice n urma actualizrii acestora n SIUI. Aplicaia va afia un mesaj de avertizare dac
detecteaz o versiune mai noua, propunnd sincronizarea datelor.

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 sfrit 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 descrcarea fiierului de personalizare, iar cel de-al
doilea ir reprezint dimensiunea fiierului care trebuie descrcat.

5. Serviciul pentru trimiterea raportrilor periodice

Serviciul permite trimiterea unui fiier de raportare periodic ctre SIUI. La momentul
trimiterii se realizeaz validarea formei i coninutului fiierului, precum verificarea
existenei 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 raportrii i decontul.

Metoda sendReport
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 coninutul fiierului de raportare
arhivat n formatul ZIP (JavaZip) i codat ulterior n formatul Base64.
Dac metoda ntoarce valoareaadevrat, atunci trimiterea raportului s-a fcut cu succes,
altfel trimiterea s-a terminat cu erori. Pe baza mesajului primit n cazul unei erori se poate
determina cauza respingerii raportrii.

Instruciuni de folosire
Numele fiierului XML de raportare trebuie sa respecte formatul:

{Prefix} + "_" + {Cod} + "_" + {Data} + "_" + {Ora} + ".xml"

{Prefix} reprezint un cod de identificare pentru tipul de furnizor, lista complet a acestor
coduri fiind prezentat n tabelul de mai jos.
{Cod} reprezint codul unic de identificare al furnizorului n sistem, codul fiscal, CUI sau
CNP, dup caz.
Parametrii {Data} i {Ora} reprezint data i ora la care a fost efectuat raportarea i trebuie
s apar n formatul "AAAALLZZ" pentru dat i "OOMM", fr nici un separator.
Schema de validare pentru acest fiier este detaliat n anexele corespunztoare fiecrui tip de
furnizor.

6. Serviciul pentru preluarea rezultatelor raportrilor periodice

Serviciul permite preluarea fiierului de rspuns pentru o raportare trimis anterior ctre SIUI
pentru prelucrare. Pentru ca fiierul de rspuns s poate fi descrcat acesta trebuie s fie
salvat ntr-o locaie predefinit pe mediile de stocare ale SIUI, lucru care se efectueaz
automat n urma prelucrrii fiierului de raportare.

Metoda getReportFeedback

String[] getReportFeedback( String fileName )

Metoda are un singur parametru de intrare :

parametrul fileName de tip ir de caractere reprezent numele fiierului de raportare
trimis de aplicaie pentru care se cere rspunsul procesrii.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector
reprezint URL-ul de la care se face descrcarea fiierului, iar cel de-al doilea ir reprezint
dimensiunea fiierului care trebuie descrcat.
Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null.
Aplicaia client trebuie s foloseasc URL-ul rezultat pentru a descrca fiierul cu
nomenclatoarele. Dimensiunea fiierului poate fi folosit pentru a verifica completitudinea
fiierului descrcat. Fiierul descrcat este o arhiv ZIP care conine un fiier XML cu
rezultatul procesrii raportrii n SIUI.
Schema de validare pentru acest fiier este detaliat n anexele corespunztoare fiecrui tip de
furnizor.

7. Serviciul pentru preluarea decontului calculat n SIUI

Serviciu permite obinerea fiierului de decont aferent unei perioade de raportare sau unei
anumite raportri (n baza numrului 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 consultrii de ctre furnizor. Datele de pe
raport nu vor fi preluate n aplicaie.

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 dorete fiierul de decont;
parametrul stop de tip dat calendaristic reprezint data de sfrit a perioadei pentru care
se dorete fiierul 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 descrcarea fiierului de decont, iar cel de-al doilea ir
reprezint dimensiunea fiierului care trebuie descrcat.
Dac nu exist un fiier de decont generat pentru furnizorul respectiv, metoda ntoarce null.

8. Serviciul pentru consultarea cererilor i a deciziilor

Serviciu permite sincronizarea informaiilor 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 rspuns un fiier XML care va conine toate datele necesare
nregistrrii corecte i pre-validrii la nivelul aplicaiei de raportare a serviciilor prestate i a
dispozitivelor medicale eliberate.

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 coninutul fiierului 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 descrcarea fiierului de rspuns, iar cel de-al doilea ir
reprezint dimensiunea fiierului care trebuie descrcat.
Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null.

Instruciuni de folosire
Aplicaia client trebuie s foloseasc URL-ul rezultat pentru a descrca fiierul de rspuns.
Dimensiunea fiierului poate fi folosit pentru a verifica completitudinea fiierului descrcat.
Fiierul descrcat este o arhiv ZIP care conine un fiier XML cu datele referitoare la
deciziile cerute din SIUI.
Numele fiierului XML de cerere trebuie sa respecte formatul:

{Prefix} + "_" + {Cod} + "_" + {Data} + "_" + {Ora} + ".xml"

{Prefix} reprezint un cod de identificare pentru tipul de furnizor, lista complet a acestor
coduri fiind prezentat n tabelul de mai jos.
{Cod} reprezint codul unic de identificare al furnizorului n sistem, CUI sau CNP, dup caz.
Parametrii {Data} i {Ora} reprezint data i ora la care a fost efectuat raportarea i trebuie
s apar n formatul "AAAALLZZ" pentru dat i "OOMM", fr nici un separator.
Schema de validare pentru acest fiier, dar i pentru fiierul de rspuns care conine deciziile,
este detaliat n anexele corespunztoare fiecrei categorii de furnizor.

9. Serviciul pentru verificarea calitii de asigurat

Serviciul permite verificarea calitii de asigurat, prinde ca parametru CNP-ul pacientului.
Serviciul Web trebuie sa trateze situaia in care parametrul furnizat nu se poate valida ca i
CNP, dar i cazul n care CNP-ul nu este nregistrat n sistem. Fiierul XML returnat de
serviciul web va conine cel puin urmtoarele categorii de informaii:
Lista categoriilor active la data interogrii
tampila de timp la momentul emiterii rspunsului
Codul de jurnalizare/auditare al rspunsului
Sistemul DES poate interaciona cu acest serviciu Web pentru verificarea online a strii de
asigurare a unui pacient.

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 dorete
verificarea calitii de asigurat, de exemplu data curent sau data efecturii serviciului.
Metoda ntoarce ca rspuns un ir de caractere reprezentnd coninutul unui fiier n format
XML care conine urmtoarele informaii:
Un cod numeric de rspuns indicnd 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 interogrii
Observaie: n cazul unei erori ntlnite n sistem la procesarea cererii se va ntoarce un cod
numeric de rspuns (-1) precum i o descriere a erorii.

Instruciuni de folosire
Aplicaia de raportare trebuie s proceseze fiierul de rspuns i s afieze un mesaj sugestiv
pentru utilizator cu privire la starea de asigurat a persoanei respective. Dac este cazul
aplicaia va precompleta cmpurile corespunztoare categoriei de asigurat, selectnd
categoria cea mai favorabil pacientului din lista transmis din SIUI.
Este de preferat ca aplicaia de raportare s realizeze validarea de corectitudine a CNP-ului,
algoritmul fiind arhicunoscut, pentru a nu suprancrca sistemul cu cereri inutile.
Schema de validare pentru fiierul de rspuns este detaliat n anexele corespunztoare
fiecrei categorii de furnizor.
 10. Serviciul pentru pre-validarea micrilor de capitaie
Serviciul permite transmiterea ctre SIUI a unei cereri de nscriere/ieire/deces a unui pacient
pe lista unui medic de familie. SIUI va valida cererea prin verificarea respectrii intervalului
de 6 luni de la ultima schimbare de ctre pacient a medicului de familie si va transmite un
rspuns prin serviciul Web ctre medicul de familie in care este trecut rezultatul operaiei.
Trebuie sa fie permis modificarea acestor informaii de ctre medicul de familie pn la
ntocmirea decontului per-capita pentru medicul de familie. Raportrile on-line cu privire la
capitaie au prioritate fa de raportrile batch (fcute la sfritul lunii), existente acum in
SIUI in sensul in care daca nscrierea on-line a unui pacient pe lista unui medic a fost
aprobata, cererea de nscriere a aceluiai pacient pentru alt medic care raporteaz batch va fi
respinsa de SIUI.
Sistemul de Dosar Electronic de Sntate poate interaciona cu acest serviciu Web n cazul n
care medicul de familie dorete s verifice/modifice datele unui pacient, fiind necesar ca
pacientul sa fie nscris pe lista medicului. Se poate verifica online i posibilitatea nscrierii
unui pacient pe lista medicului de familie, dat fiind c normele specifice CNAS prevd o
durat de timp care trebuie s treac pn cnd 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 coninutul fiierului de raportare
n format XML.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care
conine urmtoarele informaii:
O structur similar cu cea raportat, coninnd fiecare identificator de nregistrare
transmis nsoit de starea validrii (validat/nevalidat)
Lista erorilor sau avertizrilor pentru fiecare nregistrare raportat, n caz c acestea au
fost depistate
tampila de timp la momentul emiterii rspunsului

11. Serviciul pentru pre-validarea serviciilor i investigaiilor medicale

Serviciul permite transmiterea serviciile prestate n aplicaie pe msur ce acestea sunt
introduse n aplicaie. Ca regula general, datele transmise la SIUI vor fi validate iar serviciul
Web va ntoarce un rspuns cu privire la rezultatul validrii serviciilor raportate, rspuns 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.
Dosarul Electronic de Sntate poate interaciona cu acest serviciu Web n momentul validrii
unui serviciu.

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

Metoda are doi parametri de intrare:

parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n
format XML.
parametrul reportType de tip ir de caractere reprezint codul tipului de furnizor, lista
valorilor permise fiind prezentat mai jos;
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 reprezentnd fiierul de rspuns n format XML care
conine urmtoarele informaii:
O structur similar cu cea raportat, coninnd fiecare identificator de nregistrare
transmis nsoit de starea validrii (validat/nevalidat)
Lista erorilor sau avertizrilor pentru fiecare nregistrare raportat, n caz c acestea au
fost depistate
tampila de timp la momentul emiterii rspunsului
Coninutul i formatul datelor transmise este specific fiecrui tip de furnizor i va fi descris n
detaliu n anexele care nsoesc acest document. Ca regul general, datele transmise din
aplicaia de raportare ctre SIUI vor fi validate iar serviciul Web va ntoarce un rspuns cu
privire la rezultatul validrii serviciului medical raportat.

12. Serviciul pentru pre-validarea reetelor prescrise de medici

Serviciul permite raportarea de ctre un medic prescriptor a unei reete prescrise. Validarea
corectitudinii ntocmirii reetei se face dup completarea i transmiterea tuturor informaiilor
necesare legate de reet ctre SIUI, care transmite n urma procesrii un mesaj ctre medicul
prescriptor cu privire la corectitudinea reetei n ansamblu, dar i la fiecare medicament n
parte.
Reetele se afl iniial intr-o stare prescris, fiind disponibile spre interogare n farmacii
printr-un apel al serviciului Web dedicat. Modificarea unei reete prescrise se poate face de
ctre medicul prescriptor i numai de ctre el, att timp cat reeta este n starea prescris,
nainte de a trece in starea eliberat.
Dosarul Electronic de Sntate poate folosi metoda de interogare a retetelor existente

Metoda validatePrescription
String validatePrescription(
String reportXml,
String reportType )

Metoda un singur parametru de intrare:

parametrul reportXml de tip ir de caractere reprezint coninutul fiierului 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 reprezentnd fiierul de rspuns n format XML care
conine rezultatul operaiunii de validare.

13. 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 validrii.
Certificatele medicale astfel raportate vor fi stocate ntr-o baz de date pentru realizarea
verificrilor de unicitate a certificatelor medicale i a verificrilor ncruciate conform
normelor n vigoare.
Acest serviciu se adreseaza medicilor care recomanda trimiteri catre specialisti sau
investigatii de laborator. Se poate utiliza in Dosarul Electronic de Sntate.

Acest serviciu va expune dou metode online, una pentru preluarea biletelor de trimitere ctre
medicii specialiti i alta pentru biletele de trimetre ctre investigaii de laborator.
Metoda validateClinicReferral
String validateClinicReferral(
String reportXml,
String reportType )

Metoda un singur parametru de intrare:

parametrul reportXml de tip ir de caractere reprezint coninutul fiierului 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 reprezentnd fiierul de rspuns n format XML care
conine rezultatul operaiunii de validare.

Metoda validateLabReferral
String validateLabReferral(
String reportXml,
String reportType )

Metoda un singur parametru de intrare:

parametrul reportXml de tip ir de caractere reprezint coninutul fiierului 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 reprezentnd fiierul de rspuns n format XML care
conine rezultatul operaiunii de validare.

14. 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 validrii.
Certificatele medicale astfel raportate vor fi stocate ntr-o baz de date pentru realizarea
verificrilor de unicitate a certificatelor medicale i a verificrilor ncruciate conform
normelor n vigoare.
Acest serviciu se adreseaz medicilor care prescriu certificate de concediu medical.
Concediile medicale se vor aduga prin SIUI, iar Dosarul Electronic de Sntate ar putea s
le vizualizeze prin acest serviciu.
Metoda validateSickLeave

String validateSickLeave( String reportXml )

Metoda un singur parametru de intrare:

parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n
format XML.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care
conine rezultatul operaiunii de validare.

15. Serviciul pentru pre-validarea reetelor emise de farmacii

Serviciul permite unei farmacii s valideze medicamentele eliberate n baza unei reete
verificnd compatibilitatea dintre medicamentele prescrise si cele eliberate (calitativ si
cantitativ), pentru fiecare medicament eliberat. SIUI va returna un mesaj prin care farmacistul
este ntiinat despre rezultatul operaiunii de eliberare de medicamente.
O reet poate fi eliberata, total sau parial, de o singura farmacie. Dup eliberare reeta trece
in starea eliberat si nu mai este disponibil pentru alte farmacii. Orice modificare a unei
reete eliberate de ctre o farmacie poate fi fcuta exclusiv de farmacia in cauza. Aceste
modificri trebuie salvate intr-un log pentru posibilitatea consultrii ulterioare.
Dosarul Electronic de Sntate poate folosi metoda de interogare a reetelor existente

Metoda validateFarmacyDrugs

String validateFarmacyDrugs( String reportXml)

Metoda un singur parametru de intrare:

parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de raportare n
format XML.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML.
n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un
mesaj de eroare (o excepie).
Structura fiierul permite transmiterea mai multor nregistrri simultan, de exemplul la cerea
utilizatorului, dup ce acesta a finalizat operarea mai multor reete eliberate, sau n mod
automat la revenirea conexiunii online dup o perioad de lucru offline.
O reet poate fi eliberat, total sau parial, de o singur farmacie. Dup eliberare reeta trece
n starea eliberat i nu mai este disponibil pentru alte farmacii. Orice modificare a unei
reete eliberate de ctre o farmacie poate fi fcut exclusiv de farmacia n cauz. Toate aceste
modificri sunt salvate ntr-un log pentru posibilitatea auditrii ulterioare.

16. Serviciul pentru consultarea reetelor prescrise

Serviciul permite unei farmacii sa vizualizeze reetele prescrise de medici si sa elibereze
medicamentele aferente prescripiei. Transferul de date se va face printr-un serviciu Web in
care este obligatoriu, din motive de confidenialitate, ca farmacia sa completeze seria si
numrul de reeta, dar i CNP-ul pacientului pentru care se elibereaz medicamente. Serviciul
Web va returna suficiente date care sa permit aplicaiei de la farmacie pre-completarea
reetei (medic, pacient, diagnostice, medicaie). Nu vor fi disponibile prin serviciul Web reete
filtrate dup nume sau CNP.
Reetele sunt disponibile pentru interogare din momentul iniial n care se afl n starea
prescris, pn la trecerea n starea eliberat. Ulterior, o alt farmacie care interogheaz
informaiile legate de reeta respectiv va primi un mesaj c reeta a fost deja eliberat,
prevenind astfel dubla eliberare a unei reete.

Dosarul Electronic de Sntate ar putea interaciona cu acest serviciu Web pentru interogarea
reetelor. Acest serviciu permite includerea informaiilor specifice Dosarului Electronic de
Sntate i Sistemului de Prescripie Electronic prin simpla extindere a setului de date
schimbate ntre SIUI i sistemele externe cu un set de cmpuri corespunztor.

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 reetei;
parametrul number de tip ir de caractere reprezint numrul reetei;
parametrul pid de tip ir de caractere reprezint CNP-ul beneficiarului reetei;
parametrul stencil de tip ir de caractere reprezint numrul de paraf al medicului
emitent;
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML.
Aplicaiile de raportare vor avea posibilitatea de implementare a unor funcionaliti de
preluare automat a coninutului acestor documente n format electronic ctre SIUI. Astfel o
farmacie poate apela serviciul Web pentru a descrca o reet prescris n scopul de a elibera
medicamentele aferente.

17. Serviciul pentru consultarea biletelor de trimitere

Acest serviciu este folosit pentru consultarea biletelor de trimitere pentru specialiti clinice
sau investigaii de laborator validate de SIUI de ctre 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 confidenialitate, ca furnizorul s
completeze seria i numrul 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.
Acest serviciu poate fi folosit de Dosarul Electronic de Sntate pentru consultarea biletelor
de trimitere

Acest serviciu expune dou metode, una pentru consultarea trimiterilor ctre medicii
specialiti i cealalt pentru laboratoare.

Metoda getClinicReferral
String getClinicReferral (
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 numrul 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 numrul de paraf al medicului
emitent;
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns 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 numrul 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 numrul de paraf al medicului
emitent;
Metoda ntoarce ir de caractere reprezentnd fiierul de rspuns n format XML.

5.11.1. Fluxuri de date ntre componente

Prezentarea detaliata a serviciilor web expuse de sistemul SIUI este detaliat in anexele acestui
document:
Definitiile serviciilor web expuse de sistemul SIUI
Anexa 1 Fiiere XSD pentru raportare, personalizare, nomenclatoare i alte
sincronizri de date
Anexa 2 Fiiere XSD pentru pentru prevalidare online a serviciilor i
verificare a calitatii de asigurat
Anexa 3 Fiiere WSDL pentru definiiile serviciilor Web
Anexa 4 Specificaii de interfaare cu SIUI-Actualizat
Anexa 001 - Descrierea serviciilor Web expuse
Anexa 002 - Farmacii cu circuit deschis
Anexa 003 - Farmacii cu circuit nchis
Anexa 004 Spitale
Anexa 005 - Programe Naionale de Sntate
Anexa 006 - Medicin de familie si asisten medicala primara
Anexa 007 - Ambulatoriu de specialitate si specialitati clinice
Anexa 008 - Servicii paraclinice i investigaii de laborator
Anexa 009 - Servicii stomatologice i de medicin dentara
Anexa 010 - Aplicaii de raportare pentru certificatele de concediu
medical
Anexa 011 - Servicii de recuperare ambulatorie
Anexa 012 - Servicii de recuperare n sanatorii i preventorii
Anexa 013 - Furnizori de dispozitive medicale pentru recuperarea
deficientelor
Anexa 014 - Servicii de ngrijire la domiciliu
Anexa 015 - Asisten medical de urgen si transport sanitar
Anexa 016 - Furnizori de servicii de dializ
 5.11.2. Raportrile SIUI

Medicina de Familie
o medicul are obligatia sa raporteze la CNAS pentru decontarea serviciilor (cf. contractului
incheiat cu CNAS)
o ce raporteaza:
- per capita (inscrisi):
- alergii
- miscari pe categorii de asigurati
- boli cronice
- evidenta intr-un PNS
- rude de gr. I
- servicii medicale
- imunizari
- servicii pentru luarea in evidenta a gravidelor/lehuzelor
- retete
- bilete de trimitere la specialisti
- bolnavi cronici
o dpdv EHR, acestea sunt datele cu relevanta in proiect

Spitale
- raportarile se impart in 2 categorii: sintetice si analitice
o sintetice:
- se raporteaza numarul de cazuri per sectie de spital (centralizat), se pot
raporta retete, trimiteri in ambulatoriu, recomandari pentru ingrijiri la domiciliu si dispozitive
medicale (nu sunt obligatorii, dar sunt prevazute);
- este obligatorie lista de pacienti, cu foaia de observatie, date de internare si
externare, criterii de internare, cu detaliu pe procedurile medicale de care a beneficiat
pacientul
o analitice:
 - se raporteaza detaliat pe pacient, se pot raporta retete, trimiteri in
ambulatoriu, recomandari pentru ingrijiri la domiciliu si dispozitive medicale (nu sunt
obligatorii, dar sunt prevazute);
- se raporteaza pe pacient, cu foaia de observatie, date de internare si
externare, criterii de internare, criterii de internare, diagnostic la internare
- dpdv EHR, datele cu relevanta in proiect sunt incomplete, nu contin toate datele de pe foaia
de observatie

5.11.3. Nomenclatoare - cataloage SIUI

In SIUI exista un numar de nomenclatoare care pot fi folosite in EHR:

o Persoane inregistrate (contin si persoanele asigurate)
o Furnizori de servicii medicale (spitale, cabinete de medicina de familei, clinice,
stomatologice, farmacii, etc) diverse informatii: adrese, personal angajat, puncte de
lucru,
o Tari
o Judete
o Localitati
o Strazi
o Casele judetene de asigurari de sanatate
o Substantele active
o Bolile cronice
o Categoriile de boli
o Medicamentele
o Valute
o Alergii
o Diagnostice (ICD10 si CIM)
o La nivelul spitalelor:
o catalog investigatii medicale
o diagnostice secundare
o sumarizare cazuri rezolvate in spitalizare de zi
o sumarizare servicii rezolvate in spitalizare de zi
o spitalizari
o cazuri rezolvate in spitalizare de zi
o centralizatoarele pentru spitalizarea de acuti
o centralizatoarele pentru spitalizarea de cronici
o centralizatoarele pentru spitalizarea DRG
o centralizatoarele pentru spitalizare servicii paliative
o servicii spitalizare de zi
o retete raportate la spital
o persoane straine raportate la spital
o recomandari pt ingrijiri la domiciliu
o bilete de trimitere raportate la spitale
o erori la dispozitivele medicale raportate la spitale
o proceduri
o internari
o La nivelul medicilor de familie:
o Lista persoanelor inscrise la MF
o Lista de retete emise raportate de MF
o Lista de medicamente de pe retetele emise raportate de MF
o Bolnavi cronici raportati de medici
o Investigatii raportate de medici
o Servicii medicale generale raportate de medicul de familie
o Servicii de imunizare raportate de medicul de familie
o Servicii medicale pentru gravide raportate de medicul de familie

Obs:Este doar o parte a informatiilor, se poate obtine o lista mult mai detaliata

5.11.4. Integrri SIUI

o Pacient
 - Plata contributiei la CAS (neasiguratii din alte categorii)

Flux:

Definirea contribuabilului, conform documentelor

Conform Legii 95 /2006, fiecare persoana fizica realizatoare de venit pe teritoriul Romaniei,
este obligata sa contribuie la plata contributiei de asigurari sociale de sanatate pentru
formarea Fondului national unic de asigurari sociale de sanatate.
In vederea efectuarii platilor stabilite conform legii pentru contributia la Fondul de sanatate,
contribuabilul se prezinta la sediul Casei de Sanatate la care este afiliat, pentru inregistrarea
datelor legate de categoria (sau categoriile) de venituri pe care le realizeaza.
Pe baza CNP-ului existent in cartea de identitate (sau altor informatii personale din pasaport,
in cazul unui cetatean strain fara CNP), se defineste mai intai contribuabilul, care se
inregistreaza in sistem ca o asociere intre codul personal si categoria de contributie conform
venitului realizat. Astfel, pentru un cod personal, pot exista in sistem unul sau mai multi
contribuabili.
Pentru situatiile in care contribuabilul nu se prezinta benevol la sediul Casei de sanatate la
care este afiliat, se pot desfasura actiuni de coercitie, cum ar fi executarea silita. Conform
Protocolului incheiat intre Casa Nationala de Sanatate (CNAS) si Agentia Nationala de
Administratie Fiscala (ANAF), aceasta din urma furnizeaza Casei de sanatate informatii
depre toate persoanele realizatoare de venit, informatii pe baza carora aceasta poate emite
Decizii de impunere cu titlu de creanta, pe baza carora poate demara actiuni de executare
silita.
Adaugarea declaratiilor corespunzatoare categoriei de contribuabil, conform
documentelor
Dupa definirea contribuabilului in sistem, inspectorul de la ghiseu va solicita documente
legate de veniturile realizate pentru categoria respective de venituri, conform legii.
Contribuabilul va complete formularul de Declaratie Privind obligatiile de constituire si plata
la Fondul National Unic de Asigurari Sociale de Sanatate, conform Anexei 5 din Ordinul
617 / 2007.
Pe baza Declaratiilor de obligatii (cate o declarative pentru fiecare an), se vor inregistra in
sistem veniturile, dupa care sistemul va calcul contributiile aferente si datele scadente,
conform unor sabloane definite pentru fiecare categorie de contribuabil.
Generarea calculului de datorie
Odata introduse in sistem debitele, inspectorul va efectua cu ajutorul sistemului SIUI calculul
contributiei. Acesta va stabili impreuna cu contribuabilul perioada pe care acesta vrea sa
plateasca, ce anume doreste sa achite (contributii si/sau majorari) si daca are nevoie de
Dispozitii de plata separate (de exemplu pentru deducerea anumitor cheltuieli), caz in care se
vor efectua mai multe calcule de datorie pe perioade distincte.
Trimiterea in ERP a calculului de datorie si generarea Deciziei de incasare
Pentru a putea efectua incasarea de la contribuabil, inspectorul va trimite in ERP toate
informatiile legate de sumele de plata rezultate in urma calculului de datorie.
In baza informatiilor de plata, se va genera in ERP un document numit Decizie de incasare,
document care poate fi folosit pentru efectuarea platii. In acest caz insa, operarea sumelor de
plata se va face pozitie cu pozitie, de aceea este recomandabil sa se genereze si o Dispozitie
de incasare.
Generarea Dispozitiei de incasare in SIUI si trimiterea acesteia in ERP
Dispozitia de incasare se genereaza in SIUI pe baza informatiilor cuprinse pe documentul de
Decizie de incasare. Inspectorul poate modifica suma pe care contribuabilul o va plati efectiv
(in cazul in care acesta nu dispune de intreaga suma de plata).
Dupa completarea (modificarea) tuturor informatiilor legate de sumele care se vor plati
efectiv si a descrierii, inspectorul va trimite in ERP Dispozitia de plata. De asemenea, va lista
Dispozitia de incasare, pe care o va da contribuabilului.
Contribuabilul se prezinta la casierie pentru efectuarea platii
Avand Dispozitia de incasare, contribuabilul se va prezenta la ghiseul casieriei, pentru
efectuarea platii.
In cazul in care contribuabilul se razgandeste, si nu mai efectueaza plata, Decizia de incasare
generata in ERP se va storna automat in ziua urmatoare.
Exista de asemenea pozibilitatea ca Dispozitia de incasare sa fie emisa la o data ulterioara (cu
calculul de majorari facut la acea data), pentru situatiile in care contribuabilul doreste sa vina
peste cateva zile sa plateasca si nu mai doreste sa treaca pe la ghiseu pentru efectuarea
calculului de datorie.
Incasarea efectuata este transferata in SIUI
Toate incasarile efectuate in ERP se transfera ulterior in SIUI. Acest lucru se efectueaza de
regula dupa inchiderea registrului de casa din ziua respective si efectuarea tuturor
verificarilor. Exista si situatii speciale, de exemplul pentru emiterea unei adeverinte de
asigurat, pentru care este nevoie ca in sistem sa se faca preluarea operatiunilor din ERP
pentru acel contribuabil.
 - Obtinerea calitatii de asigurat
Flux:
o Persoana se prezinta la casa cu documente care ii atesta calitatea actuala de asigurat
precum si identitatea proprie.
o Dupa verificarea acestora si a informatiile deja existente se actualizeaza informatiile dupa
caz sau se elibereaza adeverinta de asigurat.
o Utilizatorul CJAS genereaza adeverinta de asigurat. Adeverinta de asigurat este un
document generat automat de sistem in baza informatiilor existente.
o
o Medic
- Incheiere contract/aditional
Flux general contractare:

o Furnizorul se prezinta la sediul CJAS

o Furnizorul trebuie sa prezinte documentele necesare contractarii atat pentru furnizor cat si
pentru persoanele care intra in contract
o Utilizatorul de la CJAS inregistreaza un nou contract
o La crearea contractului se stabilesc valorile contractate care in functie de tipul de contract
se verifica sa se incadreze in bugetele respective
o In functie de tipul contractului incheiat numarul si tipul documentelor difera, dar ca
exemplu ar fi ( Act constitutiv/Act de infiintare, Autorizatie sanitara de functionare,
Dovada de evaluare, Dovada platii contributiei la FNUASS ).
o Pentru orice modificare a contractului (crestere/diminuare valoare contract, modificare
nume furnizor/subcontractori, adresa furnizor, cont bancar furnizor, persoane noi pe
contract, scoatere persoane pe contract) se face prin act aditional semnat de ambele parti
o In cazul in care documentele necesare contractarii expira inaintea terminarii contractului,
acesta se suspenda partial (doar pentru persoanele carora le-au expirat documentele) sau
total (in cazul in care documentele expirate sunt ale furnizorului).
o La sfarsitul perioadei contractele inceteaza sau pot fi prelungite prin aditionale, cu
acordul ambelor parti.
o In cazul in care una dintre parti nu respecta termenii contractuali contractele se reziliaza.
o Obtinere personalizare - In vederea raportarii electronice serviciilor medicale, furnizorul
are nevoie de datele contractual in format electronic, date furnizate de catre casa
judeteana sub forma unui fisier de personalizare in format xml. Acesta contine:
- Datele furnizorului: cod de inregistare fiscala, denumire, adresa, numar contract,
tip contract, datele de inceput si sfarsit ale contractului;
- Datele angajatilor (medici, asistenti, personal conex): nume, cnp, coduri de parafe,
specialitati;
- Codurile serviciilor, cantitatile acestora (in cazul furnizorilor de servicii
paraclinice) si valorile contractate (la toate tipurile de contracte la care decontarea
se face dintr-un buget annual)

o Obtinere nomenclatoare- In vederea raportarii electronice serviciilor medicale, furnizorul

are nevoie de nomeclatoarele si cataloagele casei judetene, date furnizate sub forma unui
fisier in format xml. Acesta contine, printer altele:
- Catalog de tari;
- Catalog de judete;
- Catalog de orase;
- Catalog de strazi;
- Catalog de structuri organizatorice;
- Catalogul caselor judetene;
- Nomenclator de forme farmaceutice;
- Nomenclator de concentratii;
- Nomenclator de specialitati;
- Nomenclator de grade profesionale;
- Catalog de reguli de validare;
- Catalog de categorii de personae;
- Catalog de medici;
- Nomenclator de categorii de boli;
- Nomenclagor de boli;
- Nomenclator de substante active;
- Catalog de medicamente;
- Nomenclator de grupe de spacialitati;
 - Nomenclator de servicii medicale (clinice, paraclinice, stomatologice, etc.) dupa
tipul furnizorului;
- Nomenclator de servicii pe pachete medicale si tarife;
- Nomenclator de boli cronice, etc.
o Raportare cf legii + rapoarte cerute prin lege - Furnizorii de servicii medicale, odata ce au
incheiat contract cu casa judeteana, pot raporta serviciile medicale efectuate in luna
respectiva, cu obligatia de a se incardra in perioada de raportare stabilita prin lege (de
obicei cateva zile la inceputul lunii urmatoare celei in care au efectuat serviciile) . Acestia
pot transmite (offline, pe medii electronice), sau online (prin internet, folosind certificate
digitale de autentificare) fisiere xml care contin printre altele:
- CNP pacient;
- Cod serviciu;
- Pachet medical;
- Tariff serviciu;
- Cantitate serviciu;
- Parafa medic;
- Specialitate medic;
- Serie, numar si data bilet de trimitere;
- Parafa medic bilet de trimitere;
- Numar si data registru medical;
- Diagnostic initial sau confirmat;
- Tip boala (acuta, subacuta sau cronica), etc.
o Odata incarcata si procesata in sistem, raportarea este verificata sa se incadreze in
plafonul lunar de pe contract (acolo unde este cazul); daca nu se incadreaza sistemul
returneaza mesaj de eroare si nu proceseaza raportarea.
o Serviciile raportate sunt verificate cu ajutorul unui set de reguli de business; serviciile
care nu respecta aceste reguli capata starea respins celelalte capatand starea validat.
Starea raportarii estte in lucru
o Furniozrul poate face corectii asupra fisierului xml de raportare si-l poate retrimite, insa
operatorul casei judetene trebuie sa stearga raportarea veche si a proceseze fisierul cel
nou.
 Odata cu raportarea, furnizorul trebuie sa prezinte casei judetene un set de rapoarte
(legate de serviciile raportare pe pacienti si medici, tarife, cantitati, valori) cerute de
normele in vigoare, impreuna cu facture spre decontare.

o Feed-back raportare- Sistemul genereaza un fisier de feed-back in format xml, care va fi

transmis furnizorului. Acesta contine:
- Numarul total de servicii procesate, servicii validate si invalidate;
- Mesajele de eroare pentru serviciile invalidate

- Decont-factura-ordonantare
Odata procesul de raportare si corectii fiind incheiat, operatorul casei judetene poate
inchide raportarea (aceasta capata starea procesat). Apoi operatorul poate genera facture
si decontul. Odata decontul generat raportarea va trece in starea calculat Daca exista
servicii ramase in starea respins vor fi diferente intre factura si decont, caz in care
operatorul va genera nota de refuz, pe care o va trimite impreuna cu decontul furnizorului,
iar acesta are datoria de a emite factura de stornare in valoare egala cu cea din nota de
refuz.
Apoi operatorul casei judetene va ordonanta la plata valoarea decontului.
o
Asigurator/CNAS
o Gestionare nomenclatoare utilizatorii CNAS (si in unele cazuri CJAS) administreaza
(adauga/modifica/sterg) informatiile din nomenclatoare si cataloage. Acestea pot fi de mai
multe tipuri:
- Nomenclatoare generale: tari, strazi, valute, etc
- Nomenclatoare medicale: servicii, medicamente, boli, etc

o Rapoarte centralizatoare utilizatorii CJAS/CNAS pot scoate diverse rapoarte pe baza

informatiilor din sistem la nivel judetean sau national

o Gestionare contracte fiecare furnizor trebuie sa incheie un contract cu CNAS/CJAS

pentru a putea deconta serviciile permise prin lege

Flux general contractare:

 Furnizorul se prezinta la sediul CJAS
Furnizorul trebuie sa prezinte documentele necesare contractarii atat pentru furnizor cat si
pentru persoanele care intra in contract
Utilizatorul de la CJAS inregistreaza un nou contract
La crearea contractului se stabilesc valorile contractate care in functie de tipul de contract
se verifica sa se incadreze in bugetele respective
In functie de tipul contractului incheiat numarul si tipul documentelor difera, dar ca
exemplu ar fi ( Act constitutiv/Act de infiintare, Autorizatie sanitara de functionare,
Dovada de evaluare, Dovada platii contributiei la FNUASS ).
Pentru orice modificare a contractului (crestere/diminuare valoare contract, modificare
nume furnizor/subcontractori, adresa furnizor, cont bancar furnizor, persoane noi pe
contract, scoatere persoane pe contract) se face prin act aditional semnat de ambele parti
In cazul in care documentele necesare contractarii expira inaintea terminarii contractului,
acesta se suspenda partial (doar pentru persoanele carora le-au expirat documentele) sau
total (in cazul in care documentele expirate sunt ale furnizorului).
La sfarsitul perioadei contractele inceteaza sau pot fi prelungite prin aditionale, cu
acordul ambelor parti.
In cazul in care una dintre parti nu respecta termenii contractuali contractele se reziliaza.
- Generare deconturi-facturi-ordonantari

MS
- Trimite lista de preturi pentru listele de medicamente
Flux:
Ministerul Sanatatii actualizeaza Catalogul National al preturilor medicamentelor de uz
uman autorizate de punere pe piata in Romania. Fisierul care cuprinde aceste informatii se
numeste CANAMED. Pentru fiecare cod de medicament sunt specificate preturile
maximale de vanzare cu amanuntul si en-gross.
Fisierul este importat de user-ul CNAS prin interfata aplicatiei SIUI. In baza acestor
preturi, CNAS genereaza Lista medicamentelor de care beneficieaza asiguratii in
tratamentul ambulatoriu, cu sau fara contributie personala pe baza de prescriptie medicala
in sistemul de asigurari sociale de sanatate.
o SNSPMS - In momentul de fata validarile Scolii Nationale sunt numai pentru spitalizarea
continua. (Scoala nationala tine de MS)

Flux:
Lunar spitalul poate raporta activitatea pentru prima parte a lunii (perioada 1-15 se poate
raporta in perioada 16-20 a fiecarei luni) sau luna intreaga. In primele 5 zile lucratoare
spitalul raporteaza cazurile rezolvate externate in luna anterioara atat la Casa Judeteana de
Asigurari de Sanatate cat si la Scoala Nationala (SNSPMS). Dupa inchiderea perioadei de
raportare CAS deconteaza spitalului toate cazurile raportate (validate de SIUI), cu
incadrare in contract.
Dupa data de 20 a fiecarei luni Scoala Nationala trimite spitalului validarea cazurilor
raportate de acesta. Totodata Scoala Nationala trimite si CAS o raportare care contine
cazurile raportate de spital si starea acestora: validat sau respins. CAS tine cont de
raportarea primita de la SNSPMS la decontul lunii urmatoare, cand din valoarea realizata
scade cazurile invalidate in luna precedenta.
Spitalul poate contesta invalidarea Scolii Nationale sau in unele cazuri sa ceara
revalizarea cazurilor daca este eroare de operare (datele trimise erau incomplete sau
incorrect transcrise din foaia de observatie). Toate cazurile revalidate de Scoala Nationala
se transmit la CAS trimestrial, la regularizare. Tot atunci se pot transmite si cazuri care au
fost omise la raportarea lunara

5.12. Fluxuri de date intre componente

5.12.1. Fluxuri de execuie SOA (Service Oriented

Architecture)
Componentele de Integrare Aplicaii, Registrul de Servicii i Serverul de Procese sunt
necesare ca infrastructura pentru execuia de fluxuri specifice SOA (Service Oriented
Architecture).
Aceasta infrastructura trebuie sa constituie o baza solida i n acelai timp flexibila pentru
cerinele operaionale ale sistemului integrat.
Sistemul integrat DES trebuie sa permit comunicaia performanta intre oricare aceste
sisteme.
Astfel, de exemplu, aciunea unui utilizator al portalului sau o comanda automata din
partea unui sistem extern cu care sistemul de DES se integreaz, vor trebui fie sa poat
 declana un flux de proces gestionat de Serverul de Procese, fie sa poat apela un serviciu
al crui ciclu de viata este gestionat intern de sistemul DES.
In cazul declanrii procesului, Serverul de Procese va juca rol de consumator de servicii,
pe care le va apela folosind Componenta de Integrare Aplicaii cu rol de mediator fata de
componenta aplicativa ce furnizeaz serviciul respectiv.
In cazul n care n care inta cererii este un serviciu, apelul va fi preluat de Componenta
de Integrare Aplicaii.
In ambele cazuri, Componenta de Integrare Aplicaii va identifica referina i starea
serviciului apelat prin intermediul Registrului de Servicii.
Odat identificata referina i disponibilitatea serviciului, apelul va fi naintat de ctre
Componenta de Integrare Aplicaii ctre componenta aplicativa ce implementeaz
serviciul respectiv.
Server-ul de Procese va trebui sa exploateze att servicii interne (furnizate de ctre
componente aplicative din domeniul de securitate intern), cat i servicii oferite de ctre
sistemele externe (de exemplu de tip HIS, etc.).
Soluia trebuie sa fie compatibila cu dezvoltarea de module SCA (Service Component
Architecture) ca mecanism de dezvoltare ulterioara a arhitecturii SOA.

5.12.2. Fluxuri de autorizare i autentificare

Fluxul de autorizare i autentificare se bazeaz pe interaciuni intre gateway-ul de
securitate, componenta de administrare al utilizatorilor i drepturilor de acces i sistemele
aplicative din back-end.
In cazul interceptrii unei cereri neautentificate la nivel HTTP ctre o resursa protejata,
sistemul va trebui sa ofere utilizatorului posibilitatea introducerii de date de identificare
(nume de utilizator i parola).
Odat introduse, sistemul va confrunta aceste valori cu cele stocate n componenta de
administrare a utilizatorilor. n cazul n care datele de identificare se regsesc n acesta,
sistemul va trebui sa valideze rolul utilizatorului respectiv fata de politicile de acces
asociate URL-ului respectiv pentru a i se permite accesul la acea resursa.
Cererile deja autentificate vor fi recunoscute ca atare de ctre gateway-ul de securitate pe
baza gestionarii unui identificator de sesiune.
Autentificarea pe baza de certificat digital se va realiza prin interogarea de ctre gateway-
ul de securitate, prin intermediul protocolului OCSP (Online Certificate Status Protocol),
 a infrastructurii de chei publice oferite de ctre o platforma de tip CA (Certificate
Authority), oferind informaii despre validitatea certificatului digital.
In cazul n care oricare din validrile de mai sus va ntoarce rezultat negativ, accesul
utilizatorului va fi blocat.

5.12.3. Fluxuri de suport pentru funcionalitatea de raportare

Fluxul de suport pentru funcionalitatea de raportare se bazeaz pe patru elemente: Baza
de Date Operaionala, Componenta de Integrare Date, Componenta de Data Warehouse i
Componenta de Raportare.
Fluxul pentru crearea i actualizarea componentei de Data Warehouse se va realiza prin
intermediul componentei de integrare de date (ETL, Extract-Transform-Load), avnd
capacitatea de conectare la surse de date eterogene.
Cu ajutorul acestei componente se vor putea crea fluxuri de preluare a informaiei din
sursele tranzacionale, putndu-se astfel realiza transferul datelor i transformarea
formatului acestora conform cu necesitile sistemului de raportare.
Pentru partea de modelare i creare a nivelului de Data Warehouse se va folosi un
instrument specializat ce va pune la dispoziia administratorilor, prin intermediul unei
interfee vizuale, a elementelor de analiza i definire a modelului de date al sistemului de
Data Warehouse.
Ca secvena urmtoare n flux, componenta de Data Warehouse va fi folosita ca sursa
primara de date pentru componenta de analiza i raportare ce va pune la dispoziia
analitilor de raportare posibilitatea definirii de indicatori de performanta, avnd ca baza
modelul de date al Data Warehouse, precum i o paleta predefinit de criterii posibile de
raportare.
Componenta de raportare va interaciona cu utilizatorii finali prin instrumente de analiza,
raportare i dash-boarding.

5.12.4. Fluxuri de procesare a evenimentelor de monitorizare

Componenta de Help-Desk trebuie sa permit att utilizatorilor publici nregistrai ct i
personalului intern dedicat pentru operaiuni de suport, sa poat nregistra cererile de
suport sub forma de ordine de lucru (tickets).
Deasemenea, componenta de Help Desk trebuie sa se integreze sincron cu componenta
de monitorizare astfel nct alertele generate de primul sa se nregistreze automat n
modulul de Help Desk ca ordine de lucru pentru echipa de suport i avnd asociat un
numr de identificare.
 Sincronizarea trebuie sa aib loc automat n ambele sensuri, astfel nct la nchiderea unui
caz de ctre personalul de suport n modulul de Help Desk, alerta sa fie nchisa i n
componenta de monitorizare.

5.12.5. Cerine subsistem de integrare

Obiectivul integrrii la nivel de aplicaie este de a furniza diferitelor aplicaii existente
posibilitatea de a interopera i schimba date.
Una dintre cele mai cunoscute arhitecturi IT, care asigura integrarea corelata a mai
multor sisteme diferite din punct de vedere tehnologic sau al structurilor de date, este aa-
numita Service Oriented Architecture (SOA).
Arhitectura orientata pe Servicii (SOA) divide aplicaiile monolitice n seturi de servicii
care executa funcii bine definite i sunt disponibile pentru toi utilizatorii. Aceste servicii
pot fi utilizate folosind protocoale standard care asigura accesibilitatea att pe plan intern
(al aplicaiei) cit i extern. n continuare sunt descrise mecanismele de baza necesare
pentru integrarea aplicaiilor informatice existente, care vor fi luate n considerare n
dezvoltarea arhitecturii tehnice a DES.
Servicii Web XML
Serviciul Web este componenta software care furnizeaz interoperabilitatea cu alte
componente folosind protocoale Internet (inclusiv HTTP/HTTPS). Serviciile Web XML
poseda multe dintre caracteristicile care sunt necesare pentru punerea n aplicare a
arhitecturii orientate spre servicii (SOA).
Serviciile Web XML folosesc standardul SOAP. SOAP este bazat pe limbajul XML, este
independent de platforma sau limbaje software specifice i suporta multiple protocoale de
transport, care asigura conectivitatea n cadrul organizaiei sau cu alte organizaii prin
Internet. nregistrarea i cutarea de servicii Web este asigurata cu ajutorul UDDI
(Universal Description, Discovery and Integration), pentru registrele de servicii i WSDL
(Web Services Description Language) pentru descrierea fiecrui serviciu.
Orice interconectare ntre diferite aplicaii trebui sa fie realizata folosind Servicii Web
XML. Metoda tradiional de integrare la nivel de date, n care o aplicaie creeaz sau
acceseaz nregistrri direct n baza de date a altei aplicaii nu este acceptabil. Acesta
duce la crearea de aplicaii foarte dependente reciproc, ceea ce nu corespunde cu liniile
directoare ale arhitecturii orientate spre servicii.
Servicii de infrastructura
 Dei serviciile Web XML furnizeaz un nivel de baza, pentru punerea n aplicarea
necesitailor SOA sunt necesare componente de nivel superior care sunt accesate de toate
aplicaiile i serviciile. De exemplu, componentele care furnizeaz servicii de
infrastructura i de automatizare a proceselor de business.
Serviciile de infrastructura furnizeaz aplicaiilor, sau altor servicii, servicii de baza care
nu depind de utilizri specifice sau funcii de business. Pot fi menionate ca exemple :
servicii de securitate, funcii de analiza i monitorizare, brokeri de mesaje, mecanismul de
transmitere mesaj, funciile administrative, jurnalizare de date, prelucrarea situaiilor
excepionale, precum i registrele de servicii i de cutare.
Ca minim de servicii implementate, se cer servicii de securitate comune pentru toate
aplicaiile, ceea ce ofer mecanisme de autentificare unificate, de autorizare i de audit al
operaiunilor.
Mesaje XML
Tehnologiile bazate pe mesaje asigura un nivel ridicat de scalabilitate i robustee. Aceste
tehnologii permit integrarea rapida i non-limitativa a aplicaiilor care folosesc metode de
transmitere i consum al mesajelor standard. O aplicaie tipica transmite mesajul cerere
ctre alta aplicaie i continua operaiunea, fr a atepta ca mesajul sa ajung la
destinaie sau sa primeasc rspuns.
n acest caz, operaiunea curenta nu este blocata n ateptarea rspunsului. Aceasta
abordare este adecvata n special cazul n care exista necesitatea de a automatiza
procesele care constau n mai multe etape i a tranzaciilor care au o durata medie mare.
De exemplu, pentru o aplicaie de tip front-office intr-o instituie medicala care primete
o depunere de document sau solicitare de la pacient, utiliznd tehnologii bazate pe
mesaje, trimite asincron acest document la sistemul de back-office i continua sa execute
operaiunile sale curente. Acest mesaj poate fi transmis la sistemul de automatizare a
proceselor de business, care n continuare gestioneaz i controleaz acest proces pana
cnd este efectuat. Atunci cnd procesul este finalizat, sistem de back-office trimite un
mesaj de rspuns napoi la aplicaia front-office. Dup cum s-a menionat anterior, pentru
a asigura schimbul eficient de date ntre diferitele aplicaii ce funcioneaz n sistemul
medical, acestea vor fi organizate cu ajutorul unui hub centralizat de date/de integrare.
Platforma de integrare trebuie sa ofere urmtoarele funcii:
Servicii de identificare i de securitate. Grup de servicii care ofer funcia de identificare
a utilizatorului, mecanisme de autentificare i autorizare, extrem de importante pentru a
garanta confidenialitatea datele pacienilor (acces numai pentru utilizatorii autorizai).
 Cardurile electronice de asigurri de sntate urmeaz sa fie utilizate pentru identificarea
utilizatorului i autentificarea sa n sistem;
Servicii de transmitere mesaje. Grup de servicii care asigura transmiterea sincrona i
asincrona de mesaje, precum i rutarea i testarea integritii acestora.
Servicii de tip aplicaie de business. n mod centralizat, pot fi implementate mai multe
servicii de business comune care sunt folosite de mai multe aplicaii - de exemplu,
decontare de plai, trimiterea de mail securizat i semnat electronic, seif electronic, etc;
Interfee cu alte sisteme conexe de eSntate. Interfee speciale pot fi stabilite cu
sistemele existente sau ce vor fi dezvoltate n domeniul eSntii
Platforma de integrare va fi dezvoltata pe baza unei soluiile tehnologice existente pe
piaa, testata n mai multe proiecte similare ca complexitate i extindere.
Interoperabilitate tehnologica
Avnd n vedere principiile menionate mai sus de integrare intre aplicaii, tehnologic nu
exista nici o impunere privind platforma tehnologica care va fi folosita pentru dezvoltarea
sistemului. De asemenea, module sau componente diferite pot utiliza platforme
tehnologice oferite de mai muli productori, att timp cit principiile de interoperabilitate
sunt corect i consistent utilizate. Totui, furnizarea mecanismelor de transfer i stocare de
date trebuie sa asigure un nivel de securitate ridicat (n ceea ce privete confidenialitatea
i accesibilitatea), aceasta fiind una dintre impunerile fundamentale pentru orice sistem de
eSntate. n prezent, exista o astfel de reea a fost creata n cadrul CNAS i instituiilor
cu care aceasta colaboreaz n proiectul SIUI. Dezvoltarea sistemelor informatice aferente
DES trebuie sa respecte standardele internaionale i noile tehnologii sa fie utilizate la
maxim, astfel incit :
Sa se asigure neutralitatea tehnologica;
Sa ofere longevitate pentru aplicaiile existente;
Sa favorizeze libera concurena ntre furnizorii de servicii pentru a reduce costurile de
dezvoltare, ntreinere i mentenan

1.1.1.38. Cerine subsistem de integrare la nivel de date

O caracteristica definitorie a sectorului medical este necesitatea unui transfer important de

informaii ntre diferite tipuri de actori ai actului medical - instituii administrative de stat,
furnizori de servicii de asistena medicala i furnizorii pentru funcii suport (de exemplu,
companiile de asigurri).
 Fiecare dintre actorii implicai este suficient de independent atunci cnd alege soluiile IT
necesare desfurrii funciilor de baza sau suport. Ca urmare a creterii nivelului de
informatizare a sectorului medical i stabilirea de noi sisteme informatice cu funcii
administrative n cadrul instituiilor de stat i furnizorilor de servicii de asistena
medicala, o serie de fluxuri de informaii sunt informatizate sau n curs de informatizare.
Sistemul informatic cel mai extins ca funcionalitate i numr de utilizatori din sistemul
medical este implementat de CNAS SIUI.
Standardizarea fluxului de date medicale i integrarea IT se soluioneaz innd cont de
urmtoarele segmente:
semantic sau de integrare a datelor ofer un concept unitar de clasificare a datelor i
mecanisme standard de transfer a acestora;
de aplicaie sau de integrare la nivel de sistem
de infrastructura sau interoperabilitate tehnologica - asigura interoperabilitatea
tehnologiilor utilizate, oferind accesibilitate i protecie a datelor.
Dei informatizarea medicala a fost obiectul unor eforturi privind standardizarea
schimbului de informaii de mai multe decenii, din pcate, standarde unificate nu au fost
stabilite la nivel mondial i nici la nivelul UE. Prin urmare, n cadrul punerii n aplicare a
programului de e-sntate abordarea utilizrii standardelor medicale de schimb al
informaiilor specifice trebuie determinata i stabilita la nivelul Romniei.
Pentru acest proces, trebuie evaluai principalii actori ai procesului de standardizare
medical precum i standardele corespunztoare :
HL7 organizaia internaionala de standardizare, cu sediul n SUA, focalizata pe
standarde clinice. Cele mai multe dintre rile dezvoltate (inclusiv Europene) au un rol
activ n activitile organizaiei. n 2005, o noua versiune de standard - V3 - a fost creata.
Fundamental, aceste standarde definesc sintaxa specifica de raportare i principiile de
transfer de date. Semantica propriu-zisa (model de obiecte) nu este inclusa n acest
standard.
CEN - organism European de standardizare n cadrul cruia participa i colaboreaz
organismele naionale de standardizare. CEN a dezvoltat familiile de standardele CEN
TC215. n 2005, un nou standard din aceasta familie ENV 13306, care definete
principiile eHR, a fost emis.
ISO principalul organism internaional de standardizare care abordeaz familia de
standarde TC215 (in fapt adapteaz standardele CEN pentru utilizare internaionala,
innd cont de recomandrile rilor din afara UE).
 openEHR - organizaie non-profit care lucreaz pentru crearea i facilitarea
implementrii standardelor deschise n domeniul eHR.
Trebuie analizate urmtoarele aspecte legate de procesul de stabilirea standardelor
Utilizarea XML (Extensible Markup Language) pentru crearea i consumarea legturilor
de transfer de date intre aplicaii
Pentru a defini i standardiza formate de transfer de date, standardele naionale vor fi
stabilite de ctre CNAS, pentru a asigura maxima interoperabilitate cu sistemul existent
SIUI-2.
Sintaxa folosita pentru raportare trebuie sa fie dezvoltata pe baza standardelor prezentate
anterior i avnd n vedere recomandrile CEN/ISO TC2105 (inclusiv CEN ENV 13606).
n practica se vor prefera soluii compatibile HL7 iar acolo unde este necesar i posibil se
vor implementa cerinele CEN/ISO. Fundamentarea acestei decizii tine de cont de
urmtoarele :
standardele HL7 sunt mai uor de implementat i exista un suport considerabil din partea
productorilor de soluii
n multe ari (SUA, Canada, Marea Britanie etc), dezvoltarea de sisteme eHR este bazata
pe HL7
In scopul standardizrii semanticii de raportare (coninutul de date) pentru schimbul de
date, este necesara dezvoltarea de formate de raportare specifice pentru Romnia, care se
bazeaz pe modelul obiectual din CEN ENV 1306, precum i lund n considerare
formate de raportare dezvoltate de ctre alte ari.

1.1.1.39. Interfee expuse n exterior

Datorita specificului sistem DES (EHR Partajat), una dintre caracteristicile importante
este aceea de interfaare i interoperabilitate cu sistemele complementare. n cazul nostru
principalele sisteme sau sub-sisteme informatice cu care se va interconecta sunt
urmtoarele:
Alte module ale SIUI Sistemul Informatic Unic Integrat al CNAS
eCard Sistemul informatic Cardul Electronic de Sntate, componenta a SIUI
ePrescription Sistemul Prescripie Electronic, componenta a SIUI
SI spitale sistemele existente n cadrul spitalelor (de tip EMR/EPR/EHR)
SI medici generaliti / specialiti - sistemele existente n cabinetelor medici de familie,
generaliti / specialiti (de tip EMR/EPR/EHR) ulterior
 SI centralizate pentru diagnostic clinic / vizual sisteme informatice specifice
laboratoarelor pentru rezultatele clinice i a celor de tip imagistica n viitor ulterior
Funcionalitile prezentate se vor construi n faze de proiect sau ulterior n proiecte
separate.

5.12.6. Cerine subsistem monitorizare

Integritatea sistemului DES se va pstra printr-o constanta monitorizare a ntregului
sistem. Subsistemul de monitorizare trebuie sa dein urmtoarele caracteristici:
Sa monitorizeze toate sistemele de operare furnizate in cadrul solutiei
Sa monitorizeze pa lng sistemele de operare i echipamentele active ce suporta
monitorizare, cel puin:
Comunicaii reea
Comunicaii SAN
UPS
Informaiile de monitorizare colectate trebuiesc pstrate cel puin un an de zile
Informaiile colectate trebuie afiate n forma grafica n timp real.
Sa genereze rapoarte de status exportabile n formate comune, minim PDF
Sa genereze rapoarte statistice exportabile n formate comune, minim PDF

5.12.7. Cerine subsistem audit

Subsistemul de audit se mparte n doua zone:
Auditare medicala. Acest subsistem are urmtoarele caracteristici:
Va audita baza de date medicale pentru stabili utilizatorii conectai, ce activitati au
realizat, cnd, asupra cror date.
Informaiile sunt disponibile asiguratului, n portalul web, pentru a monitoriza activata
asupra datelor medicale.
Auditare de sistem. Componentele active (sistem de operare, echipamente de comunicaii,
sisteme de administrare, console de sistem, etc), vor raporta n acest sistem activitile
non medicale cu urmtoarele caracteristici:
Conectare utilizatori de sistem
Modificare de status a echipamentelor (ex: modificare porturilor de comunicaii)

5.12.8. Cerine subsistem salvare i restaurare

Subsistemul de salvare i restaurare trebuie sa dein urmtoarele caracteristici:
 Sa salveze fr a ntrerupe activitatea: sisteme de operare, coninutul bazelor de date,
codul aplicaiilor, configuraiile echipamentelor de comunicaii sau a dispozitivelor
integrate. Salvarea completa a datelor se va face cel puin odat de 24 de ore.
Coninutul bazelor de date se vor salva folosind reeaua SAN pentru transferul lor n
sistem de salvare. Doar datele cu volum mic se pot transfer prin reea Ethernet (ex: fiier
de configuraii, loguri, etc)
Sa raporteze activitile efectuate
Restaurarea completa a tuturor sistemelor trebuie sa se fac n cel mult 24 de ore de la
nceperea activitii de restaurare.

5.12.9. Cerine subsistem help desk

Subsistemul de Help-Desk trebuie sa elimine situaiile de neutilizare a sistemului
datorate diverselor incidente care pot aprea n exploatare.
Sistemul va permite preluarea, nregistrarea (automat sau manual) i urmrirea sesizrilor
privind funcionarea anormala a ntregului sistem informatic. Pentru a permite o
nregistrare eficienta subsistemul trebuie sa lucreze integrat funcional cu alte sisteme de
monitorizare, management de evenimente, reea, sisteme, etc.
Modulul va permite ca pe parcursul derulrii activitii de Help Desk, specialitii IT sa
poat nregistra modalitile de rezolvare pentru incidentele frecvent ntlnite sub forma
de baza de cunotine sau abloane de incidente, astfel nct la reapariia unui nou
incident, modalitatea de rezolvare sa fie deja nregistrata n subsistem i sa permit un
rspuns prompt prin evitarea pailor de rediagnosticare.

5.12.10. Cerine subsistem de arhivare

Datele medicale, odat introduse n sistem, trebuie pstrate pe ntreaga durata de viata
asiguratului plus 25 de ani. Durata medie de viata se considera 75 de ani. Avnd n
vedere evoluiile tehnologice i imposibilitatea practica a arhivarii datelor in acest
moment pe o perioada mai mare de 20 de ani, la fiecare 10-15 ani CNAS va reanaliza
posibilitatile de modernizare a solutiei de archivare.
Arhivarea datelor se va face folosind casete magnetice. Se vor face doua copii, astfel nct
a doua copie sa poate fi mutata n alta locaie.
Arhivarea datelor strict medicale cat i a datelor de audit asupra datelor medicale se va
face pe tehnologie W.O.R.M.

5.12.11. Cerine subsistem de comunicaii

 Sistemul de comunicaii reprezint poarta de intrare-ieire a informaiilor in/din sistem.
Exista doua pori principale:
Comunicaia cu spitalele. Se va realiza folosind un mediu de transport dedicat.
Construirea acestei infrastructuri nu face parte din acest proiect
Comunicaie cu asiguraii. Se va realiza folosind internetul ca mediu de transport. Avnd
n vedere cerinele de securitate i confidenialitate urmtoarele cerine sunt minime:
Transferul datelor se va realiza numai prin protocol WEB criptat.(SSL)
Echipamentul de comunicaie va nchide tunelul SSL, apoi va verifica coninutul folosind
sisteme IPS/IDS. Autentificare,autorizarea i contabilizarea utilizatorilor se va realiza n
alte echipamente IT
In interiorul sistemului comunicaia se va realiza pe canale de 10 Gbit n mod redundant
pentru fiecare echipament fizic de virtualizare. Pentru echipamente fizice individuale se
pot folosi i conexiuni de 1 Gbit.
Avnd n vedere traficul de date, sistemul de comunicaii va balansa traficul pe
echipamente de procesare n mod activ-activ.
Sistemul de comunicaii va fi redundant n configuraie activ-activ.
6. Cerine tehnice detaliate

Pentru asigurarea cerinelor funcionale i prezentate anterior, sistemul va trebui sa includ

cel puin componentele din diagrama de mai jos. Mediile de testare, dezvoltare i certificare
vor conine un subset din aceste componente.

In cele ce urmeaza sunt detaliate cerintele detaliate pe fiecare componenta:

 6.1. Cerine hardware detaliate

o Infrastructura hardware trebuie sa fie instalata intr-o locaie centralizata care va gzdui
toate componentele hardware necesare pentru rularea in bune condiii a aplicaiilor
descrise mai sus. Locatia unde se vor instala echipamentele este STS.
o Infrastructura hardware trebuie sa includ toate componentele necesare care sa satisfac
cerinele de performanta necesare
o Infrastructura hardware trebuie sa includ toate componentele necesare care sa satisfac
cerinele de disponibilitate necesare
o Sistemele si echipamentele livrate trebuie sa fie noi, neutilizate si de ultima generaie. Ele
trebuie sa asigure gradul necesar de performanta, fiabilitate si flexibilitate fiind proiectate
si destinate pentru aplicaii critice de tip enterprise level.
o Dispozitivele hardware trebuie sa fie astfel proiectate nct sa poat asigura scalabilitatea
sistemului in cazul creterii nevoii de putere de calcul.
o Dispozitivele hardware livrate, care au in configuraie posibilitatea de upgrade pentru
anumite componente, trebuie astfel configurate nct upgrade-ul sa se fac fr pierderea
de dispozitive existente.
o Dispozitivele hardware trebuie sa fie compatibile cu caracteristicile reelei electrice din
Romnia astfel nct sa nu existe probleme la conectarea acestora la reeaua electrica.
o Ofertantul va prezenta specificaiile tehnice privind organizarea si amenajarea camerei
serverelor (dataroom / datacenter) in care se vor instala echipamentele astfel nct sa fie
asigurate condiiile operaionale optime pentru funcionarea acestora.
o Ofertantul va preciza care este greutatea totala a echipamentelor livrate si dimensiunile
fizice ale acestora pentru a se putea verifica sigurana instalrii in locaia beneficiarului
o Ofertantul va preciza in oferta care este puterea totala consumata de echipamentele livrate
precum si caracteristicile de climatizare/ventilaie necesare, astfel nct solicitantul sa
poat asigura acest necesar in locaia unde urmeaz a fi instalate echipamentele.
o Ofertanii vor avea n vedere ca toate cerinele si caracteristicile hardware solicitate au un
caracter minim si obligatoriu.
o Toate aceste cerine sunt dezvoltate la nivel de detaliu in cadrul documentaiei de
atribuire. In acelai timp cerinele nu sunt limitative ofertanii avnd libertatea de a le
dezvolta si extinde conform soluiei pe care o au in vedere sa o propun si care trebuie sa
ndeplineasc n totalitate cerinele solicitantului.
o Ofertanii au obligativitatea de include in propunerea tehnica si comerciala toate
componentele hardware, software si de servicii pe care le considera necesare astfel nct
aceasta sa fie completa si integrata, chiar daca aceste componente nu sunt individualizate
sau solicitate explicit in documentaia de atribuire.

o Oriunde in caietul de sarcini se intalnesc nume, marci, denumiri pentru anumite produse,
tehnologii si benchmark-uri se va considera implicit adaugata mentiunea sau echivalent
.

Echivalent va fi interpretat ca insemnand ca produsul echivalent oferit are caracteristici

fizice, functionale si de performanta similare cu ale produsului brand name. Pentru a fi
luate in considerare in cadrul evaluarii, ofertele de produse echivalente trebuie :

A) Sa prezinte caracteristicile fizice, functionale si de performanta specificate in

caietul de sarcini;

B) Sa includa documentatie descriptiva, tabele cu specificatii si, acolo unde este

aplicabil, ilustratii sau desene;

C) Sa descrie clar orice modificari aduse produsului de catre ofertant, in vederea

adaptarii acestuia la cerintele caietului de sarcini.

D) Ofertele care vor stipula echivalent vor fi evaluate in baza informatiilor

furnizate de ofertanti. Comisia de evaluare nu este responsabila pentru localizarea sau
obtinerea oricaror informatii care nu sunt continute in oferta.

o Infrastructura hardware va folosi tehnologii de virtualizare specifice pentru a creste

flexibilitatea soluiei. Infrastructura de virtualizare trebuie sa permit alocarea dinamica a
resurselor (CPU, memorie, sisteme I/O), fr a ntrerupe sistemul virtual din funcionare
si fr a avea alt efect dect cel scontat de cererea de modificare a resurselor. Sistemul de
virtualizare trebuie sa separe sistemele virtuale astfel nct sa nu existe posibilitatea de
transfer de informaii de la un sistem virtual la altul.
o Infrastructura logica va conine patru zone:
Zona de dezvoltare. Aceasta zona este folosita pentru dezvoltarea tuturor
funcionalitilor sistemului att n faza de implementare, cat si ulterior pentru a
dezvolta alte funcionaliti
Zona de testare. Aceasta zona este folosita pentru testarea funcionalitilor dezvoltate.
 Zona de producie. Aceasta zona este folosita pentru utilizarea sistemului in mediu
real.
Zona de certificare. Aceasta zona este similara n funcionaliti cu zona de producie,
dar este folosita pentru a testa si certifica sistemele din teritoriu, care trebuie sau
doresc sa se integreze cu sistemul DES. Testarea si certificarea sistemelor externe
se limiteaz la funcionalitile de integrare cu DES (transmiterea datelor,
respectarea standardelor de comunicare si performanta, validarea corecta a
datelor de transmis/primit, etc)
Cerinele hardware ce trebuie ndeplinite de soluia propusa corespund urmtoarelor
componente principale:
o Sistem de procesare a datelor
o Sistem de stocare a datelor pe mediu magnetic
o Sistem de salvare si restaurare a datelor
o Sistem de comunicaii local (intre sistemele si subsistemele propuse in cadrul
ofertei solicitate)

6.1.1. Cerine minime obligatorii pentru sistem de procesare a

datelor (2 buci)
Arhitectura sistemului trebuie sa aib integrate funcionaliti de tip Capacity on Demand
in ceea ce privete resursele de calcul de tip core-uri/procesoare si memorie interna.
Aceste funcionaliti trebuie sa permit alocarea dinamica a resurselor, in mod temporar
sau permanent, in funcie de cerinele concrete ale aplicaiilor ce ruleaz pe sistem. Pentru
asigurarea unei capacitai de calcul de rezerva disponibile pentru necesitai viitoare din
punct de vedere al volumului de prelucrri se vor activa doar maximum 75% din numrul
de core-uri si memoria interna instalate fizic in configuraia ofertata a sistemului
Sistemul trebuie sa aib instalate si active un numr de core-uri care sa asigure puterea de
calcul si gradul de redundanta necesare pentru cerinele soluiei. innd seama de nivelul
tehnologic actual si de caracterul critic din punct de vedere performanta, disponibilitate si
scalabilitate dictate de acoperirea naionala a soluiei, numrul minim de core-uri
instalabile ( posibil a se instala ) fizic in configuraia maximala a sistemului ofertat nu
trebuie sa fie mai mic dect 128 iar frecventa de ceas a core-urilor nu trebuie sa fie mai
mica dect 2.00 GHz. Solutia propusa trebuie sa asigure capabilitatea ca acele core-uri
instalate si active efectiv sa aiba flexibilitatea unor functionalitati distincte si dedicate la
un moment dat: prelucrari generale, prelucrari pentru un anumit mediu de operare,
 prelucrari pentru un anumit tip de aplicaii ( workload ), sau de rezerva ( spare ). Se va
prezenta o justificare a dimensionrii propuse.
Modelul de sistem ofertat trebuie sa asigure un nivel de performanta ridicat pentru diverse
tipuri de aplicatii ( workload ) care presupun in mod intensiv calcule cu numere intregi,
reale aproximate ( floating point ) si prelucrari de tip Java. Corespunzator acestor cerinte
sistemul trebuie sa asigure urmatoarele niveluri de performante ( benchmarks ) certificate
prin prezenta pe site-urile www.spec.org si www.tpc.org:

- SPECint_rate2006: minim 9.000

- SPECfp_rate2006: minim 9.000
- SPECjbb2005: minim 15.000.000

Se admit orice benchmark-uri echivalente ca functionalitate si nivel de performanta.

Sintagma echivalent trebuie inteleasa ca fiind conforma cu detalierea prezentata in
cadrul acestui capitol.

Sistemul trebuie sa asigure suport pentru instalarea a cel puin 8 GB RAM / core. Aceasta
proporie se va pstra si pentru memoria si core-urile active incluse in configuraia
propusa. Memoria interna trebuie protejata prin mecanisme specializate de protecie a
datelor care vor trebui detaliate in oferta.
Sistemul trebuie sa aib instalate interfee dedicate de criptare a datelor si accelerare a
traficului de date de tip SSL. Numrul acestor interfee trebuie calculat astfel nct sa se
asigure nivelul de performanta si redundanta ale soluiei. Se va prezenta o justificare a
dimensionrii propuse.
Sistemul propus trebuie sa asigure suport pentru standardele si protocoalele de stocare,
prelucrare, protectie/securitate i transmisie a datelor. Se vor enumera si detalia toate
aceste standard si protocoale separate.. Soluia oferita trebuie sa dispun de certificri
standard de securitate a informaiilor care se vor meniona si include in oferta.
Arhitectura hardware interna a sistemului propus trebuie sa fie redundanta, justificndu-
se si detaliindu-se acest lucru. Ea trebuie sa permit funcionarea nentrerupta a sistemului
in situaii de defeciune a unei componente interne fr degradare de performanta
Sistemul trebuie sa fie echipat cu interfee de I/O care sa suporte transmisii de date de tip
Fibre Channel (sau echivalent) minim 4 Gb/s, 10 Gb/s Ethernet (sau echivalent) si 1 Gbps
Ethernet (sau echivalent). Fiecare din cele trei protocoale menionate va dispune de porturi
I/O fizic separate. Numrul acestor porturi trebuie calculat astfel nct sa se asigure nivelul de
performanta si redundanta ale soluiei. Se va prezenta o justificare a dimensionrii propuse.
Sistemul trebuie sa aib suport pentru partiionarea fizic i/sau logic a resurselor de calcul
(core-uri, memorie interna si interfee I/O). Partiionarea si virtualizarea resurselor de calcul
trebuie sa garanteze separarea deplina a datelor intre partiiile definite in cadrul aceleiai
maini fizice. Se va justifica modul in care soluia propusa garanteaz aceasta separare.
Soluia trebuie sa permit rularea in paralel in partiii distincte a aplicaiilor (workload) de
tipuri distincte (baze de date, aplicaii Web etc) fr afectarea performantei si funcionalitii
globale a sistemului i folosind medii/sisteme de operare eterogene
Soluia propusa trebuie sa asigure un nivel maxim posibil de utilizare a tuturor resurselor de
calcul disponibile. Se va detalia inclusiv prin furnizarea de date numerice modul in care se
asigura aceasta funcionalitate.
Modulul software sau sistemul de operare cu rol de hipervizor (management de virtualizare)
trebuie sa ruleze nativ pe arhitecturi 64 bit

6.1.2. Cerine minime obligatorii pentru infrastructura de

stocare (2 buci):

Sistemul trebuie sa dispun de o arhitectura

redundanta care sa ofere mecanisme de failover
automat in situaia defectrii oricrei componente din
sistem.
Echipamentul trebuie sa permit configurarea in aa
fel nct defectarea unui controller sau a unui
subsistem de discuri sa nu afecteze continuitatea
Arhitectura operrii sistemului
Memorie Cache Capacitatea memoriei cache instalate trebuie sa
asigure un raport de minim 10 GB memorie cache
instalata la 10 TB capacitate de stocare potenial
disponibila, fizic instalata pe sistemul livrat.
Echipamentul trebuie sa fie livrat mpreuna cu un
sistem care sa asigure salvarea datelor din memoria
cache pe un suport nevolatil in cazul ntreruperii
 neprogramate a alimentarii cu tensiune.
Capacitatea fizic instalata trebuie sa fie de minim 100
TB. Aceasta capacitate trebuie organizata in matrici
de discuri in care protectia datelor se asigura prin
mecanisme de tip RAID ( sistemul trebuie sa suporte
minim nivelurile RAID10, RAID5 si RAID6 ).
Accesul la ntreaga capacitate fizic instalata nu
trebuie sa impun ntreruperea operrii normale a
echipamentului sau modificarea componentelor
interne. Capacitatea instalata se poate realiza prin
utilizarea de discuri de inalta performanta ( SSD, FC,
SAS 2.0 ), discuri de mare capacitate ( SATA, SAS-
NL ) sau prin mixarea de tehnologii. In cazul mixarii
tehnologiilor se va furniza si mecanismul
hardware/software care asigura migrarea manuala sau
automata a datelor ( la nivel de volum logic si sub-
volum ) intre tipuri diferite de discuri, in functie de
Capacitate disponibila cerintele aplicatiilor.
Numrul minim de porturi disponibile pentru
conectarea serverelor host sau accesul la alte
sisteme de stocare trebuie sa asigure un raport de
minim 1 port la 7,5 TB capacitate de stocare potenial
disponibila, fizic instalata. Aceste porturi trebuie sa
fie de tip FC 4 Gb/s (sau superior). Se accepta si tipuri
echivalente de porturi, echivalenta referindu-se la
nivelul de performanta si funcionaliti. Nu se
accepta soluii care asigura multiplicarea unui numr
inferior de porturi disponibile la nivel de
controller/sistem de stocare prin intermediul
Conectivitate echipamentelor de tip switch externe.
 Sistemul trebuie sa asigure servicii de copiere
instantanee (SnapShot) a volumelor de date in
configuraia propusa pentru toata capacitatea
Copii volume de date disponibila in interiorul sistemului de stocare.
Sistemul trebuie sa asigure servicii de copiere a
datelor de tip sincron si asincron disponibile pentru
ntreaga capacitate de stocare utilizabila. Toate aceste
Replicare date funcionaliti trebuie sa fie active in soluia propusa.
In configuraia propusa echipamentul trebuie sa
permit utilizarea mecanismelor de provizionare
(Thin Provisioning) a capacitaii alocate unui server
permind in acest fel alocarea unor capacitai mai
mari dect capacitatea fizica utilizata propriu-zis.
Sistemul trebuie sa permit redimensionarea
volumelor logice in mod online indiferent daca
acestea au fost alocate prin intermediul mecanismelor
Provizionare de tip thin provisioning sau nu.
Monitorizare, management si Echipamentul trebuie livrat mpreuna cu o aplicaie de
securitate date management si monitorizare cu funcionalitile
descrise in continuare.
Aplicaia trebuie sa permit managementul mai
multor sisteme de stocare de acelai tip in mod
concurent si sa asigure lucrul att in mod grafic (GUI)
cat si in mod linie de comanda (CLI).
Aplicaia trebuie sa ofere posibilitatea monitorizrii
datelor legate de performanta att in timp real cat si
pe baza informaiilor istorice.
Aplicaia de monitorizare trebuie sa permit
vizualizarea informaiilor la nivel de volum logic,
host, interfaa fizica precum si pentru sistemele
intre care se realizeaz replicarea de date. La nivelul
fiecrei categorii aplicaia trebuie sa furnizeze
informaiile intr-un mod granular vis-a-vis de
subsistemele echipamentului (performanta operaii -

Sisteme de operare suportate si performanta ( benchmark ) certificat public tip SPC-1
certificate; alte certificari
6.1.3. Cerine minime obligatorii pentru infrastructura de biblioteca
de benzi (1 bucata):
Tip echipament
Descriere generala
IOPS, performanta transfer date - Mb/s, nivel de
utilizare a memoriei cache, hit rate pentru citiri si
scrieri, eficienta la scriere, ncrcarea liniilor de
replicare date, etc)
Posibilitatea de a crea grupuri de administratori cu
nivele de acces diferite oferind posibilitatea garantrii
drepturilor de configurare unui utilizator la nivelul
unui subset de operatii.
Capabilitatea la nivel de arhitectura sistem de a utiliza
mecanisme de criptare date, inclusiv la nivel de
unitati de discuri
Microsoft Windows 2003/2008, Linux (minimum
distribuiile Red Hat si Novell SUSE) si UNIX
(minimum HP-UX, Solaris si AIX).
Pentru estimarea performantelor posibile ale
sistemelor ofertate se solicita minim un nivel de
sau/si SPC-2
Sistem de salvare si restaurare a datelor pe benzi
magnetice de tip tape library din clasa enterprise
folosita in arhitecturi cu cerine critice din punct de
vedere performanta, scalabilitate si fiabilitate
Echipamentul trebuie s permit urmtoarele
funcionaliti:
identificarea automata a cartusului pe baza codului
de bare,
incarcarea cartuselor sa poata fi facuta on line
prin porturi/sloturi multiple, intr-un raport de
minim 1 port la 20 de sloturi active de stocare a
cartuelor. Trebuie asigurata posibilitatea de a
folosi, la alegere, fie porturi/sloturi dedicate
 permanent pentru incarcarea / descarcarea
cartuselor fie porturi/sloturi asignate temporar
acestui scop. Operatiile de introducere / ejectare de
casete din librarie trebuie sa fie posibile si in mod
bulk, fara afectarea functionarii librariei
Configuraia propus trebuie s includ un cititor de
cod de bare
Posibilitate de acces la cartue in modurile secvenial
Mod de acces
si/sau aleator.
Adugarea sau nlocuirea unitilor de citire /
scriere i a surselor de alimentare cu energie
electrica trebuie sa poat fi fcuta on line /
hotswap.
Capabilitati de tip failover la nivel de date si
Disponibilitate
control intre unitatile de citire/scriere
Interfete duale Ethernet pentru management
Capabilitate de actualizari software ( update ) la
nivel de librarie si unitati de citire / scriere fara
oprirea sistemului ( on line )
In configuraie maxima echipamentul trebuie sa
Scalabilitate numr de uniti permit instalarea a unui numr minim de uniti de
de citire citire/scriere de cel puin 10 ori mai mare ca acela
instalat in configuraia iniial.
In configuraie maxima echipamentul trebuie sa
Scalabilitate numr maxim de permit instalarea a unui numr minim de cartue in
casete sloturile disponibile de cel puin 50 ori mai mare ca
acela instalat in configuraia iniiala .
Sistem de alimentare cu Redundant cu minim 2 surse de alimentare cu energie
energie electrica hot-swap
Suport pentru tehnologia Ultrium LTO5 sau echivalent
Tehnologii de inscripionare
si minimum o generaie anterioara
Tipuri de uniti de banda Minimum uniti de citire/scriere in tehnologie
suportate Ultrium LTO5 sau echivalent
Tehnologii de protecie a Suport asigurat pentru de criptarea datelor stocate pe
datelor la nivel de casete cartue precum si suport pentru tehnologia WORM
(Write Once Read Many).

Upgrade capacitate de stocare
Virtualizare
Sisteme de operare suportate
Upgrade tehnologie
Conectare reea SAN
Management
Opiuni si accesorii
Solutia propusa trebuie sa permita alegerea
implementarii criptarii datelor la nivel de 1) aplicatie,
2) sistem de operare host care acceseaza libraria sau
3) librarie
Se vor prezenta in detaliu caracteristicile de
implementare tehnologica la nivel de casete de date si
unitati de citire / scriere date care asigura un nivel
superior de fiabilitate si performanta operational si
pentru mediul de stocare date
Posibilitatea de a realiza upgrade-ul capacitaii de
stocare la nivel unitate fizica (frame) prin coduri
software pentru activarea sloturilor fizic existente dar
inactive
Echipamentul trebuie sa permit definirea de librarii
logice ( inclusiv in mod dinamic, in faza de definire
sau realocare ulterioara de resurse ) in cadrul aceluiai
sistem fizic, separate din punct de vedere al unitilor
de citire/scriere folosite si a sistemelor host care le
acceseaz
Microsoft Windows 2003/2008, Linux (minimum
distribuiile Red Hat si Novell SUSE) si UNIX
(minimum HP-UX, Solaris si AIX).
Arhitectura sistemului trebuie sa permit folosirea de
uniti de citire/scriere cu tehnologii diferite sau
generaii distincte ale aceleiai tehnologii.
Conectarea unitilor de citire/scriere n reeaua SAN
trebuie realizata prin interfee Fibre Channel minim 4
Gb/s
Managementul echipamentului i a funcionalitilor
acestuia trebuie sa asigure suport pentru urmtoarele
interfee si standarde: Web, SNMP, SMI-S. Se vor
livra toate componentele hardware si software
necesare pentru realizarea tuturor funcionalitilor de
management.
Echipamentul trebuie livrat mpreuna cu toate
accesoriile necesare bunei funcionari si interconectri
 cu celelalte elemente ale soluiei propuse.
Minim 8 uniti de citire/scriere in tehnologie Ultrium
LTO 5, cu capabilitate de failover intre unitati pentru
Configuraia livrata
fluxurile de date si control in cazul defectarii unei
unitati
Minim 200 de sloturi active la nivelul sistemului livrat
Minim 200 de cartue de tip Ultrium LTO 5 sau
echivalent cu cod de bare
Consola de management dedicata echipamentului
trebuie inclusa in configuraia propusa.

6.1.4. Cerine minime obligatorii pentru infrastructura de SAN

(2 buci):
Echipament de tip director utilizabil in sisteme cu
cerine critice din punct de vedere performanta,
Tip echipament scalabilitate si fiabilitate
In configuraia propusa echipamentul trebuie sa fie
echipat cu cel puin doua carduri dedicate pentru
routarea interna a pachetelor de date cat si pentru
managementul echipamentului.
Aceste subansamble trebuie sa funcioneze in regim
redundant si sa fie capabile sa preia fr downtime in
caz de defectare a unuia dintre ele ncrcarea cardului
Modul de control (supervizor) defect.
Echipamentul trebuie sa permit instalarea cardurilor
de extensie care sa asigure cel puin urmtoarele
tehnologii de conectare: FC ( minim 8 Gb/s), FCIP,
Tehnologie FCoE si FICON .
Scalabilitate In configuraie maximala echipamentul trebuie sa
permit instalarea unui numr de cel puin 240 de
porturi FC de 8 Gb/s. Dispozitivul trebuie sa permit
interconectarea cu un alt echipament similar prin
conexiuni dedicate de mare viteza (trunking)
asigurnd in acest mod scalarea la un numr de cel
puin 480 de porturi consolidate intr-un singura reea
 fizica (SAN fabric) . Extinderea numrului de porturi
trebuie sa poat fi realizata online prin intermediul
cardurilor de extensie. Adugarea cardurilor noi
trebuie sa poat fi realizata on line fr ntreruperea
traficului de producie.
In configuraia livrata echipamentul trebuie sa fie
echipat cu cel puin 64 de porturi FC distribuite pe
minimum 2 carduri. Fiecare port trebuie sa fie echipat
Porturi instalate cu adaptoare electro-optice (SFP) de minim 8 Gb/s.
Managementul echipamentului trebuie sa poat fi
realizat prin intermediul unei reele Ethernet att in
Management mod grafic (GUI) cat si prin linie de comanda (CLI).
Funcii avansate Configuraia sistemului livrat trebuie sa cuprind
componentele software si hardware care sa asigure
urmtoarele funcionaliti:
Administrarea, configurarea si mentenan la
nivel de echipament si SAN
Partiionarea SAN in grupuri logice (zone)
pentru controlul / restricionarea
comunicaiilor si aplicarea anumitor
politici in acest sens pentru membrii zonei
respective
Posibilitatea de implementare de reele
virtuale (virtual fabrics) peste reeaua
fizica. Fiecare reea virtuala trebuie sa
poat conine switch-uri logice SAN
precum si propriile cai de transfer date si
control/management
Capabilitatea de definire de nivele de
performanta si calitate a comunicaiilor
(Quality of Services QoS) astfel nct sa
se asigure lrgime de banda necesara
comunicaiilor critice chiar in condiii de
reele congestionate
 Posibilitatea de analiza pe ntreaga cale de
comunicaie (end-to-end) a nivelului de
performanta si gradului de utilizare a
lrgimii de banda alocate
Capabilitatea de monitorizare permanenta a
funcionarii pentru detectarea potenialelor
probleme si defecte si avertizarea
administratorului nainte de apariia
propriu-zisa a defectelor
Echipamentul trebuie livrat cu surse de alimentare si
ventilatoare redundante precum si cu un numr de
cabluri FC de minim 5 m lungime si conectori LC la
ambele capete. Numrul de cabluri livrate trebuie sa
fie egal cel puin cu numrul de porturi FC active
Opiuni si accesorii (cu SFP) din configuraia propusa a echipamentului.
 6.1.5. Cerine comunicaii
Toate cerinele de mai jos sunt minime.
In condiiile n care specificaiile tehnice sunt minimale, caracteristicile tehnice din oferta
care sunt superioare celor cerute prin caietul de sarcini vor trebui sa apar intr-un mod cat
mai vizibil.
Switch multifuncional 2 buci.
Specificaiile tehnice pentru Switch multifuncional sunt:
Construcia switch-ului sa aib capacitatea fizica minima de 9 slot-uri pentru cartele
funcionale.
Oferta trebuie sa aib inclusa cea mai noua versiune de Sistem de Operare testata i
recomandata de productor, mpreuna cu serviciul de update i upgrade de versiune pe
toata perioada de garanie a echipamentului
Cardurile cu procesor trebuie sa poat funciona n mod redundant
Switch-ul trebuie sa permit surse de alimentare n redundanta
Administrare completa (full manageability)
Switch-ul sa asigure maximum de disponibilitate prin redundanta inter-asiu i
convergenta rapida .
Capacitatea de comutaie a sistemului trebuie sa fie de minim 1440Gbps i de minim
80Gbps per slot.
asiul trebuie sa fie echipat cu sistem de ghidare al cablurilor furnizat de productorul
switch-ului iar fluxul de aer al switch-ului trebuie sa fie constructiv fa-in-spate-out , fr
a se utiliza deflectoare.
asiul trebuie sa aib cel puin magistrala de control dublata intern.
nlimea sistemului sa fie de maxim 21 Rack Unit
1*Card Procesor , trebuie sa aib capacitatea de a procesa hardware minim 400M pps
(pachete pe secunda) n mod IPV4 sau minimum 200M pps (pachete pe secunda) n mod
IPV6
o Numr minim de rute IPV4 1.000.000;
o Numr minim de rute IPV6 500.000;
o Sa permit virtualizare a 2 sisteme fizice intr-unul singur cu administrare unitara ce sa
permit transfer ntre asie la debite de minim 1.4Tbps
 o Sa aib minim 2 porturi de 10G Ethernet, fiecare dintre acestea echipate cu module
optice pentru a putea fi interconectate cele 2 asie peste FDDI multimod la o lungime
de 220m
o Sa permit redundanta sub-secunda a cardului procesor n cazul utilizrii virtualizrii.
o Memorie minim 1GB
o Software adecvat pentru realizarea virtualizrii care sa permit :
- Virtual Private LAN Services (VPLS)
- L2VPN Pseudowire Redundancy
- MPLS Virtual Private Networks (VPN)
1* Card dedicat cu 48-porturi RJ-45 n mod 10/100/1000 GE n tehnologie adaptata
pentru Server Farms adic fabric-enabled, cu un card de extensie accelerator cu suport
tehnologie Cisco Distributed Forwarding Card 3 cu capabiliti de 1.000.000 rute IPv4 i
n numr de 256.000 instane de NetFlow.
1* Card dedicat cu 16-porturi de 10GigabitEthernet n tehnologie adaptata pentru Server
Farms adic fabric-enabled, cu un card de extensie accelerator cu suport tehnologie Cisco
Distributed Forwarding Card 3 cu capabiliti de 1.000.000 rute IPv4 i n numr de
256.000 instane de NetFlow. Acest card trebuie sa fie echipat cu 16 module de
10GigabitEthernet ce trebuie sa permit interconectarea peste FDDI multimod la o
lungime de 220m
1*Card dedicat IDS cu urmtoarele performante:
o S fie hotswap scoaterea acestuia sa nu afecteze funcionarea switch-ului
o In mod inline sa poat urmri trafic de minim 500MBps, minim 5000 sesiuni pe
secunda, minim 50.000 sesiuni concurente.
o Sa permit conectarea a 8 card-uri n acelai switch pentru cretere pana la 4GBps
a traficului urmrit n mod inline.
o Accesul la date sa se fac intern, prin capturarea cu access-list-uri de VLAN
o update-ului de semnturi pentru IDS pentru o perioada egala cu perioada de
garanie a echipamentului. Solicitam ca ofertanii sa includ cea mai noua
versiune de Sistem de Operare testata i recomandata de productor, mpreuna cu
serviciul de update i upgrade de versiune pe toata perioada de garanie a
echipamentului
1*Card dedicat de content switching cu urmtoarele performante :
o Pachete pe secunda procesate minim 6.5 milioane
 o Numr de partiii virtuale suportat minim 20
o Trafic SSL suportat min 6 Gbps
o Tranzacii pe secunda SSL min 30,000
o Realizeaz content switching n condiiile meninerii unui numr de 4.000.000
conexiuni;
o Numr minim de servere virtuale suportate 4000;
1*Card dedicat de firewall cu urmtoarele performante:
o Trafic suportat = minim 6Gbps;
o Sa poat fi instalat n mod redundant n switch minim 2 module;
o Sa utilizeze mecanism de protecie de tip adaptive security algorithm (ASA);
Montabil n Rack;
Capabiliti de management SSH;
Surse de alimentare modulare cu putere minima de 4000 W pe modul.
220V/50 HZ cu cordon electric pentru alimentare electrica conectabil n tablou electric
Arhitectura reelei de comunicaii este o componenta a arhitecturii sistemului informatic.
Sistemul de comunicaii este construit astfel nct sa rspund la cerinele sistemului general.
Sistemul de comunicaii de tip LAN trebuie furnizat i trebuie sa permit:
interconectarea echipamentelor solicitate
reeaua de date trebuie sa suporte stiva de protocoale TCP / IP V4 i V6
echipamentele hardware trebuie sa fie redundante n mod activ-activ i sa fie deja consolidate
pe cat posibil.
furnizorul trebuie sa livreze elementele hardware i software de reea, care sunt necesare
pentru funcionarea corecta i sigura a soluiei
viteza de interconectare intre switch-uri de minim 10Gbps
conexiuni redundante de la serverele cu interfee de minim 1Gbps
Reele i comunicaii software:
o Toate elementele de reea trebuie sa fie administrate (att la nivel local i la distana) de
ctre o soluie de management compatibila cu componente de reea oferite pentru
infrastructura
o Ofertantul va fi obligat sa ofere aceasta soluie de management al reelei, cu numrul
necesar de licene pentru ntreaga soluie.
o Soluia de management de reea este obligatoriu sa aib o componenta de
monitorizare/alarmare cu reguli de notificare via mail/SMS ce pot fi definite de utilizator.
Securitate reea
Conexiunile externe:
o trebuie protejate de cel puin cate un firewall. Este obligatoriu ca firewall-ul sa fie
redundant cel puin n modul activ-standby.
o arhitectura sistemului trebuie sa fie echipata cu cate un dispozitiv inline IPS / IDS,
senzori care vor fi plasai pe (cel puin) segmentul de reea conectat la interfaa interna(e)
a firewall-ului ce deservete conexiunile externe ale sistemului. Prin conexiuni externe
nelegem legturile cu alte reele, de genul internet sau reea WAN
o fiierele de log ale IPS / IDS trebuie sa fie arhivate pe un sistem de stocare i trebuie sa
fie disponibile minimum 3 ani.

6.2. Cerine software detaliate

6.2.1. Monitorizare sisteme i aplicaii

Descriere
Sistemul trebuie sa ofere capabiliti de monitorizare i management specifice diverselor
nivele ale unui mediu IT complex: sisteme, aplicaii, infrastructura de tip middleware, ajutnd
administratorii sa pstreze performanta i disponibilitatea aplicaiilor. Sistemul trebuie sa
ofere suport pentru optimizarea nivelelor de servicii i sa controleze costurile de operare a
aplicaiilor.

1.1.1.40. Subsistem monitorizare la nivelul sistemelor

Cerine
Soluia de monitorizare a sistemelor trebuie sa ofere urmtoarele capabiliti:
Capabilitatea de a monitoriza sisteme de operare Microsoft Windows, Unix (HP-UX,
IBM AIX, Sun Solaris) i Linux (RedHat, SLES). Colectarea datelor i analiza problemelor
trebuie sa se fac local pe sistem; colectarea datelor de pe sistemele monitorizate se va putea
face cel puin n doua moduri:
Prin utilizarea de tehnologii de tip agent
Prin utilizarea de tehnologii de tip agentless
De asemenea, platforma de monitorizare trebuie sa suporte capabilitatea de a utiliza
un agent care poate fi configurat n funcie de mediul pe care l monitorizeaz. Acest agent va
suporta tehnologii de tip SNMP, ODBC, Socket, flat files, log files, etc i va fi livrat
mpreuna cu o componenta de configurare de tip grafic (GUI).

Se vor oferi informaii istorice, agregate, despre:
Disponibilitatea sistemelor, cu rapoarte detaliate pe:
Ore
Zile
Sptmni
Capacitatea utilizata a sistemelor, cu rapoarte detaliate pe:
Ore
Zile
Sptmni
Performanta sistemelor, cu rapoarte detaliate pe:
Ore
Zile
Sptmni
Interfaa coerenta pe toate platformele i n toate funciile de administrare
Modele de monitorizare i alertare predefinite pentru toate sistemele i aplicaiile
suportate
Capabilitatea de administrare a tuturor resurselor de la o singura consola, accesibila
prin intermediul unui browser web, sau prin intermediul unui client care se instaleaz pe
staiile de lucru ale administratorilor, i care trebuie sa fie disponibil pentru sisteme de
operare Windows i Linux; de asemenea trebuie sa se ofere facilitatea unui client universal,
care sa utilizeze tehnologia Java.
Consolidarea informaiilor (evenimente) intr-o baza de date pentru analiza i raportare
ulterioara; modulul de raportare va fi inclus n produs, fr costuri adiionale; de asemenea
baza de date n care se va pstra istoricul va fi inclusa n produsul de monitorizare fr cerine
de liceniere adiionale
Modele de monitorizare pentru toate sistemele i aplicaiile suportate
Sa permit activarea/dezactivarea monitorizrii aplicaiilor fr ntreruperea
funcionarii acestora
Aplicaia trebuie sa ofere facilitatea de definire de fluxuri de lucru, care sa ofere
metode standard de adresare a problemelor detectate de ctre ageni pe sistemele
monitorizate; aplicaia de definire a fluxurilor de lucru va avea o interfaa grafica, n care
definirea fluxurilor sa se realizeze facil (de ex. drag & drop)
Emiterea de alerte: soluia trebuie sa poat emite alerte vizuale i auditive
 Prezentarea parametrilor monitorizai se va face n timp real, n mod grafic intuitiv, cu
posibilitatea de a modifica tipul graficului (bar, pie, chart, etc)
Aciuni corective: soluia trebuie sa se poat configura astfel nct sa execute aciuni
corective automate (fr intervenia administratorilor) n cazul detectrii de erori sau n cazul
degradrii performantelor.
Sa ofere capabiliti de pornire/oprire a proceselor / aplicaiilor de pe serverele
monitorizare
Agenii pentru fiecare sistem nu trebuie sa interfereze cu operaiile normale ale
sistemului pentru a nu afecta performantele acestuia i trebuie sa utilizeze la minimum
resursele sistemului pe care sunt instalai Capabilitatea de a trimite rezultatele obtinute in
urma colectarii datelor (obtinute prin capabilitati incluzand cel putin SNMP poll/trap, syslog,
WMI, ICMP Ping, sau utilizarea unor ageni dedicai tehnologiei monitorizate) catre un
modul specializat de corelare a evenimentelor, cu care functiile de monitorizare sa se
integreze nativ.
Posibilitatea de a defini mai muli administratori / utilizatori cu roluri diferite.
Soluia trebuie sa ofere un motor avansat de lucru cu reguli/politici care sa permit
administratorilor exact ce aciuni trebuie luate i cnd;
Soluia trebuie sa se poat integra cel puin cu urmtoarele surse de date:
Instrumente cu funcii de business service management, management evenimente,
CMDB, monitorizare, gestiune elemente
Interfee (industry-standard) Web Services, Extensible Markup Language (XML),
Simple Network Management Protocol (SNMP), Lightweight Directory Access Protocol
(LDAP)
Alte aplicaii via command-line, TCP/IP sockets, flat-file exports, e-mail
Soluia trebuie sa colecteze i sa prezinte datele generate n rapoarte
Soluia trebuie sa preia i sa prelucreze evenimentele n timp real
Soluia trebuie sa ofere un set de rapoarte predefinite ca i best practices (ex.
Grafice de disponibilitate, etc.)
Soluia trebuie sa ofere vizualizare uoara a rapoartelor generate, accesibile printr-o
integrata grafica WEB
Soluia trebuie sa suporte salvarea rapoartelor cel puin n urmtoarele formate:
o CSV
o HTML
 o PDF

1.1.1.41. Subsistem monitorizare aplicaii i infrastructura de

tip middleware
Soluia de monitorizare a aplicaiilor trebuie sa ofere urmtoarele capabiliti:
Sa se integreze nativ, n aceeai interfaa cu aplicaia de monitorizare a sistemelor
Sa permit definirea mai multor utilizatori cu roluri diferite de administrare
Sa ofere posibilitatea de definire a evenimentelor i alertarea automata a
administratorului bazei de date n momentul apariiei acestora
Sa ofere capabiliti de monitorizare configurabile, cu posibilitatea de a seta praguri
pentru avertizri i alerte critice
Sa aib posibilitatea de a oferi grafice de performana n timp real
Sa ofere posibilitatea configurrii sistemului de management astfel nct sa execute
aciuni automate, fr intervenia administratorilor, n momentul apariiei anumitor
evenimente
Sa integreze diferite utiliti i aplicaii pentru operarea eficienta a infrastructurii
oferite
Sa ofere administrare centralizata a elementelor de infrastructura i a aplicaiilor
pentru topologii complexe de servere de aplicaii (instane multiple, clustere de servere de
aplicaii)
Sa prezinte vizual toate componente instalate i inter-dependenele dintre acestea
Sa permit monitorizarea n timp real a serverelor de aplicaii compatibile cu
standardul Java 2 Enterprise Edition (J2EE) sau echivalent; capabiliti de colectare a
metricilor de execuie pentru urmtoarele tipuri de entiti:
o JavaServlets;
o Enterprise Java Beans (EJB);
o tranzacii;
o conexiuni la surse de date;
o cozi de mesaje;
o servicii web
Sa permit agregarea i prezentarea informaiilor corespunztoare execuiei fluxurilor i
serviciilor:
o numr de instane:
n execuie
 terminate cu succes
terminate cu eroare
timp mediu de procesare pentru instanele de procese sincrone i asincrone
o rapoarte predefinite pentru identificarea:
instanelor cele mai consumatoare de resurse
instanelor n ateptare
activitilor de proces cele mai consumatoare de resurse
Sa permit monitorizarea aplicaiilor Microsoft Active Directory, Internet
Information Server, SharePoint, Microsoft Internet Security and Acceleration Server, .NET
Framework, BizTalk Server, Hyper-V, MS Cluster Server
Sa ofere posibilitatea monitorizrii serverelor de mesagerie Microsoft Exchange i
IBM Domino Server
Sa permit monitorizarea de maini virtuale (de ex. VMware, Citrix, MS Virtual
Server)
Sa ofere posibilitatea monitorizrii serverelor de baze de date (de ex. Oracle,
Microsoft SQL Server, IBM DB2) sa ofere informaii despre:
o componente baze de date
o comenzi SQL euate
o cereri acces exclusiv al aplicaiilor (locks)
o disponibilitate tablespace
o performante SQL text
o utilizare cache (bufferhits)
o conexiuni folosite
o activitate fir de execuie (thread)
o blocaje acces concurent (deadlocks)
o acces concurenial la date (contention)
o erori I/O
o avertizri spaiu liber
o praguri cache
o avertizri acces exclusiv (locks)
o timpi de ateptare
o procentul de comenzi SQL euate
 sa prezinte datele colectate sub forma de tablouri de bord sugestive cu posibilitatea de
selectare a perioadei de monitorizare dorite
Colectarea metricilor de execuie se va face prin tehnologicii de tip agent cu impact
minim asupra performanei sistemelor monitorizate
Sa permit activarea/dezactivarea monitorizrii aplicaiilor fr ntreruperea
funcionarii acestora
Sa permit monitorizarea aplicaiilor fr modificarea acestora
Sa includ rapoarte predefinite pentru identificarea cererilor client cele mai
consumatoare de resurse
Sa includ rapoarte predefinite pentru identificarea componentelor aplicaiei cele mai
consumatoare de resurse
Sa ofere capabilitatea de a vizualiza att date n timp real cat i date istorice pentru
orice sistem prin intermediul consolei web i a interfeei GUI. Aplicaia trebuie sa ofere un
modul de raportare, inclus n pachet (fr cerine de liceniere adiionala); modulul de
raportare va pune la dispoziie un set de rapoarte predefinite cat i o aplicaie cu ajutorul
creia administratorii sistemului vor putea construi rapoarte,n mod grafic, intuitiv, utiliznd
un GUI.
Sa ofere posibilitatea monitorizrii platformelor de integrare, accelerare i securitate
SOA, oferind informaii cel puin n urmtoarele domenii:
o Gestiune servicii ale serverelor de aplicaie
o Sumar al erorilor, la nivel de operaiune
o Configuraii pentru primitive de mediere
o Mesaje primite
o Sumar al mesajelor, coninnd dimensiunea medie n octei a mesajelor, dup port,
numele operaiunii, tip (entitate solicitanta sau furnizor)
o Fluxuri operaionale
o Fluxuri operaionale pentru servere de aplicaii
o Fluxuri operaionale pentru operaiune selectata, prin agregarea la nivel de
combinaie port serviciu operaiune
o Sumar de performanta
o Sumar de performanta per identitate a entitii solicitante
 o Identiti ale entitilor solicitante pentru o anumita operaie selectata, ceea ce va
permite examinarea metricilor dup identitatea entitii solicitante pentru o
pereche specifica port serviciu operaiune.
o Posibilitatea configurrii pentru monitorizarea identitii entitii solicitante care
sa creeze i gestioneze lista tuturor identitilor de entiti solicitante ce vor fi
monitorizate.
o Sumar pe grupuri de servicii, dup criteriul apartenenei la aceeai funcionalitate
(sau aplicaie).

6.2.2. Help Desk (Sistem suport utilizatori)

Descriere
Modulul de Help-Desk trebuie sa elimine situaiile de neutilizare a sistemului datorate
diverselor incidente care pot aprea n exploatare.
Sistemul va permite preluarea, nregistrarea (automat sau manual) i urmrirea sesizrilor
privind funcionarea anormala a ntregului sistem informatic. Pentru a permite o nregistrare
eficienta modulul trebuie sa lucreze integrat funcional cu alte sisteme de monitorizare,
management de evenimente, reea, sisteme, etc.
Modulul va permite ca pe parcursul derulrii activiti de Help Desk, specialitii IT sa poat
nregistra modalitile de rezolvare pentru incidentele frecvent ntlnite sub forma de baza de
cunotine sau abloane de incidente, astfel nct la reapariia unui nou incident, modalitatea
de rezolvare sa fie deja nregistrata n subsistem i sa permit un rspuns prompt pentru prin
evitarea pailor de rediagnosticare.
Cerine
Soluia va fi conforma standardului ITIL V3.
Aplicaia va fi accesibila prin interfaa web securizata;
Aplicaia trebuie sa includ instrumente de control acces/declarare a drepturilor la
nivel de utilizator i grupuri de utilizatori acordate n concordanta cu atribuiile i
responsabilitile fiecruia.
Aplicaia va beneficia de un mecanism de auditare astfel nct orice operaiune
efectuata n sistem sa poat fi urmrita;
Va dispune de un mecanism pentru definirea i validarea unui flux de lucru unitar
conform standardului ITIL V3 dar i conform proceselor organizaiei pentru tratarea
incidentelor.
 Va permite administrarea fluxurilor de lucru n interfaa grafica web n mod drag-
and-drop cat i n mod text prin constructor de expresii. Modulul grafic trebuie sa pun la
dispoziia administratorului hrile fluxurilor de lucru.
Va permite administrarea structurii aplicaiei i a bazei de date n interfaa grafica web
(application and database designer)
Va permite definirea de abloane ale activitilor tipice de management al incidentelor
Va permite crearea unei scheme de utilizatori bazate pe grupuri i roluri
Va oferi posibilitatea de alocare a responsabilitilor n rezolvarea incidentelor n
funcie de organigrama
Va oferi posibilitatea de nregistrare i de transferare manuala sau automata a
tichetelor
Va oferi posibilitatea de planificare i urmrire a activitilor necesare n vederea
rezolvrii incidentelor
Va oferi posibilitatea de discuie on-line pe baza incidentelor
Va oferi posibilitatea de evaluare a rezolvrii incidentelor prin sondaje (survey) cerere
de aprobare de la utilizator pentru rezolvare sau de la nivelul superior de suport.
Va feri posibilitatea nregistrrii aciunilor efectuate i a soluiilor gsite n vederea
pstrrii istoricului i a constituirii bazei de cunotine (Knowledge Base & Incident
Template)
Va oferi posibilitatea de alocare a incidentelor pe echipamente sau componente ale
echipamentelor
Va oferi posibilitatea de urmrire a timpilor de rspuns i de rezolvare a incidentelor
prin grafice sau alerte (indici de performanta KPIs (Key Performance Indicators) & SLAs )
Service Level Agreement
Va oferi posibilitatea tratrii diferite a incidentelor n funcie de categoria la care se
refera (hardware, software, reea) i de impactul acestora asupra funcionarii organizaiei
Va oferi posibilitatea meninerii i regsirii informaiilor despre modul de rezolvare a
diverselor tipuri de incidente
Va permite stocarea informaiilor necesare n vederea realizrii rapoartelor, analizelor
i previziunilor privitoare la ratele de defectare, tipurile de defecte, etc. referitoare la
echipamentele care intra n componenta sistemului IT de proces sau la componente ale
acestor echipamente

6.2.3. Salvare i restaurare

Descriere
Soluia de backup, centralizare i restaurare trebuie sa asigure o protecie eficienta a datelor
mpotriva erorilor prin stocarea copiilor de salvare i arhivare pe medii de stocare n regim
offline. Aceasta trebuie sa fie scalabil, putnd asigura protecia de sisteme cu sisteme de
operare diverse, sa permit administrare centralizata prin web, sa ofere tehnologii de stocare
i transfer inteligent de date, precum i definirea de politici de automatizare cu rol benefic n
reducerea costurilor de administrare i a impactului asupra sistemelor de calcul i a reelei.
Cerine
Soluia trebuie sa asigure salvarea i arhivarea datelor, restaurarea, i extragerea
acestora.
Aplicaia trebuie sa permit efectuarea de operaiuni back-up doar pentru fiierele
care au suferit schimbri de la ultimul back-up i pentru fiierele nou create. Pentru sisteme
de fiiere FAT/NTFS, soluia trebuie sa fie capabila de a salva doar poriunea modificata a
unui fiier.
Administrarea soluiei de back-up trebuie sa se poat realiza prin intermediul unei
interfee web care sa poat gestiona mai multe servere de back-up, indiferent de platforma pe
care ruleaz acestea.
Clienii de back-up trebuie sa fie accesibili prin intermediul unei interfee web, astfel
nct administratorii sa aib la dispoziie un mecanism facil de operare de la distanta.
Soluia trebuie sa dispun de un model de administrare flexibil i sa permit accesul
mai multor utilizatori (administratori i operatori), fiecare cu nivel de autorizare diferit.
Soluia de back-up trebuie sa asigure copii de sigurana pentru mai multe versiuni ale
aceluiai fiier, astfel nct sa ofere posibilitatea restaurrilor selective.
Soluia trebuie sa fie capabila de a terge copiile de sigurana ale versiunilor expirate
ale fiierelor (in conformitate cu politica de back-up) astfel nct sa se elibereze spaiu pe
mediile de stocare (benzi).
In cazul n care n timpul procesului de back-up/restore conexiunea dintre client i
server se ntrerupe, soluia trebuie sa fie capabila de a relua acest proces din momentul
ntreruperii i nu de la nceput.
Soluia trebuie sa includ mecanisme de duplicare a datelor att la nivel de client cat
i la nivel de server.
Soluia trebuie sa includ mecanisme de salvare/restaurare de tip LAN-free.
Soluia trebuie sa includ mecanisme de salvare/restaurare de tip online (fr
ntreruperea serviciilor) pentru baze de date.
 Soluia trebuie sa fie capabila de criptarea datelor transmise de la client la server n
timpul procesului de backup/restore.
Aplicaia trebuie sa permit setarea perioadelor de pstrare a datelor salvate, n funcie
de timpul la care a fost realizat backup-ul.
Aplicaia trebuie sa genereze rapoarte referitoare la operaiunile de salvare / restaurare
i sa ofere posibilitatea de a trimite aceste rapoarte prin mecanisme e-mail.
Soluia trebuie sa fie compatibila (att la nivel de server cat i la nivel de ageni) cu
urmtoarele platforme: Windows Server (2003 & 2008 Std, Advanced), Linux (RedHat
RHEL i Suse SLES), AIX i Solaris.
Soluia trebuie sa suporte o mare varietate de medii de stocare, independent de
productor pentru toate platformele suportate.

6.2.4. Gateway de Securitate

Descriere
Platforma de securitate va oferii funcii pentru politici de securitate, control al accesului i
reverse proxy i va suporta nativ standardul XML, acesta fiind un mecanism fundamental
de asigurare a interoperabilitii n cadrul soluiei.
Dimensionare
Modulul trebuie sa suporte un trafic cumulat intre 200 Mbits/sec i 700 Mbits / sec, i pana la
25000 de conexiuni concurente (acestea includ conexiunile utilizatorilor, aplicaiilor integrate
din intranet i internet). Trebuie furnizate rezultate alte testelor de laborator cu descrierea
scenariilor de test i a condiiilor n care s-au fcut aceste msurtori.
Cerine
Platforma trebuie sa ofere urmtoarele capabiliti:

Sa fie uor de instalat i configurat oferind pentru aceasta o interfaa web, interfaa
grafica dedicata, bazata pe standarde deschise, precum i interpretor pentru linia de comanda.
Sa ofere funcii de securitate la nivel de mesaj i control al accesului astfel nct
mesajele sa poat fi:
Filtrate
validate ( validare de schema XML, validare conform WSDL a serviciilor web,
filtrare SOAP)
criptate (criptarea trebuie sa poat fi aplicata la nivel de mesaj la nivel de cmp al
mesajului)
 semnate
Sa suporte conectarea la tehnologii Web 2.0 cu filtrare i validare JSON, suport pentru
verbe REST i conectare la REST i Servicii Web.
Sa permit autentificarea mesajelor de tip servicii web folosind standardele WS-
Security i SAML 2.0.
Sa ofere configurarea cu uurina a securitii ca firewall de aplicaii web, pentru a
asigura protecie mpotriva atacurilor din perimetrul WEB ( cross-site scripting, SQL
injection, alte atacuri XML).
Sa ofere virtualizare pentru servicii web.
Sa ofere suport pentru urmtoarele infrastructuri de chei publice (PKI): XKMS, RSA,
3DES, DES, AES, SHA, X.509, PKCS, CRLs, OCSP
Sa ofere suport pentru urmtoarele tehnologii:
WS-SecureConversation
WS-Policy
WS-ReliableMessaging
WS-SecurityPolicy
WS-SecureConversation
WS-Trust
SAML
LDAP
SOAP
WSDL
XAML
Sa ofere interoperabilitate cu registri de descriere universala, descoperire dinamica i
integrare a serviciilor web (UDDI).
Sa ofere suport pentru implementarea mecanismului SSO (Single Sign On) pentru
servicii web.
Funcionalitatea de reverse proxy trebuie sa ofere suport pentru Split SSL
Certificate.
Funcionalitatea de reverse proxy trebuie sa suporte urmtoarele metode de
autentificare:
Nume de utilizator/parola;
Certificate Client x.509 V3;
Autentificare cu token;
 Autentificare NTLM;
LDAP
Funcionalitatea de reverse proxy trebuie sa ofere suport pentru autentificare cu doi
actori de autentificare, prin dispozitive hardware (hardware tokens) i combinarea a doua
metode de autentificare cu factor singular precum certificatele X.509 i nume de
utilizator/parola.
Trebuie sa ofere suport pentru urmtoarele protocoale de transport:
HTTP
HTTPs
FTP
NFS
SOAP/HTTP(s)
Sa permit implementarea de funcii de tip AAA ( Autentificare, Autorizare,
Auditare).
Din motive de securitate i protecie, platforma gateway de securitate nu trebuie sa
permit instalarea de alte componente software sau alte aplicaii altele dect cele autorizate
de productor.

6.2.5. Integrare aplicaii

Descriere
Platforma de integrare trebuie sa furnizeze funciile de transformare de mesaje, interconectare
cu aplicaiile din intranet i internet n condiii de securitate i nalta performanta, astfel nct
sa nu necesite modificarea aplicaiilor existente n cadrul soluiei integrate.
Dimensionare
Trebuie sa ofere parametri de performanta ridicata pentru funciile de transformare a
mesajelor, putnd fi folosita pentru descongestionarea serverelor de aplicaii prin preluarea
funciilor de procesare XSLT, rutare Xpath, conversie a mesajelor XML i a altor funcii
consumatoare de resurse pentru a reduce capacitatea de transfer i pentru a asigura un timp de
rspuns ridicat.
Astfel, va trebui sa suporte un trafic cumulat intre 200 Mbits/sec i 700 Mbits / sec, i pana la
25000 de conexiuni TCP (acestea includ conexiunile utilizatorilor, aplicaiilor integrate din
intranet i internet). Trebuiesc furnizate rezultate alte testelor de laborator cu descrierea
scenariilor de test i a condiiilor n care s-au fcut aceste msurtori.
Cerine
 Sa ofere suport de transformare a mesajelor de tip binar, text, XML, CVS.
Mecanismul de transformare trebuie sa fie bazat pe metode declarative i sa utilizeze meta-
date.
Sa ofere suport pentru validarea din punct de vedere tehnic a mesajelor (verificri de
sintaxa, XML schema);
Sa ofere funcii de securitate la nivel de mesaj i control al accesului astfel nct
mesajele sa poat fi:
Filtrate
validate (validare de schema XML, validare conform WSDL a serviciilor web, filtrare
SOAP)
criptate (criptarea trebuie sa poat fi aplicata la nivel de cmp al mesajului)
semnate digital
Sa permit autentificarea mesajelor de tip servicii web folosind standardele WS-
Security i SAML 2.0.
Sa ofere suport pentru urmtoarele standarde la nivel de chei publice (PKI): XKMS,
RSA, 3DES, DES, AES, SHA, X.509, PKCS, CRLs, OCSP
Sa ofere suport pentru urmtoarele tehnologii:
WS-SecureConversation
WS-Policy
WS-ReliableMessaging
WS-SecurityPolicy
WS-SecureConversation
WS-Trust
SAML
LDAP
SOAP
Sa ofere suport pentru implementarea mecanismului de SSO (Single Sign On) pentru
servicii web.
Sa ofere interoperabilitate cu registri de descriere universala, descoperire i integrare a
serviciilor web (UDDI).
Sa ofere metode grafice de definire a funciilor de procesare a mesajelor fcnd
posibila implementarea urmtoarelor scenarii:
Rutare complexa de mesaje n mai muli pai pe baza sursei, destinaiei i a
coninutului mesajului
 Filtrare
Algoritmi de procesare folosind decizii logice, bucle (loops), procesare paralela,
mecanisme de rencercare n caz de eroare.
Trebuie sa ofere suport pentru urmtoarele protocoale de transport:
HTTP
HTTPs
JMS
MQ
ODBC
FTP
Stateful RAW TCP
Stateless RAW TCP
IMS Connect
NFS
TIBCO EMS
Web Services proxy (SOAP/HTTP(s), SOAP/JMS)
Suport pentru jurnalizare, incluznd iSCSI pentru conectivitate ctre discuri externe.
Sa permit implementarea de funcii de tip AAA ( Autentificare, Autorizare,
Auditare).
Sa permit implementarea de arhitecturi de cluster de tip activ activ cu balansare de
trafic sau activ pasiv; deasemenea in ceea ce priveste balansarea, componenta trebuie sa
permita distribuia inteligent a cererilor ctre mai multe servere de aplicaii, cu modificri
dinamice ale membrilor, prioritii i afinitii.
Din motive de securitate i protecie, platforma de integrare nu trebuie sa permit
instalarea de alte componente software sau alte aplicaii altele dect cele autorizate de
productor.
Sa fie uor de instalat configurat oferind pentru aceasta o interfaa web, interfaa
grafica dedicata bazata pe standarde deschise cat i interpretor pentru linia de comanda

6.2.6. Server de Procese

Descriere
Serverul de procese va juca rolul de motor cu performanta ridicata, care mrete
flexibilitatea proceselor funcionale, oferind capabiliti puternice de rulare fluxuri cu
activitati umane.
Construit pe baza de standarde deschise, acesta trebuie sa implementeze i execute procese,
care orchestreaz servicii.
Serverul de procese trebuie sa ofere capabiliti pentru:
Reacie dinamica la cerinele de schimbare ale activitilor funcionale, cu
posibilitatea instalrii de noi versiuni de procese i migrarea proceselor n curs de execuie la
noile versiuni.
Scenarii pentru fluxuri umane adiionale, incluznd aprobri paralele cu voturi i
agregri de rezultate.
Scenarii avansate cum ar fi secvene de proces (tasks) adresate unor responsabili
umani, fluxuri, gestionare escaladri, filtrri ad-hoc , etc.
Capabiliti mbogite de a gestiona procesele n curs de execuie, cum ar fi
schimbarea responsabilului unui proces i capabiliti avansate de corectare a procesului.
Cerine
Serverul de procese trebuie sa implementeze standardul BPEL i BPMN.
Serverul de procese trebuie sa ofere posibilitatea captrii de date n timp real din orice
baza de date, coada de mesaje sau aplicaie.
Serverul de procese trebuie sa ofere posibilitatea definirii de indicatori i obiecte n
scopul analizei.
Serverul de procese trebuie sa ofere posibilitatea auditrii fluxurilor executate sau n
curs de execuie;
Serverul de procese trebuie sa permit administrarea domeniilor de fluxuri
electronice;
Serverul de procese trebuie sa permit generarea periodica de rapoarte pre-formatate
sau generate la cerere.
Serverul de procese trebuie sa suporte implementarea proceselor de tip sincron
(short-running) ct i a celor de tip asincron (long running - necesit intervenia
utilizatorilor)
Serverul de procese trebuie sa permit implementarea i rularea proceselor
tranzacionale (commit/rollback) pentru procesele de tip short running
Serverul de procese trebuie sa ofere mecanisme de compensare a tranzaciilor pentru
procesele de tip long-running. Pentru fiecare pas de execuie, sau secvena de pai de
execuie a procesului, trebuie sa ofere posibilitatea de a defini o aciune compensatorie /
opusa.
 Serverul de procese trebuie sa ofere mecanisme de gestionare a erorilor. Acest
mecanism trebuie sa fie capabil sa declaneze i mecanismele de compensare descrise mai
sus.
Serverul de procese trebuie sa ofere posibilitatea includerii de cod Java in-line direct
n fluxurile de procese.
Serverul de procese trebuie sa ofere posibilitatea de a include i defini module
funcionale n cod Java .
Serverul de procese trebuie sa ofere suport pentru integrarea aciunilor utilizatorilor ca
pai de execuie ai procesului.
Serverul de procese trebuie sa ofere posibilitatea definirii de task-uri utilizator att
pe baza standardului BPEL (Business Process Execution Language) cat i separat ca servicii
independente.
Serverul de procese trebuie sa permit administrarea aciunilor utilizatorilor pe baza
de roluri de utilizatori.
Serverul de procese trebuie sa ofere posibilitatea definirii n standard JSP sau pe baza
de portlei a interfeelor grafice pentru execuia aciunilor utilizatorilor.
Serverul de procese trebuie sa ofere suport pentru interfee de tip formulare
electronice.
Serverul de procese trebuie sa permit crearea ad-hoc, transferul i tergerea
activitilor delegate unor utilizatori.
Serverul de procese trebuie sa ofere posibilitatea de a defini i administra reguli
funcionale printr-un instrument adresat personalului fr atribuii de tehnice.
Serverul de procese trebuie sa ofere capabiliti de integrare de tip magistrala de
servicii (ESB) i capabiliti de server de aplicaie J2EE.
Serverul de procese trebuie sa permit rularea de procese de integrare cu alte sisteme
informatice, de tip magistrala de servicii (ESB) i procese care necesita o execuie de tip
straight-through cu performanta ridicata.
Serverul de procese trebuie sa permit pattern-uri de mesaje i protocoale, cum ar fi
publish/subscribe, synchronous/asynchronous i topics/queues.
Serverul de procese trebuie sa ofere suport complet pentru persistenta mesajelor
Serverul de procese trebuie sa permit integrare la nivel de standard FTP, fiier i baza
de date, nativ sau cu adaptori.
Serverul de procese trebuie sa permit rularea de procese colaborative.
 Serverul de procese trebuie sa permit documentarea proceselor i gestionarea
acestora intr-o locaie unica de stocare.
Serverul de procese trebuie sa permit gestionarea listei de secvene de proces cu
responsabil uman, aprobri, notificri, escaladri, rutri seriale, paralele, ad-hoc.
Serverul de procese trebuie sa permit integrarea cu alte sisteme utiliznd diferite
metode cum ar fi apeluri de servicii web, sau un framework pentru adaptori bazat pe
standarde deschise.
Serverul de procese trebuie sa ofere un mod centralizat de gestiune a politicilor de
securitate (autentificare, autorizare, criptare, decriptare) peste portofoliul de fluxuri
electronice instalat.
Serverul de procese trebuie sa ofere o componenta de monitorizare a activitilor
pentru analiza proactiv i monitorizare a SLA-urilor.
Serverul de procese trebuie sa ofere suport pentru emiterea i tratarea evenimentelor.
Serverul de procese trebuie sa permit ca mai multe versiuni ale aceluiai proces sa
coexiste n mediul de rulare(rularea in paralel a mai multor versiuni). Serverul trebuie s
ofere designerilor de proces posibilitatea de a gestiona si guverna versiunile proceselor,
printr-un mediu incorporat, centralizat de stocare, instalare i control al proceselor de
business, care s fie accesat nativ att de mediile de modelare i implementare a proceselor de
business, ct i de mediul de execuie. Deasemenea soluia trebuie s ofere o interfa
colaborativa utilizatorilor de business i IT, prin care toate persoanele s poat accesa aceai
versiune de proces. In plus, soluia trebuie s permit modificri majore asupra unei activiti
de proces, in timp ce acesta se afl in execuie, iar activitatea trebuie s se ruleze conform
noilor modificri
Serverul de procese trebuie sa ofere o interfaa web prin care utilizatorii sa vizualizeze
istoricul i starea secvenelor de proces desfurate, fr a rula un anumit proces
Serverul de procese trebuie sa ofere o interfaa web prin care utilizatorii pot
monitoriza procesele, administra propriile sarcini, vizualiza i modifica tablouri de bord cu
identificatorii definii, sau vizualiza i defini alerte bazate pe diferite condiii.
Serverul de procese trebuie sa ofere suport pentru o interfata bazata pe standardul
AJAX (Asynchronous JavaScript and XML) utilizand o tehnologie flexibila, de tip mash-
up pentru a permite designerilor de procese sa creeze si personalizeze experienta de utilizare
a responsabililor umani din cadrul procesului
Serverul de procese trebuie sa ofere o interfata web prin care designerii de procese sa
poata lucra cu / vizualiza / modifica regulile de proces
 Serverul de procese trebuie sa permit rutarea dinamica a sarcinilor pe baza de diferite
criterii.
Serverul de procese trebuie sa ofere posibilitatea de interaciune cu entitile de lucru
prin email.
Serverul de procese trebuie sa ofere securitate bazata pe Single Sign-On (SSO)
Serverul de procese trebuie sa permit modificarea dinamica a regulilor de proces la
rulare.
Serverul de procese trebuie sa suporte definirea i rularea de seturi de reguli de proces
i tabele de decizie
Serverul de procese trebuie sa ofere o infrastructura care sa permit mecanisme de
disponibilitate nalta i mecanisme de tolerare a erorilor de sistem.
Serverul de procese trebuie sa permit distribuirea cererilor pe baza de coninut.
Serverul de procese trebuie sa ofere autorizare i control al accesului, pe baza de
roluri, grupuri i politici de drepturi.
Serverul de procese trebuie sa permit integrarea cu un mediu extern de gestionare al
autentificrii i identitii.
Serverul de procese trebuie sa fie compatibil cu standardele XML Parser, XML
Transformer, WSDL 1.1, XPath 1.0 i XSD, SOAP/HTTP, SOAP/JMS.
Serverul de procese trebuie sa fie compatibil cu standardul JCA pentru conectarea la
sisteme externe.
Serverul de procese trebuie sa fie compatibil cu o gama larga de adaptori de
tehnologie i aplicaii ( SAP, Oracle, PeopleSoft, etc.)
Serverul de procese trebuie sa ofere compatibilitate pentru modele de programare
bazate pe standardele SDO i SCA.
Serverul de procese trebuie sa permit relaionare ntre servicii i obiecte aplicative
Serverul de procese trebuie sa suporte cel puin standardele:
WS-Addressing
WS-ReliableMessaging
WS-Trust
WS-Security 1.1
WS-Atomic Transaction
WS-Policy
WS-Coordination
WS-Federation
 WS-BPEL 1.1
UDDI 3.0
XACML
SAML 1.0
X.509
Xpath 1.0
XPDL
JAX WS
SCA i SDO
SAAJ 1.3
Serverul de procese trebuie sa permit orchestrarea serviciilor web disponibile intr-un
proces aplicativ complet.
Serverul de procese trebuie sa ofere posibilitatea monitorizrii grafice a instanelor de
proces.
Serverul de procese trebuie sa ofere cutarea cu filtrare avansata a instanelor de
proces.
Serverul de procese trebuie sa ofere posibilitatea crerii de perspective personalizate
pentru gestionarea de procese aplicative coninnd secvene de proces (tasks) cu
responsabili umani.
Serverul de procese trebuie sa ofere posibiliti de scalare pentru a permite creterea
numrului de procese i a utilizatorilor sistemului.
Serverul de procese trebuie sa suporte o arhitectura de tip cluster.
Serverul de procese trebuie sa ofere capabiliti de tip fail-over automat.
Serverul de procese trebuie sa ofere o balansare a ncrcrii la nivel de protocol web
i aplicaie.

6.2.7. Registru servicii

Descriere
Modulul catalog de servicii are rolul de a implementa guvernarea ciclului de viata al
serviciilor, n cadrul arhitecturii orientate pe servicii (SOA) a sistemului integrat.
Flexibilitatea unui astfel de model arhitectural impune adoptarea unor soluii de guvernare
proactiv a ciclului de viata al serviciilor.
Ca atare, modulul trebuie sa ofere capabiliti de gestionare a interaciunilor cu serviciile
oferite de entitile aplicative ale sistemului i a dependentelor intre servicii prin gestionarea
politicilor, versionrii, clasificrii i a utilizrii acestora pe baza unui proces comprehensiv de
management al ciclului lor de viata.
Modulul trebuie sa faciliteze stocarea, accesarea i gestionarea informaiilor (meta-date
servicii) astfel nct clientul sa poat cu uurina sa selecteze, sa apeleze i sa reutilizeze
serviciile.
Cerine
Administrarea ciclului de viata a fluxurilor i serviciilor modelate se va realiza utiliznd o
soluie de tip registru de servicii (service registry), cu cel puin urmtoarele caracteristici:

Posibilitatea definirii de taxonomii care sa permit clasificarea serviciilor repertoriate

din punct de vedere funcional i tehnic.
Interfaa cu utilizatorii de tip web care sa permit manipularea catalogului de servicii,
cu acces pe baza de roluri.
Definirea i gestionarea unui ciclu de viata pentru fiecare serviciu n parte, precum i
cutarea i utilizarea unui anumit serviciu n funcie de starea n care se afla sau alte
proprieti.
Versionarea serviciilor, precum i interogarea catalogului n funcie de versiunea
serviciului cutat.
Executarea unor analize de impact pentru a identifica interdependenta serviciilor intre
ele, precum i care ar fi impactul unei modificri la nivelul unui anumit serviciu.
Posibilitatea federalizrii cu alte cataloage de servicii.
Integrare nativa cu instrumentele de modelare i implementare oferite n cadrul
soluiei, incluznd serverul de procese, pentru facilitarea cutrii statice i dinamice a
serviciilor pe baza valorilor anumitor proprieti.
Disponibilitate ridicata 24x7 pentru registrul de servicii cu suport pentru topologii de
clustering de tip activ-activ i activ-pasiv.
Mecanisme care sa ofere scalabilitate pe orizontala (scale-out) i verticala (scale-
up) a sistemului.

6.2.8. Portal
Descriere
Platforma de tip Portal va avea rolul de a furniza un singur punct de interaciune
personalizata a utilizatorilor cu sistemul i va conine cel puin urmtoarele funcionaliti, ce
nu vor impune necesitatea achiziionrii de licene suplimentare:
 server de aplicaie
server HTTP
componenta software pentru balansarea ncrcrii
sistem de gestiune al bazelor de date relaionale
director LDAP
componenta pentru dezvoltare aplicaii i extindere funcionaliti n portal
componenta pentru managementul coninutului web
componenta pentru cutare
Cerine
Caracteristici generale
Serviciile de tip REST pentru crearea de aplicaii compozite, aplicaii mash-up cu
servicii de feed provenite de la alte aplicaii web .
Agregare la nivel client ce reduce procesarea la nivel server i mbuntete
performanta pentru utilizatorul final.
Sa pun la dispoziie abloane predefinite pentru configurarea rapida a portalului, att
pentru internet cat i pentru intranet.
Portalul va pune la dispoziie portlei configurabili de tip Workflow Task List pentru
o furnizare rapida i personalizata a proceselor integrate n aplicaiile portalului.
Platforma va oferi fiabilitatea ridicata, scalabilitate, securitate i administrarea uoara.
Platforma va oferi suport pentru implementarea de nalta performanta i
disponibilitate.
Portalul va oferi suport pentru SSO (Single Sign-On).
Portalul va permite utilizatorilor sa se autentifice cu o metoda de autentificare robusta,
care sa furnizeze nivele multiple de securitate.
Suportul pentru cele mai recente standarde deschise pentru obiecte de tip portlet (JSR
286, WSRP 2.0).
Portalul va oferi posibilitatea de a incorpora uor aplicaii Web existente.
Utilizatorii vor putea vizualiza, partaja i organiza fiiere de orice tip n cadrul
portalului. Se vor putea configura rapid biblioteci de documente astfel nct administratorii sa
poat partaja rapid coninut media, utiliza funcionaliti de configurare a meta-datelor i a
gestiona versiuni de documente. Documentele vor putea fi accesate de utilizatori direct din
browser web sau din diveri portlei
Portalul va oferi funcionaliti de cutare n cadrul acestuia.
 Portalul va include o soluie de formulare electronice pentru eficientizarea proceselor
i pentru a economisi hrtia. Se permite astfel utilizatorilor sa completeze, salveze i
vizualizeze formulare direct din interfaa portalului.
Portalul va oferi utilizatorilor portalului instrumentul necesar pentru mesagerie
instantanee n cadrul acestuia.
Interfaa
Trebuie sa existe servicii de prezentare care sa permit particularizarea interfeei
pentru fiecare ablon de lucru sau rol din echipa.
Este necesar ca interfaa portalului sa fie separata, din punct de vedere logic, de codul
aplicaiilor integrate, aa nct n cazul actualizrii unei aplicaii, sa se pstreze toate
particularizrile efectuate anterior asupra interfeei.
Utilizatorii trebuie sa poat vizualiza, crea, converti sau edita documente, tabele de
calcul i fiiere tip prezentare, direct din mediul de lucru portal, fr a avea nevoie de
instrumente adiionale.
Interfaa web a portalului trebuie sa ofere o experiena de lucru utilizatorilor incluznd
tehnologii n domeniu cum ar fi AJAX, servicii REST.
Coninutul accesat prin portal trebuie sa fie automat afiat sau ascuns, pe baza
rolurilor utilizatorilor, roluri care sunt predefinite.
Utilizatorii trebuie sa aib posibilitatea de a particulariza pagina de intrare n portal,
funcie de preferine.
Soluia trebuie sa permit administratorului sa specifice aplicaiile (portleii)
obligatorii pentru paginile ce pot fi personalizate.
Administratorii trebuie sa poat controla drepturile utilizatorilor de a particulariza
propriile pagini, funcie de rolul acestora, sau funcie de regulile definite.
Utilizatorii trebuie sa aib posibilitatea de a aduga portleii pe pagina printr-o
funcionalitate de tip drag-and-drop din paleta de portlei disponibila.
Dezvoltare/extindere funcionaliti
Platforma portal trebuie sa furnizeze un instrument dedicat de dezvoltare pentru
aplicaii web i portlei.
Instrumentul de dezvoltare trebuie sa conin componente software adaptate, ce
genereaz cod (incluznd Java, JSP i XML) pentru o funcionalitate de aplicaie specifica,
astfel nct sase poat crea aplicaii web sau portlei fr a fi nevoie de a se scrie cod.
Soluia trebuie sa ofere API-uri (Application Programming Interfaces) bine definite
pentru integrarea cu aplicaiile existente.
 Dezvoltarea aplicaiilor trebuie realizata intr-un mediu standardizat, ca de exemplu un
mediu J2EE.
Sistemul trebuie sa conin instrumente dedicate pentru construirea portleilor
Instrumentele de dezvoltare trebuie sa ofere suport pentru urmtoarele standarde:
XML, XSL, HTML, JSP, CSV.
Soluia trebuie sa ofere posibilitatea utilizrii serviciilor web pentru a expune date i
funcionaliti ctre sistemele externe portalului.
Soluia trebuie sa permit comunicarea i notificarea evenimentelor intre portlei.
Trebuie oferita posibilitatea de a declana comunicarea intre portlei la aciunea
utilizatorului sau automat n urma unui eveniment.
Administrare
Administrarea platformei portal i a componentelor sale trebuie sa poat fi realizata
prin intermediul unui browser web.
Sistemul trebuie sa conin mecanisme de tip asistent (wizard) pentru configurri
avansate, cel puin pentru configurarea cu sisteme de baze de date, mutarea bazelor de date,
configurarea cu sisteme LDAP sau sistem de mesagerie instantanee.
Suport pentru delegarea administrrii pentru controlul accesului.
Sistemul portal trebuie sa permit folosirea de politici (colecii de configurri) pentru
administrarea a cel puin urmtoarelor componente: utilizatori, grupuri, aplicaii, teme web.
Securitate
Sistemul portal trebuie sa conin propriul sistem LDAP, dar sa permit integrarea i
cu alte sisteme de tip LDAP.
Sistemul portal trebuie sa conin propriile mecanisme pentru autentificare,
autorizare, autentificare unica (Single Sign-On) i SSL, dar sa permit i integrarea cu alte
soluii de securitate existente.
Sistemul trebuie sa dea utilizatorilor posibilitatea de a se auto-nregistra n sistem.
Soluia trebuie sa permit de-logarea automata sa ofere un mecanism prin care un
utilizator sa fie de-logat n cazul n care nu a mai efectuat nicio tranzacie intr-o anumita
perioada de timp (interval ce poate fi setat de administrator).
Sistemul de portal trebuie sa permit utilizarea profilelor de utilizatori,
administratorul putnd seta astfel preferine att la nivel de profil, grup cat i la nivel de
utilizator. Aceste preferine trebuie sa specifice att accesul pe care l vor avea utilizatorii la
diverse poriuni ale portalului cat i drepturile asupra acestor zone.
Soluia trebuie sa ofere suport pentru securitate n tehnologie Java.
Standardizare
Soluia trebuie sa aib o arhitectura deschisa.
Sistemul trebuie sa fie compatibil cu urmtoarele standarde n domeniu: WSRP, JSR-
168, JSR-286
Soluia trebuie sa aib la baza i alte standarde n domeniu, ca de exemplu: Java 2
Enterprise Edition (J2EE), XML, suport pentru servicii web.
Sistemul sa fie flexibil din punct de vedere al clientilor de tip browser, al sistemelor
de operare i al suportului pentru bazele de date.
Scalabilitate, disponibilitate ridicata, performanta
Soluia trebuie sa ofere posibilitatea de a implementa portalul intr-un mediu cluster,
avnd posibilitatea de a realiza balansarea ncrcrii, fr componente software sau hardware
adiionale.
Soluia pentru portal trebuie sa ofere capabiliti de preluare a utilizatorilor pe un alt
nod, n cazul unei ntreruperi hardware de funcionare (failover).
Sistemul portal trebuie sa ofere capabiliti tip caching pentru performante ridicate.
Sa permit suport nativ pentru realizarea serviciilor de cache dinamic
Platforma
Platforma portal trebuie sa poat fi implementata pe cel puin urmtoarele platforme
sistem de operare: Microsoft Windows 2003, Microsoft Windows 2008, Linux (SUSE,
RHEL), IBM AIX, Solaris SPARC, Solaris x64, HP-UX.
Platforma portal trebuie sa permit implementarea att pe sisteme de operare x32 cat
i x64.
Sa suporte cel puin urmtoarele platforme de baze date: Oracle, IBM DB2, MS SQL
Server
Management site-uri i coninut web
Sistemul trebuie sa permit crearea de abloane de aplicaii cu portlei direct din
interfaa web.
Facilitai de tip asistent creare site (wizard) pentru a crea rapid, din interfaa web, site-
uri web pe baza unor abloane existente.
Soluia trebuie sa includ un instrument pentru publicarea de coninut, pentru a
permite utilizatorilor privilegiai sa publice, sa actualizeze sau sa tearg propriile pagini,
intr-un mod simplu i facil.
Soluia trebuie sa permit editarea coninutului direct n pagina n care este publicat.
 Pentru coninutul publicat, trebuie sa se stocheze data publicrii, data la care trebuie
arhivat i data la care documentul respectiv nu mai este valabil, cu scopul de a permite
adugri sau tergeri automate.
Soluia trebuie sa ofere o modalitate simpla de administrare centralizata, att pentru
administratorii de coninut cat i pentru deintorii de privilegii de aprobare de coninut.
Accesul la coninut se va face n funcie de utilizatorul care vizualizeaz datele.
Formatarea coninutului trebuie realizata pe baza de abloane (templates).
Soluia trebuie sa ofere capabiliti de control al versiunilor i arhivare.
Soluia trebuie sa ofere posibilitatea de a extrage coninut direct din baza de date.
Interfaa cu utilizatorul trebuie sa ofere asistenta pentru formatarea documentelor,
astfel nct utilizatorii fr cunotine de limbaj HTML sa poat contribui la publicarea de
informaii.
Soluia trebuie sa suporte structuri ierarhice de navigare arborescenta pentru
documente.
Documentele trebuie sa fie securizate fr a exista posibilitatea de a fi accesate n
absenta autentificrii.
Sistemul trebuie sa permit planificarea publicrii de coninut.
Soluia trebuie sa asigure ca structura de stocare este separata de structura de navigare
printre documente (navigarea n site nu trebuie sa reflecte n mod necesar modul de
clasificare i stocare al documentelor).
Soluia trebuie sa ofere capabiliti de publicare i personalizare de coninut direct
dintr-un browser web.
Modulul de gestiune al coninutului web trebuie sa permit un flux de aprobare
secveniala.
Modulul de gestiune al coninutului web trebuie sa furnizeze opiuni preconfigurate
pentru fluxuri de lucru ce permit procese de aprobare diferite ce depind de regulile i
cerinele organizaiei.
Modulul de gestiune al coninutului web trebuie sa permit un proces de aprobare ce
poate fi configurat n funcie de tipul elementului de coninut precum i a strii elementului
de coninut n timpul procesului de creare (de exemplu: ciorna, n ateptarea aprobrii,
publicat, arhivat, nepublicat, resubmis/restaurat etc.)
Modulul de gestiune al coninutului web trebuie sa permit escaladarea unui proces de
aprobare al unui element de coninut de ctre utilizatori autorizai.
 Modulul de gestiune al coninutului web trebuie sa permit utilizatorilor sa creeze i
sa gestioneze procese fluxuri de aprobare fr a fi nevoie de creare de scripturi sau activitati
de programare.
Modulul de gestiune al coninutului web trebuie sa furnizeze notificri n cadrul unui
flux de aprobare coninut ctre persoanele responsabile cu ndeplinirea unei anumite aciuni
(cum ar fi aprobare)
Modulul de gestiune al coninutului de lucru trebuie sa ofere posibilitatea de aprobare
de ctre una sau mai multe persoane autorizate pentru un element de coninut.
Soluia trebuie sa permit reatribuirea de sarcini n cadrul unui proces / flux de lucru.
Soluia trebuie sa permit atribuirea de roluri n cadrul unui proces flux de lucru
pentru coninut.
Soluia trebuie sa permit fluxuri de aprobare att pentru elemente de coninut dar i
pentru abloane de coninut sau design de coninut.
Soluia de management de coninut trebuie sa permit, n plus fata de propriul motor de
fluxuri de lucru i integrarea cu alte tipuri de motoare pentru fluxul de lucru (ofertantul
trebuie sa furnizeze n cadrul ofertei exemple de alte motoare de fluxuri cu care se integreaz
soluia)

1.1.1.42. Server de aplicaie

Server-ul de aplicaie trebuie sa fie o platforma robusta i agila ce ofer suport pentru
rularea de aplicaii J2EE, simplificarea dezvoltrii, performanta ridicata i administrare
inteligenta.
Server-ul de aplicaie trebuie sa ofere suport pentru ultimele versiuni de tehnologii
standard i platforme de dezvoltare, incluzand Service Component Architecture specific
modelului SOA, menite sa simplifice modelul de programare.
Server-ul de aplicaie trebuie sa respecte standardul Java EE 5, sa ofere suport pentru
tehnologiile EJB 3.0, JPA (Java Persistence API) i JDK 6.0
Server-ul de aplicaie trebuie sa permit simplificarea interoperabilitii prin suport
pentru servicii web incluznd JAX-WS, SOAP 1.2, MTOM, XOP, WS-Reliable Messaging,
WS-Trust, WS-SecureConversation, WS-Policy, i Kerberos Token Profile.
Server-ul de aplicaie trebuie sa ofere suport pentru standarde WEB 2.0
Server-ul de aplicaie trebuie sa ofere suport pentru standardul Session Initiation
Protocol (SIP).
 Server-ul de aplicaie trebuie sa permit comunicarea prin mesaje asincrone utiliznd
un furnizor integrat de Java Message Service (JMS), care respecta standardul JMS 1.1.
Server-ul de aplicaie trebuie sa ofere suport pentru tehnologia Java EE Connector
Architecture (JCA) 1.5 care sa asigure conectivitatea intre serverele de aplicaii i diferite
sisteme informatice aplicative.
Server-ul de aplicaie trebuie sa ofere suport pentru tehnologia Java Transaction API
(JTA) 1.1 pentru gestionarea tranzaciilor.
Server-ul de aplicaie trebuie sa ofere acces autentificat i autorizat pentru a securiza
funciile administrative i aplicative.
Server-ul de aplicaie trebuie sa ofere suport pentru tehnologiile de registre
(registries) oferind diverse opiuni tehnologice, cel puin: LDAP (inclus in serverul de
aplicatie), registre bazate pe fiiere si federative Server-ul de aplicaie trebuie ofere
suport pentru tehnologia Java Authorization Contract for Containers (JACC) 1.1, care sa
ofere securizarea resurselor gestionate de ctre server-ul de aplicaie.
Server-ul de aplicaie trebuie sa ofere integrare nativa cu o platforma de dezvoltare
compatibila.
Server-ul de aplicaie trebuie sa permit expunerea securizata a serviciilor intranet
ctre utilizatorii din internet.
Server-ul de aplicaie trebuie sa permit utilizare securizata a serviciilor web externe
de ctre sistemele localizate n intranet.
Server-ul de aplicaie trebuie sa permit structuri de cluster.
Server-ul de aplicaie trebuie sa permit distribuia inteligenta a ncrcrii n cluster.
Server-ul de aplicaie trebuie sa poat realiza balansarea traficului de intrare n sistem.
Server-ul de aplicaie trebuie sa ofere disponibilitate ridicata (high-availability) n
interiorul clusterului.
Server-ul de aplicaie trebuie sa ofere disponibilitate ridicata a tranzaciilor i
funcionalitate de tip back-up pentru tranzacii prin replicarea informaiilor referitoare la
tranzaciile n lucru pe toate nodurile active.
Server-ul de aplicaie trebuie sa ofere mecanisme de reglare a performantei de la
nivelul serverelor pana la nivelul cel mai detaliat al aplicaiilor i al componentelor utilizate
de acestea.
Server-ul de aplicaie trebuie sa ofere o componenta de balansare i cashing care sa
poat fi instalata n fata server-ului web n topologia de securitate.
 Server-ul de aplicaie trebuie sa ofere componenta server web care sa poat fi instalata
topologic n fata server-ului de aplicaii, pentru balansarea nodurilor de aplicaii.
Acces universal de date i persistenta
Server-ul de aplicaie trebuie sa suporte standardul Java DataBase Connectivity
(JDBC) API 4.0 pentru conectare la orice tip de baza de date.
Server-ul de aplicaie trebuie sa suporte Java Persistence API (JPA) pentru a asigura
persistenta i reutilizarea obiectelor.
Server-ul de aplicaie trebuie sa suporte standardul de dezvoltare SCA.
Server-ul de aplicaie trebuie sa suporte standardul Service Data Objects (SDO),
pentru a accesa i manipula n mod uniform date din sisteme eterogene, sub forma de obiecte
de colecii de structuri de tip arbore, sau grafuri.
Server-ul de aplicaie trebuie sa suporte portlei conform standardului Java
Specification Requests (JSR) 286 (Portlet 2.0).
Server-ul de aplicaie trebuie sa suporte aplicaii ce folosesc tehnologia Session
Initiation Protocol (SIP) conform standardului JSR 116.
Server-ul de aplicaie trebuie sa suporte standardele Java Servlet 2.5 (JSR 154) i
JavaServer Pages (JSR 245)
Securitatea aplicaiilor
Server-ul de aplicaie trebuie sa ofere flexibilitate n definirea i controlul conturilor
utilizatorilor.
Server-ul de aplicaie trebuie sa ofere funcionaliti Single Sign-On pentru
interoperabilitate mbuntit ntre diferite aplicaii.
Server-ul de aplicaie trebuie sa permit auditarea informaiilor de securitate a
aciunilor administrative, cum ar fi modificri de configurri de securitate, gestionare de chei
i certificate, modificri de politici de control al accesului, etc.
Server-ul de aplicaie trebuie sa ofere administrare a securitii mbuntit la nivelul
consolei de administrare, cu acces pe baza de permisiuni, n funcie de roluri.
Administrare inteligenta
Server-ul de aplicaie trebuie sa ofere infrastructura simplificata i flexibila pentru
controlul eficientei mediilor de rulare.
Server-ul de aplicaie trebuie sa ofere administrarea de la distanta a mai multor
servere de aplicaii.
Server-ul de aplicaie trebuie sa ofere controlul mediilor complexe cu topologii
complexe.
 Server-ul de aplicaie trebuie sa ofere activitati administrative simplificate pentru
aplicaiile cu componente multiple.
Server-ul de aplicaie trebuie sa ofere o consola de administrare web-based pentru
gestionarea centralizata a tuturor componentelor din topologii ce includ mai multe servere de
aplicaii si/sau web.
Server-ul de aplicaie trebuie sa permit gestionarea centralizata a transferului de
informaii intre medii cum ar fi: instalarea, pornirea, oprirea de aplicaii i distribuirea
fiierelor n topologii ce includ mai multe servere de aplicaii si/sau web.
Server-ul de aplicaie trebuie sa ofere posibilitatea de a grupa i gestiona mai multe
artefacte Java EE sub o singura definiie de aplicaie.
Server-ul de aplicaie trebuie sa ofere capabiliti de a configura rapid securitatea i
conectivitatea la baza de date i un client independent (stand-alone) pentru administrarea
eficienta a mediului de instalare.
Server-ul de aplicaie trebuie sa ofere script-uri avansate de administrare, care
accelereaz procesele administrative.
Server-ul de aplicaie trebuie sa ofere facilitai avansate i eficiente de gestionare a
resurselor de memorie i spaiu pe disc, n funcie de necesitile aplicaiilor care ruleaz,
prin activarea n mod dinamic, doar a componentelor necesare aplicaiilor ce ruleaz la un
moment dat pe server.
Server-ul de aplicaie trebuie sa ofere suport pentru standarde recente de servicii web
cum ar fi:
Web Services Interoperability Organization (WS-I) Basic Profile 1.2 i 2.0
WS-I Reliable Secure Profile
Java API for XML Web Services (JAX-WS)
SOAP 1.2
SOAP Message Transmission Optimization Mechanism (MTOM)
XML-binary Optimized Packaging (XOP)
WS-ReliableMessaging
WS-Trust
WS-SecureConversation
WS-Policy

1.1.1.43. Administrarea utilizatorilor i drepturilor de acces

Descriere
Modulul de administrare a utilizatorilor i drepturilor de acces are rolul de a oferi
funcionaliti de gestiune centralizata i automata a identificatorilor de identitate i
drepturilor de acces asociate utilizatorilor n cadrul sistemului integrat.
Cerine
Sistemul trebuie sa permit autentificare bazata pe nume utilizator i parola,
autentificare pe baza de certificat client SSL i autentificare folosind un subsistem ter
destinat autentificrii.
Sistemul trebuie sa conin propriile mecanisme de autorizare dar sa poat fi integrat
i cu subsisteme tere destinate controlului accesului.
Sistemul trebuie sa permit administratorului sa creeze resurse, roluri i drepturi de
acces care sa controleze ce utilizatori acces la diverse resurse pe baza rolurilor.
Sistemul trebuie sa permit definirea de politici de acces care sa poat fi ulterior
asociate utilizatorilor.
Sistemul trebuie sa permit delegarea accesului pentru operaiuni administrative.
Sistemul va fi capabil sa susin definirea de reguli de acces la date (citire, scriere,
tergere i creare) pentru diverse grupuri de utilizatori.
Sistemul trebuie sa permit configurarea rolurilor utilizator i a grupurilor i stabilirea
drepturilor de acces pentru un utilizator n funcie de rolul sau grupul din care face parte.
Platforma trebuie sa ofere capabiliti pentru configurare a funcionalitii de
autentificare unica (Single Sign-On).
Sistemul trebuie sa permit integrarea cu multiple registre majore de tip LDAP, cel
puin: Oracle ID, MS Active Directory, Tivoli Directory Server, Novel eDirectory, Sun Java
System Directory Server.

6.2.9. Integrare date

Descriere
Acest modul va oferi suport pentru realizarea funciei ETL (Extract-Transform-Load) pentru
implementarea modulului de Data Warehouse.
Cerine
Instrumentul pentru extragerea, transformarea i ncrcarea datelor (ETL) trebuie sa ofere
suport pentru modificri permanente, funcie de cerinele impuse de activitate: surse de date
noi, modificarea proceselor i cerine specifice care implica schimbarea structurii datelor. n
vederea atingerii acestui obiectiv, instrumentul ETL trebuie sa ofere urmtoarele capabiliti:
 Procesul ETL sa fie realizat cu ajutorul instrumentului specializat, fr a fi necesara
scrierea de cod, de script-uri, sau utilizarea de instrumente sau funcionaliti externe acestui
instrument.
Sa gestioneze urmtoarele cerine de proces
o Agregare
o Compresie/Decompresie
o Conversie tip si/sau format date
o Manipulare i executare de operaii aritmetice pe seturi de date
o Asignare valori si selectie conditionala de dateFiltrare
o Partiionare/grupare pentru seturile de nregistrri
o Sortare
o Manipularea nregistrrilor
o Alocarea i rezoluia cheilor surogat
o Tabele lookup
o Validarea datelor
Sa proceseze nregistrrile rejectate
Executarea de job-uri multiple n mod concurent
Eliminarea procesrii datelor n sistemele sursa/inta sau n interiorul unei baze de date.
Conectivitate avansata pentru orice tip de surse de date (baze de date, fiiere, XML, etc)
Reprezentarea grafica a fluxului de date, cu posibilitatea de proiectare ierarhica
Efectuarea de lookup-uri pe date eterogene, n cadrul aceluiai flux
Multi-sursa/multi-int n acelai flux.
Instrumentul ETL trebuie sa includ instrumente de dezvoltare cu urmtoarele
capabiliti:
Procesul ETL sa fie construit din componente reutilizabile.
Variabilele temporare sau coloanele sa fie utilizate n procesul ETL, astfel nct
procesrile sa se efectueze o singura data
o Interfaa grafica consistenta intre toate modulele
o Rollback la versiunile anterioare
o Debugger vizual
o Setare puncte de verificare
Motorul de execuie trebuie sa ofere urmtoarele capabiliti:
 o Sa pun la dispoziie o consola vizuala pentru rularea i gestionarea job-urilor
o Sa gestioneze procese ETL multiple
o Monitorizare n timp real
o Suport pentru ncrcarea volumelor mari (bulk loaders)
o Suport pentru XML ca sursa/inta de date
o Direcionarea nregistrrilor greite ctre un fiier separat pentru procesare
ulterioara
o Posibilitatea de a crea dependente intre sesiunile programate
o Restaurare pana la ultimul punct de verificare sau de euare, fr efort manual
o Repornire de la punctul de euare
o Repornirea ntregii sesiuni
o Posibilitatea de a specifica gestionarea erorilor intr-o secvena de sesiuni
dependente.
Subsistemul trebuie sa ofere acces nativ la diferite tipuri de surse:
o Microsoft SQL Server
o Oracle
o DB2 UDB
Instrumentele de administrare ale subsistemului de integrare a datelor trebuie sa ofere
urmtoarele capabiliti:
o Consola de administrare sa poat gestiona mai multe sisteme ETL
o Monitorizarea evenimentelor (stare job, linii procesate, durata fiecrui task, timpul
total, ncrcarea procesorului i consumul de memorie, valorile medii, maxime,
minime, etc.)
o Definirea planificrilor i dependentelor intre job-uri, n mod grafic
o Limitarea necesitaii interveniei administratorilor bazelor de date n sistemul ETL
o Eliminarea necesitaii cunotinelor specializate de SQL sau orice alt limbaj de
programare, prin utilizarea de conectori automatizai
o Capabilitatea de a monitoriza procesele i job-urile n desfurare.

6.2.10. Analiza i raportare

Descriere
Rolul acestui modul este acela de oferi suport pentru rularea de rapoarte ce includ facilitai de
analiza statistica
Cerine
Modulul de analiza i raportare trebuie sa permit:
existenta unor rapoarte predefinite, precum i posibilitatea de a crea rapoarte noi.
rapoartele sa poat fi distribuite i exportate n formatele cunoscute: pdf, Excel, text,
XML, etc.
generarea de grafice de tip hri, pie, charturi sau combinaii n cadrul unui raport a
mai multor astfel de elemente
vizualizarea trasabilitii componentei dintr-un raport, i daca aceasta este o msura
calculata, sa permit vizualizarea formulei de calcul.
autorizarea utilizatorilor la funcionalitatea de raportare trebuie sa se fac prin
registrul central de resurse LDAP i trebuie sa fie controlat prin mecanismul de control al
accesului pe baza de rol al utilizatorului din sistem; mediul de raportare trebuie sa exploateze
functiile de control al accesului utilizatorilor prin punerea la dispozitia acestora a unor
capabilitati de mediu colaborativ, in vederea imbunatatirii productivitatii activitatilor de
raportare:
-existena unui inbox de sarcini pe care un utilizator s il poat accesa direct din interfaa
web de raportare
-crearea de noi sarcini n care s poat fi adugai utilizatori din diverse grupuri de lucru
implicate n rapoartele analizate
-s se defineasc att o prioritate a sarcinii respective ct i o dat de nceput i sfrit
-coninutul mesajului de notificare s poat fi formatat, s poat fi adugate imagini, tabele
precum i legturi ctre rapoartele ce trebuiesc analizate sau modificate
sa pun la dispoziie un sistem de auditare a accesului i a activitati la nivelul
sistemului de raportare.
posibilitatea de drill-up, drill-down
posibilitatea de a interaciona cu sistemul de raportare doar prin intermediul unui
browser web, fr a fi necesara instalarea unui software pe sistemele utilizatorilor finali
arhivarea rapoartelor statice i vizualizarea unui istoric al rulrii raportului.
capabilitatea de drill through (deschiderea unui raport diferit pe baza unor
parametrii) de la un raport complex la altul. Raportul sursa trebuie sa difere de cel destinaie
i crearea unui astfel de raport nu va implica cunotine de programare sau utilizarea unui
limbaj de tipul JavaScript
capabilitatea de a genera rapoarte n mod automat pe baza de orar predefinit i de a le
transmite ctre anumii utilizatori prin email sau prin publicare intr-o locaie definita.
 definirea de grupuri de utilizatori i roluri;
administrarea i utilizarea prin intermediul interfeei web;
adugarea cu uurina a filtrelor de sumarizare (ex: filtre aplicate dup nsumarea
nregistrrilor individuale)
utilizarea unor template-uri predefinite n sistem sau de ctre utilizatori;
nlocuirea anumitor componente dintr-un raport de tip template cu orice alt tip de
element.
crearea de rapoarte cu mai multe pagini, unde datele de pe a doua pagina sa provin
dintr-o cerere diferita i independenta, i sa nu fie afectata de prompt-urile de pe prima
pagina.
s conin un modul de raportare ad-hoc care sa permit utilizatorilor crearea i
utilizarea rapoartelor fr a fi nevoie de cunotine de SQL, accesul sa se fac prin
intermediul unui browser web, iar componentele ce vor fi folosite pentru raportare sa fie
entiti de business mapate peste componentele surselor de date.
conectarea la diverse surse relaionale de date de la furnizori precum Oracle,
Microsoft, IBM, precum i accesibilitatea surselor prin intermediul ODBC
abonarea unui utilizator la un anumit raport i livrarea acestuia automat prin e-mail.
generarea de rapoarte pe baza informaiei de accesare i utilizare a sistemului de
raportare.
generarea cererii (query-ului) automata, prin drag-and-drop al componentelor, fr a
fi nevoie sa fie creata n prealabil i asocierea mai multor componente de prezentare la
aceeai interogare.
trecerea rapoartelor ad-hoc n editorul de rapoarte complexe, fr a fi nevoie sa fie
reconstruite rapoartele.
adugarea unui filtru pentru coloana de sumarizare daca aceasta este valoarea
urmrita.
utilizarea de prompt-uri pentru a filtra informaia din orice element de interfaare
grafica din cadrul unui raport i sa ofere o gama variata de tipuri de prompt-uri.
adugarea de hri i colorarea regiunilor, similar folosirii unui grafic de tip Pie.

6.2.11. Data Warehouse

Descriere
Acest modul reprezint depozitarul de date global pentru sistemul integrat, avnd ca sursa
diverse sisteme primare/master i este destinat utilizrii ca baza pentru funcia de raportare.
Cerine
Sistemul de Data Warehouse trebuie sa ofere o consola comuna pentru administrarea
tuturor componentelor.
Sistemul de Data Warehouse trebuie sa ofere o interfaa unica pentru dezvoltarea
sistemului, pornind de la definirea structurii tabelelor pana la definirea structurii OLAP i
data mining.
Sa ofere posibilitatea de a crea structuri OLAP.
Sa permit posibilitatea de a crea previziuni.
Sa permit compresia datelor la nivel de nregistrare
Sa permit maparea de tabele din diferite baze de date relaionale chiar daca difer
tehnologia (cum ar fi Oracle, Microsoft SQL Server, DB2). Aceste mapri sa fie transparente
pentru dezvoltatori.
Crearea de modele logice i fizice.
Descoperirea, explorarea, vizualizarea structurii sursei de date.
Sa descopere sau identifice relaiile dintre surse disparate de date.
Compararea i sincronizarea structurilor din doua surse de date.
Analiza i aplicarea de standarde la nivel enterprise
Integrare nativa cu instrumentele oferite pentru integrare.
Posibilitatea de a face modele fizice pentru baze de date cum ar fi : Oracle, Sybase,
Microsoft SQL Server, DB2
Posibilitatea de a realiza reverse engineering pe o baza de date deja creata.

6.2.12. Platforma de baze de date relaionala

Descriere
Acest modul gestioneaz necesarul de persistenta operaionala pentru componentele
aplicative ale sistemului integrat.
Cerine
Cerine generale pentru baza de date relaionala
Baza de date relaionala trebuie sa suporte comunicarea cu aplicaiile client folosind
protocolul de transport pe reea TCP/IP.
Baza de date relaionala trebuie sa poat rula pe sisteme de operare incluznd cel
puin Windows, Unix, Linux
Baza de date relaionala trebuie sa suporte o arhitectura de clustering de tip shared
disk.
Cerine specifice pentru baza de date relaionala
Baza de date / Securitatea Datelor
Baza de date relaionala nu trebuie sa permit executarea de operaii asupra obiectelor
bazei de date dect daca utilizatorul este autorizat pentru operaia n cauza.
Baza de date relaionala trebuie sa ofere o facilitate care nregistreaz informaii n
legtura cu operaiunile de modificare, inserare, tergere i selectare a obiectelor interne bazei
de date.
Baza de date relaionala trebuie sa ofere abilitatea de a se ajusta la gradul de detalii,
capturate de ctre facilitatea interna de audit.
Salvarea i recuperarea bazei de date
Baza de date relaionala trebuie sa ofere o facilitate pentru salvarea-restaurarea
ntregii baze de date.
Baza de date relaionala trebuie sa ofere o facilitate pentru nregistrarea tuturor
modificrilor bazei de date, pentru a permite recuperarea bazei de date (nregistrarea
tranzaciilor)
Baza de date relaionala trebuie sa ofere o facilitate pentru recuperarea ntregii baze
de date corespunztor unui moment de timp specificat de administrator.
Baza de date relaionala trebuie sa ofere posibilitatea de a realiza salvri pentru unul
sau mai multe spatii alocate tabelelor aa cum este specificat de ctre administratorul bazei de
date.
Baza de date relaionala trebuie sa scrie n mai multe fiiere pe disc simultan n timpul
unei operaii de salvare
Baza de date relaionala trebuie sa citeasc din mai multe fiiere pe disc simultan n
timpul unei operaii de restaurare.
Baza de date relaionala trebuie sa permit citirea i scrierea paralela n timpul unei
operaii de salvare
Baza de date relaionala trebuie sa permit citirea i scrierea paralela n timpul unei
operaii de restaurare
Integritatea datelor
Baza de date relaionala trebuie sa identifice i sa rezolve situaiile de blocaj la acces
concurent (dead-locks).
Baza de date relaionala trebuie sa permit administratorului sa impun constrngeri
de tip cheie primara.
Baza de date relaionala trebuie sa permit ca o coloana sa nu accepte valori NULL.
 Baza de date relaionala trebuie sa ofere abilitatea de creare de indeci unici.
Dicionarul datelor
Baza de date relaionala trebuie sa ofere o facilitate de catalog (sau dicionar de date)
care ofer posibilitatea execuiei de instruciuni de tipul Data Definition Language (DDL
Limbajul de definire a datelor).
Baza de date relaionala trebuie sa ofere facilitai interne de accesare a catalogului i
obinere de informaii legate de obiectele bazei de date.
Performanta i scalabilitatea bazei de date
Baza de date relaionala trebuie sa permit folosirea ei n sisteme cluster.
Baza de date relaionala trebuie sa ofere abilitatea sa partiioneze tabele.
Baza de date relaionala trebuie sa permit unui tabel sa fie partiionat bazndu-se pe
una sau mai multe valori specifice de date, aa cum este hotrt de ctre administratorul bazei
de date
Baza de date relaionala trebuie sa permit definirea cantitii minime de date
transferate ntre disc i memoria locala a bazei de date la o cerere
Baza de date relaionala trebuie sa permit setarea mrimii unei zone din memoria
locala, rezervata sa retina date din tabele special indicate, pentru o perioada nedefinita de
timp
Baza de date relaionala trebuie sa aib un optimizator bazat pe cost pentru a optimiza
interogrile
Baza de date trebuie sa permit prin parametrizare folosirea unui sistem care sa
trimit datele de pe disc n memorie nainte ca o cerere de tip SQL sa aib nevoie de acele
date.
Instane multiple, izolate i complet funcionale ale bazei de date trebuie sa poat
coexista pe un singur nod SMP.
Baza de date trebuie permit funcionalitatea de clustering a tabelelor pentru o
performanta mai buna
Baza de date trebuie sa suporte crearea de mai multe baze de date care sa aparin
unei singure instane.

6.2.13. Audit
Descriere
Acest modul are rolul de a gestiona n mod exhaustiv securitatea bazei de date i ciclul sau de
viata, n conformitate cu politicile de securitate stabilite de administratori.
Cerine
Sistem unificat de tip consola web i un mecanism de automatizare ale fluxurilor de
lucru.
Localizarea i clasificarea informaiilor sensibile stocate n baze de date relaionale.
Evaluarea vulnerabilitilor bazei de date i defecte de configurare.
Vizibilitate de 100% i granularitate a tranzaciilor din bazele de date pentru toate
distribuiile majore, incluznd Oracle, Microsoft SQL Server, IBM DB2, Informix, Sybase,
MySQL, Teradata.
Monitorizarea i aplicarea politicilor de acces privitoare la date sensibile, aciuni
privilegiate ale utilizator, controlul modificrilor, cererilor i activitilor utilizatorilor precum
i excepii de securitate, cum ar fi operaiuni euate; politicile de acces la datele sensibile
trebuie sa includa posibilitatea interceptiei automate, in timp real, a sesiunilor neautorizate
sau suspecte, prin terminare, blocare temporara sau mascare a portiunilor cu informatii
personale din datele prezentate.
Automatizarea ntregului proces de audit i de conformitate.
Posibilitatea agregrii i normalizrii automate a informaiilor de audit, provenite din
platforme diverse de baze de date, centralizate intr-un singur depozit central de date de audit
ca baza pentru raportare, optimizarea performantelor i investigaii.
Gsirea i clasificarea datelor, localizarea i clasificarea n mod automat a
informaiilor sensibile.
Soluia trebuie sa fie independenta de productorul bazei de date: nu se va baza pe
auditul nativ al bazei de date.
Logurile de audit trebuie sa fie protejate fata de accesul neautorizat: acestea vor fi
criptate i nu vor permite acces implicit la nivel "root".
Suport pentru cel puin urmtoarele standarde: SNMP, SMTP, Syslog, CEF, SIEM
7. Cerine servicii de implementare

7.1. Mod de implementare

Pentru implementarea unui proiect de o asemenea anvergura i complexitate dar i innd

cont de numrul mare de sisteme cu care vor trebui integreze, urmtoarea abordare trebuie
considerata pentru implementarea DES:
o Stabilirea clara a tuturor informaiilor ce se vor pstra n DES i care alctuiesc Date
Medicale Relevante (DMR). Pentru aceasta se va constitui o comisie (cu participani din
toate sectoarele domeniului de sntate).
o Definirea standardelor de comunicare intre sistemele locale i sistemul central DES
innd cont de securitate, performanta, fiabilitate, auditare, etc.
o Stabilirea funcionalitilor prezente n proiect i modul de integrare cu alte sisteme sau
subsisteme adiacente proiectului DES, precum i a sistemului de autentificare PKI (in
conjuncie cu cardul de sntate)
o Etapa de dezvoltare/testare a proiectului. n aceasta etapa vor fi dezvoltate componentele
identificate pentru a fi realizate i vor fi executate testele, n conformitate cu o
metodologie standard.
o Implementarea proiectului mpreuna cu spitalele majore din Romnia n cadrul cruia vor
fi implementate componentele identificate anterior.
o Implementarea sistemului de certificare n vederea integrrii cu alte sisteme din teritoriu
o Punerea n producie a sistemului, prin integrarea cu spitalele majore din Romnia i prin
utilizarea portalului
o Finalizarea proiectului

7.1.1. Servicii de implementare

Se dorete ca echipamentele i aplicaiile furnizate sa fie nsoite de servicii de implementare
i de project management de calitate, care sa garanteze atingerea cu succes a obiectivelor
proiectului. Ofertanii vor oferi servicii de management de proiect (PM) pe ntreaga durata de
viaa a proiectului, pentru a asigura ndeplinirea la timp a tuturor obiectivelor i ncadrarea n
buget.
Furnizorul va avea o abordare metodologica asupra ntregului proces de implementare i va
descrie modul n care va urmri derularea proiectului.
Oferta va fi structurata astfel nct sa conin urmtoarele:
Principii fundamentale:
Viziunea proprie asupra realizrii proiectului.
Opinii asupra aspectelor principale privind proiectul care pot influenta atingerea
obiectivelor i a rezultatelor ateptate.
Enumerarea i explicarea riscurilor i ipotezelor privind execuia proiectului.
Identificarea de noi riscuri i ipoteze
Identificarea unor soluii de prentmpinare i restrngere a riscurilor.
Strategia abordrii:
a. Metodologii folosite:
Ofertantul va declara ce metodologie de dezvoltare a sistemelor informatice folosete.
Este obligatorie folosirea unei metodologii recunoscute pe plan internaional.
Ofertantul va declara ce metodologie de management de proiect folosete. Este
obligatorie folosirea unei metodologii recunoscute pe plan internaional.
Ofertantul va face o scurta prezentare a metodologiilor folosite n proiect.
b. Soluia propusa:
Ofertantul va prezenta pe larg soluia propusa pentru proiect, n vederea atingerii
obiectivelor acestuia i a rezultatelor ateptate
Descrierea soluiei trebuie sa evidenieze etapele de proiect, activitile specifice fiecrei
etape, livrabilele ateptate de la fiecare etapa, modul n care acestea concura la atingerea
obiectivelor.
Enumerarea intrrilor i ieirilor din proiect i legturile dintre acestea.
c. Organizarea proiectului:
Ofertantul va prezenta n detaliu, n raport cu specificul acestuia i cu metodologia
propusa, modalitatea n care proiectul va fi organizat. Se va prezenta componena propusa
pentru Echipa de Management al Proiectului.
In cazul n care ofertantul reprezint o asociere, ofertantul trebuie sa descrie modalitatea n
care fiecare membru al asocierii intervine n proiect, distribuirea i interaciunea sarcinilor i
responsabilitilor.

7.1.2. Planificarea activitilor

Ofertantul va prezenta planificarea activitilor propuse, n interdependenta acestora un
plan Gantt este ateptat.
Planul trebuie sa menioneze care sunt termenele cheie (milestones) pe care ofertantul si-a
propus sa le respecte pentru atingerea obiectivelor.
 Ofertantul va detalia care sunt resursele pe care le va aloca pentru fiecare etapa a
proiectului, eventual activitati pe care le considera mai importante.

7.1.3. Metodologia de dezvoltare a sistemului

Este necesara o abordare de proiectare rapida a aplicaiilor, cu cicluri de construcie iterative,
cu suprapunere intre faze, oferind astfel oportuniti de reacie la schimbarea condiiilor i
scenariilor din domeniul de activitate.
Ofertantul va trebui sa acopere, intr-un ciclu iterativ, principalele etape ale dezvoltrii unui
sistem informatic:
Analiza:
In procesul de analiza, pentru determinarea cerinelor de funcionalitate ale sistemului,
ofertantul va trebui sa poarte discuii cu personalul IT si/sau specialiti desemnai din partea
solicitantului cat i din partea responsabililor tehnici a sistemelor locale (din teritoriu) ce se
vor integra cu DES. Ofertantul va realiza un raport cu concluziile discuiilor purtate care sa
conin specificaiile tehnice i funcionale detaliate ale sistemului.
o Analiza cerinelor funcionale
o Analiza cerinelor non-funcionale
o Specificarea cerinelor de interfaare cu alte sisteme
Proiectare:
Principalul obiectiv al acestei faze l constituie determinarea complexitii i scopului
soluiei. Acum se efectueaz o analiza a sistemului existent, identificndu-se use-case-urile
critice i scenariile de operare de baza care vor influenta n mod semnificativ designul
aplicaiei. Se evideniaz riscurile poteniale i se genereaz o arhitectura generica a soluiei.
Scopul acestei faze este de a detalia modelul soluiei identificat la nivel nalt n iniierea
schirii soluiei. Pentru aceasta se definesc n detaliu comportamentul funcional al aplicaiei
i funcionalitile care trebuie dezvoltate, se identifica omisiunile, contradiciile i cerinele
care trebuie clarificate sau corectate. Se identifica i formalizeaz n detaliu descrierea logicii
de business a aplicaiei i se definete arhitectura la nivel detaliat. Se creioneaz specificaiile
pentru planurile de testare.
o Arhitectura funcionala
o Arhitectura tehnica
o Modelul informaional
o Proiectare de detaliu
o Elaborarea planurilor de testare
Dezvoltare:
Ofertantul trebuie sa aib capacitatea de a dezvolta i realiza o soluie bazata pe rezultatele
proceselor de analiza i proiectare
o Construcia soluiei
o Testarea soluiei
Implementare:
Ofertantul trebuie sa asigure instalarea, configurarea, i punerea n producie tuturor
componentelor sistemului, cu personal certificat de productorul componentei respective,
astfel:
o Instalarea i configurarea infrastructurii HW
o Instalarea i configurarea aplicaiilor SW standard
o Integrarea aplicaiilor SW specializate
Documentare sistem DES:
Ofertantul trebuie sa creeze urmtoarele livrabile care documenteaz sistemul:
o Sistemul de help on-line.
o Manuale de utilizare pentru toate componentele HW i SW ale soluiei.
o Manual de utilizare pentru interfaa de servicii WEB a sistemului.
o Codul sursa al componentelor non-COTS (nu se aplica pentru produsele Customer Of The
Shelf sisteme i aplicaii software disponibile n mod comercial)

Testele de acceptata i validare a sistemului

Manualul de operaiuni al sistemului care conine procedurile de:

Instalare
Pornire
Oprire
Back-up
Restaurare
Monitorizare
Upgrade
Administrare / gestiune utilizatori
Proceduri de repornire a sistemului n cazul n care serverul principal nu mai este
disponibila
Documentare standarde de integrare
Ofertantul trebuie sa creeze un document detaliat n vederea integrare intre DES i sisteme
locale HIS (EMR/EPR/EHR) sau alte sisteme prin care se schimba informaii medicale. Acest
document cuprinde:

Standarde de comunicaie ntre aplicaii

Standarde de performanta n ceea ce privete transferul de informaii

Standarde de securitate a datelor
Standarde de validare a datelor transmise
Modalitatea i criteriile de testare a integrrii
Modalitatea i criteriile de certificare a integrrii
Testare de acceptanta:
Ofertantul trebuie sa pun la dispoziia beneficiarului o procedura de testare funcionala i
operaionala a sistemului realizat prin ntocmirea planurilor de testare de acceptanta i a
cazurilor de testare pentru toate modulele sistemului, conform specificaiilor. Testarea de
acceptata va fi realizata de ctre echipa CNAS pe baza planului de testare de acceptanta.
Planul de testare trebuie s urmeze o metodologie standard stabilit n domeniu. Domeniile
eseniale de testare trebuie s acopere:
o teste unitare pentru componentele instalate
o teste non-funcionale, cum ar fi:
- teste de securitate
- teste de performanta
- teste de securitate a reelei
- teste pentru procedurile de salvare i restaurare a datelor din DES
o teste de conexiune, integrare i utilizare cu sistemele conectate
o teste funcionale DES
Planurile de testare trebuie s acopere cel puin domeniile de testare enumerate mai sus i
trebuie s conin cel puin elementele urmtoare:
Descrierea componentei sistem testate
Obiectivele testului
Descrierea mediului de test
Rezultatele preconizate ale testului
Abordarea testului
Datele de test
Descrierea procedurilor de testare
 Cazurile de test
Instrumentele de test utilizate
Personale responsabile din partea Ofertantului i a Beneficiarului
Cerinele de intrare/ieire
Condiii de acceptare a testelor

Condiiile de acceptare a testelor

Condiiile de acceptanta pentru fiecare test vor fi propuse de Ofertant i aprobate de

Beneficiar n cadrul Planului de testare.
Instruirea personalului:
Scopul final al acestei componente este ca toi angajaii CNAS care vor accesa sistemul DES
sa fie capabili sa-l utilizeze n activitatea de zi cu zi precum i sa l preia n folosina i
administrare la sfritul proiectului.

Pentru desfurarea n bune condiii a activitii necesare utilizrii i administrrii sistemului

este foarte importanta existenta personalului colarizat. n acest sens se vor desfura
colarizri pe urmtoarele categorii:
Produs cursuri standard de produse adresate specialitilor IT.
Suport cursuri personalizate destinate personalului care va ntreine sistemul (Nivel 1 de
suport) i care va fi capabil sa transfere cunotine de utilizare celorlali angajai ai CNAS
care vor folosi sistemul

Cerine de documentaie

Ofertantul trebuie sa descrie documentaia care va fi pusa la dispoziia

Solicitantului/Utilizatorilor pe parcursul proiectului i sa explice n ce mod va fi organizata
aceasta documentaie: categorii de documente, convenii de numerotare i denumire, machete
de documente.
Urmtoarele reprezint un minim necesar pentru documentaia sistemului:
Specificaii detaliate: trebuie descrise n amnunt toate modulele DES la nivel tehnic. Se
vor descrie aici proceduri, funcii, integrarea intre acestea, integrarea intre module i
integrarea cu sistemele externe, fluxul de prelucrare a informaiilor. Din acest ghid nu
trebuie sa lipseasc:
o Funciile implementate (intrri, ieiri i parametri)
o Tipurile de date folosite
 o Machetele de date folosite
o Concepte
Documentaie hardware: descrierea completa a specificaiilor hardware i a instruciunilor
de instalare, configurare, operare i depanare
Documentaie a software-ului comercial: descrierea completa, att funcionala cat i
tehnica a software-ului folosit. Se vor avea n vedere instruciuni de instalare, configurare,
operare i depanare, att cele de baza (din manualele produselor) cat i cele specifice
aplicaiei DES
Documentaie a software-ului dezvoltat: descrierea completa, att funcionala cat i
tehnica, a software-ului dezvoltat pentru sistemul DES.
Ghidul de operare i administrare: acesta trebuie sa acopere arhitectura tehnica i
funcionala a tuturor modulelor sistemului DES i definete att cerinele fundamentale de
funcionare a DES cat i metode de ntreinere zilnica. Acest document trebuie sa fie
actualizat pentru fiecare noua versiune a sistemului i sa conin cel puin:
o versiunea pentru care a fost creat ghidul
o configurarea DES pentru fiecare componenta interna
o configurarea DES pentru colaborarea cu sistemele externe
o managementul erorilor
o documentaie de administrare a fiecrui modul n parte
o salvarea i restaurarea sistemului
Structura bazelor de date: n acest document trebuie descrisa ntreaga structura a bazelor
de date DES: tabele, legturi intre tabele, elemente specifice, semnificaia tabelelor i
rolul funcional al fiecreia, descrierile cmpurilor din fiecare tabela.
Ghidul de utilizare se adreseaz utilizatorilor finali ai DES i specifica, intr-un format
uor de neles, toi paii care trebuie urmai pentru utilizarea DES. Ghidul de utilizare nu
conine detalii tehnice. Detaliile funcionale sunt grupate pe module i pe procese de
business
Notele de versiune: sunt livrate mpreuna cu fiecare versiune noua a DES. Acestea sunt
adresate de obicei administratorilor de sistem i trebuie sa conin: lista funcionalitilor
nou implementate (sau a celor fixate n noua versiune), precondiii de instalare a
versiunii, modificri asupra bazei de date (daca e necesar), modificri de configurare,
instruciuni de instalare a noii versiuni (instalare manuala i automata), informaii speciale
 7.2. Servicii de management de proiect

7.2.1. Metodologia de management de proiect

Ofertanii vor oferi servicii de management de proiect (PM) pe ntreaga durat de via a
proiectului, pentru a asigura ndeplinirea la timp a tuturor obiectivelor i ncadrarea n buget.
Se solicita ca managementul de proiect sa fie realizat n conformitate cu o metodologie de
proiect consacrata i folosita n proiecte IT de mare anvergur care va fi descrisa de ofertant
n cadrul ofertei.
Ofertantul trebuie s precizeze, de asemenea, orice consecin care va deriva din abordarea
aleas, n special asupra relaiilor de lucru cu Beneficiarul, prin aceasta nelegnd ntlnirile
de lucru, metodele de raportare i modul de colaborare de-a lungul ntregului proiectului.
Serviciile PM vor fi implementate de o organizaie de management a proiectului propus, cu
roluri de responsabilitate definite att pentru Ofertantul ctigtor, ct i pentru Beneficiar.
Organizaia de management de proiect va include cel puin:
Un Comitet director - format din membrii ai conducerilor superioare ale tuturor prilor
implicate (rolurile eseniale care trebuie definite sunt: Sponsori de proiect, Responsabili
de Proiect, Manageri de proiect)
Un Comitet de management de proiect, cu rolurile de conducere ale Ofertantului i
rolurile corespunztoare ale Beneficiarului, care s acopere cel puin urmtoarele fluxuri
de lucru PM:
o Managementul comunicrii
o Managementul modificrilor
o Management de risc
o Managementul calitii
o Planificare, managementul timpului i al resurselor
o Management financiar
Ofertanii vor oferi n Propunerea tehnic o descriere complet a metodologiei de PM,
precum i un plan preliminar de proiect, care vor fi utilizate pe parcursul proiectului de
implementare. Metodologia PM va include cel puin descrierea procedurilor, instruciunile de
lucru i instrumentele care vor fi utilizate, precum i rolurile din cadrul procedurilor care vor
fi atribuite organizaiei PM menionate mai sus.
Metodologia va include cel puin procedurile care s implementeze urmtoarele procese:
Planificare;
 Monitorizare i control, inclusiv raportare;
Managementul resurselor;
Management de risc;
Managementul modificrilor, inclusiv planificarea comunicrii i a raportrilor;
Managementul problemelor, inclusiv procedurile de escaladare n ambele pri ale
organizaiei PM (Ofertantul ctigtor i Beneficiar)
Asigurarea calitii proiectului (planificare, control, aciuni preventive i corective, etc.),
Planul preliminar de proiect va trebui s acopere urmtoarele puncte:
metodologia de management a proiectului
organizarea proiectului
planul de comunicare
planificarea activitilor, timpul de desfurare i resursele implicate (un grafic Gantt este
ateptat)
planul de livrare, instalare i implementare (detalierea activitilor, rezultate ateptate
livrabile, documente rezultate i jaloane de proiect milestones)
planul de instruire
planul de acceptan
planul de ntreinere post-garanie
planul de risc pentru fazele proiectului
Serviciile PM vor fi oferite de personalul specializat n PM al Ofertantului. Ofertanii vor
include n prezentarea echipei de proiect personalul PM propus (cel puin un Manager de
proiect).
Managerul de proiect de la furnizor trebuie sa fie certificat de ctre o organizaie recunoscuta
pe plan internaional (PMP, PRINCE2 sau echivalent).

7.2.2. Activiti de management de proiect

n cadrul activitilor generale de management de proiect, sunt stabilite modalitile de
organizare i coordonare a resurselor umane implicate n realizarea activitilor proiectului.
1. Activiti de ncepere a proiectului, constnd n:
Organizarea biroului de proiect i mobilizarea echipei de management de proiect
Informarea factorilor interesai cu privire la nceperea desfurrii proiectului, la
obiectivele stabilite i la rezultatele ateptate i solicitarea sprijinirii proiectului
 2. Activiti generale de management de proiect (planificare, organizare i coordonare,
monitorizare i control, raportare, ncheierea proiectului): aspecte de management
financiar, asigurarea vizibilitii proiectului i asigurarea calitii proiectului.
Planificarea activitilor const n verificarea i dac este necesar actualizarea planurilor
proiectului: planul de activiti, ca baz general de implementare, planul de jaloane
(milestones), ca baz de monitorizare, planul activitilor de achiziii, planul de informare i
publicitate, etc.
Organizarea proiectului const n stabilirea procedurilor de lucru, stabilirea rolurilor i
limitrilor fiecrei pri interesate (echipa de management de proiect, beneficiar, furnizori,
etc.) i a modalitilor de comunicare, monitorizare i raportare n cadrul proiectului.
Coordonarea activitilor const n antrenarea tuturor prilor interesate ale proiectului n
realizarea acestuia i n dezvoltarea i meninerea unor bune legturi n interiorul i n afara
proiectului, inclusiv cu alte iniiative nrudite i programe i proiecte destinate acelorai
scopuri.
Monitorizarea, controlul i evaluarea activitilor vor fi realizate de-a lungul ntregului
proiect pentru a putea identifica i rezolva rapid orice problem legat de organizarea i
coordonarea proiectului.
Asigurarea calitii proiectului urmrete realizarea unui sistem eficient de verificare i
pstrare a documentaiilor tehnice i financiare ale proiectului, care s asigure siguran i un
acces facil la aceste documentaii.
Activitile de management de proiect trebuie sa acopere cel puin:
a. coordonarea i administrarea activitilor tehnice;
b. coordonarea i administrarea echipelor de proiect;
c. definirea i implementarea planului de comunicare n cadrul proiectului;
d. revizuirea i administrarea modificrilor proiectului;
e. pregtirea i ntreinerea planul de proiect n care sunt nregistrate activitile,
sarcinile, termenele de execuie i estimrile asupra desfurrii proiectului;
f. organizarea i conducerea ntlnirilor periodice cu echipa de proiect cu scopul
de a reanaliza starea proiectului;
g. pregtirea rapoartelor periodice; din aceste rapoarte va rezulta progresul
activitilor, eventualele ntrzieri, motivele ntrzierilor, riscurile aferente i
metode sau aciuni de redresare;

7.2.3. Cerine de raportare

 Raport Initial. Acesta va conine un raport de ncepere i un plan detaliat al derulrii
activitilor pentru toate componentele i fazele proiectului. Termenul de predare va fi de
maximum 4 sptmni de la nceperea proiectului, n vederea revizuirii. Acestea vor
cuprinde n mod obligatoriu urmtoarele componente:
o Aprecierea privind situaia existenta cu principalele probleme identificate;
o Definirea i programarea activitilor din proiect;
o Organizarea echipei sale;
o Un plan de pregtire detaliat;
o O planificare detaliata a activitilor proiectului i contribuiile pentru ntreaga
o perioada de implementare a proiectului;
o Propuneri i recomandri,
o Pentru elaborarea raportului de ncepere n termenul stabilit, Beneficiarul va
asigura toate informaiile necesare Furnizorului.
Rapoarte de progres. Aceste rapoarte vor fi elaborate trimestrial, informnd Managerul de
Proiect al Beneficiarului asupra evoluiei i stadiului activitilor prestate. Rapoartele vor
sublinia activitile contractorului i vor descrie stadiul lucrrilor n perioada raportata.
Vor fi identificate problemele, punctele de referina i realizrile semnificative.
Rapoartele vor cuprinde urmtoarele:
o Activitati desfurate n timpul perioadei raportate, precum i progresul
nregistrat, prin comparaie cu planificarea iniiala a proiectului (Project plan);
o Dificultile ntmpinate n cursul implementrii proiectului i soluiile propuse
pentru a depi respectivele dificulti;
o Rezultatele realizate n cursul perioadei de raportare, resursele utilizate, precum i
recomandrile sau solicitrile aferente i planificarea activitilor proiectului
pentru perioada urmtoare;
o Activitati planificate pentru perioada urmtoare de raportare;
o Sumarul controlului schimbrilor proiectului;
o Probleme, riscuri i recomandri;
Beneficiarul poate s solicite ofertantului s transmit rapoarte de progres intermediare ori de
cate ori reprezentanii si identifica n desfurarea activitati de implementare anumite
aspecte specifice.
Rapoarte intermediare. ntruct sarcinile ofertantului vor fi etapizate, rapoartele
intermediare sunt solicitate pentru informarea Beneficiarului despre rezultatele fiecrei
 etape (de exemplu finalizarea etapei de analiza), soluiile date i deciziile majore ce
trebuie luate. Structura acestor rapoarte intermediare va fi stabilita mpreuna cu
reprezentanii Beneficiarului, cu luarea n considerare a aspectelor concrete ale activitati,
n prima edina de proiect.
Raport final. Acesta trebuie sa fie redactat la sfritul perioadei de execuie. Proiectul
acestuia trebuie transmis cu cel puin doua sptmni nainte de sfritul perioadei de
execuie a contractului. El trebuie sa descrie ntreg procesul de implementare a
programului i care va nlesni evaluarea rezultatelor obinute n termeni att calitativi, cat
i cantitativi. Raportul va include de asemenea, o evaluare a succesului proiectului.
Raportul trebuie sa cuprind:
o Evaluarea succesului i constrngerilor majore pentru fiecare activitate i sarcina;
o Realizrile generale ale programului;
o Activitati n derulare cu data estimativa a finalizrii acestora i cu rezultatele
anticipate;
o Recomandri pentru aciuni viitoare cu scopul asigurrii sustenabilitii
activitilor programului, rezultatele ateptate de la acest proiect dup finalizarea
lui, precum i masuri ce trebuie ntreprinse de ctre Solicitani i Utilizatori n
acest sens.
Rapoartele vor avea o pagina iniiala ce va include: numele contractului, codul
contractului sau referine, titlul raportului, data emiterii i perioada acoperita, numele i
adresa Furnizorului.
Toate rapoartele trebuie depuse spre aprobare Beneficiarul.
Beneficiarul, n termen de 7 zile de la primirea rapoartelor documentelor, va notifica n
scris decizia sa cu privire la acestea, cu indicarea motivelor n cazul respingerii
rapoartelor sau al solicitrii unor clarificri sau a unor modificri. Daca Beneficiarul nu
transmite n interiorul termenului de notificare nici un comentariu cu privire la rapoartele
primite, ofertantului poate solicita o aprobare n scris a acestora. Rapoartele vor fi
considerate ca fiind aprobate de ctre beneficiar daca acesta nu l informeaz expres pe
implementator de existenta oricror comentarii n termen de 7 zile de la primirea
solicitrii scrise.
In situaia n care un raport este aprobat de ctre Beneficiar condiionat de operarea unor
modificri de ctre implementator, Beneficiarul va stabili o perioada de efectuare i
retransmitere a rspunsurilor la clarificri sau a modificrilor solicitate.
8. Cerine de administrare, operare i mentenan

8.1. Funcionaliti de tip suport pentru DES

In cadrul DES se vor avea n vedere i asigurarea unor subsisteme de suport de genul:
Un sistem de monitorizare a componentelor DES i logarea evenimentelor pentru
platforma hardware i software
Un sistem de auditare i securitate a tuturor activitilor i evenimentelor desfurate n
cadrul DES (de la infrastructura la aplicaie), conform specificului datelor de tip personal
care va fi gestionat de acesta
O componenta de tip help inclusa in aplicatie pentru toi utilizatorii sistemului. Acesta va
fi compus din ghiduri si/sau manuale de folosire a aplicaiei n funcie de rolul
utilizatorilor.
O componenta de support help-desk. Acesta va asigura suportul pentru utilizatorii
platformei; nivelul 1 de suport va fi realizat de catre CNAS.
8.2. Cerine mentenan

8.2.1. Servicii de suport hardware n garanie

Mentenan hardware va acoperi serviciile de garanie hardware pentru o durata de 3 ani de la
acceptanta finala i va pune la dispoziie servicii de tip Helpdesk i de remediere a
funcionalitii soluiei, conform nivelului de suport de mai jos.
Pe durata celor 3 ani de garanie ofertantul va respecta urmtorul nivel de suport garantat
(SLA Service Level Agreement):
Orarul de lucru: 24 ore x 7 zile pe sptmna, 365 de zile pe an
Timpul de rspuns la incident: Maxim 30 de minute de la nregistrarea apelului de
suport
Timp de rezolvare a incidentelor hardware: Maxim 24 ore de la nregistrarea apelului de
suport
Numr de intervenii: Nelimitat pe durata perioadei de garanie
Piese de schimb: ofertantul va furniza fr costuri suplimentare toate piesele de schimb
necesare (piesele defecte pot fi returnate ofertantului)
Remedierea defeciunilor hardware se va face prin nlocuirea componentelor defecte cu
componente noi aflate n buna stare de funcionare i certificate de ctre furnizorul de
echipamente.
Serviciile de suport hardware se vor efectua de ctre echipa de specialiti autorizai pentru
servicii de mentenan hardware pe platformele respective de ctre productorul de
echipamente.
Pentru efectuarea serviciilor de mentenan hardware, ofertantul trebuie sa fac dovada
accesului la un stoc de piese corespunztor aflat n tara, cat i la laboratoare specializate
pentru testarea i remedierea defeciunilor de produs, inclusiv mbuntiri aduse
microcodului. n acest sens, ofertantul va furniza o lista a inventarului de piese de schimb
dedicat meninerii n stare de funcionare a echipamentelor pe durata celor 3 ani de servicii de
suport n garanie. Ofertantul va asigura la cerere accesul CNAS la stocul de piese de schimb
n vederea verificrii inventarului.
In mod periodic (trimestrial), ofertantul va face o inspecie tehnica a echipamentelor
hardware i va ntreprinde aciuni menite a preveni apariia anumitor evenimente nedorite
(mentenan hardware preventiva), aciuni care vor fi eventual nsoite i de recomandri
tehnice fcute CNAS pentru optimizarea exploatrii sistemului.

8.2.2. Suportul software n garanie

Suportul software va acoperi serviciile de garanie software pentru o durata de 3 ani de la
acceptanta finala i va pune la dispoziie servicii de tip Helpdesk i de remediere a
defeciunilor software aprute la produsele software livrate, conform nivelului de suport de
mai jos
Pe durata celor 3 ani de garanie ofertantul va respecta urmtorul nivel de suport software
garantat (SLA Service Level Agreement):
Orarul de lucru: 24 ore x 7 zile pe sptmna, 365 de zile pe an
Timpul de rspuns la incident: Maxim 30 de minute de la nregistrarea apelului de
suport
Timp de rezolvare a incidentelor software: Maxim 24 ore de la nregistrarea apelului de
suport
Numr de intervenii: Nelimitat pe durata perioadei de garanie
Remedierea defeciunilor software se va face prin aciuni de aplicare de corecii software, de
reconfigurare, de restaurare de date sau alte aciuni menite sa restabileasc funcionalitatea
produsului respectiv n cel mai scurt timp posibil.
Serviciile de suport software vor fi furnizate de ctre specialiti cu pregtire i experiena pe
produsele respective. n cazul unor probleme de dificultate ridicata, suportul trebuie sa
asigure i escaladarea problemei la productor, pentru o diagnosticare cat mai rapida i
eficienta i chiar intervenia la sediul CNAS.
9. Testarea, instalarea, punerea n funciune i recepia sistemului

9.1. Cerine globale

Instalarea si punerea in funciune a sistemelor de operare, a pachetelor de programe

necesare si a fiecrui modul n parte al aplicaiilor la nivel de servere i staii de lucru, va
fi realizat de ctre personalul Furnizorului mpreuna cu reprezentanii Beneficiarului.
Beneficiarul va asigura condiiile tehnice pentru desfurarea n bune condiiuni a acestor
activiti pe amplasamente.
Instalarea sistemului se va face n termen de maximum 30 zile calendaristice de la data
livrrii software-ului aferent, n conformitate cu Graficul de livrare i de prestare a
activitilor.
Testarea sistemului va fi efectuat mpreun cu personalul de specialitate al
Beneficiarului, instruit n prealabil de Furnizor.
Termenii i condiiile de testare a sistemului sunt cei descrii n Anexa Planurile de
testare livrate i acceptate de Beneficiar.
Punerea n funciune a modulelor i a ntregului sistem se va face de ctre specialitii
Furnizorului, n prezena specialitilor Beneficiarului. Responsabilitatea pentru aceste
activiti revine integral Furnizorului.
Fiecare faz se va finaliza cu o acceptan parial i semnarea unui Proces-verbal semnat de
ambele pri.
Dup realizarea testelor de acceptan pentru ntregul sistem se va semna acceptana final,,
moment n care sistemul va intra n producie i va ncepe perioada de garanie si mentenan.
9.2. Organizarea activitii de testare

Ofertantul va efectua un ciclu de testare normal al aplicaiilor, conform ciclului

standard in V, respectiv va acoperi urmtoarele faze de testare;
Testare unitar
Testare de integrare
Testare de sistem
Testare de acceptan

Ofertantul va include ca un minimum n lista de livrabile proiect;

o Strategia de testare;
 o Planul testelor de acceptan.

Ofertantul va include n planurile de testare o matrice de trasabilitate care s demonstreze

acoperirea cerinelor funcionale (scenarii de utilizare) i non-funcionale (securitate,
performan, disponibilitate, etc), din punct de vedere al testrii.

Ofertantul va descrie modul de organizare a activitii de testare precum i platforma de

testare utilizat, inclusiv aspecte legate de ;
o Gradul de acoperire a verificrii cerinelor;
o Automatizarea activitii de testare;
o Testarea de regresie;
o Testarea non-funcional (performan, securitate, disponibilitate);
o Documentarea i monitorizarea testrii.

9.3. Organizarea certificrii (testrii de conformitate a)

aplicaiilor client

nceperea desfurrii n producie a sistemului DES necesit conectarea cu sistemele

informatice medicale externe (spitale, medici de familie, furnizori de servicii medicale).

Sistemele informatice medicale externe, pentru a putea accesa sistemul central DES, vor
trebui s fie certificate ca sunt conforme cu cerinele DES (funcionalitate, securitate).

CNAS va selecta un grup int corespunztor i semnificativ pentru a constitui grupul iniial
de furnizori de servicii medicale (FSM furnizori de servicii medicale) ce se vor conecta la
DES.

Ofertantul va propune o strategie de certificare a FSM, incluznd:

o calendarul de certificare (conform cu cerinele CNAS);
o organizarea platformei de certificare;
o canalele de comunicare cu fiecare FSM;
o planul de teste de certificare;
 o condiii obligatorii la nivel FSM pentru a ncepe executarea testrii;
o rapoarte de certificare.

Strategia de certificare va fi definitivat ca activitate n proiect.

Ofertantul va asista CNAS n executarea activitii de certificare propriu-zise, ca activitate a
acestui proiect.
10. Cerine de instruire a utilizatorilor

10.1. Instruire

Ofertantul va avea n vedere urmtoarele obiective ale activitii de instruire;

o pregtirea unui numr de utilizatori cheie ai beneficiarului care s poat disemina n
teritoriu utilizarea optim a sistemului;
o accesibilitatea cursurilor de ctre orice utilizator potenial al sistemului (de exemplu n
format manual electronic, instruire la distan, etc);
o monitorizarea i mbuntirea eficienei instruirii, pe parcursul desfurrii proiectului.

10.2. Cerine generale

Ofertantul trebuie s livreze urmtoarele livrabile de instruire:

Metodologia de instruire se va furniza n etapa de iniiere a proiectului, va conine
tipurile de instruire, abordarea metodologic, numrul de angajai care urmeaz a fi
instruii, numrul i cerinele referitoare la instructori, programul general de instruire,
condiiile i cerinele necesare;
Planul de instruire detaliat trebuie s fie elaborat cu 15 zile nainte de prima zi de
instruire, cu descrierea metodologiei de instruire, planul de resurse pentru cerinele de
instruire, lista materialelor de instruire, listele de prezen, datele persoanelor de contact,
alte documente pentru facilitarea organizrii i desfurrii cursurilor;
Materialele de instruire (pe hrtie / n format electronic) vor include cel puin:
o Prezentri (in format de prezentare electronica, slide show);
o Suportul de curs tiprit pentru fiecare participant la instruire;
o Suportul de curs, in format electronic, pentru nvare individual i alte activiti
de instruire
Certificat de instruire: atest finalizarea de ctre fiecare cursant, n bune condiiuni, a
instruirii respective
o Ofertantul trebuie s asigure instructori adecvai, bine pregtii i personalul de
suport necesar pentru instruire, conform Conceptului de Instruire i Planului de
Instruire detaliat acceptate;
 o Instruirea va fi n limba romn, susinut de ctre instructori autorizai. n cazul
instruirilor de produs, furnizorul instruirii va trebui s posede o autorizare din
partea productorului produselor software respective;
o Instruirile trebuie s fie documentate prin Rapoarte de instruire i prin condicile de
prezen completate. nceperea implementrii nu este condiionata de finalizarea
cursurilor.

10.3. Cerine specifice

Sistemul DES va conine un manual electronic de utilizare, disponibil pe portalul de

aplicaie, destinat tuturor categoriilor de utilizatori;
Instruire utilizatori sistem DES:
o Cursuri de utilizare a aplicaiilor DES n regim TTT (train-the-trainer), pentru cte
2 reprezentani ai Beneficiarului, din fiecare jude. Acest curs se va desfura n
serii de maximum 20 de persoane;
o Cursuri de utilizare a aplicaiilor DES n regim de instruire la distan (eLearning).
Cursurile vor putea fi descrcate de pe site-ul web al CNAS i rulate individual,
de ctre fiecare utilizator potenial, pe o staie de lucru local (PC).
Instruire tehnic DES:
o Produs cursuri standard de produs adresate specialitilor IT. Vor fi susinute
cursuri de administrare pentru produsele software incluse in oferta. Vor fi
susinute cursuri standard ale productorului produselor software, aa cum se
regsesc descrise pe site-ul public al acestuia. Numrul de participani va fi de
maxim 10 pentru fiecare dintre sesiunile de curs;
o Suport cursuri personalizate destinate personalului care va ntreine sistemul
(Nivel 1 de suport);
o Administrare a sistemului (hardware, software ) pentru 5 persoane. Cursurile de
administrare se vor desfasura pe o perioada de maxim 15 zile lucratoare