Specificatie Interfatare SIUI - Aplicatii de Raportare Pentru Furnizori

CASA NAIONAL DE ASIGURRI DE SNTATE
SISTEM INFORMATIC UNIC INTEGRAT

AL ASIGURRILOR DE SNTATE DIN ROMNIA
Specificaii de interfaare cu SIUI pentru aplicaiile de raportare

ale furnizorilor de servicii medicale i farmaceutice
ISTORICUL REVIZIILOR DOCUMENTULUI
Versiune Data Comentarii
1.0 (DRAFT) 10.10.2006 Versiune iniial
1.0 (RELEASE) 30.11.2007 Versiune publicat - conform Contract Cadru i Norme 2007
1.0.1 (RELEASE) 03.12.2007 Versiune publicat restructurat conform observaiilor CNAS
1.0.2 (RELEASE) 12.03.2008 Versiune actualizat i completat
1.1 (RELEASE) 06.05.2008 Versiune actualizat - conform Contract Cadru i Norme 2008
2.0 (RELEASE) 29.11.2010 Versiune publicat - SIUI-Actualizat : Centralizare i validare online
2.0.1 (RELEASE) 08.03.2011 Versiune actualizat - SIUI-Actualizat : Detaliere procedur conectare online
2.0.2 (RELEASE) 01.06.2011 Versiune actualizat - SIUI-Actualizat : Detaliere algoritmi semnare electronic
Versiunea 2.1 din 01.08.2011 Pagina 2 din 56

CUPRINS
Istoricul reviziilor documentului ............................................................................................................................. 2

CUPRINS ......................................................................................................................................................................... 3
TABELA DE FIGURI ........................................................................................................................................................... 6
1. INTRODUCERE .............................................................................................................................................................. 7
2. PREZENTARE GENERAL SIUI ....................................................................................................................................... 9
2.1. Descrierea sistemului informatic al asigurrilor de sntate din Romnia ................................................. 9
2.1.1. Nivelul de baz ......................................................................................................................................... 10
2.1.2. Nivelul central .......................................................................................................................................... 11
2.2. Descrierea interfeelor SIUI ........................................................................................................................... 12
2.2.1. Interfeele cu furnizorii de servicii medicale i farmaceutice ............................................................... 12
2.2.2. Interfeele cu alte instituii ...................................................................................................................... 13
2.3. Asigurarea securitii informaiei .................................................................................................................. 13
2.3.1. Autentificarea i autorizarea prin certificate digitale ............................................................................ 15
2.3.2. Semntura digital................................................................................................................................... 17
2.4. Clasificarea transferurilor de date ................................................................................................................ 18
2.4.1. Transfer unilateral - descrcare (download) ......................................................................................... 18
2.4.2. Transfer unilateral - ncrcare (upload) ................................................................................................. 18
2.4.3. Transfer bilateral ..................................................................................................................................... 18
3. DESCRIEREA FLUXULUI DE LUCRU ................................................................................................................................ 20
3.1. Personalizarea i activarea aplicaiei ............................................................................................................ 20
3.1.1. ncheierea contractului cu CAS pentru furnizare de servicii ................................................................ 20
3.1.2. Furnizarea cheii de activare a aplicaiei informatice de raportare ....................................................... 20
3.1.3. Activarea aplicaiei folosind cheia de activare ....................................................................................... 20
3.2. Fluxul de raportare periodic .......................................................................................................................... 21
3.2.1. Colectarea datelor ................................................................................................................................... 21
3.2.2. Raportarea electronic ............................................................................................................................ 21
3.2.3. Preluarea rezultatelor raportrii ............................................................................................................ 21
3.2.4. Corectarea erorilor de raportare ............................................................................................................ 21
3.2.5. Tiprire formulare de raportare ............................................................................................................. 22
3.2.6. Depunere formulare de raportare .......................................................................................................... 22
3.2.7. Preluare decont ....................................................................................................................................... 22
3.3. Funcionaliti de validare online .................................................................................................................. 22
3.3.1. Verificarea calitii de asigurat ............................................................................................................... 22
3.3.2. Validarea micrilor de capitaie ............................................................................................................ 23
3.3.3. Validarea serviciilor i investigaiilor medicale ..................................................................................... 23
3.3.4. Validarea documentelor medicale .......................................................................................................... 23
3.3.5. Validarea reetelor eliberate de farmacii ............................................................................................... 25
3.3.6. Consultarea documentelor medicale prescrise..................................................................................... 25
3.3.7. Consultarea deciziilor de acordare de ngrijiri la domiciliu sau dispozitive medicale......................... 26
3.4. Actualizri care privesc aplicaiile de raportare ........................................................................................... 26
3.4.1. Actualizarea nomenclatoarelor............................................................................................................... 26
3.4.2. Actualizarea datelor de contract ............................................................................................................. 27

4. PREZENTARE GENERAL A SERVICIILOR WEB ................................................................................................................ 28

4.1. Scurt prezentare ........................................................................................................................................... 28
4.2. Tehnologia Serviciului-Web ........................................................................................................................... 28
4.3. Arhitectura implementrii Serviciului-Web SIUI .......................................................................................... 29
5. DESCRIEREA SERVICIILOR WEB EXPUSE ........................................................................................................................ 31
5.1. Serviciul pentru sincronizarea nomenclatoarelor ........................................................................................ 34
5.1.1. Metoda g e t Ca ta l og ue s ......................................................................................................................... 34
5.1.2. Instruciuni de folosire............................................................................................................................. 34
5.1.3. Observaii .................................................................................................................................................. 35
5.2. Serviciul pentru sincronizarea datelor de personalizare ............................................................................. 35
5.2.1. Metoda g e tP r o v id er I nfo ....................................................................................................................... 35
5.2.3. Observaii .................................................................................................................................................. 37
5.3. Serviciul pentru trimiterea raportrilor periodice ........................................................................................ 37
5.3.1. Metoda s e nd Re po r t ............................................................................................................................... 37
5.3.3. Observaii .................................................................................................................................................. 38
5.3.4. Raportri speciale .................................................................................................................................... 39
5.4. Serviciul pentru preluarea rezultatelor raportrilor periodice ................................................................... 39
5.4.1. Metoda g e tR epo r tF ee dba c k ............................................................................................................... 39
5.4.3. Observaii .................................................................................................................................................. 40
5.5. Serviciul pentru preluarea decontului ........................................................................................................... 40
5.5.1. Metoda g e tR ef u nd ................................................................................................................................. 41
5.5.2. Metoda g e tR ef u ndF o rI n vo ic e ............................................................................................................. 41
5.5.3. Metoda g e tR ef u ndF o rP h ys ic ia n ........................................................................................................ 42
5.5.5. Observaii .................................................................................................................................................. 43
5.6. Serviciul pentru sincronizarea deciziilor de acordare .................................................................................. 43
5.6.1. Metoda g e tD ec i sio n s ............................................................................................................................ 43
5.6.3. Observaii .................................................................................................................................................. 44
5.7. Serviciul pentru verificarea calitii de asigurat ........................................................................................... 45
5.7.1. Metoda g e tI n s ur ed ................................................................................................................................ 45
5.7.3. Observaii .................................................................................................................................................. 46
5.8. Serviciul pentru validarea micrilor de capitaie ........................................................................................ 46
5.8.1. Metoda va l i da te E nl is te d ...................................................................................................................... 46
5.8.3. Observaii .................................................................................................................................................. 47
5.9. Serviciul pentru validarea serviciilor i investigaiilor medicale ................................................................. 47
5.9.1. Metoda va l i da te Re p o r t ......................................................................................................................... 47
5.9.3. Observaii .................................................................................................................................................. 49
5.10. Serviciul pentru validarea reetelor prescrise ............................................................................................ 49
5.10.1. Metoda va l ida t eP r esc ri p tio n ............................................................................................................ 49
5.10.2. Instruciuni de folosire........................................................................................................................... 50
5.10.3. Observaii ................................................................................................................................................ 50
5.11. Serviciul pentru validarea biletelor de trimitere ........................................................................................ 50
5.11.1. Metoda va l ida t e Cl i ni c R efe rr a l ........................................................................................................ 51
5.11.2. Metoda va l ida t e La bR efe r ra l ............................................................................................................ 51
5.11.4. Observaii ................................................................................................................................................ 51
5.12. Serviciul pentru validarea certificatelor medicale ..................................................................................... 52
5.12.1. Metoda va l ida t e Si c k L ea v e ................................................................................................................ 52

5.12.3. Observaii ................................................................................................................................................ 52

5.13. Serviciul pentru validarea reetelor emise de farmacii.............................................................................. 53
5.13.1. Metoda va l ida t eF a rm a cy D ru gs ........................................................................................................ 53
5.13.3. Observaii ................................................................................................................................................ 53
5.14. Serviciul pentru consultarea reetelor prescrise ....................................................................................... 54
5.14.1. Metoda ge tP re sc ri p tio n ..................................................................................................................... 54
5.14.3. Observaii ................................................................................................................................................ 54
5.15. Serviciul pentru consultarea biletelor de trimitere .................................................................................... 55
5.15.1. Metoda ge t Cl in ic R efe rr a l ................................................................................................................. 55
5.15.2. Metoda ge t La bR ef er ra l ...................................................................................................................... 55
5.15.4. Observaii ................................................................................................................................................ 56

TABELA DE FIGURI
FIGURA 1 - ARIA DE ACOPERIRE A SISTEMULUI .................................................................................................................. 10

FIGURA 2 - CONECTAREA APLICAIILOR DE RAPORTARE LA SIUI ......................................................................................... 13
FIGURA 3 - DIAGRAMA SOLUIEI DE ASIGURARE A SECURITII DATELOR .............................................................................. 15
FIGURA 4 - ARHITECTURA SERVICIUL-WEB SIUI 2.0 ......................................................................................................... 30

1. INTRODUCERE
Acest document descrie din punct de vedere tehnic modalitile de interfaare cu Sistemul
Informatic Unic Integrat al Casei Naionale de Asigurri de Sntate.
Sistemul Informatic Unic Integrat (SIUI) asigur colectarea, consolidarea i procesarea datelor
din ntregul sistem de asigurri sociale de sntate din Romnia. n acest scop SIUI prevede o
serie de interfee pentru interconectarea cu aplicaiile de raportare ale furnizorilor de servicii
medicale i farmaceutice care au contracte cu Casa Naional de Asigurri de Sntate.
Documentul de fa este destinat productorilor de aplicaii informatice n domeniul medical i
al asigurrilor de sntate pentru a facilita accesul acestora la informaiile tehnice necesare
actualizrii aplicaiilor existente sau dezvoltrii de noi aplicaii n vederea raportrii electronice
ctre SIUI a serviciilor prestate de furnizorii de servicii medicale i farmaceutice.
Documentul de fa face o scurt prezentare a caracteristicilor generale ale sistemului, a
tehnologiilor i componentelor tehnologice utilizate. Sunt descrise apoi fluxul de lucru prevzut
de noul sistem, precum i serviciile Web expuse de acest sistem n scopul asigurrii
interconectrii cu aplicaiile furnizorilor.
Structurile de date ale nomenclatoarelor, fiierelor de personalizare, fiierelor de raportare,
fiierelor de rspuns la raportare i altor fiiere specifice fiecrui tip de furnizor, precum i
descrierea regulilor de validare aplicate la prelucrarea raportrilor fiecrui tip de furnizor sunt
prezentate n anexele la acest document dup cum urmeaz:
Anexa 001 - Descriere_Servicii_WEB.pdf
Pentru aplicaiile de raportare ale furnizorilor de servicii
Anexa 002 - Descriere_Structura_FarmaciiCircuitDeschis.pdf
Pentru aplicaiile de raportare ale farmaciilor cu circuit deschis
Anexa 003 - Descriere_Structura_FarmaciiCircuitInchis.pdf
Pentru aplicaiile de raportare ale farmaciilor cu circuit nchis
Anexa 004 - Descriere_Structura_Spitale.pdf
Pentru aplicaiile de raportare ale spitalelor
Anexa 005 - Descriere_Structura_PNS.pdf
Pentru aplicaiile de raportare ale furnizorilor de servicii medicale care deruleaz Programe
Naionale de sntate
Anexa 006 - Descriere_Structura_MediciFamilie.pdf
Pentru aplicaiile de raportare ale medicilor de familie
Anexa 007 - Descriere_Structura_Clinice.pdf
Pentru aplicaiile de raportare ale ambulatoriilor clinice
Anexa 008 - Descriere_Structura_Paraclinice.pdf
Pentru aplicaiile de raportare ale laboratoarelor de analize i cabinetelor de radiologie i imagistic
Anexa 009 - Descriere_Structura_Stomatologii.pdf

Pentru aplicaiile de raportare ale cabinetelor de medicin dentar
Anexa 010 - Descriere_Structura_ConcediiMedicale.pdf
Pentru aplicaiile de raportare a concediilor medicale pentru medicii care au convenii cu CAS

Anexa 011 - Descriere_Structura_RecuperareAmbulatorii.pdf

Pentru aplicaiile de raportare ale ambulatoriilor de recuperare
Anexa 012 - Descriere_Structura_RecuperareSanatorii.pdf
Pentru aplicaiile de raportare ale sanatoriilor de recuperare i preventoriilor
Anexa 013 - Descriere_Structura_DispozitiveMedicale.pdf
Pentru aplicaiile de raportare ale furnizorilor de dispozitive medicale
Anexa 014 - Descriere_Structura_IngrijiriDomiciliu.pdf
Pentru aplicaiile de raportare ale furnizorilor de ngrijiri la domiciliu
Anexa 015 - Descriere_Structura_Ambulante.pdf
Pentru aplicaiile de raportare ale furnizorilor de asisten medical de urgen prespitaliceasc i
transport sanitar
Anexa 016 - Descriere_Structura_Dializa.pdf
Pentru aplicaiile de raportare ale unitilor private de hemodializ
Acest document sau anexele sale vor fi actualizate i publicate n timp util ori de cte ori va fi
necesar pe parcursul funcionrii Sistemului Informatic Unic Integrat al Casei Naionale de
Asigurri de Sntate, pentru a asigura att meninerea n concordan cu modificrile
legislative din domeniu, ct i interoperabilitatea permanent a aplicaiilor de raportare
dezvoltate de ali productori de aplicaii informatice.

2. PREZENTARE GENERAL SIUI
2.1. DESCRIEREA SISTEMULUI INFORMATIC AL ASIGURRILOR DE SNTATE DIN

ROMNIA
Sistemul Informatic Unic Integrat (SIUI) al Asigurrilor de Sntate este utilizat de Casa
Naional de Asigurri de Sntate (CNAS) i de Casele de Asigurri de Sntate (CAS) din
teritoriu pentru ndeplinirea funciilor specifice de gestionare a cheltuirii bugetului asigurrilor
de sntate.
SIUI este realizat utiliznd o arhitectur centralizat, cu baz de date unic, datele stocate fiind
accesate prin intermediul unei ferme de servere de aplicaie. Colectarea i prelucrarea datelor
sistemul informatic se realizeaz n baza de date centralizat, prezentnd ns seturi diferite de
funcionaliti, i anume:
- Funcionaliti specifice Casei Naionale de Asigurri de Sntate (CNAS);
- Funcionaliti specifice Caselor Judeene de Asigurri de Sntate (CAS):
o 41 de Case Judeene de Asigurri de Sntate
o Casa de Asigurri de Sntate a Municipiului Bucureti
- Funcionaliti specifice furnizorilor de servicii medico-farmaceutice..
La nivelul CNAS se pot accesa toate datele din baza de date centralizat: att datele proprii, ct
i cele de la CAS-uri.
La nivelul CAS nu sunt accesibile toate datele din baza de date centralizat, acestea sunt
prefiltrate, astfel nct sa fie vizibile doar datele proprii.
La baza sistemului se afl furnizorii de servicii medicale i farmaceutice, care colecteaz i
prelucreaz informaiile medicale primare specifice asiguratului, ct i informaiile cu caracter
administrativ care vor sta la baza decontrii serviciilor prestate de furnizorii de servicii
medicale i Casele Judeene de Asigurri de Sntate.
Pentru furnizorii de servicii medico-farmaceutice sistemul prevede posibilitatea de acces
securizat online la aplicaiile prevzute, prin intermediul internetului, acest document
prezentnd detalii tehnice cu privire la modul de acces al acestor funcionaliti.
n Figura 1 este prezentat structura i aria de acoperire a sistemului informatic.

