media.hotnews.ro · Web viewOdată cu implementarea tuturor fazelor sistemului, va creşte gradul...
322
SECTIUNEA II : CAIET DE SARCINI SISTEM INFORMATIC INTEGRAT PENTRU DOSARUL ELECTRONIC DE SĂNĂTATE
Transcript of media.hotnews.ro · Web viewOdată cu implementarea tuturor fazelor sistemului, va creşte gradul...
SECTIUNEA II : CAIET DE SARCINI
SISTEM INFORMATIC INTEGRAT PENTRU
DOSARUL ELECTRONIC DE SĂNĂTATE
Cuprins1. Prescurtări şi definiţii..............................................................................................7
2. Informaţii Generale .............................................................................................10
2.1. Autoritatea contractantă ..........................................................................................10
2.1.1. Descrierea instituţiei – domeniu de activitate şi atribuţii ......................................................10
2.1.2. Structura CNAS.......................................................................................................................12
2.1.3. Locaţia proiectului..................................................................................................................15
2.2. Context ....................................................................................................................15
2.2.1. Situaţia actuală.......................................................................................................................19
2.2.2. Situaţia î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 evoluţie a sistemului medical..............................................................32
4.1. Definiţii şi concepte...................................................................................................32
4.2. Organizarea sistemului Dosarul Electronic de Sănătate al pacientului (DES)...............35
5. Descrierea tehnică a proiectului............................................................................38
5.1. Arhitectura funcţională a sistemului..........................................................................39
5.1.1. Subsisteme funcţionale.........................................................................................................41
5.2. Vedere de ansamblu asupra sistemului informatic....................................................59
5.3. Scenarii de utilizare...................................................................................................62
2
5.3.1. Accident şi INTERVENŢIE de urgenţă......................................................................................63
5.3.2. Internare la spital şi operaţie................................................................................................64
5.3.3. Accesul asiguratului în portal.................................................................................................66
5.3.4. Internare la spital şi investigaţii laborator.............................................................................67
5.3.5. Dializă.....................................................................................................................................69
5.3.6. Auditarea sistemului..............................................................................................................70
5.3.7. Exemplu de urmărire a unui episod de boala.........................................................................70
5.3.8. Interogare date demografice.................................................................................................71
5.3.9. Interogare vocabulare............................................................................................................71
5.3.10. Interogare unităţi 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 înregistrărilor medicale.........................................................................................74
5.4.2. Gestiunea istoricului pacientului............................................................................................74
5.4.3. Preferinţe, indicaţii, consimţăminte şi autorizaţii..................................................................75
5.4.4. Liste specifice.........................................................................................................................75
5.5. Suport clinic..............................................................................................................76
5.5.1. Informaţii despre prestatorul de servicii medicale.................................................................76
5.5.2. Registrul pacienţilor (preluate din eCard)..............................................................................77
5.6. Rapoarte, măsurători, 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 entităţilor........................................................................................................79
5.7.2. Autorizarea entităţilor............................................................................................................80
5.7.3. Controlul accesului.................................................................................................................80
5.7.4. Gestiunea accesului pacienţilor..............................................................................................80
5.7.5. Recunoaşterea acţiunilor.......................................................................................................80
5.7.6. Schimbul sigur de date...........................................................................................................81
5.7.7. Rutarea securizata a datelor..................................................................................................81
5.7.8. Certificarea informaţiilor........................................................................................................81
5.7.9. Gestiunea înregistrărilor medicale.........................................................................................83
3
5.7.10. Stocarea şi gestiunea informaţiilor 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 aplicaţii bazata pe standarde.......................................................................85
5.9.3. Acorduri de schimb de date...................................................................................................85
5.10. Cerinţe 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. Funcţionalităţi expuse de sistemul SIUI prin servicii web.........................................88
5.11.1. Fluxuri de date între componente......................................................................................103
5.11.2. Raportările SIUI..................................................................................................................105
5.11.3. Nomenclatoare - cataloage SIUI.........................................................................................106
5.11.4. Integrări SIUI......................................................................................................................107
5.12. Fluxuri de date intre componente .........................................................................115
5.12.1. Fluxuri de execuţie SOA (Service Oriented Architecture)...................................................115
5.12.2. Fluxuri de autorizare şi autentificare..................................................................................116
5.12.3. Fluxuri de suport pentru funcţionalitatea de raportare.....................................................117
5.12.4. Fluxuri de procesare a evenimentelor de monitorizare.....................................................117
5.12.5. Cerinţe subsistem de integrare..........................................................................................118
5.12.6. Cerinţe subsistem monitorizare.........................................................................................123
5.12.7. Cerinţe subsistem audit.....................................................................................................123
5.12.8. Cerinţe subsistem salvare şi restaurare.............................................................................123
5.12.9. Cerinţe subsistem help desk..............................................................................................124
5.12.10. Cerinţe subsistem de arhivare..........................................................................................124
5.12.11. Cerinţe subsistem de comunicaţii....................................................................................124
6. Cerinţe tehnice detaliate.....................................................................................126
6.1. Cerinţe hardware detaliate.....................................................................................127
6.1.1. Cerinţe minime obligatorii pentru sistem de procesare a datelor (2 bucăţi) .......................129
6.1.2. Cerinţe minime obligatorii pentru infrastructura de stocare (2 bucăţi):..............................131
6.1.3. Cerinţe minime obligatorii pentru infrastructura de biblioteca de benzi (1 bucata):..........134
6.1.4. Cerinţe minime obligatorii pentru infrastructura de SAN (2 bucăţi):...................................137
4
6.1.5. Cerinţe comunicaţii..............................................................................................................140
6.2. Cerinţe software detaliate.......................................................................................143
6.2.1. Monitorizare sisteme şi aplicaţii.........................................................................................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 aplicaţii.................................................................................................................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 relaţionala...............................................................................177
6.2.13. Audit..................................................................................................................................179
7. Cerinţe servicii de implementare.........................................................................181
7.1. Mod de implementare............................................................................................181
7.1.1. Servicii de implementare.....................................................................................................181
7.1.2. Planificarea activităţilor.......................................................................................................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. Activităţi de management de proiect...................................................................................189
7.2.3. Cerinţe de raportare ...........................................................................................................190
8. Cerinţe de administrare, operare şi mentenanţă.................................................194
8.1. Funcţionalităţi de tip suport pentru DES..................................................................194
8.2. Cerinţe mentenanţă................................................................................................194
8.2.1. Servicii de suport hardware în garanţie...............................................................................194
8.2.2. Suportul software în garanţie...............................................................................................195
9. Testarea, instalarea, punerea în funcţiune şi recepţia sistemului........................197
9.1. Cerinţe globale........................................................................................................197
9.2. Organizarea activităţii de testare.............................................................................197
5
9.3. Organizarea certificării (testării de conformitate a) aplicaţiilor client.......................198
10. Cerinţe de instruire a utilizatorilor....................................................................200
10.1. Instruire................................................................................................................200
10.2. Cerinţe generale....................................................................................................200
10.3. Cerinţe specifice....................................................................................................201
6
1. Prescurtări şi definiţii
Termen Explicaţie
ADT Admission, Discharge and Transfer
BI Business Intelligence
CA Certificate Authority
CASE Cardul de Asigurare de Sănătate European
CASMB Casa de Asigurări de Sănătate a Municipiului Bucureşti
CASMTCT
Casa Asigurărilor de Sănătate a Ministerului Transporturilor,
Construcţiilor şi Turismului
CASAOPSNAJ
Casa Asigurărilor de Sănătate a Apărării, Ordinii Publice,
Siguranţei Naţionale şi Autorităţii Judecătoreşti
CDA Clinical Document Architecture
CDR Clinical Data Repository
CEN Comisia Europeană de Normalizare (Standardizare)
CIS Clinical Information System
CEAS Cardul Electronic de Asigurări de Sănătate
CJAS Casa Judeţeană de Asigurări de Sănătate
CMS Centers for Medicare and Medicaid Services
CNAS Casa Naţională de Asigurări de Sănătate
CNIN Compania Naţională "Imprimeria Naţională"
CNP Codul Numeric Personal
DES Dosar Electronic de Sănătate
DICOM Digital Imaging and Communications în Medicine
DMR Date Medicale Relevante
DMZ DeMilitarized Zone
EAL4 Evaluation Assurance Level 4
7
Termen Explicaţie
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 Naţional Unic de Asigurări de Sănătate
FOCG Foaia de Observaţie Clinică Generală
GP General Practitioner
HIPAA Health Insurance Portability and Accountability Act
HIS Hospital Information System
HITECH
Health Information Technology for Economic and Clinical
Health
HL7 Health Level Seven
HL7 V3 Health Level Seven Version 3
HTTP Hyper Text Transfer Protocol
ICD International Classification of Diseases
ICD-9-CM
International Classification of Diseases, 9th Revision, Clinical
Modification
ICD-10-CM
International Classification of Diseases, 10th Revision, Clinical
Modification
ICD-10-PCS
International Classification of Diseases, 10th Revision,
Procedure Coding System
IDS Intrusion Detection System
IPS Intrusion Prevention System
IHE Integrating Healthcare Enterprise
ISO International Organization for Standardization
8
Termen Explicaţie
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 Sănătăţii
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
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
9
Termen Explicaţie
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 Informaţiei
TIC Tehnologia Informaţiei şi a Comunicaţiei
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
10
11
2. Informaţii Generale
2.1. Autoritatea contractantă
Numele instituţiei conform actului de
înfiinţare:
Casa Naţionala de Asigurări de Sănătate
Cod de înregistrare fiscală: 11697800
Adresa poştală: Calea Călăraşi 248, Bl. S19, Sector 3,
030634, Bucureşti
Telefon / Fax: 0372309252 / 0372309165
Adresa e-mail: [email protected]
2.1.1. Descrierea instituţiei – domeniu de activitate şi atribuţii
Casa Naţională de Asigurări de Sănătate (CNAS) este instituţie publică, autonomă, de
interes naţional, cu personalitate juridică, al cărei principal obiect de activitate îl reprezintă
asigurarea funcţionării unitare şi coordonate a sistemului asigurărilor sociale de sănătate
din România.
Sistemul asigurărilor sociale de sănătate oferă un pachet de servicii de bază care cuprinde
servicii medicale, servicii de îngrijire a sănătăţii, medicamente, materiale sanitare şi
dispozitive medicale.
CNAS funcţionează pe baza Statutului propriu şi are următoarele obligaţii:
o să asigure logistica funcţionării unitare şi coordonate a sistemului asigurărilor sociale
de sănătate;
o să urmărească folosirea cu eficienţă a fondului de asigurări sociale de sănătate;
o să folosească mijloace adecvate de mediatizare pentru reprezentarea, informarea şi
susţinerea intereselor asiguraţilor pe care îi reprezintă;
o să acopere nevoile de servicii de sănătate ale persoanelor, în limita fondurilor
disponibile.
o CNAS are în subordine casele judeţene de asigurări de sănătate, Casa de Asigurări de
Sănătate a Municipiului Bucureşti, Casa Asigurărilor de Sănătate a Ministerului
Transporturilor, Construcţiilor şi Turismului, Casa Asigurărilor de Sănătate a Apărării,
Ordinii Publice, Siguranţei Naţionale şi Autorităţii Judecătoreşti.
Principalele atribuţii ale CNAS:
• asigură, supraveghează şi controlează funcţionarea sistemului de asigurări sociale de
sănătate;
• gestionează, prin intermediul preşedintelui CNAS, FNUASS în concordanţă cu legile
în vigoare şi având în subordine casele judeţene de asigurări de sănătate, inclusiv
CASMB, CASMTCT şi CASAOPSNAJ
• propune, cu avizul MS, proiecte de acte normative pentru asigurarea funcţionării
sistemului de asigurări de sănătate şi acordă avize conform proiectelor de acte
normative care au incidenţă asupra FNUASS
• elaborează, implementează şi gestionează procedurile şi formularele unitare, avizate de
către MS, pentru administrarea sistemului de asigurări de sănătate
• elaborează şi publică rapoarte anuale
• asigură organizarea sistemului informatic şi informaţional unic integrat pentru
înregistrarea asiguraţilor şi pentru gestionarea FNUASS. Indicatorii folosiţi în
raportarea datelor în sistemul de asigurări de sănătate sunt unitari şi se stabilesc de
către MS la propunerea CNAS, Colegiul Medicilor din România şi Colegiul Medicilor
Stomatologi din România
• aprobă anual bugetele de venituri şi cheltuieli ale caselor de asigurări de sănătate în
condiţiile legii şi, după caz, cu avizul ministerelor şi al instituţiilor centrale cu reţele
sanitare proprii, corespunzătoare unui plan de activităţi, precum şi obiectivele de
investiţii, la propunerea acestora;
• negociază criteriile privind calitatea asistenţei medicale acordate asiguraţilor din
sistemul de asigurări sociale de sănătate, elaborate de Colegiul Medicilor din România;
• participă la licitaţiile naţionale organizate de Ministerul Sănătăţii în vederea achiziţiei
de medicamente şi materiale sanitare specifice pentru realizarea programelor de
sănătate şi încheie şi derulează contracte de achiziţii publice pentru medicamente şi
materiale sanitare specifice pentru realizarea acestor programe;
o asigură şi controlează respectarea dreptului asiguraţilor la servicii medicale,
medicamente şi materiale sanitare în mod nediscriminatoriu, în condiţiile 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 admişi să lucreze în sistemul de asigurări sociale de sănătate;
o acordă gratuit informaţii, consultanţă şi asistenţă în domeniul asigurărilor sociale de
sănătate persoanelor asigurate, angajatorilor şi furnizorilor de servicii medicale.
2.1.2. Structura CNAS
Structura organizatorică CNAS se prezintă după cum urmează:
o Preşedinte
o Vicepreşedinte
o Vicepreşedinte
o Director General
o Direcţia Generală Management
o Direcţia Generală cu Furnizorii
o Direcţia Generală Evaluare
o Direcţia Monitorizare şi Corp Control
o Direcţia Relaţii Media, Relaţii publice, Purtător de cuvânt
o Compartiment Audit Public Intern
o Direcţia Juridic, Contencios şi Acorduri Internaţionale
o Direcţia Resurse Umane
o Direcţia Sisteme Informatice
o Direcţia Strategii, Metodologii şi Norme
o Centrul de Prognoză şi Planificare
o Direcţia Contractare, Decontare
o Direcţia Buget, Creanţe, Indemnizaţii şi Concedii Medicale
o Direcţia Financiar, Contabilitate şi Salarizare
o Direcţia Logistică
o Serviciul Achiziţii Publice, Contracte, Investiţii
o Direcţia Evaluare Furnizori
o Direcţia Programe Naţionale
Diagrama de relaţii a Casei Naţionale de Asigurări de Sănătate:
2.1.3. Locaţia proiectului
ROMÂNIA
Judeţul / Judeţe: Bucureşti
Localitatea / Localităţi: Bucureşti
Adresa / Adresele de
implementare:
Splaiul Independenţei nr. 323A, sector 6, Bucureşti, cod
poştal 060044
2.2. Context
Serviciile medicale de înaltă calitate oferite pacienţilor şi crearea unui spaţiu informaţional
unic în domeniul sănătăţii reprezintă principalele coordonate ale strategiei e-Sanatate
promovată de Comisia Europeana la nivelul ţarilor membre. În 2004, Comisia Europeană a
adoptat planul de acţiune 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
acţiune acoperă toate sistemele aferente serviciilor de sănătate, de la prescripţia electronică,
până la noi sisteme care sporesc eficienţa cadrelor medicale şi care reduc nivelul de erori
medicale. O prioritate în acest sens este dezvoltarea unei infrastructuri informaţionale,
infrastructură ce îşi propune eficientizarea mediului medical în statele membre, mediu în care
se resimte acut nevoia de partajare a informaţiilor de natură clinică şi nu numai.
Dimensiunea informatizării sistemului de sănătate depăşeşte sfera IT, pentru realizarea cu
succes a acesteia fiind necesară armonizarea cadrului legal, a cadrului de desfăşurare a actului
medical şi un efort susţinut în domeniul TIC. Informatizarea sistemului de sănătate nu
presupune doar implementarea unui sistem informatic, ci şi adaptarea cadrului legal astfel
încât să suporte facilităţile sistemului fără a crea tensiuni între pacienţi şi cadrele medicale,
dar şi alinierea procedurilor din domeniul sănătăţii cu noua perspectivă a sistemului
informatizat.
Informatizarea cu succes a sistemului de sănătate presupune agregarea specificului celor 3
deziderate menţionate anterior într-o strategie unică naţională de informatizare, al cărei scop
unic principal să fie poziţionarea pacientului în mijlocul sistemului de sănătate, în
conformitate cu strategia e-Sanatate la nivel european. Până în prezent, direcţiile de
informatizare ale sistemului de sănătate au vizat mai mult eficientizarea şi îmbunătăţirea
controlului asupra raportărilor făcute de furnizorii de sănătate, decât orientarea către
eficientizarea şi îmbunătăţirea episodului de îngrijire.
Un aspect foarte important este susţinerea politică de care acest program beneficiază, fiind
inclus în Programul de Guvernare 2009-2012. Acest lucru, în corelaţie cu programul privind
strategia e-Sanatate la nivelul comunităţii europene, completează şi creează premisele
dezvoltării şi implementării unei strategii naţionale de informatizare a sistemului de sănătate.
În prezent, tehnologiile TIC sunt utilizate aproape în tot sistemul sanitar, în moduri diferite şi
pentru scopuri diferite. Faţă de alte sectoare, tehnologiile informaţionale şi comunicaţionale
sunt folosite mult mai puţin în sănătate. Pana în prezent, doar anumite domenii din sectorul
sanitar au utilizat tehnologii TIC, din diverse motive: dificultăţi în agrearea unor cerinţe
specifice de interoperabilitate pentru soluţiile e-Sănătate, nevoia de comunicare nu a fost aşa
de mare în trecut, dar şi costurile ridicate ale soluţiilor 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, investiţiile în IT nu au fost însoţite de
dezvoltarea competenţelor utilizatorilor. În plus, costurile privind mentenanţa şi operarea
post-implementare au fost de cele mai multe ori subestimate.
Proiectul se află în concordanţă cu Planul Naţional de Dezvoltare a României 2007 – 2013
întrucât promovează dezvoltarea economiei bazate pe cunoaştere prin accelerarea dezvoltării
societăţii informaţionale. Acest aspect va fi realizat în cadrul proiectului prin dezvoltarea
serviciilor de e-sănătate destinate facilitării actului medical, prin accesarea în timp real a
datelor despre pacient, a istoricului sau medical, a rezultatelor investigaţiilor efectuate,
tratamentele pe care le urmează şi eventualele intoleranţe ale pacientului la anumite substanţe
medicale.
Proiectul răspunde priorităţii Cadrului Strategic Naţional de Referinţa 2007 – 2013 –
consolidarea unei capacitaţi administrative eficiente – pentru ca îşi aduce aportul la
îmbunătăţirea 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 sănătate, ceea ce contribuie la adoptarea unor decizii
optime privind diagnosticarea pacienţilor şi prescrierea reţetelor medicale. Prin urmare,
soluţia „Dosarul Electronic de Sănătate - DES” va reprezenta un instrument eficient de
comunicare între toate părţile implicate (pacienţi, prestatorii de servicii medicale, Casa
Naţională de Asigurări de Sănătate şi Casele Judeţene de Asigurări de Sănătate), având rolul
de evitare a suprapunerii prescrierilor şi investigaţiilor şi de creştere a calităţii serviciilor
medicale.
Succint, situaţia actuală a sistemului românesc de sănătate poate fi caracterizata prin:
o Implementare insuficientă a standardelor TIC;
o Lipsa cooperării;
o Nivel scăzut de interoperabilitate între sistemele TIC actuale;
o Nivel scăzut de informatizare la nivelul furnizorilor de servicii de sănătate;
Lipsa aplicării standardelor naţionale şi internaţionale acceptate este unul dintre motivele
principale ale interoperabilităţii scăzute a sistemelor TIC actuale. Astfel, dificultăţile rezultate
din problemele de integrare a datelor şi problemele semantice ale schimbului de informaţii
reprezintă o consecinţă logică a acestei situaţii. Sistemul actual al serviciilor de sănătate din
România utilizează foarte multe circuite de informaţii pe hârtie şi semi-standardizate cu
interoperabilitate semantică scăzută, ceea ce implică munca laborioasă de introducere a
datelor, calitate scăzută a acestora şi conduce la o rată potenţială mare de producere a
erorilor. Acest lucru determină întârzieri în finalizarea rapoartelor şi costuri mari de operare
ale unui astfel de sistem.
Standardele din domeniul sănătăţii nu înseamnă doar liste ale codurilor standard şi
terminologii clinice, ci şi existenţa unor concepte acceptate la scară largă, exprimate într-un
model informatic formal, care este descris într-un dicţionar de date şi care stă la baza seturilor
standard de date utilizate pentru comunicarea dintre actorii din sistemul sanitar.
Din cauza lipsei standardizării şi a coordonării în sistemul de sănătate, există multe sisteme
informatice care nu fac schimb de date şi nu folosesc interfeţe pentru comunicare. Rezultatul
acestei situaţii este interoperabilitatea scăzută a sistemelor existente şi redundanţa 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 îmbunătăţirilor treptate ale nivelului de informatizare, încă nu există suficiente
resurse TIC la nivelul furnizorilor de servicii de sănătate. În timp ce spitalele mari au un nivel
de informatizare satisfăcător, spitalele mici şi cabinetele ambulatorii nu dispun de
calculatoare (reţeaua transfuziilor de sânge este un bun exemplu în acest sens). Mai mult,
personalul angajat în sănătate se caracterizează printr-un nivel scăzut de cunoştinţe IT,
situaţie care poate fi depăşită prin programe de instruire pentru utilizatori. Există, totodată, şi
un număr insuficient de specialişti TIC la nivelul furnizorilor de servicii de sănătate şi la
nivelul autorităţilor centrale.
Sistemul informatic din domeniul sănătăţii din România este o colecţie de sisteme,
instrumente, procese şi documente eterogene. Se doreşte exploatarea registrelor existente deja
în SIUI precum şi extinderea şi completarea lor cu noile informaţii / registre necesare.
Informatizarea sistemului de sănătate face parte din proiectul reformei sectorului sanitar,
având ca obiective finale îmbunătăţirea managementului şi a finanţării sectorului sanitar,
permiţând un control mai eficient al distribuţiei resurselor financiare, întărirea posibilităţii de
control, eficientizarea sistemului, îmbunătăţirea calităţii serviciilor de sănătate. Tehnologiile
informatice reprezintă o dimensiune obligatorie a sistemului de sănătate, crescând calitatea
serviciilor de sănătate şi fiind o sursă de economii financiare în sistem.
În absenţa implementării reglementarilor unitare privind standardele de informatizare,
precum şi datorită inexistenţei unui sistem de acreditari, certificări, avizări pentru furnizori,
sistemele informatice s-au realizat şi implementat într-o manieră dezorganizată. Acest lucru a
făcut ca informatica, în loc sa ajute activitatea medicală, să genereze mai degrabă confuzie,
birocraţie şi nesiguranţă. Au apărut paralelisme în culegerea datelor primare, dublarea unor
circuite de raportare, incompatibilităţi datorită utilizării unor definiţii diferite ale indicatorilor
şi a unor codificări proprietare, etc.. Din punct de vedere al derulării unor investiţii specifice,
nu o dată a fost reluată informatizarea unor sectoare care aveau deja soluţii acceptabile, în
detrimentul altor zone, ceea ce a generat neutilizarea eficientă a fondurilor publice.
Practica medicală internaţională de tip e-Sanatate permite folosirea tehnologiilor
informaţionale şi de comunicare şi în sectorul medical, prin realizarea dosarelor pacienţilor
pe suport electronic, facilitând accesul la informaţie, crescând calitatea actului medical,
reducând costurile şi eficientizând sistemele de sănătate.
Din punct de vedere al fişei pacienţilor, sunt reglementate o serie de aspecte şi proceduri care
prevăd obligativitatea furnizorilor de sănătate sa păstreze în format electronic sau scriptic
informaţii minime privind starea de sănătate a unui pacient. Un astfel de exemplu este
Ordinul nr. 1782/2006 care prevede obligativitatea utilizării Foii de Observaţie 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 pacienţii care beneficiază de servicii medicale în regim de
spitalizare de zi. Mai mult, actul normativ prevede un set minim de informaţii clinice pe care
unităţile sanitare trebuie să le raporteze lunar. Totuşi, din reglementările actului normativ,
este destul de uşor 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 informaţii de tip statistic şi nu de centralizare a informaţiilor clinice ale pacientului
într-o fişă unică. În contextul unei strategii naţionale de informatizare, actul normativ trebuie
modificat astfel încât, pe lângă obiectivul de raportare, să fie atins şi cel de centralizare a
informaţiilor pacientului. În anul 2007, Ministerul Sănătăţii a iniţiat o acţiune naţională de
colectare şi centralizare a stării de sănătate a populaţiei României. Rezultatele ar fi trebuit,
conform termenelor comunicate iniţial, să fie centralizate până la sfârşitul anului 2008, însă
în acest moment este incertă starea actuală. Informaţiile de acest tip ar putea reprezenta o
sursă importantă în cadrul unei strategii naţionale în domeniul sănătăţii. De asemenea, în
contractul-cadru de acordare a asistenţei medicale pentru anul 2009 sunt prevăzute o serie de
reglementări care au scopul de a încuraja raportarea în format electronic a laboratoarelor.
Măsura de încurajare este de tip financiar, prin acordarea unui număr de puncte mai mare
pentru laboratoarele care gestionează şi raportează activitatea în format electronic.
Un alt aspect foarte important îl reprezintă multitudinea de aplicaţii dedicate informaţiilor şi
serviciilor medicale implementate în sectorul privat. Conform situaţiei prezentate în raportul
ce vizează situaţia actuală, există o serie de unităţi sanitare care au implementat şi utilizează
astfel de programe. Un aspect negativ, care trebuie însă tratat în contextul unei strategii
naţionale de informatizare, îl reprezintă lipsa interoperabilităţii între sisteme, atât din punct de
vedere semantic şi tehnic, cât şi din punct de vedere legal. Lipsa implementării unor
standarde privind fişa 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 informaţiilor pentru pacienţii care au mai multe dosare de sănătate de
tip electronic.
Analizând întregul cadru al sistemului sanitar din România, se poate desprinde concluzia că
există o serie de iniţiative şi realizări care pot fi considerate într-o anumită măsură ca
reprezentând o parte din strategia de informatizare. Aici menţionăm sistemul SIUI care a
adoptat un model de funcţionare 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-sănătăţii recomandă accelerarea construirii unei reţele
sigure de informaţii în domeniul sănătăţii, extinderea utilizării cardului în sănătate, precum şi
asigurarea accesului on-line la datele medicale ale pacientului.
Aceeaşi tendinţă este, de asemenea, prevăzută şi în liniile directoare pentru Cardul de
Asigurare de Sănătate European (European Health Insurance Card) precum şi de planurile de
dezvoltare individuale ale Statelor Membre.
2.2.1. Situaţia actuală
Actualmente, în domeniul sănătăţii, funcţionează un Sistem Informatic Unic Integrat (SIUI)
destinat gestiunii Fondului Naţional Unic de Asigurări Sociale de Sănătate prin gestiunea on-
line a tuturor informaţiilor medicale ale pacienţilor asiguraţi, sistem ce este administrat de
CNAS şi de care beneficiază CNAS şi Casele Judeţene de Asigurări de Sănătate. Medicii şi
prestatorii de servicii medicale introduc în acest sistem toate consultaţiile, bolile şi
tratamentele pacienţilor asiguraţi cu scopul decontării acestora. SIUI procesează la momentul
de faţă tranzacţii de tip asigurări sociale, în calitate de plătitor de servicii de sănătate; în SIUI
se procesează de asemenea aspecte privind autentificarea, gestionarea solicitărilor şi a
rambursărilor. În plus, există date centralizate despre statistici, registre şi date tranzacţionale
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 hârtie la cea pe suport
electronic este determinată atât de progresul din cercetarea medicală, cât şi de cel din
domeniul tehnologiei. Tradiţionalul registru medical pe hârtie, care funcţionează ca un
depozit static al datelor ce reflectă starea de sănătate a pacientului în mod fracţionat şi care se
află într-un singur loc, îngrădind astfel accesul la aceste date, nu mai este în măsură să
satisfacă cerinţele noi din domeniul îngrijirii sănătăţii.
2.2.2. Situaţia în viitor
CNAS, având competenţa necesară, şi-a asumat responsabilitatea definirii şi implementării
soluţiilor informatice pentru::
• cardul de sănătate (eCard). Proiectul eCard (funcţionalitate a SIUI) care îşi propune să
devină un instrument de autentificare în cadrul tuturor sistemelor informatice care
compun strategia de eSănătate în România precum şi un instrument de prevenire a fraudei
în domeniul sănătăţii.
• prescripţia electronică (ePrescripţie). Proiectul ePrescripţie (funcţionalitate a SIUI)
contribuie la creşterea calităţii actului medical de prescriere a medicamentelor, precum şi
un instrument de monitorizare a necesarului şi consumului de medicamente în România.
• dosarul electronic de sănătate al pacientului (DES). Prin acest proiect se face trecerea la
forma electronică a dosarului de sănătate al pacientului prin intermediul căruia cetăţenii
asiguraţi vor beneficia de un nivel mai ridicat al calităţii serviciilor medicale.
Prin intermediul acestor proiecte se asigură mecanisme pentru autentificarea şi autorizarea
cetăţeanului pentru a primi servicii medicale şi de colectare a datelor de sănătate la nivel
naţional. Adiţional, aceste mecanisme pot să asigure o reducere a timpului de aşteptare a
cetăţeanului pentru a primi servicii medicale, vor creşte nivelul de calitate a datelor medicale
şi vor preveni frauda în domeniul sănătăţii.
2.3. Programe şi strategii relevante pentru proiect
Proiectul se află în concordanţă cu obiectivul specific al Domeniului Major de Intervenţie 2
(„Dezvoltarea şi creşterea eficienţei serviciilor publice electronice”) întrucât are ca scop
oferirea de servicii medicale prin mijloace electronice, creând astfel beneficii atât pentru
utilizatori (cetăţeni), cât şi pentru solicitant. Beneficiile pentru cetăţeni se manifestă, în
principal, prin întărirea statutului pacientului şi o mai bună participare a acestuia la actul
medical, precum şi prin furnizarea de servicii de asistenţă medicală fără limite operaţionale,
administrative sau geografice. Beneficiile la nivel instituţional îmbracă forma unor
instrumente de lucru pentru personalul din sănătate, ceea ce acţionează în direcţia
eficientizării managementului resurselor şi a creşterii eficienţei economice a serviciilor de
sănătate.
Extinderea utilizării TIC va asigura simplificarea procedurilor de lucru şi a procesului
decizional din cadrul instituţiei solicitante. Aceasta va favoriza furnizarea mai eficientă a
serviciilor şi creşterea calităţii lor în folosul cetăţenilor.
TIP DENUMIRE MOD DE RELAŢIONARE
PROGRAM POSCCE –Programul
Operaţional Sectorial –
Creşterea Competitivităţii
Economice
– Obiectivul specific al Domeniului Major
de Intervenţie 2 aferent Axei 3 este de a
pune la dispoziţie serviciile administrative
prin mijloace electronice, atât pentru
utilizatori (cetăţeni şi mediul de afaceri),
cât şi pentru administraţia publica.
Beneficiile utilizatorilor pot fi exprimate
succint printr-un acces facil la serviciile
administraţiei publice. Pentru autorităţile
care utilizează tehnologia informaţiei şi
comunicaţiilor în scopul furnizării de
servicii electronice, aceasta înseamnă noi
oportunităţi, dar şi schimbări interne la
nivel organizaţional. Rezultă conformitatea
proiectului propus cu respectivul obiectiv
având în vedere faptul că va facilita accesul
personalului medical la istoricul medical al
pacientului dar şi accesul mai facil al
pacienţilor la serviciile de sănătate
Proiectul propus susţine prin acţiunile şi
rezultatele urmărite (scăderea timpului
necesar diagnosticării, deci reintegrarea
mai rapida în câmpul 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 finanţării în cadrul Axei Prioritare
3 – privind creşterea interacţiunii între
sectorul public şi cetăţeni prin valorificarea
potenţialului TIC.
PROGRAM PODCA – Programul
Operaţional – Dezvoltarea
Capacitaţii Administrative
- direct, relaţionare atât cu Axa Prioritara 1
– Îmbunătăţiri de structură şi proces ale
managementului ciclului de politici
publice, cât şi cu Axa Prioritara 2 –
Îmbunătăţirea calităţii şi eficienţei
furnizării serviciilor publice cu accentul
pus pe procesul de descentralizare.
Prezentul proiect constituie un instrument
pentru atingerea unor obiective, precum:
îmbunătăţirea procesului de luare a
deciziilor, îmbunătăţirea eficacităţii
organizaţionale, îmbunătăţirea calităţii şi
eficienţei serviciilor furnizate de către
solicitant.
STRATEGI
E
Strategia de e-Santate - direct, prin faptul ca proiectul contribuie
la extinderea procesului de informatizare a
sectorului sanitar din România prin
întărirea statutului pacientului şi o mai
bună participare a acestuia la actul medical;
furnizarea de servicii de asistenţă medicală
fără limite operaţionale, administrative sau
geografice; instrumente de lucru mai bune
pentru personalul din sănătate;
management eficient al resurselor şi
eficienţa economică în serviciile de
sănătate şi crearea condiţiilor pentru
utilizarea soluţiilor TIC în sănătate
PROIECT SIUI Interfaţare 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 către acest sistem. Modalitatea
principală de schimb de date va fi de tipul
sistem la sistem, folosind tehnologii de tip
servicii web.
ALT
DOCUMEN
T
RELEVANT
LA NIVEL
NAŢIONAL
/REGIONA
L
Planul Naţional de Dezvoltare
(PND) 2007 – 2013
- direct, proiectul sprijinind atingerea
obiectivelor PND respectiv creşterea
competitivităţii economice, îmbunătăţirea
capacităţii administraţiei publice de
formulare şi implementare a politicilor
publice, creşterea calităţii serviciilor
publice (inclusiv prin reducerea birocraţiei
şi realizarea unei administraţii eficiente,
moderne şi orientate către cetăţean).
ALT
DOCUMEN
T
RELEVANT
LA NIVEL
Planul Naţional de Reforme - direct, proiectul contribuind la
promovarea TIC în administraţie prin
sisteme e-sănătate. De asemenea, proiectul,
prin implementarea sa, dinamizează
procesul de simplificare administrativă,
NAŢIONAL
/REGIONA
L
unul din obiectivele majore ale reformei
administraţiei publice, venind astfel în
sprijinul cetăţeanului şi al administraţiei
însăşi.
2.4. Beneficiarii proiectului (grupuri ţintă)
Principalele entităţi care vor beneficia de implementarea proiectului sunt:
Casa Naţională de Asigurări de Sănătate - are rolul de achizitor şi administrator al sistemului
şi va asigura coordonarea implementării proiectului şi integrării acestuia cu sistemul SIUI
care va avea implementate şi funcţionalităţile de card electronic de sănătate şi de prescripţie
electronică.
Casele Judeţene de Asigurări de Sănătate - au rolul de reprezentanţi ai CNAS în teritoriu şi
vor asigura coordonarea implementării proiectului, în aria de acoperire gestionată.
Populaţie – toţi cetăţenii României, persoane asigurate, care beneficiază conform legislaţiei
actuale de servicii de asistenţă medicală gratuite.
Mediul prestatorilor de servicii de sănătate publică din România – toate unităţile de asistenţă
medicală şi prestatori de servicii de sănătate publică existente şi care contribuie la asigurarea
asistenţei medicale
3. Date generale despre proiect
3.1. Obiectivul general al proiectului
Prin acest proiect se doreşte trecerea la forma electronică a dosarului de sănătate al
pacientului prin intermediul căreia cetăţenii României vor beneficia de un nivel mai ridicat al
calităţilor serviciilor medicale. Obiectivul general poate fi sintetizat astfel:
Creşterea calităţii sistemului de sănătate din România prin implementarea Dosarul
Electronic de Sănătate al pacientului (DES);
Prezentarea într-o manieră consistentă şi consolidată a tabloului clinic al pacienţilor
asiguraţi, lucru ce vine în sprijinul direct al corectitudinii deciziei medicale bazate pe
informaţii corelate din surse diferite. Aceasta creşte nivelul de satisfacţie al
beneficiarilor serviciilor medicale care este un indicator important pentru proiect.
Oferirea suportului decizional pentru adoptarea politicilor de sănătate în România.
Implementarea proiectului DES va avea următoarele consecinţe:
creşterea interoperabilităţii între furnizorii de servicii de sănătate prin implementarea
unor interfeţe şi protocoale de comunicaţii standardizate în componenţa centrală a
sistemului DES
creşterea eficienţei serviciilor medicale oferite asiguraţilor prin accesul rapid la
istoricul informaţiilor medicale
3.2. Obiectivul specific al proiectului
CNAS doreşte să achizitioneze, sa implementeze si sa integreze in sistemul SIUI o soluţie
care să ofere toate funcţionalităţile necesare introducerii Dosarului Electronic de Sănătate al
pacientului. Soluţia va răspunde integral la toate cerinţele CNAS tehnice şi funcţionale,
exprimate în prezentul caiet de sarcini.
Obiectivul specific al sistemului a fost definit pe baza direcţiilor strategice de mai sus şi pe
baza cerinţelor funcţionale, operaţionale şi tehnologice. Obiectivul specific al proiectului
este:
Implementarea sistemului naţional Dosarul Electronic de Sănătate al pacientului (DES) ca
funcţionalitate intrinsecă a SIUI şi livrarea lui la cheie. Implementarea sistemului naţional
DES reprezintă un pas important în sprijinirea îmbunătăţirii deciziei medicale şi adoptarea de
politici de sănătate bazate pe informaţii coerente.
DES se va constitui într-o colecţie de înregistrări electronice cumulate din diverse surse şi
locaţii, datele vizate pentru stocare urmând a fi de tipul: istoric medical, alergii, imunizări,
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 sănătate va documenta orice diagnostic sau măsură terapeutică într-o
manieră standardizată. Prin reducerea sau evitarea redundanţei la înregistrarea datelor
medicale, DES va facilita prezentarea conceptelor medicale într-un mod optimizat, lipsit de
ambiguităţi, cu păstrarea contextului original. Dosarul electronic de sănătate va reflecta
cronologia evenimentelor medicale şi va suporta vederi diferite ale datelor în funcţie de
utilizator (medic sau asigurat).
Dosarul Electronic de Sănătate 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 informaţiilor printr-un sistem
permanent online;
o asigurarea accesului privat şi securizat la datele puse la dispoziţie în DES prin intermediul
infrastructurii cardului de sănătate;
o o soluţie scalabilă şi extensibilă ce va permite creşterea continuă, extensivă a
informaţiilor clinice stocate
o interoperabilitatea cu alte sisteme folosind standarde deschise;
o utilizarea standardelor deschise în domeniul sănătăţii, precum HL7.
Implementarea sistemului informatic propus va contribui la creşterea eficienţei serviciilor
publice oferite cetăţenilor, ceea ce se afla în concordanţă cu obiectivul Axei Prioritare 3
privind creşterea interacţiunii între sectorul public şi cetăţeni prin valorificarea potenţialului
TIC. Eficientizarea se manifestă prin:
o obţinerea unui mediu standardizat pentru evidenţa datelor, bazat pe sisteme performante
de gestiune a bazelor de date;
o grad mare de integrare a datelor medicale între diverse segmente ale sistemelor
informaţionale din asistenţa medicală;
o reducerea semnificativă a spaţiului necesar stocării datelor medicale;
o creşterea calităţii actului medical prin suportul informativ oferit structurilor
administrative locale şi centrale;
o reducerea semnificativă a timpului de acces la informaţii medicale, necesare în situaţii de
urgenţă.
Accesul sigur la conţinutul DES este asigurat prin politicile de securitate dezvoltate în scopul
de a îmbunătăţi 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 informaţiilor cu caracter personal
(transpunere a Directivei Europene 95/46/C), Legii 455/2001 (cu modificările ulterioare)
privind folosirea semnăturii electronice, Legii Pacientului, Legea nr. 506 din 17 noiembrie
2004 privind prelucrarea datelor cu caracter personal şi protecţia vieţii private în sectorul
comunicaţiilor electronice, etc. În acest sens, separarea conţinutului în funcţie de dreptul de
proprietate, accesul controlat pe baza de drepturi al medicilor la fişele pacienţilor, includerea
acordului pacientului, auditarea permanentă a acţiunilor sunt doar o parte din măsurile ce
trebuie implementate pentru asigurarea unui sistem sigur şi eficient.
Adresabilitatea DES la nivelul prestatorilor de servicii din România, şi nu numai, impune
implementarea unui nivel de comunicaţii standardizat, care să permită actualizarea sau
vizualizarea datelor medicale referitoare la pacienţi într-un mediu securizat. Consistenţa şi
integritatea conţinutului vor fi asigurate prin validarea tuturor mesajelor transmise în
interiorul sistemului, dar şi cele venite de la aplicaţiile existente în conformitate cu
standardele internaţionale. Astfel, DES susţine mediul concurenţial din domeniul IT specific
serviciilor medicale, având ca beneficiu central îmbunătăţirea serviciilor în domeniu.
3.3. Rezultate preconizate
Activitate Rezultate
1 Implementare DES Sistem DES implementat şi funcţional
1.2 Analiză Cerinţele sistemului sunt definite
1.3 Proiectare Sistemul DES proiectat
1.4 Implementare Sistemul DES implementat
1.5 Instruirea personalului
84 persoane instruite în utilizarea şi
administrarea sistemului DES
1.6 Testare
Sistemul DES este testat cu succes
conform planului de testare
3.4. Indicatori
Menţiuni:
Prin ponderea instituţiilor sanitare = 100% înţelegem implementarea proiectului la
solicitantul CNAS
Prin numărul de servicii electronice disponibile înţelegem implementarea serviciului
DES (Dosarul Electronic de Sănătate)
Prin numărul estimat de utilizatori ai proiectului, angajaţi în domeniul sanitar
înţelegem numărul celor care vor utiliza facilităţile sistemului după implementarea
soluţiei tehnice.
INDICATORI Valoare la începutul
perioadei de
implementare
Valoare la sfârşitul
perioadei
de implementare
Realizare
Ponderea instituţiilor sanitare în
care s-a implementat proiectul
din totalul acestora
0 100%
Nr. de servicii electronice
disponibile
0 1
Rezultat
Nr. de persoane instruite pentru
folosirea aplicaţiei informatice
0 84
Numărul estimat de utilizatori ai
proiectului, angajaţi în domeniul
sanitar
0 2500
Numărul estimat de instituţii
sanitare conectate la sistemul
DES
0 50
Număr estimat de dosare
medicale introduse în sistemul
DES
0 5000
3.5. Impactul economic şi social al proiectului
Impactul economic şi social al proiectului propus se va face simţit în următoarele aspecte:
1. Creşterea calităţii sistemului de sănătate din România prin implementarea Dosarul
Electronic de Sănătate al pacientului (DES)
2. Odată cu implementarea tuturor fazelor sistemului, va creşte gradul de informare al
instituţiilor interesate în definirea politicilor de sănătate şi în ceea ce priveşte situaţia
în timp real a stării de sănătate a populaţiei României. Având o vedere de ansamblu
asupra stării de sănătate a populaţiei, se vor putea combate, prin intermediul politicilor
de sănătate, epidemii/pandemii sau alte maladii care influenţează un număr mare de
cetăţeni;
3. Eliminarea erorilor de diagnosticare şi a dublei consultaţii ceea ce va conduce la
reducerea costurilor din sistemul sanitar naţional;
4. Facilitarea schimbului de informaţii în sistemul medical va duce la optimizarea
actului medical în sine şi a costului asociat;
5. Creşterea interoperabilităţii între furnizorii de servicii de sănătate, în calitate de punct
central şi intermediator a schimbului de informaţii medicale.
Numărul de potenţiali beneficiari ai sistemului este dat de numărul total de persoane
beneficiare ale pachetelor de servicii înscrise pe listele medicilor de familie din sistemul de
sănătate din România, care erau la 30.06.2010 în număr de aproximativ 20.455.000. După
implementarea Dosarului Electronic de Sănătate nou născuţii vor putea beneficia de dosarul
electronic de sănătate ce va monitoriza starea de sănătate pe parcursul întregii vieţi.
Pe lângă beneficiarii persoane fizice, de acest sistem vor beneficia cadrele medicale care vor
avea o bază de date completă asupra istoricului medical al pacienţilor consultaţi şi vor putea
să evite erorile de diagnostic sau repetarea unor analize. De asemenea aceştia vor avea
posibilitatea de a lua decizii medicale în cunoştinţă de cauză, având o vedere de ansamblu a
tabloului clinic al bolnavului derulat pe mai mulţi ani.
3.6. Beneficiile proiectului
În implementarea proiectului DES se vor asigura cel puţin următoarele beneficii:
• Va asigura accesul îmbunătăţit la servicii, într-un mod securizat:
o Furnizarea de acces în timp util a datelor medicale relevante indiferent de locul
unde acestea au fost achiziţionate şi / sau transcrise în mod securizat, pe diverse
niveluri de acces
o Posibilitatea consultului interdisciplinar la nivelul instituţiilor
o Localizarea în sistemele locale unde se găsesc datele medicale complete (date
clinice, investigaţii complexe, etc)
o Asigurarea accesului la istoricului medical al pacientului pe diverse niveluri de
acces
o Îmbunătăţirea continuităţii asistenţei medicale prin cunoaşterea istoricului
pacientului
o Colaborarea şi consultarea datelor clinice în timp real
o Urmărirea activităţii medicale a pacientului, respectarea tratamentelor prescrise şi
progresul din punct de vedere al sănătăţii acestuia
o Limitează accesul la datele medicale în conformitate cu identitatea, funcţia (rolul),
timpul şi locul de muncă a prestatorilor de servicii de sănătate
o Acces facil la dosarul de sănătate al pacientului, un control mai bun asupra
informaţiilor şi o actualizare rapidă a informaţiilor despre pacient
• Îmbunătăţirea productivităţii şi asigurarea unui control mai exact al costurilor:
o Reducerea momentelor de aşteptare pentru pacienţi şi de transferare a acestuia
între unităţile de sănătate
o Reducerea numărului de reexaminări, ale unui pacient, care nu sunt necesare
• Îmbunătăţirea calităţii Serviciilor de Sănătate:
o Îmbunătăţirea calităţii informaţiilor de sănătate (acurateţe, completitudine,
consistenţă, reducerea erorilor de transcriere)
o Reducerea expunerilor la radiaţii a pacienţilor
o Reducerea erorilor medicale
o Într-o etapă ulterioară identificarea pacienţilor cu nevoi speciale de îngrijire
(imunizări, tratamente, teste)
Din punct de vedere al beneficiarilor noului sistem, acesta va aduce, prin urmare, beneficii
importante după cum urmează:
Pentru populaţie, sistemul simplifică modalitatea de accesare a serviciilor de asistenţă
medicală, deoarece atunci când o persoană va merge la un furnizor de asistenţă medicală,
acesta va avea acces securizat la Dosarul Electronic de Sănătate al pacientului, în funcţie de
nivelul curent de autorizare în care va putea realiza verificări online. Gama mai larga de date
medicale va creşte calitatea serviciilor de sănătate şi va reduce posibilitatea de greşeli
administrative şi profesionale. Unul din rezultatele aşteptate este şi o preocupare mai mare a
persoanelor asigurate pentru sănătatea lor proprie şi o mai bună cunoaştere cu privire la
procedurile lor de tratament medical propriu prin intermediul portalului pus la dispoziţia
asiguraţilor.
Pentru furnizorii de servicii medicale, sistemul aduce o modalitate de comunicare între
angajaţii instituţiilor prestatoare de asistenţă medicală (consult interdisciplinar), aceştia
beneficiind de istoricul informaţiilor medicale ale pacientului şi de propunere mult mai
eficientă a unor activităţi de asistenţă (la momentul integrării 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ă creştere şi asigură sursa de date
pentru rapoartele anuale realizate de către CNAS.
Îmbunătăţirea serviciilor medicale din perspectiva pacienţilor
Îmbunătăţirea serviciilor medicale din perspectiva pacienţilor va fi realizată prin următoarele
caracteristici principale ale sistemului DES:
• DES va fi o sursă sigură de informaţii 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 informaţional de interacţiune între prestatorii de servicii medicale,
prin generarea documentelor specifice trimiterilor sau externărilor. În acest mod, fişele
medicale electronice vor fi automat actualizate, evitându-se deplasările pacientului;
• DES accelerează fluxul informaţional în beneficiul pacienţilor, spre exemplu trimiterea
imediată a solicitărilor de tratament, evitându-se astfel întreruperi sau întârzieri în
procesul de tratare.
Îmbunătăţirea serviciilor medicale din perspectiva prestatorilor de servicii medicale (PSM)
Îmbunătăţirea serviciilor medicale din perspectiva prestatorilor de servicii medicale va fi
realizata prin următoarele caracteristici principale ale sistemului DES:
• DES va asigura interoperabilitatea informaţiilor dintre mai mulţi prestatori de servicii,
atât la nivel naţional cât şi la nivel internaţional;
• DES va permite online accesul medicilor la conţinutul episoadelor anterioare de îngrijire.
Îmbunătăţirea serviciilor medicale din perspectiva susţinătorilor sistemului de servicii
medicale din România (CNAS, MS)
• DES va avea suport pentru introducerea informaţiilor;
• DES va asigura accesibilitatea şi disponibilitatea informaţiilor pacienţilor;
• DES va duce la reducerea timpului petrecut cu activităţi administrative.
4. Modele de evoluţie a sistemului medical
4.1. Definiţii şi concepte
Terminologia asociată unui sistem de gestionare a datelor de sănătate ale pacienţilor are mai
multe variante în funcţie de locul în care aceste date sunt obţinute, la nivelul medicului de
familie, spitale, laboratoare, unităţi specializate, etc.
Pentru a realiza o înţelegere clară a conceptului de eSănătate în România, şi a tipului de
sistem informatic de gestionare a înregistrărilor de sănătate, a arhitecturii acestuia cât şi a
modalităţii de implementare, vom defini şi diferenţia aceste tipuri de sisteme.
Tipurile de sisteme pentru gestiunea informaţiilor medicale ale pacienţilor sunt:
o EMR – (Electronic Medical Record) fişa electronică medicală a pacientului existentă la
un medic; organizate la nivelul unui singur furnizor de servicii
o EPR – (Electronic Patient Record) fişa electronică a pacientului existentă la un spital sau
unitate specializată; organizate la nivelul unui spital/unitate specializată – conţine toate
datele existente la nivelul departamentelor spitalului/unităţii specializate (la un anumit
moment – nu la momentul externării)
o EHR – (Electronic Health Record) - Dosarul Electronic de Sănătate - conţine datele
medicale relevante colectate la nivel longitudinal corespunzătoare 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 informaţiilor
medicale, şi poate include informaţii stocate în sisteme de genul EMR/EPR cât şi alte
tipuri de informaţii specifice fiecărei unităţi sanitare
Sistem de tip EHR
Sistemul de tip EHR este un set de componente care asigură instrumente prin intermediul
cărora 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, regăsire şi manipulare a informaţiilor conţinute în dosarele
medicale.
EHR-urile conţin înregistrări clinice computerizate create în unităţile care livrează servicii de
îngrijire, cum ar fi spitalele şi cabinetele medicilor de familie. EHR-urile au capacitatea de a
partaja cu uşurinţă informaţii medicale între părţile interesate şi trebuie sa permită informaţiei
să urmeze pacientul la diverse unităţi de asistenţă medicală la care acesta doreşte să meargă.
Părţile interesate în acest context sunt consumatorii, furnizorii de servicii medicale,
angajatorii, contribuabilii dar şi guvernul şi alte instituţii ale statului.
Scopul principal al unui EHR este acela de a furniza înregistrări medicale documentate care
să asigure suportul pentru îngrijirea curentă şi viitoare a pacientului de către acelaşi medic
sau alţi medici. Această documentare asigură o modalitate de comunicare între medicii care
participă la procesul de îngrijire a unui pacient. Principalii beneficiarii sunt pacienţii şi
medicii.
Tipurile de sisteme EHR
• Sistem EHR local
Majoritatea activităţilor de îngrijire medicală sunt furnizate în cadrul comunităţii locale în
care locuiesc pacienţii. Aceste activităţi includ serviciile asigurate de Medicul de Familie
împreună cu o serie de alte servicii medicale asigurate de furnizori locali de asistenţă
medicală (medici specialişti , profesioniştii din domeniul sănătăţii , etc.) şi servicii de
asistenţă medicală complexă, cum ar fi serviciile de diagnostic, tratament acut şi internare
spital.
În majoritatea unităţilor de sănătate, medicii de familie şi furnizorii de servicii şi asistenţă
medicală păstrează şi menţin propriile înregistrări/fişe medicale ale pacienţilor, într-un format
manual, electronic sau o combinaţie între acestea. O caracteristică importantă a acestor
înregistrări medicale este că acestea conţin informaţii detaliate referitoare la pacient, colectate
pe parcursul vizitelor pacientului la furnizorul de servicii medicale.
De obicei acestea conţin şi materiale provenite din exterior, cum ar fi rezultatele de
diagnostic şi recomandări , dar accesul la informaţii î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 răspunde şi
cerinţelor altor discipline sau sectoare din domeniul sănătăţii. 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 informaţia medicală referitoare
la pacient în cadrul spitalului, clinicii sau alte unităţi medicale sau de sănătate. Un EHR Local
poate suporta un EHR partajat – SEHR.
• Sistem EHR partajat - SEHR
Scopul unui sistem EHR partajat (SEHR) este de a asigura integrarea informaţiilor de
sănătate intr-o “comunitate locală de îngrijire”, permiterea transmiterii şi primirii
informaţiilor extrase şi fluxuri integrate.
Comunitatea locală de îngrijire va fi constituită de regulă într-o regiune geografică restrânsă
de regulă la 10-20km distanţă de reşedinţa 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 mulţi oameni îşi vor satisface majoritatea nevoile lor de asistenţă
medicală în cadrul comunităţii locale de îngrijire, sistemele SEHR au utilitate dincolo de
comunităţile locale, la nivel regional (de exemplu, judeţ, regiune) sau chiar la nivel naţional .
Pentru sistemele EHR Partajabile SEHR, există două modele principale care pot fi propuse:
o Modelul SEHR Federalizat în care informaţia 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 informaţiilor extrase din sistemele EHR "în timp real" de la
două sau mai multe surse de EHR distribuite. Abordarea de tip federalizat este atrăgătoare
în teorie, dar are, în practică, mai multe dificultăţi de performanţă, în special pentru
sistemele mari, cu multe înregistrări şi multe surse federalizate EHR (noduri EHR), şi de
fiabilitate (dacă un EHR local nu este disponibil nu se pot agrega informaţiile, având î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 interogări eficiente distribuite,
latenţă scăzută, ş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 când
informaţia este creată şi actualizată, şi nu atunci când aceasta este solicitată. Contribuţiile
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 dificultăţi tehnice proprii, dar există unele avantaje importante care
includ: sistemul de control al accesului şi de securitate este mult mai simplu în comparaţie
cu sistemele federalizate, probabilitatea unui raport mult mai bun preţ/performanţă,
fiabilitate crescută şi posibilitatea de a se integra mai uşor cu alte sisteme medicale
existente sau de viitor. Modelul consolidat de SEHR poate conţine doar un subset al
tuturor informaţiilor medicale. Acest subset este definit în funcţie de informaţiile
medicale colectabile, transmisibile, şi relevante din punct de vedere al actului medical.
4.2. Organizarea sistemului Dosarul Electronic de Sănătate al
pacientului (DES)
Pentru implementarea unui proiect de o asemenea anvergura şi complexitate dar şi ţinând
cont de numărul mare de sisteme cu care va trebui sa se integreze, următoarea etapizare
trebuie considerata pentru implementarea DES:
Etapa I – procedura curenta de achizitie
o Stabilirea clara a tuturor informaţiilor ce se vor păstra în DES şi care alcătuiesc Date
Medicale Relevante (DMR). Pentru aceasta se va constitui o comisie (cu participanţi din
toate sectoarele domeniului de sănătate).
o Definirea standardelor de comunicare intre sistemele locale şi sistemul central DES
ţinând cont de securitate, performanta, fiabilitate, auditare, etc.
o Stabilirea funcţionalităţilor prezente în proiect şi modul de integrare cu alte sisteme sau
subsisteme adiacente proiectului DES, precum şi a sistemului de autentificare PKI (in
conjuncţie cu cardul de sănătate)
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 integrării cu alte sisteme din teritoriu
o Punerea în producţie a sistemului, prin integrarea cu spitalele majore din România ş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ă organizării administrative şi teritoriale a ţării noastre pe judeţe, a numărului şi tipului
unităţilor de asistenţă medicală, cât şi a nivelului de informatizare existent în acest moment în
domeniul sănătăţii, modelul de EHR care se pretează cel mai bine este de tip EHR Partajat
(Shared EHR - SEHR) consolidat. Acest sistem va conţine un subset a informaţiilor medicale,
numit: Date Medicale Relevante (DMR) şi va asigura accesul factorilor implicaţi din
domeniul sănătăţii prin:
intermediul unui Portal web integrat cu sistemul SIUI
specificaţii de integrare, pentru schimbul automat de informaţii între DES şi HIS-urile locale.
aplicaţie client pentru medicul de familie
Ca structură şi mod de organizare funcţională sistemul va conţine următoarele componente:
o Reţeaua de comunicaţii 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 soluţie de tip PKI. Sistemul DES va verifica identitatea asiguratului
prin intermediul SIUI (componenta eCard), astfel încât 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 sănătate ş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 aplicaţie 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 sănătate despre pacienţi între SEHR şi sistemele EMR/EPR/EHR existente la
prestatorii de servicii de sănătate
o Un sistem de suport al deciziilor pentru CNAS. Acest subsistem va colecta şi stoca
informaţii pe perioade mai lungi de timp necesare pentru elaborarea unor rapoarte şi
analize statistice complexe, care vor conduce la stabilirea politicilor medicale de sănătate
în sistemul medical românesc
o Infrastructura hardware, software si de comunicatii necesara
Realizarea DES ca un sistem separat de sistemele de tip HIS din cadrul unităţilor de sănătate
şi respectând contextul impus de către SIUI, este o aplicare a principiului „separării
responsabilităţilor” şi permite o arhitectură flexibilă şi fiabilă, bazată pe modularizare şi
cuplare „slabă” între componentele sistemului informatic integrat. Prin „cuplare slabă” între
componente înţelegem că EHR/EPR/EMR aflate în teritoriu sunt independente între ele din
punct de vedere arhitectură tehnică, funcţionalităţi, mod de implementare, utilizare şi
management, dar cu toate acestea comunică prin protocoale standard între ele cât şi cu
sistemul DES, astfel încât transferul de informaţie 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 Facultăţi de medicină
o Centre de imagistică
5. Descrierea tehnică a proiectului
O caracteristică principală a noilor sisteme informatice de sănătate o constituie
implementarea unui dosar electronic de sănătate al pacientului (DES) care colectează în
format digital datele medicale relevante legate de sănătatea unui pacient precum şi
modalităţile de tratament alese.
Un sistem informatic (SI) DES are ca scop:
o să furnizeze suportul necesar sistemului decizional de management în sănătate;
o sa asigure accesul online la datele relevante privind sănătatea unui pacient, aflat în
procesul de tratament;
o să contribuie proactiv la stabilirea politicilor teritoriale de sănătate.
La nivel global există variaţii importante legate de arhitectura unui sistem DES (gradul de
centralizare al sistemului, modelul informaţional al dosarului, modul de utilizare a datelor,
etc).
Pentru implementarea unui sistem de sănătate corespunzător specificului din România se vor
respecta următoarele linii directoare:
a. Sistemul DES face posibil un acces on-line sigur şi de încredere la informaţiile
referitoare la sănătatea pacienţilor, acolo şi atunci unde acestea sunt necesare
pentru tratament
b. DES va conţine, într-o bază de date centralizată, date medicale relevante ale
pacientului. Aceste informaţii sunt preluate din sistemele informatice
aparţinând instituţiilor medicale, pe măsura integrării acestora în sistem.
Modul de achiziţie a informaţiilor este de două feluri:
Informaţiile sunt trimise în timp real de la instituţiile medicale către
sistemul centralizat, în sistem push;
Informaţiile sunt colectate de către sistemul DES de la instituţiile
medicale, în sistem pull, la cerere.
c. Accesul personalului medical (şi, mai general, al oricărui utilizator potenţial)
la DES va fi pre-autorizat pe baza unui set de reguli stabilite, urmând ca
sistemul să permită apoi schimbarea nivelului de acces de către pacient,
utilizând proceduri specifice şi putând stabili, în principiu, situaţiile şi nivelul
până la care medicii autorizaţi vor avea acces la dosarul fiecărui pacient;
identificarea medicilor se va face prin intermediul sistemelor HIS prin care
aceştia se conectează, pentru audit se vor stoca credenţialele trimise de HIS
plus un identificator unic precum un cod de parafă
d. DES aplică măsuri pentru protecţia şi siguranţa datelor, indiferent de locul sau
timpul tratării
e. Autentificarea utilizatorilor se va realiza, în mod optim, prin folosirea cardului
electronic de sănătate implementat în componenţa eCard a SIUI. Cazurile de
utilizare a cardului şi informaţiile 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,
ţinând cont de drepturile acestora în contextul fişei pacientului;
g. DES verifică autenticitatea informaţiilor prin semnătură 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 interfeţe informatice standard conectarea la registrele
care se vor implementa în viitor.
5.1. Arhitectura funcţională a sistemului
Sistemul DES este un instrument pentru sprijinirea unei îngrijiri medicale integrate. Pentru a
se asigura continuitatea în lanţul îngrijirii medicale, trebuie ca datele şi informaţiile privind
sănătatea pacientului sa fie puse la dispoziţie chiar la locul tratării. DES nu este un dosar sau
un document în sensul tradiţional, ci un sistem de documentare, informare şi comunicare
bazat pe o infrastructura IT sigură pe de o parte şi pe standarde tehnice şi de conţinut pe de
altă parte.
Sistemul DES va folosi categorii de date existente în SIUI (nomenclatoare, asiguraţi, registre
de servicii medicale şi farmaceutice, etc.). Accesul la aceste date se va face programatic.
Actori:
o Asigurat. Cetăţenii înregistraţi î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 informaţii 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 Sănătate). Sistem informatic de tip Portal prin
care un asigurat îşi consulta informaţiile medicale proprii sau pentru care este
delegat.
o DES medic de familie. Sistem informatic prin care un medic de familie accesează
informaţiile medicale ale unui asigurat.
o Tablou de bord. Sistem informatic prin care un analist procesează date
nepersonale în vederea stabilirii politicilor de sănătate.
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 sănătate.
Servicii de date:
o Servicii vocabulare
o Servicii entităţi
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 aplicaţii
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 funcţionale
1.1.1.1. Subsistemul de acces utilizatori
Subsistemul de acces al utilizatorilor la funcţionalităţile DES include un Portal, precum şi
mecanismele de control al accesului prin acest portal.
Portalul
o Portalul DES asigurat - este o aplicaţie web based prin care un asigurat poate vizualiza
informaţiile:
• Informaţii medicale proprii (DMR-uri)
• Informaţii medicale pentru care este delegat (persoane aflate în grija sa)
• Informaţii de audit asupra datelor sale medicale (cine a accesat, ce a accesat şi când)
o Portalul permite accesarea unor domenii informaţionale de detaliu aflate în DES (drill
down), plecând de la sumar.
o Portalul include vederi diferite, în funcţie de tipul utilizatorului, în particular vederi
distincte şi optimizate pentru medici şi asiguraţi.
o Portalul oferă facilităţi separate pentru alte categorii speciale de utilizatori (Analişti,
Auditori, etc)
o Portalul oferă facilităţi de administrare a utilizării datelor medicale de către utilizatorii
autorizaţi.
1.1.1.2. Interfaţa utilizator (web portal)
o Interfaţa utilizator trebuie sa fie „web based”. Interfaţa este accesibila direct dintr-un
browser WEB; interfaţa trebuie sa adreseze minim Internet Explorer şi Mozilla Firefox.
o Interfaţa trebuie sa ofere suport pentru limba romana. In mod specific toata informaţia-
text trebuie sa fie codata UNICODE (preferabil UTF-8).
o Interfaţa cu utilizatorul trebuie sa permită traducerea ei în alte limbi fără ca pentru acest
lucru sa fie necesara modificarea aplicaţiei.
o Accesul la modulele aplicaţiei trebuie sa prevadă accesul bazat pe roluri a utilizatorilor
aplicaţiei.
o Sistemul trebuie sa conţină un modul help on-line care sa afişeze informaţie în funcţie de
contextul curent în care se afla utilizatorul.
o In cazul în care pentru realizarea unei funcţii este necesara parcurgerea a mai multor
pagini utilizatorul trebuie sa poată accesa direct o funcţie de reîntoarcere la pasul anterior.
Sistemul nu trebuie sa necesite re-introducerea unei informaţii care a fost deja introdusa
la un pas anterior, exceptând informaţiile de securizare a tranzacţiei si/sau procesului
•
1.1.1.3. Servicii Aplicative
Serviciile DES de tip aplicaţie sunt serviciile principale pe care trebuie să le ofere sistemul
din punct de vedere funcţional.
Serviciile aplicative trebuie să fie de tip „cuplaj slab”, pentru a permite extinderea
funcţionalităţilor într-o manieră scalabilă, folosind tehnologii de tip servicii web. Această
cerinţă este cu atât mai importantă cu cât se preconizează o dezvoltare iterativă, cu adăugarea
de noi funcţionalităţi în faze ulterioare de dezvoltare a sistemului DES.
1.1.1.4. Serviciile DMR
Serviciile de tip DMR asigură gestiunea informaţiei de sănătate esenţiale, asociate unui
asigurat.
a) Cerinţe funcţionale
ID Cerinţă Descriere
1 Conţinut minim Informaţia gestionată va include, ca un minimum,
următoarele categorii:
o starea de sănătate a pacientului (ex. probleme
cunoscute, diagnostice, medicamentaţie, alergii,
etc) evenimente (de sănătate sau semnificative)
(trimiteri, internări / externări, consultaţii, etc)
o aspecte / documente conexe (familie, aspecte
sociale, etc)
Detalii conţinut minim DMR va permite accesul utilizatorului, pe baza
drepturilor asociate la următoarele funcţionalităţi
minimale:
Căutare asigurat
Stocarea şi vizualizarea datelor medicale
sumare
Stocarea, vizualizarea şi completarea listei
de probleme medicale
Stocarea, editarea (inclusiv modificarea,
ştergerea şi golirea), vizualizarea listei
ID Cerinţă Descriere
de alergii
Stocarea, vizualizarea şi completarea listei
de consultaţii medicale
Monitorizarea stării de sănătate a
asiguratului pe bază de indicatori
predefiniţi, 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
medicamentaţiei prescrise asiguratului
Verificarea medicamentaţiei 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 necesităţile de schimb de date cu toate
entităţile cu care comunică în sistem, precizate de
componenta de Schimb de Informaţii
5 Extensibilitate DMR va fi uşor extensibil pentru a permite
adăugarea de noi categorii / tipuri de informaţii
medicale, fără a implica modificări substanţiale în
aplicaţie
6 Asociere medic DMR va permite definirea şi gestionarea unei
relaţii, pe toată durata ei de viaţă, între un asigurat
şi personalul medical asociat acestuia
ID Cerinţă Descriere
7 Relaţii cu alte date DMR va permite identificarea de relaţii cu alte date
relevante aparţinând de exemplu rudelor unui
pacient existente în sistem
8 Alerte DMR va permite generarea şi rutarea de alerte către
utilizatorii interesaţi, ca urmare a producerii unor
evenimente
b) Cerinţe tehnice
ID Cerinţă Descriere
1 Tratare erori DMR va trebui să gestioneze situaţiile de eroare
(ex. primirea unei cereri cu identificator asigurat
eronat)
2 Corectare erori DMR nu va permite corectarea unor informaţii de
către o sursă diferită de cea care a furnizat
informaţia originală
3 Modificare informaţii Modificările de informaţie 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 informaţiilor ce se vor păstra în DES şi care alcătuiesc
setul de Date Medicale Relevante (DMR).
Pentru aceasta se va constitui o comisie de specialitate, cu participanţi din toate sectoarele
domeniului de sănătate.
Ofertantul va asista beneficiarul în definitivarea setului DMR, pe baza setului propus de
către beneficiar. Se vor identifica şi analiza posibile constrângeri sau optimizări de natură
tehnică sau legate de implementarea proiectului.
1.1.1.5. Serviciile BI
Serviciul de BI (Business Intelligence) permite analiza şi afişarea într-o formă relevantă a
unor situaţii 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) Cerinţe funcţionale
ID Cerinţă Descriere
1 Analiză informaţii complexe Serviciul de BI trebuie să permită comunicarea
unei informaţii medicale complexe, prin
intermediul unor tablouri de bord uşor de
construit, precum şi construirea unor fişe de
punctaj (scorecards) pentru alinierea echipelor
medicale şi a tacticii adoptate cu nivelul strategic
2 Analiză tendinţe Serviciul de BI va furniza instrumente pentru
analiza tendinţelor şi măsurarea rezultatelor
3 Rapoarte ad-hoc Serviciul de BI va permite realizarea de rapoarte
ad-hoc referitoare la datele stocate în DES
4 Drill-down Serviciul de BI va oferi facilităţi de tip drill-down,
respectiv navigarea facilă între diferite niveluri de
detaliu, în funcţie de necesităţile specifice
5 Format grafic Serviciul de BI va permite obţinerea de situaţii
statistice, în diferite formate grafice/numerice,
agregate la diferite niveluri organizaţionale sau
geografice
6 Format ieşire Serviciul de BI va permite obţinerea rapoartelor
într-o gamă variată de formate de ieşire, pentru a
putea fi exploatate de către sistemele conexe DES
sau exportate către alte sisteme naţionale şi
internaţionale (UE)
a) Cerinţe tehnice
ID Cerinţă Descriere
1 Depersonalizare
(anonimizare)
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 către instrumentele de
analiză şi raportare BI
ID Cerinţă Descriere
2 Calitatea datelor Serviciul de BI va accesa o componentă de tip
ETL (internă / externă) care să permită asigurarea
unei calităţi corespunzătoare a datelor, înainte de
exploatarea lor de către 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 conţinutul 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
funcţionalităţile sistematizate în această secţiune, independent de subsistemul în care se află
localizate efectiv datele (decuplare logică).
Serviciile de date principale sunt următoarele:
serviciul de vocabulare;
serviciul de entităţi;
serviciul de documente;
serviciul de depozit de date (data warehouse).
1.1.1.6.1.1. Serviciul de Vocabulare
a) Cerinţe funcţionale
ID Cerinţă Descriere
1 Interfaţă pentru
nomenclatoarele SIUI de
termeni
Serviciul trebuie să joace rolul de interfaţă SOA
pentru nomenclatoarele SIUI care furnizează
concepte specifice domeniului (ex: nomenclatoare
pentru medicamente).
ID Cerinţă Descriere
2 Acces la vocabulare
standardizate
Clientul serviciului trebuie să poată indica un
concept specific printr-un identificator de concept
şi să acceseze informaţiile asociate acestuia.
3 Regăsire de termeni specifici Clientul serviciului trebuie să poată căuta termeni
specifici în cadrul sistemelor de codificare
disponibile pe baza unor criterii.
4 Suport pentru diferite
domenii clinice
Clientul serviciului poate adăuga sau şterge
sisteme de codificare existente sau poate edita
informaţia despre un anumit sistem de codificare.
5 Regăsirea sistemului de
codificare adecvat unei
probleme
Un sistem de codificare trebuie să includă
termenii specifici unui anumit domeniu(concepte).
Informaţiile despre sistemul de codificare ajuta
clientul serviciului să identifice sistemul dorit,
prin punerea la dispoziţie a descrierii, versiunii, a
limbilor suportate de sistemul de codificare, a
datelor de identificare a sistemul samd.
6 Flexibilitate în descrierea
conceptuală a domeniului
Clientul serviciului trebuie să poată stabili relaţii
între concepte, precum relaţii 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 proprietăţi. (De ex:
conceptul Algozone are proprietatea Firma
producătoare cu valoarea Ozone)
7 Suport pentru terminologie
specifică
Clientul serviciului poate adăuga, actualiza sau
şterge termeni în cadrul fiecărui vocabular.
Clientul serviciului poate obţine detalii precum
numele sau proprietăţile conceptului pe baza unui
cod de concept
8 Validarea conceptelor într-un
anumit context
Clientul serviciului poate verifica dacă un
concept, pe baza codului acestuia, aparţine sau nu
unui sistem de codificare sau unui set de valori.
ID Cerinţă Descriere
9 Gruparea seturilor de termeni
adecvaţi unui context
Seturile de valori reprezintă grupări logice de
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 reuneşte doar bolile dermatologice.
10 Reutilizarea seturilor de
termeni
Serviciul trebuie să permită compunerea de
sisteme de valori prin agregarea altor sisteme
11 Regăsirea setului de valori
adecvat unei probleme
Serviciul trebuie să ofere acces la informaţii de
identificare şi descriere a unui set de valori
12 Asigură interoperabilitate
între diferitelor sisteme de
codificare.
În cadrul unui flux de lucru, conceptele medicale
pot fi reprezentate prin diferite scheme de codare.
Pentru a asigura interoperabilitatea şi pentru a
menţine înţelesul termenilor, utilizatorii trebuie să
definească mapări între concepte echivalente în
diferite scheme de codare.
13 Regăsirea conceptului
adecvat unei probleme
Un utilizator trebuie să poată regăsi conceptul
adecvat care trebuie utilizat într-o anumită
operaţiune de codificare (Ex: codificarea unui
diagnostic).
b) Cerinţe tehnice
ID Cerinţă Descriere
1 Mesaje Serviciul trebuie să poată comunica cu actori
externi folosind mesaje standardizate în domeniul
său 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 Entităţi
a) Cerinţe funcţionale
ID Cerinţă Descriere
1 Interfaţa pentru entităţile
existente în SIUI
Serviciul trebuie să joace rolul de interfaţă SOA
pentru entităţile SIUI (ex: asiguraţi, medicii care au
contract cu CNAS cu specializările medicale pentru
fiecare medic în parte, furnizori etc).
2 Personalizarea tipurilor de
resurse suportate de
serviciu
Entităţile stocate de serviciu trebuie să poată fi
grupate după anumite tipuri – de exemplu: Persoană,
Locaţie, etc
De asemenea entităţile 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 naşterii, CNP, etc
3 Asigurarea funcţionalităţii
adecvate pentru diferite
sisteme consumatoare ale
serviciului
Domeniile au rolul de a permite partajarea datelor
între diverse medii – ex: operaţional, testare,
certificare etc
4 Modificarea datelor despre
entităţi
Clientul serviciului trebuie să poată crea noi entităţi
de un anumit tip definit, să poată edita informaţiile
asociate entităţii ş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 Regăsirea datelor despre
entităţi
Clientul serviciului trebuie să poată căuta entităţi pe
baza unor criterii de filtrare
Clientul serviciului trebuie poată regăsi informaţii
despre o anumită entitate identificată printr-un cod
unic de entitate, într-un anumit domeniu
b) Cerinţe tehnice
ID Cerinţă Descriere
1 Structuri de date Serviciul trebuie să utilizeze structuri de date
adecvate pentru descrierea entităţilor - ex HL7 RIM
ID Cerinţă Descriere
(entitate, rol) sau echivalent.
2 Mesaje Serviciul trebuie să utilizeze în comunicaţie mesaje
adecvate – ex HL7 EIS, IHE PIX/PDQ sau
echivalent
1.1.1.6.1.3. Serviciul de Documente
a) Cerinţe funcţionale
ID Cerinţă Descriere
1 Optimizarea accesului la
documentele stocate –
registry şi repository
Registrul are rolul de a păstra metadate despre
documentele existente – reunind informaţii precum
titlu, autor, data creării documentului, precum şi
informaţia necesară pentru regăsirea documentului
într-unul din repository-uri etc. Repository-ul
conţine documentele propriu-zise, fiind un mediu de
stocare de date, în contract cu registrul care este un
mediu de stocare de metadate.
2 Întreţinerea metadatelor cu
informaţii corecte şi actuale
Metadatele asociate documentului trebuie să reflecte
conţinutul documentului pentru a facilita regăsirea
unui document.
3 Versionare Pentru un anumit document trebuie să se poată păstra
versiuni anterioare ale sale iar documentele nu vor fi
şterse fizic.
4 Acces la documente pe
baza metadatelor despre
acestea
Metadatele asociate unui document indică diverse
informaţii despre acesta, iar serviciul trebuie să
permită căutarea de documente pe baza unor criterii
bine definite.
5 Extensibilitate şi
flexibilitate în stocarea
documentelor
Documentele pot fi separate pe diverse criterii în
repository-uri diferite - cum ar fi atunci când este
necesară utilizarea de medii de stocare diferite sau
pentru tipuri diferite de documente.
6 Asigurarea unui punct de
acces unic pentru regăsirea
Registrul conţine informaţii despre localizarea
documentului într-un repository sau altul
ID Cerinţă Descriere
documentelor existente
7 Asigurarea flexibilităţii în
accesarea documentelor
Unele documente trebuie să poată să fie accesibile şi
dacă sunt stocate în repository-uri externe, plecând
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.
8 Repository de documente
clinice
Serviciul trebuie să includă unul sau mai multe
repository-uri de documente clinice. Documentele
clinice sunt documente specifice, bazate pe un model
de date particular şi constrâns 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, participaţie, entităţi, roluri,
secţiuni samd) şi transformarea lor în model
relaţional.
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,
medicaţii, imunizări, 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 integrităţii
sintactice va genera excepţii.
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 direcţii: vocabulare,
ID Cerinţă Descriere
entităţi, reguli de business (ex: diagnostice asociate).
Nerespectarea principiului integrităţii semantice va
genera excepţii sau avertismente.
b) Cerinţe tehnice
ID Cerinţă Descriere
1 Persistenţă Serviciul trebuie să suporte persistenţa documentelor
clinice codificate de diverse tipuri (ex: HL7 CDA
sau echivalent), verificate şi adoptate ca bună
practică de către industria de profil.
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) Cerinţe funcţionale
ID Cerinţă Descriere
1 Realizarea de analize şi
rapoarte pe date
depersonalizate
Data warehouse-ul trebuie să poată stoca date fie
printr-o abordare analitică bazată pe crearea de
dimensiuni şi fapte sau pe baze de date relaţionale
construite special în acest scop folosind un proces
unidirecţional 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
datelor clinice
Data warehouse-ul va include date clinice provenite
din documente de tip HL7 CDA sau echivalent, care
pot fi exprimate şi în formă relaţională (sau
ID Cerinţă Descriere
analitică) pentru realizarea de rapoarte pe baza lor.
4 Optimizată pentru viteza de
răspuns la interogări
complexe
Data warehouse-ul trebuie optimizat pentru a
permite interogări complexe care pot fi utilizate în
analiza şi/sau raportarea datelor şi a trendurilor din
aceste date, şi nu pentru introducerea de date ca în
cazul bazelor de date operaţionale.
5 Suport pentru cantităţi mari
de date
Data warehouse-ul va stoca cantităţi foarte mari de
date din documente colectate la nivel naţional.
b) Cerinţe 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 ţinând cont de următoarele caracteristici:
• Modelul de date va fi centrat pe pacientul asigurat şi va oferi o imagine comprehensivă a
informaţiilor medicale asociate unui pacient;
Modelul de date va suporta reprezentarea diferitelor domenii clinice pentru:
Administrare Pacienţi;
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, Relaţie Acte, asociaţii Act-Entitate, Clasa de
Confidenţialitate, Identificator Eveniment (OID – Object ID)
Modelul de date trebuie să poată stoca informaţii despre evenimentele asociate unui pacient
care au loc în sistemul de sănătate. Sistemul trebuie să poată întreţine date care sunt:
Specifice unei persoane: datele din DES sunt asociate în final unui pacient / unei persoane.
DES nu va conţine informaţii nesemnificative din punct de vedere al pacientului (ex. numărul
de angajaţi ai unui spital, date administrative ale unei secţii de spital, etc)
Relevante clinic: informaţiile critice care afectează calitatea, obiectivitatea şi promptitudinea
serviciilor medicale trebuie să fie accesibile de către furnizorii de servicii medicale asociaţi
unui pacient. Există în schimb o serie de alte informaţii, de exemplu analize intermediare sau
informaţii tranziţionale (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 informaţional DES sunt, în mod normal, asociate unui eveniment
medical. Informaţia este asociată unui eveniment medical trecut, care este în desfăşurare sau
care este planificată să aibă loc în viitor. Exemple de evenimente includ: examinare clinică,
imunizare, intervenţie chirurgicală, prescriere de reţetă, emiterea unui buletin de analize de
sânge, 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, când a avut loc şi detalii asociate.
Pentru ca evenimentele să fie înregistrate în mod unitar este obligatorie folosirea
nomenclatoarelor unice şi comune pentru pacienţi, furnizori şi locaţii (existente deja în SIUI),
precum şi folosirea unor reprezentări standard ale evenimentelor însele şi a detaliilor lor, pe
baza standardelor de identificare medicală în vigoare.
Este necesar, pentru compatibilitate cu cerinţele de mai sus, alinierea în cât mai mare măsură,
la standardul HL7 RIM, sau la un model informaţional compatibil cu acesta.
1.1.1.6.2.1. Conţinutul 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
Importanţa / Relevanţa
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 aplicaţii
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ă capacităţile de control necesare organizării
fluxului de lucru şi a interacţiunii între aplicaţii.
Fluxurile de lucru sunt reprezentate ca procese de business sau sub forma unor maşini de
stare.
1.1.1.7.2. Servicii de comunicare între aplicaţii
Serviciile de comunicare permit schimbul de informaţii între module aplicative interne SIUI
sau între module SIUI şi module externe (ex. HIS).
Deşi, logic, modalitatea fizică de comunicare este independentă de mecanismul tehnic folosit,
se doreste folosirea comunicării de tip mesagerie folosind mecanisme WS (web services).
În acest sens, componentele existente SIUI (componente comune şi modulul de decontări),
oferă un set de funcţionalităţi accesibile atât intern, cât şi extern (accesibile public oricăror
aplicaţii externe care au nevoie să exploateze aceste funcţionalităţi).
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 internaţionale;
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
operaţionale oferite pe magistrala de servicii.
1.1.1.8. Magistrala de Servicii (ESB)
ESB distribuie capacităţile de interconectivitate necesare utilizării serviciilor implementate în
întreaga arhitectură inclusiv serviciile de transport şi mediere. ESB este transparent pentru
serviciile care îl utilizează (aplicative, de date, etc), făcând totodată posibilă folosirea
serviciilor independente de locaţia acestora sau de protocolul folosit.
1.1.1.9. Servicii suport
Serviciile suport sunt servicii de natură tehnică, sunt amintite în această secţiune pentru
completitudine (ele sunt detaliate în secţiunile relevante din acest document:
Servicii de securitate
Servicii de administrare
Servicii de infrastructură.
1.1.1.10. Standarde
Este necesară alinierea la standardele internaţionale, conform celor mai bune practici actuale.
Precizăm principalele standarde utilizate în acest moment, cu cea mai mare bază de
implementare:
Conectivitate
Domeniul de infrastructură al organizaţiei IHE (Integrating Healthcare Enterprise) include o
serie de profile adoptate în proiecte majore (Canada, SUA, Franţa, Austria, UE-epSOS).
Standardele reprezentative:
XDS : schimbul de documente DES între instituţii medicale;
PIX / PDQ: identificare pacienţi şi interogare date demografice.
Conţinut (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 sănătate,
incluzând servicii de laborator şi farmaceutice, internări / externări / transferuri de la o clinică
la alta.
Modelul RIM include şi folosirea CDA (Clinical Document Architecture), un model pentru
schimbul de documente medicale (înregistrări medicale). Derivat din RIM, CDA converteşte
documentele care poate fi citit de un computer, ca şi de către operatori umani, prin folosirea
standardului XML.
Codificare (taxonomie)
Terminologia clinică pentru a asigura interoperabilitatea sistemelor informatice medicale este
susţinută de următoarele standarde active:
SNOMED-CT: boli, constatări 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 soluţie
care să ofere toate funcţionalităţile necesare introducerii Dosarului Electronic de Sănătate al
pacientului.
DES va reprezenta punctul de agregare a datelor medicale relevante cu privire la baza
medicală a pacienţilor asiguraţi, consolidând DMR-urile generate din sistemele informatice
medicale.
Acces-ul la DES se va face prin protocoale şi interfeţe construite conform standardelor din
domeniu şi va permite comunicarea cu principalele sisteme implementate / în curs de
implementare din sistemul medical.
Comunicaţii de tipul sistem la sistem:
• DES <--> HIS
• Schimb DMR pacienţi asiguraţi: Sistemele de tip HIS reprezintă sursa de DMR pentru
dosarul electronic de sănătate al pacienţilor asiguraţi
Sistemul DES va oferi un set de interfeţe 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.
Relaţia dintre DES şi SIUI
Asigurările sociale de sănătate reprezintă principalul sistem de finanţare a ocrotirii sănătăţii
populaţiei care asigură accesul la un pachet de servicii de bază pentru asiguraţi. Sistemul
Informatic Unic Integrat (SIUI) este soluţia software deţinută de CNAS şi este implementat la
nivel naţional. Principalii utilizatori ai sistemului sunt: CNAS, CJAS, MF, Spitale. Sistemul
Informatic Unic Integrat (SIUI) este o aplicaţie de tip distribuit din punct de vedere business /
centralizată din punct de vedere IT, destinată decontării serviciilor aplicate asiguraţilor.
Sistemul Informatic Unic Integrat este extrem de important pentru realizarea informatizării în
domeniul sănătăţii, pentru uniformizarea sistemului de raportare şi prelucrare a datelor din
sănătate, la nivel naţional şi judeţean. În acelaşi timp, SIUI este aliniat la strategia naţională
de informatizare şi se poate alinia uşor la reglementările organismelor internaţionale cu care
se efectuează schimburi permanente de date.
Sistemul Informatic Unic Integrat este destinat gestiunii online a tuturor informaţiilor
medicale ale pacienţilor asiguraţi, fiind utilizat la nivel central de către CNAS şi CJAS pentru
îndeplinirea funcţiilor specifice de administrare. La acest nivel, SIUI asigură următorul set de
funcţionalităţi:
• Evidenţa plătitorilor de contribuţii;
• Gestiunea fondului asigurărilor de sănătate;
• Gestiunea asiguraţilor;
• Gestiunea furnizorilor de servicii medico-farmaceutice;
• Asigurarea controlului serviciilor medicale (la nivelul CNAS), respectiv distribuţia
documentelor de referinţă către furnizorii de servicii medicale (la nivel CJAS).
Furnizorii de servicii medicale şi reprezentanţii angajatorilor interacţionează cu SIUI pentru a
transmite rapoarte şi a recepţiona 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 sănătate din componenţa eCard a SIUI se vor valida identitatea
utilizatorilor de tip asigurat; cardul de sănătate reprezintă punctul central de management al
identităţii în sectorul medical.
Unul din sectoarele în care DES va beneficia de datele gestionate în SIUI sunt programele
naționale. În SIUI se face o gestiune a programelor naționale precum şi participarea
pacienților la aceste programe. DES va prelua aceste informații primite din SIUI în măsura î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 asiguraţii pentru iniţializarea 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 regăsi 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.
Comunicaţii de tipul utilizator la sistem:
• DES <--> Asigurat
Vizualizare DES personal: Prin intermediul unei interfeţe 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 către asigurat a accesului la
DES-ul sau de către medici
Schimbă nivel autorizare acces DES asigurat: Se va restricţiona accesul la DES-ul
asigurat către un grup mai restrâns de medici
• DES <--> Medici
• Vizualizare DES pacienţi asiguraţi: Prin intermediul unei interfeţe web se va permite
căutarea 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
ofertanţii 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 secţiune se ilustrează scenariile tipice de utilizare a sistemului şi se indică modul în
care vor circula informaţiile principale în sistemul DES.
5.3.1. Accident şi INTERVENŢIE de urgenţă
Context:
Un asigurat diabetic îşi pierde cunoştinţa pe stradă şi este transportat la serviciul de urgenţă
de o ambulanţă;
Pas Acţiuni clinice / administrative Interacţiuni cu / între sistemele informatice
1
În ambulanţă pacientului i se
asigură tratamentul necesar
stabilizării (dacă este cazul)
2
La sosirea la spital, un medic
preia pacientul şi îi pune
diagnosticul de atac de
hipoglicemie
Ulterior internării se verifică în HIS-ul
spitalului dacă pacientul are un istoric medical
în cadrul instituţiei. În cazul în care nu există
istoric, se creează un dosar al pacientului,
existând posibilitatea de a prelua date relevante
din DES.
Se creează în dosarul (existent sau nou creat)
din HIS un episod medical al pacientului.
Medicul accesează DES (autentificare în
domeniul naţional DES) pentru a verifica
istoria medicală a pacientului, precum şi
eventuale episoade anterioare similare. În HIS
este introdus diagnosticul pus de către medicul
specialist, cu precizarea detaliilor legate de
internarea pacientului.
3Se administrează tratamentul
adecvat pacientului.
Medicul creează o nouă foaie de observaţie în
HIS-ul spitalului în care sunt precizate şi
detaliile legate de medicaţie şi procedurile
efectuate pacientului.
4
Starea pacientului este stabilizată,
este gata de externare şi i se emite
o reţetă
În sistemul HIS se adaugă înregistrări la
dosarul HIS al pacientului, în concordanţă cu
activităţile medicale (monitorizare, prescriere
medicamente, prescriere dietă, etc). Sistemul
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 operaţie
Context:
O pacientă aflată în supravegherea MF are simptome repetate de pierdere a cunoştinţei;
MF îi face o trimitere a pacientei pentru consultaţie de specialitate la un spital;
Pas Acţiuni clinice / administrative Interacţiuni cu / între sistemele informatice
1Pacientul se prezintă la recepţia
spitalului pentru consult
Recepţionista creează un dosar nou pentru
pacient în HIS daca nu îl găseşte deja în sistem.
În cazul în care pacientul nu are istoric medical
înregistrat în HIS-ul spitalului, este creat un
dosar pentru pacient, existând posibilitatea de a
prelua date relevante din DES.
2 Medicul consultant face anamneza
bolii
Medicul se conectează (dacă nu este deja) în
sistemul local (HIS) prin operaţiunea de login în
HIS-ul spitalului. Pe baza drepturilor definite în
DES medicul accesează informaţiile din DES
referitor la pacientul în cauză şi automat se
transmit către DES, date de identificare a
medicului, inclusiv parafa pentru sistemul de
audit.
Medicul identifică şi afişează dosarul pacientului
aflat în HIS. În plus, medicul vizualizează
informaţiile din DES, prin HIS este înregistrată
anamneza în HIS şi e stabilită internarea
pacientului cu crearea foii de internare.
3
Medicul efectuează un consult şi îl
trimite pe pacient să facă o
electrocardiogramă (ECG)
Medicul cere un ECG prin HIS
4 În spital se efectuează ECG
Rezultatele testării sunt adăugate la dosarul HIS
al pacientului
Medicul este notificat că este disponibil
rezultatul ECG
Medicul poate compara rezultatul ECG cu
rezultatele unor ECG precedente (efectuate în
spital, sau în ambulanţă)
5
Medicul analizează rezultatele
ECG şi diagnostichează un puls
neregulat
Diagnosticul este înregistrat în dosarul HIS al
pacientului
6
Medicul concluzionează că este
vorba de o complicaţie
coronariană şi face o trimitere
pacientului la un spital judeţean
Medicul face o trimitere din sistemul HIS, către
spitalul judeţean
HIS generează foaia de externare care
este transmisă şi în DES;
7 Următorul episod medical
8Pacientul este transferat la spitalul
judeţean
La internare, pacientului i se creează o foaie de
internare în HIS-ul spitalului judeţean
9
În urma consultului la spitalul
judeţean, medicul specialist decide
că este necesară implantarea unui
stimulator cardiac
Sunt preluate în HIS-ul spitalului judeţean prin
intermediul DES detaliile relevante înregistrate
în trimiterea şi foaia de externare a pacientului
Detaliile tratamentului şi procedurilor necesare
sunt înregistrate în HIS spitalul judeţean.
În HIS-ul spitalului judeţean sunt înregistrate
mai multe evenimente, legate de diagnostic, iar
datele medicale relevante şi recomandările
medicale sunt transmise în DES
5.3.3. Accesul asiguratului în portal
Context:
Un asigurat accesează portalul medical DES pentru a consulta informaţii medicale proprii.
Similar şi în cazul în care accesează dosare ale altor persoane pentru care este delegat
autorizat.
Pas Acţiuni clinice / administrative Interacţiuni cu / între sistemele informatice
1
Un asigurat doreşte să-şi consulte
dosarul propriu
Folosind un computer, asiguratul accesează
portalul medical prin internet. În continuare i se
cere să se autentifice. Asiguratul se autentifică în
portal prin mecanismul de autentificare.
2
Asiguratul verifică datele
medicale relevante din portal
În pagina de portal dedicată datelor medicale
relevante, asiguratul consultă informaţiile sale şi
are posibilitatea exportării lor în format PDF
pentru a putea fi printate.
3Asiguratul observă o nouă intrare
în dosarul său medical din DES
Asiguratul vizualizează noua intrare medicală. Îi
verifica sursa (datele de identificare şi parafa
medicului care a accesat informaţiile) şi
concluzionează că este de la ultima vizită
medicală de la spital
4Asiguratul verifică accesul
medicilor la dosarul propriu
În pagina de portal (tab-ul) dedicată auditului,
asiguratul citeşte 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 adăuga datele
medicale relevante de la ultima vizită la spital.
j. Citeşte motivaţiile medicilor
pentru a-i accesa dosarul şi
concluzionează că sunt corecte.
k. Citeşte motivaţiile 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 investigaţii laborator
Context:
Pacient aflat în supravegherea MF acuză dureri repetate în zona abdominală;
MF îi face o trimitere a pacientului pentru consultaţie de specialitate şi investigaţii la un
spital;
Pas Acţiuni clinice / administrative Interacţiuni cu / între sistemele informatice
1Pacientul se prezintă la recepţia
spitalului pentru consult
Recepţionista creează un dosar nou pentru
pacient în HIS
In cazul în care pacientul nu are istoric medical
înregistrat în HIS-ul spitalului, este creat un dosar
pentru pacient, existând posibilitatea de a prelua
date relevante din DES.
2 Medicul consultant face anamneza
Medicul se autentifică în sistemul local prin
operaţiunea de login în HIS.
Medicul identifică şi afişează dosarul pacientului
aflat în HIS.
În plus, medicul vizualizează în DES, prin HIS.
Este consemnată în HIS anamneza şi decizia de
internare.
3Medicul solicită efectuarea unui
set complex de investigaţii
Medicul solicită prin HIS setul de analize, cu
selectare pe clase de analize
4În laboratorul spitalului se
efectuează investigaţiile
În laboratorul spitalului este primită cererea de
investigaţii prin intermediul HIS spital
Sunt efectuate investigaţiile iar rezultatele sunt
adăugate la dosarul HIS al pacientului
În laborator sunt vizualizate şi validate rezultatele
analizelor
Prin intermediul HIS spital este închisă cererea de
investigaţii, cu ataşarea rezultatelor
Medicul este notificat că sunt disponibile
rezultatele analizelor
5 Medicul analizează rezultatele
Rezultatele analizelor sunt ataşate/ înregistrate în
HIS
Medicul vizualizează rezultatele transmise de
către laborator prin intermediul HIS, el putându-
le compara cu rezultatele unor analize similare
precedente (efectuate în spital, în afara spitalului
– prin DES, sau în ambulanţă)
5 Medicul diagnostichează pacientul Diagnosticul este înregistrat în dosarul HIS al
pacientului
Tratamentul prescris pacientului este înregistrat
în dosarul HIS
6Se administrează tratamentul
pacientului
Medicul creează o nouă foaie de observaţie în
HIS-ul spitalului, în care precizează evoluţia
pacientului în urma tratamentului efectuat şi
diagnosticul la externare
7
Starea pacientului este ameliorată,
este gata de externare şi se prescrie
o reţetă
În sistemul HIS se adaugă înregistrări la dosarul
HIS al pacientului, în concordanţă cu activităţile
medicale
Prin intermediul HIS, se creează o fişă de
externare; datele medicale relevante acestui
eveniment şi eventual reţeta (dacă este
considerată informaţie 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 Acţiuni clinice / administrative Interacţiuni cu / între sistemele informatice
1
Pacientul se prezintă la recepţia
centrului de dializă pentru
efectuarea tratamentului
Pacientul se prezintă la centru pentru tratament.
2 Furnizorul de servicii de dializă
efectuează tratamentul
Furnizorul se autentifică în domeniul local prin
operaţiunea de login în HIS.
Se identifică şi afişează dosarul pacientului aflat
în HIS.
În plus, se vizualizează în DES, prin HIS sau
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 evidenţa altui centru de dializă
3Pacientului i se efectuează
hemodializa
In HIS sunt înregistrate informaţiile cu privire la
tratarea pacientului cu precizarea detaliilor
specifice (pacientul se afla în primele 6-12
şedinţe de hemodializa)
După finalizarea şedinţei, este programata prin
intermediul HIS următoarea şedinţa
4Pacientul părăseşte centrul de
dializa
Tratamentul aplicat în şedinţa de hemodializa este
înregistrat în dosarul HIS
De asemenea este efectuata, înregistrata în HIS şi
prezentata pacientului programarea pentru
şedinţa 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 sănătate
Pas Acţiuni clinice / administrative
1 Un utilizator accesează portalul DES
2 Fiecare episod din dosarul de sănătate are asociat informaţii de audit şi anume: cine,
când, 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 către DES pentru auditare.
5.3.7. Exemplu de urmărire a unui episod de boala
Context:
Pacientul se prezintă se prezintă la medicul specialist pentru o problema de sănătate
Medicul specialist iniţiază un episod nou de boala
Pas
Acţiuni clinice / administrative
1 Medicul specialist iniţiază o noua intrare de tip DMR.
In cadrul consultaţiei iniţiale 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 investigaţiei sunt introduse de către
departamentul de radiologie şi ajung în dosarul electronic de sănătate al pacientului
pentru a putea fi consultate.
3 Pacientul se prezintă a doua oara la medicul specialist. Acesta accesează din sistem
rezultatele radiografiei şi stabileşte diagnosticul pacientului.
4 In urma stabilirii diagnosticului, medicul specialist stabileşte şi o schema de
tratament. Aceasta este introdusa în sistem şi se adaugă în dosarul electronic al
pacientului la secţiunea de medicaţie 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:
Aplicaţia HIS instalata la sediul unei unităţi spitaliceşti. Un pacient ajunge la Unitatea de
primire a urgentelor a spitalului acuzând o stare acuta de rău.
Pas Acţiuni clinice / administrative
1 Personalul de la biroul de recepţie a pacienţilor utilizează aplicaţia HIS pentru a
obţine pe baza codului unic de asigurat datele demografice ale pacientului (nume,
prenume, adresa, stare civila, etc).
2 Aplicaţia HIS solicita Dosarului Electronic de Sănătate aceste informaţii şi le
utilizează pentru a completa în mod automat câmpurile corespunzătoare din noua fisa
pentru pacient.
5.3.9. Interogare vocabulare
Context:
Aplicaţia HIS instalata la sediul unui spital necesită pentru codificarea informaţiei medicale
din documentele clinice un set de vocabulare adoptate la nivel naţional
Pas Acţiuni clinice / administrative
1 Aplicaţia HIS instalata la sediul unui spital necesită pentru codificarea informaţiei
medicale din documentele clinice un set de vocabulare adoptate la nivel naţional,
precum nomenclatorul de medicamente, specialităţi clinice, planuri naţionale de
compensare a medicamentelor samd.
2 Aplicaţia solicita aceste vocabulare Dosarului Electronic de Sănătate şi le stochează
local pentru utilizare în cadrul formularelor medicale electronice şi a comunicaţiei cu
sisteme externe
5.3.10.Interogare unităţi medicale
Context:
Un pacient este consultat de un medic specialist.
Pas Acţiuni clinice / administrative
1 Un pacient este consultat de un medic specialist. Folosind aplicaţia informatica din
cabinet, medicul scrie pacientului un bilet de trimitere către internare pentru o unitate
clinica specializata pe endocrinologie
2 Pentru a decide unitatea medicala către care se trimite pacientul, medicul foloseşte
aplicaţia informatica instalata în clinica de care aparţine pentru a căuta unităţile
medicale care dispun de aceasta specialitate
3 Pe baza datelor obţinute, medicul ii prezintă pacientului lista de opţiuni pe care acesta
o are în alegerea unităţii spitaliceşti 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 sănătate
Pas Acţiuni clinice / administrative
1 Medicul de familie îl consulta şi decide ca trebuie sa îl trimită pentru a-şi face analize
de laborator sau o investigaţie radiologica. Ii emite pacientului un bilet de trimitere
către un laborator de analize sau către o unitate medicale care are departament de
radiologie. Biletul de trimitere este înregistrat în sistem cu starea de “emis”. Atâta
timp cât 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 investigaţia radiologica şi în acelaşi 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 ataşează dosarului electronic al pacientului, pentru a putea fi consultate la
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 câteva categorii de informatii esentiale
Pas Acţiuni 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 câteva 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 putând
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
Activităţile de îngrijire medicala sunt cele executate de către prestatorii de servicii medicale;
acestea creează înregistrări medicale electronice în sistemul DES.
5.4.1. Gestiunea înregistrărilor medicale
Datele pot fi înregistrate folosind seturi de coduri standardizate sau nomenclatoare, depinzând
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 înregistrărilor este foarte importanta atât din punct de vedere legal cât şi
pentru organizarea coerenta a datelor de către 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). Informaţiile medicale sunt preluate şi ataşate înregistrărilor
pacientului.
1.1.1.12. Gestionarea informaţiilor demografice
Se înregistrează şi actualizează informaţiile demografice într-un mod în care sa fie relevant
din punct de vedere clinic iar datele să poată fi folosite pentru raportare. Informaţiile de
contact, incluzând adrese şi numere de telefon precum şi informaţii demografice precum data
naşterii, sex şi alte informaţii sunt stocate şi actualizate în înregistrările pacienţilor şi sunt
folosite pentru furnizarea serviciilor de îngrijire şi pentru raportare. Informaţiile demografice
trebuie înregistrate sub forma de câmpuri discrete (nume separat de prenume şi adresa, etc.)
Sistemul de audit va urmări cine actualizează informaţiile demografice şi ora exacta când
sunt actualizate.
1.1.1.13. Realizarea unui sumar al înregistrărilor medicale
Sistemul trebuie sa fie capabil sa ofere informaţia necesara într-un mod sumar sau sub forma
de raport determinat de politicile definite de exemplu pentru folosirea la terminarea unor
episoade de îngrijire fără a necesita înregistrarea altor informaţii de către personalul
prestatorului de servicii. Un exemplu de sumar poate fi un raport de o singură pagină tipizat.
5.4.2. Gestiunea istoricului pacientului
Datele conţin istoricul informaţiilor medicale relevante ca de exemplu: date istorice care au
legătură cu diagnosticele precedente, intervenţii chirurgicale şi alte proceduri efectuate
pacientului precum şi condiţii de sănătate relevante a membrilor de familie. Datele
înregistrate în sistem provin din interviuri pacient sau date istorice electronice sau ne-
electronice. În mod tipic când pacienţii vizitează pentru prima data un prestator de servicii
medicale, aduc cu ei informaţii medicale provenite din evenimente anterioare.
5.4.3. Preferinţe, indicaţii, consimţăminte şi autorizaţii
1.1.1.14. Gestiunea preferinţelor 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 încât
acestea sa fie disponibile prestatorului de servicii medicale la locul de îngrijire.
1.1.1.15. Gestiunea indicaţiilor pacientului
Datele privind indicaţiile furnizate de pacient precum şi circumstanţele în care acestea au fost
înregistrate pot fi importante pentru modul cum sunt administrate serviciile medicale. Datele
pot face referiri la înregistrări sau documente legale daca este cazul.
1.1.1.16. Gestiunea consimţămintelor şi autorizaţiilor
Sistemul trebuie să permită crearea, actualizarea şi verificarea deciziilor pacientului privind
tratamentul sau autorizaţiilor pentru divulgarea informaţiilor atunci când sunt necesare.
Deciziile trebuie sa fie documentate şi trebuie sa includă gradul de informare, nivelele de
verificare şi de expunere la opţiunile de tratament. Documentaţia va asigura ca serviciile
medicale care sunt efectuate pacientului sunt conform prevederilor pacientului, familiei sau
altor părţi 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, intoleranţelor şi reacţiilor
adverse
Alergenii, inclusiv imunizările şi substanţele 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 reacţiei adverse şi poate fi modificata ulterior. Lista include
reacţii ale pacientului care sunt clasificate ca alergii dar şi alte reacţii precum intolerante,
efecte secundare şi alte reacţii adverse la medicamente, dieta sau declanşatori din mediul
înconjurător.
1.1.1.18. Gestiunea listei medicamentelor
Listele de medicamente sunt actualizate de-a lungul timpului, fie de-a lungul vizitei sau
internării unui pacient fie de-a lungul unei perioade mai mari de timp. Toate datele relevante
inclusiv data/ora începerii administrării, modificări ce au loc asupra medicaţiei şi perioadelor
de administrare şi data/ora încetării administrării sunt stocate în lista. Elementele din lista pot
include date privind medicamente alternative, suplimente şi medicaţie naturista daca este
cazul. Lista nu este limitata la medicamentele înregistrate de prestatorii de servicii dar poate
include de exemplu şi înregistrări provenite din modulul ePrescripţie, medicaţie raportata de
pacient (si înregistrata ca atare) şi informaţii adiţionale dozajul particular administrat.
1.1.1.19. Gestiunea listei de probleme
Problemele pot include condiţii cronice, diagnostice, simptome, limitări funcţionale, condiţii
specifice ale vizitei sau internării. Listele de probleme sunt gestionate de-a lungul timpului,
fie de-a lungul vizitei sau internării unui pacient fie de-a lungul unei perioade mai mari de
timp permiţând documentarea informaţiei istorice şi urmărirea schimbărilor apărute în
probleme şi prioritatea lor. Sursa problemelor (raportate de pacient, verificate de medic, etc.)
trebuie înregistrata explicit în sistem atât timp cât fac parte din setul date medicale relevante.
Toate datele relevante sunt stocate în fiecare înregistrare inclusiv data notarii şi a
diagnosticului, datele schimbărilor apărute în probleme.
1.1.1.20. Gestiunea listei imunizărilor
Listele de imunizări sunt gestionate de-a lungul timpului fie de-a lungul vizitei sau internării
unui pacient fie de-a lungul unei perioade mai mari de timp. Detaliile imunizărilor
administrate sunt înregistrate ca elemente discrete care trebuie sa includă informaţii precum
data, tipul, producătorul, numărul lotului.
5.5. Suport clinic
5.5.1. Informaţii 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ă conţină date privind nivelul de acces necesar pentru accesarea sistemului şi orice alte
informaţii necesare pentru verificarea ca utilizatorul este autorizat să folosească sau să
vizualizeze datele.
1.1.1.22. Informaţii privind locaţiile
Sistemul trebuie sa includă informaţii privind locaţiile prestatorilor de servicii medicale
inclusiv date de contact şi informaţii de contact pentru intervale de timp din afara
programului de lucru pentru persoanele abilitate. Sistemul trebuie să includă informaţii
privind locaţiile principale dar şi locaţiile secundare ale prestatorului de servicii medicale
daca acestea exista. Informaţiile gestionate pot include adrese web, hărţi, adrese şi locaţia
exactă a clădirilor, etc.
1.1.1.23. Registrul prestatorilor de servicii medicale
Registrul oferă acces de tip director, registru sau depozit pentru informaţiile prestatorilor de
servicii medicale actualizate aflate în SIUI în concordanta cu legile, regulamentele şi
cerinţele interne şi externe relevante. Datele incluse pot fi numele complet, specialitatea,
adresa, locaţia, date contact, etc. Vizualizarea datelor este posibila pentru utilizatori conform
nivelurilor de securitate şi acces necesare. Pacienţii nu vor avea de exemplu acces la
informaţii personale ale prestatorilor de servicii medicale.
5.5.2. Registrul pacienţilor (preluate din eCard)
Sunt incluse informaţii precum numele complet, adrese, persoane de contact, informaţii
contact. Vizualizarea datelor se face în conformitate cu nivelele de securitate şi acces
necesare.
1.1.1.24. Informaţii demografice pacient (preluate din eCard)
Sistemul trebuie sa includă setul de date minimal necesar conform legilor aplicabile şi
necesitaţilor de raportare. Registrul trebuie sa includă posibilitatea urmăririi schimbărilor
elementelor, suport pentru multiple coduri de identificare şi nume multiple, şi istoricul
schimbărilor de nume.
1.1.1.25. Locaţii de reşedinţa ale pacienţilor pentru
pregătirea şi administrarea serviciilor
Informaţiile privind reşedinţa pacienţilor este necesara pentru servicii care au loc în afara
locaţiilor prestatorului de servicii medicale. Exemple pot include vizitele pentru oferirea
îngrijirii medicale pentru copii nou născuţi direct la domiciliu sau în cazul pacienţilor cu
probleme de mobilitate. Sistemul trebuie sa permită identificarea reşedinţelor multiple pentru
un pacient.
5.6. Rapoarte, măsurători, analiza şi cercetare
Funcţiile de raportare, măsurători, analiza şi cercetare trebuie sa vina în completarea
funcţiilor existente deja în SIUI.
5.6.1. Rezultate şi analize
De multe ori este necesara raportarea asupra statisticilor medicale către 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 informaţii 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 înregistrările
pacienţilor.
1.1.1.26. Generarea înregistrărilor medicale sub forma de
rapoarte
Sistemul trebuie sa permită generarea unor rapoarte formale conţinând informaţii provenite
din dosarul pacientului. Trebuie sa fie posibila generarea unor subseturi ale dosarului bazate
pe profile. De exemplu un profil poate conţine informaţii demografice pacient şi informaţii
externare iar alt profil poate conţine toate informaţiile create de un anumit prestator de
servicii medicale în timp ce un al treilea profil poate conţine toate informaţiile î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 înregistrările
pacienţilor. Utilizatorii trebuie sa poată filtra/sorta rapoartele în funcţie de diverse criterii (de
exemplu sa poată vedea doar pacienţii cu diabet dintr-o lista de pacienţi ş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ă răspunsuri rapide la cerinţe de raportare şi analiza noi.
Utilizatorii trebuie sa îşi poată defini parametrii pentru rapoarte cu rezultate care pot conţine
atât date structurate cat şi date nestructurate. Sistemul trebuie sa permită căutări şi după
prezenta sau absenta unor seturi de date. De exemplu în cadrul unei verificări pentru
respectarea unui protocol medical care presupune testarea unei categorii de pacienţi o data la
3 luni, investigatorul trebuie sa poată crea un raport pentru aflarea pacienţilor care nu au date
de test în DES.
5.7. Administrarea accesului
Pentru asigurarea confidenţialităţii toate modulele aplicaţiei trebuie sa adere la un set de
reguli stabilite pentru asigurarea controlului accesului şi protejarea datelor personale.
Masurile de control al accesului previn utilizarea fără autorizaţie a datelor şi protejează
împotriva pierderilor, modificărilor şi distrugerii datelor. Sistemul DES trebuie sa fie capabil
sa se integreze cu sisteme standard de securitate şi sa asigure ca orice entitate (persoana,
aplicaţie, echipament, etc.) care accesează sistemul este autentificat, autorizat şi auditat în
conformitate cu politicile de administrare a accesului.
5.7.1. Autentificarea entităţilor
Atât utilizatorii cat şi aplicaţiile se supun regulilor de autentificare. DES oferă mecanisme de
autentificare atunci când se încearcă folosirea aplicaţiei. Aplicaţiile care se conectează la
DES trebuie sa se autentifice în prealabil pentru a se putea face autorizarea. Modalităţile prin
care se face autentificarea sunt:
1. Posesorii de carduri de sănătate 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 adăuga parafa
medicului care face cererea de date. Sistemul HIS al spitalului păstrează o corelare
intre sistemul propriu de autentificare şi parafa medicului care s-a autentificat în
sistem.
Aplicaţiile care schimba informaţii cu DES se vor autentifica pe baza de certificat digital.
Canalul de comunicaţie este întotdeauna criptat.
5.7.2. Autorizarea entităţilor
Utilizatorii DES sunt autorizaţi sa folosească componentele acestuia conform identităţii,
rolului, sarcinilor, locaţiei, condiţiile curente ale pacientului, domeniului în care activează
presatorul de servicii medicale şi jurisdicţia legala aplicabila.
5.7.3. Controlul accesului
Sistemul verifica şi impune controlul accesului pentru toate componentele DES, informaţiile
din DES şi acţiunile 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 pacienţilor
Sistemul trebuie sa permită gestiunea drepturilor de vizualizare a conţinutului dosarului
electronic de sănătate. Pacientul poate vedea secţiuni de date ale propriului dosar conform
legilor şi regulamentelor aplicabile.
5.7.5. Recunoaşterea acţiunilor
Sistemul trebuie sa nu permită nerecunoaşterea acţiunilor făcute de către utilizatori folosind
sistemul DES inclusiv a datelor primite sau transmise prin sistem. Sistemul înregistrează
informaţii audit pentru toate activităţile executate de utilizatori sau pentru datele primite în
sistem şi transmise din sistem. Sistemul garantează că utilizatorii sistemului nu pot nega mai
târziu introducerea unor date sau recepţionarea unor date.
5.7.6. Schimbul sigur de date
La schimbul de informaţii din cadrul sistemului DES este necesara o securitate adecvata care
poate fi obţinuta prin mecanisme specifice precum criptare şi autentificare. Un schimb de
date securizat necesita o coordonare globala a schimbului de informaţii intre componentele
DES şi reguli privind modul cum vor decurge aceste comunicaţii. Politicile de securitate
aplicate la nivele şi locaţii diferite trebuie sa fie consistente şi compatibile intre ele pentru a
asigura protecţia informaţiei la trecerea intre ele.
5.7.7. Rutarea securizata a datelor
Datele electronice trebuie sa fie transmise către şi de la entităţile cunoscute şi autentificate în
concordanta cu regulile şi standardele relevante. Aceasta funcţie a sistemului se bazează pe
autentificarea, autorizarea şi criptarea informaţiilor intre entităţi.
5.7.8. Certificarea informaţiilor
Scopul certificării informaţiilor este de a indica entitatea care a creat sau modificat datele şi
pentru a putea impune responsabilitatea pentru o acţiune, eveniment, opinie, diagnostic, etc.
Fiecare element din dosarul electronic trebuie sa poată fi identificat clar ca fiind creat sau
semnat de către autor. Certificarea informaţiilor trebuie sa se supună standardelor şi cerinţelor
legale.
Cerinţe subsistem de securitate, siguranţa şi confidenţialitate
In locaţia finala echipamentele vor prezenta următoarele sisteme de siguranţa. 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 fiecărui operator. Sistemul ce permite accesul în zona serverelor va fi conectat la sistemul
de audit centralizat. Această cerinţă este îndeplinită de către operatorul centrului de date unde
este găzduit sistemul.
1.1.1.29. Cerinţe 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 susţin rularea aplicaţiei în condiţii optime vor avea alimentare
electrica duala (doua surse de alimentare) şi vor fi protejate cu UPS-uri redundante sau în
configuraţie N+1. Timpul de funcţionare în sarcina pe baterii a UPS-urilor va fi cu cel
puţin 30% mai mare decât timpul necesar opririi în condiţii de siguranţa a echipamentelor
IT ce deservesc sistemul informatic dar nu mai puţin de 20 minute în total.
1.1.1.30. Cerinţe de securitate a sistemului
Securitatea sistemului este asigurata folosind următoarele metode în funcţie de nivelul de
acces, astfel:
o La nivel de sistem de stocare, se vor folosi arii de discuri dedicate pentru partiţiile logice
ce folosesc date medicale, astfel încât discurile fizice sa conţin date medicale sa poată fi
marcate corespunzător.
o La nivel de server, se vor folosi sisteme virtualizate ce îndeplinesc şi funcţia de izolare a
partiţiilor virtuale astfel încât sa nu exista comunicare intre doua partiţii prin alte mijloace
decât cele dorite.
o Sistemele de operare folosite vor fi certificate minim EAL4
o La nivelul echipamentelor de comunicaţii se va folosi tehnologia VLAN pentru izolarea a
traficului. Echipamente IT din aceeaşi zona de securitate vor avea VLAN-uri dedicate. O
zona de securitate reprezintă echipamentele protejate firewall şi ca nu pot fi accesate
decât 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 întâi cu contul lor unic şi dedicat, şi apoi vor
comuta către 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. Confidenţialitatea datelor
o Traficul utilizatorilor va trece prin mai multe sisteme de filtrare.
• La nivel de reţea, traficul va trece prin firewall-uri, IDS, IPS şi sisteme de
autentificare şi autorizare dedicate. în plus reţeaua de date va fi împărţită în mai multe
zone (ex: acces internet, DMZ, zona de management şi administrare, zona de aplicaţii,
zona bazelor de date , zona audit şi monitorizare, etc)
• La nivel de aplicaţie traficul sa fi filtrat folosind metode de genul ReverseProxy şi
sisteme tampon (daca acestea sunt compromise se întrerupe legătura la serverele de
date)
o Beneficiarul datelor medicale (asiguratul medical) va avea acces la informaţiile de audit,
prin portal, astfel încât sa poată monitoriza toate accesele efectuate asupra propriului
dosar medical.
o Accesul în sistemul de audit se va face strict pe baza nevoii de cunoaştere.
1.1.1.32. Managementul utilizatorilor şi accesul la sistem
Pentru asigurarea securităţii aplicaţiei este nevoie de un sistem solid dar în acelaşi timp
flexibil care sa permită integrarea mai multor surse de autentificare printre care LDAP şi baze
de date. Sistemul trebuie sa fie dimensionat corespunzător pentru a permite stocarea tuturor
utilizatorilor definiţi în sistem şi scalabil pentru a satisface nivelul de performanta cerut.
Autentificarea se va face o singura data pentru toate aplicaţiile componente (SSO – Single
Sign On). Pentru fiecare utilizator se vor afişa doar aplicaţiile şi informaţiile pentru care a
fost autorizat.
Drepturile de acces vor putea fi definite intr-un mo flexibil: cine şi ce se poate accesa în
cadrul aplicaţiei. Pentru fiecare rol se va putea defini ce resurse pot fi accesate.
La nivel de aplicaţie 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 informaţie medicala şi alte informaţii 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 semnătura
digitala (atât a utilizatorilor individuali prin cardurile de sănătate cat şi a sistemelor cu care
DES se va integra) pentru a împiedica negarea acţiunilor efectuate asupra datelor
Datele adunate în urma auditării acestor evenimente vor putea fi vizualizate apoi în cadrul
unor rapoarte. Pe fiecare raport se poate da drept de vizualizare pentru diverse roluri ale
aplicaţiei.
5.7.9. Gestiunea înregistrărilor medicale
1.1.1.33. Păstrarea, disponibilitatea şi distrugerea datelor
Datele medicale trebuie sa fie păstrate 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
cerinţele legale şi regulamentele aplicabile).
Datele trebuie păstrate în sistem pentru o perioada de timp stabilita de legislaţia 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. Înregistrări auditabile
Sistemul trebuie sa ofere funcţii de audit pentru acces şi folosire indicând autorul,
modificarea care a fost făcuta (atunci când 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 activităţile care ţin de securitate.
1.1.1.35. Anonimizarea datelor
Sistemul trebuie sa permită exportul datelor - un mod care să îndeplinească cerinţele de
anonimizare a datelor conform legislaţiei şi regulamentelor în vigoare. Sistemul trebuie sa
înregistreze toate exporturile de date de acest fel, cu detalii privind cine, ce, de ce şi când au
fost cerute şi exportate aceste date.
5.7.10.Stocarea şi gestiunea informaţiilor medicale
1.1.1.36. Gestiunea informaţiilor nestructurate
Informaţiile nestructurate sunt informaţii 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 către un operator fără 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 referinţe la sisteme externe.
1.1.1.37. Gestiunea informaţiilor structurate
Informaţiile structurate sunt informaţii care sunt separate în elemente. Exemple de date
structurate pot include adrese, presiune sanguina (element numeric), observaţii 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 referinţe la informaţii pentru pacienţi şi prestatori
de servicii medicale, organizaţii din domeniul sănătăţii, 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 informaţiilor intre sisteme de tip EHR, ce da posibilitatea schimburilor de
informaţii la nivel naţional dar şi internaţional. Astfel, este promovat accesul la informaţie
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 cerinţele de
interoperabilitate cu entităţi interne şi externe. Este fundamentala existenta unei înţelegeri
comune asupra regulilor de conectivitate, structuri de informaţii, 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 aceloraşi date în sisteme diferite sau copierea datelor manuala de către utilizator nu
este acceptabila.
Suportul pentru moduri de interacţiune multiple este necesar pentru a răspunde la diverse
tipuri de schimburi de date şi nivele de timpi de răspuns.
Terminologiile standard, descrise mai sus, sunt fundamentale pentru schimbul de informaţii.
Folosirea unui model informaţional specific este necesara pentru optimizarea
interoperabilităţii.
5.9.2. Integrarea intre aplicaţii bazata pe standarde
Sistemul trebuie sa permită integrarea la nivel de aplicaţie 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 interacţiune 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. Interacţiunea 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. Cerinţe tehnice generale
o Nu sunt permise pierderi de date la transferul spre baza de date.
o Aplicaţia este dezvoltata urmărind o arhitectura în trei straturi (baza de date, logica de
aplicaţie, interfaţa cu utilizatorul).
o Sistemul informatic propus în cadrul prezentului proiect trebuie proiectat, instalat, testat
şi pus în funcţiune ca un sistem complet integrat, scalabil, deschis, extensibil, flexibil, cu
atribute înalte de securitate şi disponibilitate, interoperabil cu alte sisteme informaţionale,
prin interfeţe care vor fi descrise mai jos.
o Utilizarea unei arhitecturi modulare permite o cuplare redusa intre componente şi în care
responsabilităţile fiecărei componente sunt specializate.
o Structura modulara permite adăugarea de noi module fără modificări î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 interfaţa bazata pe servicii WEB prin care aplicaţiile instituţiilor
medicale pot transmite informaţie folosind un canal de comunicare sistem la sistem.
o Sistemul propus permite exportul informaţiilor stocate în diverse formate (bazate pe
XML).
o Infrastructura hardware trebuie sa includă toate componentele necesare care sa satisfacă
cerinţele de performanta. Această infrastructura trebuie sa conţină cel puţin:
• Sisteme de calcul
• Sistem de stocare - storage (SAN)
• Sisteme de arhivare secundare, librărie de benzi
• Sistem de asigurare continua a energiei electrice
• Rack-uri
• Infrastructura de reţea necesara în cadrul soluţiei (între componentele ce compun
sistemul propriu-zis)
o Va fi proiectat ca un sistem de înalta performanta şi disponibilitate
o Va oferi suport pentru soluţii moderne deschise de integrare
o Sistemele şi echipamentele livrate trebuie sa fie noi, neutilizate şi de ultima generaţie. Ele
trebuie sa asigure gradul necesar de performanta, fiabilitate şi flexibilitate fiind proiectate
şi destinate pentru aplicaţii critice “enterprise level”.
o Dispozitivele hardware trebuie sa fie astfel proiectate încât sa poată asigura scalabilitatea
sistemului în cazul creşterii nevoii de putere de calcul.
o Dispozitivele hardware livrate, care au în configuraţie posibilitatea de upgrade pentru
anumite componente, trebuie astfel configurate încât upgrade-ul sa se facă fără pierderea
de dispozitive existente.
o Dispozitivele hardware trebuie sa fie compatibile cu caracteristicile reţelei electrice din
România astfel încât sa nu existe probleme la conectarea acestora la reţeaua electrica.
o Ofertantul va prezenta specificaţiile tehnice privind organizarea şi amenajarea camerei
serverelor (dataroom / datacenter) în care se vor instala echipamentele astfel încât sa fie
asigurate condiţiile operaţionale optime pentru funcţionarea acestora.
o Ofertantul va preciza care este greutatea totala a echipamentelor livrate şi dimensiunile
fizice ale acestora pentru a se putea verifica siguranţa instalării în locaţia solicitantului.
o Ofertantul va preciza în oferta care este puterea totala consumata de echipamentele livrate
precum şi caracteristicile de climatizare/ventilaţie necesare, astfel încât solicitantul sa
poată asigura acest necesar în locaţia unde urmează a fi instalate echipamentele.
o Implementatorii posibili vor avea în vedere ca toate cerinţele şi caracteristicile hardware
sunt minime şi obligatorii.
o Cerinţele nu sunt limitative ofertanţii având libertatea de a le dezvolta şi extinde conform
soluţiei pe care o au în vedere. Este aşadar necesar ca ofertanţii sa propună soluţii
complete şi integrate, care sa îndeplinească în totalitate cerinţele solicitantului.
o Ofertanţii 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 documentaţia de atribuire cu
condiţia explicării detaliate a funcţionalităţilor în cadrul construcţiei arhitecturilor
software şi hardware din care sa reiasă necesitatea lor.
5.10.1.Flexibilitatea sistemului
o Aplicaţiile informatice vor trebui sa prezinte un grad important de parametrizare care sa
permită modificări rapide şi facile.
o Aplicaţiile informatice trebuie sa utilizeze un sistem modern de gestiune al conţinutului
care să permită funcţii 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 fără modificarea aplicaţiilor
instalate.
o Sistemul trebuie sa permită extinderea numărului de utilizatori suportaţi şi a numărului de
accesări zilnice prin adăugarea de hardware suplimentar fără a fi necesare modificări la
nivelul aplicaţiei.
o Întreaga soluţie centrala trebuie realizata astfel încât sa nu existe nici un punct unic de
avarie (Single Point of Failure).
o Timpul de răspuns al sistemului la nivel de interfaţa utilizator nu trebuie sa depăşească 5
secunde pentru 90% din cereri cu excepţia operaţiilor de logare, generare de rapoarte şi a
căutărilor.
o Prin utilizarea unor tehnici avansate de cluster, soluţia propusa trebuie sa asigure un nivel
înalt de disponibilitate (availability) şi fiabilitate (reliability). Utilizarea tehnicilor
avansate de cluster asigura, pe lângă un nivel crescut de scalabilitate şi o buna distribuţie,
şi un nivel ridicat de fiabilitate prin creşterea nivelului de toleranţa la erori.
o Implementarea unei soluţii 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 Numărul 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 sănătate
o Portalul DES trebuie sa susţină aproximativ 20.000.000 de utilizatori . Fiecare asigurat va
avea acces la portalul DES folosind cardul de sănătate. Estimam un număr de 50.000 de
sesiuni concurente.
o Estimam 20.000 de evenimente pe zi generatoare de înregistrări/acţiuni tip DMR.
5.11. Funcţionalităţi expuse de sistemul SIUI prin servicii web
În acest capitol sunt prezentate funcţionalităţile expuse de sistemul SIUI prin intermediul
serviciilor web.
Detalierea serviciilor şi a metodelor expuse de acestea este prezentată pe larg în
“Specificaţiile de interfaţare cu SIUI-Actualizat”, documentaţie publicata pe Portalul CNAS-
SIUI la adresa http://siui.casan.ro/cnas/siui_2.0/specificatii. Documentaţia conţine şi
structura fişierelor XML specifice fiecarui serviciu Web expus, dar şi fiecărui 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 aplicaţii cu
nomenclatoarele din SIUI. Aplicaţiile de la furnizori vor putea descărca online
nomenclatoarele specifice în urma publicşrii unor noi versiuni ale acestora. Aplicaţia va afişa
un mesaj de avertizare dacă detectează o versiune mai nouă de nomenclatoare, propunând
sincronizarea acestora.
Sistemul DES si HIS-urile pot interacţiona cu acest serviciu Web din perspectiva utilizării
codurilor din nomenclatoarele standardizate SIUI pentru identificarea semnificaţiei datelor cu
caracter medical, dar si a celor cu caracter administrativ, înlesnind astfel utilizarea unui
vocabular comun cu SIUI atât pentru sistemul de gestiune pentru Dosarul Electronic de
Sănătate, cât şi pentru alte sisteme naţionale din domeniul sănătaţii şi al asigurărilor de
sănătate, cum ar fi Cardul Electronic de Asigurări de Sănătate sau Prescripţia 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
existenţa unei noi versiuni.
Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector
reprezintă URL-ul de la care se face descărcarea fişierului, iar cel de-al doilea şir reprezintă
dimensiunea fişierului care trebuie descărcat.URL-ul va expira la momentul publicării unei
noi versiuni de nomenclatoare pentru a nu permite aplicaţiilor de raportare să descarce
accidental un fişier de nomenclatoare mai vechi folosind un URL din cache.
Dacă nu există o versiune mai nouă de nomenclatoare metoda întoarce null.
Cel de-al doilea parametru poate fi folosit pentru a evita transferul inutil de date prin stocarea
în aplicaţia client a datei la care s-a efectuat sincronizare anterioară şi prin folosirea acestei
date ca dată de început pentru căutare a unei versiuni mai noi a nomenclatoarelor.
4. Serviciul pentru sincronizarea datelor de personalizare
Serviciul va permite sincronizarea datelor de personalizare a aplicaţei existente în aplicaţiile
furnizorilor cu nomenclatoarele din SIUI. Datele de personalizare se referă la detalii
contractuale, servicii şi tarife contractate, liste de înscrişi, în funcţie de specificul fiecărui tip
de furnizor. Aplicaţiile de raportare vor putea descărca online datele de personalizare
specifice în urma actualizării acestora în SIUI. Aplicaţia va afişa un mesaj de avertizare dacă
detectează o versiune mai noua, propunând 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 sfârşit a perioadei pentru care
se caută datele furnizorului în sistem;
• parametrul uic de tip şir de caractere reprezintă codul unic de identificare al furnizorului
în sistem, CUI (cod fiscal) sau CNP, după caz.
Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector
reprezintă URL-ul de la care se face descărcarea fişierului de personalizare, iar cel de-al
doilea şir reprezintă dimensiunea fişierului care trebuie descărcat.
5. Serviciul pentru trimiterea raportărilor periodice
Serviciul permite trimiterea unui fişier de raportare periodică către SIUI. La momentul
trimiterii se realizează validarea formei şi conţinutului fişierului, precum verificarea
existenţei unui contract valid şi a unei perioade de raportare deschisă pentru furnizorul
respectiv. Prelucrarea datelor este asincronă, furnizorul trebuind să se conecteze ulterior
pentru a prelua rezultatele raportării şi decontul.
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ă conţinutul fişierului de raportare
arhivat în formatul ZIP (JavaZip) şi codat ulterior în formatul Base64.
Dacă metoda întoarce valoarea„adevărat”, atunci trimiterea raportului s-a făcut cu succes,
altfel trimiterea s-a terminat cu erori. Pe baza mesajului primit în cazul unei erori se poate
determina cauza respingerii raportării.
Instrucţiuni de folosire
Numele fişierului 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", fără nici un separator.
Schema de validare pentru acest fişier este detaliată în anexele corespunzătoare fiecărui tip de
furnizor.
6. Serviciul pentru preluarea rezultatelor raportărilor periodice
Serviciul permite preluarea fişierului de răspuns pentru o raportare trimisă anterior către SIUI
pentru prelucrare. Pentru ca fişierul de răspuns să poate fi descărcat acesta trebuie să fie
salvat într-o locaţie predefinită pe mediile de stocare ale SIUI, lucru care se efectuează
automat în urma prelucrării fişierului de raportare.
Metoda getReportFeedback
String[] getReportFeedback( String fileName )
Metoda are un singur parametru de intrare :
• parametrul fileName de tip şir de caractere reprezentă numele fişierului de raportare
trimis de aplicaţie pentru care se cere răspunsul procesării.
Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector
reprezintă URL-ul de la care se face descărcarea fişierului, iar cel de-al doilea şir reprezintă
dimensiunea fişierului care trebuie descărcat.
Dacă nu există un fişier de raportare procesat cu numele dat, metoda întoarce null.
Aplicaţia client trebuie să folosească URL-ul rezultat pentru a descărca fişierul cu
nomenclatoarele. Dimensiunea fişierului poate fi folosită pentru a verifica completitudinea
fişierului descărcat. Fişierul descărcat este o arhivă ZIP care conţine un fişier XML cu
rezultatul procesării raportării în SIUI.
Schema de validare pentru acest fişier este detaliată în anexele corespunzătoare fiecărui tip de
furnizor.
7. Serviciul pentru preluarea decontului calculat în SIUI
Serviciu permite obţinerea fişierului de decont aferent unei perioade de raportare sau unei
anumite raportări (în baza numărului de factură). În acest sens, serviciul va expune două
metode, una pentru preluarea decontului pentru o perioadă de raportare, şi alta pentru
preluarea decontului pentru o anumită factură (folosită în mod special de farmacii).
Datele vor fi disponibile după finalizarea procedurii de decontare din cadrul SIUI. Decontul
este un raport (în format PDF) şi este destinat consultării de către furnizor. Datele de pe
raport nu vor fi preluate în aplicaţie.
Metoda getRefund
String[] getRefund(String partnerCategory,DateTime start,DateTime stop,String uic )
Metoda are patru parametri de intrare:
• parametrul partnerCategory de tip şir de caractere reprezintă codul tipului de furnizor,
lista valorilor permise fiind prezentată mai jos;
• parametrul start de tip dată calendaristică reprezintă data de început a perioadei pentru
care se doreşte fişierul de decont;
• parametrul stop de tip dată calendaristică reprezintă data de sfârşit a perioadei pentru care
se doreşte fişierul de decont;
• parametrul uic de tip şir de caractere reprezintă codul unic de identificare al furnizorului
în sistem, CUI (cod fiscal) sau CNP, după caz.
Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector
reprezintă URL-ul de la care se face descărcarea fişierului de decont, iar cel de-al doilea şir
reprezintă dimensiunea fişierului care trebuie descărcat.
Dacă nu există un fişier de decont generat pentru furnizorul respectiv, metoda întoarce null.
8. Serviciul pentru consultarea cererilor şi a deciziilor
Serviciu permite sincronizarea informaţiilor referitoare la deciziile de aprobare ale unor
categorii de servicii, cum ar fi acordarea de dispozitive medicale sau de îngrijiri la domiciliu.
Serviciul va întoarce ca răspuns un fişier XML care va conţine toate datele necesare
înregistrării corecte şi pre-validării la nivelul aplicaţiei de raportare a serviciilor prestate şi a
dispozitivelor medicale eliberate.
Metoda getDecisions
String[] getDecisions(String partnerCategory,String requestXml )
Metoda are doi parametri de intrare:
• parametrul partnerCategory de tip şir de caractere reprezintă codul tipului de furnizor,
lista valorilor permise fiind prezentată mai jos;
• parametrul requestXml de tip şir de caractere reprezintă conţinutul fişierului de cerere
arhivat în formatul ZIP (JavaZip) şi codat ulterior în formatul Base64.
Metoda întoarce un vector de şiruri de caractere de lungime doi. Primul şir din acest vector
reprezintă URL-ul de la care se face descărcarea fişierului de răspuns, iar cel de-al doilea şir
reprezintă dimensiunea fişierului care trebuie descărcat.
Dacă nu există un fişier de raportare procesat cu numele dat, metoda întoarce null.
Instrucţiuni de folosire
Aplicaţia client trebuie să folosească URL-ul rezultat pentru a descărca fişierul de răspuns.
Dimensiunea fişierului poate fi folosită pentru a verifica completitudinea fişierului descărcat.
Fişierul descărcat este o arhivă ZIP care conţine un fişier XML cu datele referitoare la
deciziile cerute din SIUI.
Numele fişierului 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", fără nici un separator.
Schema de validare pentru acest fişier, dar şi pentru fişierul de răspuns care conţine deciziile,
este detaliată în anexele corespunzătoare fiecărei categorii de furnizor.
9. Serviciul pentru verificarea calității de asigurat
Serviciul permite verificarea calităţii de asigurat, prinde ca parametru CNP-ul pacientului.
Serviciul Web trebuie sa trateze situaţia in care parametrul furnizat nu se poate valida ca şi
CNP, dar şi cazul în care CNP-ul nu este înregistrat în sistem. Fişierul XML returnat de
serviciul web va conţine cel puţin următoarele categorii de informaţii:
• Lista categoriilor active la data interogării
• Ștampila de timp la momentul emiterii răspunsului
• Codul de jurnalizare/auditare al răspunsului
Sistemul DES poate interacţiona cu acest serviciu Web pentru verificarea online a stării 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 doreşte
verificarea calităţii de asigurat, de exemplu data curentă sau data efectuării serviciului.
Metoda întoarce ca răspuns un şir de caractere reprezentând conţinutul unui fişier în format
XML care conţine următoarele informaţii:
• Un cod numeric de răspuns indicând dacă beneficiarul este asigurat sau nu, dacă figurează
ca decedat în sistem, dacă nu este înregistrat în sistem sau dacă CNP-ul nu este corect.
• Lista categoriilor active la data interogării
Observaţie: În cazul unei erori întâlnite în sistem la procesarea cererii se va întoarce un cod
numeric de răspuns (-1) precum şi o descriere a erorii.
Instrucţiuni de folosire
Aplicaţia de raportare trebuie să proceseze fişierul de răspuns şi să afişeze un mesaj sugestiv
pentru utilizator cu privire la starea de asigurat a persoanei respective. Dacă este cazul
aplicaţia va precompleta câmpurile corespunzătoare categoriei de asigurat, selectând
categoria cea mai favorabilă pacientului din lista transmisă din SIUI.
Este de preferat ca aplicaţia de raportare să realizeze validarea de corectitudine a CNP-ului,
algoritmul fiind arhicunoscut, pentru a nu supraîncărca sistemul cu cereri inutile.
Schema de validare pentru fişierul de răspuns este detaliată în anexele corespunzătoare
fiecărei categorii de furnizor.
10. Serviciul pentru pre-validarea mișcărilor de capitațieServiciul permite transmiterea către SIUI a unei cereri de înscriere/ieşire/deces a unui pacient
pe lista unui medic de familie. SIUI va valida cererea prin verificarea respectării intervalului
de 6 luni de la ultima schimbare de către pacient a medicului de familie si va transmite un
răspuns prin serviciul Web către medicul de familie in care este trecut rezultatul operaţiei.
Trebuie sa fie permisă modificarea acestor informaţii de către medicul de familie până la
întocmirea decontului per-capita pentru medicul de familie. Raportările on-line cu privire la
capitaţie au prioritate faţă de raportările batch (făcute la sfârşitul lunii), existente acum in
SIUI in sensul in care daca înscrierea on-line a unui pacient pe lista unui medic a fost
aprobata, cererea de înscriere a aceluiaşi pacient pentru alt medic care raportează batch va fi
respinsa de SIUI.
Sistemul de Dosar Electronic de Sănătate poate interacţiona cu acest serviciu Web în cazul în
care medicul de familie doreşte 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 prevăd o
durată de timp care trebuie să treacă până când un pacient are dreptul să-şi schimbe medicul
de familie.
Metoda validateEnlisted
String validateEnlisted(String enlistedXml)
Metoda are un singur parametru de intrare:
• parametrul enlistedXml de tip şir de caractere reprezintă conţinutul fişierului de raportare
în format XML.
Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care
conţine următoarele informaţii:
• O structură similară cu cea raportată, conţinând fiecare identificator de înregistrare
transmisă însoţit de starea validării (validat/nevalidat)
• Lista erorilor sau avertizărilor pentru fiecare înregistrare raportată, în caz că acestea au
fost depistate
• Ştampila de timp la momentul emiterii răspunsului
11. Serviciul pentru pre-validarea serviciilor și investigațiilor medicale
Serviciul permite transmiterea serviciile prestate în aplicaţie pe măsură ce acestea sunt
introduse în aplicaţie. Ca regula generală, datele transmise la SIUI vor fi validate iar serviciul
Web va întoarce un răspuns cu privire la rezultatul validării serviciilor raportate, răspuns care
va purta o un identificator unic care poate fi referit de furnizor şi care va permite trasabilitatea
cererii transmisă prin serviciul WEB pentru un operator CJAS.
Dosarul Electronic de Sănătate poate interacţiona cu acest serviciu Web în momentul
validării 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ă conţinutul fişierului de raportare în
format XML.
• parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista
valorilor permise fiind prezentată mai jos;
• parametrul requestType de tip şir de caractere reprezintă codul tipului de cerere de
validare transmisă, lista valorilor permise fiind prezentată mai jos;
Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care
conţine următoarele informaţii:
• O structură similară cu cea raportată, conţinând fiecare identificator de înregistrare
transmisă însoţit de starea validării (validat/nevalidat)
• Lista erorilor sau avertizărilor pentru fiecare înregistrare raportată, în caz că acestea au
fost depistate
• ştampila de timp la momentul emiterii răspunsului
Conţinutul şi formatul datelor transmise este specific fiecărui tip de furnizor şi va fi descris în
detaliu în anexele care însoţesc acest document. Ca regulă generală, datele transmise din
aplicaţia de raportare către SIUI vor fi validate iar serviciul Web va întoarce un răspuns cu
privire la rezultatul validării serviciului medical raportat.
12. Serviciul pentru pre-validarea rețetelor prescrise de medici
Serviciul permite raportarea de către un medic prescriptor a unei reţete prescrise. Validarea
corectitudinii întocmirii reţetei se face după completarea şi transmiterea tuturor informaţiilor
necesare legate de reţetă către SIUI, care transmite în urma procesării un mesaj către medicul
prescriptor cu privire la corectitudinea reţetei în ansamblu, dar şi la fiecare medicament în
parte.
Reţetele se află iniţial intr-o stare “prescrisă”, fiind disponibile spre interogare în farmacii
printr-un apel al serviciului Web dedicat. Modificarea unei reţete prescrise se poate face de
către medicul prescriptor şi numai de către el, atât timp cat reţeta este în starea “prescrisă”,
înainte de a trece in starea “eliberată”.
Dosarul Electronic de Sănătate 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ă conţinutul fişierului de raportare în
format XML;
• parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista
valorilor permise fiind prezentată mai jos.
Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care
conţine rezultatul operaţiunii de validare.
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 validării.
Certificatele medicale astfel raportate vor fi stocate într-o bază de date pentru realizarea
verificărilor de unicitate a certificatelor medicale şi a verificărilor încrucişate conform
normelor în vigoare.
Acest serviciu se adreseaza medicilor care recomanda trimiteri catre specialisti sau
investigatii de laborator. Se poate utiliza in Dosarul Electronic de Sănătate.
Acest serviciu va expune două metode online, una pentru preluarea biletelor de trimitere către
medicii specialişti şi alta pentru biletele de trimetre către investigaţii de laborator.
Metoda validateClinicReferral
String validateClinicReferral(String reportXml,String reportType )
Metoda un singur parametru de intrare:
• parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în
format XML;
• parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista
valorilor permise fiind prezentată mai jos.
Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care
conţine rezultatul operaţiunii de validare.
Metoda validateLabReferral
String validateLabReferral(String reportXml,String reportType )
Metoda un singur parametru de intrare:
• parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în
format XML;
• parametrul reportType de tip şir de caractere reprezintă codul tipului de furnizor, lista
valorilor permise fiind prezentată mai jos.
Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care
conţine rezultatul operaţiunii de validare.
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 validării.
Certificatele medicale astfel raportate vor fi stocate într-o bază de date pentru realizarea
verificărilor de unicitate a certificatelor medicale şi a verificărilor încrucişate conform
normelor în vigoare.
Acest serviciu se adresează medicilor care prescriu certificate de concediu medical.
Concediile medicale se vor adăuga prin SIUI, iar Dosarul Electronic de Sănătate 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ă conţinutul fişierului de raportare în
format XML.
Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML care
conţine rezultatul operaţiunii de validare.
15. Serviciul pentru pre-validarea reţetelor emise de farmacii
Serviciul permite unei farmacii să valideze medicamentele eliberate în baza unei reţete
verificând compatibilitatea dintre medicamentele prescrise si cele eliberate (calitativ si
cantitativ), pentru fiecare medicament eliberat. SIUI va returna un mesaj prin care farmacistul
este înştiinţat despre rezultatul operaţiunii de eliberare de medicamente.
O reţetă poate fi eliberata, total sau parţial, de o singura farmacie. După eliberare reţeta trece
in starea “eliberată” si nu mai este disponibilă pentru alte farmacii. Orice modificare a unei
reţete eliberate de către o farmacie poate fi făcuta exclusiv de farmacia in cauza. Aceste
modificări trebuie salvate intr-un log pentru posibilitatea consultării ulterioare.
Dosarul Electronic de Sănătate poate folosi metoda de interogare a reţetelor existente
Metoda validateFarmacyDrugs
String validateFarmacyDrugs( String reportXml)
Metoda un singur parametru de intrare:
• parametrul reportXml de tip şir de caractere reprezintă conţinutul fişierului de raportare în
format XML.
Metoda întoarce un şir de caractere reprezentând fişierul de răspuns în format XML.
În cazul în care conexiunea nu a putut fi efectuată, rezultatul apelului metodei Web va fi un
mesaj de eroare (o excepţie).
Structura fişierul permite transmiterea mai multor înregistrări simultan, de exemplul la cerea
utilizatorului, după ce acesta a finalizat operarea mai multor reţete eliberate, sau în mod
automat la revenirea conexiunii online după o perioadă de lucru offline.
O reţetă poate fi eliberată, total sau parţial, de o singură farmacie. După eliberare reţeta trece
în starea „eliberată” şi nu mai este disponibilă pentru alte farmacii. Orice modificare a unei
reţete eliberate de către o farmacie poate fi făcută exclusiv de farmacia în cauză. Toate aceste
modificări sunt salvate într-un log pentru posibilitatea auditării ulterioare.
16. Serviciul pentru consultarea reţetelor prescrise
Serviciul permite unei farmacii sa vizualizeze reţetele prescrise de medici si sa elibereze
medicamentele aferente prescripţiei. Transferul de date se va face printr-un serviciu Web in
care este obligatoriu, din motive de confidenţialitate, ca farmacia sa completeze seria si
numărul de reţeta, dar şi CNP-ul pacientului pentru care se eliberează medicamente. Serviciul
Web va returna suficiente date care sa permită aplicaţiei de la farmacie pre-completarea
reţetei (medic, pacient, diagnostice, medicaţie). Nu vor fi disponibile prin serviciul Web
reţete filtrate după nume sau CNP.
Reţetele sunt disponibile pentru interogare din momentul iniţial în care se află în starea
“prescrisă”, până la trecerea în starea “eliberată”. Ulterior, o altă farmacie care interoghează
informaţiile legate de reţeta respectivă va primi un mesaj că reţeta a fost deja eliberată,
prevenind astfel dubla eliberare a unei reţete.
Dosarul Electronic de Sănătate ar putea interacţiona cu acest serviciu Web pentru interogarea
reţetelor. Acest serviciu permite includerea informaţiilor specifice Dosarului Electronic de
Sănătate şi Sistemului de Prescripţie Electronică prin simpla extindere a setului de date
schimbate între SIUI şi sistemele externe cu un set de câmpuri corespunzător.
Metoda getPrescription
String getPrescription(String serial,String number,String pid,String stencil)
Metoda are patru parametri de intrare:
• parametrul serial de tip şir de caractere reprezintã seria reţetei;
• parametrul number de tip şir de caractere reprezintã numãrul reţetei;
• parametrul pid de tip şir de caractere reprezintã CNP-ul beneficiarului reţetei;
• parametrul stencil de tip şir de caractere reprezintã numãrul de parafã al medicului
emitent;
Metoda întoarce şir de caractere reprezentând fişierul de rãspuns în format XML.
Aplicaţiile de raportare vor avea posibilitatea de implementare a unor funcţionalitãţi de
preluare automatã a conţinutului acestor documente în format electronic cãtre SIUI. Astfel o
farmacie poate apela serviciul Web pentru a descãrca o reţetã prescrisã în scopul de a elibera
medicamentele aferente.
17. Serviciul pentru consultarea biletelor de trimitere
Acest serviciu este folosit pentru consultarea biletelor de trimitere pentru specialităţi clinice
sau investigaţii de laborator validate de SIUI de către furnizorii de servicii medicale care
prestează servicii în baza unui bilet de trimitere.Transferul de date se va face printr-un
serviciu Web in care este obligatoriu, din motive de confidenţialitate, ca furnizorul să
completeze seria şi numărul biletului, dar şi CNP-ul pacientului pentru care au fost efectuate
servicii medicale.
Acest serviciu se adresează medicilor care efectuează servicii în baza biletelor de trimitere.
Acest serviciu poate fi folosit de Dosarul Electronic de Sănătate pentru consultarea biletelor
de trimitere
Acest serviciu expune două metode, una pentru consultarea trimiterilor către medicii
specialişti şi cealaltă pentru laboratoare.
Metoda getClinicReferral
String getClinicReferral(String serial,String number,String pid,String stencil )
Metoda are patru parametri de intrare:
• parametrul serial de tip şir de caractere reprezintă seria biletului de trimitere;
• parametrul number de tip şir de caractere reprezintă numărul biletului de trimitere;
• parametrul pid de tip şir de caractere reprezintă CNP-ul beneficiarului biletului de
trimitere;
• parametrul stencil de tip şir de caractere reprezintă numărul de parafă al medicului
emitent;
Metoda întoarce şir de caractere reprezentând fişierul de răspuns în format XML.
Metoda getLabReferral
String getLabReferral(String serial,String number,String pid,String stencil )
Metoda are patru parametri de intrare:
• parametrul serial de tip şir de caractere reprezintă seria biletului de trimitere;
• parametrul number de tip şir de caractere reprezintă numărul biletului de trimitere;
• parametrul pid de tip şir de caractere reprezintă CNP-ul beneficiarului biletului de
trimitere;
• parametrul stencil de tip şir de caractere reprezintă numărul de parafă al medicului
emitent;
Metoda întoarce şir de caractere reprezentând fişierul de răspuns în format XML.
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 Fişiere XSD pentru raportare, personalizare, nomenclatoare şi alte
sincronizări de date
Anexa 2 Fişiere XSD pentru pentru prevalidare online a serviciilor şi
verificare a calitatii de asigurat
Anexa 3 Fişiere WSDL pentru definiţiile serviciilor Web
Anexa 4 Specificaţii de interfaţare 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 Naţionale de Sănătate
Anexa 006 - Medicină de familie si asistenţă medicala primara
Anexa 007 - Ambulatoriu de specialitate si specialitati clinice
Anexa 008 - Servicii paraclinice şi investigaţii de laborator
Anexa 009 - Servicii stomatologice şi de medicină dentara
Anexa 010 - Aplicaţii 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.Raportările 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.Integrări 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 execuţie SOA (Service Oriented Architecture)
• Componentele de Integrare Aplicaţii, Registrul de Servicii şi Serverul de Procese sunt
necesare ca infrastructura pentru execuţia de fluxuri specifice SOA (Service Oriented
Architecture).
• Aceasta infrastructura trebuie sa constituie o baza solida şi în acelaşi timp flexibila pentru
cerinţele operaţionale ale sistemului integrat.
• Sistemul integrat DES trebuie sa permită comunicaţia performanta intre oricare aceste
sisteme.
• Astfel, de exemplu, acţiunea 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ă
declanşa un flux de proces gestionat de Serverul de Procese, fie sa poată apela un serviciu
al cărui ciclu de viata este gestionat intern de sistemul DES.
• In cazul declanşării procesului, Serverul de Procese va juca rol de consumator de servicii,
pe care le va apela folosind Componenta de Integrare Aplicaţii 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 Aplicaţii.
• In ambele cazuri, Componenta de Integrare Aplicaţii va identifica referinţa şi starea
serviciului apelat prin intermediul Registrului de Servicii.
• Odată identificata referinţa şi disponibilitatea serviciului, apelul va fi înaintat de către
Componenta de Integrare Aplicaţii către componenta aplicativa ce implementează
serviciul respectiv.
• Server-ul de Procese va trebui sa exploateze atât servicii interne (furnizate de către
componente aplicative din domeniul de securitate intern), cat şi servicii oferite de către
sistemele externe (de exemplu de tip HIS, etc.).
• Soluţia 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 interacţiuni intre gateway-ul de
securitate, componenta de administrare al utilizatorilor şi drepturilor de acces şi sistemele
aplicative din back-end.
• In cazul interceptării unei cereri neautentificate la nivel HTTP către 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 regăsesc î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 către gateway-ul de securitate pe
baza gestionarii unui identificator de sesiune.
• Autentificarea pe baza de certificat digital se va realiza prin interogarea de către gateway-
ul de securitate, prin intermediul protocolului OCSP (Online Certificate Status Protocol),
a infrastructurii de chei publice oferite de către o platforma de tip CA (Certificate
Authority), oferind informaţii despre validitatea certificatului digital.
• In cazul în care oricare din validările de mai sus va întoarce rezultat negativ, accesul
utilizatorului va fi blocat.
5.12.3.Fluxuri de suport pentru funcţionalitatea de raportare
• Fluxul de suport pentru funcţionalitatea de raportare se bazează pe patru elemente: Baza
de Date Operaţionala, 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), având
capacitatea de conectare la surse de date eterogene.
• Cu ajutorul acestei componente se vor putea crea fluxuri de preluare a informaţiei din
sursele tranzacţionale, putându-se astfel realiza transferul datelor şi transformarea
formatului acestora conform cu necesităţile sistemului de raportare.
• Pentru partea de modelare şi creare a nivelului de Data Warehouse se va folosi un
instrument specializat ce va pune la dispoziţia administratorilor, prin intermediul unei
interfeţe vizuale, a elementelor de analiza şi definire a modelului de date al sistemului de
Data Warehouse.
• Ca secvenţa următoare în flux, componenta de Data Warehouse va fi folosita ca sursa
primara de date pentru componenta de analiza şi raportare ce va pune la dispoziţia
analiştilor de raportare posibilitatea definirii de indicatori de performanta, având ca baza
modelul de date al Data Warehouse, precum şi o paleta predefinită de criterii posibile de
raportare.
• Componenta de raportare va interacţiona 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ă atât utilizatorilor publici înregistraţi cât şi
personalului intern dedicat pentru operaţiuni 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 încât alertele generate de primul sa se înregistreze automat în
modulul de Help – Desk ca ordine de lucru pentru echipa de suport şi având asociat un
număr de identificare.
• Sincronizarea trebuie sa aibă loc automat în ambele sensuri, astfel încât la închiderea unui
caz de către personalul de suport în modulul de Help – Desk, alerta sa fie închisa şi în
componenta de monitorizare.
5.12.5.Cerinţe subsistem de integrare
• Obiectivul integrării la nivel de aplicaţie este de a furniza diferitelor aplicaţii 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 aşa-
numita Service Oriented Architecture (SOA).
• Arhitectura orientata pe Servicii (SOA) divide aplicaţiile monolitice în seturi de servicii
care executa funcţii bine definite şi sunt disponibile pentru toţi utilizatorii. Aceste servicii
pot fi utilizate folosind protocoale standard care asigura accesibilitatea atât pe plan intern
(al aplicaţiei) cit şi extern. în continuare sunt descrise mecanismele de baza necesare
pentru integrarea aplicaţiilor 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 organizaţiei sau cu alte organizaţii prin
Internet. Înregistrarea şi căutarea 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 fiecărui serviciu.
• Orice interconectare între diferite aplicaţii trebui sa fie realizata folosind Servicii Web
XML. Metoda „tradiţională” de integrare la nivel de date, în care o aplicaţie creează sau
accesează înregistrări direct în baza de date a altei aplicaţii nu este acceptabil. Acesta
duce la crearea de aplicaţii foarte dependente reciproc, ceea ce nu corespunde cu liniile
directoare ale arhitecturii orientate spre servicii.
• Servicii de infrastructura
• Deşi serviciile Web XML furnizează un nivel de baza, pentru punerea în aplicarea
necesitaţilor SOA sunt necesare componente de nivel superior care sunt accesate de
toate aplicaţiile şi serviciile. De exemplu, componentele care furnizează servicii de
infrastructura şi de automatizare a proceselor de business.
• Serviciile de infrastructura furnizează aplicaţiilor, sau altor servicii, servicii de baza care
nu depind de utilizări specifice sau funcţii de business. Pot fi menţionate ca exemple :
servicii de securitate, funcţii de analiza şi monitorizare, brokeri de mesaje, mecanismul de
transmitere mesaj, funcţiile administrative, jurnalizare de date, prelucrarea situaţiilor
excepţionale, precum şi registrele de servicii şi de căutare.
• Ca minim de servicii implementate, se cer servicii de securitate comune pentru toate
aplicaţiile, ceea ce oferă mecanisme de autentificare unificate, de autorizare şi de audit al
operaţiunilor.
• Mesaje XML
• Tehnologiile bazate pe mesaje asigura un nivel ridicat de scalabilitate şi robusteţe. Aceste
tehnologii permit integrarea rapida şi non-limitativa a aplicaţiilor care folosesc metode de
transmitere şi consum al mesajelor standard. O aplicaţie tipica transmite mesajul cerere
către alta aplicaţie şi continua operaţiunea, fără a aştepta ca mesajul sa ajungă la
destinaţie sau sa primească răspuns.
• În acest caz, operaţiunea curenta nu este blocata în aşteptarea răspunsului. Aceasta
abordare este adecvata în special cazul în care exista necesitatea de a automatiza
procesele care constau în mai multe etape şi a tranzacţiilor care au o durata medie mare.
De exemplu, pentru o aplicaţie de tip front-office intr-o instituţie medicala care primeşte
o depunere de document sau solicitare de la pacient, utilizând tehnologii bazate pe
mesaje, trimite asincron acest document la sistemul de back-office şi continua sa execute
operaţiunile sale curente. Acest mesaj poate fi transmis la sistemul de automatizare a
proceselor de business, care în continuare gestionează şi controlează acest proces pana
când este efectuat. Atunci când procesul este finalizat, sistem de back-office trimite un
mesaj de răspuns înapoi la aplicaţia front-office. După cum s-a menţionat anterior, pentru
a asigura schimbul eficient de date între diferitele aplicaţii ce funcţionează în sistemul
medical, acestea vor fi organizate cu ajutorul unui hub centralizat de date/de integrare.
• Platforma de integrare trebuie sa ofere următoarele funcţii:
• Servicii de identificare şi de securitate. Grup de servicii care oferă funcţia de identificare
a utilizatorului, mecanisme de autentificare şi autorizare, extrem de importante pentru a
garanta confidenţialitatea datele pacienţilor (acces numai pentru utilizatorii autorizaţi).
Cardurile electronice de asigurări de sănătate 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 integrităţii acestora.
• Servicii de tip aplicaţie de business. În mod centralizat, pot fi implementate mai multe
servicii de business comune care sunt folosite de mai multe aplicaţii - de exemplu,
decontare de plaţi, trimiterea de mail securizat şi semnat electronic, seif electronic, etc;
• Interfeţe cu alte sisteme conexe de eSănătate. Interfeţe speciale pot fi stabilite cu
sistemele existente sau ce vor fi dezvoltate în domeniul eSănătăţii
• Platforma de integrare va fi dezvoltata pe baza unei soluţiile tehnologice existente pe
piaţa, testata în mai multe proiecte similare ca complexitate şi extindere.
• Interoperabilitate tehnologica
• Având în vedere principiile menţionate mai sus de integrare intre aplicaţii, 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 mulţi producători, atât timp cit principiile de interoperabilitate
sunt corect şi consistent utilizate. Totuşi, furnizarea mecanismelor de transfer şi stocare
de date trebuie sa asigure un nivel de securitate ridicat (în ceea ce priveşte
confidenţialitatea şi accesibilitatea), aceasta fiind una dintre impunerile fundamentale
pentru orice sistem de eSănătate. În prezent, exista o astfel de reţea a fost creata în cadrul
CNAS şi instituţiilor cu care aceasta colaborează în proiectul SIUI. Dezvoltarea
sistemelor informatice aferente DES trebuie sa respecte standardele internaţionale şi noile
tehnologii sa fie utilizate la maxim, astfel incit :
• Sa se asigure neutralitatea tehnologica;
• Sa ofere longevitate pentru aplicaţiile existente;
• Sa favorizeze libera concurenţa între furnizorii de servicii pentru a reduce costurile de
dezvoltare, întreţinere şi mentenanţă
1.1.1.38. Cerinţe subsistem de integrare la nivel de date
• O caracteristica definitorie a sectorului medical este necesitatea unui transfer important de
informaţii între diferite tipuri de actori ai actului medical - instituţii administrative de stat,
furnizori de servicii de asistenţa medicala şi furnizorii pentru funcţii suport (de exemplu,
companiile de asigurări).
• Fiecare dintre actorii implicaţi este suficient de independent atunci când alege soluţiile IT
necesare desfăşurării funcţiilor de baza sau suport. Ca urmare a creşterii nivelului de
informatizare a sectorului medical şi stabilirea de noi sisteme informatice cu funcţii
administrative în cadrul instituţiilor de stat şi furnizorilor de servicii de asistenţa
medicala, o serie de fluxuri de informaţii sunt informatizate sau în curs de informatizare.
Sistemul informatic cel mai extins ca funcţionalitate şi număr de utilizatori din sistemul
medical este implementat de CNAS – SIUI.
• Standardizarea fluxului de date medicale şi integrarea IT se soluţionează ţinând cont de
următoarele segmente:
• semantic sau de integrare a datelor – oferă un concept unitar de clasificare a datelor şi
mecanisme standard de transfer a acestora;
• de aplicaţie sau de integrare la nivel de sistem
• de infrastructura sau interoperabilitate tehnologica - asigura interoperabilitatea
tehnologiilor utilizate, oferind accesibilitate şi protecţie a datelor.
• Deşi informatizarea medicala a fost obiectul unor eforturi privind standardizarea
schimbului de informaţii de mai multe decenii, din păcate, 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-sănătate abordarea utilizării standardelor medicale de schimb al
informaţiilor specifice trebuie determinata şi stabilita la nivelul României.
• Pentru acest proces, trebuie evaluaţi principalii actori ai procesului de standardizare
medical precum şi standardele corespunzătoare :
• HL7 – organizaţia internaţionala de standardizare, cu sediul în SUA, focalizata pe
standarde clinice. Cele mai multe dintre ţările dezvoltate (inclusiv Europene) au un rol
activ în activităţile organizaţiei. Î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 căruia participa şi colaborează
organismele naţionale de standardizare. CEN a dezvoltat familiile de standardele CEN
TC215. În 2005, un nou standard din aceasta familie ENV 13306, care defineşte
principiile eHR, a fost emis.
• ISO – principalul organism internaţional de standardizare care abordează familia de
standarde TC215 (in fapt adaptează standardele CEN pentru utilizare internaţionala,
ţinând cont de recomandările ţărilor din afara UE).
• openEHR - organizaţie non-profit care lucrează pentru crearea şi facilitarea
implementării standardelor deschise în domeniul eHR.
• Trebuie analizate următoarele aspecte legate de procesul de stabilirea standardelor
• Utilizarea XML (Extensible Markup Language) pentru crearea şi consumarea legăturilor
de transfer de date intre aplicaţii
• Pentru a defini şi standardiza formate de transfer de date, standardele naţionale vor fi
stabilite de către 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 având în vedere recomandările CEN/ISO TC2105 (inclusiv CEN ENV 13606).
în practica se vor prefera soluţii compatibile HL7 iar acolo unde este necesar şi posibil se
vor implementa cerinţele CEN/ISO. Fundamentarea acestei decizii tine de cont de
următoarele :
• standardele HL7 sunt mai uşor de implementat şi exista un suport considerabil din partea
producătorilor de soluţii
• în multe ţari (SUA, Canada, Marea Britanie etc), dezvoltarea de sisteme eHR este bazata
pe HL7
• In scopul standardizării semanticii de raportare (conţinutul de date) pentru schimbul de
date, este necesara dezvoltarea de formate de raportare specifice pentru România, care se
bazează pe modelul obiectual din CEN ENV 1306, precum şi luând în considerare
formate de raportare dezvoltate de către alte ţari.
1.1.1.39. Interfeţe expuse în exterior
• Datorita specificului sistem DES (EHR Partajat), una dintre caracteristicile importante
este aceea de interfaţare şi interoperabilitate cu sistemele complementare. în cazul nostru
principalele sisteme sau sub-sisteme informatice cu care se va interconecta sunt
următoarele:
• Alte module ale SIUI – Sistemul Informatic Unic Integrat al CNAS
• eCard – Sistemul informatic Cardul Electronic de Sănătate, componenta a SIUI
• ePrescription – Sistemul Prescripţie Electronică, componenta a SIUI
• SI spitale – sistemele existente în cadrul spitalelor (de tip EMR/EPR/EHR)
• SI medici generalişti / specialişti - sistemele existente în cabinetelor medici de familie,
generalişti / specialişti (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
• Funcţionalităţile prezentate se vor construi în faze de proiect sau ulterior în proiecte
separate.
5.12.6.Cerinţe subsistem monitorizare
• Integritatea sistemului DES se va păstra printr-o constanta monitorizare a întregului
sistem. Subsistemul de monitorizare trebuie sa deţină următoarele caracteristici:
• Sa monitorizeze toate sistemele de operare furnizate in cadrul solutiei
• Sa monitorizeze pa lângă sistemele de operare şi echipamentele active ce suporta
monitorizare, cel puţin:
• Comunicaţii reţea
• Comunicaţii SAN
• UPS
• Informaţiile de monitorizare colectate trebuiesc păstrate cel puţin un an de zile
• Informaţiile colectate trebuie afişate î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.Cerinţe subsistem audit
• Subsistemul de audit se împarte în doua zone:
• Auditare medicala. Acest subsistem are următoarele caracteristici:
• Va audita baza de date medicale pentru stabili utilizatorii conectaţi, ce activitati au
realizat, când, asupra căror date.
• Informaţiile sunt disponibile asiguratului, în portalul web, pentru a monitoriza activata
asupra datelor medicale.
• Auditare de sistem. Componentele active (sistem de operare, echipamente de comunicaţii,
sisteme de administrare, console de sistem, etc), vor raporta în acest sistem activităţile
non medicale cu următoarele caracteristici:
• Conectare utilizatori de sistem
• Modificare de status a echipamentelor (ex: modificare porturilor de comunicaţii)
5.12.8.Cerinţe subsistem salvare şi restaurare
• Subsistemul de salvare şi restaurare trebuie sa deţină următoarele caracteristici:
• Sa salveze fără a întrerupe activitatea: sisteme de operare, conţinutul bazelor de date,
codul aplicaţiilor, configuraţiile echipamentelor de comunicaţii sau a dispozitivelor
integrate. Salvarea completa a datelor se va face cel puţin odată de 24 de ore.
• Conţinutul bazelor de date se vor salva folosind reţeaua SAN pentru transferul lor în
sistem de salvare. Doar datele cu volum mic se pot transfer prin reţea Ethernet (ex: fişier
de configuraţii, loguri, etc)
• Sa raporteze activităţile efectuate
• Restaurarea completa a tuturor sistemelor trebuie sa se facă în cel mult 24 de ore de la
începerea activităţii de restaurare.
5.12.9.Cerinţe subsistem help desk
• Subsistemul de Help-Desk trebuie sa elimine situaţiile de neutilizare a sistemului
datorate diverselor incidente care pot apărea în exploatare.
• Sistemul va permite preluarea, înregistrarea (automat sau manual) şi urmărirea sesizărilor
privind funcţionarea anormala a întregului sistem informatic. Pentru a permite o
înregistrare eficienta subsistemul trebuie sa lucreze integrat funcţional cu alte sisteme de
monitorizare, management de evenimente, reţea, sisteme, etc.
• Modulul va permite ca pe parcursul derulării activităţii de Help Desk, specialiştii IT sa
poată înregistra modalităţile de rezolvare pentru incidentele frecvent întâlnite sub forma
de baza de cunoştinţe sau şabloane de incidente, astfel încât la reapariţia unui nou
incident, modalitatea de rezolvare sa fie deja înregistrata în subsistem şi sa permită un
răspuns prompt prin evitarea paşilor de rediagnosticare.
5.12.10. Cerinţe subsistem de arhivare
• Datele medicale, odată introduse în sistem, trebuie păstrate pe întreaga durata de viata
asiguratului plus 25 de ani. Durata medie de viata se considera 75 de ani. Având în
vedere evoluţiile 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 încât
a doua copie sa poate fi mutata în alta locaţie.
• 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. Cerinţe subsistem de comunicaţii
• Sistemul de comunicaţii reprezintă poarta de intrare-ieşire a informaţiilor in/din sistem.
Exista doua porţi principale:
• Comunicaţia cu spitalele. Se va realiza folosind un mediu de transport dedicat.
Construirea acestei infrastructuri nu face parte din acest proiect
• Comunicaţie cu asiguraţii. Se va realiza folosind internetul ca mediu de transport. Având
în vedere cerinţele de securitate şi confidenţialitate următoarele cerinţe sunt minime:
• Transferul datelor se va realiza numai prin protocol WEB criptat.(SSL)
• Echipamentul de comunicaţie va închide tunelul SSL, apoi va verifica conţinutul folosind
sisteme IPS/IDS. Autentificare,autorizarea şi contabilizarea utilizatorilor se va realiza în
alte echipamente IT
• In interiorul sistemului comunicaţia 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.
• Având în vedere traficul de date, sistemul de comunicaţii va balansa traficul pe
echipamente de procesare în mod activ-activ.
• Sistemul de comunicaţii va fi redundant în configuraţie activ-activ.
6. Cerinţe tehnice detaliate
Pentru asigurarea cerinţelor funcţionale şi prezentate anterior, sistemul va trebui sa includă
cel puţin componentele din diagrama de mai jos. Mediile de testare, dezvoltare şi certificare
vor conţine un subset din aceste componente.
In cele ce urmeaza sunt detaliate cerintele detaliate pe fiecare componenta:
6.1. Cerinţe hardware detaliate
o Infrastructura hardware trebuie sa fie instalata intr-o locaţie centralizata care va găzdui
toate componentele hardware necesare pentru rularea in bune condiţii a aplicaţiilor
descrise mai sus. Locatia unde se vor instala echipamentele este STS.
o Infrastructura hardware trebuie sa includă toate componentele necesare care sa satisfacă
cerinţele de performanta necesare
o Infrastructura hardware trebuie sa includă toate componentele necesare care sa satisfacă
cerinţele de disponibilitate necesare
o Sistemele si echipamentele livrate trebuie sa fie noi, neutilizate si de ultima generaţie. Ele
trebuie sa asigure gradul necesar de performanta, fiabilitate si flexibilitate fiind proiectate
si destinate pentru aplicaţii critice de tip “enterprise level”.
o Dispozitivele hardware trebuie sa fie astfel proiectate încât sa poată asigura scalabilitatea
sistemului in cazul creşterii nevoii de putere de calcul.
o Dispozitivele hardware livrate, care au in configuraţie posibilitatea de upgrade pentru
anumite componente, trebuie astfel configurate încât upgrade-ul sa se facă fără pierderea
de dispozitive existente.
o Dispozitivele hardware trebuie sa fie compatibile cu caracteristicile reţelei electrice din
România astfel încât sa nu existe probleme la conectarea acestora la reţeaua electrica.
o Ofertantul va prezenta specificaţiile tehnice privind organizarea si amenajarea camerei
serverelor (dataroom / datacenter) in care se vor instala echipamentele astfel încât sa fie
asigurate condiţiile operaţionale optime pentru funcţionarea acestora.
o Ofertantul va preciza care este greutatea totala a echipamentelor livrate si dimensiunile
fizice ale acestora pentru a se putea verifica siguranţa instalării in locaţia beneficiarului
o Ofertantul va preciza in oferta care este puterea totala consumata de echipamentele livrate
precum si caracteristicile de climatizare/ventilaţie necesare, astfel încât solicitantul sa
poată asigura acest necesar in locaţia unde urmează a fi instalate echipamentele.
o Ofertanţii vor avea în vedere ca toate cerinţele si caracteristicile hardware solicitate au un
caracter minim si obligatoriu.
o Toate aceste cerinţe sunt dezvoltate la nivel de detaliu in cadrul documentaţiei de
atribuire. In acelaşi timp cerinţele nu sunt limitative ofertanţii având libertatea de a le
dezvolta si extinde conform soluţiei pe care o au in vedere sa o propună si care trebuie sa
îndeplinească în totalitate cerinţele solicitantului.
o Ofertanţii au obligativitatea de include in propunerea tehnica si comerciala toate
componentele hardware, software si de servicii pe care le considera necesare astfel încât
aceasta sa fie completa si integrata, chiar daca aceste componente nu sunt individualizate
sau solicitate explicit in documentaţia 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 soluţiei. Infrastructura de virtualizare trebuie sa permită alocarea dinamica a
resurselor (CPU, memorie, sisteme I/O), fără a întrerupe sistemul virtual din funcţionare
si fără a avea alt efect decât cel scontat de cererea de modificare a resurselor. Sistemul de
virtualizare trebuie sa separe sistemele virtuale astfel încât sa nu existe posibilitatea de
transfer de informaţii de la un sistem virtual la altul.
o Infrastructura logica va conţine patru zone:
Zona de dezvoltare. Aceasta zona este folosita pentru dezvoltarea tuturor
funcţionalităţilor sistemului atât în faza de implementare, cat si ulterior pentru a
dezvolta alte funcţionalităţi
Zona de testare. Aceasta zona este folosita pentru testarea funcţionalităţilor
dezvoltate.
Zona de producţie. Aceasta zona este folosita pentru utilizarea sistemului in mediu
real.
Zona de certificare. Aceasta zona este similara în funcţionalităţi cu zona de producţie,
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 funcţionalităţile de integrare cu DES (transmiterea datelor,
respectarea standardelor de comunicare si performanta, validarea corecta a
datelor de transmis/primit, etc)
Cerinţele hardware ce trebuie îndeplinite de soluţia propusa corespund următoarelor
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 comunicaţii local (intre sistemele si subsistemele propuse in cadrul
ofertei solicitate)
6.1.1. Cerinţe minime obligatorii pentru sistem de procesare a
datelor (2 bucăţi)
• Arhitectura sistemului trebuie sa aibă integrate funcţionalităţi de tip Capacity on Demand
in ceea ce priveşte resursele de calcul de tip core-uri/procesoare si memorie interna.
Aceste funcţionalităţi trebuie sa permită alocarea dinamica a resurselor, in mod temporar
sau permanent, in funcţie de cerinţele concrete ale aplicaţiilor ce rulează pe sistem. Pentru
asigurarea unei capacitaţi de calcul de rezerva disponibile pentru necesitaţi viitoare din
punct de vedere al volumului de prelucrări se vor activa doar maximum 75% din numărul
de core-uri si memoria interna instalate fizic in configuraţia ofertata a sistemului
• Sistemul trebuie sa aibă instalate si active un număr de core-uri care sa asigure puterea de
calcul si gradul de redundanta necesare pentru cerinţele soluţiei. Ţinând seama de nivelul
tehnologic actual si de caracterul critic din punct de vedere performanta, disponibilitate si
scalabilitate dictate de acoperirea naţionala a soluţiei, numărul minim de core-uri
instalabile ( posibil a se instala ) fizic in configuraţia maximala a sistemului ofertat nu
trebuie sa fie mai mic decât 128 iar frecventa de ceas a core-urilor nu trebuie sa fie mai
mica decât 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 aplicaţii ( workload ), sau de rezerva ( spare ). Se va
prezenta o justificare a dimensionării 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 puţin 8 GB RAM / core. Aceasta
proporţie se va păstra si pentru memoria si core-urile active incluse in configuraţia
propusa. Memoria interna trebuie protejata prin mecanisme specializate de protecţie a
datelor care vor trebui detaliate in oferta.
• Sistemul trebuie sa aibă instalate interfeţe dedicate de criptare a datelor si accelerare a
traficului de date de tip SSL. Numărul acestor interfeţe trebuie calculat astfel încât sa se
asigure nivelul de performanta si redundanta ale soluţiei. Se va prezenta o justificare a
dimensionării 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.. Soluţia oferita trebuie sa dispună de certificări
standard de securitate a informaţiilor care se vor menţiona si include in oferta.
• Arhitectura hardware interna a sistemului propus trebuie sa fie redundanta, justificându-
se si detaliindu-se acest lucru. Ea trebuie sa permită funcţionarea neîntrerupta a sistemului
in situaţii de defecţiune a unei componente interne fără degradare de performanta
Sistemul trebuie sa fie echipat cu interfeţe 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 menţionate va dispune de porturi
I/O fizic separate. Numărul acestor porturi trebuie calculat astfel încât sa se asigure nivelul de
performanta si redundanta ale soluţiei. Se va prezenta o justificare a dimensionării propuse.
Sistemul trebuie sa aibă suport pentru partiţionarea fizică şi/sau logică a resurselor de calcul
(core-uri, memorie interna si interfeţe I/O). Partiţionarea si virtualizarea resurselor de calcul
trebuie sa garanteze separarea deplina a datelor intre partiţiile definite in cadrul aceleiaşi
maşini fizice. Se va justifica modul in care soluţia propusa garantează aceasta separare.
Soluţia trebuie sa permită rularea in paralel in partiţii distincte a aplicaţiilor (workload) de
tipuri distincte (baze de date, aplicaţii Web etc) fără afectarea performantei si funcţionalităţii
globale a sistemului şi folosind medii/sisteme de operare eterogene
Soluţia 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 funcţionalitate.
Modulul software sau sistemul de operare cu rol de hipervizor (management de virtualizare)
trebuie sa ruleze nativ pe arhitecturi 64 bit
6.1.2. Cerinţe minime obligatorii pentru infrastructura de
stocare (2 bucăţi):
Arhitectura
Sistemul trebuie sa dispună de o arhitectura
redundanta care sa ofere mecanisme de „failover”
automat in situaţia defectării oricărei componente din
sistem.
Echipamentul trebuie sa permită configurarea in aşa
fel încât defectarea unui controller sau a unui
subsistem de discuri sa nu afecteze continuitatea
operării 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 potenţial
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.
Capacitate disponibila
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 operării 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
cerintele aplicatiilor.
Conectivitate
Numărul 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 potenţial
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 funcţionalităţi. Nu se
accepta soluţii care asigura multiplicarea unui număr
inferior de porturi disponibile la nivel de
controller/sistem de stocare prin intermediul
echipamentelor de tip switch externe.
Copii volume de date
Sistemul trebuie sa asigure servicii de copiere
instantanee (SnapShot) a volumelor de date in
configuraţia propusa pentru toata capacitatea
disponibila in interiorul sistemului de stocare.
Replicare date
Sistemul trebuie sa asigure servicii de copiere a
datelor de tip sincron si asincron disponibile pentru
întreaga capacitate de stocare utilizabila. Toate aceste
funcţionalităţi trebuie sa fie active in soluţia propusa.
Provizionare
In configuraţia propusa echipamentul trebuie sa
permită utilizarea mecanismelor de provizionare
(Thin Provisioning) a capacitaţii alocate unui server
permiţând in acest fel alocarea unor capacitaţi mai
mari decât capacitatea fizica utilizata propriu-zis.
Sistemul trebuie sa permită redimensionarea
volumelor logice in mod „online” indiferent daca
acestea au fost alocate prin intermediul mecanismelor
de tip „thin provisioning” sau nu.
Monitorizare, management si
securitate date
Echipamentul trebuie livrat împreuna cu o aplicaţie de
management si monitorizare cu funcţionalităţile
descrise in continuare.
Aplicaţia trebuie sa permită managementul mai
multor sisteme de stocare de acelaşi tip in mod
concurent si sa asigure lucrul atât in mod grafic (GUI)
cat si in mod linie de comanda (CLI).
Aplicaţia trebuie sa ofere posibilitatea monitorizării
datelor legate de performanta atât in timp real cat si
pe baza informaţiilor istorice.
Aplicaţia de monitorizare trebuie sa permită
vizualizarea informaţiilor la nivel de volum logic,
„host”, interfaţa fizica precum si pentru sistemele
intre care se realizează replicarea de date. La nivelul
fiecărei categorii aplicaţia trebuie sa furnizeze
informaţiile intr-un mod granular vis-a-vis de
subsistemele echipamentului (performanta operaţii -
IOPS, performanta transfer date - Mb/s, nivel de
utilizare a memoriei cache, „hit rate” pentru citiri si
scrieri, eficienta la scriere, încărcarea liniilor de
replicare date, etc)
Posibilitatea de a crea grupuri de administratori cu
nivele de acces diferite oferind posibilitatea garantării
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
Sisteme de operare suportate si
certificate; alte certificari
Microsoft Windows 2003/2008, Linux (minimum
distribuţiile 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
performanta ( benchmark ) certificat public tip SPC-1
sau/si SPC-2
6.1.3. Cerinţe minime obligatorii pentru infrastructura de biblioteca
de benzi (1 bucata):
Tip echipament
Sistem de salvare si restaurare a datelor pe benzi
magnetice de tip „tape library” din clasa „enterprise”
folosita in arhitecturi cu cerinţe critice din punct de
vedere performanta, scalabilitate si fiabilitate
Descriere generala Echipamentul trebuie să permită următoarele
funcţionalităţi:
• 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
cartuşelor. 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
Configuraţia propusă trebuie să includă un cititor de
cod de bare
Mod de accesPosibilitate de acces la cartuşe in modurile secvenţial
si/sau aleator.
Disponibilitate
• Adăugarea sau înlocuirea unităţilor de citire /
scriere şi a surselor de alimentare cu energie
electrica trebuie sa poată fi făcuta „on line /
hotswap”.
• Capabilitati de tip „failover” la nivel de date si
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 )
Scalabilitate număr de unităţi
de citire
In configuraţie maxima echipamentul trebuie sa
permită instalarea a unui număr minim de unităţi de
citire/scriere de cel puţin 10 ori mai mare ca acela
instalat in configuraţia iniţială.
Scalabilitate număr maxim de
casete
In configuraţie maxima echipamentul trebuie sa
permită instalarea a unui număr minim de cartuşe in
sloturile disponibile de cel puţin 50 ori mai mare ca
acela instalat in configuraţia iniţiala .
Sistem de alimentare cu
energie
Redundant cu minim 2 surse de alimentare cu energie
electrica „hot-swap”
Tehnologii de inscripţionareSuport pentru tehnologia Ultrium LTO5 sau
echivalent si minimum o generaţie anterioara
Tipuri de unităţi de banda
suportate
Minimum unităţi de citire/scriere in tehnologie
Ultrium LTO5 sau echivalent
Tehnologii de protecţie a Suport asigurat pentru de criptarea datelor stocate pe
datelor la nivel de casete
cartuşe precum si suport pentru tehnologia WORM
(Write Once Read Many).
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
Upgrade capacitate de stocare
Posibilitatea de a realiza upgrade-ul capacitaţii de
stocare la nivel unitate fizica (frame) prin coduri
software pentru activarea sloturilor fizic existente dar
inactive
Virtualizare
Echipamentul trebuie sa permită definirea de librarii
logice ( inclusiv in mod dinamic, in faza de definire
sau realocare ulterioara de resurse ) in cadrul aceluiaşi
sistem fizic, separate din punct de vedere al unităţilor
de citire/scriere folosite si a sistemelor „host” care le
accesează
Sisteme de operare suportate
Microsoft Windows 2003/2008, Linux (minimum
distribuţiile Red Hat si Novell SUSE) si UNIX
(minimum HP-UX, Solaris si AIX).
Upgrade tehnologie
Arhitectura sistemului trebuie sa permită folosirea de
unităţi de citire/scriere cu tehnologii diferite sau
generaţii distincte ale aceleiaşi tehnologii.
Conectare reţea SAN
Conectarea unităţilor de citire/scriere în reţeaua SAN
trebuie realizata prin interfeţe Fibre Channel minim 4
Gb/s
Management Managementul echipamentului şi a funcţionalităţilor
acestuia trebuie sa asigure suport pentru următoarele
interfeţe si standarde: Web, SNMP, SMI-S. Se vor
livra toate componentele hardware si software
necesare pentru realizarea tuturor funcţionalităţilor de
management.
Opţiuni si accesorii
Echipamentul trebuie livrat împreuna cu toate
accesoriile necesare bunei funcţionari si interconectări
cu celelalte elemente ale soluţiei propuse.
Configuraţia livrata
Minim 8 unităţi de citire/scriere in tehnologie Ultrium
LTO 5, cu capabilitate de failover intre unitati pentru
fluxurile de date si control in cazul defectarii unei
unitati
Minim 200 de sloturi active la nivelul sistemului livrat
Minim 200 de cartuşe de tip Ultrium LTO 5 sau
echivalent cu cod de bare
Consola de management dedicata echipamentului
trebuie inclusa in configuraţia propusa.
6.1.4. Cerinţe minime obligatorii pentru infrastructura de SAN
(2 bucăţi):
Tip echipament
Echipament de tip „director” utilizabil in sisteme cu
cerinţe critice din punct de vedere performanta,
scalabilitate si fiabilitate
Modul de control (supervizor)
In configuraţia propusa echipamentul trebuie sa fie
echipat cu cel puţin doua carduri dedicate pentru
routarea interna a pachetelor de date cat si pentru
managementul echipamentului.
Aceste subansamble trebuie sa funcţioneze in regim
redundant si sa fie capabile sa preia fără downtime in
caz de defectare a unuia dintre ele încărcarea cardului
defect.
Tehnologie
Echipamentul trebuie sa permită instalarea cardurilor
de extensie care sa asigure cel puţin următoarele
tehnologii de conectare: FC ( minim 8 Gb/s), FCIP,
FCoE si FICON .
Scalabilitate
In configuraţie maximala echipamentul trebuie sa
permită instalarea unui număr de cel puţin 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)
asigurând in acest mod scalarea la un număr de cel
puţin 480 de porturi consolidate intr-un singura reţea
fizica (SAN fabric) . Extinderea numărului de porturi
trebuie sa poată fi realizata „online” prin intermediul
cardurilor de extensie. Adăugarea cardurilor noi
trebuie sa poată fi realizata „on line” fără întreruperea
traficului de producţie.
Porturi instalate
In configuraţia livrata echipamentul trebuie sa fie
echipat cu cel puţin 64 de porturi FC distribuite pe
minimum 2 carduri. Fiecare port trebuie sa fie echipat
cu adaptoare electro-optice (SFP) de minim 8 Gb/s.
Management
Managementul echipamentului trebuie sa poată fi
realizat prin intermediul unei reţele Ethernet atât in
mod grafic (GUI) cat si prin linie de comanda (CLI).
Funcţii avansate Configuraţia sistemului livrat trebuie sa cuprindă
componentele software si hardware care sa asigure
următoarele funcţionalităţi:
Administrarea, configurarea si mentenanţă la
nivel de echipament si SAN
Partiţionarea SAN in grupuri logice (zone)
pentru controlul / restricţionarea
comunicaţiilor si aplicarea anumitor
politici in acest sens pentru membrii zonei
respective
Posibilitatea de implementare de reţele
virtuale (virtual fabrics) peste reţeaua
fizica. Fiecare reţea virtuala trebuie sa
poată conţine switch-uri logice SAN
precum si propriile cai de transfer date si
control/management
Capabilitatea de definire de nivele de
performanta si calitate a comunicaţiilor
(Quality of Services – QoS) astfel încât sa
se asigure lărgime de banda necesara
comunicaţiilor critice chiar in condiţii de
reţele congestionate
Posibilitatea de analiza pe întreaga cale de
comunicaţie (end-to-end) a nivelului de
performanta si gradului de utilizare a
lărgimii de banda alocate
Capabilitatea de monitorizare permanenta a
funcţionarii pentru detectarea potenţialelor
probleme si defecte si avertizarea
administratorului înainte de apariţia
propriu-zisa a defectelor
Opţiuni si accesorii
Echipamentul trebuie livrat cu surse de alimentare si
ventilatoare redundante precum si cu un număr de
cabluri FC de minim 5 m lungime si conectori LC la
ambele capete. Numărul de cabluri livrate trebuie sa
fie egal cel puţin cu numărul de porturi FC active
(cu SFP) din configuraţia propusa a echipamentului.
6.1.5. Cerinţe comunicaţii
Toate cerinţele de mai jos sunt minime.
In condiţiile în care specificaţiile 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 multifuncţional – 2 bucăţi.
Specificaţiile tehnice pentru Switch multifuncţional sunt:
• Construcţia switch-ului sa aibă capacitatea fizica minima de 9 slot-uri pentru cartele
funcţionale.
• Oferta trebuie sa aibă inclusa cea mai noua versiune de Sistem de Operare testata şi
recomandata de producător, împreuna cu serviciul de update şi upgrade de versiune pe
toata perioada de garanţie a echipamentului
• Cardurile cu procesor trebuie sa poată funcţiona î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 comutaţie 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 producătorul
switch-ului iar fluxul de aer al switch-ului trebuie sa fie constructiv faţă-in-spate-out , fără
a se utiliza deflectoare.
• Şasiul trebuie sa aibă cel puţin magistrala de control dublata intern.
• Înălţimea 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 Număr minim de rute IPV4 1.000.000;
o Număr 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 utilizării virtualizării.
o Memorie minim 1GB
o Software adecvat pentru realizarea virtualizării 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 capabilităţi de 1.000.000 rute IPv4 şi
în număr de 256.000 instanţe 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 capabilităţi de 1.000.000 rute IPv4 şi în număr de
256.000 instanţe 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 următoarele performante:
o Să fie hotswap – scoaterea acestuia sa nu afecteze funcţionarea switch-ului
o In mod inline sa poată urmări trafic de minim 500MBps, minim 5000 sesiuni pe
secunda, minim 50.000 sesiuni concurente.
o Sa permită conectarea a 8 card-uri în acelaşi switch pentru creştere pana la 4GBps
a traficului urmărit în mod inline.
o Accesul la date sa se facă intern, prin capturarea cu access-list-uri de VLAN
o update-ului de semnături pentru IDS pentru o perioada egala cu perioada de
garanţie a echipamentului. Solicitam ca ofertanţii sa includă cea mai noua
versiune de Sistem de Operare testata şi recomandata de producător, împreuna cu
serviciul de update şi upgrade de versiune pe toata perioada de garanţie a
echipamentului
• 1*Card dedicat de content switching cu următoarele performante :
o Pachete pe secunda procesate – minim 6.5 milioane
o Număr de partiţii virtuale suportat – minim 20
o Trafic SSL suportat – min 6 Gbps
o Tranzacţii pe secunda SSL – min 30,000
o Realizează content switching în condiţiile menţinerii unui număr de 4.000.000
conexiuni;
o Număr minim de servere virtuale suportate – 4000;
• 1*Card dedicat de firewall cu următoarele performante:
o Trafic suportat = minim 6Gbps;
o Sa poată fi instalat în mod redundant în switch minim 2 module;
o Sa utilizeze mecanism de protecţie de tip adaptive security algorithm (ASA);
• Montabil în Rack;
• Capabilităţi 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 reţelei de comunicaţii este o componenta a arhitecturii sistemului informatic.
Sistemul de comunicaţii este construit astfel încât sa răspundă la cerinţele sistemului general.
Sistemul de comunicaţii de tip LAN trebuie furnizat şi trebuie sa permită:
interconectarea echipamentelor solicitate
reţeaua 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 reţea, care sunt necesare
pentru funcţionarea corecta şi sigura a soluţiei
viteza de interconectare intre switch-uri de minim 10Gbps
conexiuni redundante de la serverele cu interfeţe de minim 1Gbps
Reţele şi comunicaţii software:
o Toate elementele de reţea trebuie sa fie administrate (atât la nivel local şi la distanţa) de
către o soluţie de management compatibila cu componente de reţea oferite pentru
infrastructura
o Ofertantul va fi obligat sa ofere aceasta soluţie de management al reţelei, cu numărul
necesar de licenţe pentru întreaga soluţie.
o Soluţia de management de reţea este obligatoriu sa aibă o componenta de
monitorizare/alarmare cu reguli de notificare via mail/SMS ce pot fi definite de utilizator.
Securitate reţea
Conexiunile externe:
o trebuie protejate de cel puţin cate un firewall. Este obligatoriu ca firewall-ul sa fie
redundant cel puţin în modul activ-standby.
o arhitectura sistemului trebuie sa fie echipata cu cate un dispozitiv inline IPS / IDS,
senzori care vor fi plasaţi pe (cel puţin) segmentul de reţea conectat la interfaţa interna(e)
a firewall-ului ce deserveşte conexiunile externe ale sistemului. Prin conexiuni externe
înţelegem legăturile cu alte reţele, de genul internet sau reţea WAN
o fişierele de log ale IPS / IDS trebuie sa fie arhivate pe un sistem de stocare şi trebuie sa
fie disponibile minimum 3 ani.
6.2. Cerinţe software detaliate
6.2.1. Monitorizare sisteme şi aplicaţii
Descriere
Sistemul trebuie sa ofere capabilităţi de monitorizare şi management specifice diverselor
nivele ale unui mediu IT complex: sisteme, aplicaţii, infrastructura de tip middleware, ajutând
administratorii sa păstreze performanta şi disponibilitatea aplicaţiilor. Sistemul trebuie sa
ofere suport pentru optimizarea nivelelor de servicii şi sa controleze costurile de operare a
aplicaţiilor.
1.1.1.40. Subsistem monitorizare la nivelul sistemelor
Cerinţe
Soluţia de monitorizare a sistemelor trebuie sa ofere următoarele capabilităţi:
• 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 puţin î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 funcţie 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 informaţii istorice, agregate, despre:
• Disponibilitatea sistemelor, cu rapoarte detaliate pe:
Ore
Zile
Săptămâni
• Capacitatea utilizata a sistemelor, cu rapoarte detaliate pe:
Ore
Zile
Săptămâni
• Performanta sistemelor, cu rapoarte detaliate pe:
Ore
Zile
Săptămâni
• Interfaţa coerenta pe toate platformele şi în toate funcţiile de administrare
• Modele de monitorizare şi alertare predefinite pentru toate sistemele şi aplicaţiile
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
staţiile 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 informaţiilor (evenimente) intr-o baza de date pentru analiza şi raportare
ulterioara; modulul de raportare va fi inclus în produs, fără costuri adiţionale; de asemenea
baza de date în care se va păstra istoricul va fi inclusa în produsul de monitorizare fără cerinţe
de licenţiere adiţionale
• Modele de monitorizare pentru toate sistemele şi aplicaţiile suportate
• Sa permită activarea/dezactivarea monitorizării aplicaţiilor fără întreruperea
funcţionarii acestora
• Aplicaţia trebuie sa ofere facilitatea de definire de fluxuri de lucru, care sa ofere
metode standard de adresare a problemelor detectate de către agenţi pe sistemele
monitorizate; aplicaţia de definire a fluxurilor de lucru va avea o interfaţa grafica, în care
definirea fluxurilor sa se realizeze facil (de ex. drag & drop)
• Emiterea de alerte: soluţia trebuie sa poată emite alerte vizuale şi auditive
• Prezentarea parametrilor monitorizaţi se va face în timp real, în mod grafic intuitiv, cu
posibilitatea de a modifica tipul graficului (bar, pie, chart, etc)
• Acţiuni corective: soluţia trebuie sa se poată configura astfel încât sa execute acţiuni
corective automate (fără intervenţia administratorilor) în cazul detectării de erori sau în cazul
degradării performantelor.
• Sa ofere capabilităţi de pornire/oprire a proceselor / aplicaţiilor de pe serverele
monitorizare
• Agenţii pentru fiecare sistem nu trebuie sa interfereze cu operaţiile normale ale
sistemului pentru a nu afecta performantele acestuia şi trebuie sa utilizeze la minimum
resursele sistemului pe care sunt instalaţi• 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 agenţi dedicaţi tehnologiei monitorizate) catre un
modul specializat de corelare a evenimentelor, cu care functiile de monitorizare sa se
integreze nativ.
• Posibilitatea de a defini mai mulţi administratori / utilizatori cu roluri diferite.
• Soluţia trebuie sa ofere un motor avansat de lucru cu reguli/politici care sa permită
administratorilor exact ce acţiuni trebuie luate şi când;
• Soluţia trebuie sa se poată integra cel puţin cu următoarele surse de date:
Instrumente cu funcţii de business service management, management evenimente,
CMDB, monitorizare, gestiune elemente
Interfeţe (industry-standard) Web Services, Extensible Markup Language (XML),
Simple Network Management Protocol (SNMP), Lightweight Directory Access Protocol
(LDAP)
Alte aplicaţii via command-line, TCP/IP sockets, flat-file exports, e-mail
• Soluţia trebuie sa colecteze şi sa prezinte datele generate în rapoarte
• Soluţia trebuie sa preia şi sa prelucreze evenimentele în timp real
• Soluţia trebuie sa ofere un set de rapoarte predefinite ca şi “best practices” (ex.
Grafice de disponibilitate, etc.)
• Soluţia trebuie sa ofere vizualizare uşoara a rapoartelor generate, accesibile printr-o
integrata grafica WEB
• Soluţia trebuie sa suporte salvarea rapoartelor cel puţin în următoarele formate:
o CSV
o HTML
o PDF
1.1.1.41. Subsistem monitorizare aplicaţii şi infrastructura de
tip middleware
Soluţia de monitorizare a aplicaţiilor trebuie sa ofere următoarele capabilităţi:
• Sa se integreze nativ, în aceeaşi interfaţa cu aplicaţia 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 apariţiei acestora
• Sa ofere capabilităţi de monitorizare configurabile, cu posibilitatea de a seta praguri
pentru avertizări şi alerte critice
• Sa aibă posibilitatea de a oferi grafice de performanţa în timp real
• Sa ofere posibilitatea configurării sistemului de management astfel încât sa execute
acţiuni automate, fără intervenţia administratorilor, în momentul apariţiei anumitor
evenimente
• Sa integreze diferite utilităţi şi aplicaţii pentru operarea eficienta a infrastructurii
oferite
• Sa ofere administrare centralizata a elementelor de infrastructura şi a aplicaţiilor
pentru topologii complexe de servere de aplicaţii (instanţe multiple, clustere de servere de
aplicaţii)
• Sa prezinte vizual toate componente instalate şi inter-dependenţele dintre acestea
• Sa permită monitorizarea în timp real a serverelor de aplicaţii compatibile cu
standardul Java 2 Enterprise Edition (J2EE) sau echivalent; capabilităţi de colectare a
metricilor de execuţie pentru următoarele tipuri de entităţi:
o JavaServlets;
o Enterprise Java Beans (EJB);
o tranzacţii;
o conexiuni la surse de date;
o cozi de mesaje;
o servicii web
• Sa permită agregarea şi prezentarea informaţiilor corespunzătoare execuţiei fluxurilor şi
serviciilor:
o număr de instanţe:
• în execuţie
• terminate cu succes
• terminate cu eroare
• timp mediu de procesare pentru instanţele de procese sincrone şi asincrone
o rapoarte predefinite pentru identificarea:
• instanţelor cele mai consumatoare de resurse
• instanţelor în aşteptare
• activităţilor de proces cele mai consumatoare de resurse
• Sa permită monitorizarea aplicaţiilor 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 monitorizării serverelor de mesagerie Microsoft Exchange şi
IBM Domino Server
• Sa permită monitorizarea de maşini virtuale (de ex. VMware, Citrix, MS Virtual
Server)
• Sa ofere posibilitatea monitorizării serverelor de baze de date (de ex. Oracle,
Microsoft SQL Server, IBM DB2) sa ofere informaţii despre:
o componente baze de date
o comenzi SQL eşuate
o cereri acces exclusiv al aplicaţiilor (locks)
o disponibilitate tablespace
o performante SQL text
o utilizare cache (bufferhits)
o conexiuni folosite
o activitate fir de execuţie (thread)
o blocaje acces concurent (deadlocks)
o acces concurenţial la date (contention)
o erori I/O
o avertizări spaţiu liber
o praguri cache
o avertizări acces exclusiv (locks)
o timpi de aşteptare
o procentul de comenzi SQL eşuate
• sa prezinte datele colectate sub forma de tablouri de bord sugestive cu posibilitatea de
selectare a perioadei de monitorizare dorite
• Colectarea metricilor de execuţie se va face prin tehnologicii de tip agent cu impact
minim asupra performanţei sistemelor monitorizate
• Sa permită activarea/dezactivarea monitorizării aplicaţiilor fără întreruperea
funcţionarii acestora
• Sa permită monitorizarea aplicaţiilor fără modificarea acestora
• Sa includă rapoarte predefinite pentru identificarea cererilor client cele mai
consumatoare de resurse
• Sa includă rapoarte predefinite pentru identificarea componentelor aplicaţiei cele mai
consumatoare de resurse
• Sa ofere capabilitatea de a vizualiza atât date în timp real cat şi date istorice pentru
orice sistem prin intermediul consolei web şi a interfeţei GUI. Aplicaţia trebuie sa ofere un
modul de raportare, inclus în pachet (fără cerinţe de licenţiere adiţionala); modulul de
raportare va pune la dispoziţie un set de rapoarte predefinite cat şi o aplicaţie cu ajutorul
căreia administratorii sistemului vor putea construi rapoarte,în mod grafic, intuitiv, utilizând
un GUI.
• Sa ofere posibilitatea monitorizării platformelor de integrare, accelerare şi securitate
SOA, oferind informaţii cel puţin în următoarele domenii:
o Gestiune servicii ale serverelor de aplicaţie
o Sumar al erorilor, la nivel de operaţiune
o Configuraţii pentru primitive de mediere
o Mesaje primite
o Sumar al mesajelor, conţinând dimensiunea medie în octeţi a mesajelor, după port,
numele operaţiunii, tip (entitate solicitanta sau furnizor)
o Fluxuri operaţionale
o Fluxuri operaţionale pentru servere de aplicaţii
o Fluxuri operaţionale pentru operaţiune selectata, prin agregarea la nivel de
combinaţie port serviciu – operaţiune
o Sumar de performanta
o Sumar de performanta per identitate a entităţii solicitante
o Identităţi ale entităţilor solicitante pentru o anumita operaţie selectata, ceea ce va
permite examinarea metricilor după identitatea entităţii solicitante pentru o
pereche specifica port serviciu – operaţiune.
o Posibilitatea configurării pentru monitorizarea identităţii entităţii solicitante care
sa creeze şi gestioneze lista tuturor identităţilor de entităţi solicitante ce vor fi
monitorizate.
o Sumar pe grupuri de servicii, după criteriul apartenenţei la aceeaşi funcţionalitate
(sau aplicaţie).
6.2.2. Help Desk (Sistem suport utilizatori)
Descriere
Modulul de Help-Desk trebuie sa elimine situaţiile de neutilizare a sistemului datorate
diverselor incidente care pot apărea în exploatare.
Sistemul va permite preluarea, înregistrarea (automat sau manual) şi urmărirea sesizărilor
privind funcţionarea anormala a întregului sistem informatic. Pentru a permite o înregistrare
eficienta modulul trebuie sa lucreze integrat funcţional cu alte sisteme de monitorizare,
management de evenimente, reţea, sisteme, etc.
Modulul va permite ca pe parcursul derulării activităţi de Help Desk, specialiştii IT sa poată
înregistra modalităţile de rezolvare pentru incidentele frecvent întâlnite sub forma de baza de
cunoştinţe sau şabloane de incidente, astfel încât la reapariţia unui nou incident, modalitatea
de rezolvare sa fie deja înregistrata în subsistem şi sa permită un răspuns prompt pentru prin
evitarea paşilor de rediagnosticare.
Cerinţe
• Soluţia va fi conforma standardului ITIL V3.
• Aplicaţia va fi accesibila prin interfaţa web securizata;
• Aplicaţia trebuie sa includă instrumente de control acces/declarare a drepturilor la
nivel de utilizator şi grupuri de utilizatori acordate în concordanta cu atribuţiile şi
responsabilităţile fiecăruia.
• Aplicaţia va beneficia de un mecanism de auditare astfel încât orice operaţiune
efectuata în sistem sa poată fi urmărita;
• Va dispune de un mecanism pentru definirea şi validarea unui flux de lucru unitar
conform standardului ITIL V3 dar şi conform proceselor organizaţiei pentru tratarea
incidentelor.
• Va permite administrarea fluxurilor de lucru în interfaţa grafica web în mod „drag-
and-drop” cat şi în mod text prin constructor de expresii. Modulul grafic trebuie sa pună la
dispoziţia administratorului hărţile fluxurilor de lucru.
• Va permite administrarea structurii aplicaţiei şi a bazei de date în interfaţa grafica web
(application and database designer)
• Va permite definirea de şabloane ale activităţilor tipice de management al incidentelor
• Va permite crearea unei scheme de utilizatori bazate pe grupuri şi roluri
• Va oferi posibilitatea de alocare a responsabilităţilor în rezolvarea incidentelor în
funcţie de organigrama
• Va oferi posibilitatea de înregistrare şi de transferare manuala sau automata a
tichetelor
• Va oferi posibilitatea de planificare şi urmărire a activităţilor necesare în vederea
rezolvării incidentelor
• Va oferi posibilitatea de discuţie on-line pe baza incidentelor
• Va oferi posibilitatea de evaluare a rezolvării incidentelor prin sondaje (survey) cerere
de aprobare de la utilizator pentru rezolvare sau de la nivelul superior de suport.
• Va feri posibilitatea înregistrării acţiunilor efectuate şi a soluţiilor găsite în vederea
păstrării istoricului şi a constituirii bazei de cunoştinţe (Knowledge Base & Incident
Template)
• Va oferi posibilitatea de alocare a incidentelor pe echipamente sau componente ale
echipamentelor
• Va oferi posibilitatea de urmărire a timpilor de răspuns şi de rezolvare a incidentelor
prin grafice sau alerte (indici de performanta – KPIs (Key Performance Indicators) &
SLAs )Service Level Agreement
• Va oferi posibilitatea tratării diferite a incidentelor în funcţie de categoria la care se
refera (hardware, software, reţea) şi de impactul acestora asupra funcţionarii organizaţiei
• Va oferi posibilitatea menţinerii şi regăsirii informaţiilor despre modul de rezolvare a
diverselor tipuri de incidente
• Va permite stocarea informaţiilor necesare în vederea realizării 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
Soluţia de backup, centralizare şi restaurare trebuie sa asigure o protecţie eficienta a datelor
împotriva erorilor prin stocarea copiilor de salvare şi arhivare pe medii de stocare în regim
“offline”. Aceasta trebuie sa fie scalabilă, putând asigura protecţia 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 reţelei.
Cerinţe
• Soluţia trebuie sa asigure salvarea şi arhivarea datelor, restaurarea, şi extragerea
acestora.
• Aplicaţia trebuie sa permită efectuarea de operaţiuni back-up doar pentru fişierele
care au suferit schimbări de la ultimul back-up şi pentru fişierele nou create. Pentru sisteme
de fişiere FAT/NTFS, soluţia trebuie sa fie capabila de a salva doar porţiunea modificata a
unui fişier.
• Administrarea soluţiei de back-up trebuie sa se poată realiza prin intermediul unei
interfeţe web care sa poată gestiona mai multe servere de back-up, indiferent de platforma pe
care rulează acestea.
• Clienţii de back-up trebuie sa fie accesibili prin intermediul unei interfeţe web, astfel
încât administratorii sa aibă la dispoziţie un mecanism facil de operare de la distanta.
• Soluţia 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.
• Soluţia de back-up trebuie sa asigure copii de siguranţa pentru mai multe versiuni ale
aceluiaşi fişier, astfel încât sa ofere posibilitatea restaurărilor selective.
• Soluţia trebuie sa fie capabila de a şterge copiile de siguranţa ale versiunilor expirate
ale fişierelor (in conformitate cu politica de back-up) astfel încât sa se elibereze spaţiu pe
mediile de stocare (benzi).
• In cazul în care în timpul procesului de back-up/restore conexiunea dintre client şi
server se întrerupe, soluţia trebuie sa fie capabila de a relua acest proces din momentul
întreruperii şi nu de la început.
• Soluţia trebuie sa includă mecanisme de duplicare a datelor atât la nivel de client cat
şi la nivel de server.
• Soluţia trebuie sa includă mecanisme de salvare/restaurare de tip LAN-free.
• Soluţia trebuie sa includă mecanisme de salvare/restaurare de tip online (fără
întreruperea serviciilor) pentru baze de date.
• Soluţia trebuie sa fie capabila de criptarea datelor transmise de la client la server în
timpul procesului de backup/restore.
• Aplicaţia trebuie sa permită setarea perioadelor de păstrare a datelor salvate, în funcţie
de timpul la care a fost realizat backup-ul.
• Aplicaţia trebuie sa genereze rapoarte referitoare la operaţiunile de salvare / restaurare
şi sa ofere posibilitatea de a trimite aceste rapoarte prin mecanisme e-mail.
• Soluţia trebuie sa fie compatibila (atât la nivel de server cat şi la nivel de agenţi) cu
următoarele platforme: Windows Server (2003 & 2008 Std, Advanced), Linux (RedHat
RHEL şi Suse SLES), AIX şi Solaris.
• Soluţia trebuie sa suporte o mare varietate de medii de stocare, independent de
producător pentru toate platformele suportate.
6.2.4. Gateway de Securitate
Descriere
Platforma de securitate va oferii funcţii pentru politici de securitate, control al accesului şi
“reverse proxy” şi va suporta nativ standardul XML, acesta fiind un mecanism fundamental
de asigurare a interoperabilităţii în cadrul soluţiei.
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, aplicaţiilor integrate
din intranet şi internet). Trebuie furnizate rezultate alte testelor de laborator cu descrierea
scenariilor de test şi a condiţiilor în care s-au făcut aceste măsurători.
Cerinţe
Platforma trebuie sa ofere următoarele capabilităţi:
• Sa fie uşor de instalat şi configurat oferind pentru aceasta o interfaţa web, interfaţa
grafica dedicata, bazata pe standarde deschise, precum şi interpretor pentru linia de comanda.
• Sa ofere funcţii de securitate la nivel de mesaj şi control al accesului astfel încât
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 câmp 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 uşurinţa a securităţii ca firewall de aplicaţii web, pentru a
asigura protecţie împotriva atacurilor din perimetrul WEB ( cross-site scripting, SQL
injection, alte atacuri XML).
• Sa ofere virtualizare pentru servicii web.
• Sa ofere suport pentru următoarele infrastructuri de chei publice (PKI): XKMS, RSA,
3DES, DES, AES, SHA, X.509, PKCS, CRLs, OCSP
• Sa ofere suport pentru următoarele 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.
• Funcţionalitatea de “reverse proxy” trebuie sa ofere suport pentru Split SSL
Certificate.
• Funcţionalitatea de “reverse proxy” trebuie sa suporte următoarele metode de
autentificare:
Nume de utilizator/parola;
Certificate Client x.509 V3;
Autentificare cu token;
Autentificare NTLM;
LDAP
• Funcţionalitatea 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 următoarele protocoale de transport:
HTTP
HTTPs
FTP
NFS
SOAP/HTTP(s)
• Sa permită implementarea de funcţii de tip AAA ( Autentificare, Autorizare,
Auditare).
• Din motive de securitate şi protecţie, platforma gateway de securitate nu trebuie sa
permită instalarea de alte componente software sau alte aplicaţii altele decât cele autorizate
de producător.
6.2.5. Integrare aplicaţii
Descriere
Platforma de integrare trebuie sa furnizeze funcţiile de transformare de mesaje, interconectare
cu aplicaţiile din intranet şi internet în condiţii de securitate şi înalta performanta, astfel încât
sa nu necesite modificarea aplicaţiilor existente în cadrul soluţiei integrate.
Dimensionare
Trebuie sa ofere parametri de performanta ridicata pentru funcţiile de transformare a
mesajelor, putând fi folosita pentru descongestionarea serverelor de aplicaţii prin preluarea
funcţiilor de procesare XSLT, rutare Xpath, conversie a mesajelor XML şi a altor funcţii
consumatoare de resurse pentru a reduce capacitatea de transfer şi pentru a asigura un timp de
răspuns 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, aplicaţiilor integrate din
intranet şi internet). Trebuiesc furnizate rezultate alte testelor de laborator cu descrierea
scenariilor de test şi a condiţiilor în care s-au făcut aceste măsurători.
Cerinţe
• 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 (verificări de
sintaxa, XML schema);
• Sa ofere funcţii de securitate la nivel de mesaj şi control al accesului astfel încât
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 câmp al mesajului)
semnate digital
• Sa permită autentificarea mesajelor de tip servicii web folosind standardele WS-
Security şi SAML 2.0.
• Sa ofere suport pentru următoarele standarde la nivel de chei publice (PKI): XKMS,
RSA, 3DES, DES, AES, SHA, X.509, PKCS, CRLs, OCSP
• Sa ofere suport pentru următoarele 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 funcţiilor de procesare a mesajelor făcând
posibila implementarea următoarelor scenarii:
Rutare complexa de mesaje în mai mulţi paşi – pe baza sursei, destinaţiei şi a
conţinutului mesajului
Filtrare
Algoritmi de procesare folosind decizii logice, bucle (loops), procesare paralela,
mecanisme de reîncercare în caz de eroare.
• Trebuie sa ofere suport pentru următoarele 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, incluzând iSCSI pentru conectivitate către discuri externe.
• Sa permită implementarea de funcţii 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 distribuţia inteligentă a cererilor către mai multe servere de aplicaţii, cu modificări
dinamice ale membrilor, priorităţii şi afinităţii.
• Din motive de securitate şi protecţie, platforma de integrare nu trebuie sa permită
instalarea de alte componente software sau alte aplicaţii altele decât cele autorizate de
producător.
• Sa fie uşor de instalat configurat oferind pentru aceasta o interfaţa web, interfaţa
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 măreşte
flexibilitatea proceselor funcţionale, oferind capabilităţi 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 capabilităţi pentru:
• Reacţie dinamica la cerinţele de schimbare ale activităţilor funcţionale, cu
posibilitatea instalării de noi versiuni de procese şi migrarea proceselor în curs de execuţie la
noile versiuni.
• Scenarii pentru fluxuri umane adiţionale, incluzând aprobări paralele cu voturi şi
agregări de rezultate.
• Scenarii avansate cum ar fi secvenţe de proces (“tasks”) adresate unor responsabili
umani, fluxuri, gestionare escaladări, filtrări ad-hoc , etc.
• Capabilităţi îmbogăţite de a gestiona procesele în curs de execuţie, cum ar fi
schimbarea responsabilului unui proces şi capabilităţi avansate de corectare a procesului.
Cerinţe
• Serverul de procese trebuie sa implementeze standardul BPEL şi BPMN.
• Serverul de procese trebuie sa ofere posibilitatea captării de date în timp real din orice
baza de date, coada de mesaje sau aplicaţie.
• Serverul de procese trebuie sa ofere posibilitatea definirii de indicatori şi obiecte în
scopul analizei.
• Serverul de procese trebuie sa ofere posibilitatea auditării fluxurilor executate sau în
curs de execuţie;
• 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”) cât şi a celor de tip asincron (“long running” - necesită intervenţia
utilizatorilor)
• Serverul de procese trebuie sa permită implementarea şi rularea proceselor
tranzacţionale (commit/rollback) pentru procesele de tip “short running”
• Serverul de procese trebuie sa ofere mecanisme de compensare a tranzacţiilor pentru
procesele de tip “long-running”. Pentru fiecare pas de execuţie, sau secvenţa de paşi de
execuţie a procesului, trebuie sa ofere posibilitatea de a defini o acţiune compensatorie /
opusa.
• Serverul de procese trebuie sa ofere mecanisme de gestionare a erorilor. Acest
mecanism trebuie sa fie capabil sa declanşeze ş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
funcţionale în cod Java .
• Serverul de procese trebuie sa ofere suport pentru integrarea acţiunilor utilizatorilor ca
paşi de execuţie ai procesului.
• Serverul de procese trebuie sa ofere posibilitatea definirii de “task-uri” utilizator atât
pe baza standardului BPEL (Business Process Execution Language) cat şi separat ca servicii
independente.
• Serverul de procese trebuie sa permită administrarea acţiunilor utilizatorilor pe baza
de roluri de utilizatori.
• Serverul de procese trebuie sa ofere posibilitatea definirii în standard JSP sau pe baza
de portleţi a interfeţelor grafice pentru execuţia acţiunilor utilizatorilor.
• Serverul de procese trebuie sa ofere suport pentru interfeţe de tip formulare
electronice.
• Serverul de procese trebuie sa permită crearea ad-hoc, transferul şi ştergerea
activităţilor delegate unor utilizatori.
• Serverul de procese trebuie sa ofere posibilitatea de a defini şi administra reguli
funcţionale printr-un instrument adresat personalului fără atribuţii de tehnice.
• Serverul de procese trebuie sa ofere capabilităţi de integrare de tip magistrala de
servicii (ESB) şi capabilităţi de server de aplicaţie 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 execuţie 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, fişier ş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 locaţie unica de stocare.
• Serverul de procese trebuie sa permită gestionarea listei de secvenţe de proces cu
responsabil uman, aprobări, notificări, escaladări, rutări seriale, paralele, ad-hoc.
• Serverul de procese trebuie sa permită integrarea cu alte sisteme utilizând 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 activităţilor
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 aceluiaşi 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 atât de mediile de modelare şi implementare a proceselor de
business, cât şi de mediul de execuţie. Deasemenea soluţia trebuie să ofere o interfaţă
colaborativa utilizatorilor de business şi IT, prin care toate persoanele să poată accesa aceaşi
versiune de proces. In plus, soluţia trebuie să permită modificări majore asupra unei activităţi
de proces, in timp ce acesta se află in execuţie, iar activitatea trebuie să se ruleze conform
noilor modificări
• Serverul de procese trebuie sa ofere o interfaţa web prin care utilizatorii sa vizualizeze
istoricul şi starea secvenţelor de proces desfăşurate, fără a rula un anumit proces
• Serverul de procese trebuie sa ofere o interfaţa web prin care utilizatorii pot
monitoriza procesele, administra propriile sarcini, vizualiza şi modifica tablouri de bord cu
identificatorii definiţi, sau vizualiza şi defini alerte bazate pe diferite condiţii.
• 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 interacţiune cu entităţile 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 conţinut.
• 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
autentificării şi identităţii.
• 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 aplicaţii ( 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ă relaţionare între servicii şi obiecte aplicative
• Serverul de procese trebuie sa suporte cel puţin 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 monitorizării grafice a instanţelor de
proces.
• Serverul de procese trebuie sa ofere căutarea cu filtrare avansata a instanţelor de
proces.
• Serverul de procese trebuie sa ofere posibilitatea creării de perspective personalizate
pentru gestionarea de procese aplicative conţinând secvenţe de proces (“tasks”) cu
responsabili umani.
• Serverul de procese trebuie sa ofere posibilităţi de scalare pentru a permite creşterea
numărului de procese şi a utilizatorilor sistemului.
• Serverul de procese trebuie sa suporte o arhitectura de tip “cluster”.
• Serverul de procese trebuie sa ofere capabilităţi de tip “fail-over” automat.
• Serverul de procese trebuie sa ofere o balansare a încărcării la nivel de protocol web
şi aplicaţie.
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 soluţii de guvernare
proactivă a ciclului de viata al serviciilor.
Ca atare, modulul trebuie sa ofere capabilităţi de gestionare a interacţiunilor cu serviciile
oferite de entităţile aplicative ale sistemului şi a dependentelor intre servicii prin gestionarea
politicilor, versionării, clasificării şi a utilizării acestora pe baza unui proces comprehensiv de
management al ciclului lor de viata.
Modulul trebuie sa faciliteze stocarea, accesarea şi gestionarea informaţiilor (meta-date
servicii) astfel încât clientul sa poată cu uşurinţa sa selecteze, sa apeleze şi sa reutilizeze
serviciile.
Cerinţe
Administrarea ciclului de viata a fluxurilor şi serviciilor modelate se va realiza utilizând o
soluţie de tip registru de servicii (“service registry”), cu cel puţin următoarele caracteristici:
• Posibilitatea definirii de taxonomii care sa permită clasificarea serviciilor repertoriate
din punct de vedere funcţional şi tehnic.
• Interfaţa 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
căutarea şi utilizarea unui anumit serviciu în funcţie de starea în care se afla sau alte
proprietăţi.
• Versionarea serviciilor, precum şi interogarea catalogului în funcţie de versiunea
serviciului căutat.
• Executarea unor analize de impact pentru a identifica interdependenta serviciilor intre
ele, precum şi care ar fi impactul unei modificări la nivelul unui anumit serviciu.
• Posibilitatea federalizării cu alte cataloage de servicii.
• Integrare nativa cu instrumentele de modelare şi implementare oferite în cadrul
soluţiei, incluzând serverul de procese, pentru facilitarea căutării statice şi dinamice a
serviciilor pe baza valorilor anumitor proprietăţi.
• 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 interacţiune
personalizata a utilizatorilor cu sistemul şi va conţine cel puţin următoarele funcţionalităţi, ce
nu vor impune necesitatea achiziţionării de licenţe suplimentare:
• server de aplicaţie
• server HTTP
• componenta software pentru balansarea încărcării
• sistem de gestiune al bazelor de date relaţionale
• director LDAP
• componenta pentru dezvoltare aplicaţii şi extindere funcţionalităţi în portal
• componenta pentru managementul conţinutului web
• componenta pentru căutare
Cerinţe
Caracteristici generale
• Serviciile de tip REST pentru crearea de aplicaţii compozite, aplicaţii “mash-up” cu
servicii de “feed” provenite de la alte aplicaţii web .
• Agregare la nivel client ce reduce procesarea la nivel server şi îmbunătăţeşte
performanta pentru utilizatorul final.
• Sa pună la dispoziţie şabloane predefinite pentru configurarea rapida a portalului, atât
pentru internet cat şi pentru intranet.
• Portalul va pune la dispoziţie portleţi configurabili de tip “Workflow Task List”
pentru o furnizare rapida şi personalizata a proceselor integrate în aplicaţiile portalului.
• Platforma va oferi fiabilitatea ridicata, scalabilitate, securitate şi administrarea uşoara.
• 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 uşor aplicaţii Web existente.
• Utilizatorii vor putea vizualiza, partaja şi organiza fişiere de orice tip în cadrul
portalului. Se vor putea configura rapid biblioteci de documente astfel încât administratorii sa
poată partaja rapid conţinut media, utiliza funcţionalităţi de configurare a meta-datelor şi a
gestiona versiuni de documente. Documentele vor putea fi accesate de utilizatori direct din
browser web sau din diverşi portleţi
• Portalul va oferi funcţionalităţi de căutare în cadrul acestuia.
• Portalul va include o soluţie de formulare electronice pentru eficientizarea proceselor
şi pentru a economisi hârtia. Se permite astfel utilizatorilor sa completeze, salveze şi
vizualizeze formulare direct din interfaţa portalului.
• Portalul va oferi utilizatorilor portalului instrumentul necesar pentru mesagerie
instantanee în cadrul acestuia.
Interfaţa
• Trebuie sa existe servicii de prezentare care sa permită particularizarea interfeţei
pentru fiecare şablon de lucru sau rol din echipa.
• Este necesar ca interfaţa portalului sa fie separata, din punct de vedere logic, de codul
aplicaţiilor integrate, aşa încât în cazul actualizării unei aplicaţii, sa se păstreze toate
particularizările efectuate anterior asupra interfeţei.
• Utilizatorii trebuie sa poată vizualiza, crea, converti sau edita documente, tabele de
calcul şi fişiere tip prezentare, direct din mediul de lucru portal, fără a avea nevoie de
instrumente adiţionale.
• Interfaţa web a portalului trebuie sa ofere o experienţa de lucru utilizatorilor incluzând
tehnologii în domeniu cum ar fi AJAX, servicii REST.
• Conţinutul accesat prin portal trebuie sa fie automat afişat sau ascuns, pe baza
rolurilor utilizatorilor, roluri care sunt predefinite.
• Utilizatorii trebuie sa aibă posibilitatea de a particulariza pagina de intrare în portal,
funcţie de preferinţe.
• Soluţia trebuie sa permită administratorului sa specifice aplicaţiile (portleţii)
obligatorii pentru paginile ce pot fi personalizate.
• Administratorii trebuie sa poată controla drepturile utilizatorilor de a particulariza
propriile pagini, funcţie de rolul acestora, sau funcţie de regulile definite.
• Utilizatorii trebuie sa aibă posibilitatea de a adăuga portleţii pe pagina printr-o
funcţionalitate de tip “drag-and-drop” din paleta de portleţi disponibila.
Dezvoltare/extindere funcţionalităţi
• Platforma portal trebuie sa furnizeze un instrument dedicat de dezvoltare pentru
aplicaţii web şi portleţi.
• Instrumentul de dezvoltare trebuie sa conţină componente software adaptate, ce
generează cod (incluzând Java, JSP şi XML) pentru o funcţionalitate de aplicaţie specifica,
astfel încât sase poată crea aplicaţii web sau portleţi fără a fi nevoie de a se scrie cod.
• Soluţia trebuie sa ofere API-uri (Application Programming Interfaces) bine definite
pentru integrarea cu aplicaţiile existente.
• Dezvoltarea aplicaţiilor trebuie realizata intr-un mediu standardizat, ca de exemplu un
mediu J2EE.
• Sistemul trebuie sa conţină instrumente dedicate pentru construirea portleţilor
• Instrumentele de dezvoltare trebuie sa ofere suport pentru următoarele standarde:
XML, XSL, HTML, JSP, CSV.
• Soluţia trebuie sa ofere posibilitatea utilizării serviciilor web pentru a expune date şi
funcţionalităţi către sistemele externe portalului.
• Soluţia trebuie sa permită comunicarea şi notificarea evenimentelor intre portleţi.
• Trebuie oferita posibilitatea de a declanşa comunicarea intre portleţi la acţiunea
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 conţină mecanisme de tip asistent (“wizard”) pentru configurări
avansate, cel puţin pentru configurarea cu sisteme de baze de date, mutarea bazelor de date,
configurarea cu sisteme LDAP sau sistem de mesagerie instantanee.
• Suport pentru delegarea administrării pentru controlul accesului.
• Sistemul portal trebuie sa permită folosirea de politici (colecţii de configurări) pentru
administrarea a cel puţin următoarelor componente: utilizatori, grupuri, aplicaţii, teme web.
Securitate
• Sistemul portal trebuie sa conţină propriul sistem LDAP, dar sa permită integrarea şi
cu alte sisteme de tip LDAP.
• Sistemul portal trebuie sa conţină propriile mecanisme pentru autentificare,
autorizare, autentificare unica (Single Sign-On) şi SSL, dar sa permită şi integrarea cu alte
soluţii de securitate existente.
• Sistemul trebuie sa dea utilizatorilor posibilitatea de a se auto-înregistra în sistem.
• Soluţia 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 tranzacţie intr-o anumita
perioada de timp (interval ce poate fi setat de administrator).
• Sistemul de portal trebuie sa permită utilizarea profilelor de utilizatori,
administratorul putând seta astfel preferinţe atât la nivel de profil, grup cat şi la nivel de
utilizator. Aceste preferinţe trebuie sa specifice atât accesul pe care îl vor avea utilizatorii la
diverse porţiuni ale portalului cat şi drepturile asupra acestor zone.
• Soluţia trebuie sa ofere suport pentru securitate în tehnologie Java.
Standardizare
• Soluţia trebuie sa aibă o arhitectura deschisa.
• Sistemul trebuie sa fie compatibil cu următoarele standarde în domeniu: WSRP, JSR-
168, JSR-286
• Soluţia 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
• Soluţia trebuie sa ofere posibilitatea de a implementa portalul intr-un mediu cluster,
având posibilitatea de a realiza balansarea încărcării, fără componente software sau hardware
adiţionale.
• Soluţia pentru portal trebuie sa ofere capabilităţi de preluare a utilizatorilor pe un alt
nod, în cazul unei întreruperi hardware de funcţionare (“failover”).
• Sistemul portal trebuie sa ofere capabilităţi 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 puţin următoarele 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 atât pe sisteme de operare x32 cat
şi x64.
• Sa suporte cel puţin următoarele platforme de baze date: Oracle, IBM DB2, MS SQL
Server
Management site-uri şi conţinut web
• Sistemul trebuie sa permită crearea de şabloane de aplicaţii cu portleţi direct din
interfaţa web.
• Facilitaţi de tip asistent creare site (wizard) pentru a crea rapid, din interfaţa web, site-
uri web pe baza unor şabloane existente.
• Soluţia trebuie sa includă un instrument pentru publicarea de conţinut, pentru a
permite utilizatorilor privilegiaţi sa publice, sa actualizeze sau sa şteargă propriile pagini,
intr-un mod simplu şi facil.
• Soluţia trebuie sa permită editarea conţinutului direct în pagina în care este publicat.
• Pentru conţinutul publicat, trebuie sa se stocheze data publicării, data la care trebuie
arhivat şi data la care documentul respectiv nu mai este valabil, cu scopul de a permite
adăugări sau ştergeri automate.
• Soluţia trebuie sa ofere o modalitate simpla de administrare centralizata, atât pentru
administratorii de conţinut cat şi pentru deţinătorii de privilegii de aprobare de conţinut.
• Accesul la conţinut se va face în funcţie de utilizatorul care vizualizează datele.
• Formatarea conţinutului trebuie realizata pe baza de şabloane (“templates”).
• Soluţia trebuie sa ofere capabilităţi de control al versiunilor şi arhivare.
• Soluţia trebuie sa ofere posibilitatea de a extrage conţinut direct din baza de date.
• Interfaţa cu utilizatorul trebuie sa ofere asistenta pentru formatarea documentelor,
astfel încât utilizatorii fără cunoştinţe de limbaj HTML sa poată contribui la publicarea de
informaţii.
• Soluţia trebuie sa suporte structuri ierarhice de navigare arborescenta pentru
documente.
• Documentele trebuie sa fie securizate fără a exista posibilitatea de a fi accesate în
absenta autentificării.
• Sistemul trebuie sa permită planificarea publicării de conţinut.
• Soluţia 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).
• Soluţia trebuie sa ofere capabilităţi de publicare şi personalizare de conţinut direct
dintr-un browser web.
• Modulul de gestiune al conţinutului web trebuie sa permită un flux de aprobare
secvenţiala.
• Modulul de gestiune al conţinutului web trebuie sa furnizeze opţiuni preconfigurate
pentru fluxuri de lucru ce permit procese de aprobare diferite ce depind de regulile şi
cerinţele organizaţiei.
• Modulul de gestiune al conţinutului web trebuie sa permită un proces de aprobare ce
poate fi configurat în funcţie de tipul elementului de conţinut precum şi a stării elementului
de conţinut în timpul procesului de creare (de exemplu: ciorna, în aşteptarea aprobării,
publicat, arhivat, nepublicat, resubmis/restaurat etc.)
• Modulul de gestiune al conţinutului web trebuie sa permită escaladarea unui proces de
aprobare al unui element de conţinut de către utilizatori autorizaţi.
• Modulul de gestiune al conţinutului web trebuie sa permită utilizatorilor sa creeze şi
sa gestioneze procese fluxuri de aprobare fără a fi nevoie de creare de scripturi sau activitati
de programare.
• Modulul de gestiune al conţinutului web trebuie sa furnizeze notificări în cadrul unui
flux de aprobare conţinut către persoanele responsabile cu îndeplinirea unei anumite acţiuni
(cum ar fi aprobare)
• Modulul de gestiune al conţinutului de lucru trebuie sa ofere posibilitatea de aprobare
de către una sau mai multe persoane autorizate pentru un element de conţinut.
• Soluţia trebuie sa permită reatribuirea de sarcini în cadrul unui proces / flux de lucru.
• Soluţia trebuie sa permită atribuirea de roluri în cadrul unui proces flux de lucru
pentru conţinut.
• Soluţia trebuie sa permită fluxuri de aprobare atât pentru elemente de conţinut dar şi
pentru şabloane de conţinut sau design de conţinut.
Soluţia de management de conţinut 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ă
soluţia)
1.1.1.42. Server de aplicaţie
• Server-ul de aplicaţie trebuie sa fie o platforma robusta şi agila ce oferă suport pentru
rularea de aplicaţii J2EE, simplificarea dezvoltării, performanta ridicata şi administrare
inteligenta.
• Server-ul de aplicaţie 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 aplicaţie 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 aplicaţie trebuie sa permită simplificarea interoperabilităţii prin suport
pentru servicii web incluzând JAX-WS, SOAP 1.2, MTOM, XOP, WS-Reliable Messaging,
WS-Trust, WS-SecureConversation, WS-Policy, şi Kerberos Token Profile.
• Server-ul de aplicaţie trebuie sa ofere suport pentru standarde WEB 2.0
• Server-ul de aplicaţie trebuie sa ofere suport pentru standardul “Session Initiation
Protocol” (SIP).
• Server-ul de aplicaţie trebuie sa permită comunicarea prin mesaje asincrone utilizând
un furnizor integrat de Java Message Service (JMS), care respecta standardul JMS 1.1.
• Server-ul de aplicaţie trebuie sa ofere suport pentru tehnologia Java EE Connector
Architecture (JCA) 1.5 care sa asigure conectivitatea intre serverele de aplicaţii şi diferite
sisteme informatice aplicative.
• Server-ul de aplicaţie trebuie sa ofere suport pentru tehnologia Java Transaction API
(JTA) 1.1 pentru gestionarea tranzacţiilor.
• Server-ul de aplicaţie trebuie sa ofere acces autentificat şi autorizat pentru a securiza
funcţiile administrative şi aplicative.
• Server-ul de aplicaţie trebuie sa ofere suport pentru tehnologiile de registre
(“registries”) oferind diverse opţiuni tehnologice, cel puţin: LDAP (inclus in serverul de
aplicatie), registre bazate pe fişiere si federative • Server-ul de aplicaţie trebuie ofere
suport pentru tehnologia Java Authorization Contract for Containers (JACC) 1.1, care sa
ofere securizarea resurselor gestionate de către server-ul de aplicaţie.
• Server-ul de aplicaţie trebuie sa ofere integrare nativa cu o platforma de dezvoltare
compatibila.
• Server-ul de aplicaţie trebuie sa permită expunerea securizata a serviciilor intranet
către utilizatorii din internet.
• Server-ul de aplicaţie trebuie sa permită utilizare securizata a serviciilor web externe
de către sistemele localizate în intranet.
• Server-ul de aplicaţie trebuie sa permită structuri de cluster.
• Server-ul de aplicaţie trebuie sa permită distribuţia inteligenta a încărcării în cluster.
• Server-ul de aplicaţie trebuie sa poată realiza balansarea traficului de intrare în sistem.
• Server-ul de aplicaţie trebuie sa ofere disponibilitate ridicata (“high-availability”) în
interiorul clusterului.
• Server-ul de aplicaţie trebuie sa ofere disponibilitate ridicata a tranzacţiilor şi
funcţionalitate de tip “back-up” pentru tranzacţii prin replicarea informaţiilor referitoare la
tranzacţiile în lucru pe toate nodurile active.
• Server-ul de aplicaţie trebuie sa ofere mecanisme de reglare a performantei de la
nivelul serverelor pana la nivelul cel mai detaliat al aplicaţiilor şi al componentelor utilizate
de acestea.
• Server-ul de aplicaţie 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 aplicaţie trebuie sa ofere componenta server web care sa poată fi instalata
topologic în fata server-ului de aplicaţii, pentru balansarea nodurilor de aplicaţii.
Acces universal de date şi persistenta
• Server-ul de aplicaţie trebuie sa suporte standardul Java DataBase Connectivity
(JDBC) API 4.0 pentru conectare la orice tip de baza de date.
• Server-ul de aplicaţie trebuie sa suporte Java Persistence API (JPA) pentru a asigura
persistenta şi reutilizarea obiectelor.
• Server-ul de aplicaţie trebuie sa suporte standardul de dezvoltare SCA.
• Server-ul de aplicaţie 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 colecţii de structuri de tip arbore, sau grafuri.
• Server-ul de aplicaţie trebuie sa suporte portleţi conform standardului Java
Specification Requests (JSR) 286 (Portlet 2.0).
• Server-ul de aplicaţie trebuie sa suporte aplicaţii ce folosesc tehnologia Session
Initiation Protocol (SIP) conform standardului JSR 116.
• Server-ul de aplicaţie trebuie sa suporte standardele Java Servlet 2.5 (JSR 154) şi
JavaServer™ Pages (JSR 245)
Securitatea aplicaţiilor
• Server-ul de aplicaţie trebuie sa ofere flexibilitate în definirea şi controlul conturilor
utilizatorilor.
• Server-ul de aplicaţie trebuie sa ofere funcţionalităţi Single Sign-On pentru
interoperabilitate îmbunătăţită între diferite aplicaţii.
• Server-ul de aplicaţie trebuie sa permită auditarea informaţiilor de securitate a
acţiunilor administrative, cum ar fi modificări de configurări de securitate, gestionare de chei
şi certificate, modificări de politici de control al accesului, etc.
• Server-ul de aplicaţie trebuie sa ofere administrare a securităţii îmbunătăţită la nivelul
consolei de administrare, cu acces pe baza de permisiuni, în funcţie de roluri.
Administrare inteligenta
• Server-ul de aplicaţie trebuie sa ofere infrastructura simplificata şi flexibila pentru
controlul eficientei mediilor de rulare.
• Server-ul de aplicaţie trebuie sa ofere administrarea de la distanta a mai multor
servere de aplicaţii.
• Server-ul de aplicaţie trebuie sa ofere controlul mediilor complexe cu topologii
complexe.
• Server-ul de aplicaţie trebuie sa ofere activitati administrative simplificate pentru
aplicaţiile cu componente multiple.
• Server-ul de aplicaţie trebuie sa ofere o consola de administrare web-based pentru
gestionarea centralizata a tuturor componentelor din topologii ce includ mai multe servere de
aplicaţii si/sau web.
• Server-ul de aplicaţie trebuie sa permită gestionarea centralizata a transferului de
informaţii intre medii cum ar fi: instalarea, pornirea, oprirea de aplicaţii şi distribuirea
fişierelor în topologii ce includ mai multe servere de aplicaţii si/sau web.
• Server-ul de aplicaţie trebuie sa ofere posibilitatea de a grupa şi gestiona mai multe
artefacte Java EE sub o singura definiţie de aplicaţie.
• Server-ul de aplicaţie trebuie sa ofere capabilităţi 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 aplicaţie trebuie sa ofere script-uri avansate de administrare, care
accelerează procesele administrative.
• Server-ul de aplicaţie trebuie sa ofere facilitaţi avansate şi eficiente de gestionare a
resurselor de memorie şi spaţiu pe disc, în funcţie de necesităţile aplicaţiilor care rulează,
prin activarea în mod dinamic, doar a componentelor necesare aplicaţiilor ce rulează la un
moment dat pe server.
• Server-ul de aplicaţie 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
funcţionalităţi de gestiune centralizata şi automata a identificatorilor de identitate şi
drepturilor de acces asociate utilizatorilor în cadrul sistemului integrat.
Cerinţe
• 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 autentificării.
• Sistemul trebuie sa conţină propriile mecanisme de autorizare dar sa poată fi integrat
şi cu subsisteme terţe 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 operaţiuni administrative.
• Sistemul va fi capabil sa susţină 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 funcţie de rolul sau grupul din care face parte.
• Platforma trebuie sa ofere capabilităţi pentru configurare a funcţionalităţii de
autentificare unica (“Single Sign-On”).
• Sistemul trebuie sa permită integrarea cu multiple registre majore de tip LDAP, cel
puţin: 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 funcţiei ETL (Extract-Transform-Load) pentru
implementarea modulului de Data Warehouse.
Cerinţe
Instrumentul pentru extragerea, transformarea şi încărcarea datelor (ETL) trebuie sa ofere
suport pentru modificări permanente, funcţie de cerinţele impuse de activitate: surse de date
noi, modificarea proceselor şi cerinţe specifice care implica schimbarea structurii datelor. în
vederea atingerii acestui obiectiv, instrumentul ETL trebuie sa ofere următoarele capabilităţi:
• Procesul ETL sa fie realizat cu ajutorul instrumentului specializat, fără a fi necesara
scrierea de cod, de script-uri, sau utilizarea de instrumente sau funcţionalităţi externe acestui
instrument.
• Sa gestioneze următoarele cerinţe de proces
o Agregare
o Compresie/Decompresie
o Conversie tip si/sau format date
o Manipulare şi executare de operaţii aritmetice pe seturi de date
o Asignare valori si selectie conditionala de dateFiltrare
o Partiţionare/grupare pentru seturile de înregistrări
o Sortare
o Manipularea înregistrărilor
o Alocarea şi rezoluţia cheilor surogat
o Tabele lookup
o Validarea datelor
• Sa proceseze înregistrările rejectate
• Executarea de job-uri multiple în mod concurent
• Eliminarea procesării datelor în sistemele sursa/ţinta sau în interiorul unei baze de date.
• Conectivitate avansata pentru orice tip de surse de date (baze de date, fişiere, XML, etc)
• Reprezentarea grafica a fluxului de date, cu posibilitatea de proiectare ierarhica
• Efectuarea de lookup-uri pe date eterogene, în cadrul aceluiaşi flux
• Multi-sursa/multi-ţintă în acelaşi flux.
• Instrumentul ETL trebuie sa includă instrumente de dezvoltare cu următoarele
capabilităţi:
• Procesul ETL sa fie construit din componente reutilizabile.
• Variabilele temporare sau coloanele sa fie utilizate în procesul ETL, astfel încât
procesările sa se efectueze o singura data
o Interfaţa grafica consistenta intre toate modulele
o Rollback la versiunile anterioare
o Debugger vizual
o Setare puncte de verificare
• Motorul de execuţie trebuie sa ofere următoarele capabilităţi:
o Sa pună la dispoziţie o consola vizuala pentru rularea şi gestionarea job-urilor
o Sa gestioneze procese ETL multiple
o Monitorizare în timp real
o Suport pentru încărcarea volumelor mari (“bulk loaders”)
o Suport pentru XML ca sursa/ţinta de date
o Direcţionarea înregistrărilor ‘greşite’ către un fişier separat pentru procesare
ulterioara
o Posibilitatea de a crea dependente intre sesiunile programate
o Restaurare pana la ultimul punct de verificare sau de eşuare, fără efort manual
o Repornire de la punctul de eşuare
o Repornirea întregii sesiuni
o Posibilitatea de a specifica gestionarea erorilor intr-o secvenţa 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
următoarele capabilităţi:
o Consola de administrare sa poată gestiona mai multe sisteme ETL
o Monitorizarea evenimentelor (stare job, linii procesate, durata fiecărui task, timpul
total, încărcarea procesorului şi consumul de memorie, valorile medii, maxime,
minime, etc.)
o Definirea planificărilor şi dependentelor intre job-uri, în mod grafic
o Limitarea necesitaţii intervenţiei administratorilor bazelor de date în sistemul ETL
o Eliminarea necesitaţii cunoştinţelor specializate de SQL sau orice alt limbaj de
programare, prin utilizarea de conectori automatizaţi
o Capabilitatea de a monitoriza procesele şi job-urile în desfăşurare.
6.2.10.Analiza şi raportare
Descriere
Rolul acestui modul este acela de oferi suport pentru rularea de rapoarte ce includ facilitaţi de
analiza statistica
Cerinţe
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 hărţi, pie, charturi sau combinaţii în cadrul unui raport a
mai multor astfel de elemente
• vizualizarea trasabilităţii componentei dintr-un raport, şi daca aceasta este o măsura
calculata, sa permită vizualizarea formulei de calcul.
• autorizarea utilizatorilor la funcţionalitatea 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:
-existenţa unui “inbox” de sarcini pe care un utilizator să il poată accesa direct din interfaţa
web de raportare
-crearea de noi sarcini în care să poată fi adăugaţi utilizatori din diverse grupuri de lucru
implicate în rapoartele analizate
-să se definească atât o prioritate a sarcinii respective cât şi o dată de început şi sfârşit
-conţinutul mesajului de notificare să poată fi formatat, să poată fi adăugate imagini, tabele
precum şi legături către rapoartele ce trebuiesc analizate sau modificate
• sa pună la dispoziţie un sistem de auditare a accesului şi a activitati la nivelul
sistemului de raportare.
• posibilitatea de drill-up, drill-down
• posibilitatea de a interacţiona cu sistemul de raportare doar prin intermediul unui
browser web, fără a fi necesara instalarea unui software pe sistemele utilizatorilor finali
• arhivarea rapoartelor statice şi vizualizarea unui istoric al rulării 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 destinaţie
şi crearea unui astfel de raport nu va implica cunoştinţe 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 către anumiţi utilizatori prin email sau prin publicare intr-o locaţie definita.
• definirea de grupuri de utilizatori şi roluri;
• administrarea şi utilizarea prin intermediul interfeţei web;
• adăugarea cu uşurinţa a filtrelor de sumarizare (ex: filtre aplicate după însumarea
înregistrărilor individuale)
• utilizarea unor template-uri predefinite în sistem sau de către 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ă conţină un modul de raportare ad-hoc care sa permită utilizatorilor crearea şi
utilizarea rapoartelor fără a fi nevoie de cunoştinţe de SQL, accesul sa se facă prin
intermediul unui browser web, iar componentele ce vor fi folosite pentru raportare sa fie
entităţi de business mapate peste componentele surselor de date.
• conectarea la diverse surse relaţionale 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 informaţiei de accesare şi utilizare a sistemului de
raportare.
• generarea cererii (query-ului) automata, prin “drag-and-drop” al componentelor, fără
a fi nevoie sa fie creata în prealabil şi asocierea mai multor componente de prezentare la
aceeaşi interogare.
• trecerea rapoartelor ad-hoc în editorul de rapoarte complexe, fără a fi nevoie sa fie
reconstruite rapoartele.
• adăugarea unui filtru pentru coloana de sumarizare daca aceasta este valoarea
urmărita.
• utilizarea de prompt-uri pentru a filtra informaţia din orice element de interfaţare
grafica din cadrul unui raport şi sa ofere o gama variata de tipuri de prompt-uri.
• adăugarea de hărţi ş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, având ca sursa
diverse sisteme primare/master şi este destinat utilizării ca baza pentru funcţia de raportare.
Cerinţe
• Sistemul de Data Warehouse trebuie sa ofere o consola comuna pentru administrarea
tuturor componentelor.
• Sistemul de Data Warehouse trebuie sa ofere o interfaţa 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 relaţionale chiar daca diferă
tehnologia (cum ar fi Oracle, Microsoft SQL Server, DB2). Aceste mapări sa fie transparente
pentru dezvoltatori.
• Crearea de modele logice şi fizice.
• Descoperirea, explorarea, vizualizarea structurii sursei de date.
• Sa descopere sau identifice relaţiile 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 relaţionala
Descriere
Acest modul gestionează necesarul de persistenta operaţionala pentru componentele
aplicative ale sistemului integrat.
Cerinţe
Cerinţe generale pentru baza de date relaţionala
• Baza de date relaţionala trebuie sa suporte comunicarea cu aplicaţiile client folosind
protocolul de transport pe reţea TCP/IP.
• Baza de date relaţionala trebuie sa poată rula pe sisteme de operare incluzând cel
puţin Windows, Unix, Linux
• Baza de date relaţionala trebuie sa suporte o arhitectura de clustering de tip “shared
disk”.
Cerinţe specifice pentru baza de date relaţionala
Baza de date / Securitatea Datelor
• Baza de date relaţionala nu trebuie sa permită executarea de operaţii asupra obiectelor
bazei de date decât daca utilizatorul este autorizat pentru operaţia în cauza.
• Baza de date relaţionala trebuie sa ofere o facilitate care înregistrează informaţii în
legătura cu operaţiunile de modificare, inserare, ştergere şi selectare a obiectelor interne bazei
de date.
• Baza de date relaţionala trebuie sa ofere abilitatea de a se ajusta la gradul de detalii,
capturate de către facilitatea interna de audit.
Salvarea şi recuperarea bazei de date
• Baza de date relaţionala trebuie sa ofere o facilitate pentru salvarea-restaurarea
întregii baze de date.
• Baza de date relaţionala trebuie sa ofere o facilitate pentru înregistrarea tuturor
modificărilor bazei de date, pentru a permite recuperarea bazei de date (înregistrarea
tranzacţiilor)
• Baza de date relaţionala trebuie sa ofere o facilitate pentru recuperarea întregii baze
de date corespunzător unui moment de timp specificat de administrator.
• Baza de date relaţionala trebuie sa ofere posibilitatea de a realiza salvări pentru unul
sau mai multe spatii alocate tabelelor aşa cum este specificat de către administratorul bazei de
date.
• Baza de date relaţionala trebuie sa scrie în mai multe fişiere pe disc simultan în timpul
unei operaţii de salvare
• Baza de date relaţionala trebuie sa citească din mai multe fişiere pe disc simultan în
timpul unei operaţii de restaurare.
• Baza de date relaţionala trebuie sa permită citirea şi scrierea paralela în timpul unei
operaţii de salvare
• Baza de date relaţionala trebuie sa permită citirea şi scrierea paralela în timpul unei
operaţii de restaurare
Integritatea datelor
• Baza de date relaţionala trebuie sa identifice şi sa rezolve situaţiile de blocaj la acces
concurent (“dead-locks”).
• Baza de date relaţionala trebuie sa permită administratorului sa impună constrângeri
de tip cheie primara.
• Baza de date relaţionala trebuie sa permită ca o coloana sa nu accepte valori NULL.
• Baza de date relaţionala trebuie sa ofere abilitatea de creare de indecşi unici.
Dicţionarul datelor
• Baza de date relaţionala trebuie sa ofere o facilitate de catalog (sau dicţionar de date)
care oferă posibilitatea execuţiei de instrucţiuni de tipul Data Definition Language (DDL –
Limbajul de definire a datelor).
• Baza de date relaţionala trebuie sa ofere facilitaţi interne de accesare a catalogului şi
obţinere de informaţii legate de obiectele bazei de date.
Performanta şi scalabilitatea bazei de date
• Baza de date relaţionala trebuie sa permită folosirea ei în sisteme cluster.
• Baza de date relaţionala trebuie sa ofere abilitatea sa partiţioneze tabele.
• Baza de date relaţionala trebuie sa permită unui tabel sa fie partiţionat bazându-se pe
una sau mai multe valori specifice de date, aşa cum este hotărât de către administratorul bazei
de date
• Baza de date relaţionala trebuie sa permită definirea cantităţii minime de date
transferate între disc şi memoria locala a bazei de date la o cerere
• Baza de date relaţionala trebuie sa permită setarea mărimii unei zone din memoria
locala, rezervata sa retina date din tabele special indicate, pentru o perioada nedefinita de
timp
• Baza de date relaţionala trebuie sa aibă un optimizator bazat pe cost pentru a optimiza
interogările
• 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.
• Instanţe multiple, izolate şi complet funcţionale ale bazei de date trebuie sa poată
coexista pe un singur nod SMP.
• Baza de date trebuie permită funcţionalitatea de clustering a tabelelor pentru o
performanta mai buna
• Baza de date trebuie sa suporte crearea de mai multe baze de date care sa aparţină
unei singure instanţe.
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.
Cerinţe
• Sistem unificat de tip consola web şi un mecanism de automatizare ale fluxurilor de
lucru.
• Localizarea şi clasificarea informaţiilor sensibile stocate în baze de date relaţionale.
Evaluarea vulnerabilităţilor bazei de date şi defecte de configurare.
• Vizibilitate de 100% şi granularitate a tranzacţiilor din bazele de date pentru toate
distribuţiile majore, incluzând Oracle, Microsoft SQL Server, IBM DB2, Informix, Sybase,
MySQL, Teradata.
• Monitorizarea şi aplicarea politicilor de acces privitoare la date sensibile, acţiuni
privilegiate ale utilizator, controlul modificărilor, cererilor şi activităţilor utilizatorilor
precum şi excepţii de securitate, cum ar fi operaţiuni eşuate; 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 agregării şi normalizării automate a informaţiilor 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 investigaţii.
• Găsirea şi clasificarea datelor, localizarea şi clasificarea în mod automat a
informaţiilor sensibile.
• Soluţia trebuie sa fie independenta de producătorul 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 puţin următoarele standarde: SNMP, SMTP, Syslog, CEF, SIEM
7. Cerinţe servicii de implementare
7.1. Mod de implementare
Pentru implementarea unui proiect de o asemenea anvergura şi complexitate dar şi ţinând
cont de numărul mare de sisteme cu care vor trebui integreze, următoarea abordare trebuie
considerata pentru implementarea DES:
o Stabilirea clara a tuturor informaţiilor ce se vor păstra în DES şi care alcătuiesc Date
Medicale Relevante (DMR). Pentru aceasta se va constitui o comisie (cu participanţi din
toate sectoarele domeniului de sănătate).
o Definirea standardelor de comunicare intre sistemele locale şi sistemul central DES
ţinând cont de securitate, performanta, fiabilitate, auditare, etc.
o Stabilirea funcţionalităţilor prezente în proiect şi modul de integrare cu alte sisteme sau
subsisteme adiacente proiectului DES, precum şi a sistemului de autentificare PKI (in
conjuncţie cu cardul de sănătate)
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 România în cadrul căruia vor
fi implementate componentele identificate anterior.
o Implementarea sistemului de certificare în vederea integrării cu alte sisteme din teritoriu
o Punerea în producţie a sistemului, prin integrarea cu spitalele majore din România şi prin
utilizarea portalului
o Finalizarea proiectului
7.1.1. Servicii de implementare
Se doreşte ca echipamentele şi aplicaţiile furnizate sa fie însoţite de servicii de implementare
şi de project management de calitate, care sa garanteze atingerea cu succes a obiectivelor
proiectului. Ofertanţii vor oferi servicii de management de proiect (PM) pe întreaga durata de
viaţa 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 urmări derularea proiectului.
Oferta va fi structurata astfel încât sa conţină următoarele:
Principii fundamentale:
• Viziunea proprie asupra realizării proiectului.
• Opinii asupra aspectelor principale privind proiectul care pot influenta atingerea
obiectivelor şi a rezultatelor aşteptate.
• Enumerarea şi explicarea riscurilor şi ipotezelor privind execuţia proiectului.
• Identificarea de noi riscuri şi ipoteze
• Identificarea unor soluţii de preîntâmpinare şi restrângere a riscurilor.
Strategia abordării:
a. Metodologii folosite:
• Ofertantul va declara ce metodologie de dezvoltare a sistemelor informatice foloseşte.
Este obligatorie folosirea unei metodologii recunoscute pe plan internaţional.
• Ofertantul va declara ce metodologie de management de proiect foloseşte. Este
obligatorie folosirea unei metodologii recunoscute pe plan internaţional.
• Ofertantul va face o scurta prezentare a metodologiilor folosite în proiect.
b. Soluţia propusa:
• Ofertantul va prezenta pe larg soluţia propusa pentru proiect, în vederea atingerii
obiectivelor acestuia şi a rezultatelor aşteptate
• Descrierea soluţiei trebuie sa evidenţieze etapele de proiect, activităţile specifice fiecărei
etape, livrabilele aşteptate de la fiecare etapa, modul în care acestea concura la atingerea
obiectivelor.
• Enumerarea intrărilor şi ieşirilor din proiect şi legăturile 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 componenţa 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 interacţiunea sarcinilor şi
responsabilităţilor.
7.1.2. Planificarea activităţilor
• Ofertantul va prezenta planificarea activităţilor propuse, în interdependenta acestora – un
plan Gantt este aşteptat.
• Planul trebuie sa menţioneze 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 aplicaţiilor, cu cicluri de construcţie iterative,
cu suprapunere intre faze, oferind astfel oportunităţi de reacţie la schimbarea condiţiilor şi
scenariilor din domeniul de activitate.
Ofertantul va trebui sa acopere, intr-un ciclu iterativ, principalele etape ale dezvoltării unui
sistem informatic:
Analiza:
In procesul de analiza, pentru determinarea cerinţelor de funcţionalitate ale sistemului,
ofertantul va trebui sa poarte discuţii cu personalul IT si/sau specialişti desemnaţi 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 discuţiilor purtate care sa
conţină specificaţiile tehnice şi funcţionale detaliate ale sistemului.
o Analiza cerinţelor funcţionale
o Analiza cerinţelor non-funcţionale
o Specificarea cerinţelor de interfaţare cu alte sisteme
Proiectare:
Principalul obiectiv al acestei faze îl constituie determinarea complexităţii şi scopului
soluţiei. Acum se efectuează o analiza a sistemului existent, identificându-se use-case-urile
critice şi scenariile de operare de baza care vor influenta în mod semnificativ designul
aplicaţiei. Se evidenţiază riscurile potenţiale şi se generează o arhitectura generica a soluţiei.
Scopul acestei faze este de a detalia modelul soluţiei identificat la nivel înalt în iniţierea
schiţării soluţiei. Pentru aceasta se definesc în detaliu comportamentul funcţional al aplicaţiei
şi funcţionalităţile care trebuie dezvoltate, se identifica omisiunile, contradicţiile şi cerinţele
care trebuie clarificate sau corectate. Se identifica şi formalizează în detaliu descrierea logicii
de business a aplicaţiei şi se defineşte arhitectura la nivel detaliat. Se creionează specificaţiile
pentru planurile de testare.
o Arhitectura funcţionala
o Arhitectura tehnica
o Modelul informaţional
o Proiectare de detaliu
o Elaborarea planurilor de testare
Dezvoltare:
Ofertantul trebuie sa aibă capacitatea de a dezvolta şi realiza o soluţie bazata pe rezultatele
proceselor de analiza şi proiectare
o Construcţia soluţiei
o Testarea soluţiei
Implementare:
Ofertantul trebuie sa asigure instalarea, configurarea, şi punerea în producţie tuturor
componentelor sistemului, cu personal certificat de producătorul componentei respective,
astfel:
o Instalarea şi configurarea infrastructurii HW
o Instalarea şi configurarea aplicaţiilor SW standard
o Integrarea aplicaţiilor SW specializate
Documentare sistem DES:
Ofertantul trebuie sa creeze următoarele livrabile care documentează sistemul:
o Sistemul de help on-line.
o Manuale de utilizare pentru toate componentele HW şi SW ale soluţiei.
o Manual de utilizare pentru interfaţa de servicii WEB a sistemului.
o Codul sursa al componentelor non-COTS (nu se aplica pentru produsele Customer Of The
Shelf – sisteme şi aplicaţii software disponibile în mod comercial)
Testele de acceptata şi validare a sistemului
Manualul de operaţiuni al sistemului care conţine 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 informaţii medicale. Acest
document cuprinde:
Standarde de comunicaţie între aplicaţii
Standarde de performanta în ceea ce priveşte transferul de informaţii
Standarde de securitate a datelor
Standarde de validare a datelor transmise
Modalitatea şi criteriile de testare a integrării
Modalitatea şi criteriile de certificare a integrării
Testare de acceptanta:
Ofertantul trebuie sa pună la dispoziţia beneficiarului o procedura de testare funcţionala şi
operaţionala a sistemului realizat prin întocmirea planurilor de testare de acceptanta şi a
cazurilor de testare pentru toate modulele sistemului, conform specificaţiilor. Testarea de
acceptata va fi realizata de către echipa CNAS pe baza planului de testare de acceptanta.
Planul de testare trebuie să urmeze o metodologie standard stabilită în domeniu. Domeniile
esenţiale de testare trebuie să acopere:
o teste unitare pentru componentele instalate
o teste non-funcţionale, cum ar fi:
- teste de securitate
- teste de performanta
- teste de securitate a reţelei
- teste pentru procedurile de salvare şi restaurare a datelor din DES
o teste de conexiune, integrare şi utilizare cu sistemele conectate
o teste funcţionale DES
Planurile de testare trebuie să acopere cel puţin domeniile de testare enumerate mai sus şi
trebuie să conţină cel puţin elementele următoare:
• 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
• Cerinţele de intrare/ieşire
• Condiţii de acceptare a testelor
Condiţiile de acceptare a testelor
Condiţiile 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 toţi angajaţii CNAS care vor accesa sistemul DES
sa fie capabili sa-l utilizeze în activitatea de zi cu zi precum şi sa îl preia în folosinţa şi
administrare la sfârşitul proiectului.
Pentru desfăşurarea în bune condiţii a activităţii necesare utilizării şi administrării sistemului
este foarte importanta existenta personalului şcolarizat. în acest sens se vor desfăşura
şcolarizări pe următoarele categorii:
• Produs – cursuri standard de produse adresate specialiştilor IT.
• Suport – cursuri personalizate destinate personalului care va întreţine sistemul (Nivel 1 de
suport) şi care va fi capabil sa transfere cunoştinţe de utilizare celorlalţi angajaţi ai CNAS
care vor folosi sistemul
Cerinţe de documentaţie
Ofertantul trebuie sa descrie documentaţia care va fi pusa la dispoziţia
Solicitantului/Utilizatorilor pe parcursul proiectului şi sa explice în ce mod va fi organizata
aceasta documentaţie: categorii de documente, convenţii de numerotare şi denumire, machete
de documente.
Următoarele reprezintă un minim necesar pentru documentaţia sistemului:
• Specificaţii detaliate: trebuie descrise în amănunt toate modulele DES la nivel tehnic. Se
vor descrie aici proceduri, funcţii, integrarea intre acestea, integrarea intre module şi
integrarea cu sistemele externe, fluxul de prelucrare a informaţiilor. Din acest ghid nu
trebuie sa lipsească:
o Funcţiile implementate (intrări, ieşiri şi parametri)
o Tipurile de date folosite
o Machetele de date folosite
o Concepte
• Documentaţie hardware: descrierea completa a specificaţiilor hardware şi a instrucţiunilor
de instalare, configurare, operare şi depanare
• Documentaţie a software-ului comercial: descrierea completa, atât funcţionala cat şi
tehnica a software-ului folosit. Se vor avea în vedere instrucţiuni de instalare, configurare,
operare şi depanare, atât cele de baza (din manualele produselor) cat şi cele specifice
aplicaţiei DES
• Documentaţie a software-ului dezvoltat: descrierea completa, atât funcţionala cat şi
tehnica, a software-ului dezvoltat pentru sistemul DES.
• Ghidul de operare şi administrare: acesta trebuie sa acopere arhitectura tehnica şi
funcţionala a tuturor modulelor sistemului DES şi defineşte atât cerinţele fundamentale de
funcţionare a DES cat şi metode de întreţinere zilnica. Acest document trebuie sa fie
actualizat pentru fiecare noua versiune a sistemului şi sa conţină cel puţin:
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 documentaţie de administrare a fiecărui 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, legături intre tabele, elemente specifice, semnificaţia tabelelor şi
rolul funcţional al fiecăreia, descrierile câmpurilor din fiecare tabela.
• Ghidul de utilizare se adresează utilizatorilor finali ai DES şi specifica, intr-un format
uşor de înţeles, toţi paşii care trebuie urmaţi pentru utilizarea DES. Ghidul de utilizare nu
conţine detalii tehnice. Detaliile funcţionale 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 conţină: lista funcţionalităţilor
nou implementate (sau a celor fixate în noua versiune), precondiţii de instalare a
versiunii, modificări asupra bazei de date (daca e necesar), modificări de configurare,
instrucţiuni de instalare a noii versiuni (instalare manuala şi automata), informaţii speciale
7.2. Servicii de management de proiect
7.2.1. Metodologia de management de proiect
Ofertanţii 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 relaţiilor de lucru cu Beneficiarul, prin aceasta înţelegând întâlnirile
de lucru, metodele de raportare şi modul de colaborare de-a lungul întregului proiectului.
Serviciile PM vor fi implementate de o organizaţie de management a proiectului propusă, cu
roluri de responsabilitate definite atât pentru Ofertantul câştigător, cât şi pentru Beneficiar.
Organizaţia de management de proiect va include cel puţin:
• Un Comitet director - format din membrii ai conducerilor superioare ale tuturor părţilor
implicate (rolurile esenţiale 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 corespunzătoare ale Beneficiarului, care să acopere cel puţin următoarele fluxuri
de lucru PM:
o Managementul comunicării
o Managementul modificărilor
o Management de risc
o Managementul calităţii
o Planificare, managementul timpului şi al resurselor
o Management financiar
Ofertanţii 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 puţin descrierea procedurilor, instrucţiunile de
lucru şi instrumentele care vor fi utilizate, precum şi rolurile din cadrul procedurilor care vor
fi atribuite organizaţiei PM menţionate mai sus.
Metodologia va include cel puţin procedurile care să implementeze următoarele procese:
• Planificare;
• Monitorizare şi control, inclusiv raportare;
• Managementul resurselor;
• Management de risc;
• Managementul modificărilor, inclusiv planificarea comunicării şi a raportărilor;
• Managementul problemelor, inclusiv procedurile de escaladare în ambele părţi ale
organizaţiei PM (Ofertantul câştigător şi Beneficiar)
• Asigurarea calităţii proiectului (planificare, control, acţiuni preventive şi corective, etc.),
Planul preliminar de proiect va trebui să acopere următoarele puncte:
• metodologia de management a proiectului
• organizarea proiectului
• planul de comunicare
• planificarea activităţilor, timpul de desfăşurare şi resursele implicate (un grafic Gantt este
aşteptat)
• planul de livrare, instalare şi implementare (detalierea activităţilor, rezultate aşteptate –
livrabile, documente rezultate şi jaloane de proiect – milestones)
• planul de instruire
• planul de acceptanţă
• planul de întreţinere post-garanţie
• planul de risc pentru fazele proiectului
Serviciile PM vor fi oferite de personalul specializat în PM al Ofertantului. Ofertanţii vor
include în prezentarea echipei de proiect personalul PM propus (cel puţin un Manager de
proiect).
Managerul de proiect de la furnizor trebuie sa fie certificat de către o organizaţie recunoscuta
pe plan internaţional (PMP, PRINCE2 sau echivalent).
7.2.2. Activităţi de management de proiect
În cadrul activităţilor generale de management de proiect, sunt stabilite modalităţile de
organizare şi coordonare a resurselor umane implicate în realizarea activităţilor proiectului.
1. Activităţi de începere a proiectului, constând în:
• Organizarea biroului de proiect şi mobilizarea echipei de management de proiect
• Informarea factorilor interesaţi cu privire la începerea desfăşurării proiectului, la
obiectivele stabilite şi la rezultatele aşteptate şi solicitarea sprijinirii proiectului
2. Activităţi generale de management de proiect (planificare, organizare şi coordonare,
monitorizare şi control, raportare, încheierea proiectului): aspecte de management
financiar, asigurarea vizibilităţii proiectului şi asigurarea calităţii proiectului.
Planificarea activităţilor constă în verificarea şi dacă este necesar actualizarea planurilor
proiectului: planul de activităţi, ca bază generală de implementare, planul de jaloane
(milestones), ca bază de monitorizare, planul activităţilor de achiziţii, planul de informare şi
publicitate, etc.
Organizarea proiectului constă în stabilirea procedurilor de lucru, stabilirea rolurilor şi
limitărilor fiecărei părţi interesate (echipa de management de proiect, beneficiar, furnizori,
etc.) şi a modalităţilor de comunicare, monitorizare şi raportare în cadrul proiectului.
Coordonarea activităţilor constă în antrenarea tuturor părţilor interesate ale proiectului în
realizarea acestuia şi în dezvoltarea şi menţinerea unor bune legături în interiorul şi în afara
proiectului, inclusiv cu alte iniţiative înrudite şi programe şi proiecte destinate aceloraşi
scopuri.
Monitorizarea, controlul şi evaluarea activităţilor vor fi realizate de-a lungul întregului
proiect pentru a putea identifica şi rezolva rapid orice problemă legată de organizarea şi
coordonarea proiectului.
Asigurarea calităţii proiectului urmăreşte realizarea unui sistem eficient de verificare şi
păstrare a documentaţiilor tehnice şi financiare ale proiectului, care să asigure siguranţă şi un
acces facil la aceste documentaţii.
Activităţile de management de proiect trebuie sa acopere cel puţin:
a. coordonarea şi administrarea activităţilor tehnice;
b. coordonarea şi administrarea echipelor de proiect;
c. definirea şi implementarea planului de comunicare în cadrul proiectului;
d. revizuirea şi administrarea modificărilor proiectului;
e. pregătirea şi întreţinerea planul de proiect în care sunt înregistrate activităţile,
sarcinile, termenele de execuţie şi estimările asupra desfăşurării proiectului;
f. organizarea şi conducerea întâlnirilor periodice cu echipa de proiect cu scopul
de a reanaliza starea proiectului;
g. pregătirea rapoartelor periodice; din aceste rapoarte va rezulta progresul
activităţilor, eventualele întârzieri, motivele întârzierilor, riscurile aferente şi
metode sau acţiuni de redresare;
7.2.3. Cerinţe de raportare
• Raport Initial. Acesta va conţine un raport de începere şi un plan detaliat al derulării
activităţilor pentru toate componentele şi fazele proiectului. Termenul de predare va fi de
maximum 4 săptămâni de la începerea proiectului, în vederea revizuirii. Acestea vor
cuprinde în mod obligatoriu următoarele componente:
o Aprecierea privind situaţia existenta cu principalele probleme identificate;
o Definirea şi programarea activităţilor din proiect;
o Organizarea echipei sale;
o Un plan de pregătire detaliat;
o O planificare detaliata a activităţilor proiectului şi contribuţiile pentru întreaga
o perioada de implementare a proiectului;
o Propuneri şi recomandări,
o Pentru elaborarea raportului de începere în termenul stabilit, Beneficiarul va
asigura toate informaţiile necesare Furnizorului.
• Rapoarte de progres. Aceste rapoarte vor fi elaborate trimestrial, informând Managerul de
Proiect al Beneficiarului asupra evoluţiei şi stadiului activităţilor prestate. Rapoartele vor
sublinia activităţile contractorului şi vor descrie stadiul lucrărilor în perioada raportata.
Vor fi identificate problemele, punctele de referinţa şi realizările semnificative.
Rapoartele vor cuprinde următoarele:
o Activitati desfăşurate în timpul perioadei raportate, precum şi progresul
înregistrat, prin comparaţie cu planificarea iniţiala a proiectului (Project plan);
o Dificultăţile întâmpinate în cursul implementării proiectului şi soluţiile propuse
pentru a depăşi respectivele dificultăţi;
o Rezultatele realizate în cursul perioadei de raportare, resursele utilizate, precum şi
recomandările sau solicitările aferente şi planificarea activităţilor proiectului
pentru perioada următoare;
o Activitati planificate pentru perioada următoare de raportare;
o Sumarul controlului schimbărilor proiectului;
o Probleme, riscuri şi recomandări;
Beneficiarul poate să solicite ofertantului să transmită rapoarte de progres intermediare ori de
cate ori reprezentanţii săi identifica în desfăşurarea activitati de implementare anumite
aspecte specifice.
• Rapoarte intermediare. Întrucât sarcinile ofertantului vor fi etapizate, rapoartele
intermediare sunt solicitate pentru informarea Beneficiarului despre rezultatele fiecărei
etape (de exemplu – finalizarea etapei de analiza), soluţiile date şi deciziile majore ce
trebuie luate. Structura acestor rapoarte intermediare va fi stabilita împreuna cu
reprezentanţii Beneficiarului, cu luarea în considerare a aspectelor concrete ale activitati,
în prima şedinţa de proiect.
• Raport final. Acesta trebuie sa fie redactat la sfârşitul perioadei de execuţie. Proiectul
acestuia trebuie transmis cu cel puţin doua săptămâni înainte de sfârşitul perioadei de
execuţie a contractului. El trebuie sa descrie întreg procesul de implementare a
programului şi care va înlesni evaluarea rezultatelor obţinute în termeni atât calitativi, cat
şi cantitativi. Raportul va include de asemenea, o evaluare a succesului proiectului.
• Raportul trebuie sa cuprindă:
o Evaluarea succesului şi constrângerilor majore pentru fiecare activitate şi sarcina;
o Realizările generale ale programului;
o Activitati în derulare cu data estimativa a finalizării acestora şi cu rezultatele
anticipate;
o Recomandări pentru acţiuni viitoare cu scopul asigurării sustenabilităţii
activităţilor programului, rezultatele aşteptate de la acest proiect după finalizarea
lui, precum şi masuri ce trebuie întreprinse de către Solicitanţi şi Utilizatori în
acest sens.
• Rapoartele vor avea o pagina iniţiala ce va include: numele contractului, codul
contractului sau referinţe, 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 solicitării unor clarificări sau a unor modificări. 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 către beneficiar daca acesta nu îl informează expres pe
implementator de existenta oricăror comentarii în termen de 7 zile de la primirea
solicitării scrise.
• In situaţia în care un raport este aprobat de către Beneficiar condiţionat de operarea unor
modificări de către implementator, Beneficiarul va stabili o perioada de efectuare şi
retransmitere a răspunsurilor la clarificări sau a modificărilor solicitate.
8. Cerinţe de administrare, operare şi mentenanţă
8.1. Funcţionalităţi 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 activităţilor şi evenimentelor desfăşurate în
cadrul DES (de la infrastructura la aplicaţie), conform specificului datelor de tip personal
care va fi gestionat de acesta
• O componenta de tip help inclusa in aplicatie pentru toţi utilizatorii sistemului. Acesta va
fi compus din ghiduri si/sau manuale de folosire a aplicaţiei în funcţie 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. Cerinţe mentenanţă
8.2.1. Servicii de suport hardware în garanţie
Mentenanţă hardware va acoperi serviciile de garanţie hardware pentru o durata de 3 ani de la
acceptanta finala şi va pune la dispoziţie servicii de tip Helpdesk şi de remediere a
funcţionalităţii soluţiei, conform nivelului de suport de mai jos.
Pe durata celor 3 ani de garanţie ofertantul va respecta următorul nivel de suport garantat
(SLA –Service Level Agreement):
• Orarul de lucru: 24 ore x 7 zile pe săptămâna, 365 de zile pe an
• Timpul de răspuns 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
• Număr de intervenţii: Nelimitat pe durata perioadei de garanţie
• Piese de schimb: ofertantul va furniza fără costuri suplimentare toate piesele de schimb
necesare (piesele defecte pot fi returnate ofertantului)
Remedierea defecţiunilor hardware se va face prin înlocuirea componentelor defecte cu
componente noi aflate în buna stare de funcţionare şi certificate de către furnizorul de
echipamente.
Serviciile de suport hardware se vor efectua de către echipa de specialişti autorizaţi pentru
servicii de mentenanţă hardware pe platformele respective de către producătorul de
echipamente.
Pentru efectuarea serviciilor de mentenanţă hardware, ofertantul trebuie sa facă dovada
accesului la un stoc de piese corespunzător aflat în tara, cat şi la laboratoare specializate
pentru testarea şi remedierea defecţiunilor de produs, inclusiv îmbunătăţiri aduse
microcodului. în acest sens, ofertantul va furniza o lista a inventarului de piese de schimb
dedicat menţinerii în stare de funcţionare a echipamentelor pe durata celor 3 ani de servicii de
suport în garanţie. Ofertantul va asigura la cerere accesul CNAS la stocul de piese de schimb
în vederea verificării inventarului.
In mod periodic (trimestrial), ofertantul va face o inspecţie tehnica a echipamentelor
hardware şi va întreprinde acţiuni menite a preveni apariţia anumitor evenimente nedorite
(mentenanţă hardware preventiva), acţiuni care vor fi eventual însoţite şi de recomandări
tehnice făcute CNAS pentru optimizarea exploatării sistemului.
8.2.2. Suportul software în garanţie
Suportul software va acoperi serviciile de garanţie software pentru o durata de 3 ani de la
acceptanta finala şi va pune la dispoziţie servicii de tip Helpdesk şi de remediere a
defecţiunilor software apărute la produsele software livrate, conform nivelului de suport de
mai jos
Pe durata celor 3 ani de garanţie ofertantul va respecta următorul nivel de suport software
garantat (SLA –Service Level Agreement):
• Orarul de lucru: 24 ore x 7 zile pe săptămâna, 365 de zile pe an
• Timpul de răspuns 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
• Număr de intervenţii: Nelimitat pe durata perioadei de garanţie
Remedierea defecţiunilor software se va face prin acţiuni de aplicare de corecţii software, de
reconfigurare, de restaurare de date sau alte acţiuni menite sa restabilească funcţionalitatea
produsului respectiv în cel mai scurt timp posibil.
Serviciile de suport software vor fi furnizate de către specialişti cu pregătire şi experienţa pe
produsele respective. în cazul unor probleme de dificultate ridicata, suportul trebuie sa
asigure şi escaladarea problemei la producător, pentru o diagnosticare cat mai rapida şi
eficienta şi chiar intervenţia la sediul CNAS.
9. Testarea, instalarea, punerea în funcţiune şi recepţia sistemului
9.1. Cerinţe globale
• Instalarea si punerea in funcţiune a sistemelor de operare, a pachetelor de programe
necesare si a fiecărui modul în parte al aplicaţiilor la nivel de servere şi staţii de lucru, va
fi realizată de către personalul Furnizorului împreuna cu reprezentanţii Beneficiarului.
Beneficiarul va asigura condiţiile tehnice pentru desfăşurarea în bune condiţiuni a acestor
activităţi pe amplasamente.
• Instalarea sistemului se va face în termen de maximum 30 zile calendaristice de la data
livrării software-ului aferent, în conformitate cu Graficul de livrare şi de prestare a
activităţilor.
• Testarea sistemului va fi efectuată împreună cu personalul de specialitate al
Beneficiarului, instruit în prealabil de Furnizor.
• Termenii şi condiţiile de testare a sistemului sunt cei descrişi în Anexa Planurile de
testare livrate şi acceptate de Beneficiar.
• Punerea în funcţiune a modulelor şi a întregului sistem se va face de către specialiştii
Furnizorului, în prezenţa specialiştilor Beneficiarului. Responsabilitatea pentru aceste
activităţi revine integral Furnizorului.
Fiecare fază se va finaliza cu o acceptanţă parţială şi semnarea unui Proces-verbal semnat de
ambele părţi.
După realizarea testelor de acceptanţă pentru întregul sistem se va semna acceptanţa finală,,
moment în care sistemul va intra în producţie şi va începe perioada de garanţie si mentenanţă.
9.2. Organizarea activităţii de testare
Ofertantul va efectua un ciclu de testare normal al aplicaţiilor, conform ciclului
standard in „V”, respectiv va acoperi următoarele 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 cerinţelor funcţionale (scenarii de utilizare) şi non-funcţionale (securitate,
performanţă, disponibilitate, etc), din punct de vedere al testării.
Ofertantul va descrie modul de organizare a activităţii de testare precum şi platforma de
testare utilizată, inclusiv aspecte legate de ;
o Gradul de acoperire a verificării cerinţelor;
o Automatizarea activităţii de testare;
o Testarea de regresie;
o Testarea non-funcţională (performanţă, securitate, disponibilitate);
o Documentarea şi monitorizarea testării.
9.3. Organizarea certificării (testării de conformitate a)
aplicaţiilor client
Începerea desfăşurării în producţie 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 cerinţele DES (funcţionalitate, securitate).
CNAS va selecta un grup ţintă corespunzător şi semnificativ pentru a constitui grupul iniţial
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, incluzând:
o calendarul de certificare (conform cu cerinţele CNAS);
o organizarea platformei de certificare;
o canalele de comunicare cu fiecare FSM;
o planul de teste de certificare;
o condiţii obligatorii la nivel FSM pentru a începe executarea testării;
o rapoarte de certificare.
Strategia de certificare va fi definitivată ca activitate în proiect.
Ofertantul va asista CNAS în executarea activităţii de certificare propriu-zise, ca activitate a
acestui proiect.
10. Cerinţe de instruire a utilizatorilor
10.1. Instruire
Ofertantul va avea în vedere următoarele obiective ale activităţii de instruire;
o pregătirea unui număr de utilizatori cheie ai beneficiarului care să poată disemina în
teritoriu utilizarea optimă a sistemului;
o accesibilitatea cursurilor de către orice utilizator potenţial al sistemului (de exemplu în
format manual electronic, instruire la distanţă, etc);
o monitorizarea şi îmbunătăţirea eficienţei instruirii, pe parcursul desfăşurării proiectului.
10.2. Cerinţe generale
Ofertantul trebuie să livreze următoarele livrabile de instruire:
• Metodologia de instruire se va furniza în etapa de iniţiere a proiectului, va conţine
tipurile de instruire, abordarea metodologică, numărul de angajaţi care urmează a fi
instruiţi, numărul şi cerinţele referitoare la instructori, programul general de instruire,
condiţiile şi cerinţele 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 cerinţele de
instruire, lista materialelor de instruire, listele de prezenţă, datele persoanelor de contact,
alte documente pentru facilitarea organizării şi desfăşurării cursurilor;
• Materialele de instruire (pe hârtie / în format electronic) vor include cel puţin:
o Prezentări (in format de prezentare electronica, „slide show”);
o Suportul de curs tipărit pentru fiecare participant la instruire;
o Suportul de curs, in format electronic, pentru învăţare individuală şi alte activităţi
de instruire
• Certificat de instruire: atestă finalizarea de către fiecare cursant, în bune condiţiuni, a
instruirii respective
o Ofertantul trebuie să asigure instructori adecvaţi, bine pregătiţi şi personalul de
suport necesar pentru instruire, conform Conceptului de Instruire şi Planului de
Instruire detaliat acceptate;
o Instruirea va fi în limba română, susţinută de către instructori autorizaţi. În cazul
instruirilor de produs, furnizorul instruirii va trebui să posede o autorizare din
partea producătorului produselor software respective;
o Instruirile trebuie să fie documentate prin Rapoarte de instruire şi prin condicile de
prezenţă completate. Începerea implementării nu este condiţionata de finalizarea
cursurilor.
10.3. Cerinţe specifice
• Sistemul DES va conţine un manual electronic de utilizare, disponibil pe portalul de
aplicaţie, destinat tuturor categoriilor de utilizatori;
• Instruire utilizatori sistem DES:
o Cursuri de utilizare a aplicaţiilor DES în regim TTT (train-the-trainer), pentru câte
2 reprezentanţi ai Beneficiarului, din fiecare judeţ. Acest curs se va desfăşura în
serii de maximum 20 de persoane;
o Cursuri de utilizare a aplicaţiilor DES în regim de instruire la distanţă (eLearning).
Cursurile vor putea fi descărcate de pe site-ul web al CNAS şi rulate individual,
de către fiecare utilizator potenţial, pe o staţie de lucru locală (PC).
• Instruire tehnică DES:
o Produs – cursuri standard de produs adresate specialiştilor IT. Vor fi susţinute
cursuri de administrare pentru produsele software incluse in oferta. Vor fi
susţinute cursuri standard ale producătorului produselor software, aşa cum se
regăsesc descrise pe site-ul public al acestuia. Numărul de participanţi va fi de
maxim 10 pentru fiecare dintre sesiunile de curs;
o Suport – cursuri personalizate destinate personalului care va întreţine 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