Figura 1 - Aria de acoperire a sistemului
2.1.1. Nivelul de baz

La nivelul de baz se afl diversele categorii de furnizori cu care sistemul (SIUI) opereaz
schimburi de date:
- furnizorii de servicii medicale
- furnizorii de dispozitive medicale
- furnizorii de medicamente i servicii farmaceutice
Pentru toate tipurile de furnizori exist aplicaii informatice prin care acetia pot raporta ctre
nivelul central serviciile prestate sau produsele furnizate i pot prelua de la nivelul central
setul de informaiile necesare nregistrrii datelor primare i efecturii raportrilor. Aceste
aplicaii vor fi numite n continuare Aplicaii de raportare.
Pentru nivelul de baz, sistemul ofer interfee programatice de colectare i validare a datelor.
Prin intermediul acestor interfee se pun la dispoziia furnizorilor de servicii medicale i
farmaceutice toate informaiile necesare cum ar fi cataloagele de servicii i de medicamente,
dar i datele de contract relevante ale furnizorului precum tarife contractate sau medici
angajai, pentru a face posibil nregistrarea i raportarea datelor ctre nivelul central.
Prin intermediul acestor interfee se creeaz mecanisme prin care datele despre serviciile
prestate de fiecare furnizor de servicii medicale i farmaceutice se transfer, n format
electronic n SIUI. Transferul poate fi fcut online, prin comunicaie electronic direct
securizat, sau offline, pe un suport de stocare mobil. De asemenea exist posibilitatea
interogrii sistemului de ctre furnizorii de servicii medicale i farmaceutice pentru a
sincroniza datele din aplicaia de raportare cu rezultatele prelucrrii acestor raportri la nivel
CJAS, prin transmiterea erorilor detectate ctre fiecare furnizor de servicii medicale i
farmaceutice.

2.1.2. Nivelul central

Aplicaia SIUI, dei are o baz de date centralizat ofer funcionaliti diferite pentru cele dou
niveluri ierarhice teritoriale ale CNAS, nivelul caselor judeene (CJAS) i nivelul casei naionale
(CNAS). Prezentm n continuare diferenierea acestor funcionaliti n funcie de nivelul
ierarhic al utilizatorilor, pentru o mai bun nelegere a modului de operare al sistemului.
Nivelul CJAS
La nivel CJAS se vor consolida toate informaiile de interes pentru sistemul informatic integrat
de la nivel judeean. Aceste informaii pot proveni fie, pe un flux informaional prestabilit, prin
transfer de date n format electronic, de la nivelul de baz, fie se pot opera cu ajutorul
interfeelor puse la dispoziie de sistem. La acest nivel sunt implementate regulile de
prelucrare a datelor care intr n sistem, indiferent de modalitatea lor de provenien.
De asemenea, acest nivel este responsabil cu gestionarea comunicrii cu partenerii de sistem
de la nivelul inferior, acetia neavnd acces direct la nivel CNAS. n concluzie, majoritatea
funcionalitilor sistemului vor fi implementate la nivel judeean, acesta fiind nivelul n care
informaiile sunt prelucrate, iar n urma prelucrrii vor fi obinute datele de ieire din sistem
ctre nivelul inferior. Fiecare proces identificat la nivel CJAS are un corespondent la nivel
CNAS, sistemul consolidnd la nivel CNAS toate informaiile de interes, prelucrate de la toate
CJAS-urile, stabilindu-se astfel un flux informatic care propag informaiile de la nivel CJAS la
nivel CNAS.
Fluxurile de date de acest nivel al sistemului informatic integrat sunt legate att de datele
necesare activitii specifice (gestiunea contribuabililor, gestiunea fondului asigurrilor sociale
de sntate, gestiunea asigurailor i gestiunea furnizorilor de servicii medicale i
farmaceutice) ct i de datele necesare sistemului ERP.
Nivelul CNAS
Acest nivel are 2 mari categorii de funcionaliti fiecare cu propriul flux de date.
Prima o constituie elaborarea normelor care guverneaz sistemul. La acest nivel se stabilesc
criteriile de evaluare a furnizorilor de servicii medicale i farmaceutice, contractele cadru
conform crora se vor presta i deconta serviciile medicale i farmaceutice precum i care sunt
aceste servicii. Toate aceste elemente constituie o parte din regulile de funcionare a
Sistemului Informatic Unic Integrat al Asigurrilor de Sntate din Romnia, i pot fi denumite
generic cataloage sau nomenclatoare. Aceste informaii sunt transmise prin intermediul unui
flux informaional ctre nivelul CJAS care, la rndul su, prin intermediul altui flux
informaional va transmite datele de interes la nivelul furnizorilor de servicii medicale i
farmaceutice.
A doua categorie de funcionaliti ale acestui nivel o constituie funcionalitile de prelucrare a
informaiilor de la nivel naional, fie n vederea validrii informaiilor de la nivel judeean, fie n
vederea prelucrrii statistice a informaiilor din sistem. Fluxul informaional care deservete
aceste funcionaliti pleac de la nivel CJAS i se caracterizeaz prin transmiterea la nivel
CNAS a tuturor informaiilor de interes n vederea prelucrrii lor centralizat, la nivel naional.

2.2. DESCRIEREA INTERFEELOR SIUI

Sistemul informatic integrat este prevzut cu interfee de comunicare cu exteriorul prin care se
face transfer de date n format electronic. Aceste interfee se mpart n 2 mari categorii:
- interfee cu furnizorii de servicii medicale i farmaceutice
- interfee cu alte instituii.
2.2.1. Interfeele cu furnizorii de servicii medicale i farmaceutice

Pentru a rezolva problemele legate de transferul de informaii, n format electronic, cu
furnizorii de servicii medicale i farmaceutice, dar i cu angajatorii, au fost dezvoltate interfee
cu fiecare categorie de parteneri.
O prim funcionalitate este actualizarea informaiilor necesare la nivelul partenerilor, pentru
buna desfurare a activitii cu informaii actuale din SIUI. Aceasta este o funcionalitate
general a acestor interfee necesar tuturor categoriilor de parteneri. Informaiile care se
sincronizeaz sunt legate de contractele n vigoare dintre fiecare furnizor de servicii medicale
i farmaceutice i CJAS, de serviciile medicale i farmaceutice pe care fiecare furnizor le poate
presta, de cataloagele specifice fiecrei categorii i de alte nomenclatoare generale gestionate
la nivel CNAS (de exemplu, nomenclatoare de localiti, de strzi, etc.).
O alt funcionalitate este raportarea serviciilor prestate de fiecare furnizor de servicii medicale
i farmaceutice. Este tot o funcionalitate general, acesta fiind scopul principal al interfeelor
dintre SIUI i furnizorii de servicii medicale i farmaceutice.
Pentru transmiterea rezultatului prelucrrii i validrii serviciilor raportate de furnizorii de
servicii medicale i farmaceutice n SIUI, napoi ctre fiecare furnizor a strii de validare i a
eventualelor erori detectate, este definit o alt funcionalitate, de sincronizare a rezultatului
prelucrrilor raportrilor. n acest mod fiecare furnizor de servicii medicale i farmaceutice este
informat despre serviciile care pot fi decontate i care nu pot fi decontate, crendu-se astfel
premisele controlului de ctre furnizorii de servicii medicale i farmaceutice a sumelor
ncasate din fondul naional al asigurrilor de sntate.
Exist si funcionaliti specifice anumitor categorii de furnizori de servicii medicale i
farmaceutice cum ar fi medicii de familie care sunt obligai s raporteze asiguraii aflai pe
listele lor, micrile acestora sau schimbarea categoriei de asigurat, sau furnizorilor de
dispozitive medicale care pot descrca din SIUI informaii referitoare la deciziile de acordare
aprobate la CJAS.
Prin intermediul acestor interfee se pot transfera informaii legate de reetele prescrise de
medici i de biletele de trimitere eliberate de acetia. Aceste informaii pot fi coroborate cu
raportrile farmaciilor despre reetele eliberate sau cu raportrile furnizorilor de servicii
medicale care presteaz serviciile prevzute n biletele de trimitere. Pentru farmacii este
definit o interfa special pentru interogarea informaiilor referitoare la reetele prescrise.
O noutate adus de versiunea 2.0 a SIUI este introducerea posibilitii de a valida online, nainte
de raportarea final, eligibilitatea serviciilor declarate de furnizori precum i calitatea de
asigurat a unui beneficiar de servicii medicale sau farmaceutice permind astfel medicilor i
farmacitilor s lucreze cu date actualizate n timp real la nivel naional, reducnd astfel
posibilitatea prestrii de servicii care nu vor fi decontate ulterior.

Figura 2 - Conectarea aplicaiilor de raportare la SIUI
OBSERVAIE
Conexiunea prin Internet la SIUI va fi posibil doar n mod securizat folosind
protocolul HTTPS/SSL i un certificat digital calificat, utilizat la autentificarea i
autorizarea accesului online la sistem, precum i la semntura electronic.
2.2.2. Interfeele cu alte instituii

Prin aceste interfee se transfer, conform unor protocoale de comunicaie, datele necesare
sistemului informatic integrat pentru desfurarea n bune condiiuni a activitii. Un astfel de
protocol este ncheiat cu Biroul de Eviden Informatizat a Persoanei n care sunt stabilite
datele ce vor fi transferate i structura acestor date. Cu acest partener de sistem se schimb
informaii despre persoanele fizice care pot deveni asigurai i despre persoanele decedate.
Se vor ncheia astfel de protocoale i cu alte instituii din care enumerm: Primriile pentru
asistaii social sau pauperi, Ministerul Muncii i Proteciei Sociale pentru pensionari i
omeri, Inspectoratul de Stat pentru Handicapai pentru persoanele cu handicap, Ministerul
de Finane pentru indicatorii economici necesari fundamentrii bugetului i pentru evidena
contribuabililor, Institutul Naional de Statistic pentru diveri indicatori statistici.
Se preconizeaz, de asemenea ncheierea unui protocol cu ANAF (Agenia Naional de
Administrare Fiscal) prin care se dorete obinerea datelor referitoare la achitarea
contribuiilor la FNUASS pentru validarea calitii de asigurat a beneficiarilor asigurrilor de
sntate.
2.3. ASIGURAREA SECURITII INFORMAIEI

Pentru asigurarea securitii informaiilor transferate ntre aplicaiile de raportare i SIUI se va
folosi o soluie bazat pe o infrastructur cu chei publice (PKI), care utilizeaz criptografia
asimetrica oferind cadrul i serviciile ce pun la dispoziia utilizatorului metode pentru a genera,
distribui, controla, contoriza i revoca certificate cu chei publice.

ntr-un sens mai larg, se poate spune ca PKI integreaz certificatele digitale, criptografia cu
cheie publica i noiunea de autoritate de certificare ntr-o arhitectura de securitate a reelei.
Pentru a stabili un vocabular comun, prezentm n continuare cteva concepte cheie legate de
autentificare prin certificate digitale.
Infrastructura cu chei publice (PKI) arhitectura, tehnicile, practicile i procedurile care
contribuie n mod colectiv la implementarea i funcionarea sistemelor criptografice cu chei
publice, bazate pe certificate; PKI const n hardware si software, baze de date, resurse de
reea, proceduri de securitate i obligaii legale, legate mpreun i care colaboreaz pentru a
furniza i implementa att serviciile de certificare ct i alte servicii asociate infrastructurii (de
ex. marca temporal).
Cheia privat este una dintre cheile asimetrice aparinnd unui utilizator i folosita
numai de acel abonat. n cazul sistemelor cu chei asimetrice, o cheie privat descrie
transformarea de semnare. n cazul sistemului asimetric de criptare, o cheie privat descrie
transformarea de decriptare. Cheia privata este:
1. cheia al crei scop este decriptarea sau crearea de semntur pentru uzul
exclusiv al proprietarului;
2. acea cheie din perechea de chei care este cunoscut numai proprietarului.
Cheia public este una dintre cheile perechii asimetrice ale unui utilizator, care este
disponibil publicului. n cazul sistemelor de criptare asimetric, cheia public definete
transformarea de verificare a semnturii. n cazul criptrii asimetrice, cheia public definete
transformarea de criptare a mesajelor.
Jeton (token) structura de date folosita pentru schimbul dintre entiti i care conine
informaii transformate prin tehnici criptografice. Jetonul este semnat de operatorul unei
Autoriti de nregistrare i poate fi folosit pentru autentificarea deintorului su n relaia sa
cu Autoritatea de Certificare.
Lista de Certificate Revocate (CRL) list emis periodic sau imediat, semnat electronic
de ctre o autoritate, permind identificarea certificatelor care au fost revocate sau
suspendate nainte de expirarea perioadei de validitate. CRL conine numele emitentului su,
data publicrii, data urmtoarei actualizri, numerele seriale ale certificatelor revocate sau
suspendate i datele i motivele revocrii sau suspendrii lor.
Semntur electronic transformarea criptografic a datelor pentru a permite att
verificarea originii i integritii datelor de ctre destinatarul acestora ct i protejarea
expeditorului i a destinatarului mpotriva falsificrii de ctre primitor; semnturile electronice
asimetrice pot fi generate de ctre o entitate prin folosirea unei chei private i a unui algoritm
asimetric, ex. RSA.
Validarea certificatelor de cheie public verificarea strii unui certificat, care permite
stabilirea dac certificatul este revocat sau nu. Aceast problem poate fi rezolvat pe baza
CRL-ului sau printr-o cerere trimis direct prin protocolul OCSP (Online Certificate Status
Protocol). Folosind acest protocol, aplicaiile nu trebuie sa consulte o lista mare (si uneori
neactualizata) de certificate (CRL), ci doar sa trimit o cerere ctre un serviciu bazat pe
protocolul OCSP (conform RFC-2560) pentru verificarea strii certificatului n cauza. OCSP are
dezavantajul ca presupune un acces online la serviciul OCSP.
Beneficiile ce rezult din adaptarea sistemului la modelul PKI sunt:
- ntregul sistem prezint o portabilitate ridicat, utilizatorul avnd acces sigur din diverse
locaii la informaiile sale;

- utilizatorii sistemului vor beneficia de comunicaii sigure i secrete cu ajutorul

capacitilor de criptare;
- sistemul permite att separarea operaiei de identificare i autentificare de operaia de
autorizare, ct i faptul c actele n forma lor clasic (pe suport de hrtie) pot fi nlocuite
cu documente n format electronic.
Procesul de adaptare a unor aplicaii existente i de integrare a acestora ntr-o infrastructur
cu chei publice nu reprezint o operaie banal. Aceasta presupune c aplicaiile sau mediul n
care ruleaz ele s poat: s manipuleze cheile i certificatele n mod sigur; s accepte i s
proceseze certificatele valide; s fie capabile s obin date relevante pentru certificate i
pentru revocarea acestora. Trebuie subliniat diferena dintre o infrastructur cu chei publice
i o aplicaie care este doar capabil s foloseasc serviciile de securitate puse la dispoziie de
aceasta.
Diagrama urmtoare prezint echipamentele, fluxurile informaionale, standardele i
protocoale utilizate pentru realizarea infrastructurii PKI.
Figura 3 - Diagrama soluiei de asigurare a securitii datelor
2.3.1. Autentificarea i autorizarea prin certificate digitale

Pentru a putea accesa online sistemul informatic centralizat SIUI al CNAS, furnizorii de servicii
medicale i farmaceutice vor avea nevoie de certificate digitale emise de o autoritate public de
certificare recunoscut de STS. Fiecare furnizor va trebui s nregistreze certificatele digitale
care vor fi folosite de utilizatorii proprii pentru a accesa SIUI online. Practic vor exista utilizatori
autorizai n SIUI pentru fiecare utilizator al furnizorului, iar acetia vor putea accesa sistemul
online numai prin intermediul certificatului digital. Pentru gestionarea acestor certificate
digitale va fi creat o baz de date dedicat i o aplicaie de administrare care va fi folosit de
operatorii de la Casele de Asigurare Judeene.
Certificatul digital va fi prezent pe calculatorul pe care este instalat aplicaia de raportare i va
fi accesibil aplicaiei prin mijloace de interconectare (instalare pe sistemul de operare sau

acces prin driver sistem la un eToken). Aplicaia va folosi certificatul pentru autentificarea i
autorizarea cererilor online ctre SIUI prin intermediului protocolului HTTPS/SSL.
Poarta de intrare n SIUI va fi un echipament hardware care va juca rolul de firewall,
accelerator SSL i load balancer, dar va realiza i verificarea certificatelor digitale prezentate
de aplicaiile de raportare din punct de vedere al integritii i valabilitii la deschiderea unei
noi sesiuni SSL prin HTTPS.
n urma verificrii integritii i valabilitii certificatului, acceleratorul SSL va transmite mai
departe cererea prin protocol HTTP ctre un server de autentificare i autorizare, parte
integrant a SIUI, nglobnd n header-ul HTTP i informaiile din certificatul digital necesare
pentru verificarea prin OCSP a strii de revocare certificatului digital.
Acest server va verifica n baza de date tampon, dac certificatul digital a fost nregistrat de
ctre un utilizator autorizat al sistemului, iar dac este va formula o cerere prin protocolul
OCSP ctre serviciul pus la dispoziie de STS. Acest serviciu va verifica autenticitatea
certificatului prin interogarea serviciilor similare ale autoritilor de certificare publice cu care
STS are protocoale de comunicare.
Serviciul de Telecomunicaii Speciale ofer ca parte a acestui sistem o component care
permite interogarea simultan a tuturor Autoritilor de Certificare publice din Romnia,
realiznd astfel izolarea sistemului de eventuale modificri ale structurii sau componenei
acestor autoriti. Aceast component va trebui s respecte, la rndul ei, caracteristicile
legate de nalta disponibilitate i scalabilitate la toate nivelurile ale sistemului SIUI.
Dac certificatul digital nu este revocat, atunci serverul de autentificare si autorizare verific n
baza de date tampon dac furnizorul cu care este asociat utilizatorul nu are contractul expirat.
Ulterior transmite aplicaiei de raportare un token software (session-id-hash) care va fi folosit
de aceasta la apelurile urmtoare pe sesiunea SSL curent la sfritul url-ului de apel, pentru
a indica sistemului c sesiunea a fost deja autorizat, evitnd astfel verificarea excesiv a
certificatului care ar putea introduce penalizri de performan semnificative.
Acceleratorul SSL va folosi acest session-id-hash pentru a transmite cererile ulterioare ctre
serverele de aplicaie SIUI. Aici hash-ul va fi verificat i n funcie de drepturile de acces se va
acorda accesul ctre serviciul Web.
n cazul n care unul dintre criteriile de verificare de mai sus nu va fi respectat, atunci sistemul
va ntoarce un mesaj de eroare HTTP corespunztor:
- 401 - Unauthorized: Certificatul este expirat sau revocat, ori utilizatorul nu este autorizat
s acceseze sistemul SIUI.
- 403 - Forbidden: Certificatul este valid, iar utilizatorul este autorizat s acceseze
sistemul online, dar cererea a fost respins datorit lipsei drepturilor de acces la un
anumit serviciu Web sau metod a serviciului Web, de exemplu un medic nu va putea
accesa serviciile destinate farmacitilor.
n acest context prin autentificare se nelege confirmarea identitii declarate a unui utilizator,
iar prin autorizare se nelege procesul de acordare a accesului la resursele informaionale din
sistem numai utilizatorilor, aplicaiilor, proceselor i altor sisteme care dein credenialele
necesare. Practic la autentificare se verific identitatea iniiatorului unei cereri de acces, iar la
autorizare se verific existena unor drepturi pe baza crora se permite sau nu accesul la
resursele cerute.

Pentru a evita verificarea certificatului digital la fiecare apel aplicaia de raportare va trebui sa
implementeze un mecanism de meninere deschise a sesiunii SSL, astfel nct ulterior
autentificrii i autorizrii apelurile ctre serviciul Web s poat fi efectuate direct.
2.3.2. Semntura digital

Semntura electronic reprezint o informaie n format electronic, care este ataat sau logic
asociat unor documente n form electronic, de asemenea, avnd aceeai semnificaie ca i o
semntur olograf. Semnatarul este definit ca fiind acea persoan care deine un dispozitiv de
creare a semnturii electronice i care acioneaz, fie n nume propriu (persoan fizic), fie n
numele unui ter (persoan juridic, de exemplu).
O semntura digital furnizeaz un grad mai mare de securizare dect o semntur olograf.
Destinatarul mesajului semnat digital poate verifica att faptul ca mesajul original aparine
persoanei a crei semntur a fost ataat ct i faptul ca mesajul n-a fost alterat, intenionat
sau accidental, de cnd a fost semnat.
Pentru ca o persoan s poat folosi semntura electronic, este necesar ca n prealabil s
dobndeasc un certificat digital calificat care i atest identitatea. Certificatul digital reprezint
o colecie de date n form electronic i atest legtura dintre datele de verificare a semnturii
electronice i semnatarul ca persoan, confirmnd identitatea acelei persoane. Certificatul
calificat este eliberat de ctre un furnizor de servicii de certificare, legal constituit, numit
autoritate de certificare.
Pentru a garanta non-repudierea datelor raportate n SIUI, fiierele de raportare vor trebui s
fie semnate electronic folosind aceleai certificate digitale ca i pentru autorizarea accesului la
sistem. Prin semnarea electronic a fiierelor de raportare se creeaz premisele eliminrii n
viitor a raportrilor clasice pe hrtie i astfel simplificarea fluxurilor de documente, care va
duce la posibilitatea automatizrii complete a procesului de raportare i decontare.
Pentru ca o persoan s poat folosi semntura electronic, este necesar ca n prealabil s
dobndeasc un certificat digital calificat care i atest identitatea. Certificatul digital reprezint
o colecie de date n form electronic i atest legtura dintre datele de verificare a semnturii
electronice i semnatarul ca persoan, confirmnd identitatea acelei persoane. Certificatul
calificat este eliberat de ctre un furnizor de servicii de certificare, legal constituit, numit
autoritate de certificare.
Fiierele XML generate de aplicaia de raportare vor fi semnate electronic folosind certificatul
digital al utilizatorului care realizeaz raportarea, beneficiind astfel de toate avantajele oferite
de aceast tehnologie. Certificatul digital va fi prezent pe calculatorul pe care este instalat
aplicaia de raportare i va fi accesibil aplicaiei prin mijloace de interconectare (instalare pe
sistemul de operare sau acces prin driver sistem de pe eToken).
Pentru ca fiierul semnat electronic s poat fi raportat online este necesar n prealabil
urmarea pailor din procedura de autentificare i autorizare. Aplicaia va folosi certificatul
pentru a deschide conexiunea online ctre SIUI prin intermediului protocolului HTTPS/SSL.
Dup ce sistemul va verifica certificatele digitale prezentate de aplicaiile de raportare din
punct de vedere al integritii i valabilitii la deschiderea unei noi sesiuni SSL prin HTTPS,
acesta va transmite mai departe cererea prin protocol HTTP ctre o aplicaie Web de
autentificare i autorizare, nglobnd n header-ul HTTP informaiile din certificatul digital
necesare pentru verificarea prin OCSP a strii de revocare certificatului digital.

Aplicaia de autentificare va verifica n baza de date tampon, dac certificatul digital a fost
nregistrat de ctre un utilizator autorizat al sistemului, iar dac este va formula o cerere prin
protocolul OCSP ctre serviciul pus la dispoziie de STS.
Pentru a putea face oricnd dovada motivului de respingere sau invalidare a unei raportri,
sistemul va pstra o arhiv a tuturor fiierelor de raportare care au fost transmise, indiferent
dac semntura a fost sau nu valid.
2.4. CLASIFICAREA TRANSFERURILOR DE DATE

Schimbul de date ntre aplicaiile de raportare i SIUI poate fi clasificat din punct de vedere al
sensului de transfer n trei categorii:
- transfer unilateral download
- transfer unilateral upload
- transfer bilateral upload-download.
2.4.1. Transfer unilateral - descrcare (download)

n aceast categorie se nscriu proceduri ca actualizarea nomenclatoarelor generale,
actualizarea nomenclatoarelor personalizate sau preluarea fiierului de decont. Aceste operaii
presupun emiterea unei cereri ctre serviciul-Web n urma creia acesta valideaz
autenticitatea cererii, proceseaz datele necesare i rspunde prin trimiterea unui URL ctre
fiierului care trebuie descrcat.
Pentru optimizarea performanei sistemului este recomandat implementarea unei proceduri
de descrcare parial cu posibilitatea de reluare n cazul unei ntreruperi de conexiune.
2.4.2. Transfer unilateral - ncrcare (upload)

Aceste operaii presupun trimiterea unui fiier ctre serviciul-Web inclus in cadrul anvelopei
SOAP a mesajului ce conine i datele de identificare a aplicaiei de raportare. Rspunsul de la
Web-service const n validarea primirii fiierului respectiv din punct de vedere al structurii de
date, dar i a autenticitii cererii prin autentificarea aplicaiei furnizor.
Nu exist un exemplu practic pentru acest tip de transfer, dar trebuie s existe implementat
suportul tehnic pentru partea de upload din cadrul transferului bilateral.
2.4.3. Transfer bilateral

Transferul bilateral presupune att o operaie de ncrcare (upload) a unui fiier n serviciul-
Web, ct i a unei operaii de descrcare (download) a unui fiier de rspuns ulterior.
Din punct de vedere al momentului de primire a rspunsului aceste transferuri pot fi clasificate
n sincrone n cazul n care rspunsul vine imediat, n urma prelucrrii cererii, i asincrone n
cazul n care colectarea fiierului de rspuns presupune o conectare ulterioar la serviciul-
Web pentru operaiile care implic procesri de durat sau intervenia unui operator uman
pentru validare manual a cererii.
Exemple de astfel de transferuri sunt procedura de raportare (asincron) i procedura de
sincronizare a cererilor/aprobrilor (sincron).

n primul caz, se trimite un fiier cu raportarea electronic i se primete ca rspuns o validare

a primirii i a autenticitii cererii. Pentru descrcarea fiierului de rspuns se va efectua o
conectare ulterioar.
n al doilea caz, se trimite un fiier care conine cererile care necesit a fi aprobate, iar
rspunsul vine imediat coninnd cererile care au fost aprobate n SIUI, cererile neaprobate
fiind tratate n consecin de aplicaia de raportare.
n contextul adugrii noilor funcionaliti online ale SIUI, de pre-validare a serviciilor i
verificare a calitii de asigurat, transferul sincron va deveni cel predominant datorit gradului
de interactivitate ridicat al noilor funcionaliti care implic obinerea unor rspunsuri la
interogri din partea aplicaiilor de raportare

3. DESCRIEREA FLUXULUI DE LUCRU
n acest capitol sunt prezentate fluxurile de lucru principale de interfaare ntre SIUI i
aplicaiile de raportare pentru furnizori.
3.1. PERSONALIZAREA I ACTIVAREA APLICAIEI

Aceast seciune prezint precondiiile i procedura de populare a bazei de date a aplicaiei de
raportare cu datele din nomenclatoarele unice la nivel naional, dar i cu informaiile existente
n SIUI referitoare la contractul dintre furnizor i Casa de Asigurri de Sntate (CAS).
De asemenea se prezint procedura de activare a aplicaiei prin intermediul unei chei de
activare generat n SIUI, cheie care va fi folosit ulterior pentru autentificarea i autorizarea
accesului aplicaiei la funcionalitile oferite online de SIUI.
3.1.1. ncheierea contractului cu CAS pentru furnizare de servicii

Furnizorul ncheie un contract de furnizare de servicii cu CAS n baza cruia i vor putea fi
decontate serviciile pe care le presteaz n favoarea asigurailor din sistemul naional de
asigurri de sntate. Aceast secven este o condiie obligatorie pentru personalizarea unei
aplicaii de raportare.
3.1.2. Furnizarea cheii de activare a aplicaiei informatice de raportare

n urma ncheierii contractului cu CAS, furnizorul de servicii medicale i farmaceutice va putea
opera schimburi de date cu SIUI - n scopul procesrii electronice automate a datelor
cantitative legate de activitatea desfurat - prin intermediul unei aplicaii informatice de
raportare a activitii.
Prin intermediul interfeelor puse la dispoziie, o aplicaie de raportare va avea acces la datele
particulare de contract ale furnizorului respectiv, precum i ultima versiune complet a
nomenclatoarelor unice naionale de servicii medicale, diagnostice medicale, specialiti
medicale, etc. De asemenea, pentru fiecare aplicaie va fi tiprit o convenie de utilizare care
va conine o cheie de activare (un numr de serie) folosit n cadrul aplicaiei de raportare
pentru autentificarea conexiunii la SIUI prin intermediul serviciilor-Web.
3.1.3. Activarea aplicaiei folosind cheia de activare

Aplicaiile de raportare vor conine o operaiune de activare prin care se va importa ultima
versiune a nomenclatoarelor unice ale SIUI, dar i datele legate de contract pentru a face
posibil validrii datelor introduse n aplicaie nainte de raportare. SIUI 2.0 introduce i
posibilitatea pre-validrii online a serviciilor, precum i a reetelor i biletelor de trimitere,
ceea ce permite interogarea datelor referitoarea la acestea de cei interesai.
La finalul operaiunii de activare se va introduce cheia de activare, cheie care va fi folosit
ulterior ca parol de autentificare a aplicaiei n procesul de comunicaie cu SIUI.

De notat c n lipsa specificrii acestei chei de activare, aplicaia nu va putea fi folosit pentru
efectuarea raportrilor electronice online, aceasta nefiind autorizat s comunice cu SIUI. La
acest lucru se adaug i prezena token-ului cu certificatul digital calificat al utilizatorului
pentru a putea deschide canalul de comunicaie securizat prin HTTPS/SSL.
3.2. FLUXUL DE RAPORTARE PERIODIC

Aceast seciune descrie procedura de raportare ctre SIUI prin intermediul aplicaiilor de
raportare pentru furnizorii de servicii medicale i farmaceutice.
Trebuie remarcate facilitile de raportare oferite de aplicaie pentru utilizatorii care posed
conexiune electronic cu SIUI, funcionaliti care i pierd sensul pentru utilizatorii
neconectai.
3.2.1. Colectarea datelor

Utilizatorul culege datele n vederea raportrii pe ntreg parcursul perioadei de raportare.
Fluxurile de culegerea a datelor precum i volumul de date difer de la un tip de furnizor la
altul. Prezentm aici un flux generic de raportare lunar.
Aplicaia de raportare trebuie s implementeze o serie de validri la introducerea datelor
pentru a uura munca de culegere a datelor i pentru a evita raportri repetate cu date eronate
care vor ngreuna procesul de procesare online a raportrilor (regulile de validare se regsesc
n anexa specific fiecrei categorii de parteneri).
3.2.2. Raportarea electronic

Dup introducerea datelor, utilizatorul efectueaz o raportare electronic, att online prin
serviciul-Web ct i offline pe un mediu de stocare mobil.
Dac utilizatorul nu dispune de conexiune cu SIUI poate salva fiierul de raportare pe un mediu
de stocare mobil i se va prezenta cu acest fiier la casa de asigurri. De regul acest fiier
trebuie nsoit de formularele de raportare tiprite pe hrtie.
3.2.3. Preluarea rezultatelor raportrii

Utilizatorul efectueaz importul rezultatelor raportrii dup ce raportarea a fost prelucrat n
SIUI, att online prin serviciul-Web ct i offline pe un mediu de stocare mobil.
Serviciul-Web de preluare a rezultatelor raportrii permite preluarea fiierului de rspuns
pentru o raportare trimis anterior ctre SIUI. Pentru ca fiierul de rspuns s poat fi
descrcat acesta trebuie s fie salvat ntr-o locaie predefinit pe mediile de stocare ale SIUI,
lucru care se efectueaz automat n urma prelucrrii fiierului de raportare.
3.2.4. Corectarea erorilor de raportare

Utilizatorul vizualizeaz rezultatele raportrii i corecteaz eventualele date invalidate la
raportare, relund practic fluxul de colectare a datelor prin verificarea sau completarea datelor
introduse.
Utilizatorul va trebui s repete acest flux pn cnd raportarea nu mai conine erori
corectabile, n caz contrar CAS nu va deconta dect o parte a serviciilor prestate de furnizor, n
baza regulilor prevzute n actele normative n vigoare.

3.2.5. Tiprire formulare de raportare

Utilizatorul tiprete formularele de raportare dup verificarea rezultatelor raportrii.
Este recomandat ca aceast operaiune s fie efectuat dup corectarea datelor culese prin
validarea acestora n SIUI, prin raportarea electronic.
3.2.6. Depunere formulare de raportare

Furnizorul depune formularele de raportare la casa de asigurri. Odat cu formularele, el
poate depune i factura pentru contravaloarea serviciilor prestate i raportate.
OBSERVAIE
Dac utilizatorii aplicaiei de raportare nu actualizeaz n mod corespunztor
nomenclatoarele sau datele de contract, este posibil ca valorile raportate s difere
considerabil de cele acceptate de SIUI, iar serviciile raportate s fie respinse.
3.2.7. Preluare decont

Utilizatorul descarc online fiierul de decont sau l preia pe suport magnetic de la Casa de
Asigurri dup ce raportarea a fost procesat.
Fiierul de decont nu se import propriu-zis n aplicaie, el fiind un fiier PDF care conine o
sintez a datelor raportate i acceptate de SIUI, date existente deja n baza de date a aplicaiei,
precum i suma final acceptat spre decontare de SIUI n urma procesrii i validrii datelor
raportate.
Exist ns facilitatea de a putea descrca online acest fiier de decont pentru cei care lucreaz
online cu SIUI pentru a evita un drum inutil la Casa de Asigurri.
3.3. FUNCIONALITI DE VALIDARE ONLINE

Funcionalitile descrise n aceast seciune sunt o noutate introdus de versiunea a doua a
SIUI. Ele sunt disponibile numai n varianta de lucru online, prin intermediul serviciului-Web
expus, accesibil prin Internet prin intermediul unei legturi securizate.
Sistemul va permite operatorilor de la CAS trasabilitatea tuturor cererilor de procesare n scop
de a preveni ncercrile de fraudare a sistemului dar i interogarea abuziv.
3.3.1. Verificarea calitii de asigurat

Sistemul permite medicilor i farmacitilor verificarea online a calitii de asigurat a unui
beneficiar de servicii medicale sau farmaceutice. Serviciul-Web primete ca parametru CNP-ul
pacientului i ntoarce ca rspuns un fiier XML care va conine cel puin urmtoarele
informaii:
- Lista categoriilor de asigurat valabile la data interogrii
- Un cod numeric care reprezint starea se asigurat a persoanei
Sistemul va trata i urmtoarele situaii excepionale, caz n care va ntoarce un mesaj
corespunztor:
- Parametrul furnizat nu se poate valida ca CNP
- Persoana nu este nregistrat n sistem

- Persoana figureaz decedat n sistem

Aplicaiile de raportare vor folosi aceast funcionalitate pentru verifica starea de asigurat a
unei persoane, care vor putea astfel asista operatorul precompletnd informaiile
corespunztoare sau vor afia mesaje de avertizare n cazul n care se nregistreaz servicii
pentru persoane neasigurate.
3.3.2. Validarea micrilor de capitaie

Sistemul permite validarea unei cereri de nscriere sau ieire a unui pacient pe lista unui medic
de familie. Sistemul va procesa cererea verificnd respectarea intervalului legal (6 luni) de la
ultima schimbare de ctre pacient a medicului de familie i va transmite un rspuns ctre
medicul de familie coninnd rezultatul operaiei.
Medicul de familie nregistreaz nscrierea a unui pacient n aplicaia de raportare n momentul
n care pacientul o solicit, aplicaia de raportare apeleaz serviciul Web prin care transmite
pentru validare operaiunea, n momentul efecturii acesteia.
Serviciul Web va valida cererea de nscriere a pacientului n lista medicului de familie prin
verificarea regulilor de validare aferente i va transmite un rspuns privind rezultatul operaiei
ctre aplicaia de raportare.
Este permis modificarea acestor informaii de ctre medicul de familie pn la sfritul
perioadei de raportare i ntocmirea decontului per-capita. Pentru re-validarea nregistrrii
modificate aplicaia de raportare va trebui s transmit acelai identificator de nregistrare, n
caz contrar operaia va fi tratat ca o adugare i va fi invalidat.
3.3.3. Validarea serviciilor i investigaiilor medicale

Sistemul permite transmiterea serviciilor prestate pe msur ce acestea sunt nregistrate n
aplicaia de raportare. Coninutul i formatul datelor transmise este specific fiecrui tip de
furnizor i este descris n detaliu n anexele care nsoesc acest document. Ca regul general,
datele transmise din aplicaia de raportare ctre SIUI vor fi validate iar serviciul Web va
ntoarce un rspuns cu privire la rezultatul validrii serviciului medical raportat.
Orice serviciu pre-validat poate fi modificat ulterior de ctre furnizor, n intervalul de timp
alocat raportrilor, conform legislaiei n vigoare, dar nu mai trziu de ntocmirea deconturilor
ctre furnizori. Pentru re-validarea dup modificarea datelor privind serviciului medical
efectuat aplicaia de raportare va trebui s transmit acelai identificator de serviciu, n caz
contrar operaia va fi tratat ca o adugare i va fi invalidat (serviciul medical efectuat i
pstreaz identificatorul unic indiferent de cte ori este modificat).
3.3.4. Validarea documentelor medicale

Sistemul permite raportarea documentelor medicale prescrise sau eliberate de ctre medici
necesare n scopuri de verificarea ncruciat a serviciilor prestate sau a medicamentelor
eliberate beneficiarilor n baza lor. O alt funcionalitate posibil pe baza acestor documente
este interogarea de ctre farmacii, laboratoare sau medici specialiti a datelor prescrise pentru
a realiza n cunotin de cauz serviciile respective.
Documentele medicale care vor putea fi transmise prin acest serviciu vor fi:
- Reetele compensate i gratuite
- Biletele de trimitere ctre specialiti clinice sau investigaii de laborator
- Certificatele de concediu medical

Astfel, aplicaiile de raportare vor avea, pe lng funcionalitile clasice de nregistrare,

validare local i tiprire, funcionalitatea de transmitere a coninutului acestor documente n
format electronic ctre SIUI. Sistemul va stoca toate aceste informaii pentru a permite
consultarea lor de ctre cei crora le sunt adresate.
Validarea reetelor prescrise
Validarea corectitudinii ntocmirii reetei se face dup completarea i transmiterea tuturor
informaiilor necesare legate de reet ctre SIUI, acesta transmind la rndul lui, n urma
procesrii, un mesaj ctre medicul prescriptor cu privire la corectitudinea reetei n ansamblu,
dar i a fiecrui medicament n parte.
Numai reetele validate de SIUI vor fi disponibile pentru interogare de ctre furnizorii de
medicamente i servicii farmaceutice. Identificarea reetelor prescrise n vederea eliberrii
medicaiei se face dup combinaia de cmpuri: serie i numr reet, CNP beneficiar i paraf
medic prescriptor.
Modificarea unei reete prescrise se poate face doar de ctre medicul prescriptor att timp ct
reeta nu a fost eliberat de ctre furnizorul de servicii farmaceutice. n cazul n care un medic
prescriptor aflat on-line va dori s modifice o reet care a fost eliberat, nu va putea salva
modificrile i va primi un mesaj care l va avertiza c reeta a fost eliberat.
Validare biletelor de trimitere pentru specialiti clinice
Sistemul va permite raportarea de ctre un medic emitent a unui bilet de trimitere pentru
specialiti clinice. Medicul completeaz n aplicaia de raportare datele aferente biletului de
trimitere pentru servicii medicale clinice. La salvarea biletului de trimitere se va apela un
serviciu Web prin care SIUI va valida biletul de trimitere conform regulilor de validare definite i
va transmite medicului emitent un mesaj cu rezultatul validrii.
Biletele de trimitere validate de SIUI vor fi disponibile pentru interogare de ctre furnizorii de
servicii clinice de specialitate care presteaz servicii n baza unui bilet de trimitere. Acetia vor
identifica biletele de trimitere n vederea efecturii serviciilor sau consultaiilor prescrise dup
combinaia e cmpuri: serie i numr bilet de trimitere, CNP beneficiar i paraf medic
prescriptor.
Modificarea unui bilet de trimitere se poate face doar de ctre medicul emitent att timp ct
acesta nu face obiectul unui serviciu clinic de specialitate deja prestat. n cazul n care un
medic emitent aflat online va dori s modifice un bilet de trimitere n baza cruia a fost efectuat
un serviciu paraclinic, va primi un mesaj care l va avertiza c biletul de trimitere fost utilizat la
validarea i/sau raportarea lunar a unui serviciu.
Validarea biletelor de trimitere pentru investigaii de laborator
Sistemul va permite raportarea de ctre un medic emitent a unui bilet de trimitere pentru
investigaii de laborator. Medicul va completa datele biletului de trimitere n aplicaia de
raportare, la salvarea biletului de trimitere se va apela serviciul Web prin care se va transmite
ctre SIUI, pentru validare, biletul de trimitere introdus. Serviciul Web va ntoarce un rspuns
cu privire la rezultatul validrii biletului de trimitere emis.
Biletele de trimitere validate de SIUI vor fi disponibile pentru interogare de ctre furnizorii de
investigaii de laborator care presteaz servicii n baza unui bilet de trimitere. Acetia vor
identifica biletele de trimitere n vederea efecturii investigaiilor prescrise dup combinaia e
cmpuri: serie i numr bilet de trimitere, CNP beneficiar i paraf medic prescriptor.
Modificarea unui bilet de trimitere se poate face doar de ctre medicul emitent att timp ct
acesta nu face obiectul unui serviciu paraclinic de laborator prestat. n cazul n care un medic

emitent aflat online va dori s modifice un bilet de trimitere n baza cruia a fost efectuat un
serviciu paraclinic, va primi un mesaj care l va avertiza c biletul de trimitere fost utilizat la
validarea i/sau raportarea lunar a unui serviciu.
Validarea certificatelor de concediu medical
Funcionalitatea va permite unui medic s valideze un certificat de concediu medical prescris,
la salvarea acestuia n aplicaia de raportare a furnizorului, utiliznd un serviciu Web. SIUI va
valida concediul medical i va informa medicul prescriptor despre rezultatul validrii.
Validarea concediilor medicale sa va face conform regulilor de validare specifice, conform
legislaiei n vigoare, i implic verificarea completrii cu date corecte a certificatului, dar i
verificri ncruciate cu certificate emise de ali medici.
3.3.5. Validarea reetelor eliberate de farmacii

O farmacie poate apela un serviciu-Web prin care va transfera date ctre SIUI i care va verifica
compatibilitatea dintre medicamentele prescrise de medic i cele eliberate (calitativ si
cantitativ) precum i validarea ncadrrii n plafonul de decontare contractat cu Casa de
Asigurri. Sistemul va returna un mesaj prin care farmacistul este ntiinat despre rezultatul
validrii operaiunii de validare a eliberrii medicamentelor.
O reet poate fi eliberata, total sau parial, de o singur farmacie. Dup ce reeta a fost
eliberat, nu va mai fi disponibil pentru alte farmacii. Orice modificare a unei reete eliberate
de ctre o farmacie poate fi fcuta exclusiv de farmacia n cauz pn la sfritul intervalului de
timp alocat raportrilor lunare i nainte de ntocmirea decontului.
3.3.6. Consultarea documentelor medicale prescrise

Serviciul Web permite consultarea documentelor medicale prescrise sau eliberate de ctre
medici pentru a face posibil, pe de o parte verificarea existenei documentului n sistem,
preluarea i completarea automat a informaiilor corespunztoare dar i pe de alt parte
validarea c n baza documentului respectiv nu a mai fost deja raportat efectuarea serviciilor
medicale sau farmaceutice prescrise de ctre un alt furnizor.
Documentele medicale care vor putea fi consultate prin acest serviciu vor fi:
- Reetele compensate i gratuite
- Biletele de trimitere ctre specialiti clinice
- Biletele de trimitere ctre investigaii de laborator
Aplicaiile de raportare vor avea posibilitatea de implementare a unor funcionaliti de
preluare automat a coninutului acestor documente n format electronic ctre SIUI. Astfel o
farmacie poate apela serviciul Web pentru a descrca o reet prescris n scopul de a
eliberarea medicamentele aferente. Pentru a putea interoga serviciul-Web este obligatoriu ca
farmacistul s completeze seria i numrul reetei, CNP-ul beneficiarului i parafa medicului
prescriptor, din motive de asigurarea confidenialitii informaiilor i pentru a nu se permite
interogarea abuziv reetelor oricrui beneficiar.
n mod asemntor biletele de trimitere pentru specialiti clinice sau investigaii de laborator
validate de SIUI vor fi disponibile pentru interogare de ctre furnizorii de servicii medicale care
presteaz servicii n baza unui bilet de trimitere. Acetia vor putea interoga i descrca
informaii despre biletele de trimitere pentru investigaii de laborator n vederea efecturii
serviciilor menionate dup combinaia e cmpuri: serie i numr bilet de trimitere, CNP
beneficiar, paraf medic emitent.

3.3.7. Consultarea deciziilor de acordare de ngrijiri la domiciliu sau dispozitive medicale

Serviciul Web permite sincronizarea informaiilor referitoare la deciziile de aprobare ale unor
categorii de servicii, cum ar fi acordarea de dispozitive medicale sau de ngrijiri la domiciliu,
pentru ca aceste informaii s poat fi precompletate de aplicaie.
Serviciul va primi ca parametru de intrare numrul deciziei i codul CAS emitente i va ntoarce
ca rspuns un fiier XML care va conine toate datele necesare nregistrrii corecte la nivelul
aplicaiei de raportare a serviciilor prestate i a dispozitivelor medicale eliberate.
3.4. ACTUALIZRI CARE PRIVESC APLICAIILE DE RAPORTARE

3.4.1. Actualizarea nomenclatoarelor
n cazul unei modificri legislative sau la aprobarea unor noi norme metodologice, CNAS poate
decide modificarea unor nomenclatoare la nivel naional. Aceste nomenclatoare vor trebui
actualizate n SIUI i vor trebui notificai utilizatorii aplicaiilor de raportare pentru a i
actualiza datele.
Procedura de actualizare a nomenclatoarelor este descris n detaliu n cadrul specificaiilor
fiecrei aplicaii de raportare.
Un flux de actualizare a nomenclatoarelor este propus mai jos.
Utilizatorul activeaz opiunea de actualizare a nomenclatoarelor.
Aplicaia afieaz ecranul prin intermediul cruia se poate efectua actualizarea
nomenclatoarelor.
Utilizatorul alege daca actualizarea se va face online sau offline.
1) Actualizare online: Stabilire conexiune cu SIUI
- Aplicaia se conecteaz prin reea la serviciul-Web expus de SIUI.
- Dac nu reuete stabilirea conexiunii cu SIUI aplicaia afieaz mesajul
"Conexiune nereuit".
- Altfel aplicaia cere fiierul de import cu ultima versiune a
nomenclatoarelor.
- Dac nu exist o versiune mai nou dect cea curent aplicaia afieaz
mesajul "Nu exista versiune nou".
- Altfel aplicaia descarc fiierul de import pentru nomenclatoare.
2) Actualizare offline:
- Utilizatorul alege un fiier de import pentru nomenclatoare de pe un
suport de stocare mobil.
Aplicaia valideaz i proceseaz fiierul de import pentru nomenclatoare.
Aplicaia afieaz rezultatul operaiei:
- Succes
- Eroare (mesaj detaliat)
- Anularea operaiei de ctre utilizator
Utilizatorul nchide ecranul.
De remarcat c n cazul lipsei unei conexiuni cu SIUI, furnizorii vor trebui s ridice de la casa de
asigurri pe un suport de stocare mobil fiierele necesare pentru actualizarea
nomenclatoarelor.
n cazul utilizatorilor care posed conexiune, acetia vor putea descrca online coninutul
nomenclatoarelor, dar acest lucru necesit din partea CNAS o dimensionare atent a benzii de
transfer de date disponibil datorit volumelor mari de date care vor trebui descrcate ntr-un
interval relativ scurt de timp.

3.4.2. Actualizarea datelor de contract

n cazul modificrii datelor de contract acestea vor fi operate mai nti n SIUI, iar utilizatorii
aplicaiilor de raportare vor trebui s actualizeze aceste date n cadrul aplicaiilor de raportare
pentru a putea opera conform cu noul contract sau act adiional.
Procedura de actualizare a datelor de contract este descris n detaliu n cadrul specificaiilor
fiecrei aplicaii de raportare.
Un flux de actualizare a datelor de contract este propus mai jos.
Utilizatorul activeaz opiunea de actualizare a datelor de contract.
Aplicaia afieaz ecranul prin intermediul cruia se poate efectua actualizarea
datelor de contract.
Utilizatorul alege daca actualizarea se va face online sau offline.
1) Actualizare online: Stabilire conexiune cu SIUI
- Aplicaia se conecteaz prin reea la serviciul-Web expus de SIUI.
- Dac nu reuete stabilirea conexiunii cu SIUI aplicaia afieaz mesajul
"Conexiune nereuit".
- Altfel aplicaia cere fiierul de import cu datele de contract.
- Dac nu exist un contract valid aplicaia afieaz mesajul "Nu exist un
contract valid".
- Altfel aplicaia descarc fiierul de import pentru datele de contract.
2) Actualizare offline:
- Utilizatorul alege un fiier de import pentru datele de contract de pe un
suport de stocare mobil.
Aplicaia valideaz i proceseaz fiierul de import pentru datele de contract.
Aplicaia afieaz rezultatul operaiei:
- Succes
- Eroare (mesaj detaliat)
- Anularea operaiei de ctre utilizator
Utilizatorul nchide ecranul.
De remarcat ar fi, la fel ca pentru fiierul cu nomenclatoare generale, c n cazul lipsei unei
conexiuni cu SIUI, furnizorii vor trebui s ridice de la casa de asigurri - pe un suport de stocare
informatic - fiierele necesare pentru actualizarea datelor de contract i personalizarea
aplicaiei.
n cazul utilizatorilor care posed conexiune, acetia vor putea descrca online aceste fiiere,
dar acest lucru necesit din partea CNAS o dimensionare atent a benzii de transfer de date
disponibil datorit volumelor mari de date care vor trebui descrcate ntr-un interval relativ
scurt de timp.

4. PREZENTARE GENERAL A SERVICIILOR WEB
Acest capitol prezint pe scurt tehnologia serviciilor-Web detaliind arhitectura de

implementare a acestei tehnologii n cadrul SIUI.
4.1. SCURT PREZENTARE

Un serviciu Web este o colecie de protocoale i standarde folosite pentru schimbul de date
ntre aplicaii sau sisteme. Aplicaii software scrise n limbaje de programare diferite i care
ruleaz pe diverse platforme pot folosi serviciile Web pentru a face schimb de date pe reea, pe
Internet, ntr-o manier asemntoare comunicrii inter-procese pe un singur calculator.
Interoperabilitatea se datoreaz standardelor publice folosite.
Folosite la nceput pentru comunicarea ntre ele i cu clienii, serviciile Web permit
organizaiilor s comunice ntre ele fr a avea cunotine despre sistemele IT ale fiecreia.
Spre deosebire de modelele client/server, asemenea sistemului server Web/pagin Web,
serviciile Web nu furnizeaz utilizatorilor o interfa grafic (GUI). n schimb, serviciile Web
mpart logic, date i procese de business prin intermediul unei interfee programatice, printr-
o reea. Interfaarea se face direct n cadrul aplicaiilor, i nu prin intermediul utilizatorilor.
Programatorii pot astfel s adauge un serviciu Web la un GUI (asemenea unei pagini Web sau a
unui program executabil) pentru a oferi funcionalitate specific utilizatorilor.
Serviciile Web permit diferitelor aplicaii de pe diferite surse s comunice unele cu altele fr
consum de timp, i pentru c toate comunicaiile sunt n XML, serviciile Web nu sunt legate de
alte sisteme de operare sau limbaje de programare.
Principiile din spatele unui serviciu Web sunt simple i nu sunt principii noi n lumea
Internetului. Mai nti furnizorul de serviciu Web definete un format pentru cererile ctre
serviciul su i pentru rspunsurile care vor fi generate de ctre acesta. Dup care, un
program de calculator face o cerere ctre un serviciu Web prin reea i apoi ntr-un final,
serviciul Web realizeaz anumite aciuni, dup care trimite napoi un rspuns.
4.2. TEHNOLOGIA SERVICIULUI-WEB

Termenul de Serviciu-Web descrie o modalitate standardizat de integrare a aplicaiilor bazate
pe Web folosind XML (Extensible Markup Language), SOAP (Simple Object Access Protocol),
WSDL (Web Services Description Language) i UDDI (Universal Description, Discovery and
Integration).
Dac SOAP reprezint mijlocul de comunicare dintre solicitant i furnizorul serviciului, cu
ajutorul WSDL-ului este efectuat descrierea serviciului oferit. Aceast descriere se face
folosind limbajul XML i ofer, practic, documentaia necesar aplicaiilor pentru a comunica
ntre ele n mod automat.

Ceea ce ofer WSDL este n fapt un fel de Curriculum Vitae pentru serviciul oferit; el descrie
ce poate face serviciul respectiv, unde este localizat i cum poate fi invocat. n fapt, descrierea
unui serviciu Web se face printr-un document XML n a crui structur pot fi incluse ase tipuri
de elemente ce pot fi divizate in dou grupuri: definiiile abstracte care includ informaii
despre tipurile de date folosite de serviciu (ntreg, ir de caractere, etc.), mesajele pe care
serviciul le poate accepta i portType-urile - care sunt metodele i procedurile serviciului; i
definiiile concrete, care specific prin legturi tipul de accesare pe care serviciul l accept (de
exemplu, SOAP) i serviciul, care nu este altceva dect o publicare a porturilor definite
anterior.
Pentru a avea valoare practic, un serviciu Web trebuie s fie cunoscut eventualilor si
utilizatori. UDDI este un standard al crui rol este de a oferi un director, o carte de telefoane
cu serviciile disponibile, astfel nct orice aplicaie s poat gsi serviciul adecvat necesitilor
sale. n fapt, acest director ofer informaii despre localizarea geografic, categorizarea
industrial, informaii de contact, precum i informaii tehnice despre serviciile Web oferite.
Pe scurt, XML este folosit pentru a eticheta datele, SOAP la transferul de date, WSDL pentru
descrierea disponibilitii serviciului i UDDI este folosit pentru a lista serviciile disponibile.
Principale avantaje ale utilizrii serviciilor Web sunt:
- folosesc protocoale standardizate (HTTP, SOAP, WSDL);
- nu genereaz dependen de un anumit limbaj de programare sau platform pentru
aplicaiile client;
- vechile metode de comunicare (RPC, CORBA, RMI si DCOM) generau o interdependena
ntre aplicaia client i aplicaia server. Utiliznd serviciile Web aceasta dependen este
eliminat, serverul poate fi modificat fr modificarea clientului (att timp ct interfaa
expus nu este modificat);
- accesul la serviciile Web poate fi securizat, ca n orice alt aplicaie Web.
Pentru a asigura securitatea comunicaiei este recomandat utilizarea HTTPS, un protocol de
comunicaie destinat transferului de informaie criptat prin intermediul internetului, care nu
este altceva dect protocolul HTTP ncapsulat ntr-un flux SSL/TLS. Astfel datele sunt criptate
la server nainte de a fi trimise clientului, astfel nct simpla interceptare a acestora pe traseu
s nu mai fie suficient pentru a avea acces la informaii.
4.3. ARHITECTURA IMPLEMENTRII SERVICIULUI-WEB SIUI

Sistemul Informatic Unic Integrat (SIUI) expune mai multe servicii Web cu ajutorul pachetului
AXIS pus la dispoziie de Apache Software Foundation, o implementare a protocolului SOAP
publicat de W3C (WWW-Consortium). Pachetul AXIS a fost conceput pentru a fi utilizat in cadrul
unui container Web, acesta fiind n cazul SIUI serverul Tomcat.
OBSERVAIE
Pentru a putea comunica cu SIUI aplicaiile trebuie s foloseasc protocolul HTTPS,
mai precis versiunea 3.0 a protocolului SSL (Secure Sockets Layer), cu TLS (Transport
Layer Security) dezactivat.
Arhitectura serviciilor Web este exemplificata in figura urmtoare, folosind protocolul HTTPS,
containerul Web Tomcat i serverul de aplicaie JBoss:

Figura 4 - Arhitectura Serviciul-Web SIUI 2.0
OBSERVAIE
Pentru a putea lucra cu AXIS folosind metoda de autentificare simpla, pe baz de
nume de utilizator i parol, aplicaia client trebuie configurat s foloseasc
versiunea 1.0 a protocolului de transfer HTTP.
V prezentm spre informare versiunile aplicative ale componentelor folosite n instalarea

actual a SIUI, acestea fiind dup cum urmeaz:
- Apache AXIS (ver. 1.3);
- Apache Tomcat (ver. 5.5);
- JBoss Application Server (ver. 4.0.5).
De asemenea prezentm i versiunile aplicative al componentelor folosite n cadrul
implementrilor de referin ale aplicaiilor de raportare puse la dispoziie gratuit de CNAS
pentru furnizorii de servicii medicale i farmaceutice:
- Microsoft .NET Framework (ver. 4.0)
Microsoft .NET Framework ofer suport complet pentru comunicarea prin servicii Web ntre
aplicaii, dar i pentru realizarea aplicaiilor propriu-zise pe toate nivelurile logice de
proiectare.

5. DESCRIEREA SERVICIILOR WEB EXPUSE
n acest capitol sunt prezentate pe larg metodele expuse de interfaa serviciului-Web al SIUI.
Prezentarea const n descrierea semnturii metodelor, adic a numelui, a parametrilor i a
tipului ntors pentru fiecare metod, urmate de o scurt descriere a modului de folosire.
Accesul prin serviciul-Web la SIUI se face n mod securizat prin autorizarea apelului pe baz de
nume de utilizator i parol. n acest scop n SIUI trebuie nregistrat n prealabil un utilizator
pentru fiecare furnizor de servicii medicale care dorete s raporteze electronic datele n
sistem.
Pentru accesul la sistem, n urma ncheierii contractului dintre furnizor i casa de asigurri, se
elibereaz o convenie de utilizare care conine codul de acces al utilizatorului autorizat sub
forma unei serii de licen autovalidant prin sum de control. Aceast serie de licen este
creat aleator de ctre sistem la cerere prin intermediul interfeei de operare de la nivelul
casei judeene de asigurri.
OBSERVAIE
Prin convenie numele acestui utilizator este chiar codul unic de identificate al
acestuia (CUI sau CNP, dup caz) la care se adaug codul SIUI ai casei de asigurri cu
care s-a ncheiat contractul de prestare servicii, respectiv convenia de utilizare a
aplicaiei, iar parola este seria de licen de mai sus.
Prezentm mai jos un exemplu practic de nume de utilizator i parol:

- Nume: 123456789_CAS-X
- Parol: AB132-C123-D123-E123
Pentru fiecare serviciu Web vor fi prezentate n anexele acestui document structurile de date
ale fiierelor XML, sub forma unor fiiere XSD (XML Schema Definition), precum i fiierele
WSDL de definiie a metodelor expuse.
Sistemul SIUI folosete trei fiiere WSDL corespunztoare funcionalitilor majore expuse:
- SiuiWS.wsdl pentru serviciile pentru sincronizarea nomenclatoarelor, fiierelor de
personalizare, transmiterea de raportri i preluarea rezultatelor prelucrrii
raportrilor, precum i alte servicii conexe, expuse n seciunile urmtoare. Toate aceste
servicii expun online funcionalitile oferite pn acum de sistem n mod offline, prin
transferul fiierelor folosind medii de stocare mobile.
- SiuiInsuredWS.wsdl pentru serviciul-Web de verificare online a calitii de asigurat al
unei persoane/pacient. Acest serviciu este o funcionalitate nou adus de SIUI 2.0.
- SiuiValidateWS.wsdl pentru serviciile-Web de prevalidare online a eligibilitii la
decontare a serviciilor prestate de furnizori. Acest serviciu este o funcionalitate nou
adus de SIUI 2.0.

Adresele serviciilor-Web expuse de SIUI sunt urmtoarele:

https://www.siui.ro/svapntws/services/SiuiWS
https://www.siui.ro/svapntws/services/SiuiValidateWS
https://www.siui.ro/svapntws/services/SiuiInsuredWS
Adresa serviciului de autentificare i validare OCSP a certificatelor digitale este urmtoarea:

https://www.siui.ro/OCSP/validator
Serviciul de autentificare transmite aplicaiei client un jeton de sesiune care trebui adugat de
ctre aplicaie n antetul cererii HTTP pentru a putea accesa serviciile web din lista anterioar.
Jetonul de sesiune este generat de serviciul de autorizare pe baza certificatului digital al
utilizatorului SIUI.
OBSERVAIE
Pentru a putea obine jetonul de sesiune serviciul de autentificare necesit
transmiterea ca parametru a numelui utilizatorului SIUI care se solicit acccesul.
De notat c acest jeton are o perioad de valabilitate limitat, dup care expir, fiind necesar
obinerea unui nou jeton.
V prezentm n continuare un exemplu de efectuare a cererii i de obinere a jetonului de
sesiune, transmis de ctre server n antetul rspunsului ctre client, dintr-o aplicaie .NET:
// configurare opiuni generale http
ServicePointManager.ServerCertificateValidationCallback = ServerCertificateBypass;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 |
SecurityProtocolType.Tls; // default in .NET
// creare cerere web https

var url = String.Format("https://www.siui.ro/OCSP/validator?username={0}", userName);
var request = (HttpWebRequest)WebRequest.Create( new Uri(url) );
// configurare cerere web

request.Accept = "*/*";
request.KeepAlive = true;
request.AllowAutoRedirect = false;
request.PreAuthenticate = true;
// preluare Proxy din Internet Explorer

request.Proxy = ProxyHelper.GetSystemWebProxy();
// adugare certificat digital

request.ClientCertificates.Add(userCertifcate);
// configurare autentificare pe baz de utilizator i parol

var credentials = new CredentialCache();
credentials.Add( uri, "Basic", new NetworkCredential( userName .password ) );
request.Credentials = credentials;
// suprasciere CookieContainer pentru a pstra cookie-urile

request.CookieContainer = CookieJar; // CookieJar este un CookieContainer static
// obinere rspuns de la serviciul web

var response = request.GetResponse();
// extragere jeton de sesiune din antetul rspunsului https

return response.Headers["OSCP_RESPONSE"];

unde:
- userName este o variabil String care reprezint numele utilizatorului, similar cu exemplul
mai sus (concatenare CUI furnizor i cod CAS),
- password este o variabil String care reprezint parola utilizatorului, similar cu exemplul
mai sus (cheia de activare de pe convenia de utilizare), iar
- userCertificate este o variabil de tip X509Certificate care reprezint certificatul digital al
furnizorului.
Implementarea ServerCertificateValidationCallback pentru a face bypass la validarea
certificatului server-ului este destul de simpl i intuitiv:
bool ServerCertificateBypass(object sender,
X509Certificate certificate,
X509Chain chain,
SslPolicyErrors sslPolicyErrors)
{
return true;
}
Prezentm n continuare un alt exemplu pentru configurarea cererilor https ctre SIUI care se
aplic tuturor cererilor ulterioare obinerii jetonului de sesiune de la OCSP.
// configurare cerere web
request.Accept = "*/*";
request.KeepAlive = true;
request.AllowAutoRedirect = false;
request.PreAuthenticate = true;
// preluare Proxy din Internet Explorer

request.Proxy = ProxyHelper.GetSystemWebProxy();
// adugare certificat digital

request.ClientCertificates.Add(userCertifcate);
// configurare autentificare pe baz de utilizator i parol

var credentials = new CredentialCache();
credentials.Add( uri, "Basic", new NetworkCredential( userName .password ) );
request.Credentials = credentials;
// evitare cache local

request.CachePolicy = new RequestCachePolicy( RequestCacheLevel.NoCacheNoStore );
// suprasciere CookieContainer pentru a pstra cookie-urile

request.CookieContainer = CookieJar; // CookieJar este un CookieContainer static
// adugare jeton de sesiune la antetul cererii

request.Headers.Add("OSCP_RESPONSE", sessionToken);
unde:
- request este o variabil HttpWebRequest care reprezint cererea ctre SIUI,
- sessionToken este o variabil String care reprezint jetonul (ID) de sesiune primit de la
serviciul OCSP,
- userName este o variabil String care reprezint numele utilizatorului, similar cu exemplul
mai sus (concatenare CUI furnizor i cod CAS),
- password este o variabil String care reprezint parola utilizatorului, similar cu exemplul mai
sus (cheia de activare de pe convenia de utilizare), iar
- userCertificate este o variabil de tip X509Certificate care reprezint certificatul digital al
furnizorului.

5.1. SERVICIUL PENTRU SINCRONIZAREA NOMENCLATOARELOR

Acest serviciu se folosete pentru descrcarea fiierului de nomenclatoare specifice pentru
furnizorii de servicii medicale i farmaceutice.
5.1.1. Metoda getCatalogues

String[] getCatalogues (
String partnerCategory,
DateTime start )
Metoda are doi parametri de intrare :
- parametrul partnerCategory de tip ir de caractere reprezint codul tipului de furnizor
pentru care se cere versiunea actual de nomenclatoare, lista valorilor permise fiind
prezentat mai jos;
- parametrul start de tip dat calendaristic reprezint data de la care se caut n sistem
existena unei noi versiuni.
Metoda ntoarce un vector de iruri de caractere de lungime doi. Primul ir din acest vector
reprezint URL-ul de la care se face descrcarea fiierului, iar cel de-al doilea ir reprezint
dimensiunea fiierului care trebuie descrcat. URL-ul va expira la momentul publicrii unei noi
versiuni de nomenclatoare pentru a nu permite aplicaiilor de raportare s descarce accidental
un fiier de nomenclatoare mai vechi folosind un URL din cache.
Dac nu exist o versiune mai nou de nomenclatoare metoda ntoarce null.
Cel de-al doilea parametru poate fi folosit pentru a evita transferul inutil de date prin stocarea
n aplicaia client a datei la care s-a efectuat sincronizare anterioar i prin folosirea acestei
date ca dat de nceput pentru cutare a unei versiuni mai noi a nomenclatoarelor.
Fiierul XML va conine n nodul rdcin un cmp care va reprezenta data la care a fost
generat. Aceast data va fi utilizat de aplicaia client pentru a memora data valabilitii
nomenclatoarelor care va fi folosit ca valoare pentru parametrul al doilea.
Este recomandat ca aplicaiile de raportare nu trebuie s permit importul unor nomenclatoare
mai vechi dect cele deja ncrcate n aplicaie.
5.1.2. Instruciuni de folosire

Aplicaia client trebuie s foloseasc URL-ul rezultat pentru a descrca fiierul cu
nomenclatoarele. Dimensiunea fiierului poate fi folosit pentru a verifica completitudinea
fiierului descrcat. Fiierul descrcat este o arhiv ZIP care conine un fiier XML de
nomenclatoare SIUI.
Schema de validare pentru acest fiier este detaliat n anexele corespunztoare fiecrui tip de
furnizor.
Prezentm n continuare lista de valori admise pentru parametrul partnerCategory:
Valoare Tip de furnizor corespunztor
parametru
MF Medicin primar i de familie
FARM (sau PHM) Farmacii (circuit deschis / circuit nchis)
CLIN Specialiti clinice
PARA Specialiti paraclinice
STOM Specialiti stomatologice


parametru
AMB Ambulane
MD Dispozitive medicale
HC ngrijire la domiciliu
REC Recuperare - ambulatoriu i sanatorii
SPT Spitale
NHP P.N.S.
DIA Hemodializ
SICK Raportri concedii medicale
EMP Raportri angajatori
Un exemplu tipic de algoritm pentru actualizarea nomenclatoarelor este:

Se apeleaz metoda getCatalogues cu parametrii corespunztori.
Dac apelul ntoarce null atunci:
- Se afieaz mesajul "Nu exist o versiune mai nou".
Dac se ntoarce un vector de iruri de caractere de lungime 2 atunci:
- Se consider primul ir ca fiind url-ul pentru descrcarea fiierului.
- Se descarc fiierul (care este o arhiv ZIP).
- Dac dimensiunea fiierului descrcat coincide cu valoarea celui de-al
doilea element din vector atunci:
- Se dezarhiveaz arhiva descrcat i rezult un fiier XML.
- Se valideaz fiierul XML cu schema de validare XSD corespunztoare.
- Dac fiierul este valid atunci:
- Se parcurge fiierul i se actualizeaz valorile din
nomenclatoarele din baza de date.
- Altfel se afieaz mesaj de eroare "Fiier invalid".
- Altfel se afieaz mesaj de eroare de comunicaie.
Altfel se afieaz un mesaj de eroare de comunicaie.
5.1.3. Observaii
n cazul n care conexiunea nu a putut fi efectuat, rezultatul apelului metodei Web va fi un
mesaj de eroare (o excepie).
De asemenea, accesul prin url la arhiv este securizat, folosindu-se aceeai nume de utilizator
i parol ca pentru accesul la metoda Web, precum i certificatul digital pentru deschiderea
conexiunii SSL.
5.2. SERVICIUL PENTRU SINCRONIZAREA DATELOR DE PERSONALIZARE

Acest serviciu este folosit pentru descrcarea fiierului cu datele de personalizare specifice
pentru furnizorii de servicii medicale i farmaceutice.
5.2.1. Metoda getProviderInfo

String[] getProviderInfo (
DateTime start,
DateTime stop,
String uic )
Metoda are patru parametri de intrare :
- parametrul partnerCategory de tip ir de caractere reprezint codul tipului de furnizor,
lista valorilor permise fiind prezentat mai jos;

- parametrul start de tip dat calendaristic reprezint data de nceput a perioadei pentru
care se caut datele furnizorului n sistem;
- parametrul stop de tip dat calendaristic reprezint data de sfrit a perioadei pentru
care se caut datele furnizorului n sistem;
- parametrul uic de tip ir de caractere reprezint codul unic de identificare al furnizorului
n sistem, CUI (cod fiscal) sau CNP, dup caz.
reprezint URL-ul de la care se face descrcarea fiierului de personalizare, iar cel de-al
doilea ir reprezint dimensiunea fiierului care trebuie descrcat.
URL-ul va fi generat pentru fiecare cerere i vor avea o perioad de valabilitate predefinit dup
trecerea creia nu va mai fi disponibil pentru a nu permite aplicaiilor de raportare s descarce
accidental un fiier de personalizare mai vechi folosind un URL din cache.
Fiierul XML va conine n nodul rdcin un cmp care va reprezenta data la care fiierul a fost
generat. Aceast data va fi utilizat de aplicaia client pentru a memora data valabilitii
fiierului de personalizare.
Este recomandat ca aplicaiile de raportare nu trebuie s permit importul unui fiier de
personalizare mai vechi dect cel deja ncrcate n aplicaie.

Fiierul de personalizare conine date de identificare ale furnizorului, datele de contract, date
legate de medicii angajai i specialitile acestora, precum i, acolo unde este cazul, valorile
tarifelor, plafoanelor sau altor sume contractate.
Schema de validare pentru fiierul de personalizare este detaliat n anexele corespunztoare
fiecrui tip de furnizor.
parametru
FARMD Farmacii (circuit deschis)
FARMI Farmacii (circuit nchis)
AMB Ambulane
RECA Recuperare - ambulatoriu
RECS Recuperare - sanatorii
SPT Spitale
NHP P.N.S.
DIA P.N.S. / Dializ public
FSD Dializ privat
SICK Raportri concedii medicale
EMP Raportri angajatori

Un exemplu tipic de algoritm pentru actualizarea datelor de contract este:

Se apeleaz metoda getProviderInfo cu parametrii corespunztori.
- Se parcurge fiierul i se actualizeaz datele de contract din baza
de date.
5.2.3. Observaii
conexiunii SSL.
5.3. SERVICIUL PENTRU TRIMITEREA RAPORTRILOR PERIODICE

Acest serviciu se folosete pentru trimiterea unui fiier de raportare periodic ctre SIUI. La
momentul trimiterii se realizeaz validarea formei i coninutului fiierului, precum i
verificarea existenei unui contract valid i a unei perioade de raportare deschis pentru
furnizorul respectiv.
5.3.1. Metoda sendReport

Boolean sendReport (
String reportType,
String reportXml )
Metoda are doi parametri de intrare :
- parametrul reportType de tip ir de caractere reprezint codul tipului de furnizor, lista
valorilor permise fiind prezentat mai jos;
- parametrul reportXml de tip ir de caractere reprezint coninutul fiierului de
raportare semnat electronic, arhivat n formatul ZIP (JavaZip) i codat ulterior n
formatul Base64.
Dac metoda ntoarce valoarea adevrat, atunci trimiterea raportului s-a fcut cu succes,
altfel trimiterea s-a terminat cu erori. Pe baza mesajului primit n cazul unei erori se poate
determina cauza respingerii raportrii.

Numele fiierului XML de raportare trebuie sa respecte formatul:
{Prefix} + "_" + {Cod} + "_" + {Data} + "_" + {Ora} + ".xml"

{Prefix} reprezint un cod de identificare pentru tipul de furnizor, lista complet a acestor
coduri fiind prezentat n tabelul de mai jos.
{Cod} reprezint codul unic de identificare al furnizorului n sistem, codul fiscal, CUI sau CNP,
dup caz.
Parametrii {Data} i {Ora} reprezint data i ora la care a fost efectuat raportarea i trebuie s
apar n formatul "AAAALLZZ" pentru dat i "OOMM", fr nici un separator.
furnizor.
Prezentm n continuare lista de valori admise pentru parametrul reportType:
Valoare Valoare prefix Tip de furnizor corespunztor / Tip de raportare
parametru fiier
MF MF Medicin primar i de familie
PRM PRM Centre de permanen
FARMD FARMD Farmacii (circuit deschis)
FARMI FARMI Farmacii (circuit nchis)
CLIN CLIN Specialiti clinice
PARA PARA Specialiti paraclinice
STOM STOM Specialiti stomatologice
AMB AMB Ambulane
MD MD Dispozitive medicale
HC HC ngrijire la domiciliu
RECA RECA Recuperare - ambulatoriu
RECS RECS Recuperare - sanatorii
SICK SICK Certificate de concediu medicale
FSD DIA Dializ privat
NHPDIA DIA P.N.S. / Dializ public
NHPREP NHPREP P.N.S. / Raportare de indicatori P.N.S.
NHPCJ NHPCJ P.N.S. / Cereri justificative (facturi i ordine de plat)
SPT_ACUT SPT_ACUT Spitale / Raportare de cazuri acute (internri)
SPT_CHR SPT_CHR Spitale / Raportare de cazuri cronice
SPT_DRG SPT_DRG Spitale / Raportare D.R.G.
SPT_SPZ SPT_SPZ Spitale / Raportare spitalizare de zi
SPT_PAL SPT_PAL Spitale / Raportare paliative
Un exemplu tipic de algoritm pentru generarea fiierelor XML de raportare este:

Se pregtesc datele pentru raportare:
- Se genereaz fiierul de raportare XML corespunztor perioadei selectate.
- Se semneaz electronic fiierul XML, folosind standardul CMS (RFC5652).
- Se arhiveaz fiierul XML folosind algoritmul ZIP.
- Se codific coninutul arhivei folosind codarea Base64.
Se apeleaz metoda sendReport cu parametrii corespunztori.
Dac metoda ntoarce valoarea true se afieaz mesaj de succes.
5.3.3. Observaii
Pentru semnarea digital a unui fiier n vederea procesrii n SIUI este necesar deinerea
unui certificat digital calificat X.509 emis de unul din furnizorii acreditai de servicii de
certificare din Romnia. Perechea de chei aferent certificatului trebuie s fie de tip RSA.

Fiierele semnate cu certificatul digital X.509, folosind algoritmul SHA-1, se transmit ctre SIUI
folosind formatul CMS (Cryptographic Message Syntax) publicat n RFC-5652 de ctre IETF
(Internet Engineering Task Force) (vezi http://tools.ietf.org/html/rfc5652).
Descrierea algoritmului SHA (Secure Hash Algorithm) este publicat de ctre National
Institute of Standards and Technology (NIST) n Digital Signature Standard FIPS 186-2.
Majoritatea sistemelor de operare permit realizarea unei astfel de semnturi digitale folosind
biblioteci i/sau framework-uri disponibile n sistem, dar i prin produse adiionale.
Semnarea electronic a fiierului XML este necesar doar n cazul transmiterii electronice
online a acestuia ctre SIUI, fiiere aduse la CAS de ctre furnizor pe suport electronic nu
trebuie semnate
NOT
Pentru furnizorii cu mai multe contracte pe aceeai perioad de raportare trebuie
generat cte un fiier pentru fiecare contract. Excepie face aplicaie de raportare
pentru PNS unde se genereaz cte un fiier pentru fiecare PNS.
5.3.4. Raportri speciale

Pentru anumite categorii de furnizori exist raportri speciale, care nu sunt n vederea
decontrii serviciilor, ci pentru trimiterea n sistem a unor informaii auxiliare, de exemplu:
- structura organizatoric a unitii (departamente, secii, angajai)
- oferte de preuri pentru servicii n vederea contractrii
Valoare Valoare prefix Tip de furnizor corespunztor / Tip de raportare
parametru fiier
RECA_OFFER RECAMB_OFFER Recuperare - ambulatoriu / Ofert de preuri pentru servicii
MD_OFFER MEDDEV_OFFER Dispozitive medicale / Ofert de preuri pentru dispozitive medicale
PARA_OFFER PARA_OFFER Paraclinice (Laboratoare) / Ofert de preuri pentru servicii
SPT_E SPT_E Spitale / Structura organizatoric (departamente, secii, angajai)
SPT_I SPT_I Spitale / Raportare indicatori statistici
HBDG HBDG Spitale / Structur i indicatori bugetari
5.4. SERVICIUL PENTRU PRELUAREA REZULTATELOR RAPORTRILOR PERIODICE

Acest serviciu se folosete pentru preluarea fiierului de rspuns pentru o raportare trimis
anterior ctre SIUI pentru prelucrare. Pentru ca fiierul de rspuns s poate fi descrcat acesta
trebuie s fie salvat pe server, lucru care se efectueaz automat n urma prelucrrii fiierului
de raportare.
5.4.1. Metoda getReportFeedback

String[] getReportFeedback ( String fileName )
Metoda are un singur parametru de intrare :
- parametrul fileName de tip ir de caractere reprezent numele fiierului de raportare
trimis de aplicaie pentru care se cere rspunsul procesrii.
reprezint URL-ul de la care se face descrcarea fiierului, iar cel de-al doilea ir reprezint
dimensiunea fiierului care trebuie descrcat.

Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null.

Aplicaia client trebuie s foloseasc URL-ul rezultat pentru a descrca fiierul cu
nomenclatoarele. Dimensiunea fiierului poate fi folosit pentru a verifica completitudinea
fiierului descrcat. Fiierul descrcat este o arhiv ZIP care conine un fiier XML cu rezultatul
procesrii raportrii n SIUI.
furnizor.
Un exemplu tipic de algoritm pentru actualizarea nomenclatoarelor este:
Se apeleaz metoda getReportFeedback cu parametrii corespunztori.
- Se dezarhiveaz fiierul ZIP descrcat i rezult un fiier XML.
- Se parcurge fiierul i se actualizeaz tabela de erori din baza de
date.
5.4.3. Observaii
Numele fiierului de raportare identific n mod unic o raportare efectuat, astfel nct ali
parametrii, cum ar fi tipul de furnizor, nu sunt necesari pentru aceast metod. Aplicaia client
trebuie s in evidena fiierelor de raportare trimise pentru a putea cere rspunsurile
procesate ale acestor fiiere.
5.5. SERVICIUL PENTRU PRELUAREA DECONTULUI

Acest serviciu este folosit pentru obinerea fiierului de decont aferent unei perioade de
raportare sau unei anumite raportri (n baza numrului de factur). n acest sens, serviciul va
expune dou metode, una pentru preluarea decontului pentru o perioad de raportare, i alta
pentru preluarea decontului pentru o anumit factur. Interogarea pe baz de factur este
folosit n mod particular de furnizorii de medicamente (farmacii) sau de dispozitive medicale.
Datele vor fi disponibile dup finalizarea procedurii de decontare din cadrul SIUI. Decontul este
un raport (n format PDF) i este destinat consultrii de ctre furnizor. Datele de pe raport nu
vor fi preluate n aplicaie.

5.5.1. Metoda getRefund

String[] getRefund (
DateTime start,
DateTime stop,
String uic )
Metoda are patru parametri de intrare:
care se dorete fiierul de decont;
reprezint URL-ul de la care se face descrcarea fiierului de decont, iar cel de-al doilea ir
reprezint dimensiunea fiierului care trebuie descrcat.
Dac nu exist un fiier de decont generat pentru furnizorul respectiv, metoda ntoarce null.
5.5.2. Metoda getRefundForInvoice

String[] getRefundForInvoice (
String invoiceNumber,
DateTime invoiceDate,
String uic )
Metoda are trei parametri de intrare:
acelai ca pentru metoda de preluare decont dintr-o perioad;
- parametrul invoiceNumber de tip ir de caractere reprezint numrul de serie al facturii
pentru care se dorete fiierul de decont;
- parametrul invoiceDate de tip dat calendaristic reprezint data facturii pentru care se
dorete fiierul de decont;

5.5.3. Metoda getRefundForPhysician

String[] getRefundForPhysician (
DateTime start,
DateTime stop,
String uic
String stencil )
Metoda are cinci parametri de intrare:
- parametrul stencil de tip ir de caractere reprezint codul de paraf al medicului pentru
care se dorete fiierul de decont, n cazul cabinetelor medicale cu mai muli medici
titulari de contract, pentru care se calculeaz decontul separat.

Aplicaia client trebuie s foloseasc URL-ul rezultat pentru a descrca fiierul de decont.
Valoarea celui de-al doilea parametru poate fi folosit pentru a verifica completitudinea
fiierului descrcat. Fiierul descrcat este o arhiv ZIP care conine un fiier PDF cu sumele
care vor fi decontate de casa de asigurri.
parametru
PRM Centre de permanen
FARM (sau PHM) Farmacii (circuit deschis)
AMB Ambulane
RECA Recuperare - ambulatoriu
RECS Recuperare - sanatorii
SPT Spitale
NHP P.N.S.
DIA P.N.S. / Dializ public
FSD Dializ privat

NOT
Nu toate categoriile de furnizori pot descrca un fiier de decont, de exemplu
farmaciile cu circuit nchis sau medicii cu convenie de eliberare a certificatelor de
concediu medical, deoarece fluxul de lucru specific nu implic decontri.
Un exemplu tipic de algoritm pentru preluarea fiierului de decont este:

Se apeleaz metoda getRefund cu parametrii corespunztori.
- Se dezarhiveaz arhiva descrcat i rezult un fiier PDF.
- Se afieaz coninutul fiierului PDF folosind aplicaia de vizualizare
instalat.
5.5.5. Observaii
conexiunii SSL.
5.6. SERVICIUL PENTRU SINCRONIZAREA DECIZIILOR DE ACORDARE

Acest serviciu este folosit pentru sincronizarea informaiilor referitoare la deciziile de aprobare
ale unor categorii de servicii.
5.6.1. Metoda getDecisions

String[] getDecisions (
String requestXml )
Metoda are doi parametri de intrare:
- parametrul requestXml de tip ir de caractere reprezint coninutul fiierului de cerere
arhivat n formatul ZIP (JavaZip) i codat ulterior n formatul Base64.
reprezint URL-ul de la care se face descrcarea fiierului de rspuns, iar cel de-al doilea ir
Dac nu exist un fiier de raportare procesat cu numele dat, metoda ntoarce null.


Aplicaia client trebuie s foloseasc URL-ul rezultat pentru a descrca fiierul de rspuns.
Dimensiunea fiierului poate fi folosit pentru a verifica completitudinea fiierului descrcat.
Fiierul descrcat este o arhiv ZIP care conine un fiier XML cu datele referitoare la deciziile
cerute din SIUI.
Numele fiierului XML de cerere trebuie sa respecte formatul:
{Prefix} + "_" + {Cod} + "_" + {Data} + "_" + {Ora} + ".xml"
{Prefix} reprezint un cod de identificare pentru tipul de furnizor, lista complet a acestor
coduri fiind prezentat n tabelul de mai jos.
{Cod} reprezint codul unic de identificare al furnizorului n sistem, CUI sau CNP, dup caz.
Parametrii {Data} i {Ora} reprezint data i ora la care a fost efectuat raportarea i trebuie s
apar n formatul "AAAALLZZ" pentru dat i "OOMM", fr nici un separator.
Schema de validare pentru acest fiier, dar i pentru fiierul de rspuns care conine deciziile,
este detaliat n anexele corespunztoare fiecrei categorii de furnizor:
Valoare Valoare prefix Tip de furnizor corespunztor
parametru fiier
MD MD_SYNC Dispozitive medicale
HC HC_SYNC ngrijire la domiciliu
Un exemplu tipic de algoritm pentru preluarea i sincronizarea deciziilor este:

Se pregtesc datele pentru raportare:
- Se genereaz fiierul cerere n format XML corespunztor deciziei
selectate.
- Se arhiveaz fiierul XML folosind algoritmul ZIP.
- Se codific coninutul arhivei folosind codarea Base64.
Se apeleaz metoda getDecisions cu parametrii corespunztori.
- Se parcurge fiierul i se actualizeaz tabela de decizii din baza
de date.
5.6.3. Observaii
Aceast metod are implementri doar pentru dou categorii de furnizori, cei de dispozitive
medicale i servicii de ngrijire la domiciliu, pentru care este necesar obinerea unei aprobri
speciale (decizie) din partea casei de asigurri n vederea eliberrii dispozitivului sau acordrii
serviciului de ngrijire la domiciliu.
mesaj de eroare (o excepie). De asemenea, accesul prin url la arhiv este securizat, folosindu-
se aceeai nume de utilizator i parol ca pentru accesul la metoda Web.

5.7. SERVICIUL PENTRU VERIFICAREA CALITII DE ASIGURAT

Acest serviciu este folosit pentru verificarea online a calitii de asigurat pe baza CNP-ului unui
beneficiar de servicii medicale sau farmaceutice.
Aplicaiile de raportare vor folosi acest serviciu pentru a verifica starea de asigurat a unui
beneficiar, care vor putea astfel asista operatorul precompletnd informaiile corespunztoare
sau vor afia mesaje de avertizare n cazul n care se nregistreaz servicii pentru persoane
neasigurate.
5.7.1. Metoda getInsured

String getInsured (
String pid,
Date requestDate )
- parametrul pid de tip ir de caractere reprezint CNP-ul unui beneficiar;
- parametrul requestDate de tip dat calendaristic reprezint data la care se dorete
verificarea calitii de asigurat, de exemplu data curent sau data efecturii serviciului.
Metoda ntoarce ca rspuns un ir de caractere reprezentnd coninutul unui fiier n format
XML care conine urmtoarele informaii:
- Un cod numeric de rspuns indicnd dac beneficiarul este asigurat sau nu, dac
figureaz ca decedat n sistem, dac nu este nregistrat n sistem sau dac CNP-ul nu
este corect.
- Lista categoriilor active la data interogrii
Observaie: n cazul unei erori ntlnite n sistem la procesarea cererii se va ntoarce un cod
numeric de rspuns (-1) precum i o descriere a erorii.

Aplicaia de raportare trebuie s proceseze fiierul de rspuns i s afieze un mesaj sugestiv
pentru utilizator cu privire la starea de asigurat a persoanei respective. Dac este cazul
aplicaia va precompleta cmpurile corespunztoare categoriei de asigurat, selectnd
categoria cea mai favorabil pacientului din lista transmis din SIUI.
Este de preferat ca aplicaia de raportare s realizeze validarea de corectitudine a CNP-ului,
algoritmul fiind arhicunoscut, pentru a nu suprancrca sistemul cu cereri inutile.
Schema de validare pentru fiierul de rspuns este detaliat n anexele corespunztoare
fiecrei categorii de furnizor.

Un exemplu tipic de algoritm pentru verificarea categoriei de asigurat este:

Utilizatorul introduce CNP-ului unui pacient sau selecteaz un pacient dintr-o
list derulant.
Aplicaia valideaz corectitudinea CNP-ului:
- Dac CNP-ul este incorect se afieaz un mesaj de avertizare.
- Altfel se continu verificarea online:
Aplicaia apeleaz metoda getInsured folosind CNP-ul respectiv i data
serviciului ca parametri.
Dac SIUI ntoarce un ir de caractere ca rspuns, aplicaia l salveaz ntr-un
fiier XML:
- Se parcurge fiierul i se afieaz un mesaj corespunztor strii
de asigurat.
- Altfel se afieaz mesaj de eroare "Fiier de rspuns invalid".
5.7.3. Observaii
Metoda poate fi apelat de orice categorie de furnizor, motiv pentru care nu apare parametrul
de apel corespunztor prezent n celelalte metode ale serviciilor Web SIUI.
5.8. SERVICIUL PENTRU VALIDAREA MICRILOR DE CAPITAIE

Acest serviciu este folosit pentru validarea unei cereri de nscriere sau ieire , nsoit de
motivaia operaiunii, a unui pacient pe lista unui medic de familie.
5.8.1. Metoda validateEnlisted

String validateEnlisted ( String enlistedXml )
Metoda are un singur parametru de intrare:
- parametrul enlistedXml de tip ir de caractere reprezint coninutul fiierului de
raportare n format XML.
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML care
conine urmtoarele informaii:
- O structur similar cu cea raportat, coninnd fiecare identificator de nregistrare
transmis nsoit de starea validrii (validat/nevalidat)
- Lista erorilor sau avertizrilor pentru fiecare nregistrare raportat, n caz c acestea au
fost depistate
- tampila de timp la momentul emiterii rspunsului


Un exemplu tipic de algoritm pentru validarea micrilor de capitaie este:
Utilizatorul adaug sau elimin un pacient din lista de nscrii:
- Aplicaia genereaz fiierul cerere n format XML coninnd informaiile
referitoare la pacient, operaia efectuat i motivul acesteia.
Aplicaia apeleaz metoda valiadateEnlisted trimind coninutul fiierului.
fiier XML:
- Se parcurge fiierul i se afieaz un mesaj corespunztor
rezultatului validrii.
5.8.3. Observaii
5.9. SERVICIUL PENTRU VALIDAREA SERVICIILOR I INVESTIGAIILOR MEDICALE

Acest serviciu este folosit pentru validarea serviciilor prestate n aplicaie pe msur ce
acestea sunt nregistrate, nainte de ncheierea perioadei re raportare.
5.9.1. Metoda validateReport

String validateReport (
String reportXml,
String reportType,
String requestType )
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;
conine urmtoarele informaii:
- O structur similar cu cea raportat, coninnd fiecare identificator de nregistrare
transmis nsoit de starea validrii (validat/nevalidat)
- Lista erorilor sau avertizrilor pentru fiecare nregistrare raportat, n caz c acestea au
fost depistate
- tampila de timp la momentul emiterii rspunsului

Coninutul i formatul datelor transmise este specific fiecrui tip de furnizor i va fi descris n
detaliu n anexele care nsoesc acest document. Ca regul general, datele transmise din
aplicaia de raportare ctre SIUI vor fi validate iar serviciul Web va ntoarce un rspuns cu
privire la rezultatul validrii serviciului medical raportat.

Un exemplu tipic de algoritm pentru validarea unei reete este:
Utilizatorul adaug o reet n baza de date:
referitoare la reet i medicamentele prescrise.
Aplicaia apeleaz metoda validateReport trimind coninutul fiierului nsoit
de tipul raportrii.
fiier XML:
- Se proceseaz fiierul XML i se afieaz un mesaj corespunztor
- Aplicaia asociaz i pstreaz rezultatul validrii, afind
nregistrarea respectiv n mod distinct.
Altfel se afieaz excepia returnat sau un mesaj de eroare de comunicaie.
Prezentm n continuare lista de valori admise pentru parametrul reportType:

Valoare Valoare prefix Tip de furnizor corespunztor
parametru fiier
MF MF Medicin primar i de familie
PRM PRM Centre de permanen
FARMD FARMD Farmacii (circuit deschis)
FARMI FARMI Farmacii (circuit nchis)
CLIN CLIN Specialiti clinice
PARA PARA Specialiti paraclinice
STOM STOM Specialiti stomatologice
AMB AMB Ambulane
MD MD Dispozitive medicale
HC HC ngrijire la domiciliu
RECA RECA Recuperare - ambulatoriu
RECS RECS Recuperare - sanatorii
DIA DIA Dializ privat
NHPDIA DIA P.N.S. / Dializ public
NHPREP NHPREP P.N.S. / Raportare de indicatori P.N.S.
NHPCJ NHPCJ P.N.S. / Cereri justificative (facturi i ordine de plat)
SPT_ACUT SPT_ACUT Spitale / Raportare de cazuri acute (internri)
SPT_CHR SPT_CHR Spitale / Raportare de cazuri cronice
SPT_DRG SPT_DRG Spitale / Raportare D.R.G.
SPT_SPZ SPT_SPZ Spitale / Raportare spitalizare de zi
SPT_PAL SPT_PAL Spitale / Raportare paliative
CM CM Concedii medicale
Prezentm n continuare lista de valori admise pentru parametrul requestType:

Valoare parametru Tip de cerere de validare
RQ_PRESCRIPTION Cerere de validare reet prescris de medic
RQ_REFERRAL Cerere de validare bilet de trimitere emis
RQ_CHRONICS Cerere de validare a bolnavilor cronici aflai n eviden

Valoare parametru Tip de cerere de validare

RQ_MF_ENLISTED Cerere de validare a micrii nscriilor pe listele medicilor de familie
RQ_MF_SERVICES Cerere de validare a serviciilor prestate de medicii de familie
RQ_SPT_ACUTE Cerere de validare a cazurilor acute de spitalizare
RQ_SPT_CHRONIC Cerere de validare a cazurilor cronice de spitalizare
RQ_SPT_ANALYTIC Cerere de validare a raportrii analitice a spitalelor
RQ_SPT_DRG Cerere de validare a raportrii DRG a spitalelor
RQ_SPT_HC_REC Cerere de validare a recomandrilor de servicii de ngrijire la domiciliu
RQ_SPT_MD_REC Cerere de validare a recomandrilor de acordare de dispozitive medicale
RQ_SPT_PAL Cerere de validare a cazurilor paliative de spitalizare
RQ_PHM_PRESCRIPTION Cerere de validare a unei reete eliberate n farmacie
RQ_PHM_HR Cerere de validare a unei foi de condic din farmacii cu circuit nchis
RQ_PRM Cerere de validare a serviciilor prestate n centre de permanen
RQ_MD Cerere de validare a dispozitive medicale acordate
RQ_HC Cerere de validare a servicii de ngrijire la domiciliu
RQ_AMB_SRV Cerere de validare a servicii de urgen sau transport cu ambulana
RQ_AMB_WT Cerere de validare/raportare a timpilor de ateptare a ambulanelor
RQ_DIA_SRV Cerere de validare a serviciilor de dializ privat
RQ_NHP_DIA_SRV Cerere de validare a serviciilor de dializ public
RQ_RECA_SRV Cerere de validare a serviciilor de recuperare ambulatorie
RQ_RECS_SRV Cerere de validare a serviciilor de recuperare n sanatorii
RQ_CLIN_SRV Cerere de validare a serviciilor clinice de specialitate
RQ_PARA_SRV Cerere de validare a serviciilor paraclinice (investigaii de laborator)
RQ_STOM_SRV Cerere de validare a serviciilor stomatologice i dentare
RQ_NHP_GC Cerere de validare a consumului de materiale decontate din PNS
RQ_NHP_IND Cerere de validare/raportare a indicatorilor PNS
RQ_NHP_TS Cerere de validare a schemelor terapeutice recomandate n cadrul PNS
RQ_NHP_INV Cerere de validare a facturilor decontate din PNS
RQ_NHP_OP Cerere de validare a plilor decontate din PNS
RC_CM Cerere de validare certificat medical prescris de medic
5.9.3. Observaii
Orice serviciu pre-validat poate fi modificat ulterior de ctre furnizor, n intervalul de timp
alocat raportrilor, conform legislaiei n vigoare, dar nu mai trziu de ntocmirea deconturilor
ctre furnizori. Pentru re-validarea dup modificarea a serviciului medical efectuat aplicaia de
raportare va trebui s transmit acelai identificator de serviciu, n caz contrar operaia va
tratat ca o adugare i va fi invalidat (serviciul medical efectuat i pstreaz identificatorul
unic indiferent de cte ori este modificat).
5.10. SERVICIUL PENTRU VALIDAREA REETELOR PRESCRISE

Acest serviciu permite raportarea reetelor prescrise de ctre medici. Medicul va completa
datele referitoare la reet n aplicaia de raportare, la salvarea biletului de trimitere se va
apela serviciul Web prin care se va transmite pentru validare ctre SIUI reeta.
5.10.1. Metoda validatePrescription

String validatePrescription (
String reportXml,
String reportType )
Metoda un singur parametru de intrare:


raportare n format XML;
valorilor permise fiind prezentat mai jos.
conine rezultatul operaiunii de validare.

Un exemplu tipic de algoritm pentru validarea unei reete este:
Utilizatorul adaug o reet n baza de date:
referitoare la reet i medicamentele prescrise.
Aplicaia apeleaz metoda valiadatePrescription trimind coninutul fiierului.
fiier XML:
5.10.3. Observaii
Structura fiierul permite transmiterea mai multor nregistrri simultan, de exemplul la cerea
utilizatorului, dup ce acesta a finalizat operarea mai multor reete, sau n mod automat la
revenirea conexiunii online dup o perioad de lucru offline.
Modificarea unei reete prescrise se poate face doar de ctre medicul prescriptor att timp ct
reeta nu a fost eliberat de ctre furnizorul de servicii farmaceutice. n cazul n care un medic
prescriptor aflat on-line va dori s modifice o reet care a fost eliberat, nu va putea salva
modificrile i va primi un mesaj care l va avertiza c reeta a fost eliberat.
Metoda validareReport se poate folosi n locul aceste metode, dac se utilizeaz parametrii
corespunztori, rezultatul validrii fiind acelai.
5.11. SERVICIUL PENTRU VALIDAREA BILETELOR DE TRIMITERE

Acest serviciu permite raportarea biletelor de trimitere pentru specialiti clinice sau
investigaii de laborator de ctre un medic emitent. Medicul va completa datele biletului de
trimitere n aplicaia de raportare, la salvarea biletului de trimitere se va apela serviciul Web
prin care se va transmite pentru validare ctre SIUI biletul de trimitere.

5.11.1. Metoda validateClinicReferral

String validateClinicReferral (
String reportXml,
String reportType )
5.11.2. Metoda validateLabReferral

String validateLabReferral (
String reportXml,
String reportType )

Un exemplu tipic de algoritm pentru validarea unui bilet de trimitere este:
Utilizatorul adaug un bilet de trimitere n baza de date:
referitoare la biletul de trimitere i diagnosticul prezumtiv.
Aplicaia apeleaz metoda valiadateClinicReferral sau validateLabReferral, dup
caz, trimind ca parametru coninutul fiierului generat.
fiier XML:
5.11.4. Observaii

utilizatorului, dup ce acesta a finalizat operarea mai multor bilete de trimitere, sau n mod
automat la revenirea conexiunii online dup o perioad de lucru offline.
Metoda validareReport se poate folosi n locul acestor metode, dac se utilizeaz parametrii
5.12. SERVICIUL PENTRU VALIDAREA CERTIFICATELOR MEDICALE

Acest serviciu permite unui medic prescriptor sa raporteze concediile medicale prescrise.
Serviciul va valida concediul medical i va informa medicul prescriptor despre rezultatul
validrii. Certificatele medicale astfel raportate vor fi stocate ntr-o baz de date pentru
realizarea verificrilor de unicitate a certificatelor medicale i a verificrilor ncruciate
conform normelor n vigoare.
5.12.1. Metoda validateSickLeave

String validateSickLeave ( String reportXml )

Un exemplu tipic de algoritm pentru validarea unui certificat medicale este:
Utilizatorul adaug un certificat medical n baza de date:
referitoare la certificatul medical, perioad i diagnostic.
Aplicaia apeleaz metoda valiadateSickLeave trimind ca parametru coninutul
fiierului generat.
fiier XML:
5.12.3. Observaii
utilizatorului, dup ce acesta a finalizat operarea mai multor certificate medicale, sau n mod

Metoda validareReport se poate folosi n locul aceste metode, dac se utilizeaz parametrii
5.13. SERVICIUL PENTRU VALIDAREA REETELOR EMISE DE FARMACII

Acest serviciu permite unei farmacii s verifice compatibilitatea dintre medicamentele
prescrise si cele eliberate (calitativ i cantitativ) precum i validarea ncadrrii n plafonul de
decontare contractat cu Casa de Asigurri. SIUI va returna un mesaj prin care farmacistul este
ntiinat despre rezultatul operaiunii de validare a eliberrii medicamentelor.
5.13.1. Metoda validateFarmacyDrugs

String validateFarmacyDrugs ( String reportXml )
Metoda ntoarce un ir de caractere reprezentnd fiierul de rspuns n format XML.

Un exemplu tipic de algoritm pentru validarea unui certificat medicale este:
Utilizatorul adaug un certificat medical n baza de date:
referitoare la reet, pacient i medicamentele eliberate.
Aplicaia apeleaz metoda validateFarmacyDrugs trimind ca parametru coninutul
fiierului generat.
fiier XML:
5.13.3. Observaii
utilizatorului, dup ce acesta a finalizat operarea mai multor reete eliberate, sau n mod
O reet poate fi eliberat, total sau parial, de o singur farmacie. Dup eliberare reeta trece
n starea eliberat i nu mai este disponibil pentru alte farmacii. Orice modificare a unei
reete eliberate de ctre o farmacie poate fi fcut exclusiv de farmacia n cauz. Toate aceste
modificri sunt salvate ntr-un log pentru posibilitatea auditrii ulterioare.

5.14. SERVICIUL PENTRU CONSULTAREA REETELOR PRESCRISE

Acest serviciu este folosit pentru a permite unei farmacii s vizualizeze reetele prescrise de
medici i s elibereze medicamentele aferente reetei.
5.14.1. Metoda getPrescription

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

Un exemplu tipic de algoritm pentru consultarea unei reete prescrise este:
Utilizatorul introduce datele necesare (vezi lista de parametri):
Aplicaia apeleaz metoda getPrescription trimind ca parametri datele introduse
ce utilizator.
fiier XML:
- Se proceseaz fiierul XML i se afieaz coninutul reetei
cerute, eventual se precompleteaz datele n ecranul de introducere reete.
5.14.3. Observaii
Numai reetele raportate ca validate de SIUI vor fi disponibile pentru interogare de ctre
furnizorii de servicii farmaceutice, acetia vor identifica reetele prescrise n vederea eliberrii
medicaiei dup combinaia de cmpuri: serie i numr reet, CNP pacient i paraf medic
prescriptor.

5.15. SERVICIUL PENTRU CONSULTAREA BILETELOR DE TRIMITERE

Acest serviciu este folosit pentru consultarea biletelor de trimitere pentru specialiti clinice
sau investigaii de laborator validate de SIUI de ctre furnizorii de servicii medicale care
presteaz servicii n baza unui bilet de trimitere.
5.15.1. Metoda getClinicReferral

String getClinicReferral (
String serial,
String number,
String pid,
String stencil )
- parametrul serial de tip ir de caractere reprezint seria biletului de trimitere;
- parametrul number de tip ir de caractere reprezint numrul biletului de trimitere;
- parametrul pid de tip ir de caractere reprezint CNP-ul beneficiarului biletului de
trimitere;
emitent;
5.15.2. Metoda getLabReferral

String getLabReferral (
String serial,
String number,
String pid,
String stencil )
- parametrul serial de tip ir de caractere reprezint seria biletului de trimitere;
- parametrul number de tip ir de caractere reprezint numrul biletului de trimitere;
- parametrul pid de tip ir de caractere reprezint CNP-ul beneficiarului biletului de
trimitere;
emitent;


Un exemplu tipic de algoritm pentru consultarea unei reete prescrise este:
Utilizatorul introduce datele necesare (vezi lista de parametri):
Aplicaia apeleaz metoda getClinicReferral sau getLabReferral, dup caz,
trimind ca parametri datele introduse ce utilizator.
fiier XML:
- Se proceseaz fiierul XML i se afieaz coninutul biletului de
trimitere cerut, eventual se precompleteaza datele n ecranul de introducere
servicii.
5.15.4. Observaii

Specificatie Interfatare SIUI - Aplicatii de Raportare Pentru Furnizori

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Specificatie Interfatare SIUI - Aplicatii de Raportare Pentru Furnizori

Uploaded by

Copyright:

Available Formats

CASA NAIONAL DE ASIGURRI DE SNTATE

SISTEM INFORMATIC UNIC INTEGRAT

Specificaii de interfaare cu SIUI pentru aplicaiile de raportare

ISTORICUL REVIZIILOR DOCUMENTULUI

Versiune Data Comentarii

1.0 (DRAFT) 10.10.2006 Versiune iniial

1.0.1 (RELEASE) 03.12.2007 Versiune publicat restructurat conform observaiilor CNAS

1.0.2 (RELEASE) 12.03.2008 Versiune actualizat i completat

1.1.1 (RELEASE) 07.07.2008 Versiune actualizat i completat

1.1.2 (RELEASE) 05.02.2009 Versiune actualizat i completat

2.0 (RELEASE) 29.11.2010 Versiune publicat - SIUI-Actualizat : Centralizare i validare online

Versiunea 2.1 din 01.08.2011 Pagina 2 din 56

Istoricul reviziilor documentului ............................................................................................................................. 2

Versiunea 2.1 din 01.08.2011 Pagina 3 din 56

4. PREZENTARE GENERAL A SERVICIILOR WEB ................................................................................................................ 28

Versiunea 2.1 din 01.08.2011 Pagina 4 din 56

5.12.3. Observaii ................................................................................................................................................ 52

Versiunea 2.1 din 01.08.2011 Pagina 5 din 56

FIGURA 1 - ARIA DE ACOPERIRE A SISTEMULUI .................................................................................................................. 10

Versiunea 2.1 din 01.08.2011 Pagina 6 din 56

Anexa 009 - Descriere_Structura_Stomatologii.pdf

Versiunea 2.1 din 01.08.2011 Pagina 7 din 56

Anexa 011 - Descriere_Structura_RecuperareAmbulatorii.pdf

Versiunea 2.1 din 01.08.2011 Pagina 8 din 56

2. PREZENTARE GENERAL SIUI

2.1. DESCRIEREA SISTEMULUI INFORMATIC AL ASIGURRILOR DE SNTATE DIN

Versiunea 2.1 din 01.08.2011 Pagina 9 din 56

Figura 1 - Aria de acoperire a sistemului

2.1.1. Nivelul de baz

Versiunea 2.1 din 01.08.2011 Pagina 10 din 56

2.1.2. Nivelul central

Versiunea 2.1 din 01.08.2011 Pagina 11 din 56

2.2. DESCRIEREA INTERFEELOR SIUI

2.2.1. Interfeele cu furnizorii de servicii medicale i farmaceutice

Versiunea 2.1 din 01.08.2011 Pagina 12 din 56

Figura 2 - Conectarea aplicaiilor de raportare la SIUI

2.2.2. Interfeele cu alte instituii

2.3. ASIGURAREA SECURITII INFORMAIEI

Versiunea 2.1 din 01.08.2011 Pagina 13 din 56

Versiunea 2.1 din 01.08.2011 Pagina 14 din 56

- utilizatorii sistemului vor beneficia de comunicaii sigure i secrete cu ajutorul

Figura 3 - Diagrama soluiei de asigurare a securitii datelor

2.3.1. Autentificarea i autorizarea prin certificate digitale

Versiunea 2.1 din 01.08.2011 Pagina 15 din 56

Versiunea 2.1 din 01.08.2011 Pagina 16 din 56

2.3.2. Semntura digital

Versiunea 2.1 din 01.08.2011 Pagina 17 din 56

2.4. CLASIFICAREA TRANSFERURILOR DE DATE

2.4.1. Transfer unilateral - descrcare (download)

2.4.2. Transfer unilateral - ncrcare (upload)

2.4.3. Transfer bilateral

Versiunea 2.1 din 01.08.2011 Pagina 18 din 56

n primul caz, se trimite un fiier cu raportarea electronic i se primete ca rspuns o validare

Versiunea 2.1 din 01.08.2011 Pagina 19 din 56

3. DESCRIEREA FLUXULUI DE LUCRU

3.1. PERSONALIZAREA I ACTIVAREA APLICAIEI

3.1.1. ncheierea contractului cu CAS pentru furnizare de servicii

3.1.2. Furnizarea cheii de activare a aplicaiei informatice de raportare

3.1.3. Activarea aplicaiei folosind cheia de activare

Versiunea 2.1 din 01.08.2011 Pagina 20 din 56

3.2. FLUXUL DE RAPORTARE PERIODIC

3.2.1. Colectarea datelor

3.2.2. Raportarea electronic

3.2.3. Preluarea rezultatelor raportrii